Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Du 22 au 24 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. UML 2.5
  3. Métamodélisation
Extrait - UML 2.5 Initiation, exemples et exercices corrigés (5e édition)
Extraits du livre
UML 2.5 Initiation, exemples et exercices corrigés (5e édition)
4 avis
Revenir à la page d'achat du livre

Métamodélisation

Introduction

Dans ce chapitre, nous étudions la métamodélisation en UML. Dans un premier temps, nous étudions les profils, qui sont un support pour enrichir les capacités de modélisation d’UML, notamment au niveau de leur sémantique, afin d’adapter UML :

  • soit à une plateforme spécifique telle que Java, .NET ou EJB ;

  • soit à un domaine spécifique à l’utilisateur, comme le domaine des équidés.

Un profil est un support léger d’extension : il appose de nouvelles constructions au métamodèle d’UML, mais ne permet pas d’en modifier les constructions existantes. Ces nouvelles constructions sont principalement les stéréotypes, les tagged values (valeurs étiquetées) et les contraintes. Les contraintes sont décrites en langage naturel ou à l’aide du langage OCL qui a été abordé au chapitre La modélisation des objets.

Un profil est décrit par un diagramme de profil, qui fait partie des diagrammes de structure d’UML. Il introduit un type spécifique de paquetage. Les paquetages ont été introduits au chapitre La structuration des éléments de modélisation.

Dans un deuxième temps, nous présentons le métamodèle d’UML. Le métamodèle contient toutes les constructions décrivant les éléments UML et en particulier ceux que nous avons étudiés dans les chapitres précédents. Un exemple d’une telle construction est la classe Class qui décrit les classes ou encore la classe Interface qui décrit les interfaces. Les classes sont des instances de la classe Class, tandis que les interfaces sont des instances de la classe Interface. Les classes du métamodèle sont appelées des métaclasses....

Les stéréotypes

1. Les métaclasses

Un stéréotype est défini comme une extension d’une métaclasse. Il convient, par conséquent, d’étudier dans un premier temps la notion de métaclasse. Une métaclasse est une classe dont les instances sont des éléments d’UML détenant eux-mêmes des instances. Citons, à titre d’exemple, la métaclasse Class dont les instances sont des classes, la métaclasse Interface dont les instances sont des interfaces et la métaclasse Association dont les instances sont des associations entre deux classes.

Dans la documentation du métamodèle d’UML, les métaclasses sont présentées comme des classes sans indication explicite de leur nature de métaclasse. Nous faisons le choix de les munir du stéréotype «Metaclass» pour faciliter la lecture des diagrammes. La figure 11.1 montre la représentation simplifiée de la métaclasse Class en UML, à savoir sans ses attributs, opérations et associations. 

images/N11RI01.png

Figure 11.1 - Représentation simplifiée en UML de la métaclasse Class

Les principales métaclasses du métamodèle d’UML sont les suivantes :

Métaclasse

Description

Association

Métaclasse concrète décrivant les associations, par exemple entre deux instances de la métaclasse Class.

Class

Métaclasse concrète décrivant les classes. Class est une sous-classe de la métaclasse Classifier. Elle introduit la description des opérations, attributs et rôles.

Classifier

Métaclasse abstraite décrivant des éléments pouvant être spécialisés (introduction de la relation de spécialisation/généralisation).

Element

Métaclasse...

Les tagged values (valeurs étiquetées)

1. Introduction

Un stéréotype peut introduire des attributs comme toute classe. Dans la terminologie UML, un tel attribut est appelé un tag (étiquette) et un couple (attribut, valeur) est appelé une tagged value (valeur étiquetée par le nom de l’attribut). Chaque tag d’un stéréotype donne lieu à une tagged value au sein de l’élément UML qui est muni de ce stéréotype.

Comme un attribut, un tag possède un type. Seuls les types introduits dans le métamodèle (et, comme nous le verrons plus loin, dans le profil) peuvent être utilisés pour typer un tag.

La figure 11.9 montre un exemple d’introduction du tag prixMoyen dans le stéréotype «ChevalDeSport» et de la tagged value correspondant à ce tag dans la classe TrotteurFrançais qui est munie de ce stéréotype. Les tagged values d’un élément sont indiquées sous la forme d’une liste entre accolades.

