Définition du ModelClass EMOF_Core

Le sous-ensemble d’EMOF est présenté dans la figure8.5en utilisant la nota-tion usuelle du diagramme de classe UML. Le ModelClass associé peut être défini de la manière suivante :

RV , { N amedElement, T ype, T ypedElement, DataT ype, Boolean, String, N atural⊤, Class, P roperty}

RE , { hClass,♦✇♥❡❞❆ttr✐❜✉t❡, P ropertyi, hClass, ✐s❆❜str❛❝t, Booleani, hClass,s✉♣❡r❈❧❛ss, Classi, hClass, inh, T ypei, . . . }

où “inh” représente la relation standard d’héritage.

Nous détaillons dans la suite de cette partie la formalisation de la classe de modèles. La fonction conformsT o est pour sa part présentée dans la partie8.3.2

comme le résultat de la promotion définie.

Une classe (Class dans la figure8.5) est une entité conceptuelle qui permet de définir une famille d’objets. Elle peut être instanciée pour construire des instances. Une instance est un objet particulier qui a été créé en suivant les contraintes de structure définies par sa classe. Chaque instance est liée exactement à une classe par la relation d’instanciation.

Une classe regroupe un ensemble ordonné de propriétés (P roperty) qui sont instanciées de multiples fois pour construire la structure de chaque objet. Chaque propriété est définie entre une classe et un type (T ype) qui peut être :

– un type de donnée (DataT ype), associé à une sémantique de valeur. Elle est alors appelée attribut.

Description d’une classe

Héritage Il s’agit du moyen de définir une classe (une sous-classe) en réutili-sant d’autres classes (les classes parentes) déjà définies. Une sous-classe est liée à ses classes parentes par un lien de type superClass. La nouvelle classe hérite des propriétés des classes parentes.

Dans le cadre que nous avons défini, nous avons identifié différentes approches possibles selon que la classe de modèles doit intégrer ou non la notion d’héritage.

Dans le cas sans héritage les objets ne peuvent pas être dupliqués et nous for-malisons la propriété ainsi :

noInheritance ,hM V, M Ei 7→

∀ho1, c₁i, ho2, c₂i ∈ M V, o1 = o2 ⇒ c1= c2

Dans le cas d’un héritage classique, les objets peuvent être dupliqués, à condi-tion que les classes de ces doublons est un sous-type commun, la classe de base. La propriété suivante est paramétrée par inh, prenant en compte la relation d’héritage standard. Nous définissons d’abord un prédicat auxiliaire qui exprime qu’un objet ode type c₁a un dupliqué de type c₂, avec c₂sous-type de c₁.

hasSub(inh ∈ RE, o ∈❖❜❥❡❝ts, c1, c₂∈❈❧❛ss❡s, hMV, MEi) , c₁ = c₂∨ ∃c₃∈❈❧❛ss❡s, hho, c2i, inh, ho, c₃ii ∈ M E

∧hasSub(inh, o, c1, c₃,hM V, M Ei)

Nous définissons ensuite la notion d’héritage standard. Le premier prédicat ex-prime que la relation d’héritage se transmet à travers les objets dupliqués. Le deuxième exprime que chaque ensemble d’objets dupliqués a un objet dupliqué de base, c’est à dire dont la classe est la classe de classe.

standardInheritance(inh ∈ RE) , hM V, M Ei 7→ ∀hho₁, c₁i, inh, ho₂, c₂ii ∈ M E, o₁ = o₂

∧∀ho1, c₁i, ho2, c₂i ∈ M V, o1 = o2⇒ ∃c ∈❈❧❛ss❡s, hasSub(inh, o₁, c₁, c,hM V, M Ei)

∧hasSub(inh, o₂, c₂, c,hM V, M Ei)

Enfin, la propriété suivante exprime que c₂ est une sous-classe de c₁. subClass(inh ∈ RE, c1, c₂ ∈ RV ) , hM V, M Ei 7→

∀ho, ci ∈ M V, c = c₂ ⇒ hho, c₂i, inh, ho, c₁ii ∈ M E

Les classes abstraites Une classe est abstraite si son attribut isAbstract a la va-leur vraie. Elle ne peut pas être instanciée. Les classes abstraites sont utilisées pour représenter les entités et concepts abstraits.

Dans un modèle M conforme à MC, chaque objet instance d’une classe abs-traite doit avoir un objet dupliqué instance d’une des sous-classes concrètes. Pour

8.3. FORMALISATION DE MOF ET DE LA PYRAMIDE DE L’OMG 137 vérifier cette propriété il suffit d’appliquer le prédicat isAbstract suivant sur toutes les classes identifiées comme abstraites.

isAsbstract(inh ∈ RE, c₁∈ RV ) , hM V, M Ei 7→

∀ho, ci ∈ M V, c = c₁ ⇒ ∃c₂ ∈ RV, hho, c₂i, inh, ho, c₁ii ∈ M E Description des propriétés

Lower & Upper Pour un attribut ou une référence, le nombre minimum et maxi-mum d’instances du concept cible peut être défini en utilisant les attributs lower et upper. Cette paire est usuellement appelée multiplicité. Ces deux attributs sont utilisés afin d’exprimer un intervalle pour le nombre d’instances possibles. Un in-tervalle non borné est modélisé en utilisant la valeur ⊤ pour l’attribut upper. Nous introduisons pour cela le type Natural⊤= N ∪ {⊤} où ∀e ∈ N, e < ⊤. Ce type est également défini par l’OMG sous le nom de UnlimitedNatural [OMG06b, §12]).

lower(c1∈ RV, r1 ∈ RE, n ∈ N atural⊤) , hM V, M Ei 7→

∀ho, ci ∈ M V, c = c₁⇒ card({m₂ ∈ M V | hho, c₁i, r₁, m₂i ∈ M E}) ≥ n Une formalisation analogue est définie pour la propriété upper en remplaçant ≥ par ≤.

Opposite Une référence peut être associée à une autre référence, dite opposite. Cela implique qu’un modèle valide devra, pour chaque lien entre deux objets ins-tances de cette référence, avoir un lien en sens inverse entre ces deux mêmes objets typée par la relation opposée.

isOpposite(r₁, r₂ ∈ RE) , hM V, M Ei 7→

∀m1, m₂ ∈ M V, hm1, r₁, m₂i ∈ M E ⇔ hm2, r₂, m₁i ∈ M E Composite Une référence peut être composite. Une instance d’un concept ne peut être cible que d’au plus une instance d’une référence composite. La formali-sation de cette propriété nécessite de considérer l’ensemble R des références com-posites et est donnée par le prédicat areComposite pour les objets d’une classe c₁. Une référence composite est également caractérisée par une propriété temporelle qui limite la durée de vie d’un composé à celle du composant. Cette propriété n’est actuellement pas prise en compte par l’expressivité de notre langage de contrainte et sera donc à prendre en compte dans la sémantique d’exécution du DSML.

areComposite(c1∈ RV, R ⊆ RE) , hM V, M Ei 7→ ∀ho, ci ∈ M V, c = c₁ ⇒

card({m₁∈ M V | hm₁, r,ho, cii ∈ M E, r ∈ R}) ≤ 1

Il existe d’autres propriétés que nous ne détaillons pas ici, comme par exemple de ne pas avoir deux références opposites qui sont toutes les deux composites. Une autre est la notion d’ensemble ordonné (isOrdered). Sa sémantique est temporelle

et n’est pas traitée dans cette partie. Elle doit suivre la définition d’un comporte-ment à travers une sémantique d’exécution (ordre d’insertion et d’accès aux objets de l’ensemble).