Tag Archives: uml

J’ai trouvé mon outil UML idéal

screenshotUMLet.gifJe suis un grand fan de l’utilisation d’UML en tan que croquis.
Le meilleur outil pour cette utilisation est sans doute le paper board ou le bon vieux papier + crayon. Malgrès tout on fini toujours par avoir besoin de passer tout cela au format électronique et c’est là que ça se gâte. La pluspart des outils sont conçus pour utiliser UML en tan que plan, ils sont compliqués et regorgent de fonctions qui me sont totalement inutiles (round trip engineering , apply pattern…). Bref, après être passé par Structure Builder, Objecteering, Together, Rose, XDE, Visual paragdim for UML, Poseidon, Omondo… J’ai toujours été frustré et trouvé que le temps d’apprentissage pour être productif avec ces outils était trop long. Je précise une nouvelle fois: ces critiques portent sur une utilisation d’UML en tan que croquis.

Mais ma quête du Graal est finie!! J’ai enfin trouvé mon outil UML de rêve : il est conçu pour faire la seule chose qui m’intéresse: des croquis UML de manière simple et rapide. Il m’a fallu 10 min pour savoir m’en servir et 5 de plus pour faire mon premier diagramme d’une dizaine de classes.
Pour ne rien gâcher:

– C’est un programme open source en java.
– Il permet d’exporter ses diagramme dans de nombreux format.
– L’interface est simple et sans pop-up!
– Il fonctionne en standalone où comme plugin eclipse.
– Il est extensible très facilement.
– Il supporte les principaux types de diagramme UML.

Je vous fait pas patienter plus longtemps. Courrez essayer UMLet.

UML n’est pas une méthodologie

Je profite de ce billet de Bruce Eckel: UML vs OO design pour rappeler qu’UML n’est pas une méthodologie. Ce n’est sans doute pas inutile de le rappeler car énormément de cv associe Uml et méthodologie. Uml est tout juste un outil, un simple language, une collection de diagrammes qui facilitent la communication entre les différents acteurs d’un projet informatique. Bref UML est un outil très utile mais loin d’être suffisant pour garantir de bien modéliser un problème donné.

La preuve qu’Uml n’est pas une méthodologie on peut l’utiliser de différentes manières comme l’indique Martin Fowler:
Uml en tant que croquis:
On modélise rapidement une partie d’un problème pour en discuter avec d’autres personnes et avancer dans la compréhension du système. Dans ce mode l’outil essentiel reste la feuille de papier et le crayon de papier avec une bonne gomme. Si vous été fortuné un paperBoard et un marqueur seront les bienvenus 😉
Uml en tant que plan:
Le concepteur va modéliser le système à l’aide de diagrammes uml (principalement des diagrammes de classe et de séquence). Le développeur s’appuie sur ces diagrammes (des plans) pour implémenter le système. Dans ce mode un bon logiciel de modélisation est indispensable.
Uml en tan que plan peut aussi servir à faire du reverse engineering (omondo est particulièrement fort à ce petit jeu).
Uml en tant que language:
MDD.. Model driven développement. L’ensemble du système est décrit en uml. On appuie sur un bouton et l’implémentation qui va bien est généré automatiquement (c’est un peu plus compliqué que ça mais c’est l’idée). L’un des buts d’UML 2.0 est de mieux supporter MDD et MDA (model driven architecture)

On peut aussi se servir d’Uml pour la capture des besoins (c’est proche d’uml en tan que croquis): les diagrammes de cas utilisation. Mais attention l’important dans un cas d’utilisation ce n’est pas le dessin avec les petits bonhommes mais la description qui va avec. Les diagrammes de classes et/ou d’objets sont aussi de bons supports si les fonctionnels ne les rejettent pas. Modéliser un problème avec un diagramme de classe Uml force à la rigueur en laissant peu de place pour les incertitudes (à moins de tracer des relation n,n dans tous les sens).

Et vous, vous en servez comment d’uml?