🖨️ Version PDF
But : Met en avant l’aspect temporel des interactions. Le temps s’incrémente du haut vers le bas de la figure, mais les espaces ne sont pas significatifs.
Seules les séquences d’événement sont représentées, non le temps qui les sépare.
Chaque objet concerné est représenté par une ligne verticale.
Les messages sont représentés par des lignes horizontales sur lesquelles on précise le type de message par un verbe.
Pour décrire textuellement un diagramme de séquence ou bien un diagramme de collaboration, il suffit d’écrire émetteur (acteur) / message / récepteur (acteur). Le diagramme de séquence prend en compte le TEMPS. Il nous suffit d’ordonner les opérations, voire de les numéroter.
Dans ce diagramme :
Notations complémentaires :
Les rectangles sur les barres verticales sont des blocs d’opérations qui montrent les périodes d’activité des objets. Les retours de messages ne sont indiqués que s’ils augmentent la compréhension du modèle.
Les stimuli inter-processus, ceux qui franchissent la frontière du système, sont plutôt appelés des signaux. Les autres stimuli intra-processus sont appelés les messages.
Pour info, le stéréotype “Boundary” signifie “Frontière” et est souvent utilisé pour représenter une UI dans les diagrammes.
Tous les objets ou acteur d’un sécénario ont une ligne de vie. Dans notre diagramme, Le Client(C) et le Serveur (S) existent depuis le début jusqu’à la fin.
Création d’objet :
Desctruction d’objet :
Les fragments structurent le scénario (c’est l’équivalent des boîtes en UML).
Remarque : suivant les versions de PlantUML certaines écritures ne fonctionnent pas, il faut vérifier dans la documentation.
par [texte facultatif] ...actions 1... and [texte facultatif] ...actions 2... end
Avec PlantUML, le mot “par” pour parallele fonctionne avec la version inférieure ou égale à 1.2024 et voici ci-dessous ce que donne la syntaxe :
@startuml participant S participant Repo participant Logs par Enregistrer S -> Repo : save() and Journaliser S -> Logs : audit() end @enduml
Autre écriture et rendu
@startuml participant S participant Repo participant Logs S --> Repo : save() # exécution non bloquante S --> Logs : audit() # envoi en parallèle @enduml
En Java, on pourrait imaginer que l’on utilise des Threads (processus)
But : Montrer qui parle à qui et dans quel ordre : Les messages sont numérotés pour un scénario plus précis. C’est une sorte de vue de réseau de conversations qui est complémentaire au diagramme de séquence (qui met plutôt l’accent sur la chronologie verticale).
Dans ce diagramme, les interactions sont représentées par des flèches et la chronologie par des numéros. Cette notation devient vite difficile à lire pour les cas d’utilisation qui nécessitent de nombreuses interactions. Par contre, elle met en évidence les acteurs dont le rôle est important.
les interactions sont représentées par des flèches et la chronologie par des numéros
Les acteurs sont représentés par des rectangles placés n’importe où dans le diagramme. `Chaque acteur émet et reçoit des messages comme dans le diagramme de Séquence vu précédemment.
Éléments clés :
<<boundary>>
<<control>>
<<entity>>
Voici un premier exemple basique :
Un autre exemple concernant le processus de Paiement :
Dans UML, l’élaboration de la liste des scénarios est une activité importante de l’analyse.
On peut proposer un début de démarche :
Un scénario est une série d’événements ordonnés dans le temps, simulant une exécution particulière du système.
Exemples de scénari :
Ce premier scénario décrit le recrutement d’un développeur en JavaEE par la société Objet SA qui s’adresse à France Travail.
Remarque : A priori on construit le scénario de base sans tenir compte des exceptions (erreurs, absence de réponse quand le temps prévu est dépassé).
Diagramme de collaboration (point de vue structurel) :
Il représente du point de vue statique et dynamique les objets impliqués dans la mise en place d’une fonction. Sa granularité est plus ou moins fine, selon qu’il décrit un ensemble d’opérations utilisées dans l’exécution d’une fonction ou une opération plus simple.
Deux notions fondamentales sont utilisées dans un diagramme de collaboration :
Le message 6 entre Oosoft et Dupont va générer un Nouveau contrat de travail (New ContratTravail).
Ce diagramme est souvent « chargé » en notation et parfois moins lisible que les scénari. Pourtant, s’il est peu utile durant la phase d’analyse, il le devient particulièrement lors de la phase de conception. car il permet de faire le lien entre le modèle objet et le modèle dynamique. Les méthodes (messages) y apparaissent entre les différents objets.
But : Modéliser un processus (flux de contrôle et/ou de données), avec des décisions, des boucles, des parallélismes et des partitions.
Ce sont des cas particuliers de diagramme d’état dans lesquels les états représentent des activités et les transitions des transitions automatiques.
Il sont plutôt rattachés à une opération ou un cas d’utilisation qu’à une classe. Utilisés pour décrire l’algorithmique d’une opération : séquences d’étapes avec représentation de décisions et de la synchronisation des flots de contrôles. Focalisés sur les traitements internes et non pas sur la réception d’événements externes.
Faire apparaître les Responsabilités dans le diagramme.
Un diagramme d’activité peut être divisé en couloirs verticaux assignant la responsabilité de certaines activités à des objets particuliers.
Exemple “Commander en ligne” avec rôle, parallélisme et décisions
Ou bien sous la forme d’un diagramme de séquence mais en numérotant les messages (méthodes)
Astuces utiles :
But : Décrire le cycle de vie d’un objet : états stables + événements + transitions avec gardes/actions.
Idéal pour Commande, Réservation, Ticket, Compte, …
Exemple de “Réservation de Vol” avec actions et gardes
Bonnes pratiques :
But : Montrer l’architecture logique d’un logiciel (modules, services, interfaces exposées/requises et leurs dépendances)
C’est la vue pour comprendre comment le code est organisé et interagit
Exemple pour afficher les composants d’une boutique en ligne
Quelques notations avec PlantUML :
Bonnes pratiques
Pense-Bête
But :Décrire la mise en œuvre physique : machines, conteneurs, réseaux, où tournent les composants et comment ils communiquent.
<<device>>
<<executionEnvironment>>
<<database>>
Exemple simple d’une boutique en ligne
@startuml skinparam linetype ortho object "Acteur" as A <<actor>> object "Boundary" as B <<boundary>> object "Contrôle" as C <<control>> object "Entité" as E <<entity>> A -[#1F4BF2]> B : 1: action() B -[#1F4BF2]> C : 2: traiter() C -[#1F4BF2]> E : 3: save() E -[#888,dashed]> C : 3.1: ok C -[#1F4BF2]> B : 4: confirmation() @enduml
@startuml start partition "Rôle A" { :Action A1; } partition "Rôle B" { if (Condition ?) then (Oui) :Action B1; else (Non) :Action B2; endif } stop @enduml
@startuml [*] --> Etat1 Etat1 --> Etat2 : evenement() [garde] / action Etat2 --> [*] @enduml
But : C’est une condition booléenne qui doit être vraie pour qu’un flux soit emprunté : message, transition d’état, flux d’activité, etc. C’est un filtre sans effet de bord (elle ne “fait” rien, elle décide juste oui/non)
Quand plusieurs chemins sont possibles, la garde dit lequel est autorisé dans ce contexte
Règles
Dans les diagrammes de Séquence : On les place sur les messages ou les fragments combinés
[panier.total > 0] et [panier.total == 0] dans le message :
[panier.total > 0]
[panier.total == 0]
@startuml actor Client participant "Service" as S Client -> S : [panier.total > 0] validerCommande() Client -> S : [panier.total == 0] refuser("vide") @enduml
Autre écriture possible sans les crochet (dans un fragment alt/opt/loop=) :
@startuml participant UI participant S alt Panier vide S --> UI : Afficher "Panier vide" else Panier non vide S --> UI : Afficher paiement end @enduml
En UML, la garde est le petit texte dans l’en-tête du fragment (“Panier vide”) On peut aussi écrire la condition exacte entre crochets sur le message comme dans l’exemple précédent.
Erreurs fréquentes
Avec PlantUML :