Discussion :

[zann12]

Bonjour,

J'ai quelques difficultés à appréhender certains aspects d'EMF et d'ecore.
Voici ce que moi j'en ai compris :

Par rapport aux 4 niveaux de l'architecture MOF on se trouve avec :
M3 : méta-méta-modèle (MOF)
M2 : méta-modèle (Ecore)
M1 : modèle (nos modèle.ecore basé sur ecore)
M0 : l'utilisation dans un cas réel de notre modèle.ecore

Est-ce correct ?

Merci.

Michaël

[Vlade]

M0: UML diagrams ou diagramme EMF (graphisme fourni par les plugins GEF ou GMF)
M1: UML Superstrucutre (EclipseUML2 metamodel) ou modèle EMF
M2: Transformation de modèle (sérialisation EMF)
M3 : MOF ou Ecore que l'on appel aussi EMOF

Pour moi rester au niveau du diagramme EMF sans migrer vers UML n'a pas de sens.

[Hephaistos007]

Je n'ai jamais été d'accord avec toi Vlade sur la hiérarchie que tu cites. D'ailleurs, as-tu une référence solide à me citer concernant cette hiérarchie ?

La méta-modélisation s'appuie sur une architecture à 4 niveaux suggérée par l'OMG. De ce fait, tout bon framework pour l'ingénierie des modèles adhère à cette architecture. En l'occurence, EMF, fournit ceci (et je répond au passage à zann12) :
M3 -- Méta-Méta-modèle (ECORE)
M2 -- Méta-modèle
M1 -- Modèle
M0 -- Monde réel modélisé

Ce dont tu parles Vlade n'a aucun rapport direct. Que vient faire GMF, EMF, UML ou encore la transformation de modèles là-dedans ? J'ai l'impression que tu me parles d'une hypothétique hiérarchie, de surcroit totalement spécifique à la construction de ton outil EclipseUML.

[Vlade]

Oh c'est quoi cette répponse de Hephaistos007 !!
J'ai un lien vers Wiipedia : http://en.wikipedia.org/wiki/File:M0-m3.png
Toutefois si on regarde bien il ne place le metamodel UML 2 que en M2 et non pas en M1. Le problème vient du fait que les outils traditionels tel Papyrus, RSA etc... utilise un modèle graphique et un modèle en interne pour stocker les informations du diagramme visuel UML. C'est pour cela que je parle de GMF
De plus dans le slide wikipédia il oubli tout simplement la transformation concidérant que MOF est UML. Mais non MOF n'est pas UML ou une instance, il faut sérialiser MOF ou Ecore avant et c'est une étape de transformation indispensable. Par exemple c'est à partir de MOF ou d'Ecore qu'on fait du DSL, qui n'a rien à avoir avec UML. Tout dépend de la transformation du language initiale MOF/Ecore qui s'opère par une sérialisarion de l'xmi afin de créer un metamodel orienté DSL ou UML ou autres.

M0 comme monde réel. Dans ce cas cela se réprésente bien par un diagramme visuel. Je pense qu'on est d'accord !!
M1 Modèle mais modèle de quoi ? Car les outils comme RSA ont un modèle graphique et modèle en interne qu'il transforme en metamodel UML sauvegardé en format xmi.
Pour Omondo le stage 2 est déjà le metamodel et non pas le model interne graphique définissant la réalité de la modélisation visuelle. C'est là que l'idée est génial car la vue de la réalité défini par des graphique UML est une vue du metamodel directement et non pas juste une instance de celui-ci.
Pour la technologie EMF il s'agit du modèle graphique mappé avec un modèle interne EMF. On est loin encore du metamodel.
M2 est pour moi la sérialization car Ecore n'est pas un modèle UML. Il faut donc bien transformer Ecore en UML. Sinon c'est impossible. Pour RSA comme ils ont une étapes de plus c'est le méta model cette étape pour eux. Disons leur modèle en interne. C'est des fichier emx chez eux et pour EMF c'est la transformation.
M3 c'est Ecore là on est quasi d'accord car on parle plus de meta model mais de MOF qui est le language au dessu de tous les languages de modélisation.

