Discussion :

[hegros]

Suite à un échange avec Hephaistos007 j'ai décidé d'ouvrir ce post.(voir 2-3 dernières réponses)


Merci Hephaistos007, je comprends mieux cela facilite aussi l'écriture de test automatisé comme le test de modéle uml ou/et de code et surement pleins d'autres choses.


Par contre quand tu dis qu'en langage naturel c'est plus difficilement exploitable en fait il s'agit de spécialiser un analyseur syntaxique par exemple pour les gardes dans les diagrammes d'état.

La question est surtout comment à mon niveau de modeleur-concepteur-developpeur je peux intégrer un niveau de transformation de mon langage naturel avant d'envoyer le tout à la moulinette de la norme ou de l'outil logiciel que j'utilise (comme eclipse ou encore bouml) ?


Pour ceux qui connaissent le sujet beaucoup ou peu vous pouvez tentez alors d'exposer pour les autres ou de poser des questions afin d'explorer le sujet

[Vlade]

Il y a un mécanisme dans la Structure UML du model afin de validé le metamodel. Ce mécanisme est simple, il suffit d'ouvrir la structure uml avec l'éditeur Eclipse et de sélectionner le menu Validate Model.

D'abord pour simplifier les débats il faut voir ce qu'on appel historiqument model, metamodel et meta metamodel. On parle aussi de niveau 0, 1, 2, 3.
Aujourd'hui grâce aux nouvelles technologies EMF l'approche traditionnelle est "has been".
Le model sont les diagrammes UML.
Le metamodel est la sauvegarde en XMI corespondant à la norme UML. C'est la structure UML du Model.
Le meta metamodel est le MOF qui est un language au dessu qui a permis de définir l'UML.

La validation du modèle et tests aujourd'hui en UML 2.2 doit se faire au niveau de la Structure UML (c'est à dire le metamodel). Le metamodel doit être unique et regrouper tous les diagrammes UML. Le diagramme UML doit être un viewer du modèle et non pas le modèle lui-même.

En partant de ces règles, il n'y a plus de problème dans la validation du modèle, de test et de synchronization de code. Si par contre des utlisateurs veulent toujours utilisés les anciennes approches UML avec un diagramme qui donne une vue du modèle et qui crée un metamodel par vue alors ce débat devient intéressant car plus d'actualité.
Cette approche des vues métiers découpés sans cohérence entre elle sont des usines à gaz
J'ai lu un certains nombres de livres UML que je recommende seulement à mes ennemies

[hed62]

Le model sont les diagrammes UML.
Le metamodel est la sauvegarde en XMI corespondant à la norme UML. C'est la structure UML du Model.
Le meta metamodel est le MOF qui est un language au dessu qui a permis de définir l'UML.

Je me trompe peut être, mais je ne suis pas tout à fait d'accord :

si le métamodèle n'est que la sauvegarde en XMI de la modélisation, on ne "monte" pas d'un niveau. Par contre, le langage employé (XMI + règle de construction) , ça je veux bien que ce sois le métamodèle.

La sauvegarde en XMI est plutot donc la traduction des diagrammes avec le langage du méta modèle, non ?

Ou alros, je décale tout d'un niveau (ça commence à remonter à quelques années tout ça ^^)

[TheLeadingEdge]

comment à mon niveau de modeleur-concepteur-developpeur je peux intégrer un niveau de transformation de mon langage naturel

Si on évite les maths, ce qui me vient à l'esprit comme langage ''formel'' pour modéliser c'est B. C'est fortement basé sur la logique des prédicats. Il y a même eu un outil ''atelier B'' mais je ne sais pas s'il existe encore.
Si ça t'intéresses, pour avoir plus d'informations (en français) il faudrait rechercher Habrias. C'est un prof d'IUT qui en faisait pas mal la promotion il y qques années.

[Vlade]

Hervé,

Je comprend ta remarque et tu as raison dans l'absolue.
Jusqu'a présent on avait des vues métiers réprésenté par des diagramme UML. De cette vue métier ont sauvegardait un fichier xmi qui était appelé le model. Si un utlisateur avait plusieurs vue, cela faisait plusieurs models et il fallais ensuite une transformation pour rajouter des règles de constructions pour avoir un metamodel. Voilà ce que font tous les outils UML du marché avant que Omondo accepte d'intégrer la vision du metamodel unique que j'ai proposé.

Ce concept consiste a monté plus haut dans l'abstraction, c'est à dire au niveau MOF en utilisant EMF. A chaque création d'élement UML ce lance un appel vers le MOF qui merge l'Id UML avec les Id existante. Donc on fait d'un coup de manière transparente ce qui nécéssitait avant 2 étapes. C'est à dire le diagramme UML est tout de suite un XMI + règle de construction du model consolidé dans un metamodel plutot que de passer par le diagramme, ensuite sauvegarde xmi et ensuite règle de consolidation.

