Évolutions et Contraintes

Le modèle met l’accent sur la notion de produit cartésien, c’est-à-dire que toute entité du « monde réel » peut être associée à, ou définie par, un nombre illimité de facettes. Ainsi, pendant sa durée de vie, une entité peut évoluer très facilement en y associant ou en y supprimant des valeurs de facettes. Ces opé- rations se traduisent par le changement des extensions des facettes respectives dansF et éventuellement par l’ajout ou la suppression d’une entité dansE.

Lorsque nous associons une valeur de facette à une entité, nous disons que nous attachons la facette à l’entité. Inversement, lorsque nous supprimons une valeur de facette d’une entité, nous disons que nous

détachons la facette de l’entité. Nous parlerons aussi d’opérations respectivement de plug et d’unplug de

facettes.

Ces opérations sont à la source de la flexibilité du système. Reprenons à nouveau l’exemple de la problématique dans la figure 8.2. En attachant ou détachant des facettes successivement, une entité peut évoluer aisément au cours de sa durée de vie : Jacques Durand, après avoir été technicien quelques années évolue naturellement vers un poste à responsabilités. Toutefois, un minimum de contrôle est nécessaire puisqu’il existe dans le monde réel des contraintes qui peuvent limiter la flexibilité.

8.2.1 Facettes principales

Tout d’abord, toutes les facettes ne peuvent être utilisées comme la première facette d’une entité. Nous pouvons, par exemple, imposer qu’il n’y a aucun sens à créer juste une PERSONNE, cette entité doit au moins représenter autre chose, comme un AUTEUR ou un EMPLOYÉ. Dans ces circonstances, la facette PERSONNE ne peut pas servir à la création d’une nouvelle instance ex nihilo. Comme nous

(a) P er so n n e Prof il Emplo_ye T ec_h n ic ie n 1288 (b) P er so n n e Prof il Emplo_ye T ec_h n ic ie n 1288 M an ag er

Figure 8.2 – L’entité Jacques Durand (ID 1288) avant (a) et après (b) sa promotion

le verrons dans la prochaine section, elle doit être impliquée parAUTEUR ou EMPLOYÉ, qui sont des facettes autorisées pour la création de nouvelles entités.

Nous définissons donc un sous-ensemble non vide de noms de facettes principales (ou main facets) MF :

∅ ⊂ MF ⊆ NF (8.9)

En remplacement de l’équation (8.7), l’existence d’une entité est maintenant subordonnée au support d’au moins une facette principale :

∀e ∈ E, ∃(f, t) ∈ MF × T : (f, e, t) ∈ F (8.10)

En conséquence, si la dernière facette principale supportée par une entité est détachée, alors cette entité et les facettes restantes sont automatiquement supprimées (voir la section A.2 de l’annexe sur le cycle de vie pour un exemple d’implémentation).

La facette principale agit comme une classe dans des paradigmes plus classiques, au moins lors de la création d’instances. Cependant, ce couplage entre une instance et sa « classe » est faible. Au contraire des modèles à objets, il est en effet possible à une entité de supporter plusieurs facettes principales en même temps. Par exemple, une personne peut être créée comme unEMPLOYÉ; ensuite, elle peut deve- nir simultanément un EMPLOYÉ et unAUTEUR de documentation ; finalement, elle restera unAUTEUR en quittant la société. La mutabilité du modèle est intrinsèquement importante. En comparaison, les rôles [27] sont restreints à ceux définis sur la classe de leur instance.

8.2.2 Contraintes sur les facettes

En plus de la notion de facette principale, d’autres contraintes nous permettent de contrôler la flexibi- lité. La catégorie la plus simple de ces contraintes concerne les valeurs des facettes (cf. section 3.3.1). Il s’agit simplement de limiter les valeurs d’une facette en en contraignant le domaine grâce, par exemple, à un intervalle ou une énumération de valeurs autorisées.

