M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Du scénario au diagramme de séquence d objets

L'objet est une unité formée d'un état, constitué des valeurs instantanées de ses
attributs et d'un comportement.
Les attributs sont des valeurs qui sont associées aux objets (ex : couleur est un
attribut d'un objet voiture).
Le comportement regroupe les compétences de l'objet.
Ce comportement est décrit par ce que l'on appelle des opérations déclenchées
par des stimulations externes appelées messages.
Autrement dit, un objet joue un rôle dans un système.
Il est assuré au moyen de ses attributs ou de ses opérations.

1 Du cas d utilisation au diagramme de classe

Le diagramme de classes fera l objet d une étude détaillée ultérieurement.
Pour le moment, il s agit de comprendre le cheminement de modélisation qui conduit
des cas d utilisation au diagramme de classes.
Pour beaucoup d utilisateurs de diverses méthodes objet, les cas d utilisation
apparaissent comme anecdotiques.
On dessine des petits bonhommes. Et on ne voit pas très clairement où cela va
nous
conduire ! Autrement dit, on fait de l’OMT et puis on « ajoute » les cas d utilisation
Le choix de présentation qui est fait ici est délibéré.
Il consiste à montrer, et si possible à démontrer que la modélisation d’ un
système à objets s’effectue en observant la nature (statique) et le comportement
(dynamique) des objets qui y participent. Comment faire ?

1.1 Notion de scénario

Comme nous l avons déjà évoqué dans le précédent polycopié, un scénario
correspond à une séquence d événements « observables ». Ces événements
mettent en uvre des objets qui interagissent les uns avec les autres.
Un scénario n’est pas une construction intellectuelle. Il s’ agit de capter ce qui se
passe « ici et maintenant ».
Mettre en évidence des comportements, semble plus en conformité avec le concept
d'objet au sens dynamique, car c'est la dynamique qui est l'essence même d'un
système.

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Un cas d utilisation est constitué d un ensemble de scénarios. Il a un début et une fin

clairement identifiés.
Mais entre les deux, plusieurs parcours sont possibles.
Ce sont ces parcours qui constituent les différents scénarios possibles.

Figure 1: Cas d'Utilisation « Téléphoner » représentant une famille de scénarios

Les cas d'utilisation se déterminent en observant et en précisant, acteur par acteur,

les différents scénarios d'utilisation du système, étape par étape.
Une famille de scénarios, regroupée suivant un critère fonctionnel, forme un cas
d'utilisation

« Un scénario est un chemin particulier au travers de la description abstraite et

générale fournie par le cas d utilisation. Les scénarios traversent le cas
d utilisation, en suivant le chemin nominal ainsi que tout chemin alternatif et
exceptionnel. L explosion combinatoire fait qu il est bien souvent impossible de
dérouler tous les scénarios »

Pour décrire un cas d utilisation,

« il est primordial de trouver le bon niveau d’abstraction, c’ est à dire la quantité

de détails à mentionner, et de faire la distinction entre un cas d utilisation et un scénario.
Il n’ y a malheureusement pas de réponse toute faite, de sorte que l’appréciation
du niveau d’abstraction repose grandement sur l’expérience.
Les réponses apportées aux deux interrogations suivantes peuvent néanmoins
servir de gabarit : Est-il possible d’exécuter une activité donnée
indépendamment des autres, ou faut-il toujours l’enchaîner avec une autre
activité ? Deux activités qui s’enchaînent toujours font probablement partie du
même cas d’utilisation.
Est-il judicieux de regrouper certaines activités en vue de les décrire, de les
tester ou de les modifier ? Si oui, ces activités font sûrement partie du même cas
d utilisation. »

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Il n existe pas de normalisation officielle des scénarios. En général, ils sont

représentés par une liste numérotée d actions. Reprenons l exemple du scénario
d un appel téléphonique de Mr Jules vers son correspondant Mr Edouard

1. Mr Jules décroche son téléphone

2. Le téléphone de Mr Jules active la ligne du RTC
3. Le réseau envoie la tonalité
4. Mr Jules fait son numéro
5. Le numéro est transmis au réseau
6. Le réseau contrôle la validité du numéro
7. Le réseau recherche le correspondant
8. Le correspondant est trouvé
9. Le réseau fait sonner le téléphone de Mr Edouard
10. Mr Edouard décroche son téléphone
11. Sa ligne est activée
12. Une conversation est créée (objet temporaire)
13. Mr Jules raccroche
14. La ligne de Mr Jules est libérée
15. Mr Edouard raccroche
16. La ligne de Mr Edouard est libérée

Il est important d avoir toujours présent à l esprit qu un message correspond en

général à une sollicitation externe qui a pour objectif de déclencher une opération
auquel l objet receveur a accès. Il faut donc prendre l habitude de se placer du point
de vue du receveur. Ainsi, quand dans un scénario on écrit : Mr Jules décroche son
téléphone, on doit l interpréter de la façon suivante : Mr Jules envoie un message
à son téléphone pour lui demander d exécuter son opération « décrocher »

1.2 Interactions entre objets

Ce sont les diagrammes d'interactions qui mettent en évidence le comportement des
différents objets et permettent de délimiter leurs responsabilités. Le langage UML en
propose deux :

Le diagramme de séquence
Le diagramme de collaboration

Il est préférable de détecter progressivement les objets d un système au travers de

différents scénarios.
Ensuite seulement, on peut mettre en évidence que les scénarios sont des
réalisations particulières de Ca d'Utilisation et que le regroupement conceptuel d'objets
et leur abstraction vont permettre de définir une ébauche de diagramme de classes.
Il est de loin plus sécurisant de développer des scénarios et ensuite de regrouper
les objets dans des diagrammes de classes partiels, qui vont se compléter les uns
les autres, plutôt que de tenter d'obtenir le diagramme de classes directement et de
façon plus ou moins intuitive.

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

La modélisation des scénarios correspond à une vision réaliste du système.

Par ailleurs, les objets s'échangent des messages, pas les classes !
Autrement dit, d'un point de vue purement formel, il est naturel d'échanger des
messages entre objets dans des diagrammes d'interactions, qui sont justement
prévus pour cela.

Cette façon de procéder a pour avantage, d'une part de penser le système en terme
d'objets (et non plus en terme de classes, encore une fois, le système contient des
objets, pas des classes), d'autre part de s'en tenir aux objets réellement pertinents
pour les besoins.
Quels sont les objets du système qui collaborent au scénario ? Quels messages
échangent-ils ? Les diagrammes de collaboration permettent de dessiner les objets,
donc de les visualiser. A partir de là, il est plus facile de se poser des questions telles
que : quelle est la demande que tel objet envoie à tel autre pour participer au
scénario ? Cela suppose une idée générale des responsabilités de chacun des
objets. Rappelons que la responsabilité d un objet rassemble à la fois :

