Vérification de la métacircularité du MOF

Nous décrivons maintenant comment EMOF_Corepeut formellement se dé-crire en lui-même. La vue usuelle de EMOF présentée sur la figure8.5correspond à la classe de modèles, sans la fonction de conformité. La notation utilisée (celle du diagramme de classe UML) ne permet de représenter qu’une partie de la séman-tique, par exemple les multiplicités sur les références. Nous introduisons mainte-nant le modèle de EMOF, puis la fonction de promotion permettant d’obtenir la classe de modèles correspondant à EMOF.

Création du modèle MOF à partir de la classe de modèles MOF

La figure 8.6 présente le modèle de EMOF_Core avec la notation du dia-gramme d’objet d’UML. Dans ce diadia-gramme, les attributs avec les valeurs par défaut ne sont pas présentés et les liens ont une notation graphique en fonction de leur type. Tout élément du modèle est une instance d’un concept de la classe de modèles du MOF présenté sur la figure8.5. Le modèle respecte également les propriétés sémantiques de la classe de modèles.

Chaque concept est instancié comme un objet de type Classet chaque réfé-rence ou attribut comme un objet de typeP roperty. Une propriété d’un concept, référence ou attribut, est représentée par un lien de l’objet instanciant le concept vers l’objet instanciant la propriété. Il y a aussi un lien de l’objet instanciant la pro-priété vers l’objet instanciant le type de la propro-priété. Par exemple, un attribut devra pointer vers un objet instanciant le concept Boolean, String ou Natural^⊤ (c.-à-d.

DataType).

Promotion du modèle MOF vers la classe de modèles MOF

Nous décrivons maintenant la fonction de promotion qui, à partir du modèle de la figure8.6 représenté comme un multigraphe typé, construit une classe de mo-dèles. Celle-ci est représentée par une paire composée d’un multigraphe et d’une conjonction de propriétés sémantiques sur les éléments du multigraphe. Cette fonc-tion est définie en trois étapes :

1. nous construisons d’abord les nœuds du graphe de la classe de modèles, 2. nous définissons les références entre ces nœuds,

3. nous enrichissons finalement le graphe résultant avec les propriétés expri-mées sur les éléments du graphe.

8.3. FORMALISATION DE MOF ET DE LA PYRAMIDE DE L’OMG 139 name = "Natural橫"

: Class name = "String"

FIGURE 8.6: Modèle (en MOF) deEMOF_Core(notation du diagramme d’objet UML)

Construction des nœuds : concepts de la classe de modèles Cette première étape est simple. Nous devons identifier dans le modèle les nœuds qui sont les concepts dans la classe de modèles.

Dans le modèle MOF, nous identifions les objets qui sont de typeClasscomme concept dans la classe de modèles cible. Le champnamedes objets est utilisé pour identifier les classes. Nous avons donc les concepts suivants : DataType, Natural^⊤...

Plus formellement, soit(M V, M E) le graphe du modèle. Nous construisons l’ensembleRV de la classe de modèles de la manière suivante :

RV ,

o.name ho, Classi ∈M V

Constructions des arcs : références de la classe de modèles Une fois que les classes ont été construites, la seconde étape consiste à enrichir le graphe avec les arcs entre les nœuds, représentant les références entre les classes. Les arcs sont construits à partir d’une séquence de liens et d’objets dans le modèle MOF.

La règle traduit les chemins d’un objeto₁ de typeClassà un objeto₂ de type Property, par un arc de type ownedAttribute, suivi par un arc de type type vers une objeto₃ de typeClass. Chaque chemin est traduit en référence, de la classe associée à l’objeto₁vers la classe associée à la l’objeto₃. Ils sont étiquetés par l’at-tributnamede l’objeto₂. Ces références seront plus tard associées à des propriétés sémantiques.

SoitRulele prédicat utilisé comme règle dematchingpour identifier les che-mins.

