Validation modéle et code

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

:merci:

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 :roll:
J'ai lu un certains nombres de livres UML que je recommende seulement à mes ennemies :mouarf:

Citation:

---

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 ^^)

Citation:

---

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.

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.

Citation:

---

Envoyé par Vlade

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. :aie:

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.

Citation:

---

Envoyé par Vlade

la structure uml du modèle métier assurance

---

Ca veut dire quoi ca par exemple ?

Citation:

---

Envoyé par Hephaistos007

Honnêtement, je ne comprends rien. :aie:

---

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


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 ?

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 :oops:

Citation:

---

Envoyé par hegros

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.

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 ?

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:

---

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:

---

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:

---

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.

Merci Hephaistos007 :ccool: Plus explicite va devenir plus compliqué à faire :P


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:

---

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.

Citation:

---

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. :koi: C'est que leur xmi est extensible utilisable par exemple avec du B ?

Citation:

---

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.

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 ?:ccool:

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 :roll: 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 ;)

Citation:

---

Envoyé par Vlade

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 ?:ccool:

---

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.

Citation:

---

Envoyé par Vlade

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 ?

Citation:

---

Envoyé par Vlade

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...

Citation:

---

Envoyé par Vlade

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 :roll:

---

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.

Citation:

---

Envoyé par Vlade

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à ?

Citation:

---

Envoyé par Vlade

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 ?

Hephaistos007,

Citation:

---

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.

Citation:

---

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.

Citation:

---

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

Citation:

---

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.

Citation:

---

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 :france:
Le tout sans transformation car natif. C'est 10 fois plus puissant

Citation:

---

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.

Citation:

---

Envoyé par hegros

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.

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. ;)

Citation:

---

Envoyé par Vlade

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.

Citation:

---

Envoyé par Vlade

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 :roll:

"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.

Citation:

---

Envoyé par Vlade

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 :france:
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".

Citation:

---

Envoyé par Vlade

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 ! :x
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 ?

Citation:

---

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. :chin:

Citation:

---

"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.

Citation:

---

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 :fessee:

Citation:

---

"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é :arf:
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 :roll:

Citation:

---

Envoyé par Vlade

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"...

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. :roll:

Citation:

---

Envoyé par hegros

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

---

Tu peux développer ton idée? Parce que là c'est moi qui ne suis plus! Les 9 niveaux de Boulding je les vois bien, les s/systèmes de production et de pilotage aussi, mais j'ai du mal à raccrocher avec tt ce qui précède :?

Citation:

---

Envoyé par TheLeadingEdge

Tu peux développer ton idée? Parce que là c'est moi qui ne suis plus! Les 9 niveaux de Boulding je les vois bien, les s/systèmes de production et de pilotage aussi, mais j'ai du mal à raccrocher avec tt ce qui précède :?

---

Justement c'est ce que je cherche à éclaircir plutôt à explorer.

La transformation de modèle tel qu'on en parle avec UML concerne, mais je peux me tromper, surtout des transformations techniques en fonction de l'application qu'on en fait(documentation, génération de code, reverse ingénierie...) mais avec le méta modèle et le méta méta-modèle ce n'est pas encore très clair en tout cas les 9 niveaux de Boulding (plutot la de la moigne)reste modélisable en UML ou encore mieux en utilisant un méta-modèle ( ce qui revient à écrire un dsl avec atl par exemple?) ou partir depuis le départ avec un méta méta-modèle.

C'est aussi pour ma culture d'informaticien :mrgreen:

Citation:

---

Envoyé par hegros

en tout cas les 9 niveaux de Boulding (plutot la de la moigne)reste modélisable en UML

---

Je n'avais pas compris comme ça. J'avais compris que tu disais que le Meta modèle d'UML et les niveaux (Boulding ou LeMoigne c'est juste la formulation qui est différente) étaient la même chose. Forcément j'avais du mal...
Quoiqu'en y réfléchissant après coup, je me suis dis que ça pourrait peut-être le faire jusqu'au 7. Mais je n'ai pas vraiment creusé et il faudrait peut-être faire preuve d'imagination pour certains niveaux. Mais dans ce cas ça peut s'appliquer à autre chose qu'au métamodèle d'UML.
Je cherche si je retrouve mon ex. de la ''théorie générale des systèmes'' pour mettre un jpg. parce que le lien que tu donnes est plutôt avare d'explications.