Qui il est, c'est-à-dire ce qui permet de le distinguer de tous les autres objets,
y compris de ceux qui lui sont semblables
Ce qu il sait, c'est-à-dire l ensemble de ses attributs instanciés, par exemple :
couleur = « bleu », poids = 275 g, etc
Ce qu il sait faire, c'est-à-dire l ensemble de ses opérations, par exemple :
Créer(), Détruire(), Décrocher(), Composer(numéro), etc .

2 Diagrammes de séquence d objets

Les diagrammes de séquences permettent de représenter des collaborations entre
objets selon un point de vue temporel, on met l'accent sur la chronologie des envois
de messages. Contrairement au diagramme de collaboration, on n'y décrit pas le
contexte ou l'état des objets, la représentation se concentre sur l'expression
des interactions.
Les diagrammes de séquences sont très utilisés pour illustrer les scénarios des
cas d’utilisation.

Dans un diagramme de séquence, un objet est représenté par une boîte contenant le
nom de l objet éventuellement suivi du nom de la classe à laquelle il appartient. Une
ligne verticale en pointillés représente la ligne de vie de l objet.

Figure 2 : Désignation d'un objet

Figure 3 : Un objet sans classe, une classe sans objet

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Un diagramme de séquence est défini par :

1. un axe vertical qui représente le temps. Par convention, le temps s écoule de