images/N11RI10.png

Figure 11.9 - Le tag prixMoyen du stéréotype «ChevalDeSport»

2. Les associations entre stéréotypes

Il est possible d’introduire des associations entre les stéréotypes d’un profil. Ces associations sont en tout point identiques à celles existant entre des classes. Une association binaire entre deux stéréotypes relie des éléments munis du stéréotype situé à une extrémité de l’association à des éléments munis du stéréotype situé à l’autre extrémité. La figure 11.10 illustre une telle association entre les stéréotypes «ChevalDeSport» et «SportÉquin».

Le stéréotype «SportÉquin»...

Les autres éléments d’un profil

1. Les contraintes

Un stéréotype peut également introduire des contraintes qui s’appliquent aux éléments qui sont munis de ce stéréotype. La figure 11.12 illustre ce cas dans le cadre d’un profil spécifique au langage Java. En effet, en UML, il est possible d’employer l’héritage multiple des classes alors que c’est interdit en Java. Le stéréotype «JavaClass» introduit une contrainte écrite en OCL qui interdit l’héritage multiple.

images/N11RI14.png

Figure 11.12 - Le stéréotype «JavaClass»

Cette contrainte écrite en OCL s’appuie sur la description de la relation de généralisation/spécialisation dans le métamodèle d’UML qui est introduite au niveau de la métaclasse Classifier, surclasse de la métaclasse Class. Cette description sous une forme simplifiée est fournie par la figure 11.13 où il apparaît que les éléments généraux d’une instance de Classifier sont fournis par l’expression de chemin self.generalization.general. Comme le rôle generalization a pour cardinalité la cardinalité multiple *, il convient d’utiliser l’opérateur collect pour obtenir tous les éléments généraux sous la forme d’une collection qui est ensuite transformée en un ensemble pour supprimer les éventuels doublons. La contrainte vérifie ensuite que cet ensemble a un nombre d’éléments inférieur ou égal à 1.

images/N11RI15.png

Figure 11.13 - Description de la relation de généralisation dans le métamodèle

Afin de compléter la description d’une classe du langage Java en UML, le tag javaStrictfp est introduit. Il sert...

Les profils

1. La représentation d’un profil

Un profil est représenté par un paquetage de profil, à savoir un paquetage muni du stéréotype «profile» détaillant tous les éléments qu’il contient ainsi que les métaclasses qu’il étend. La figure 11.14 illustre un exemple de profil appelé ChevauxSport.

images/N11RI16.png

Figure 11.14 - Le profil ChevauxSport

2. La relation de référence

La relation de référence permet d’importer une ou plusieurs métaclasses depuis un métamodèle vers un profil où elles deviennent visibles par tout modèle appliquant ce profil. Il est possible d’importer implicitement toutes les métaclasses du métamodèle dans le profil. Une autre possibilité est de choisir explicitement les métaclasses à importer dans le profil. Enfin, il est possible d’étendre une métaclasse sans l’importer. Dans ce cas, seules ses instances étendues par le stéréotype sont visibles.

Le premier cas où toutes les métaclasses du métamodèle UML sont implicitement importées dans le profil Chevaux est illustré à la figure 11.15.

images/N11RI17.png

Figure 11.15 - Relation de référence avec importation implicite

Le deuxième cas où seules les deux métaclasses Class et Interface du métamodèle UML sont explicitement importées dans le profil Chevaux est illustré à la figure 11.16. Les autres métaclasses du métamodèle UML ne sont pas visibles. L’importation implicite est surchargée par les deux importations explicites.

images/N11RI18.png

Figure 11.16 - Relation de référence avec importation explicite

La figure 11.17 illustre un cas d’importation explicite pour la métaclasse Class...

Un exemple de domaine : les équidés

Nous présentons, à titre d’exemple, un modèle basé sur le domaine des équidés.

1. Le profil