Les avantages sont énormes pour l'utilisateur qui se libère de la gestion des modèles pour ce concentré sur son métier. Cela donne la possibilité de travailler à un niveau au dessu et directement sur le metamodel et non le diagramme comme model. Je préfére parler de Structure UML du Model plutôt que de meta model même si c'est la même chose car cela est une confusion pour l'utilisateur et on ne comprend pas bien l'esprit d'UML 2.2

Comment cela marche: La Structure UML du model est synchronisé avec les diagrammes, qui sont désormais une vue de cette structure et pas juste une vue métier graphique. La Structure UML contient le métier qui lui est crée par les diagrammes UML précédent. Toute nouvelle information est sauvegardé dans la structure uml. Toute information existante est visionable dans les diagrammes UML sans ajouter d'information. On distincte donc 2 type de modeleurs. Le premier qui crée la structure du modèle et le second qui visualise les élements UML déjà existant afin d'en produire des diagrammes UML.
Il est possible par exemple d'avoir une vue "Métier de l'assurance" et de crée une Structure UML de ce modèle métier. Ensuite la Structure UML du model assurance est donné à des équipes qui vont en sortir des vues diagrammes correspondant à leur spécificités métiers. Il s'agit dans cette étape de reconstruire des diagrammes par le drag and drop d'élément UML de l'XMI vers les diagrammes.

Cela fait une grosse économie de temps et donne déjà un socle de départ.
L'autre intérêt de cette approche est permettre un cycle complet entre les équipes de modeleurs de haut niveau, modeleur applicatif, architectes et aussi équipe de developpement. Enfin cerise sur le gateau, dans un cycle agile nécéssiatant des itérations, la structure uml du modèle métrier assurance est remis à jour à chaque itération car le modèle métier est mergé avec la Structure UML afin de partir sur une nouvelle itération. Bien sûre que dans ce cas c'est pas le modèle qui drive la génération de code, mais le modèle qui est un complément au code.

J'espère que mon explication apporte des éclaircissements sinon n'hésiter à me poser des questions je serai ravi de continuer ce débat.

[Hephaistos007]

J'espère que mon explication apporte des éclaircissements sinon n'hésiter à me poser des questions je serai ravi de continuer ce débat.

Honnêtement, je ne comprends rien.

PS : En outre, ce n'était pas le sujet de la question de hegros. Il faut que je trouve le temps de lui répondre d'ailleurs.

la structure uml du modèle métier assurance

Ca veut dire quoi ca par exemple ?

[hegros]

Honnêtement, je ne comprends rien.

Ouf merci à un moment donné qu'est-ce me suis senti bête alors dans tous ces éclaircissements


Merci TheLeadingEdge je comprends mieux de quoi on parle quand on évoque 'langage formel'.


On se retrouve typiquement dans un cas de compilation d'un langage. La norme UML doit fixer son propre langage formel et, à l'instar de B,les modeleurs l'implémente peut-être également en utilisant leur propre langage formel basé sur les prédicats ou autre chose.


Aujourd'hui un XMI pour moi ce n'est qu'un fichier de compilation qui contient les informations nécessaire à la génération du code source (et que ce code compile sans erreur biensûr)

Ou alors est-ce que XMI est le format du fichier du langage formel (posé par la norme uml) utilisé pour la validation de modèle ?

[Vlade]

La validation du modèle se passe au niveau de la Structure UML du model. La structure regroupent tous les diagrammes UML qui ont été crée dans le projet. La sauvegarde de la Structure UML est en xmi 2.2 qui est aussi appelé UML 2.2.

Il y a 2 normes à l'OMG. La normalisation des representations graphiques UML et la normalisation du MOF qui est le language qui donne l'UML. Ce language s'appuie sur un mécanisme interne de sauvegarde en format xmi des informations des diagrammes UML.
IBM parle dans ces tutos de différents niveau de validation aux norme UML 2. Leur explication est un peu marketing mais ce qu'il faut retenir est:
Un outil comme Boum est un niveau 1. C'est à dire que les diagrammes graphiquement sont UML 2.
Un outil comme RSA est un niveau 3. C'est à dire le graphisme niveau 1, la sauvegarde xmi niveau 2 pour chaque diagramme, la structure UML niveau 3.
Je vais pas dire que Omondo est niveau 4 car cela va encore faire une guerre thermo nucléaire, mais bon EclispeUML travail au niveau MOF directement.

J'espère que mes explications aide a comprendre les différentsniveaux entre model, metamodel et meta metamodel

[Vlade]

Aujourd'hui un XMI pour moi ce n'est qu'un fichier de compilation qui contient les informations nécessaire à la génération du code source (et que ce code compile sans erreur biensûr)

Ou alors est-ce que XMI est le format du fichier du langage formel (posé par la norme uml) utilisé pour la validation de modèle ?

L'xmi est bien plus qu'un fichier qui contient les informations nécessaire à la génération de code. L'XMI est la sauvegarde UML 2.2 de la Structure UML. La structure uml est ce qu'on construit chaque fois qu'on crée un nouveau element UML avec un éditeur UML. Il y a des règles précisent de sauvegarde XMI et chaque élément UML 2 à son correspondant en XMI.