haut en bas et de gauche à droite.
2. un axe horizontal sur lequel sont représentés les objets. Un objet est indiqué
par un rectangle, auquel on attache une ligne en pointillé qui représente sa
ligne de vie. Cette ligne de vie sert de point de départ ou d arrivée à des
messages échangés entre objets.
3. Les messages sont représentés horizontalement par une ligne terminée par
une flèche, orientée de l émetteur du message vers le destinataire.

La représentation d’un délai de propagation significatif dans la transmission

d’un message est indiquée par le fait que la flèche correspondant au message
est oblique.

M r Jules: Le Télép hone de M r Jules:

Décrocher

Figure 4: Exemple d'interaction entre deux objets

Les périodes durant lesquelles l'objet est actif sont représentées sur l'axe des temps
par un rectangle, et portent le nom de périodes d'activation.
Attention, un objet peut être actif plusieurs fois au cours de son existence.
Cette période correspond simplement à la durée pendant laquelle l'objet "travaille",
pendant laquelle le code de cet objet est exécuté par le processeur si l'on est
dans le cas d'un programme informatique.

Figure 5 : Exemples de bandes d'activation

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Un même message peut déclencher des opérations différentes selon l'objet qui le
reçoit. C est la notion de polymorphisme.
Concernant la réponse à un message, un événement peut être associé à la
réception d'un message.
Si la réponse est instantanée il n'y a pas de message associé à la réponse.
Il existe différents types de messages.

Objet1: Objet2: Objet3:

M essage 1

M essage2

M essage 3

Figure 6: Un objet actif plusieurs fois

Les objets s'échangent des messages. L'axe des temps donne l'information sur la
chronologie, les délais, la simultanéité de l'envoi des messages. Les notations
concernant les messages sont identiques à celles pratiquées dans le diagramme de
collaboration.

2.1 Notion de message

Un message est un mécanisme par lequel un objet communique avec un autre.
Un message est supposé provoquer l'exécution d'une opération par l'objet
destinataire.
Il faut distinguer le message et l'opération.
Le message peut être assimilé à un appel, un stimulus extérieur qui provoque
l’exécution de l’opération.
UML distingue l opération (équivalent de la signature d une procédure ou d une
fonction) de la méthode qui correspond au code qui sera exécuté.
Par un glissement du sens lié à la pratique des certains langages de
programmation (Java), dans de nombreux ouvrages ou sites Internet, le terme de
méthode est utilisé pour faire référence à l’opération !

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

2.2 Les différents types de messages

2.2.1 Les messages d appel d opération

C est le type message le plus souvent utilisé. Selon les AGL, il est référencé
comme :

L invocation d une opération (Objecteering)

Un type « call » (Magic Draw)
Une ActionTypeCall (Visual Paradigm)

Dans chacun des ces cas, la typage du message en tant qu appel d une opération
n est réalisable qu à partir du moment où l objet considéré a préalablement été
déclaré comme appartenant à une classe.

Figure 7 : Différents formalismes des messages d'appel d'opérations

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Les messages d appel d opération peuvent transporter des valeurs par l intermédiaire
de paramètres. On distingue :

1. les paramètres d appel qui peuvent être nombreux et qui sont placés dans
les parenthèses ouvrantes et fermantes de l opération. Dans l exemple ci-dessus :

Message2(p)

2. le paramètre résultat pour lequel il existe deux formalismes de représentation,

dans l exemple de la figure ci-dessous :

Figure 8 : Les deux formalismes de représentation du paramètre de retour

2.2.2 Les messages de Création et de Destruction

