De la modélisation UML à la programmation en Java

Bonjour,

Pourriez-vous, s'il vous plaît me dire comment passer de l'UML en Java ?

Merci

Pouvez-vous donner un plus de détail sur la question ?
S'agit-il de transformer en code Java un modèle UML existant ou d'utiliser UML dans un projet Java ?

Salut,

pour passer d'une modélisation UML en JAVA tu as la possibilité de t'appuyer sur des logiciels (des modeleurs). Cette pratique se nomme MDA pour Model Driven Architecture.

Pour un peu de culture "génie logiciel"
http://fr.wikipedia.org/wiki/Model_driven_architecture

Il y a une liste de logiciel qui le font mais je souligne également certains logiciels plus accessibles aux débutants :

• Eclipse Modeling Framework
• AndroMDA
• bouml

par contre cela demande un bon niveau en UML bien entendu mais n'hésite pas à clarifier ta requête ou à demander des précisions

Kenji,

La transformation d'un modèle UML en code java s'appel le Model Driven Development car il y a transformation.
Le MDA est un concept abstrait dans lequel le language MOF est utilisé avec UML ou autre language tel SysML afin de modéliser un système.

L'UML est avant tout un language de modélisation pouvant être utilisé avec ou sans les concepts MDD et du MDA. UML est donc une norme graphique.
Le passage de UML à Java peut être fait de nombreuses manières. Maintenant parlons du dilème entre MDD et UML qui me fait enrager depuis des années et qui semble toujours ne pas être compris. C'est vrai qu'avec 10 ans de Rational il est dure de faire marche arrière dans le université et cela prendra sans doute du temps !!

niveau 0 c'est le diagramme graphique qui montre le modèle comme un dessin qui est normé et défini par l'OMG. C'est un modèle graphique qui gère les élements.
Niveau 1 c'est le modèle sur lequel s'appuie le diagramme. On parle de metamodel. Pour faire simple le metamodel s'est la sauvegarde en format xmi dans un modèle défini par l'OMG des informations graphiques. Ce format XMI n'a pour l'instant été utlisé dans l'histoire de l'UML que pour des échanges de fichiers entre modeleurs UML. C'est un véritable gachi car l'xml est un language très riche permettant de suavegardé des informations ne pouvant l'être dans des languages voir dans des diagramme UML :ccool: Ceci est l'histoire car on a lancé le concept du natif metamodel dans lequel le metamodel est mergé en synchronisation bidirectionnelle avec MOF afin d'augemnté la puissance et le niveau d'abstraction.
Niveau 2 c'est la transformation entre MOF et UML. C'est là que les choses dérappent en générale et que a part de rares logiciels qui ont une architecture propre basé sur EMOF/ ecore, tous les autres ont fait une grosse usine à gaz propriétaire ou non avec GMF. Il s'agit de transformer un modèle MOF en UML et ensuite à partir de ce modèle de le rentransformer à la fin de la modélisation en metamodel format xmi de nouveau. Je m'explique: MOF --> transformation -->Metamodel --> Diagramme UML --> export xmi --> reconstruction du model en metamodel
Voilà ce que j'appel usine à gaz :mouarf:
Niveau 3 c'est le MOF qui utlise l'architecture suivante Ecore + Transformation <--> Metamodel + diagramme. Ecore est mergé avec la transformation et les diagramme sont une vue du model global appelé metamodel. Comme c'est une syncrhonization permanente dans les 2 sens alors l'xmi est jamais transformé il est juste utilisé.

Revenons donc au concept MDD et MDA qui prend un modèle pour le transformer en code java. Ces programmes UML prennent un xmi et font une moulineete afin de produire du code java de manière programmatique. Ce qui se passe est donc un code java généré qui n'a pas de relation autre que la transformation avec le modèle. Voilà l'approche historique de tous les modeleurs.

C'est exactement ce qu'il ne faut pas faire en faisant du MDD a partir de programme de transformation. Il faut faire du MDD natif c'est à dire que le code et le modèle merge les Id Java et UML ensemble. Donc une fois généré on sait toujours qui est le modèle et qui sont les enfants généré dans le code. C'est le concept de l'Id unique pendant tout le projet permettant à tout moment de tracer aussi bien l'élement java que sont équivalent dans le modèle. Je ne parle pas de synchronization permanente, qui est juste une option du MDD mais de modélisation Ecore utilsant nativement UML afin de ne pas avoir de transformation et donc perte d'information entre les différentes étapes de la modélisation. Tous les gouroux UML ayant utilisé Rational ou autre vont dire que le code et le modèle ne sont pas la même chose juste parce qu'il comprennent pas ou ne veulent pas comprendre le concept qui est génant pour eux.
C'est vrai que d'avoir dit depuis toujours qu'il y a un modèle indépendant du code et que le modèle drive la génération de code et surtout pas l'inverse, ces gens passent pour des crétins de ce rendre compte que le code et modèle peuvent être liés avec l'utilisation de l'ID UML mergé avec Java sans pour autant remmettre en cause la modélisation de haut niveau indépendante du code.
On parle dans ce cas du dileme de la couche de transformation MOF en UML sur le créneau duquel s'est positionné EMF mais qui a échoué lamantablement car il fallait partir d'Ecore et pas d'EMF à la base :mouarf: