Lorsque l’on parle de modélisation, la première idée qui nous vient est, » ok faisons des modèles, utilisons UML! » Ok oui c’est pas forcement un mauvais réflexe, après tout, on cherche a mettre en évidence des particularité d’un système existant ou que l’on cherche a construire et quoi de mieux qu’un modèle pour le faire.
Pourtant, UML est il forcement un bon choix? Bien sur celui ci couvre de nombreux besoins comme la représentations d’aspects dynamiques ou statiques. Pourtant dans d’autres domaines que l’informatique, d’autres formalismes peuvent être utilisés entre autre le plus courant est l’équation mathématique!
Ceci est nous montre donc que si UML offre souvent la bonne opportunité pour modéliser un système logiciel, celui ci trouvera rapidement lorsqu’il s’agira de modéliser des particularité d’un domaine métier ou même si l’on doit être dans des aspects plus fin que ce que permet UML.
Par exemple UML permet la modélisation d’automate a état finis sous la forme de state machine mais nous permet il de construire des automates de Buchi [1] ou de Kripke [2] et de permettre d’opérer des opérations de Model Checking? Clairement pas.
Ainsi, si UML permet de représenter dans les grande lignes un système logiciel selon des points de vues considérés comme essentiels, les spécificités du contexte métier peuvent nous pousser a avoir besoin d’autres formalises que celui d’UML (ou celui très abrute des mathématiques) mais ces formalismes
- existent t ils?
- sont ils outillés?
A la première réponse, on pourra souvent répondre oui car généralement les domaines métier sont des domaines connus et quand cela n’est pas le cas alors il importera de le modéliser… mais mais? quoi?
Oui un domaine est un système comme un autre qui peut être modéliser au même titre que tout autre système…. et c’est la qu’intervient la méta-modélisation: nous ne cherchons plus a modéliser un système physique (ou concret) directement mais plutôt le domaine et les lois dans lequel n’importe lequel des systèmes physiques du même ordre évoluent.
Le but de cette approche est alors de nous doter du formalisme tant souhaité qui en plus nous fournira une base pour l’élaboration d’un outil nous facilitant la construction des modèles eux même répondant par ce fait a la seconde question.
Mais alors la question qui arrive est si l’on modélise un domaine qui lui même permet de faire des modèles. Alors ce modèle de domaine, c’est quoi ? un méta-modèle? Et bien oui c’est cela… et vient donc directement la question: mais avec quoi je vais modéliser mon domaine? Pour faire des modèles de système, j’utilisais UML mais la avec quoi on modélise un domaine? UML aussi?
Et bien pourquoi pas? En fait, peu importe en réalité, l’important est de disposer d’un langage nous permet de faire état des spécificités du domaine! UML peut très bien faire l’affaire ou un autre mais sachez que dans l’idéal alors on utilise un meta-meta-langage de modélisation ou un langage capable de modéliser des domaines de modélisation!
Pour cela, on peut effectivement utiliser UML mais sachez que le langage le plus adapté est le MOF (Meta-Object Facility) duquel UML en es un modèle et dont il est lui même un modèle. (Et oui a ce niveau de modélisation, et pour que l’on ait pas une infinité de langages méta en décrivant d’autres, ce langage doit être capable de auto-décrire). Il s’agit d’un langage de niveau M3.
Un langage M3? Par M3 je parle d’un niveau d’abstraction. En effet, nous avions parlé du pattern step dans l’article sur l’IDM [3]. Pour rappel ce pattern permet de décrire les liens d’abstraction entre système, modèle, langage de modélisation et méta-modèle. Ce que nous n’avions pas précisé c’est que ce pattern peut être cascadé dans le sens ou un méta-modèle peut être vu comme un « simple » modèle et donc appartenir a un ensemble de méta-modèles formant ainsi un langage de méta-modélisation qui lui même peut être alors modélisé par un méta-méta-modèle.
Ainsi, si l’on associé M0 comme étant le niveau d’abstraction le plus bas, c’est a dire celui du système logiciel concret, on pourra alors donner au modèle, le niveau M1, au méta-modèle, le niveau M2 et au méta-méta-modèle le niveau M3, avec tous les langages constituant ces différents niveau donnant la capacité de construire les modèles de rang inférieur.
Et nous voici donc avec ce que l’on appelè la pyramide de méta-modélisation décrite part Bézivin en 2003.
Models&Code 
Un commentaire sur “Pyramide de méta-modèlisation”