Ils correspondent aux deux opérations de base auxquelles ont accès tous les objets.
Mais si tous les objets d un système peuvent êtres créés et détruits,ils ne se
positionnent pas de la même façon vis-à-vis de ces deux opérations fondamentales.
C est, en général, ce qui permet de distinguer les objets réputés « permanents » des
objets « temporaires ».
Bien sûr, à l échelle de l histoire de l univers, tous les objets peuvent être considérés
comme temporaires ! Dès lors, comment distinguer, les uns des autres ?
Ce sont les cas d utilisation qui nous apporteront une réponse.

Dans le contexte d un échange téléphonique entre deux personnes, les téléphones,

l ensemble des éléments composants le RTC sont appréhendés par les utilisateurs
(les acteurs) comme étant des objets permanents. En revanche, la conversation
téléphonique elle-même, si elle est matérialisée par un objet, celui-ci aura été créé à
l occasion de cet échange téléphonique et il sera détruit dès que l un des deux
interlocuteurs aura raccroché. Au regard du cas d utilisation cet objet aura été
appréhendé comme temporaire.

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Dans un diagramme de séquence, les objets créés se distinguent des objets

permanents par leur positionnement graphique. Ils ne figurent pas en haut du
diagramme, mais au niveau de l axe du temps correspondant au moment de leur
création.

Un objet:

Création
Un autre:

Figure 9: Un objet peut créer un autre objet puis le détruire

2.2.3 Les messages réflexifs

Ils représentent des messages qu un objet s envoie à lui-même. En général, cela est
représentatif que l on se trouve confronté à un objet composite. Dès lors deux
positions peuvent s envisager :

1. la nature de l étude conduit à ignorer la composition exacte de cet objet. C est

un choix délibéré de granularité qui amène l analyste à laisser à cet objet le
statut de « boîte noire », l étude du système se concentrant sur d autres
aspects.
2. à l inverse, les messages réflexifs mettent en évidence l existence d objets
composants que l on n a pas mis en évidence et qui apparaissent comme
indispensables à l étude. Ces messages mettent alors en évidence une
mauvaise granularité de l analyse qui devra alors être corrigée.

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Figure 10 : Exemple de messages réflexifs sur l objet composite « Le réseau »

Figure 11 : Un message réflexif est représentatif de l'activité d'un objet composite

2.2.4 Les messages conditionnels

Les envois de messages peuvent être conditionnels. L évaluation d un prédicat

déclenche l activation d une opération sur un objet ou d une autre opération sur un
autre.
Les messages conditionnels doivent être utilisés avec prudence.
En effet, un diagramme de séquence d’objets sert à illustrer un scénario.
Or il est assez rare qu’un scénario présente des cheminements alternatifs. En
revanche, une famille de scénarios, pourra comporter des alternatives.

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Mais en pareil cas, il faut être certain que l’on ne glisse pas insensiblement d’une
représentation des objets du système vers une représentation du comportement des
classes !
Objet 1: Objet 2: Objet 3:

[X] M essage

[non X] M essage

Figure 12 : Un envoi de message conditionnel

2.2.5 Le message récursif

On peut représenter des messages récursifs, en dédoublant la bande d'activation de

l'objet concerné.
Les structures de contrôles telles que les boucles ou les conditions peuvent aussi
être représentées.
Par exemple, pour représenter de manière graphique une exécution
conditionnelle d'un message, on peut documenter un diagramme de séquence
avec du pseudo-code et représenter des bandes d'activation conditionnelles.

Figure 13 : Exemple de message récursif

Avec les diagrammes de séquences on cherche à mettre en valeur les passages de