C'est une chose connu par les spécialistes qui concoivent les outils mais je comprend que les utilsateurs ne voient pas ce qu'il y dérrière ce qu'il manipule. A vrai dire à part Ed Merks du projet EMF et les gens ayant suivi une formation comme celle chez Omondo de plus de 2 ans sur les technologies EMF, il est impossible de voir cette subtilité technologique.
En parlant de GMF, EMF et UML j'explique les couches utilisées par étapes dans la technologie EMF telle qu'elle l'est appliqué par Omondo.

Sinon pour information malgrés tous les livres et slides de l'OMG je peux dire que Omondo est le premier outil UML au monde à avoir vraiment atteint directement MOF en utilisant la technologie Ecore. Les autres outils se limites aux modèles interne et offre juste un export du meta model. Quand à EMF il ne peut se transformer en UML qu'après sérialisation. D'ou le fait que EMF n'est pas de l'UML et n'utilise que la partie serialisation pour transformer Ecore en metamodel. EMF de plus à une approche taggage du code car il écrit des tag dans java lors de la génération.
Là vient la confusion dans l'esprit das gens car il voient le graphisme et la partie fonctionnelle sans voir ce qui se passe réellement en dessou !!
Notre approche par couche est d'ailleur pleinement soutenu par l'OMG et au niveau de la chair UML et par son président qui est aussi un ami de longue date originaire des balkans comme moi

Je préfère montré ce qu'il y a dérrière car c'est là qu'est la valeur aujourd'hui. Faire juste des diagrammes visuelles limites fortement la modélisation car toute la logique du métamodel et de la récréation des vues est impossible. Sans parler de l'ajout des contraintes et règles métiers directement dans UML sans passer par bpmn. Et oui l'UML permet tout et en plus il se mappe avec java.
Pour ceux qui ont pas comprit je peux détaillé car j'ai peur que l'on nage dans la choucroute avec mes explications

[Vlade]

Je suis entrain de discuter avec les autres membres et on se demande s'il faut préciser qu'il y a une sérialization entre Ecore et le meta model UML. Il faudrait peut-être juste ne pas parler de cette étape car après tout le metamodel UML est bien une instance de MOF/Ecore.

Mon explication dans ce cas serait:

M0: le diagramme visuel UML pour tous les outils et EMF
M1: le modèle interne pour EMF et RSA géré par GMF. Omondo n'a pas cette étape car le model est le métamodel directement
M2: Le meta model UML
M3: Ecore

Donc pour Omondo on a 3 étapes MO; M2 et M3 et les autres outils et Ecore ont 4 étapes car ajout de GMF pour avoir un modèle graphique lié au modèle interne EMF qui pourra si le mappage GMF:EMF est valide faire une serialisation xmi pour obtenir meta model UML.

[Hephaistos007]

Je t'explique que l'architecture à quatre niveaux fonctionne de manière générique, et toi tu en reviens toujours à UML 2.0. Ce n'est qu'un langage de modélisation parmi des centaines. La preuve, c'est que chacun peut être amené à créer son propre langage de modélisation (les DSLs dont tu parles), conformément à l'architecture prévue par l'OMG. Arrêtes de raisonner de manière spécifique alors qu'il faut raisonner de manière générale.

Quant à l'exemple donné sur Wikipedia, il est tout à fait exact et correspond parfaitement à la hiérarchie dont je parle, pas la tienne. Où vois-tu de la transformation de modèle, EMF et autre GMF dans cet exemple ? Tu te tires une balle dans le pied.

Le niveau M0 (représenté par une photo de jaquette de film dans l'exemple) représente le fait que cela échappe au monde informatique, car il s'agit du monde réel. Donc il n'y a rien au niveau M0 du point de vue informatique.

Par ailleurs, la notion de modèle, méta-modèle et méta-méta-modèle n'est pas concerné directement par les questions syntaxiques (i.e, choix entre notation textuelle ou graphique), et restent au niveau sémantique uniquement. Par exemple, GMF est la solution fournie par EMF pour associer un syntaxe graphique aux entités sémantiques d'un modèle.

Comme tu l'as souligné, ECORE n'est pas UML. L'ambiguïté vient du fait qu'on lui a associé un-sous ensemble de la notation UML 2.0 : celle du diagramme de classe. C'est le principe de séparation sémantique/syntaxique dont je parlait ci-dessus.
etc...