Présentation du formalisme Porte de garage motorisée à enroulement

7.1.1 Introduction

Un objet interagit pour implémenter un comportement. On peut décrire cette interaction de deux manières complémentaires : l’une est centrée sur des objets individuels (diagramme d’états-transitions) et l’autre sur une collection d’objets qui coopèrent (diagrammes d’interaction).

La spécification d’un diagramme d’états-transitions est précise et conduit immédiatement au code. Elle ne permet pas pour autant d’expliquer le fonctionnement global d’un système, car elle se concentre sur un seul objet à la fois. Un diagramme d’interaction permet d’offrir une vue plus holistique1 _{du comportement d’un jeu d’objets.}

Le diagramme de communication (section 7.2) est un diagramme d’interaction mettant l’accent sur l’organisation structurelle des objets qui envoient et reçoivent des messages. Le diagramme de séquence (section 7.3) est un diagramme d’interaction mettant l’accent sur la chronologie de l’envoi des messages. Les diagrammes d’interaction permettent d’établir un lien entre les diagrammes de cas d’utilisation et les diagrammes de classes : ils montrent comment des objets (i.e. des instances de classes) communiquent pour réaliser une certaine fonctionnalité. Ils apportent ainsi un aspect dynamique à la modélisation du système.

Pour produire un diagramme d’interaction, il faut focaliser son attention sur un sous-ensemble d’éléments du système et étudier leur façon d’interagir pour décrire un comportement

particulier. UML permet de décrire un comportement limité à un contexte précis de deux façons : dans le cadre d’un classeur structuré (cf. section 7.1.2) ou dans celui d’une collaboration (cf. section 7.1.3).

7.1.2 Classeur structuré

Figure 7.1: Exemple de classeur structuré montrant qu’un classeur Moteur est en fait constitué d’un Allumage et de quatre Bougie.

Les classes découvertes au moment de l’analyse (celles qui figurent dans le diagramme de classes) ne sont parfois pas assez détaillées pour pouvoir être implémentées par des

développeurs. UML propose de partir des classeurs découverts au moment de l’analyse (tels que les classes, mais aussi les sous-systèmes, les cas d’utilisation, …) et de les décomposer en éléments suffisamment fins pour permettre leur implémentation. Les classeurs ainsi

décomposés s’appellent des classeurs structurés.

Un classeur structuré est donc la description de la structure d’implémentation interne d’une classe. Graphiquement, un classeur structuré se représente par un rectangle en trait plein comprenant deux compartiments. Le compartiment supérieur contient le nom du classeur et le compartiment inférieur montre les parties internes reliées par des connecteurs (cf. figure 7.1). Un classeur structuré possède des ports (cf. section 8.2.3), des parties et des connecteurs. Lorsque l’on crée l’instance d’un classeur structuré, on crée également une instance de ses ports, de ses parties et de ses connecteurs.

7.1.3 Collaboration

Une collaboration permet de décrire la mise en œuvre d’une fonctionnalité par un jeu de participants. Un rôle est la description d’un participant. Contrairement aux paquetages et aux classeurs structurés, une collaboration ne détient pas les instances liées à ses rôles. Les instances existent avant l’établissement d’une instance de la collaboration, mais la

collaboration les rassemble et précise des connecteurs entre elles. Une collaboration peut donc traverser plusieurs niveaux d’un système et un même élément peut apparaître dans plusieurs collaborations.

Par exemple, pour implémenter un cas d’utilisation, il faut utiliser un ensemble de classes, et d’autres éléments, fonctionnant ensemble pour réaliser le comportement de ce cas

d’utilisation. Cette ensemble d’éléments, comportant à la fois une structure statique et dynamique, est modélisé en UML par une collaboration.

Graphiquement, une collaboration se représente par une ellipse en trait pointillé comprenant deux compartiments. Le compartiment supérieur contient le nom de la collaboration et le compartiment inférieur montre les participants à la collaboration (cf. figure 7.2).

7.1.4 Interactions et lignes de vie

Figure 7.3: Diagramme de classe d’un système de pilotage.

Figure 7.5: Diagramme de séquence d’un système de pilotage.

Une interaction montre le comportement d’un classeur structuré ou d’une collaboration en se focalisant sur l’échange d’informations entre les éléments du classeur ou de la collaboration. Une interaction contient un jeu de ligne de vie. Chaque ligne de vie correspond à une partie interne d’un classeur ou d’une collaboration (i.e. un rôle dans le cas d’une collaboration). L’interaction décrit donc l’activité interne des éléments du classeur ou de la collaboration, appelés lignes de vie, par les messages qu’ils échangent.

UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme de communication et celui de séquence. Une même interaction peut être présentée aussi bien par l’un que par l’autre (cf. figure 7.4 et 7.5).

Remarque

A ces deux diagrammes, UML 2.0 en ajoute un troisième : le diagramme de timing. Son usage est limité à la modélisation des systèmes qui s’exécutent sous de fortes contraintes de temps, comme les systèmes temps réel.

7.1.5 Représentation générale

Un diagramme d’interaction se représente par un rectangle contenant, dans le coin supérieur gauche, un pentagone accompagné du mot-clef sd lorsqu’il s’agit d’un diagramme de

séquence (cf. figure 7.5) et com lorsqu’il s’agit d’un diagramme de communication (cf. figure 7.4). Le mot clé est suivi du nom de l’interaction. Dans le pentagone, on peut aussi faire suivre le nom par la liste des lignes de vie impliquées, précédée par le mot clé lifelines :. Enfin, des attributs peuvent être indiqués dans la partie supérieure du rectangle contenant le diagramme (cf. figure 7.11). La syntaxe de ces attributs est la même que celle des attributs d’un classe.

1

Doctrine ou point de vue qui consiste à considérer les phénomènes comme des totalités.