Monthly Archives: July 2005

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?

Avec où sans état? une histoire de context

A lire ou à regarder et écouter sur TheServerSide l’interview de Ted Neward. Le personnage est haut en couleur et ne dis pas que des bêtises. Difficile de s’y résoudre mais il a raison, il faudra bien que je finisse par mettre un peu de .net dans mon CV.

J’aime beaucoup son exemple pour expliquer qu’il préfère les “designs patterns” aux “best practices”:
Une bonne pratique est de toujours veiller à libérer les ressources que l’on utilise une fois que le programme a fini de s’exécuter. Mais dans le cas d’un programme embarqué de guidage d’un missile…Ce n’est pas forcément très utile. Les best practices n’existent pas, il n’y a que des problèmes et des solutions qui s’appliquent dans un certain contexte.

Et j’adore son exemple pour illustrer le concept de communication avec où sans état.

Conversation avec état:
– Bonjour Jean, tu veux aller déjeuner?
– Bien sûr Paul, où allons nous?
– Pourquoi pas le restaurant Italien?
– Super, quand y allons nous?
– A midi.

Conversation sans état:
– Bonjour Jean, tu veux aller déjeuner?
– Bien sûr Paul, je veux aller déjeuner, où allons nous?
– Allons déjeuner au restaurant Italien, Jean.
– Super Paul, allons déjeuner au restaurant Italien mais à quelle heure?
– Jean nous allons déjeuner au restaurant Italien à midi.

Un protocole de communication sans état doit en permanence transporter tout le contexte.

Impedance Mismatch

Que ceux qui travaillent en mémoire avec des objets et qui persistent ces mêmes objets dans une base de données relationnelles lèvent le doight…

Hibernate et Toplink avant lui sont des “messies” pour résoudre le fameux problème du mapping objet relationnel. Mais utiliser ces frameworks pour résoudre le problème ne garantit pas le succès. Il faut comprendre la différence entre la conception orienté objet et le monde des bases de données relationnelle, le fameux “Impedance mismatch”. Je vous recommande donc la lecture de cette publication : Modèles relationnel et objet qui fait très bien le tour de la question.

Si il n’y avait qu’une seule chose à retenir:
Dans le monde relationnel on calcul (jointures, indexes…) l’accès aux données alors que dans le monde objet on parcours un model (pointeurs). Les conséquences? L’objet permet d’obtenir un modèle plus proche de la réalité et donc utile pour traiter des problèmes complexes. Par contre il est beaucoup plus dur de mettre à jour une données dans un modèle objet que dans un modèle relationnel.

Je veux travailler avec une base de données objet !!!!