Cette section présente les nouveautés UML2.0 en ce qui concerne le diagramme de séquence (appelé sequence diagram ou interaction diagram en anglais)
Les diagrammes de séquence sont comme on peut s’en rendre compte couramment utilisés par nombre d'acteurs d'un projet, même quelque fois à leur insu, sans savoir qu'ils utilisent là un des diagrammes UML. En effet, le diagramme de séquence est une représentation intuitive lorsque l'on souhaite concrétiser des interactions entre deux entités (deux sous-systèmes ou deux classes d'un futur logiciel). Ils permettent à l'architecte/designer de créer au fur et à mesure sa solution. Cette représentation intuitive est également un excellent vecteur de communication dans une équipe d'ingénierie pour discuter cette solution.Les diagrammes de séquence peuvent également servir à la problématique de test.
Les traces d'exécution d'un test peuvent en effet être représentées sous cette forme et servir de comparaison avec les diagrammes de séquence réalisés lors des phases d'ingénierie.
Les diagrammes de séquence tels que définis en UML1.x souffraient cependant d'un gros inconvénient. La quantité de diagrammes à réaliser pouvait atteindre un nombre conséquent dès lors que l'on souhaitait décrire avec un peu de détail les différentes branches comportementales d'une fonctionnalité.
Le plus coûteux étant de remettre à jour ces diagrammes lors d'un changement au niveau des exigences ou bien du design. Nous allons voir qu’UML2.0 souhaite donner plus de puissance de représentation à ces diagrammes grâce à de nouvelles constructions qui peuvent servir à réduire la quantité de diagramme à réaliser.
Nous avons vu plus haut qu’un diagramme de séquence permet de décrire les interactions entre différentes entités et/ou acteurs : par exemple des objets dans un modèle d'un logiciel, des sous-systèmes dans un modèle d'un système complet.
- Le temps est représenté comme s'écoulant du haut vers le bas le long des "lignes de vie" (lifeline) des entités.- Des flèches représentent les messages qui transitent d'une entité vers l'autre. Le nom des message apparaît sur chaque flèche. Si l'extrémité de la flèche est pleine, le message est synchrone. Si l'extrémité de la flèche est creuse, le message est asynchone.
1.1. « Boite noire »
Un composant possède une « vue externe » (ou vue de type Black Box) qui reflète ses propriétés et ses opérations visibles. Cette vue montre l’ensemble des interfaces requises et fournies, nécessaires au fonctionnement du composant. De plus, le comportement d’un composant peut être spécifié sous la forme d’une machine à état associée à une interface ou au composant lui-même, servant à définir de façon précise les différents états possibles du composant et les conditions à remplir pour déclencher des réactions ou des changements d’états au sein de ce même composant.
1.2. « Boite blanche »
Un composant possède aussi une « vue interne » regroupant l’ensemble de ses propriétés privées et de ses fonctions réalisant ses interfaces. Cette vue montre comment le comportement externe est implémenté
Commentaires