Rule(o₁, o₂, o₃), hho₁, Classi,♦✇♥❡❞❆ttr✐❜✉t❡,ho₂, P ropertyii ∈M E

∧hho2, P ropertyi,t②♣❡,ho3, Classii ∈M E

RE est l’ensemble des arcs dans la classe de modèles construite avec cette règle.

RE,

ho₁.name, o₂.name, o₃.namei Rule(o₁, o₂, o₃)

Enrichissement de la classe de modèles avec les propriétés sémantiques La dernière étape consiste à enrichir le graphe de la classe de modèles résultant par les propriétés sémantiques du modèle. Ces propriétés sémantiques (intégrées à la fonctionconf ormsT o) portent sur les éléments du graphe. Chacune de ces pro-priétés est définie formellement et correspond à une propriété du MOF introduite dans la partie8.3.1.

Héritage Chaque lien avec un labelsuperClassentre deux objets de type Class est traduit comme une relation d’héritage entre les deux classes correspon-dantes.

^ {subClass(inh, o1.name, o₂.name)|

hho₁, Classi,s✉♣❡r❈❧❛ss,ho₂, Classii ∈M E}

Classes abstraites Chaque classecrésultant de la promotion d’un objetoavec un attribut✐s❆❜str❛❝tdont la valeur esttr✉❡a la propriétéisAbstract(c). Elle dénote qu’une classe abstraite ne peut pas être instanciée.

^ {isAbstract(inh, o.name)|

hho, Classi,✐s❆❜str❛❝t,htr✉❡, Booleanii ∈M E}

lower Chaque référenceo₂.nameentre les classeso₁.nameeto₃.name, formant le triplet(o1, o₂, o₃)traduit par la règle dematching, a un nombre minimum deo₂.❧♦✇❡rinstanciations dans un modèle valide.

^ lower(o₁.name, o₂.name, o₂.❧♦✇❡r) Rule(o₁, o₂, o₃) upper Cette propriété sémantique est définie de manière similaire.

^ upper(o₁.name, o₂.name, o₂.✉♣♣❡r) Rule(o₁, o₂, o₃)

ordered Chaque référence construite en utilisant la règle dematchinget pour la-quelle l’objeto₂ a un attribut appeléisOrdered avec la valeur à true, doit satisfaire la propriété d’ordre. Cette propriété est relative à l’ordre dans le-quel l’ensemble des objets cibles de la référence peuvent être accédés et donc implique que les notions de temps et d’exécution soient définies. Cette propriété n’est donc pas traitée dans un premier temps par notre langage de requête.

8.3. FORMALISATION DE MOF ET DE LA PYRAMIDE DE L’OMG 141 opposite Chaque référence promue d’un objeto₁avec un lien typé♦♣♣♦s✐t❡vers

un autre objeto₂possède également une référence inverse.

^ {isOpposite(o₁.name, o₂.name)|

hho₁, P ropertyi,♦♣♣♦s✐t❡,ho₂, P ropertyii ∈M E}

composite Chaque référence entre classes qui a été construite en utilisant la règle de matchinget pour laquelle l’objet o₂ a un attribut nommé isComposite avec la valeur àtruesatisfait la propriété de composition. Nous définissons d’abord l’ensemble des relations de composition.

compRelations,{o₂.name|

ho2, P ropertyi,✐s❈♦♠♣♦s✐t❡,htr✉❡, Booleanii ∈M E} Puis nous définissons la propriété à ajouter àconformsTo.

^ areComposite(o₁.name, compRelations) ho₁, Classi ∈M V

default value Chaque lien entre objets promu en utilisant la règle de matching et pour laquelle l’objeto₂ a un attribut nommédefault ayant pour valeurv permet d’initialiser la propriété. Cette propriété n’est valide que pour l’état initial des objets, et nous ne détaillons donc pas ici sa gestion qui doit être prise en charge par la sémantique d’exécution.