Par contraste, les contraintes sur les facettes sont plus complexes et nous permettent d’imposer des règles sur les mécanismes d’attachement et de détachement de facettes. Il en existe trois types : exclusion, implication et implication légère (soft implication).

CHAPITRE 8 — DOAN : Un modèle flexible 81

Exclusion. L’exclusion est une contrainte binaire et bi-directionnelle. Elle interdit à toute instance de supporter simultanément les deux facettes spécifiées. Formellement, nous avons la définition suivante :

f1 rejectsf2, f2rejectsf1⇒ dom(f1) ∩ dom(f2) = ∅ (8.11)

où nous utilisons une notation simplifiée pour décrire le domaine d’une extension de la facette f dans l’extension de schémaS (l’indice est supprimé quand il n’y a pas d’ambiguïté) :

dom

hE,Fi(f ) = {e ∈ E|∃t ∈ T : (f, e, t) ∈ F} (8.12)

Si nous tentons d’attacher une facette à une entité supportant déjà une autre facette en exclusion avec la nouvelle, l’opération est interrompue et une erreur est retournée.

Implication. La contrainte d’implication nous aide à nous assurer que toutes les facettes qui « tra- vaillent » ensemble sont présentes. Par exemple, attacher la facette EMPLOYÉ implique que la facette

PERSONNEest déjà présente sur l’instance. Ainsi, siPERSONNEn’est pas encore supportée par l’entité, elle est attachée automatiquement avant EMPLOYÉ. Pour la même raison, il est impossible de détacher PERSONNEsiEMPLOYÉest présente. Formellement, nous notons :

f1impliesf2⇒ dom(f1) ⊆ dom(f2) (8.13)

Ainsi, les implications sont transitives :

f1impliesf2∧ f2impliesf3 ⇒ f1impliesf3 (8.14)

Les implications sont maintenues sous la forme d’un graphe acyclique orienté. L’opération d’atta- chement des facettes impliquées est réalisée récursivement avant l’attachement de la nouvelle.

Implication légère. L’implication légère, que nous appelons aussi soft implication ou softplug, est similaire à l’implication lors de l’opération d’attachement mais ne déclenche aucune action durant le détachement. Par exemple, unEMPLOYÉest généralement vu comme unUTILISATEURdu système, mais l’application peut fonctionner avec la facetteEMPLOYÉ seule. En conséquence, la facetteUTILISATEUR peut être détachée plus tard.

Il n’y a aucune restriction sur la structure du graphe d’implications légères. En particulier, il est pos- sible de combiner une liste d’implications et une seule implication légère pour obtenir un comportement similaire à des implications croisées.

Ces trois contraintes sont exclusives par paires :

f1 impliesf2 ⇔ ¬f1rejectsf2

f1 impliesf2 ⇔ ¬f1softplugsf2

f1rejectsf2 ⇔ ¬f1softplugsf2

(8.15)

L’évolution des contraintes est elle aussi contrôlée. La suppression d’une contrainte n’a aucune conséquence sur l’extension de schéma ; elle est donc toujours acceptée. En revanche, l’ajout d’une exclusion déclenche le contrôle des entités existantes. Une erreur est renvoyée si les données présentes et le modèle existant n’obéissent pas à la nouvelle contrainte. Pour l’implication, soit toutes les facettes requises sont attachées avec des valeurs par défaut, soit une erreur est retournée si la nouvelle implication

n’est pas admissible (au niveau de la structure du graphe acyclique orienté, ou à cause de contre-exemples dans les données).

D’autre part, l’opération de détachement (unplug) est sujette à un choix de conception : les fa- cettes impliquées doivent-elles être détachées automatiquement avec les facettes qui les impliquent ? Nous avons décidé de donner le choix au concepteur entre une approche conservatrice où les facettes impliquées sont laissées telles quelles, et une approche plus agressive où les facettes qui ont été at- tachées automatiquement suite à une contrainte d’implication sont détachées elles aussi (voir l’option

CascadingUnplug, dont l’influence est détaillée en section A.2 de l’annexe sur le cycle de vie).