Vérification de la métacircularité du MOF

Nous décrivons maintenant comment EMOF_Core peut 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 Class et chaque réfé-rence ou attribut comme un objet de type P 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 : ownedAttribute : superClass : type : opposite : Class name = "NamedElement" isAbstract = true : Property name = "name" : Class name = "Type" isAbstract = true : Property name = "type" : Class name = "DataType" isAbstract = true : Class name = "TypedElement" isAbstract = true : Class name = "Class" : Property name = "isAbstract" default = "false" : Property name = "superClass" lower = 0 upper = * : Property name = "ownedAttribute" lower = 0 upper = * isOrdered = true isComposite = true : Class name = "Property" : Property name = "lower" default = "1" : Property name = "upper" default = "1" : Property name = "isOrdered" default = "false" : Property name = "isComposite" default = "false" : Property name = "opposite" lower = 0 : Property name = "owner" : Property name = "default" : Class name = "Boolean" : Class name = "Natural橫" : Class name = "String"

FIGURE 8.6: Modèle (en MOF) de EMOF_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 type Class comme concept dans la classe de modèles cible. Le champ name des objets est utilisé pour identifier les classes. Nous avons donc les concepts suivants : DataType, Natural⊤... Plus formellement, soit (MV, ME) le graphe du modèle. Nous construisons l’ensemble RV 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 objet o₁ de type Class à un objet o₂ de type Property, par un arc de type ownedAttribute, suivi par un arc de type type vers une objet o₃ de type Class. Chaque chemin est traduit en référence, de la classe associée à l’objet o₁vers la classe associée à la l’objet o₃. Ils sont étiquetés par l’at-tribut name de l’objet o₂. Ces références seront plus tard associées à des propriétés sémantiques.

Soit Rule le prédicat utilisé comme règle de matching pour identifier les che-mins.

Rule(o₁, o₂, o₃) , hho₁, Classi,♦✇♥❡❞❆ttr✐❜✉t❡, ho2, 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 fonction conformsT 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 label superClass entre 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, ho2, Classii ∈ M E }

Classes abstraites Chaque classe c résultant de la promotion d’un objet o avec un attribut✐s❆❜str❛❝t dont la valeur est tr✉❡ 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 ∈ ME }

lower Chaque référence o2.nameentre les classes o₁.nameet o₃.name, formant le triplet (o1, o₂, o₃) traduit par la règle de matching, a un nombre minimum de o₂.❧♦✇❡r instanciations dans un modèle valide.

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

^  upper(o₁.name, o₂.name, o₂.✉♣♣❡r) Rule(o1, o₂, o₃) ordered Chaque référence construite en utilisant la règle de matching et pour

la-quelle l’objet o₂ 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 objet o1avec un lien typé♦♣♣♦s✐t❡ vers

un autre objet o₂possède également une référence inverse. ^ { isOpposite(o₁.name, o₂.name) |

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

composite Chaque référence entre classes qui a été construite en utilisant la règle de matching et pour laquelle l’objet o₂ a un attribut nommé isComposite avec la valeur à true satisfait 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 ∈ ME } 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’objet o₂ a un attribut nommé default ayant pour valeur v 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.