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?
bon rappel effectivement, j’ai récemment pu utiliser les cas d’utilisation pour capturer les besoins fonctionnels associés à un processus. La capture s’est effectuée directement avec les utilisateurs (non informatiques) qui se sont dans l’ensemble bien pris au jeu. Une pratique bien agréable.
Tres bon rappel, on peut considerer UML comme un langage permettant a tous de se comprendre en utilisant le même vocabulaire. En tant que concepteur, j utiliserais plutot la forme “plan” avec diagramme de classes ( afin de definir quels sont les objets metiers), et diagrammes de sequence afin de décrire les processus métiers complexes .
Qu’en est-il de Catalyst ? Cette méthodologie autour d’UML, si je me souviens bien, a-t-elle évoluée pour prendre en compte UML2 ? PS: je suis l’actualité d’UML de loin en loin…
Je me réponds ! Ce n’est pas ‘catalyst’ mais ‘catalysis’ (http://www.catalysis.org/index.html) et ça ne semble pas avoir beucoup bougé depuis 1998.
Pingback: J’ai trouvé mon outil UML idéal at Aurélien Pelletier’s Weblog