Alors l'XMI s'est un truc extraordinaire. On peut tout faire avec et stocker toutes les informations du projet et pas seulement les éléments UML des diagrammes. On peut y stocker les contraintes et règle métiers, la documentation, la tracabilité des diagrammes etc.... Avec l'XMI il y a pas de limite ni de taille, ni de qualité d'information. Je dirai même qu'on bon XMI est plus important que tous les diagrammes UML.
Quand je parle de modèle métier, je veux dire que l'on peut sauvegarder des elements uml dans des packages et reconstruitre ensuite des diagrammes juste avec les drag and drop du model vers un éditeur UML. Cela concerne le diagramme de classe, de usecase, state, component etc....
L'utilisateur n'aura qu'a refactorer les noms existant pour les faire correspondres à ces besoins et crée juste quelques élement manquant . On peut par exemple avoir déjà une architecture projet avec un classe diagramme sauvegardant les modèles dans des packages prédéfini.
Des usecase diagrammes définissant le scope. Des state diagrammes pour les flows etc...A chaque fois juste un drag and drop et le diagramme UML permet de reconstuire une vue UML du modèle.

[Hephaistos007]

Je ne comprends rien aux explications de Vlade, mais je connais bien la méta-modélisation. J'ai vraiment l'impression que Vlade utilise un déluge de termes qui n'ont pas la même signification pour lui que ceux utilisés dans la communauté sur le sujet. C'est plutôt embêtant pour se faire comprendre ...

Qu'il parle de "Structure UML du modèle" au lieu de méta-modèle UML, passe encore (quoique...). Le reste me donne l'impression de vouloir noyer le poisson.

Le XMI (dérivé d'XML donc) n'est que le format standardisé choisi par l'OMG pour sérialiser des modèles. En d'autres termes, créer un modèle en UML et le sauvegarder sur son disque revient à créer un fichier XMI. Ni plus, ni moins. Un document XML (donc à fortiori XMI) étant un arbre, il n'y a pas de quoi s'émerveiller de pouvoir consulter le contenu d'un fichier XMI avec un éditeur arborescent. Il n'y a pas non plus de quoi s'étonner de pouvoir extraire une représentation graphique à partir d'un fichier XMI, et inversement.

Ensuite, un modèle sérialisé en XMI est exploitable informatiquement. C'est là qu'intervient la transformation de modèle à modèle et la génération de code (ou autre : rapports, documentation, etc). Dans la communauté, ces deux usages sont appelés transformation M2M (Model to Model) et M2T (Model to Text). EMF inclue ce qu'il faut pour le M2M (QVT ou ATL), et propose JET (Java Emitter Template) pour le M2T. Certains produits comme Acceleo par exemple, se positionne sur le créneau du M2T. Comment Eclipse UML est-il positionné par rapport à la concurrence ?

[Hephaistos007]

Après tous ces hors-sujet, je vais pouvoir répondre à la question de Hegros, en deux temps.

D'une part, il n'y a pas de contraintes particulières sur les évènements (garde et action) que l'on affecte aux transitions sur un diagramme d'état-transition. Il existe cependant quelques pseudo évènements pré-définis. Si le diagramme est juste destiné à être contemplé, pas de soucis. En revanche, si on souhaite produire d'autres ressources à partir de ce diagramme, les choses se compliquent.

D'autre part, supposons une transformation M2T où ton diagramme d'état-transition modélise les états d'un feu tricolore, et que tu souhaites générer automatiquement le code correspondant qui sera embarqué sur un micro-contrôleur (c'est comme ca qu'on dit ??). Selon le formalisme que tu auras choisi pour exprimer ton évènement, tu auras grosso-modo le choix entre transformer :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<uml:state id="s1" name="rouge"/>
<uml:state id="s2" name="vert"/>
<uml:transition id="t1" source="@s1" target="@s2">
  <uml:guard value="after(10)">
</uml:transition>

ou bien

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<uml:state id="s1" name="rouge"/>
<uml:state id="s2" name="vert"/>
<uml:transition id="t1" source="@s1" target="@s2">
  <uml:guard value="Après dix secondes bien tassées">
</uml:transition>

Dans les deux cas, on aimerait générer, disons un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
-- Pause de 10 sec avant de passer au vert
SLEEP(10000);

Le problème se ramène à un problème d'analyse syntaxique comme tu le disais. Lorsque tu vas récupérer la valeur des noeuds 'guard' de l'arbre XML, il va bien falloir exploiter cette dernière. On comprends bien l'intérêt d'avoir un formalisme plus rigoureux. [1]

En fait, il faut bien voir qu'un modèle est destiné à être exploité par la suite. Son exploitation va guider le choix d'un formalisme, qui je le rappelle, n'appartient pas à la norme UML en soi. TheLeadingEdge suggérais des évènements exprimés en B. Pourquoi pas si par c'est un atelier B qui doit exploiter le diagramme par la suite.

[1] Évidemment, le problème est faussé si tu considère que l'évènement doit être choisi dans un ensemble fini de phrases bien déterminées.

[hegros]

Merci Hephaistos007 Plus explicite va devenir plus compliqué à faire


Oui c'est bien comme cela qu'on dit effectivement le code binaire est embarqué dans une rom, eprom, eeprom, supercard pour nintendo, micro-contrôleur par exemple.


Reprenons ton exemple de code xml pour bien comprendre, est-ce que cela veut dire que la norme UML fixée par OMG publie le DTD pour le XMI pour chaque diagramme et que valider un modéle UML (du point de vue de la norme) revient à valider un DTD ? La validation de modéle concerne aussi la validation d'un modéle mathématique ou prédicatif au dessus du modéle que fixe la norme UML ?


Exemple : c'est OMG qui défini qu'il y a un attribut guard ou qui défini la balise uml:state mais je peux écrire la guard avec une écrite en B ou comme dans cet exemple avec le ^ logique des prédicats ?

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<uml:state id="s1" name="rouge"/>
<uml:state id="s2" name="vert"/>
<uml:transition id="t1" source="@s1" target="@s2">
  <uml:guard value="profondeur(2000) ^ after(10) ">
</uml:transition>

En tout cas cela me montre bien le problème d'analyse syntaxique et que la solution se trouve dans l'utilisation d'un langage formels ou autant écrire directement à la main le XMI pour contourner le problème d'interprétation mais bon on perd ensuite tout l'intérêt de la modélisation graphique.

En fait, il faut bien voir qu'un modèle est destiné à être exploité par la suite. Son exploitation va guider le choix d'un formalisme, qui je le rappelle, n'appartient pas à la norme UML en soi.

C'est cela que je ne suis pas sûr de bien capter. UML est un langage semi-formelle ? Ce n'est pas très clair en application ce que cela veut dire. C'est que leur xmi est extensible utilisable par exemple avec du B ?

TheLeadingEdge suggérais des évènements exprimés en B. Pourquoi pas si par c'est un atelier B qui doit exploiter le diagramme par la suite.

Oui effectivement écrire les événements en B est une bonne idée, j'imagine qu'un langage mathématique devrait aussi convenir si on est plus à l'aise avec si au final c'est de l'xmi qu'on exploite et qu'on cherche à valider.

[Vlade]

Je suis surpris par ce poste je vais donc réexpliquer pour Hephaistos007.

Le XMI (dérivé d'XML donc) n'est que le format standardisé choisi par l'OMG pour sérialiser des modèles. En d'autres termes, créer un modèle en UML et le sauvegarder sur son disque revient à créer un fichier XMI. Ni plus, ni moins. Un document XML (donc à fortiori XMI) étant un arbre, il n'y a pas de quoi s'émerveiller de pouvoir consulter le contenu d'un fichier XMI avec un éditeur arborescent.

Oui l'xmi c'est l'xml sauvegardé dans un format spécifique et défini par l'OMG. Le diagramme UML crée se sauvegarde sur disque. Moi je trouve cela merveilleux car aussi simple que cela puisse paraître personne au monde ne le fait. Peut-être est-ce pas aussi simple ?

Sur mon image il s'agit de prendre un projet java, de l'uméliser ensuite de l'extraire comme modèle UML en le mappant à l'XMI et ensuite de copier coller le projet dans un autre projet. Cela permet de le refactorer sans avoir de synchronization entre le code et le modèle, mais toutefois d'avoir tout le projet en entier.

Ensuite, un modèle sérialisé en XMI est exploitable informatiquement. C'est là qu'intervient la transformation de modèle à modèle et la génération de code (ou autre : rapports, documentation, etc). Dans la communauté, ces deux usages sont appelés transformation M2M (Model to Model) et M2T (Model to Text). EMF inclue ce qu'il faut pour le M2M (QVT ou ATL), et propose JET (Java Emitter Template) pour le M2T. Certains produits comme Acceleo par exemple, se positionne sur le créneau du M2T. Comment Eclipse UML est-il positionné par rapport à la concurrence ?
La transformation modèle à modèle c'est "has been" et ca marche pas. Désolé de te décevoire mais l'exemple qui tue est de prendre l'outil de modélisation Papyrus, Topcased ou Eclipse modeling, de faire un export xmi et ensuite d'importer l'xmi exporté. Alors ca plante La meilleur transformation de modèle est pas de transformation du tout. Si certains veulent s'amuser à transformer des modèles alors ils peuvent le faire, omondo lui est natif

la structure uml du modèle métier assurance

J'ai répondu à la question, désolé. Je ne vais quant même mettre le modèle en copie. C'est le travail de consultant et je suis persuadé qu'ils vont vendre très cher leur modèle à des grand groupes d'assurances. Chacun sont métier, Omondo c'est la mécanique du moteur UML, les consultant c'est leurs expertises métiers. Nous ne pouvons faire leur travail et eux ne peuvent faire le notre

[Hephaistos007]

Oui l'xmi c'est l'xml sauvegardé dans un format spécifique et défini par l'OMG. Le diagramme UML crée se sauvegarde sur disque. Moi je trouve cela merveilleux car aussi simple que cela puisse paraître personne au monde ne le fait. Peut-être est-ce pas aussi simple ?

Il faut bien un format de stockage des modèles. Plutôt que chaque outil définisse son format propriétaire, l'OMG propose un standard en 2003 : le XMI. Tout les outils qui manipulent des modèles (UML ou autres) sont passés à XMI. Mais selon toi personne ne le fait ? il faut que tu m'expliques.

Sur mon image il s'agit de prendre un projet java, de l'uméliser ensuite de l'extraire comme modèle UML en le mappant à l'XMI et ensuite de copier coller le projet dans un autre projet. Cela permet de le refactorer sans avoir de synchronization entre le code et le modèle, mais toutefois d'avoir tout le projet en entier.

ok, si j'ai bien compris, il y a synchronisation (bi-directionnelle : refactor/merge) entre un fichier textuel contenant du Java et un fichier XMI. Pour pouvoir briser cette synchronisation, tu suggères de copier/coller le XMI dans un tout autre répertoire de projet. Pourquoi ne pas le dire aussi simplement que cela ?

La transformation modèle à modèle c'est "has been" et ca marche pas.

C'est une blague ? Le dernier EclipseCon2009 a encore fait la part belle aux applications possibles de la transformation de modèle. Les dernières techniques haut-niveau (comme QVT et ATL) marchent tellement bien qu'elles sont directement passées de l'incubation à leur intégration native dans Eclipse EMF ! On ne peut pas en dire autant de tous les projets eclipse en incubation...

Désolé de te décevoire mais l'exemple qui tue est de prendre l'outil de modélisation Papyrus, Topcased ou Eclipse modeling, de faire un export xmi et ensuite d'importer l'xmi exporté. Alors ca plante

Tu me cites un problème d'import/export d'XMI entre certains outils de modélisations. C'est le problème de ces éditeurs qui ne savent pas respecter une spécification, pas un problème de la technologie de transfo M2M. Lorsque l'on modélise avec l'éditeur UML2 inclue dans EMF par exemple, tout fonctionne à merveille.

La meilleur transformation de modèle est pas de transformation du tout. Si certains veulent s'amuser à transformer des modèles alors ils peuvent le faire, omondo lui est natif

Qu'entends-tu par là ?

J'ai répondu à la question, désolé.

Non, car je ne comprends pas les termes que tu emplois. Tu parles d'un modèle métier décris avec UML, où d'un (méta) modèle métier décris avec EMOF ?

[Vlade]

Hephaistos007,

Il faut bien un format de stockage des modèles. Plutôt que chaque outil définisse son format propriétaire, l'OMG propose un standard en 2003 : le XMI. Tout les outils qui manipulent des modèles (UML ou autres) sont passés à XMI. Mais selon toi personne ne le fait ? il faut que tu m'expliques.

Non très peu d'outil sont passé à l'XMI. Seul existe l'export XMI à partir d'un modèle propriétaire. Et encore cette export est pas propre. Seul RSA et EclipseuML ont des XMI propres, les autres ne savent pas le faire. La norme a changé, c'est un gros investissement financier et les entreprises ne l'ont pas fait.

ok, si j'ai bien compris, il y a synchronisation (bi-directionnelle : refactor/merge) entre un fichier textuel contenant du Java et un fichier XMI. Pour pouvoir briser cette synchronisation, tu suggères de copier/coller le XMI dans un tout autre répertoire de projet. Pourquoi ne pas le dire aussi simplement que cela ?

Non, il faut copier l'xmi dans un autre projet car la structure uml est lié à tout le projet. L'avantage est d'avoir un structure du model uml comme celle du projet java c'est à dire avec des package et nested packages.
Le copier dans un autre répertoire du projet en cours change rien car la synchronisation reste.

C'est une blague ? Le dernier EclipseCon2009 a encore fait la part belle aux applications possibles de la transformation de modèle. Les dernières techniques haut-niveau (comme QVT et ATL) marchent tellement bien qu'elles sont directement passées de l'incubation à leur intégration native dans Eclipse EMF ! On ne peut pas en dire autant de tous les projets eclipse en incubation...

Non, c'est pas une blague. EclipseCon copie Omondo depuis 5 ans maintenant avec toujours un train de retard. On espère un jour se débarasser de ces projets open sources financer par les aides des fonds européens qui ne cherchent qu'a remplacer Omondo. QVT et ATL travail avec des modèles EMF, or EMF c'est pour moi pas de la modélisation mais un framework. La modélisation c'est Ecore et UML. J'ai un un échange violent avec Ed Merks sur ce sujet de savoir "should UML be used in an Agile Project" : http://www.eclipse.org/newsportal/th...lipse.modeling

Lorsque l'on modélise avec l'éditeur UML2 inclue dans EMF par exemple, tout fonctionne à merveille.

Je suis d'accord ca s'est des beaux projets l'editeur UML2 d'Eclipse de même que EMF et ATL.

La meilleur transformation de modèle est pas de transformation du tout. Si certains veulent s'amuser à transformer des modèles alors ils peuvent le faire, omondo lui est natif

EclipseUML a un Ecore en interne et pas juste un UML. Donc nous n'avons pas besoin de faire de transformation car cela est traité à la création tout de suite au moment de l'Id UML. C'est natif avec UML2 et donc pas de besoin de transformation. On peut de plus juste faire des copiers collers de models de RSA. RSA gère juste un seul modèle et ne peux merger 2 models. Omondo peut prendre 10 modèles RSA et toujours avoir un seul modèle
Le tout sans transformation car natif. C'est 10 fois plus puissant

Non, car je ne comprends pas les termes que tu emplois. Tu parles d'un modèle métier décris avec UML, où d'un (méta) modèle métier décris avec EMOF ?

Oui, c'est de l'EMOF qui est synchronisé dans un cycle top down avec UML en incrémentale. L'utlisateur ne voit pas l'EMOF qui est masqué et utilise juste l'UML qui lui est de nouveau synchronisé dans le cycle bottom up. C'est dans les 2 sens. Idem au concept de la synchronisation du code et du modèle.

[Hephaistos007]

Reprenons ton exemple de code xml pour bien comprendre, est-ce que cela veut dire que la norme UML fixée par OMG publie le DTD pour le XMI pour chaque diagramme et que valider un modéle UML (du point de vue de la norme) revient à valider un DTD ? La validation de modéle concerne aussi la validation d'un modéle mathématique ou prédicatif au dessus du modéle que fixe la norme UML ?

En fait, l'OMG a proposé le XMI, qui n'est qu'une forme d'XML respectant certaines conventions. Logiquement, l'OMG a appliqué cette technique à son propre bébé, c-a-d le métamodèle UML, mais est prévu pour n'importe quel autre métamodèle, tant que celui-ci est décris dans le langage MOF. En fait, chaque fois que l'on créé un métamodèle, on peut en dériver un schéma XMI équivalent. Du coup, créer un modèle conforme au métamodèle revient à vérifier la validité d'un document XMI vis-à-vis de son schéma.

Voici en pièce jointe (pas à jour) du métamodèle UML concernant spécifiquement le diagramme d'état-transition. Le nom du métamodèle (ici UML) devient un namespace. Chaque entité devient un élément, ses propriétés deviennent des attributs de l'élément (et non pas des éléments imbriqués), les multiplicité sont prises en comptes, les compositions impliquent l'imbrication des éléments, etc. Au final, on obtiens bien un schéma. Dans l'exemple, une garde possède un attribut expression (et non pas value comme je l'avais mis), typé BooleanExpression (montré dans une autre partie du méta-modèle). Donc, normalement, en respectant strictement ce méta-modèle, on ne pourrait pas mettre de texte libre dans une garde, mais uniquement une expression booléenne. En pratique, beaucoup d'outil de modélisation UML n'implantent pas strictement ce méta-modèle et sont volontairement plus laxistes (par exemple, en mettant Expression : String).

A partir de ce moment là, la garde "j'aime la bière" sur un diagramme d'état-transition est tout à fait acceptable, au sens que le document XMI sera validé par rapport à son schéma. En fait, dans ce cas, le méta-modèle UML ne donne pas de sémantique à la garde, et ce n'est pas son problème de savoir quel formalisme est utilisé (du pseudo-code maison, du B, du Z, de l'algèbre, du Fortran, etc.). Cela pose effectivement la question de savoir si le diagramme est "valide" par rapport à mes attentes, c'est à dire si les gardes sont bien exprimées en B par exemple. Soit on modifie le méta-modèle UML (eg, expression : B-formula...) et auquel cas ce n'est plus le méta-modèle UML de l'OMG mais un méta-modèle UML "maison". Soit on créer son propre méta-modèle, ce qui revient un peu au même. Soit on ne s'occupe pas de cela au moment où le diagramme est créé, mais au niveau de l'exploitation que l'on en fait plus tard : c'est l'exemple de transfo M2T du post précédent.

PS : tout ceci est a peu près logique car UML se veut généraliste et technologiquement neutre, donc on ne peut pas stipuler dans le méta-modèle UML que les gardes doivent être exprimées en B.

[Hephaistos007]

Vlade,

On ne se comprends pas, car moi j'ai une approche conceptuelle des choses, alors que toi tu a une approche technique des choses. Pour te caricaturer, je dirais que tant que tu n'as pas vu un outil sur le marché permettant de cliquer sur le bouton "TOTO", alors la fonctionnalité TOTO n'existe pas. Tu es comme St Thomas, tu ne crois que ce que tu vois.

Non très peu d'outil sont passé à l'XMI. Seul existe l'export XMI à partir d'un modèle propriétaire. Et encore cette export est pas propre. Seul RSA et EclipseuML ont des XMI propres, les autres ne savent pas le faire. La norme a changé, c'est un gros investissement financier et les entreprises ne l'ont pas fait.

ok, je veux bien te croire. C'est un problème de technique donc c'est ton dada. Seulement, je n'ai pas entendu parler de l'ampleur de ce phénomène. Il faudrait voir ce que Bruno (auteur de Bouml) en pense.

Non, c'est pas une blague. EclipseCon copie Omondo depuis 5 ans maintenant avec toujours un train de retard. On espère un jour se débarasser de ces projets open sources financer par les aides des fonds européens qui ne cherchent qu'a remplacer Omondo. QVT et ATL travail avec des modèles EMF, or EMF c'est pour moi pas de la modélisation mais un framework. La modélisation c'est Ecore et UML. J'ai un un échange violent avec Ed Merks sur ce sujet de savoir "should UML be used in an Agile Project" : http://www.eclipse.org/newsportal/th...lipse.modeling

Euh... EclipseCon2009 n'est pas un outil de modélisation open source financé par les aides des fonds européens comme tu dis, ... c'est une conférence que tu devrais connaitre

"La modélisation c'est Ecore et UML.". D'une part, ces derniers sont inclus dans EMF (qui pour toi n'est pas de la modélisation -- d'où contradiction). D'autre part, réduire la modélisation à UML est une erreur. Tu dois être le seul à penser cela. C'est d'ailleurs ce genre de conviction erronée que te reproche Ed Merks.

EclipseUML a un Ecore en interne et pas juste un UML. Donc nous n'avons pas besoin de faire de transformation car cela est traité à la création tout de suite au moment de l'Id UML. C'est natif avec UML2 et donc pas de besoin de transformation. On peut de plus juste faire des copiers collers de models de RSA. RSA gère juste un seul modèle et ne peux merger 2 models. Omondo peut prendre 10 modèles RSA et toujours avoir un seul modèle
Le tout sans transformation car natif. C'est 10 fois plus puissant

ok, je comprends mieux. Omondo dispose donc de trois niveaux de modèles : ECORE (emarqué dans Omondo)-UML(emarqué dans Omondo)-Diagramme(fais par les end-users). Soit, un sous-ensemble de ce que propose déjà EMF. Quel est le rapport entre transformation et UML2 ? Je fini par croire que l'on a pas la même définition du mot "transformation".

Oui, c'est de l'EMOF qui est synchronisé dans un cycle top down avec UML en incrémentale. L'utlisateur ne voit pas l'EMOF qui est masqué et utilise juste l'UML qui lui est de nouveau synchronisé dans le cycle bottom up. C'est dans les 2 sens. Idem au concept de la synchronisation du code et du modèle.

"Oui, c'est de l'EMOF qui est synchronisé dans un cycle top down avec UML en incrémentale." Même un spécialiste du domaine ne peut pas comprendre cette phrase !
L'utilisateur a l'impression de créer un modèle en UML alors qu'en fait il le crée avec EMOF. C'est cela ?

[Vlade]

Euh... EclipseCon2009 n'est pas un outil de modélisation open source financé par les aides des fonds européens comme tu dis, ... c'est une conférence que tu devrais connaitre

Oui, je connais car j'ai d'ailleurs été avec Omondo sur place plusieurs fois et aussi responsable du sponsoring Omondo de l'EclipseCon. D'ailleurs le truc que je me rappel s'est surtout la bouf et les fêtes.

"La modélisation c'est Ecore et UML.". D'une part, ces derniers sont inclus dans EMF (qui pour toi n'est pas de la modélisation -- d'où contradiction). D'autre part, réduire la modélisation à UML est une erreur. Tu dois être le seul à penser cela. C'est d'ailleurs ce genre de conviction erronée que te reproche Ed Merks.

Ce que me repproche Ed Merks je m'en fou car chacun vend sa savonnette. Lui il vend des livres et moi du logiciel. Mais c'est pas parce qu'il a écrit des livres qu'il sait ce que c'est la vrai vie des projets EMF. Et la réalité est bien différente. Nous on a intégré EMF dans la vrai vie et ca a été vraiment dure.

ok, je comprends mieux. Omondo dispose donc de trois niveaux de modèles : ECORE (emarqué dans Omondo)-UML(emarqué dans Omondo)-Diagramme(fais par les end-users). Soit, un sous-ensemble de ce que propose déjà EMF. Quel est le rapport entre transformation et UML2 ? Je fini par croire que l'on a pas la même définition du mot "transformation".

Non, EMF n'a qu'un niveau celui du diagramme de Classe Ecore. C'est GMF qui est l'outil graphique qui a des modèles EMF. Mais c'est une vrai usine à gaz avec plein de modèle de partout et donc un réel besoin de transformation. Chez Omondo pas de trnasformation car tout est natif dés la création et gérer au niveau projet. Comme j'ai déjà dit. La meilleur transformation c'est pas de transformation

"Oui, c'est de l'EMOF qui est synchronisé dans un cycle top down avec UML en incrémentale." Même un spécialiste du domaine ne peut pas comprendre cette phrase !
L'utilisateur a l'impression de créer un modèle en UML alors qu'en fait il le crée avec EMOF. C'est cela ?

D'accord c'est compliqué, disons même très compliqué mais en expliquant on peut réduire la complexité
EclipseUML fonctionne comme un sniffer d'information qui travail en temps réel en lançant pour chaque opération une dizaine de tache de fond. Donc dés qu'on touche le diagramme UML se lance un refresh graphique, qui lui déclenche un update du model UML et du code java si c'est un classe diagramme avec élement java. Ensuite en même temps part un appel vers Ecore qui crée l'élement fait une transformation et redonne l'information épurée à l structure UML du model. Il y a donc bien validation et transformation mais c'est transparent. De plus c'est spécifique à UML, donc vraiment bien tuné. Contrairement à EMF/Ecore qui sont généraliste pour couvrir UML et DSL. Ils réalisent ensemble moins de 30% du job, les autres 70% c'est de l'Omondo. Si on utilise GMF alors cela réduit le travail d'encore 20%. Mais nous on a pris GEf en natif donc le job s'est alourdi de 20%. C'est plus lourd à développer mais c'est plus prêt des couches basses et donc plus puissant et léger sur le poste client. C'est important surtout pour le graphisme qui est un gros consommateur de CPU et RAM.

Donc l'utilisateur manipule bien l'UML graphique mais le tout est synchronisé et validé dans un tache qui est transparente pour lui. Ecore est juste un moteur de validation encapsuler dans le traitement de la tache de synchronization du modèle UML. Toute l'architecture d'EclipseUML est basé sur la structure UML qui contient l'information et à partir de laquelle toutes les autres taches sont déclenchées. D'ailleurs vous pouvez effacer à la main le model d'omondo pour nettoyer le modèle. Ca a l'air bête mais c'est important. Si vous controler le modèle et pouvez comme on dit en jargon développeur "passer sous la culotte" alors l'outil est entièrement customisable.
C'est à ce moment que cela génial surtout si on veut faire des modèles métiers. On a un éditeur graphique qui crée le modèle en directe avec toute la gestion de celui-ci au niveau projet. Ca devient un jeu d'enfant de faire des modèles très très compliqués qui avant nécessitait un travail 10 voir 100 fois plus long. Avec EclipseUML on voit tout de suite ce qu'on fait avec l'XMI. Donc l'XMI en tant que base de sauvegarde et non juste pour générer du code ou faire des échanges de modèles renferme toute la puissance de la modélisation.
On pourrai dire qu'EclipseUML est un outil UML temps réel. Sa complexité est vraiment impressionante, car même les développeurs se perdent dans tous ces threads. C'est si complexe que chacun ne peut faire qu'une partie du traitement et passe ensuite aux autres qui sont spécialisés sur une technologie

[kartben]

Ce que me repproche Ed Merks je m'en fou car chacun vend sa savonnette. Lui il vend des livres et moi du logiciel. Mais c'est pas parce qu'il a écrit des livres qu'il sait ce que c'est la vrai vie des projets EMF. Et la réalité est bien différente. Nous on a intégré EMF dans la vrai vie et ca a été vraiment dure.

Ou peut-être, tout simplement, qu'il a compris la différence entre modèle et méta-modèle, et qu'il arrive ainsi à utiliser EMF "dans la vraie vie" sans devoir passer 10 minutes à s'entortiller les pinceaux à parler de UML graphique qui se synchronise automatiquement via des appels Ecore avec une transformation qui épure le modèle nativement grâce à des threads...
Et, autant que je sache, Ed Merks ne passe pas son temps à inonder Internet de propos visant à dire qu'EMF est "vraiment génial", ou qu'il a "une avance technologique de plusieurs années"...

[hegros]

Merci c'est un peu plus clair avec toutes ces explications.

Si je comprends bien le langage UML est un méta-modèle écrit avec un langage méta méta-modèle appellé MOF et les diagrammes UML comme le diagramme d'états transition est le modèle à mon niveau de modeleur-concepteur. SI je comprends bien à chaque fois que je ne respecte pas le modèle UML alors c'est comme si je venais de définir un profil uml ou de redéfinir un méta modèle hérité de uml mais en le contraignant (car l'étendre parait plus difficile)


j'y trouve une analogie avec l'analyse systémique sauf qu'il n'y a pas 3 niveaux comme ici modèle, méta-modèle et méta méta-modèle il y en a 9 de mémoire de niveau et de transformation dont le premier devrait être la production et le dernier pilotage SI, c'est ce qui m'a intéressé sur le sujet aussi au départ


cependant il s'agit plus de modèle d'application parce qu'il n'apparait pas dans ce schéma puisque cela s'arrête au modèle d'étude


au départ pour ma part le méta méta-modèle c'était le modèle mathèmatique sous-jacent au langage B ou un autre modèle et la validation concernerait aussi ce modèle là par rapport au code ou une conception.

Finalement pas évident de s'y retrouver dans tout cela.