messages (déclenchant des événements) entre acteurs et objets (ou entre objets) en
les ordonnant dans le temps.
Un diagramme de séquences est un moyen semi-formel de capturer le
comportement de tous les objets et acteurs impliqués dans un scénario d un cas
d'utilisation.
On peut indiquer un type de message particulier : les retours de fonction signifient la
fin de l'appel de l'objet appelé. Ils permettent d'indiquer la libération de l'objet
appelant (ou de l'acteur).

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

On peut faire apparaître de nombreuses informations de contrôle le long de la ligne

de vie d'un objet. Deux notions, liées au contrôle des interactions s'avèrent utiles :

1. La condition qui indique quand un message doit être envoyé. Le message ne

sera transmis que si la condition est vérifiée. On indique les conditions entre
crochets au-dessus de l'arc du message ;
2. La façon de marquer la répétitivité d'un envoi de message. Par exemple, si l'on
doit répéter un appel pour toute une collection d'objets (pour tous les éléments de
la liste des demandes), on fera précéder le dénominateur du message par un
« * ».

La figure suivante illustre des exemples de messages.

Le message A est envoyé avec une itération symbolisée par *[i :=1..n].
Le message B1 signifie que l objet 2 va demander à l objet 3 une valeur qui
sera contenue dans le paramètre p.
Le message B2 correspond à la même action avec un formalisme différent.
Le message C est la figure inverse des précédents. Ici, c est l objet 2 qui
envoie la valeur p à l objet 1.
Enfin, le message D déclenche l activité de l objet 3 qui s envoie un message
à lui-même, c est un message récursif.

Objet 1: Objet 2: Objet 3:

*[i:=1..n] M essage A

p := M essage B1

M essage B2

M essage C (p )

M essage D
M essage F

Figure 14: Des exemples de messages

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Un diagramme de séquence permettra de valider que tous les acteurs du système,

les classes, les associations et les opérations ont bien été identifiés. Il constitue par
ailleurs une spécification utile pour le codage d'un algorithme ou la conception d'un
automate.

Figure 15 : Exemples de contraintes temporelles sur des messages

2.3 Synchronisation des messages

En plus de la représentation des messages selon l axe de l écoulement du temps, il
existe des possibilités de caractériser des synchronisations de messages entre eux.
Voici quelques exemples de messages liés à des synchronisations :

messageMinuté (timeout)
Bloque l'expéditeur pendant un temps donné (qui peut être spécifié dans une
contrainte), en attendant la prise en compte du message par le récepteur.
L'expéditeur est libéré si la prise en compte n'a pas eu lieu pendant le délai spécifié.

messageSynchrone()
Bloque l'expéditeur jusqu'à prise en compte du message par le destinataire. Le flot
de contrôle passe de l'émetteur au récepteur (l'émetteur devient passif et le
récepteur actif) à la prise en compte du message.

messageAsynchrone()
N'interrompt pas l'exécution de l'expéditeur. Le message envoyé peut être pris en
compte par le récepteur à tout moment ou ignoré (jamais traité).

messageDérobant()
N'interrompt pas l'exécution de l'expéditeur et ne déclenche une opération chez le
récepteur que s'il s'est préalablement mis en attente de ce message.

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Figure 16: Illustrations des différents types de messages synchronisés

UML permet également de spécifier de manière très précise l'ordre et les conditions
d'envoi des messages sur un diagramme dynamique.
Pour chaque message, il est possible d'indiquer :

les clauses qui conditionnent son envoi,

