Accueil > UML / Enterprise Architect > Introduction à la notion de MDG

Introduction à la notion de MDG

Vous avez appris d’expérience ou par le biais d’une formation qu’il n’existait pas une seule modélisation possible pour représenter un concept du monde réel. En effet, là où certains privilégient un héritage d’autres choisiront plutôt un stéréotype, d’autres encore préfèreront une instanciation, un attribut, etc. Et personne n’a tort ou raison. Que vous débutiez ou que vous maîtrisiez UML et Enterprise Architect (EA) vous aimeriez donc pouvoir limiter les choix de modélisation possibles pour permettre de faciliter les échanges, la lecture, la compréhension du système et donc l’étude même de ce système.

Vous aimeriez disposer de diagrammes dédiés à votre domaine avec des boîtes à outils personnalisées et des icônes explicites pour représenter les éléments… Eh bien c’est possible ! Le MDG est là pour vous !

« MDG » signifie « Model Driven Generation », dans EA on parle de MDG Technologies. Un MDG permet d’étendre UML pour l’adapter à un contexte donné. Qu’est-ce que cela signifie « étendre UML » ? Cela signifie personnaliser les types de diagramme, personnaliser les boîtes à outils et personnaliser les icônes représentant les éléments. Exactement ce que vous souhaitiez ! Cela permet de limiter l’accès aux éléments nécessaires et suffisants à un objectif de modélisation (objectif défini par le type de diagramme). Tout comme les diagrammes de Cas d’utilisation ont pour objectif de limiter la modélisation aux grandes fonctionnalités métier du système, vous pourriez par exemple avoir des « diagrammes d’application » dont l’objectif serait de modéliser les « applications »… Ou des « diagrammes d’architecture fonctionnelle » où on modéliserait les « domaines fonctionnels » et leurs responsabilités en termes de « services fonctionnels ». Tout est imaginable.

Dans les supports fournis par EA, on trouve par exemple un MDG pour la modélisation d’un écosystème :

La notion UML de « Classe » a été étendue pour définir un « Animal », l’image de la classe a été remplacée mais le stéréotype reste visible.

La notion UML de « Package » a été étendue pour définir un « Habitat » (ici la forêt), l’image du package a totalement été remplacée par un ‘nuage’ vert.

La relation UML de dépendance a été étendue pour définir 2 relations : « consomme » et « vit », il n’y a pas de personnalisation de l’aspect UML de cette relation (on reste en pointillés longs avec une flèche simple).

La boîte à outils a également été personnalisée :

Un modélisateur est donc conduit à n’utiliser que les éléments du MDG à sa disposition.

Autre exemple (plus technique – trouvé également dans les supports EA) :

Dans ce cas, une seule notion UML a été étendue : la notion de « Classe » pour donner lieu à chacun des types présentés ci-dessus.

Un MDG bien pensé est un atout pour une modélisation contextualisée. Il nécessite évidemment une étude en amont pour définir quels nouveaux « concepts » mettre à disposition des modélisateurs. Pour chacun de ces concepts quel élément UML étendre : Doit-on se baser sur une classe, un package, un attribut ? Choisir la bonne image, l’utilisation de fichiers métafile par exemple peut entraîner quelques déceptions lors de l’utilisation et il est parfois préférable de rester très basique. Quels sont les relations UML à étendre ? Car de la même manière un lien d’héritage ou un lien d’association ne fournira pas les mêmes caractéristiques. Bref, il faut se poser les bonnes questions…

Certains d’entre vous voient peut-être déjà vers où je vous emmène… Car oui, lorsque l’on pousse la réflexion et afin de formaliser les choix pris on arrive tout logiquement à la notion de Méta-Modèle. Un méta-modèle est un modèle de modèle. Et dans notre cas, notre méta-modèle sera la modélisation (en UML) de l’extension que l’on va faire d’UML pour modéliser notre système. Et nous passons là à un autre niveau d’abstraction mais ceci est un autre sujet…

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


+ 2 = six