Version imprimable
Bonjour à tous,
voila je viens de finir mon projet en java et j'aimerai créer un diagramme UML.
Je développe sous éclipse et les seul outils que j(ai trouvé sur internet ne me permette pas de recupéré mes sources pour créer le diagramme.
En clair je voudrai a partir de mes sources généré un schémas UML
Merci d'avance
1) Plugin "Omondo" pour Eclipse
2) Cette réponse est donnée au moins une fois par semaine... fais une recherche sur le forum!
Et merise, pour une fois que quelque chose est francais ;)
Merise pour Eclipse?... Je ne connais pas ce produit, et je n'arrive pas à le trouver de plugin portant ce nom sur Google. Pourrais-tu m'en dire plus (voire donner un lien): ça m'intéresse grandement!Citation:
Envoyé par openWorld
Je n'aime pas beaucoup Omondo, et je ne l'utilise que parceque je n'ai pas trouvé de meilleurs produit gratuit intégré à Eclipse pour l'instant.
Les diagrammes UML ne sont pas fait pour donner une representation schematique de ton code. Un diagramme de classe est le fruit d'une reflexion qui te permet ensuite de produire du code. Je pense que tu as fait un peu le cheminement inverseCitation:
Envoyé par pierrot2908
tu as outil gratuit bouml qui est pas mal aussi,
il te fait un reverse engeneering et te construit tes classes. par contre il de fait pas les diag a ta place ;-)
mais comme dit plus haut, normalement c est a toi de la faire (en general avant de coder ;-)) )
Comme le dit leyee on crée d'abord des diagrammes, en réflechissant d'abord à tous les services et facilités auquel le logiciel doit répondre (Use Case Diagram)
A partir de là on peut commencer )à faires des diagrammes de classes qui vont être souvent retravaillés afin de fournir le squelette de ton projet avec toutes les interactions avec le système. Une fois ça fait on crée les diagrammes d'étas, de séquence, etc représentant l'éxécution du programme. Mais jusque là, on n'a encore tapé AUCUN code. Quand tous les diagrammes sastisfont (A est un bon modèle de B si A permet de répondre de manière satisfaisante aux questions posées sur B) tu utilise le bouton de génération de code de ton IDE (même si je ne le recommande pas) et le code squeletted e ton projet va être généré. Mais en aucun cas on ne fais le code puis les diagrammes. C'est un peu comme si tu construisais ta maison et puis que tu faisais les plans. Ca n'a aucun sens.
A quoi servent-ils alors ?Citation:
Les diagrammes UML ne sont pas fait pour donner une representation schematique de ton code.
Faux. Il peut très bien arriver qu'on écrive du code, puis qu'on génère des diagrammes après. C'est particulièrement le cas dans une situation de maintenance de code (les diagrammes n'existent pas toujours), ou même de refactoring. D'ailleurs, les plans n'étant jamais figés définitivementCitation:
Mais en aucun cas on ne fais le code puis les diagrammes.
.Citation:
faires des diagrammes de classes qui vont être souvent retravaillés
Il va de soi qu'il faut avant de coder une idée précise de ce que l'on va faire, mais certains diagrammes peuvent n'intervenir qu'au cours de la réalisation (dans un cycle de développement par itérations par exemple).
Il serait faux de dire qu'ils ne donnent pas une représentation shématique du code, surtout au niveau des diagrammes de classes, mais ils sont avant tout un modèle. UML ça signifie quand même unified Modeling language, les diagrames sont des modèles, ils sont utilisés comme simplification de la réalité afin de répondre aux questions posées cette dernière.
Quoiqu'il en soit, tu peux en dire ce que tu veux on en fait pas lecode puis les diagrammes, on ne le fait même JAMAIS, si on le fait c'est qu'on s'est mal pris. Tu mérite d'être brûlé vif en place publique pour hérésie en proférant de telles paroles lol;).
Pour la maintenace de code, on modifie le diagramme et justement la connection modèle-réalité la modifier le comportement du projet. Mais avant toute chose on modélise. Si le modèle ne fonctionne pas, la réalité ne le fera pas non plus.
On modifie un diagramme parce qu'on s'est aperçu qu'une autre approche du problème est meilleure, et dans ce cas on modifie les parties du diagramme concernées, mais si on s'aperçoit d'un problème de fonctionenment, on ne modifie pas le code puis les diagrammes, c'est tout le contraire. N'importe qui te dira ça, c'est le fondement même de la modélisation UML. Quand tu construis une maison, si tu t'aperçois qu'un mur est malfait, tu change les plans, tu les corrige et ensuite tu abats le mur pour en faire autre chose. Pas l'inverse.
Sinon tu as raison certains diagrammes n'aparaissent pas tout de suite et seulement en cours de développement. On a un ensemble de diagrammes D1, à partir de ça on génère et implémente pour avoir un projet P1. On veut ensuite rajouter une fonctionnalité, on crée les diagrammes associés pour avoir un ensemble D2, et ensuite on implémente sur base de D2 le projet P2.
Salut, pardon de dévier un peu du sujet original, mais je voudrais savoir ce que tu repproches à Omondo ? est ce que c'est juste que "tu ne l'aimes pas" ou y a-t-il quelque chose de plus technique et que tu pourrais développer ?Citation:
Envoyé par CyberChouan
Merci :)
Si tu es sur un GNU/Linux, je te conseille d'essayer Umbrello. Ces derniers mois, l'import de classes java a été grandement amélioré et c'est un vrai bonheur.
Sinon, pour la question du moment d'utiliser ce genre d'outils, moi je dirai que c'est utile avant, pendant et après. Avant pour la phase de conception bien évidemment. Mais comme il est très difficile de tout prévoir, j'ai souvent à modifier ou ajouter des choses, et dans ce cas, je modifie le UML sur le papier. La génération d'un diagramme UML me permet alors de documenter et communiquer, et surtout vérifier que ce que j'ai fait reste conceptuellement correct.
C'est vrai que l'on dévie du sujet mais ce n'est pas simplement que "je ne l'aime pas": tout d'abord, la version gratuite est bridée (mais bon, qu'ils ne soient pas adeptes du logiciel libre, c'est leur choix). Ce qui me gène surtout, c'est que ce logiciel fait de jolis diagrammes... MAIS qui ne respectent pas la syntaxe UML lorsque l'on veut être rigoureux! ;)Citation:
Envoyé par kimz
Passons maintenant à la génération de diagrammes UML après avoir codé une application. Cela est effectivement une "hérésie" dans un projet informatique "classique". Cependant, depuis maintenant un certain temps, de nombreux projets sont développés en utilisant "les méthodes agiles": dans cette façon de gérer un projet (en cycles itératifs cours de 2 semaines à un mois), les documents sont bien souvent négligés au profit d'un codage direct.
Généralement, on dispose (heureusement) d'un diagramme effectué en début de projet. Cependant, au fil des cycles, durant ce type de projets, le "refactoring", l'ajout/la suppression/la modification de fonctions sont très courant et bien souvent, les diagrammes ne suivent pas ces modifications.
Dans ces circonstances, il est donc utile de pouvoir régénérer des diagrammes de classe mis à jour à partir des sources.
ok merci, mais je pense que certaines fonctionnalités qui n'étaient pas dispo sur la version free le sont maintenant (exportation de diagrammes .uml ?), donc au fil des versions peut être qu'on aura plus de choix, sinon concernant l'apparence des diagrammes, il y a 3 présentations possibles (Omondo, UML Standard et Eclipse), la seconde te conviendrait mieux peut être.
++
Pas toujours, le code peut être le fruit d'une réflexion et déboucher ensuite sur un diagramme de classe.Citation:
Un diagramme de classe est le fruit d'une reflexion qui te permet ensuite de produire du code
Faux, on peut tout à fait faire ça. La différence entre le développement d'un logiciel et le développement d'un batîment, c'est qu'un logiciel c'est du soft. On peut réusiner (refactoring) le code écrit facilement pour le remodeler, ce qui n'est pas le cas d'une maison. Cette comparaison ne tient pas la route.Citation:
Mais en aucun cas on ne fais le code puis les diagrammes. C'est un peu comme si tu construisais ta maison et puis que tu faisais les plans. Ca n'a aucun sens.
Faux. Tout d'abord, UML n'est pas une méthode de modélisation, mais un langage de modélisation. Comme tout langage, son but est uniquement de communiquer. Et comme le dit CyberChouan, les méthodes agiles préconisent d'obtenir un code qui fonctionne plutôt qu'une documentation fournie. Avec eXtrem Programming par exemple, on ne fait en principe aucune conception préalable au code. On code, on fait des refactorings qui font apparaitre petit à petit de nouvelles classes et modifient la conception. Les habitudes sont changées mais ca fonctionne aussi très bien. On peut ensuite générer des diagrammes UML facilitent ensuite la communication entre les développeurs.Citation:
tu peux en dire ce que tu veux on en fait pas lecode puis les diagrammes, on ne le fait même JAMAIS, si on le fait c'est qu'on s'est mal pris.
...
on ne modifie pas le code puis les diagrammes, c'est tout le contraire. N'importe qui te dira ça, c'est le fondement même de la modélisation UML.
Tout ça peut dire qu'il est tout à fait légitime de vouloir générer les diagrammes UML après avoir réalisé le code source. Cela dépend de la méthode et du cycle de développement appliqués. Et cela permet d'avoir une base saine pour la maintenance du logiciel.
Désolé d'être en hors sujet, mais je pense qu'il fallait remettre les chose au point.
Je t'accorde le fait de m'être mal exprimé sur l'UML en disant modélisation UML, je voulais dire modélisation orienté objet en UML.
Néanmoins je peux t'assurer que tout bon développeur va créer / modifier ses diagrammes avant de coder quoi que ce soit. Si mes arguments ne te persuadent pas (et ils ne le font pas;) ) n'importe quel livre de modélisaton OO te dira la même chose, bien qu'en pratique faire comme cela soit un idéal et que peu de gens le font tout le temps (c'est parfois très ennuyeux de bidouiller les diagrammes pour des bétises), c'est une bonne pratique de développement.
Evidemment le code doit fonctionner, créer des diagrames pour du code qui plante ne sert à rien. Mais en général un code qui plante correspond à un diagramme incorrect, et l'erreur saute généralement aux yeux sur un diagramme (car beaucoup plus simple et lisible qu'un gros bout de code) alors que se plonger dans son code pour chercher l'erreur de modélisation est très fastidieux (je ne parle pas ici d'erreurs de logique spécifiques au language, comme erreurs de casts, divisions mal réalisées,...).
Lol si on continue cette discussion elle va mériter d'être déplacée dans un topic débat réservé;) , mais c'est sympa de partager ses opinions (surtout quand elles sont différentes).