Le profil est présenté à la figure 11.19 sous la forme d’un diagramme de profil. Trois stéréotypes concrets sont introduits pour étendre la métaclasse Class dans le cadre de la modélisation des équidés : «ÉquidéDeTrait», «ÉquidéDeSelle» et «ÉquidéDeSport». La hiérarchie des stéréotypes relative au sport équin est constituée du stéréotype abstrait «SportÉquin» spécialisé par les deux stéréotypes concrets : «SportHippique» et «SportÉquestre». Le stéréotype abstrait permet d’introduire l’association sport/équidéTaillé dont les liens connectent des instances de ses deux sous-stéréotypes concrets à des instances du stéréotype «ÉquidéDeSport». Enfin, le stéréotype «Alimentation» étend la métaclasse Association en introduisant le tag alimentationPrincipale. Ce stéréotype peut être appliqué à toute association du modèle.

images/N11RI21.png

Figure 11.19 - Le profil Équidés

2. Le modèle

Le modèle est présenté aux figures 11.20 et 11.21 sous la forme de deux diagrammes de classes. Le diagramme de la figure 11.20 introduit plusieurs classes dont les classes NourritureVégétale et Équidé. Ces deux classes sont liées par une association interobjets munie du stéréotype «Alimentation».

Le diagramme introduit aussi une classification de plusieurs...

Un exemple de profil de plateforme : un profil pour EJB

La figure 11.22 illustre un profil de plateforme, à savoir la plateforme EJB (Enterprise Java Beans). Cet exemple de profil extrait du document de l’OMG décrivant la superstructure d’UML introduit plusieurs stéréotypes :

  • Le stéréotype «Bean» qui étend la métaclasse Component. Il est abstrait et spécialisé par les deux sous-stéréotypes «Entity» et «Session». Comme «Bean» est un stéréotype requis, chaque instance de la métaclasse Component doit être munie de l’un de ces deux sous-stéréotypes. Ce stéréotype introduit une contrainte complémentaire qui interdit la généralisation et par conséquent la spécialisation des beans. Cette contrainte est comparable à celle présentée précédemment pour imposer, en Java, l’héritage simple des classes.

  • Le stéréotype «JAR» qui étend la métaclasse Artifact.

  • Les deux stéréotypes «Remote» et «Home» qui étendent la métaclasse Interface

La métaclasse Component a pour instances les composants qui sont abordés au chapitre La modélisation de l’architecture du système, dans lequel sont également étudiés les artefacts dont la métaclasse est Artifact.

images/N11RI24.png

Figure 11.22 - Un exemple de profil EJB

Le métamodèle d’UML

1. Présentation

En UML, un modèle décrit un domaine au travers de différents diagrammes. Le métamodèle d’UML décrit un domaine particulier : UML lui-même. En conséquence, il décrit l’ensemble des éléments d’UML. Il s’agit d’une description statique basée sur les éléments des diagrammes de classes et d’objets. Le métamodèle fait ainsi partie d’UML et il se décrit donc lui-même.

Le métamodèle d’UML contient des centaines d’éléments. Il est beaucoup trop important pour être étudié de façon exhaustive dans le cadre de ce livre. La figure 11.23 montre le fragment que nous avons choisi d’étudier. Il s’agit de la partie relative aux classes et aux associations. Ce fragment ne montre pas cette partie dans son intégralité : des associations comme nestingClass et des classes comme Relationship n’y figurent pas, les contraintes n’ont pas été indiquées, etc.

images/11R23V5.png

Figure 11.23 - Fragment du métamodèle UML

Les éléments du métamodèle apparaissant sur la figure 11.23 sont les suivants :

Élément

Description

AggregationKind

Énumération indiquant le type d’agrégation : pas d’agrégation (none), composition faible (shared) ou composition forte (composite).

Association

Métaclasse concrète décrivant les associations. Chaque extrémité est représentée par une instance de Property et liée par le rôle memberEnd. Le rôle ownedEnd représente les extrémités qui appartiennent à l’association. Le rôle navigableOwnedEnd représente...

Exemples

La figure 11.24 illustre un diagramme de classes avec deux classes (Propriétaire et Cheval) ainsi que l’association appartenance.

images/11R24V5.png

Figure 11.24 - Exemple de diagramme de classes

La figure 11.25 montre la représentation de ce diagramme de classes sous la forme d’un diagramme d’objets (instances de métaclasses du métamodèle).

images/11R25V5.png

Figure 11.25 - Représentation sous la forme d’un diagramme d’objets

