Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
création diagramme UML
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!
Avant de poster, pensez à regarder la FAQ, les tutoriaux, la Javadoc (de la JRE que vous utilisez) et à faire une recherche
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!Envoyé par openWorld
Et merise, pour une fois que quelque chose est francais
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.
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 ?
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!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 ?
Merci
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.
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 inverse
bouml
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 ?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éfinitivementMais en aucun cas on ne fais le code puis les diagrammes.
.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.
Répondre avec citation
Partager