son rang (son numéro d'ordre par rapport aux autres messages),
sa récurrence,
ses arguments.

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

2.4 Des exemples de synchronisation de messages

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

Figure 17: Le diagramme de séquence correspondant au scénario de la page 3

3 Le diagramme de collaboration
Les diagrammes de collaboration montrent des interactions entre objets. Ils
permettent de représenter le contexte d'une interaction, car on peut y préciser les
états des objets qui interagissent. Ces diagrammes sont une extension des
diagrammes d'objet.
Un diagramme de collaboration ne représente pas le temps. Il faut numéroter les
messages échangés entre les objets afin de connaître l'ordre d'envoi. Ils peuvent
aussi représenter les acteurs des cas d'utilisation. Le diagramme de collaboration est
isomorphe au diagramme de séquence. Il met davantage l accent sur la
représentation spatiale des objets, alors que le diagramme de séquence met l accent
sur la représentation temporelle. Ce diagramme fera l objet d une présentation dans
un document spécifique.

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC 2006/2007

4 Annexe :

Cas d Utilisation Téléphoner

Inclut
Est inclus
Etend
Spécialise
Généralise

Acteur principal Jules (appelant)

Acteur(s) Edouard (appelé)
secondaire(s)

Pré condition(s) Les téléphones de jules et Edouard sont raccrochés

Scénario Jules appelle Edouard qui décroche

Description
1. Mr Jules décroche son téléphone
2. Le téléphone de Mr Jules active la ligne du RTC
(Réseau téléphonique commute)
3. Le réseau envoie la tonalité
4. Mr Jules fait son numéro
5. Le numéro est transmis au réseau
6. Le réseau contrôle la validité du numéro
7. Le réseau recherche le correspondant
8. Le correspondant est trouvé
9. Le réseau fait sonner le téléphone de Mr Edouard
10. Mr Edouard décroche son téléphone
11. Sa ligne est activée
12. Une conversation est créée (objet temporaire)
13. Mr Jules raccroche
14. La ligne de Mr Jules est libérée
15. Mr Edouard raccroche
16. La ligne de Mr Edouard est libérée

Exceptions Edouard absent ( un autre scénario doit être développé)

Post condition(s) Les téléphones de jules et Edouard sont raccrochés

Hamid Azzi
M09 SPECIFICATION FONCTIONNELLE D’UNE APPLICATION INFORMATIQUE TSDI1GC
2006/2007

Index du Texte :

1 Du cas d utilisation au diagramme de classe ....................................................... 1

1.1 Notion de scénario........................................................................................ 1
1.2 Interactions entre objets ............................................................................... 3
2 Diagrammes de séquence d objets...................................................................... 4
2.1 Notion de message....................................................................................... 7
2.2 Les différents types de messages ................................................................ 7
2.2.1 Les messages d appel d opération ........................................................ 7
2.2.2 Les messages de Création et de Destruction ....................................... 8
2.2.3 Les messages réflexifs .......................................................................... 9
2.2.4 Les messages conditionnels ............................................................... 10
2.2.5 Le message récursif ............................................................................ 11
2.3 Synchronisation des messages .................................................................. 13
2.4 Des exemples de synchronisation de messages ...................................... 15
3 Le diagramme de collaboration ......................................................................... 17
4 Annexe : ............................................................................................................ 18

Index des illustrations :

Figure 1: Cas d'Utilisation « Téléphoner » représentant une famille de scénarios...... 2

Figure 2 : Désignation d'un objet ................................................................................ 5
Figure 3 : Un objet sans classe, une classe sans objet .............................................. 5
Figure 4: Exemple d'interaction entre deux objets ...................................................... 5
Figure 5 : Exemples de bandes d'activation................................................................ 6
Figure 6: Un objet actif plusieurs fois .......................................................................... 6
Figure 7 : Différents formalismes des messages d'appel d'opérations ....................... 7
Figure 8 : Les deux formalismes de représentation du paramètre de retour...............
8
Figure 9: Un objet peut créer un autre objet puis le détruire ....................................... 9
Figure 10 : Exemple de messages réflexifs sur l objet composite « Le réseau » ...... 10
Figure 11 : Un message réflexif est représentatif de l'activité d'un objet composite . 10
Figure 12 : Un envoi de message conditionnel ......................................................... 11
Figure 13 : Exemple de message récursif................................................................. 11
Figure 14: Des exemples de messages .................................................................... 12
Figure 15 : Exemples de contraintes temporelles sur des messages .......................
13
Figure 16: Illustrations des différents types de messages synchronisés (uml.free.fr) 14
Figure 17: Le diagramme de séquence correspondant au scénario de la page 3 .. 17

Hamid Azzi