Contraintes d'intégrité

Pour maintenir les objets cohérents, le modèle doit offrir à l'utilisateur la possibilité d'exprimer des contraintes que le système doit vérifier. Dans le cas où ces contraintes sont

violées, on peut soit refuser les modifications de valeurs, soit essayer de rétablir la cohérence. La notion de contraintes existe principalement dans les bases de données, et a été étendue plus tard aux bases de données orientées objet. Les systèmes diffèrent suivant la nature de la cohérence à assurer (partielle, totale, interne, externe, etc.), la nature des contraintes (structurelles, comportementales, etc.) et le processus de vérification (quand et comment vérifier).

2.3.1.1 Typologie des contraintes

Les contraintes peuvent être classifiées en fonction la cohérence qu'elles veulent exprimer :

• Les contraintes structurelles spécifient la sémantique du modèle de données. Parmi elles, on retrouve les contraintes qui modélisent la disjonction des classes, les liens de dépendances (exclusivité, partage), le caractère obligatoire d’un attribut, etc. [Bouaziz95]. Les contraintes structurelles sont exprimées de manière déclarative au niveau de la description des classes.

• Les contraintes comportementales assurent que les méthodes n'introduisent pas d'incohérences. Ces contraintes sont mises en œuvre à l'aide de pré et post conditions, vérifiées avant et après l'exécution d'une méthode [Defude93] [Meyer88]. Ce type de contraintes peut aussi être mis en œuvre par des règles actives [Bounaas94a].

• Et finalement, les contraintes applicatives ont pour objectif de modéliser la cohérence d'une application. Ces contraintes sont exprimées au niveau du schéma de l’application par des contraintes déclaratives (contraintes de domaine, unicité, caractère obligatoire, etc.) ou par des règles actives [Bouaziz95]. On y retrouve les contraintes qui mettent en jeu un attribut (intra-attribut), plusieurs attributs d'une classe (inter-attribut) ou plusieurs attributs de classes différentes (inter-classes).

2.3.1.2 Contrôle de l'intégrité

Le processus de vérification a besoin de connaître le moment de tester les différentes contraintes. Lorsqu'il s'agit de contraintes structurelles, elles sont vérifiées par et lors des opérations de mise à jour. Par exemple, les contraintes modélisant un lien d'exclusivité sont vérifiées avant l'opération de mise à jour d'un attribut. Le processus de vérification a pour tâche de rétablir les contraintes lorsqu'elles sont violées. Pour cela, il applique une politique qui peut être un rejet ou une propagation de l'opération.

Pour les autres types de contraintes (comportementales et applicatives), l'utilisateur indique quand il faut les vérifier et comment réagir lorsqu'elles sont violées.

La mise en œuvre d'un système d'intégrité doit donc proposer un langage d'expression des contraintes et un mécanisme de contrôle d'intégrité. L'avantage d'une approche par les règles actives est de proposer en même temps un langage d'expression, pouvant être utilisé pour les contraintes, et un mécanisme de déclenchement de règles qui assure le contrôle d'intégrité [Bouaziz95]

2.3.1.3 Les travaux sur les contraintes d'intégrité

Dans ce paragraphe, nous citons quelques travaux sur les contraintes d'intégrité.

Kheops [Bouzeghoub91] propose un langage permettant de spécifier des contraintes d'intégrité. Après un contrôle de compatibilité ou de redondance des contraintes, le système génère des méthodes (en O2C) représentant ces contraintes.

Thémis [Benzaken93] est un langage de bases de données permettant d'exprimer des contraintes d'intégrité utilisant la logique du premier ordre avec intégration des appels de méthodes dans les contraintes. Il est proposé dans ce système une technique d'optimisation pour la vérification des contraintes. L'objectif est de détecter statiquement quelles sont les contraintes qui doivent être vérifiées pendant l'exécution d'une transaction afin de réduire le coût de la vérification.

Dans ContAct [Defude93], les contraintes sont définies sur les méthodes en spécifiant les pré et les post conditions. Ces conditions sont définies dans la signature des méthodes. Une exception est déclenchée si une contrainte est violée.

2.3.1.4 Conclusion sur les contraintes d'intégrité

Les contraintes d'intégrité contrôlent l’évolution des instances car elles permettent de vérifier la cohérence des valeurs modifiées, et/ou de réagir à la violation d'une contrainte pour maintenir la cohérence. Le système d'intégrité qui assurera la gestion de ces contraintes devra assurer l'expression, la manipulation et le maintien de ces contraintes. Les règles actives existant dans la plupart des systèmes [Medeiros91] jouent les rôles de langage d'expression et de mécanisme de mise en œuvre des contraintes d'intégrité.

2.3.2 Les versions

Une version d'instance est un état de l'objet que le système ou l'utilisateur veut conserver [Agrawal90]. L’objectif des versions est de garder une trace dans le temps de l’évolution d’une instance. Le fait de créer une version d’une instance, lorsque celle-ci est modifiée, permet de garder les anciennes versions qui sont cohérentes par rapport aux autres instances. Les versions représentent un thème qui concerne plusieurs domaines tels que les bases de

données, la CAO, le génie logiciel, les bases documentaires, etc. Les pionniers sur ce thème étant bien sûr les concepteurs de logiciel. Les domaines techniques sont appropriées pour la gestion des versions. La gestion de versions est aussi utile dans le domaine de la CAO

[Katz87]. Plusieurs concepteurs veulent, d'une part partager des objets ; ce partage est résolu en affectant une version de l'objet à partager à chaque concepteur. D'autre part, les concepteurs veulent garder l'historique de la conception d'un produit, qui se traduit par un arbre de versions (Figure 2-10).

Une alternative représente une évolution différente d'une même entité qui traduit le choix d'une nouvelle solution. Par contre, une dérivée représente une succession de changement d'état d'une version.

Plusieurs prototypes ou systèmes implémentent un gestionnaire de versions d'objets. Nous n'allons pas les citer tous [Skarra86] [Adele93], mais nous en présenterons un seul, celui d'ORION [Kim88] qui propose une approche un peu différente de celle des autres modèles de versions.

Les versions dans Orion

Un objet est soit “versionnalisable”, instance d'une classe déclarée versionnalisable, soit non versionnalisable. ORION distingue deux types de versions, les versions temporaires ("transient") qui peuvent être modifiées ou détruites, et les versions de travail ("working") qui peuvent être détruites mais non modifiées. L'usager peut explicitement promouvoir une version temporaire en une version de travail. La promotion d'une version temporaire en une version de travail peut être implicite si une version temporaire est dérivée de celle-ci.

Du moment qu'il est possible de dériver d'une version existante des versions temporaires, un objet versioné consiste en une hiérarchie de versions appelée hiérarchie de dérivation de versions. ORION utilise le terme de version d'instance pour référencer un nœud spécifique de la hiérarchie de dérivation, et le terme instance générique pour référencer l'entité abstraite d'un objet versionné. A chaque version d'instance est attachée une instance générique qui maintient l'historique des dérivations des versions d'instances d'un objet versionné.

V1

V1.2 _V1.1

V1.2.1 _V1.2.2

Alternatives

Dérivées

Classe Ci

a1.v0 a1.v1

Instance générique a1

Figure 2-11 : Instance générique

Conclusion sur le versionnement

L'évolution des instances engendre plusieurs points critiques. Parmi ces points, la gestion du stockage de l'historique des données. En effet, il est nécessaire pour les utilisateurs de garder une trace de leurs données dans le temps. Le problème des versions ne constitue pas, dans le cadre de cette thèse, une priorité de notre travail, car il a déjà été étudié dans le cadre du système SHOOD [Djeraba93b].