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.
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. »
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.
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
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.
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 !
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.
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.
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.
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.
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).
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 p M essage C (p ) M essage D M essage F
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.
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,
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.
4 Annexe :
Cas d Utilisation Téléphoner
Inclut Est inclus Etend Spécialise Généralise
Acteur principal Jules (appelant)
Acteur(s) secondaire(s)
Edouard (appelé)
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é)
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