Enfin, la figure 11.26 montre comment le métamodèle d’UML peut se décrire lui-même. Nous avons choisi de décrire un tout petit extrait du diagramme de la figure 11.23, à savoir l’association réflexive class/superClass qui s’applique à la métaclasse Class.

images/11R26V5.png

Figure 11.26 - Association class/superClass sous la forme d’un diagramme d’objets

Représentation des stéréotypes dans le métamodèle

La figure 11.27 montre de façon simplifiée comment les stéréotypes sont introduits dans le métamodèle.

images/11R27V5.png

Figure 11.27 - Partie du métamodèle UML relative aux stéréotypes

La métaclasse Stereotype est introduite comme une sous-classe de la métaclasse Class. Les stéréotypes introduits dans des diagrammes de classes sont des instances de cette métaclasse et sont donc des classes. Par conséquent, tout stéréotype peut contenir des attributs (les tags).

L’association (extension) qui connecte un stéréotype à l’élément qu’il étend est une instance de la métaclasse Extension. Cette dernière est une sous-classe de la métaclasse Association. La métaclasse introduit des restrictions sur ce type d’association :

  • D’une part l’une des extrêmités appartenant à cette association est typée par la métaclasse ExtensionEnd dont le type est unique et obligatoirement un stéréotype.

  • Une extension est une association binaire, ce qui est décrit dans la métaclasse Extension par la contrainte OCL suivante :  inv: memberEnd->size() = 2

Par conséquent, une extension connecte un stéréotype à l’élément qu’il étend par son autre extrémité. Celle-ci n’est pas spécialisée mais elle doit lier l’extension à une métaclasse, ce qui est traduit par la contrainte suivante :

inv: metaclassEnd()->notEmpty() and metaclassEnd().type.oclIsKindOf(Class) 

metaclassEnd() est une requête OCL qui renvoie l’extrémité qui n’est pas typée par le stéréotype.

La description...

Introduction au MOF

Le MOF a pour objet d’apporter une architecture standardisée pour décrire les éléments d’un métamodèle comme celui que nous venons d’étudier. Cette architecture doit être indépendante de la plateforme logicielle. Une telle architecture donne lieu à un métamétamodèle, fruit de la modélisation d’un métamodèle.

Le premier métamétamodèle que nous avons étudié jusqu’à présent est le métamodèle d’UML. En effet, ce métamodèle a la propriété de se décrire lui-même comme nous avons pu en voir un aperçu à la figure 11.26. Il constitue donc une première possibilité de métamétamodèle du MOF. Dans la littérature du MOF, il est simplement appelé un métamodèle du MOF. Dans cette même littérature, la description du métamodèle UML par lui-même, comme elle est illustrée à la figure 11.26, s’applique dans le cadre de la perspective du MOF. En dehors de cette perspective, le métamodèle d’UML n’est employé que pour décrire des modèles UML qui n’introduisent aucune métadonnée.

L’utilisation du métamodèle UML au niveau du MOF n’est pas adéquate : ce modèle étant trop important pour décrire des modèles plus simples, y compris lui-même. Par conséquent, le MOF s’est vu doté de deux métamodèles plus simples, sous-ensembles du métamodèle d’UML :

  • Le premier s’appelle EMOF (Essential MOF). Il est obtenu par l’application d’un jeu de contraintes OCL au métamodèle UML....

Conclusion

Dans un premier temps, nous avons étudié les profils. Le but des profils est d’adapter le métamodèle à un langage de programmation comme Java, à une plateforme logicielle comme EJB ou à un domaine spécifique comme celui des équidés. Ces trois exemples que nous avons introduits dans ce chapitre démontrent qu’il est facile et rapide de mettre en œuvre les profils (tout autant que les classes et les paquetages template) même sans avoir une grande connaissance du métamodèle.

Puis, nous avons étudié de façon plus détaillée le métamodèle d’UML qui décrit UML dans toute son intégralité et notamment les profils. Il détient la capacité de se décrire lui-même. S’il peut constituer un métamétamodèle du MOF pour décrire d’autres architectures, l’OMG a préféré introduire des métamodèles plus simples : EMOF et CMOF qui sont des sous-ensembles du métamodèle d’UML.