Bonjour à tous,
est ce que quelqu'un pourrait bien me donner un lien de site dans lequel je pourrais avoir le diagramme de classe du méta-modèle UML.
Merci bien d'avance.
Version imprimable
Bonjour à tous,
est ce que quelqu'un pourrait bien me donner un lien de site dans lequel je pourrais avoir le diagramme de classe du méta-modèle UML.
Merci bien d'avance.
Aujourd'hui 2 metamodèles sont officiellement reconu par l'OMG. Il y a celui de Netbean appelé MDR mais qui est en sérieurse perte de vitesse car uniquement utilisé par un seul outil et celui d'Eclipse EclipseUML2 disponible sur: http://www.eclipse.org/modeling/mdt/?project=uml2
Il faut avouer que c'est un peu complexe si on veut tout annalyser car il y un mécanisme interne. Mais c'est vraiment intéressant car en regardant de plus prêt on voit que le metamodel utilise un méchanisme de Id crée dynamiquement ce qui est petite révolution dans le monde de la conception UML.
L'avantage est de donné à la volé à chaque élement une Id défini de manière arbitraire à sa création et ensuite réutilisé durant toute la vie du projet. Je veux dire que 2 elements ne peuvent avoir la même Id mais que si on utlise le même élement dans plusieurs vue dans des diagrammes alors il y possibilité de garder la même Id et c'est là que ce métamodel devient absolument génial :ccool:
L'avantage par rapport au modèle prenant en compte le nom de l'élément comme réference du modèle est considérable. Nous avions chez Omondo en 2002 décidé de partir de tag dans le code afin d'aider la synchronization permanente entre le code et le modèle et de partir des noms des élements car une classe java ne peut avoir 2 fois le même nom. Cela semblait logique et on a sorti notre outil EclipseUML Free Edition.
Deux ans plus tard malgrés 500 000 download on s'est prit le mur en pleine figure car l'outil était de manière systématique abandonner pour les projets complexes. Seul le reverse était utilisé.
En 2005 on demande un rapport à un expert qui nous explique que le fait de mélanger code et tags rendait le refactoring du projet et donc du modèle impossible. Or un projet est toujours refactorer tôt ou tard. L'autre conclusion était que la gestion du modèle en partant du nom de l'élément était mauvaise car on restait uniquement lié à java et au JDK et idem le refactoring devenait aussi impossible en Java.
Enfin cérise sur le gateau on découvre en Junitant le modèle en mémoire que le model EMF est mauvais et ne corespond pas au diagramme. Une vrai catastrophe pour un outil mais personne ne le savait et encore aujourd'hui EMF ne l'a pas fixé !!
La solution pour nous passait donc par l'utilisation du métamodel EclipseUML2 en natif afin d'éviter les tags dans le code et de ne pas manipuler un modèle en mémoire corrompu mais d'avoir toujours une sauvegarde sur disque manipulable et testable du modèle. La gestion du modèle en partant des Id UML et non pas du nom a aussi permis de de libérer de la contrainste Java et de pouvoir donner le même nom à plusieurs élements.
Le rafactoring du modèl est abolument génial car comme on refactor le nom de l'élément et pas l'Id alors celle ci reste toujours la même et comme à chaque création du diagramme on va chercher l'information dans le modèle du metamodel sur disque, alors tous les diagrammes sont remis à jour. L'idée est vraiment une grande avancé dans la modélisation UML car il faut oublié qu'il n'y a que 5 ans on parlait encore de modèle et de vue et que cela ne s'appliquait qu'a la partie graphique. Il n'y avait pas moteur en dessou comme une sorte de règle mathématique pour gérer les vues et y rajoutant un sens plus profond que juste graphique. Nous sommes donc passé d'un UML graphique a un UML moderne prenant en compte le modèle graphique (e.g. niveau 0) et le modèle physique appelé metamodel (niveau 1) , excuser moi de cette liberté de language car on est pas en base de donné, mais l'extrapolisation est parfaite dans ce cas si on sauvegarde le metamodel sur disque comme chez Omondo.
Enfin l'idée de remonté jusqu' à MOF et d'encapsuler la transformation afin de rendre transparent le niveau 2 et 3 est aussi une nouveauté que j'ai proposé :mouarf:
Ca fait 5 ans que l'on se bat dans mon entreprise pour promouvoir une interchangeabilité des modèles entre les éditeurs UML, et il faut bien dire que EclipseUML2 est devenu le standard utlisé par quasiment tous les outils du marché. C'est résolument l'avenir de l'UML
Vlade, je me permet d'être TRES surpris par cette erreur de conception pour une société qui travail sur UML et les transformations UML-Java.
Je suis vraiment surpris :(
Contrairement à Vlade qui noie les autres et se noie lui-même sous des aspects techniques imcompréhensibles, moi je répond aux questions que l'on me pose. Aussi, voici, cher masterist, ce que tu demandes en pièce jointe. (attention, il s'agit d'UML 1.1 et pas 2.0).
Hephaistos007: C'est quoi cette litérature UML 1.1 !! Autant revenir à la programmation en assembleur :mouarf:
De plus dans ce pdf ou voyez-vous qu'il parle de metamodel. Un peu dans le titre avec un shéma qui veut rien dire et dans les éléments du metamodel. C'est du pipo !! c'est creux et c'est pour cela que l'UML est entrain de ce planter. Ce type de diagramme c'est du vent pour planner et non pas pour faire des projets !! Conclusion ce pdf c'est nul.
Ego je viens de lire vos articles sur la modélisation, et il traite de la modélisation d'un point de vue utilisateur. Ce que vous me dites c'est comme si un conducteur de voiture venait dire à un mécanicien comment réparer la voiture sous prétexte qu'il sait conduire. Vous n'avez aucune expertise en création d'outil sauf si je me trompe !! Laisser nous faire notre travail car nous on va pas vous dire comment modéliser car ce serait un peu prétentieux de remmettre en cause votre travail que vous faite sans doute tous les jours.
Vous devez dans un projet avoir des diagrammes UML et un modèle unique de tout votre projet. Tout le reste est superflu et ne fait perdre que de la productivité. La transformation est aussi superflu au niveau des modèles, mais pas au niveau conception. C'est là que vous avez pas vu la subtilité !! cette transformation des modèles que j'appel aussi usine à Gaz, n'a d'objet que de répondre à une problématique technique de création et merge de modèle pour les outils ne sont pas natif xmi. Ces outils UML transforment pour être faire du meta model mais ne manipule pas directement le metamodel.
L'exemple qui tue est ce que j'ai vu l'autre jour dans une entreprise. Il avait une cinquantaine de modèle un peu partout sur UML fait avec RSA. Il voulait toout consolider afin de mieux gérer leurs modèles. Un grand du consulting est passé et a chiffré à 1 000 jours hommes à 1200 euro jours pour faire ce merge au niveau entreprise. Je sus passé derrière et j'ai chiffré à 15 minutes le travail nécéssaire pour faire ce merge si on est natif en récupérant tous les modèles RSA. Je comprend qu'après mon passage je n'ai pas que des amis parmis les intégrateurs et consultants, mais j'aime pas faire du vent !!
Mon explicatiion sur le meta model c'est ce qui passe vraiment sous le capot et pas les slides théoriques des consultants qui ne sont là que pour vous facturer le plus de jours possible et non pas répondre au vrai problème d'agilité, de gestion de projets, d'intégration continue, de cycle de vie du logiciel etc....!! :calim2:
Ce document, datant de 1997 (plus de dix ans !) commence ainsi :Citation:
De plus dans ce pdf ou voyez-vous qu'il parle de metamodel. Un peu dans le titre avec un shéma qui veut rien dire et dans les éléments du metamodel.
This is the metamodel of the Unified Modeling Language (UML). It describes the constituents of all well-formed models that may be represented in the UML, using the UML itself. See http://www.rational.com/uml for updates.
On en revient toujours au même point. Tu es le seul en 2009 qui n'a toujours pas compris ce qu'est un métamodèle :cfou:. Que ce document ne contiennent pas tous les détails, cela je te le concède volontier.
Bah tu veux que je lui donne quoi ? le métamodèle d'UML au format ECORE ? Le voici : platform:/plugin/org.eclipse.uml2/model/UML2.ecore. Tu crois vraiment que ca va l'aider à comprendre quelque chose ?Citation:
C'est du pipo !! c'est creux et c'est pour cela que l'UML est entrain de ce planter. Ce type de diagramme c'est du vent pour planner et non pas pour faire des projets !
Sans transition, qu'appelles-tu consolider des modèles UML, et merger des modèles UML d'une entreprise ? Pour une fois, essayes de m'expliquer dans des termes simples, clairs et acceptés de tous, en prenant un exemple concret. Merci d'avance.
Ce document est nul et 10 ans en UML c'est comme 100 ans en industrie. Va-t-on encore parler des machine à vapeur aujourd'hui ?
Le metamodel est le language UML provenant de MOF. Le diagramme est une vue du metamodel pour moi maintenant je comprend que si on a utiliser la machine à vapeur en 97 il est difficle de se remmettre à jour.:mouarf:
Le lien n'est pas un html et je ne trouve pas la page, merci de renvoyer le bon lien svp. Non, ce n'est résolument pas Ecore mais EclipseUML2 qui est le metamodel. Ecore s'est comme un MOF et à partir d'Ecore on sérialise pour faire un metamodel UML. A partir d'Ecore on peut aussi généreeer des modèles DSL, BPMN etc...Citation:
Bah tu veux que je lui donne quoi ? le métamodèle d'UML au format ECORE ? Le voici : platform:/plugin/org.eclipse.uml2/model/UML2.ecore. Tu crois vraiment que ca va l'aider à comprendre quelque chose ?
Donc en UML on prend que et seulement EclipseUML2 car prendre MOF qui est le dictionnaire du language ne sert à rien !!
Les entreprises ont des models xmi provenants d'outil UML divers et qui ont été développé sur les 10 dernières années. Ces modèles métiers sont indispensable pour concevoir de nouvelle application communiquant avec les anciennes (je parle de mainframe et de webservices) . L'idée est donc de faire un très gros projet de modélisation composé de tous les projets. Le dilem est que dans l'UML classique on ne peut modéliser qu'un projet à la fois. EclipseUML permet le de merge tous les projets dans un gros datawahouse sans obligation de gérer tous ces projets de modélisation séparement.Citation:
Sans transition, qu'appelles-tu consolider des modèles UML, et merger des modèles UML d'une entreprise ? Pour une fois, essayes de m'expliquer dans des termes simples, clairs et acceptés de tous, en prenant un exemple concret.
Ce n'est qu'une des facettes du projet bien sûre car la complexité croit ensuite, mais elle permet de bien comprendre les challenge auquelles la modélisation actuelle est confrontée dû à la monté en charge de la complexité et du nombre d'information sauvegardé. D'ici 10 ans si on continue comme cela on aura multiplier par 100 la taille des modèles et cela deviendra ingérable si on traite pas le modèle directement à la source et sans transformation. C'est pourquoi que j'ai lancé l'initiative metamodel natif et non pas une trnasformation à partir d'Ecore en utilisant un modèle intermédiare de type GMF :ccool:
Comme d'habitude, je n'ai rien compris à ton intervention, surtout à cause du vocabulaire que tu emplois. Bref, passons...
Ça c'est une remarque pertinente. Mais que veut dire "traiter le modèle à la source", que veut dire "transformation" dans ce contexte ? Du coup, je me demande ce qu'est un métamodèle UML natif ?Citation:
Envoyé par Vlade
Dis-moi si je me trompes, mais je viens de réaliser que, finalement, à travers tes interventions récurrentes sur ce forum, tu estimes que ton produit EclipseUML est plus performant que l'approche EMF+GMF. En gros, tu es en train de nous dire qu'un outil de modélisation UML construit de A à Z sera mieux qu'un outil créé à partir d'un framework générique. Ce genre de remarque s'applique à tous les produits logiciels à travers le monde : encore heureux que le sur-mesure est plus aboutit que ce qui est standardisé.
Moi ce que je vois c'est que c'est une performance de proposer des frameworks génériques permettant de faire tout seul et en une seule journée 60% du travail réalisé par 15 ingénieurs pendant un an. La preuve historique, c'est que des outils de modélisation UML, ca existe depuis 10 ans. Le framework EMF et plus généralement l'idée que chacun puisse créer son propre outil de modélisation (UML ou tout autre chose) en un temps record, ça date de 2008. Ce n'est pas un hasard.
bonjour tout le monde;
j'ai lu presque toutes les reponses bien enchainées sur la discussion, malheureusement, c'est du chinois pour moi.
je fais de l'informatique j'ai déja eu l'occasion de découvrir UML dans le cadre de ma formation mais feu de paille.
aujourd'hui et dans le cadre de mon projet : La première étape consiste
à créer un méta modèle d'un lagage (LAESH c'est un langage qui rentre dans le cadre médical et dernièrement crée par une équipe de recherche), enfin bref; j'aimerai juste savoir comment on fait pour créer un métamodèle d'un langage qui va me servir par la suite d'outil de conversion à un autre langage de programmation en sortie.
j'ai lu dans toutes les réponses et j'ai déduis les poits suivants:
travailler avec eclipse.
telecharger un plugin ecore pour modéliser
une fois la modélisation faite on procède à la partie transformation puis codage.
théoriquement, j'ai rien compris je suis désolé.
mais je veux juste que vous me mettez dans les rails.
PS:
????????? comment creer un metamodèle.??????????
- Tu télécharges Eclipse EMF : http://www.eclipse.org/modeling/emf/
- Tu créé un nouveau modèle ECORE : tu y décrit les concepts de ton langage LAESH).
- Quelques manips plus tard, tu pourras "écrire" qqchose dans ce langage.
Tu trouveras plein de tutoriaux sur Eclipse EMF sur le Net.
Puis, tu va devoir créer une transformation pour passer automatiquement de LAESH à un autre langage. Là renseignes-toi sur la transformation de modèles avec Eclipse EMF. De mémoire, il y a déjà ce qu'il faut (QVT par exemple) dans les plugins installés.
Bon courage.
Il y a 2 possibilités au début du projet:
Soit on crée une sorte de DSL LAESH en partant de Ecore et ensuite en utilisant la sérialisation EMF pour générer ce métamodel spécifique et dédié uniquement à LAESH.
Soit on part d'UML et on rajoute un profile LAESH.
L'avantage du DSL LAESH est de permettre d'avoir un metamodel dédié et spécifique au monde médical.
Le désaventage est qu'il n'existe pas d'éditeur graphique et de normalisation commune de sauvegarde du metamodel ou de representation graphique des éléments. Cela veut dire qu'il peut y avoir autant de DSL LAESH que de projet.
De plus le coût de créer un éditeur graphique est énorme en terme de R&D pour avoir un résultat minimaliste. Un exemple de résultat minimaliste malgré une forte communauté et un projet Eclipse est le projet GMF. On a certe un framework dédié à la modélisation, mais dés qu'on veut faire un truc spécifique on se rend compte que soit la fonction n'a jamais été codée, soit c'est pas vraiment possible sans "workaround" alourdissant considérablement le projet.
Ma recommendation est donc de faire un profile LAESH sur le metamodel UML directement. Les stéréotypes seviront à spécifier les particularités du language LAESH, et permettrons même de changer l'apparence graphique des éléments. Il y a aura un éditeur graphique robuste et testé. Les modèles pourront être interchangeable avec d'autre projet LAESH car seul le profile sera spécifique enfin cerise sur le gateau la génération de code sera déjà cablée.
Faire un DSL LAESH est un projet 50 fois plus long que faire un projet de profile, par contre cela oblige a acheté quelques licences mais qui seront encore entre 10 à 20 fois moins cher que le coup d'intégration d'un projet DSL.
Je suis disponible pour créer un profile UML 2.2 LAESH si vous m'envoyer votre spécification, c'est pas un gros travail et sera une base de travail intéressante.
Avant d'allez plus loin, vous devez donc faire un choix au début du projet sur quelle technologie utiliser avec les avantages et inconvénients.
L'utilisation de framewor générique afin de créer son propre outil est une réelle avancée technologique mais cette avantage ce trouve plus sur la qualité des applicatiions développées que sur la réduction du temps nécessaire. Chez Omondo par exemple on utilise GEF, EMF, EclipseUML2, Eclipse, SVN etc dans notre environnement de développement. Ceci permet de réduire au début le temps pour faire une première maquette mais ensuite l'interconnection des méthodes des différents framework devant être appelées afin de réaliser des opérations complexes est nettement plus difficile. On peut donc avoir un résultat quasi immédiat de 60% du projet mais les 40% qui reste sont très très technique et difficile à finaliser pour passer d'une maquette à un projet vraiment utilsable en production.Citation:
Moi ce que je vois c'est que c'est une performance de proposer des frameworks génériques permettant de faire tout seul et en une seule journée 60% du travail réalisé par 15 ingénieurs pendant un an. La preuve historique, c'est que des outils de modélisation UML, ca existe depuis 10 ans. Le framework EMF et plus généralement l'idée que chacun puisse créer son propre outil de modélisation (UML ou tout autre chose) en un temps record, ça date de 2008. Ce n'est pas un hasard.
L'avantage des frameworks est énorme afin d'améliorer la qualités mais pas le temps nécessaire. Il est une erreure de croire que sous prétexte que l'on puisse faire 60% d'un projet en quelques jours on puissent finaliser un projet en entier de modélisation. L'exemple type est le projet UML2 tools d'Eclipse qui a une équipe de 2 personnes à plein temps derrière, qui est projet Eclipse officiel, mais qui plante dés qu'on veut faire un truc avancé. Si c'était si facile pourquoi ce projet eclipse serait-il un échec aujourd'hui ?
On peut toujours dire que le projet à beson de plus de temps, mais ce projet existe depuis 3 ans maintenant !!
@Vlade
Je ne voulais pas semer la zizanie, je m'étonnais juste de cette erreur qui me parait être une évidence.
Pour ce qui me concerne, ben je ne me considère pas uniquement comme un "utilisateur" d'UML. J'ai beaucoup navigué dans le monde de la modélisation et des outils associés (Rose, XDE, RSM, RSA, Mia-Generation, transformations JET sous Eclipse,...). Je connais plutôt pas mal UML et EMF (et très très bien les entrailles de RSM et RDA). J'ai pas mal participé à l'adaptation d'UML pour..............COBOL !!!! Avec même des générateurs de code.
J'avais au début d'Omondo regardé le produit et j'avais vite abandonné étant donnée la vision que vous aviez de l'utilisation d'UML dans un contexte Java. Ce point a peut être évolué depuis.
NB : pour le langage de Vlade, merci de ne pas faire de remarques désobligeantes. Notez que Vlade vient de Londres.
Ego je comprends pas !! Vous conaissez UML et Mia-Generation donc comment ne comprenez vous pas ce que vous explique ?:calim2:
Confondez-vous EMF et UML ? je pense que non, donc vous savez bien qu'il y a transformation entre Ecore vers UML via une serialisation. Vous savez bien que EMF utlise les tags dans le code pour sauvegarder l'information du modèle etc...
C'est dans cette sauvegarde du modèle taggé que se trouve la limite EMF. J'espère que vous êtes d'accord ?
Le metamodel est pour moi EclipseUML2, qui est le language UML provenant d'Ecore aussi appelé EMOF. Si vous allez sur cette page le mot metamodel est écrit plus de 10 fois. Ne me dite pas que c'est pas un métamodel sinon nous sommes tous des crétins ...:oops:
Pour finir sur le sujet Java, la tracabilité, les itération multiples pour les projets de type agile rendent la génération de code à partir du modèle UML inutile. Désolé mais le modeleur doit travailler sur le modèle et pas essayer de remplacer le développeur en voulant générer du code que l'équipe de developpement aura tout les problèmes du monde à nettoyer.
Les générateurs de code sont pour moi comme les pages html générées à partir des documents word. Ah oui ca marche, on visualise bien l'html sur un browser, mais si on regarde le code en dessou c'est catastrophique. Et si on veut changer alors là ca devient quasi impossible. Le generateur de code que j'appel l'approche MDD s'est idem car le code devient une vrai galère. Il aurai été plus simple de spécifié le squelette de l'application et d'expliquer le métiers de manière fonctionnel en laissant le développeur codé tout en étant dans un cadre défini.
Ma blague du jour: Ce que fait le générateur de code c'est comme un chef d'entreprise qui va faire le ménage à la place de la femme de ménage de peur que le travail soit mal fait :mouarf:
Donc la traceabilité des Id java et UML en même temps permet de combler ce vide et de faire de vrai projet UML bien codé :ccool:
Concernant Cobol, dotnet, c++ etc...ce n'est pas notre cible et on fera jamais. Nous sommes des experts java/jee et on reste uniquement sur ce marché.
Excusez moi d'être un peu directe mais j'ai l'impression que de monbreux modeleur confondent MDD (model driven development) et UML. On peut faire de l'UML sans generation de code car l'UML est un language.
Ni ego, ni moi, n'avons remis en cause cela il me semble. C'est même précisément ce que j'ai dis. En effet, vous m'avez indiqué ci-dessus que le lien platform:/plugin/org.eclipse.uml2/model/UML2.ecore n'était pas une URL valide. Evidemment, puisqu'il s'agit d'une URI permettant d'accéder au méta-modèle UML2 d'EclipseUML justement !! C'est assez ironique comme situation...Citation:
Envoyé par Vlade
Moi je veux bien vous croire, mais je ne comprend toujours pas de quoi vous parlez (je ne demande qu'à apprendre). Pouvez-vous illustrer ce principe par un exemple de codeou un schéma s'il vous plaît. Sans cela, j'arrête ici cette conversation qui ne mène à rien. Merci.Citation:
Envoyé par Vlade
Désolé mais je ne comprend pas cette phrase "EMF utilise des tags" ? "dans le code" ? Le code de quoi ?Citation:
Vous savez bien que EMF utlise les tags dans le code pour sauvegarder l'information du modèle
Si je regarde RSM, voici un début de modèle UML
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16<?xml version="1.0" encoding="UTF-8"?> <!--xtools2_universal_type_manager--> <?com.ibm.xtools.emf.core.signature <signature id="com.ibm.xtools.uml.msl.model" version="7.0.0"><feature description="" name="com.ibm.xtools.ruml.feature" url="" version="7.0.0"/></signature>?> <?com.ibm.xtools.emf.core.signature <signature id="com.ibm.xtools.mmi.ui.signatures.diagram" version="7.0.0"><feature description="" name="Rational Modeling Platform (com.ibm.xtools.rmp)" url="" version="7.0.0"/></signature>?> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:BNPP_LabelManagement="http:///schemas/BNPP_LabelManagement/_plZJUIM9Ed6J0bxvLhW5gw/5" xmlns:Cobol="http:///schemas/Cobol/_4UJJcKK9Ed6pR7UGpf_PKQ/38" xmlns:Default="http:///schemas/Default/1" xmlns:IMSDB2="http:///schemas/IMSDB2/_sJEPoM0uEd64QZOYgQq1cg/3" xmlns:LogicalDataModel="http:///schemas/LogicalDataModel/_I-A7kH22EdyVFsbHosTlvA/59" xmlns:RUPAnalysis="http:///schemas/RUPAnalysis/3" xmlns:Standard="http://www.eclipse.org/uml2/schemas/Standard/1" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:notation="http://www.eclipse.org/gmf/runtime/1.0.1/notation" xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML" xmlns:umlnotation="http://www.ibm.com/xtools/1.5.2/Umlnotation" xsi:schemaLocation="http:///schemas/BNPP_LabelManagement/_plZJUIM9Ed6J0bxvLhW5gw/5 pathmap://ANALYSIS_PROFILE/BNPP_LabelManagement.epx#_plZJUYM9Ed6J0bxvLhW5gw?BNPP_LabelManagement/BNPP_LabelManagement? http:///schemas/Cobol/_4UJJcKK9Ed6pR7UGpf_PKQ/38 pathmap://MY_COBOL_PROFILE/Cobol.epx#_4UcEYKK9Ed6pR7UGpf_PKQ?Cobol/Cobol? http:///schemas/Default/1 pathmap://UML2_MSL_PROFILES/Default.epx#_IN8k8MmBEdqBcN1R6EvWUw?Default/Default? http:///schemas/IMSDB2/_sJEPoM0uEd64QZOYgQq1cg/3 pathmap://MY_COBOL_PROFILE/imsdb2.epx#_sJEPoc0uEd64QZOYgQq1cg?IMSDB2/IMSDB2? http:///schemas/LogicalDataModel/_I-A7kH22EdyVFsbHosTlvA/59 pathmap://TRANSFORM_LDM_PROFILES/LogicalDataModel.epx#_I-NI0H22EdyVFsbHosTlvA?LogicalDataModel/LogicalDataModel? http:///schemas/RUPAnalysis/3 pathmap://RUP_PROFILES/RUPAnalysis.epx#_DM6zsMmEEdqP1b5S0px2VQ?RUPAnalysis/RUPAnalysis? http://www.eclipse.org/uml2/schemas/Standard/1 pathmap://UML_PROFILES/Standard.profile.uml#_yzU58YinEdqtvbnfB2L_5w"> <uml:Model xmi:id="_p4YtQOsVEdqui5XwzVul9Q" name="02- Modèle analyse conception"> <eAnnotations xmi:id="_p4YtQesVEdqui5XwzVul9Q" source="uml2.diagrams"> <contents xmi:type="notation:Diagram" xmi:id="_cnsT8tbNEduGM6ZC3Thcqg" type="Freeform" name="!Lisez-moi"> <styles xmi:type="umlnotation:UMLDiagramStyle" xmi:id="_cnsT89bNEduGM6ZC3Thcqg"/> <element xsi:nil="true"/> </contents> </eAnnotations> <eAnnotations xmi:id="_srfuEOsVEdqui5XwzVul9Q" source="http://www.eclipse.org/emf/2002/Ecore"/> <packageImport xmi:id="_p4YtU-sVEdqui5XwzVul9Q"> <importedPackage xmi:type="uml:Model" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#_0"/> </packageImport>
etCitation:
Pour finir sur le sujet Java, la tracabilité, les itération multiples pour les projets de type agile rendent la génération de code à partir du modèle UML inutile
je ne comprend toujours pas ?Citation:
Donc la traceabilité des Id java et UML en même temps permet de combler ce vide et de faire de vrai projet UML bien codé
Selon vous, on peut ou pas générer du code Java à partir d'un modèle UML ?
Les Id UML, je peux comprendre car chaque élément UML dans le méta-modèle comporte un identifiant unique (xmi:id) mais l'identifiant Java, je ne connais pas !
Bon, comme mon prédécesseur, des exemples concrets me paraissent nécessaires
RSM utlise un modèle interne et ensuite une transformation EMF pour séraliser ce modèle et générer un XMI. Ce n'est pas une utlisation directe d'EMF avec le code Java.Citation:
Désolé mais je ne comprend pas cette phrase "EMF utilise des tags" ? "dans le code" ? Le code de quoi ?
Si je regarde RSM, voici un début de modèle UML
Chaque élément Java a une Id et aussi un modèle dans le jdt. Lorsqu'on travail au niveau de la couche en dessou de java avec le byte code alors cela est plus visible :ccool:Citation:
je ne comprend toujours pas ?
Selon vous, on peut ou pas générer du code Java à partir d'un modèle UML ?
Les Id UML, je peux comprendre car chaque élément UML dans le méta-modèle comporte un identifiant unique (xmi:id) mais l'identifiant Java, je ne connais pas !
Je comprends que cela soit pas visible pour les développeurs qui utlise le language Java car ils ne doivent pas comprendre la façon dont le language a été créer.:?
D'une manière générale, il y a les couches hautes et visible que son les diagrammes UML graphiques et le code java et les couches basses, voir très basse que sont le metamodel, les sérializations à partir de MOF permettant de générer le language UML, le byte code pour java etc...Ces couches basses ne sont pas visibles et donc inconnu aux utlisateurs mais c'est sur cette partie que les gains de productivités sont les plus spectaculaires aujourd'hui.
Si on devait faire une comparaison avec une voiture, j'ai l'impression qu'avec UML que on a pensé à la carrosserie, à l'intérieurs, aux fonctions de bien être etc...et que jamais personne ne s'est préocuper de la puissance du moteur !!
Pour moi fan de belle Ferrari, Aston Martin, BMW, Mercedes coupé décapotable etc... :ccool: , c'est d'abord le moteur qu'on construit et ensuite on bati la carrosserie avec soin autour et non pas l'inverse. On peut avoir une superbe carrosserie et un moteur de 2CV dedans si on commence pas par développer une architecture logiciel bâti autour d'un moteur puissant suivi de l'implémentation UML au dessu:aie:
bjr j'ai besoin de vous car j'ai un problème sur EMF,UML,métamodele :mes question:
1-comment créer les modèles conforme à métamodèle Ecore?
2-ou je peut trouver le métamodèle UML sur l'environnement EMF eclipse?
3-que faire pour que le mon modele UML soit conforme a ce métamodele?
4-ou je peut trouver le métamodèle java dans EMF?
merci:calim2:
@Vlade
là je lache prise, je ne comprend rien, désolé