En parlant du metamodel et meta metamodel c'est vrai que l'on en oublie l'essentiel qui la mise en oeuvre d'une démarche à l'aide d'UML et des vues. :oops:

Vues des cas d'utilisation, logique, d'implémentation, de déploiement et des processus. Chaque diagramme couvre une ou plusieurs vues. Dans l'approche d'UML Structure du Model il n'y a plus de séparation entre les vues et les mêmes élements peuvent être utlisé dans plusieurs diagrams voir et dans différentes vues.

Par exemple une classe peut être dans un classe diagramme mais aussi dans un usecase diagramme, un compoment diagramme etc...Le découpage traditionnel entre diagramme existe plus vraiment. C'est une volonté de l'OMG et d'IBM de faire évoluer l'UML dans ce sens.
Les diagrammes Structurels que sont: Class, paquetage, objets, composant et composite structure sont dans le même metamodel et peuvent être utlisé avec des diagrammes comportementaux : diagramme de usecase, etat transition, activé ou des diagrammes dynamiques : séquence diagramme, communication.

Je dirai que l'UML devient transversale et non plus en approche top down avec UML 2. Cette transversalitée est encore accentué avec UML 2.2 et la normalisation des métamodel au niveau de l'OMG.
La validation du model valide tous les élements de tous les diagrammes et de toutes les vues en même temps grâce à un mécanisme interne qui est une sorte de moteur xmi de validation dtd. Le moteur de validation utilisé est celui du plugin UML2 qui est aussi celui qui a été validé par l'OMG lors de la spécification UML 2.2.

Citation:

---

Envoyé par vlade

La validation du model valide tous les élements de tous les diagrammes et de toutes les vues en même temps grâce à un mécanisme interne qui est une sorte de moteur xmi de validation dtd.

---

La validation concerne un méta modèle d'après ce que j'ai compris et il y a l'air d'avoir différents niveau de validation et ce n'est pas clair encore.

La validation, pour te reformuler, concerne la vérification d'un fichier XMI soit il est bien formé selon UML ou selon celui qu'on utilise en "maison" et alors on peut dire qu'il est validé.

C'est un niveau de validation, il doit en exister d'autres que je cherche à 'découvrir'. La preuve par le code par exemple en utilisant les modèles n'est pas du tout le type de validation dont tu parles, les exemples de type de validation de modèle si tu en as d'autres avec le code par exemple, bienvenue.

Re,
Je ne remet pas la main sur le schéma des processeurs, je met déjà la représentation canonique du niveau VII de LeMoigne en attendant.http://theleadingedge.developpez.com...mique 7-94.jpg

Je pense que le système des validations pourrait être représenté comme ça. C'est un début et trés simpliste, juste pour voir si on est sur la même longueur d'ondes. A voir par la suite comment y superposer le méta modèle.

