Expertise Java & J2EE

Diagrammes de séquence UML : percer le mystère [Permalink]

Sun May 18 10:35:16 CEST 2008

Très répandus, mais aussi très mal compris, les diagrammes de séquence sont pour moi une des parties le moins bien compris de l'UML. Cette mécompréhension mène beaucoup d'analystes d'études à finir par s'en passer complètement, en préférences d'un usage exclusif des diagrammes d'activité pour modéliser le comportement de leurs projets.

Ce phénomène révèle une première mauvaise idée reçu, car les diagrammes d'activité et les diagrammes de séquence devraient intervenir dans le projet à des stades complètement différentes !. En effet, le diagramme d'activité, plus générale, sert à définir le déroulement d'un cas d'utilisation. Il est donc utile au moment de la spécification où les besoin fonctionnels deviennent figés pour les acteurs techniques on concrétise ce que le logiciel va faire. ("Voici ce qui va se dérouler dans le programme.) Et, effectivement, pour modéliser ces déroulements les diagrammes d'activité sont faciles à lire et très utiles.

Les diagrammes de séquence n'ont rien à faire à ce stade. Les acteurs fonctionnels dans le projet n'y comprendront rien, et ceci pour une bonne raison: les diagrammes de séquence existent pour modéliser le comportement technique. Ils doivent donc intervenir lors de la conception technique de l'application: les diagrammes de séquences sont étroitement liés à la code source de projet, et non pas aux cas d'utilisation au sens métier.

La deuxième chose qu'il faut donc comprendre c'est que, comme le diagramme de séquence est un modélisation technique et non pas fonctionnel, cette modélisation revient à faire de la programmation visuelle. Et comme telle, pour bien faire un diagramme de séquence, il faut avoir une connaissance profonde de la programmation orienté objet.

Déjà pour poser le premier élément du diagramme, l'objet, il faut comprendre le cycle de vie de l'objet, car il est modéliser par la ligne pointillé: il descend, non pas systématiquement du haut en bas du diagramme comme on voit souvent, mais uniquement aussi loin que l'objet modélisé n'existe. Le début represente la création de l'objet ; lorsqu'il est détruit (manuellement dans des langages comme C++, ou bien conceptuellement dans tous les cas), son trait s'arrête.

Le deuxième chose que beaucoup d'analystes comprennent mal c'est les rectangles qui se posent sur ces lignes de vie. Alors que, pour un programmeur, il n'y a rien de plus simple: ça veut dire que la méthode est en train d'exécuter. Quelle méthode? Mais la méthode indiqué sur la flèche stimulus, bien sûr! En effet, ces flèches doivent être utilisées pour définir les appels des méthodes eux-mêmes, et les blocs sur l'objet montrent l'espace de temps où il est en train de s’exécuter activement. C'est donc pour ça que ces diagrammes sont étroitement liés à la code source :

Je peux dire ça dans d'autres mots pour ceux qui sont peut-être plus orienté développement: imaginez le diagramme de séquence comme un schéma visuel de ce qui se passe lorsque vous passez sur un point de débogue. Chaque flèche représente un appel de méthode que vous suivez, et le rectangle représente l'espace de temps que le méthode s’exécute jusqu'à son return. Ce rectangle s’agrandira, donc, si notre méthode appelle d'autres méthodes (sur ce même objet ou un autre). Le rectangle finit lorsque notre appel se retire du call stack.

Lu comme ça, on voit qu'un diagramme de séquence n'est pas du tout un diagramme d'activité difficile à lire! Au contraire, c'est une représentation très lisible des détails au niveau du code qui ne seraient jamais modélisables sur les diagrammes de classes, et qui ne sont pas spécifiés par les diagrammes d'activité. C'est un diagramme qui répond à la question: quel est l'enchaînement des appels des méthodes, sur quels objets, et dans quel ordre?

J'espère que ces points aideront à mieux comprendre ce diagramme et son rôle utile dans la documentation d'un projet informatique. Si vous avez des questions ou si vous n'êtes pas d'accord avec mon point de vue, n'hésitez pas à laisser un commentaire ci-dessous).