Diagrammes de séquence

Depuis le début de ce cours, nous n’avons présenté que les concepts relatifs à la vue structurelle des applications. Dans le paradigme orienté objet, la structure d’une application est entièrement définie par ses classes et leurs relations. La vue structurelle est donc complètement couverte par les concepts UML relatifs aux classes (classe, opération, propriété, association, etc.). Rappelons que le diagramme de classes est la représentation graphique de cette vue. L’aspect comportemental d’une application orientée objet est défini par la façon dont interagissent les objets qui composent l’application. À l’exécution, l’objet est l’entité de base d’une application. Les objets qui composent une application pendant son exécution et leurs échanges de messages permettent à l’application de réaliser les traitements pour lesquelles elle a été développée. Cette vue, dont la représentation graphique est le diagramme de séquence, définit deux concepts principaux : celui d’objet et celui de message échangé entre deux objets. Une interaction permet d’identifier plusieurs objets et de représenter les messages qu’ils s’échangent. Dans une application, tout objet est au moins instance d’une classe concrète. Cette classe est celle qui a permis de construire l’objet. En UML, les objets qui participent à une interaction peuvent ne pas avoir de classe dont ils sont instances. Nous appellerons ces objets des objets non typés. Les objets non typés sont utilisés dans les interactions pour spécifier des objets qui ne font que demander la réalisation d’opérations et dont on ne se soucie pas de connaître le type. Dans une application, tout objet a un identifiant. En UML, les objets qui participent à une interaction peuvent ne pas avoir d’identifiant. Nous appellerons ces objets des objets anonymes. Les objets anonymes sont utilisés dans les interactions pour spécifier des objets qui ne sont utilisés qu’une seule fois. Il ne sert alors à rien de bien les identifier.

Les objets qui participent à une interaction sont représentés graphiquement dans un diagramme de séquence par un carré contenant l’identifiant de l’objet (si l’objet n’est pas anonyme), suivi du nom de la classe dont l’objet est instance (si l’objet est typé). Attaché à ce carré, une ligne verticale représente la vie de l’objet dans le temps (l’axe du temps étant dirigé vers le bas du diagramme).UML intègre donc le message d’appel d’opération dans les interactions entre objets. Plus précisément, UML propose deux messages d’appel d’opération : un message pour les appels synchrones (l’appelant attend de recevoir le résultat de l’opération avant de continuer son activité) et un message pour les appels asynchrones (l’appelant n’attend pas de recevoir le résultat de l’opération et continue son activité après avoir envoyé son message).UML propose aussi des messages de création et de suppression d’objets afin de gérer le cycle de vie des objets participant à une interaction. Dans une interaction UML, les objets peuvent soit exister au début de l’interaction, soit être créés par d’autres objets pendant l’interaction. Il est aussi possible de spécifier des suppressions d’objets. Celles- ci sont initiées par des objets participant à l’interaction. Un objet détruit ne peut plus recevoir de message.

Le troisième message est un message d’appel asynchrone d’opération. Ce message signifie que l’objet id1 demande à l’objet id2 de réaliser l’opération nommée opération2. Une même opération sur un même objet peut être appelée de manière synchrone et asynchrone dans une même interaction. Il aurait donc été possible d’appeler à nouveau l’opération opération1 mais de manière asynchrone. L’appel étant asynchrone, l’objet id1 n’a pas besoin d’attendre la fin du traitement de l’opération pour continuer son activité. Une interaction spécifie une succession d’échanges de messages entre les objets participant à l’interaction. Le temps est donc très important puisqu’il précise l’ordre d’exécution entre tous les messages d’une même interaction. Dans une interaction UML, le temps est gouverné par deux règles principales (voir ci- après). Ces règles considèrent les messages d’appel synchrone d’opération et de création comme deux messages, un appel et un retour. Il y a donc une flèche de l’objet émetteur vers l’objet récepteur (appel) et une autre de l’objet récepteur vers l’objet émetteur (retour).Chaque message est ensuite décomposé en deux événements, un événement d’envoi et un événement correspondant à la réception. L’envoi est matérialisé par l’extrémité de départ de la flèche correspondant au message et la réception par l’extrémité d’arrivée de la flèche. Ainsi, le temps est régulé par les règles suivantes..