Niveau I UML.
N II Boite noire qui transforme un flux d'informations en diagrammes UML
N III Système opérant.
- Ensemble de opérations modifiant les informations permettant de construire les diagrammes.
- Doit aussi refuser certains comportements de façon autonome. (régulation)
N IV Système d'information.
- Ne traiter que du XMI en entrée ...
- ... et ne générer que du XMI conforme, les 2 nécessitent la présence d'une DTD et ca dépend du SI qui informe le SO. Ce n'est pas de la régulation.
N V Système décisionnel. Il existe des règles (Méta-modèle)
- Analyse le flux d'entrée et déclenche certains traitements du SO fonction de état courant des informations permettant
de construire les diagrammes. (décision)
N VI SI. L'état courant des informations permettant de construire les diagrammes devient permanent. (Mémorisation.)
N VII Coordination (là j'ai du mal ... :?)
- Synchronization des diagrammes (?)

Niveaux VIII (IA) et IX (entropie) NA je pense

Merci cette transposition pose assez bien les choses et c'est un bon début je trouve

C'est intéressant que tu parles de xmi au niveau 4 je le verrais plutot au niveau 6 tandis que pour le niveau 7 je te rejoins tout à fait par rapport à la synchronisation des diagrammes mais il y a surement d'autres choses encore pour chacun de ces niveaux à explorer avec le méta méta-modèle ou un méta modèle :roll:

on finira bien par localiser et voir ce qu'est la validation du modèle et quelle partie concerne particuliérement la validation modèles/code c'est peut etre le niveau 9 ?

ce n'est pas sûr mais quand vlade parle de structure de modèle UML il ne veut pas dire par là qu'il informatise et automatise seulement les diagrammes de ce type (les statiques/structuraux comme le diagramme de classe) et qu'il ne traite pas les autres comme les dynamiques ou d'architectures ?

Puisqu'à ma connaissance il y a une topologie des modèles UML :statique,dynamique,architecture,usage,temporel...

Je ne connait pas les travaux de LeMoigne, mais je pense que cela n'est pas directement en rapport en avec l'ingénierie des modèles discutée ici. En fait, il me semble que les travaux de LeMoigne visent l'analyse et la modélisation de SI complexe, et ne s'intéressent pas directement aux langues (ou langages) utilisées pour le faire. Or, précisément, l'ingénierie des modèles se focalise uniquement sur les langages sans se soucier du pourquoi de leur existence et de leur utilité. D'ailleurs, l'ingénierie des modèle reste une approche très générale, qui n'est pas réservée aux informaticiens.

Pour en revenir au sujet, l'ambiguïté vient du mélange des genres, entre l'ingénierie des modèles d'une part, et UML d'autre part. Il y a des groupes de travail qui réfléchissent aux différents points de vues que l'on doit avoir sur un système d'information destinée à être implémenté dans une technologie objet, et qui proposent une spécification UML. D'autre part, il y a l'ingénierie des modèles, indépendante de toute cette agitation, qui stipule que la spécification d'un langage (UML, Merise, Tartanpion, etc.) doit être vu comme un méta-modèle et doit en conséquence être décrit dans un langage appelé le MOF (vu comme un méta-méta-modèle).

oui mais alors la validation qu'en est-il ? est-ce simplement une validation de la forme (du xmi) ? il n'y a pas de niveau différent de validation allant notamment jusqu'à la validation du code ? ou plutôt cela veut dire que MOF valide les modèles ce qui revient à valider du xml ? Ou écrire son langage de validation de modèle ?

j'avoue utiliser l'approche systémique pour appréhender mieux un peu tout ces concepts parce qu'entre le MOF, DSL, RTL et OCL c'est un peu le brouillard.

puis ce n'est toujours pas clair concernant la validation des modèles. Cela se dit déjà validation d'un modèle ou du code en utilisant les modèles ?

Encore désolé car plus je lis vos réponse plus je me rend compte que je répond plus la tête dans le guidon que de manière fonctionnelle :oops:

La validation du modèle est faite sur l'XMI au niveau du métamodel.
La validation du code est faite par le JDT java directement.
Comme le diagramme UML est synchronisé avec le model interne EMF, qui lui est synchronisé avec Ecore, qui lui est synchronisé avec la structure UML qui lui se synchronise avec le code java alors la validation du modèle et du code java marche à tous les coups sinon il y a un warning et l'impossibilité de clicker sur le bouton ok.
Par contre si on désire générer le code après la phase de conception alors c'est différent. Omondo a décidé de faire un travail minimaliste sur ce sujet. On crée juste les squellettes des applications, je veux dire les classifiers et ont laisse les développeurs implémenter les attributs et méthodes d'implémentation dedans à la main. C'est limité mais ca permet de bien séparé le travail de chacun et surtout de garder les même Id UML durant tout le projet.
C'est très important car si itération entre code et modèle en phase botom up (je veux model vers code et après code refactorer par le développeur vers le model) ont garde la tracabilité. La génération de code à partir d'un XMI casse la logique entre le code et le modèle. Il faut donc généré soit en synchronisation permanente, soit si en conception juste les classifiers.
Si toutefois cela n'est pas un problème de cassé cette logique ont a inclus AndroMDA chez nous. Le problèlme d'Andro c'est qu'il est juste xmi 2.0 et donc ne marche pas avec les derniers standards de l'OMG. On a dû donc bidouiller. On a bidouiller "assez gravement" :oops: afin d'utliser Ecore pour avoir un modèle valide pour le framework AndroMDA qui prend la main sur l'xmi en mémoire pour généré le code. Mais Andro même si c'est sympa je pense que garder une Id unique pour couvrir les cycles des itérations est plus important. Mais bon chacun fait comme il veut:calim2:

Il semblerai que certe parti de génération de code intérésse, pensez-vous qu'il est bon de parler plus en détail de cela et de la validation du code ?

Citation:

---

Envoyé par Vlade

La validation du modèle est faite sur l'XMI au niveau du métamodel.

---

mais justement la question est là concernant la validation. D'après vos dires cela concerne une vérification que les modèles sont bien formés conformément au métamodel UML dans notre cas c'est donc une vérification syntaxique.

mais c'est tout ce que couvre comme validation omondo ?

Citation:

---

La validation du code est faite par le JDT java directement.

---

Nommer pas de langage de programmation cela n'aide pas à moins que on part du principe qu'on peut considérer uml comme tel.

Citation:

---

Comme le diagramme UML est synchronisé avec le model interne EMF, qui lui est synchronisé avec Ecore, qui lui est synchronisé avec la structure UML qui lui se synchronise avec le code java alors la validation du modèle et du code java marche à tous les coups sinon il y a un warning et l'impossibilité de
clicker sur le bouton ok.

---

EMF c'est bien un méta métamodel comme MOF mais à un niveau plus technique et Ecore serait le module de sychronisation entre modèles UML pour avoir une structure(omondo?)UML qui génére ensuite du java alors la validation du modèle.

si je comprends bien omondo est un outil pour faire du MDA puisqu'on pourrait considérer uml comme un langage de programmation.

ma question concerne plus la transformation de quelque chose écrit dans une guard d'un diagramme états transition en prédicat ou du z par exemple : a ^ b puis vérifier que le code colle avec ça.

mais comme je ne sais pas finalement ce que pourrait valider un outil omondo ou autre mise à part la forme des modèles (que c'est bien du uml par exemple), cela doit se développer pour la synchronisation inter-modèle sinon je suis complétement perdu :calim2:

Citation:

---

mais justement la question est là concernant la validation. D'après vos dires cela concerne une vérification que les modèles sont bien formés conformément au métamodel UML dans notre cas c'est donc une vérification syntaxique.
mais c'est tout ce que couvre comme validation omondo ?

---

Omondo n'a pas de règle validation c'est EMF, puis Ecore, puis UML 2 qui valident directement avec des règles prédéfini par Eclipse et l'OMG. A aucun moment Omondo n'intervient dans la définition des règles de validation.
La vérification est sur la validité de l'XMI sur la dtd de réference en utlisant les règles de la structure UML et rien d'autre à ce niveau
La création du modèle graphique se fait par Omondo qui a crée un "glue" entre EMF+GEF, et ensuite l'étape d 'après c'est EMF qui valide cette création et envoie cette validation au modèle en mémoire. Après cela passe à Ecore qui revalide avant de redonner le tout à la structure UML. Il y a 4 étapes de validation du modèle. L'un est graphique avec le modèle EMF+GEf, ensuite c'est la vérification vis à vis de EMF qui appel à l'EMOF et enfin la validation de la syntax xmi et de sa sauvegarde. Ecore écrit l'xmi et la structure uml la valide toute seul. C'est vrai que parfois Ecore se trompe, mais on a corrigé toutes les erreurs directement en coddant en dure chez Omondo et en désactivant les appels aux méthodes buggés. Nous n'avons donc pas changé EMF mais réecrit les méthodes buggés chez Omondo.C'est là aussi qu'est la valeur car il y a un travail d'audit des couches basses d'EMOF
Mais comme expliqué plus tôt, tout est transparent car synchronisé en temps réel.

Citation:

---

EMF c'est bien un méta métamodel comme MOF mais à un niveau plus technique et Ecore serait le module de sychronisation entre modèles UML pour avoir une structure(omondo?)UML qui génére ensuite du java alors la validation du modèle.

---

Ecore est égal un MOF et pas EMF. EMF est l'étape d'en dessous qui permet à Omondo de vérifier son modèle graphique.

Désolé c'est vrai que je me rend compte que ce qui me semble évident n'est pas du tout évident en realité :oops:

A hegros,

EMF n'est pas un méta-modèle, c'est juste un composant d'Eclipse dédié à la méta-modélisation, comme il existe des composants dédié au J2EE, au Mobile, etc.

Effectivement, la validation d'un modèle par rapport à son méta-modèle est assez simpliste. Tout simplement parce que certaine règles ne peuvent pas être exprimées de cette façon. C'est l'intérêt du langage OCL par exemple, qui va permettre de spécifier des contraintes dans un méta-modèle, et qui seront vérifiés dans les modèles. Une telle validation ne peut pas être basée uniquement sur le XMI. Un sous-composant de EMF est d'ailleurs dédié à cela : http://www.eclipse.org/modeling/emf/...ion#validation

En reprenant l'exemple du méta-modèle UML concernant le diagramme d'état-transition, un exemple de contrainte OCL serait de stipuler que deux états ne peuvent pas avoir le même nom :

Code:

---

1 2 3

context uml2::stateMachine self.states->forall(s1, s2 | s1.name=s2.name implies s1=s2)

---

merci pour ces précisions, il y a des éléments qui sont difficilement à savoir si l'ingénierie des modèles prends en compte ou pas, certains aspects comme la preuve par le code, pour rester dans un niveau de validation, par rapport à des modèles écrit avec un langage formel.


puis il y a la difficulté du contexte est-ce que le code source est existant sans modèle au préalable dans ce cas on fait une simple rétro-ingénierie et on remodele un peu puis on regénére un code source à jour ou alors il n'y a aucun code existant on peut utiliser une simple génération de squelette ou plus ou alors il y a du code existant avec un modèle préalable fait postérieurement etc...


puis la difficulté de validité la cohérence entre les modèles d'une part par exemple un diagramme de classe statique et un diagramme de séquence dynamique lié à un diagramme de cas d'usage et un diagramme d'architecture de déploiement et d'autres parts la validité de ce qui est généré au final (enfin ce qui est possible dans ce thread le code)



enfin, dernière question est-ce qu'il existe un méta modèle de validation de référence pour les éditeurs de IDE afin de voir la modélisation graphique( si c'est avec du UML c'est tant mieux ) de ce qui est entendu dans la communauté par validation des modèles lorsqu'on inclus le code comme modèle

Citation:

---

EMF n'est pas un méta-modèle, c'est juste un composant d'Eclipse dédié à la méta-modélisation, comme il existe des composants dédié au J2EE, au Mobile, etc.

---

Oui, EMF n'est pas un metamodel mais juste un model interne utilisé par Omondo afin de permettre la passerelle avec Ecore. C'est notre modèle graphique qui prépare à l'étape suivante.

Citation:

---

Effectivement, la validation d'un modèle par rapport à son méta-modèle est assez simpliste. Tout simplement parce que certaine règles ne peuvent pas être exprimées de cette façon. C'est l'intérêt du langage OCL par exemple, qui va permettre de spécifier des contraintes dans un méta-modèle, et qui seront vérifiés dans les modèles. Une telle validation ne peut pas être basée uniquement sur le XMI. Un sous-composant de EMF est d'ailleurs dédié à cela : http://www.eclipse.org/modeling/emf/...ion#validation

---

On rentre dans la transformation de modèle multiples. C'est une alternative au modèle unique promu par Omondo. Pour moi cette approche n'a d'intéret que si on cible autre chose que UML.
Mais si on cible java alors c'est une usine à gaz car la synchronization en temps réel rend ce projet inutile. D'ailleurs je me demande si ce projet sera encore maintenu. Il faut savoir que beaucoup de projet Eclipse sont juste dévellopé par une ou 2 personnes. C'est des sujets de recherche et bien souvent ils disparaissent avant d'arriver à maturité; Ce projet à mon avis va disparaitre mais bon on verra bien :roll:

Citation:

---

En reprenant l'exemple du méta-modèle UML concernant le diagramme d'état-transition, un exemple de contrainte OCL serait de stipuler que deux états ne peuvent pas avoir le même nom :

---

Omondo a décidé d'abandonner l'OCL car UML 2.2 n'a pas de régle bien défini. Un élement UML est unique mais il peut être utlisé dans autant de vue qu'on vue. OCL est difficilement implémentable. OCL va disparaitre avec UML 2.2 c'est une quesi certitude, il faut donc passer à autre chose. Je dis pas que OCL est pas une bonne idée, juste que l'OMG ne l'a pas pris en compte lors de l'implémentation d'UML 2.
De plus en UML 2.2 ont peut rajouter des contrainstes directement à la racine de chaque élément. C'est pas l'OCL mais bon ca fait le boulot en partie. En résumé l'OCL et UML 2.2 c'est un vrai bordel aujourd'hui :(

Citation:

---

il y a la difficulté du contexte est-ce que le code source est existant sans modèle au préalable dans ce cas on fait une simple rétro-ingénierie et on remodele un peu puis on regénére un code source à jour ou alors il n'y a aucun code existant on peut utiliser une simple génération de squelette ou plus ou alors il y a du code existant avec un modèle préalable fait postérieurement etc...

---

Si le code source existe alors il faut le reverser pour créer un modèle. J'ai répondu à un poste sur ce sujet dans ce forum sur: http://www.developpez.net/forums/d55...g-accessibles/

Citation:

---

dernière question est-ce qu'il existe un méta modèle de validation de référence pour les éditeurs de IDE afin de voir la modélisation graphique( si c'est avec du UML c'est tant mieux ) de ce qui est entendu dans la communauté par validation des modèles lorsqu'on inclus le code comme modèle

---

Il y a un modèle de validation XMI de la structure UML que propose le plugin UML 2 d'Eclipse. a part cela pas d'autre validateur que je connaisse et qui respectent les dernière normes UML 2.2

Citation:

---

Envoyé par hegros

merci pour ces précisions, il y a des éléments qui sont difficilement à savoir si l'ingénierie des modèles prends en compte ou pas, certains aspects comme la preuve par le code, pour rester dans un niveau de validation, par rapport à des modèles écrit avec un langage formel.

---

Il y la notion de validité vis-à-vis d'un langage/formalisme (cela rentre dans le cadre de l'ingénierie des modèles) et d'autre notions de "validité" comme par exemple la preuve dans les langage formels. Mais cette dernière notion n'est pas lié aux éléments du langages, mais à des analyses que l'on fait en s'appuyant sur le langage, nuance. Par conséquent, cette notion là de validité qui existe pour certains langages (ex: le B) et peut être inexistant dans d'autre (ex: le CSS), n'est pas une préoccupation de l'ingénierie des modèles.

Reprenons le fil rouge de ce topic. Le langage UML (cad le méta-modèle UML) indique qu'un diagramme d'état-transitions contient des états et des transitions entre ces états, et n'autorise pas deux états à porter le même nom (Cf. contrainte OCL). Lorsque tu vas créer un diagramme d'état transition pour modéliser les feux tricolores, tu vas considérer un tel diagramme uniquement "valide" si il n'y a pas de transition réflexive par exemple. On comprends bien que cette notion de validité dépends du contexte d'utilisation d'un diagramme d'état-transition, et ne concerne pas la définition du langage UML en soi. Ton diagramme EST valide (au sens langage) car il respecte bien la langue UML, mais n'est pas valide par rapport à une analyse qui vise à détecter des transitions réflexives.

Comme je l'ai déjà dit, tu peux prendre le problème de deux façons. Soit tu modifie le méta-modèle UML en ajoutant une contrainte OCL pour interdire les transitions réflexives. Dans ce cas, tu viens de définir ton propre langage, appelons-le UML-FT (Uml pour les Feux Tricolore). Soit tu ne touche pas à UML, et tu développe un programme spécifique qui prend en entrée un diagramme d'état-transition, et qui indique en sortie si oui ou non, ce dernier est valide pour les feux tricolore, cad si il ne contient aucune transition réflexive.

Citation:

---

Envoyé par hegros

puis il y a la difficulté du contexte est-ce que le code source est existant sans modèle au préalable dans ce cas on fait une simple rétro-ingénierie et on remodele un peu puis on regénére un code source à jour ou alors il n'y a aucun code existant on peut utiliser une simple génération de squelette ou plus ou alors il y a du code existant avec un modèle préalable fait postérieurement etc...

---

Pas compris la question.

Citation:

---

Envoyé par hegros

puis la difficulté de validité la cohérence entre les modèles d'une part par exemple un diagramme de classe statique et un diagramme de séquence dynamique lié à un diagramme de cas d'usage et un diagramme d'architecture de déploiement et d'autres parts la validité de ce qui est généré au final (enfin ce qui est possible dans ce thread le code)

---

Alors ça c'est un tout autre problème, qui n'appartient pas non plus à la méta-modélisation en soi. D'ailleurs, si tu considères le méta-modèle du langage CSS ou HTML par exemple, cette notion de cohérence n'existe pas. C'est une caractéristque propre à UML qui définit 13 diagrammes, comme autant de vues différentes sur un même système. En fait, le problème de la cohérence se pose dès qu'un langage offre des vues. Du coup, ce n'est pas un problème de la phase de méta-modélisation, mais un problème qui devra être réglé par l'environnement qui permettra de modéliser.

Citation:

---

Envoyé par hegros

enfin, dernière question est-ce qu'il existe un méta modèle de validation de référence pour les éditeurs de IDE afin de voir la modélisation graphique( si c'est avec du UML c'est tant mieux ) de ce qui est entendu dans la communauté par validation des modèles lorsqu'on inclus le code comme modèle

---

Pas compris la question

J'ai compris que UML définit 13 diagrammes ressemblant à ce que tu as posté plus haut avec le diagramme d'état transition et aussi que OCL permet d'une certaine manière la spécification et validation de modèle et n'est pas lié au XMI. Et que l'ingénierie des modèles se concentre sur les langages notamment sur les méta méta-modèle comme MOF

Citation:

---

Envoyé par Hephaistos007

Il y la notion de validité vis-à-vis d'un langage/formalisme (cela rentre dans le cadre de l'ingénierie des modèles) et d'autre notions de "validité" comme par exemple la preuve dans les langage formels. Mais cette dernière notion n'est pas lié aux éléments du langages, mais à des analyses que l'on fait en s'appuyant sur le langage, nuance. Par conséquent, cette notion là de validité qui existe pour certains langages (ex: le B) et peut être inexistant dans d'autre (ex: le CSS), n'est pas une préoccupation de l'ingénierie des modèles.

---

Est-ce que vous avez des sites à conseiller pour les notions de validité de langage/formalisme qui entre dans le cadre de l'ingénierie des modèles autant si vous connaissez un site qui montre une mise en oeuvre de validité avec le langage B/UML qui nous soit accessible.

Et encore merci pour tout le temps que vous voulez bien passer à donner des réponses sur le sujet.

Quel débat !

Merci pour cette belle discution (oui, je sais, mon post n'est pas très utile... mais je tenais à dire que j'avais aprécié la discution, voila :) ) !