SlideShare une entreprise Scribd logo
Impossible d’afficher l’image.
Impossible d’afficher l’image.
MODÉLISATION DYNAMIQUE
1
ASPECTS DYNAMIQUES DU SYSTÈME
 Jusqu’ici, le système a été décrit statiquement:
 Le diagramme de classes
 Décrit les messages (méthodes ou opérations) que les instances des classes
peuvent recevoir mais ne décrit pas l’émission de ces messages
 Ne montre pas le lien entre ces échanges de messages et les processus
généraux que l’application doit réaliser
 Il faut maintenant décrire comment le système évolue dans le
temps
2
Impossible d’afficher l’image.
Impossible d’afficher l’image.
Modélisation dynamique
Objectifs
 Introduire les diagrammes
d’interaction
 Introduire les diagrammes de
comportement
3
DIAGRAMMES D'INTERACTIONS
 Les diagrammes de séquences et les diagrammes de
communication (ou collaboration) d’instances sont deux types de
diagrammes d'interaction. Les diagrammes d'interaction
représentent une interaction, c'est-à-dire un ensemble d’objets
et leurs relations, y compris les messages qu'ils peuvent
échanger. Ils présentent une vue dynamique d’un système.
 Cas particulier : diagrammes de séquences système : interaction entre
acteurs et système
 Les diagrammes de séquence sont des diagrammes d'interaction
qui mettent l'accent sur le classement chronologique des
messages alors que les diagrammes de communication
d’instances sont des diagrammes d'interaction qui mettent
l'accent sur l'organisation spatiale des éléments qui envoient et
reçoivent des messages.
 Les diagrammes de séquence et les diagrammes de
communication d’instances sont isomorphes, c'est-à-dire que
l'un peut être transformé en l'autre.
4
DIAGRAMME D’INTÉRACTIONS
Modèle conceptuel
(Analyse dynamique)
Description de
l’interaction moyennant
les objets (de l’analyse)
du système
Diagramme
d’Interaction
Modèle logique (Conception
dynamique)
Description de l’interaction moyennant
les objets (de la conception) du système
Diagramme
d’interaction
Diagramme
d’interaction
Expression des
Besoins (Cas d’utilisation)
Description de l’interaction
du système avec les acteurs
extérieurs
5
DIAGRAMMES DE SÉQUENCES
 Dérivés des scénarios de OMT :
 Montrent des exemples de coopération entre objets dans la réalisation
de processus de l’application
 Illustrent la dynamique d’enchaînement des traitements à travers les
messages échangés entre objets
 le temps est représenté comme une dimension explicite
(en général de haut en bas)
 Les éléments constitutifs d’un scénario sont :
 Un ensemble d’objets (et/ou d’acteurs)
 Un message initiateur du scénario
 La chronologie des messages échangés subséquemment
 Les contraintes de temps (aspects temps réel)
6
PRÉSENTATION
 Diagramme de séquence:
 Montre la séquence dans le temps des interactions entre les objets du
système au sein d’un scénario.
 Objet passif : activation dépend d’un fil externe
 Objet actif : possède son propre fil d’exécution
 Un diagramme de séquence a deux dimensions:
 dimension verticale: le temps;
L'ordre d'envoi d'un message est déterminé par sa position sur l'axe
vertical du diagramme ; le temps s'écoule "de haut en bas" de cet axe.
 dimension horizontale: les objets (et les acteurs)
L’ordre de disposition des objets sur l'axe horizontal est sans importance.
:c1 :c5 :c3 objets
temps
7
SYNTAXE GRAPHIQUE
 Objets et messages
Nom Objet1:NomClasse1
Nom Objet:NomClasse
Objets = Instances de classes
nom message (paramètres)
Message nom message
émis par Nom Objet
vers Nom Objet1
Temps
8
LIGNE DE VIE ET ACTIVATION
La «ligne de vie» représente l’existence de
l’objet à un instant particulier
 Commence avec la création de l’objet
 Se termine avec la destruction de l’objet
L’activation est la période durant laquelle
l’objet exécute une action lui-même ou via
une autre procédure
9
NOTATION
objet1:Classe1
objet2:Classe2
objet3:Classe3
Client
op ( )
m1 ( )
m2 ( )
m3 ( )
Objet créé dans le scénario
Activité de l’objet
Objet existant avant et après l’activation du scénario
Ligne de vie
10
MESSAGES SIMPLES
 Communication entre objets
 Des paramètres
 Un retour
 Cas particuliers
 La récursivité
 Les messages entraînant la construction d’un objet
 Les destructions d’objets
11
MESSAGES SYNCHRONE VS
ASYNCHRONE
 message synchrone
Suite à l’envoi de son message, l’expéditeur (objet passif ou actif)
perd le contrôle mais demeure en activation (invocation
d’opération). Il demeure bloqué jusqu’à ce que le destinataire ait
fini de traiter le message. Il retrouve ensuite le contrôle avec la
réponse à son message (pouvant être représenté par une flèche
pointillée).
 message simple
L’expéditeur envoie un message au destinataire sans attendre de réponse :
(signal).
 Si l’expéditeur est un objet passif: l’expéditeur perd le contrôle et termine
son activation après l’envoi du message
 Si l’expéditeur est un objet actif: l’envoi d’un message simple équivaut à
l’envoi d’un message asynchrone.
12
 Un objet actif initie et contrôle le flux d’activités.
Graphiquement, la ligne pointillée verticale d’un objet actif est
remplacée par un double trait vertical
 Représentation d’un objet actif (à gauche) et d’une exécution sur
un objet passif (à droite):
CATÉGORIE DE MESSAGES
13
MODE D’INTERACTION PROCÉDURAL
(I.E. SYNCHRONE)
 Au plus un objet détient le contrôle à la fois.
 Un objet obtient le contrôle quand il reçoit un message
(i.e. on invoque une de ses méthodes). Ce moment
détermine le début de son activation.
 Un objet rend le contrôle à son destinateur lorsqu’il lui
renvoie sa réponse. Ce moment détermine la fin de son
activation.
 Lorsqu’un objet en activation a le contrôle, il peut
 faire des calculs,
 ou envoyer des messages: dans ce cas, l’objet demeure en
activation mais cède à son tour le contrôle à son destinataire. Il
ne peut rien faire jusqu’à ce qu’il reçoive la réponse de son
destinataire (message synchrone ou dit « bloquant »).
14
 Les objets sont dits « passif », car on doit leur envoyer un message
pour déclencher leur activation.
 Un seul fil d’exécution.
 Dans ce mode, seul un acteur peut envoyer un message ou faire des
calculs sans l’intervention de qui que ce soit. Son activation est
constante…
 L’identité des objets en activation est gérée dans une pile:
 Dessus de la pile = objet en activation qui possède le contrôle
 On empile l’identité d’un objet qui débute une activation.
 On dépile l’identité d’un objet qui termine une activation.
 Les messages sont numérotés de façon à refléter
l’imbrication des envois de messages.
 Le message 2.2 est envoyé après que la réponse au message 2.1 ait été reçue
 Il faut attendre la réponse au message 2.2.3 avant de pouvoir répondre au
message 2.2.
MODE D’INTERACTION PROCÉDURAL
15
EXEMPLE :
MODE D’INTERACTION PROCÉDURAL
mb
:MembreBiblio
exemplaire
:Exemplaire
leLivre:Livre
unMembre
:EmprunteurDeLivre
emprunter(exemplaire)
1:okPourEmprunter
2:emprunter
2.1:estEmprunté
activation
message
ligne de
vie
message
réflexif
AUTRES NOTATIONS POUR DES
INTERACTIONS AVANCÉES
On peut alors avoir besoin de:
 Interactions concurrentes
 Conditions (gardes) sur les messages:
 Ligne de vie à branches multiples.
 Itérations
 Contraintes temporelles (temps réel)
17
MODE D’INTERACTION CONCURRENT
(I.E. ASYNCHRONE)
 Certains objets disposent d’un propre fil d’exécution. Il ont
leur propre contrôle et leur activation est constante. Ces
objets sont dits « actifs », car il peuvent faire des calculs et
envoyer des messages sans l’intervention de qui que ce soit.
 Les objets actifs peuvent envoyer deux types de messages
 synchrones: ils attendent la réponse de leur destinataire avant de
poursuivre…
 asynchrones: ils poursuivent leurs activités sans attendre la réponse à
leur message… Celle-ci leur sera signalée.
N.b. En mode procédural, tous les messages sont synchrones…
18
MODE D’INTERACTION CONCURRENT
Il existe différente façon de créer de nouveaux fils de contrôle
(threads)
1. À la réception d’un message, un objet peut découpler le
fil d’exécution en envoyant plusieurs messages
simultanément (fork).
o:Obj
1.a: foo()
1.b: bar()
Branchement: Lorsque les
messages n’ont pas de
garde mutuellement
exclusive, on en déduit
qu’ils sont concurrents.
MODE D’INTERACTION CONCURRENT
2. Un acteur peut spontanément décider d’envoyer un message et crée
ainsi un nouveau fil d’exécution.
3. Un objet actif peut également découpler le fil d’exécution en envoyant
un message asynchrone.
• L’objet continue sans attendre le message de retour.
• Il octroie ainsi un fil d’exécution indépendant à l’objet
destinataire.
o1:Obj
1: foo()
2:bar()
o2:Obj
EXEMPLES DE SCÉNARIOS
 Appel téléphonique
 Scénario : le numéro appelé est occupé
 L'appelant décroche le téléphone
 L'appelant commence à composer le numéro
 L'appelant termine de composer le numéro
 La tonalité "occupée" commence à sonner
 L'appelant raccroche le téléphone
 Scénario : le numéro appelé n'est pas occupé
 L'appelant décroche le téléphone
 L'appelant commence à taper le numéro
 L'appelant termine de taper le numéro
 Le téléphone commence à sonner
 L'appelé décroche
 La conversation se déroule
 L'appelé raccroche le téléphone
21
EXEMPLE
MODE D’INTERACTION CONCURRENT (ASYNCHRONE)
appelant
centrale
téléphonique
appelé
1: décrocher()
2: envoyer_signal()
3: composer_numéro()
4: chercher_destinataire()
5B: activer_sonnerie()
5A: entendre_sonnerie()
6: décrocher()
7B: arrêter_sonnerie()
7A: arrêter_signal_sonnerie()
22
MESSAGES AVEC GARDE
o:Obj
1.a: [i=0] foo()
1.b: [i=1] bar()
o:Obj
1.1: [i=0] foo()
1.2: [i=1] bar()
Différence??
• Permet d’exprimer les alternatives de comportement.
• Message envoyé seulement si la garde est vraie.
• Les gardes doivent être mutuellement exclusives pour signifier
que l’envoi est conditionnel (et non concurrent).
LIGNE DE VIE À BRANCHES MULTIPLES
• Si deux messages, dont l’envoi est conditionnel à l’évaluation
d’une garde, sont destinés à un même objet, on doit pouvoir
exprimer le comportement de l’objet dans chaque cas…
o1:Obj1
3.1.a: [i=0] foo()
3.1.b: [i=1] bar()
o2:Obj2
EXEMPLE :REPRÉSENTATION DE
CONDITIONNELLES
objet1:Classe1
op ( )
objet2:Classe2
[x<0] m1 ( x )
[x>0] m2 ( x )
Branchement conditionnel
Branchement conditionnel
25
ITÉRATION
• On ajoute une clause d’itération (introduite par un *) à côté du
message pour spécifier le nombre d’itérations ou l’invariant de
l’itération:
Exemples:
*[i:=1..10] Le message est envoyé 10 fois
*[x<10] Le message est envoyé de façon répétée
jusqu’à ce que x soit plus grand ou égal à 10.
*[item not found] Le message est envoyée de façon répétée
jusqu’à ce que l’item soit trouvé….
Ne pas répéter la clause d’itération chez le destinataire (elle est
implicite)… à moins de vouloir une boucle imbriquée.
EXEMPLE :
Itération
a:ObjA
3.1:*[i:=1..2] a()
3.1.1: b()
b:ObjB c:ObjC
AUTRE REPRÉSENTATION: FRAGMENTS
D’INTERACTION
LES FRAGMENTS D’INTERACTION
 Un fragment combiné représente des articulations d'interactions.
Il est défini par un opérateur et des opérandes. L'opérateur
conditionne la signification du fragment combiné. Les fragments
combinés peuvent faire intervenir l'ensemble des entités
participant au scénario ou juste un sous-ensemble.
 Les principaux opérateurs en UML 2 :
 Opérateur "Alternative"
 Opérateur "Option"
 Opérateur "Break"
 Opérateur "Parallel"
 Opérateur "Loop"
29
 L'opérateur "alt" désigne un choix, une alternative. Il
représente des comportements possibles : c'est en quelque
sorte l'équivalent du SI...ALORS...SINON : donc, une seule
des branches alternatives sera réalisée dans un scénario
donné.
 La condition d'exécution d'une des branches alternatives
(l'équivalent du SI) peut être explicite ou implicite.
 L'utilisation de l'opérateur else permet d'indiquer que la
branche est exécutée si la condition du alt est fausse.
Les fragments combinés
2. Le diagramme de séquence système
Les fragments d’interaction
30
L'exemple ici montre un
opérateur "alt" : - soit
l'utilisateur rentre un code
correct et dans ce cas le
diagramme de séquence relatif
à la vérification du code est
appelé, - soit l'utilisateur rentre
un code erroné, trois fois, et sa
carte est gardée.
a) Les fragments combinés
2. Le diagramme de séquence système
Les fragments d’interaction
31
2. Le diagramme de séquence système a) Les fragments combinés
L'opérateur "opt" désigne un
fragment combiné optionnel
comme son nom l'indique : c'est
à dire qu'il représente un
comportement qui peut se
produire... ou pas. Un fragment
optionnel est équivalent à un
fragment "alt" qui ne posséderait
pas d'opérande else (qui n'aurait
qu'une seule branche).
L'exemple ici montre un
opérateur "opt" : L'utilisateur, si
il est mécontent, peut se défouler
sur le distributeur de billets.
Les fragments d’interaction
32
L'opérateur "break" est utilisé pour représenter des scenarii d'exception. Les
interactions de ce fragment seront exécutées à la place des interactions
décrites en dessous. Il y a donc une notion d'interruption du flot "normal"
des interactions.
Les fragments combinés
2. Le diagramme de séquence système
L'exemple ici montre un
opérateur "break" :
L'utilisateur, lorsque le
distributeur lui
demande son code,
peut choisir de rentrer
son code ou de
consulter l'aide. S’il
choisit de consulter
l'aide, le flot
d'interaction relatif à la
saisie du code est
interrompu.
Les fragments d’interaction
33
 L'équivalent de ce diagramme de séquence sans l'opérateur
break correspond aux deux diagrammes de séquence suivants :
Les fragments combinés
2. Le diagramme de séquence système
Les fragments d’interaction
34
L'exemple ici montre
qu’un développeur
ayant accès à Internet
peut consulter en
parallèle, soit le site
http://www.developpez.
com soit le site
http://www.developpez.
net/forums/ sans
préférence d’ordre.
L'opérateur "par" est utilisé pour représenter des interactions ayant lieu
en parallèle. Les interactions des différents opérandes peuvent se mélanger,
s'intercaler, dans la mesure où l'ordre imposé dans chaque opérande est
respecté.
Les fragments combinés
2. Le diagramme de séquence système
Les fragments d’interaction
35
L'opérateur "Loop" (boucle) est
utilisé pour décrire un ensemble
d'interaction qui s'exécutent en
boucle. En général, une
contrainte appelée garde indique
le nombre de répétitions
(minimum et maximum) ou bien
une condition booléenne à
respecter.
L'exemple ici montre un exemple
pour l'opérateur "loop" : Le
diagramme de séquence indique
que lorsque l'utilisateur se
trompe trois fois de code, la carte
est gardée et le distributeur se
remet en mode d'attente d'une
carte.
Les fragments combinés
2. Le diagramme de séquence système
Les fragments d’interaction
36
 Une référence (interaction occurrence) peut être vue comme
un pointeur ou un raccourci vers un autre diagramme de
séquence existant.
 Cela équivaut à copier le contenu du diagramme de séquence
pointé en lieu et place de la référence.
 Cela permet de factoriser des parties de comportement
utilisées dans plusieurs scénario.
Les références
2. Le diagramme de séquence système
Les fragments d’interaction
37
Cas d'utilisation principal : Jouer une partie de démineur
 Dans la boucle (loop) de jeu, il y a trois possibilités (alt) :
perte, gain ou cas normal. Les cas de perte ou de gain
arrêtent la partie (break). Sinon, le joueur passe son temps à
découvrir ou (alt) marquer des cases.
 Ensuite, le joueur pourra (opt) entrer son nom dans les
meilleurs scores si ([]) il a le meilleur temps en fonction du
niveau choisi.
 On peut ajouter la configuration du jeu comme étape
optionnelle (opt) avant de commencer à jouer.
Exemple
2. Le diagramme de séquence système
Les fragments d’interaction
38
Exemple
Section 3
Les diagrammes
comportementaux
Chapitre 2
Les diagrammes d’analyse
2. Le diagramme de séquence système
39
CONTRAINTES TEMPORELLES
 Lecture du scénario et chronologie
 Un scénario se lit de haut en bas dans le sens chronologique d’échange
des messages.
 Des contraintes temporelles peuvent être ajoutées au scénario
:Nom classe2
Nom Objet1:
demande
réponse
a
b
{b-a< 5 sec.}
:Nom classe2
Nom Objet1:
demande
d
d’
{d’-d< 1 sec.}
40
Le diagramme de séquence système
 Le diagramme de séquence système (DSS) décrit les
interactions entre les acteurs et le système selon un point de
vue temporel (l'accent est mis sur la chronologie des
envois/réceptions de messages entre les acteurs et le
système).
 Le DSS permet la description de la dynamique du système
vu de l'extérieur où le système est vu comme une « boîte
noire ».
 Le système est donc vu de l'extérieur (par les acteurs) sans
préjuger de comment il sera réalisé. La « boîte noire » sera
ouverte (décrite) seulement en conception. 41
2. Le diagramme de séquence système
 Le DSS est typiquement utilisé pour représenter le
fonctionnement d'un cas d'utilisation sous la forme d’une
séquence de messages échangés entre les acteurs et le
système. Il représente la synthèse des scénarios liés aux cas
d'utilisation.
 Un scénario : une suite spécifique d'événements
(d'actions et d'interactions) entre les acteurs et le
système (les DSS sont toujours lus du haut vers le bas,
pour illustrer l'ordre dans lequel les messages sont
envoyés entre les acteurs et le système).
Le diagramme de séquence système
42
2. Le diagramme de séquence système
système
acteur
E1
E2
R1
Acteurs/Système
Messages
(asynchrone ou
synchrone)
Ligne de vie
Barre d’activation
commentaire
Les principaux concepts
Le diagramme de séquence système
43
Le bibliothécaire souhaite enregistrer un nouvel ouvrage
dans le système de gestion de l’inventaire de la bibliothèque.
Pour cela, il fournit au système le nom de l’auteur et le titre
de l’ouvrage.
Le bibliothécaire sélectionne ensuite le type d’ouvrage à
enregistrer. Le système lui retourne la liste des ouvrages de
ce type qui ont été écrit par cet auteur et qui sont déjà
enregistrés dans le système.
Le bibliothécaire insère une description complète de
l’ouvrage. Le système retourne l’ensemble de la description
sous un format de lecture et confirme l’enregistrement du
nouvel ouvrage.
2. Le diagramme de séquence système Exemple
Le diagramme de séquence système
44
2. Le diagramme de séquence système Exemple
Le diagramme de séquence système
45
DIAGRAMME D’ÉTATS-TRANSITIONS
 But: Permet de décrire le comportement d’un objet (instance
d’une classe) en fonction événements et des messages reçus.
Disponible
Verrouillé
Vendu
attribué_sur_abonnement
achète
verrouiller
déverrouiller
délai écoulé
Diagramme d’état d’un billet de spectacle à vendre sur Internet
46
PRINCIPAUX CONCEPTS
 État
 Transition
 Marqueur d’état initial
Nom_état
événement / action
47
PRINCIPAUX CONCEPTS
TRANSITION
 Une transition (sortante) définit la réponse d’un objet, dans un état
donné, à un événement donné.
 Les transitions sont étiquetées par un événement et
(optionnellement) par une action :
 Événement: Tout ce qui survient et peut affecter un objet. Élément
déclencheur de la transition.
 Action: Opération réalisée lorsqu’une transition est tirée.
Emprunté Sur les rayons
emprunter() / livre.emprunté(self)
retourner() / livre.retourné(self)
Diagramme d’état pour la classe Exemplaire_de_livre
événement / action
PRINCIPAUX CONCEPTS
ÉTAT
 Décrit un moment pendant la vie d’un objet.
 Un objet ne se trouve que dans un seul état à la fois.
 Tous les objets d’une classe qui se trouvent dans un même état
réagissent de façon identique aux événements.
 Les objets qui se trouvent dans un état donné, à un moment donné,
partagent l’une et/ou l’autre des caractéristiques suivantes
 Ils ont des valeurs d’attributs similaires.
 Ils attendent un événement particulier.
 Il exécutent une activité particulière.
 Un état est généralement décrit par un nom.
 En UML, il existe différents types d’état: simple, concurrent,
composite, etc.
Nom_état
COMMENT TROUVER LES ÉTATS
SIGNIFICATIFS D’UN OBJET
Principaux concepts
Transition
Principaux concepts
Transition
EVÈNEMENT
PRINCIPAUX CONCEPTS
TYPES D’ÉVÉNEMENTS
Un événement peut être paramétré…
Type
d’événement
Description Syntaxe
Appel Réception d’un message synchrone (pour
lequel l’émetteur attend une réponse).
Invocation d’une opération.
op(p1:type,
p2:type, …)
Changement Changement de valeur d’une condition
booléenne. Satisfaction soudaine de cette
condition. Condition fausse qui devient vraie.
when(exp)
Signal Réception d’un message asynchrone. sname(p1:typ
e, p2:type, …)
Temps Temps absolu atteint ou passage d’un certain
intervalle de temps. Peut signaler le temps
écoulé depuis l’entrée dans un état donné.
after(time)
54
GARDE
GARDES
 Une transition peut être conditionnelle à l’évaluation d’une
garde.
 Si la garde est vraie, la transition est tirée.
 Si la garde est fausse, la transition n’a pas lieu.
 Notation: événement [garde]
Ne peut être
emprunté
Peut être
emprunté
est_emprunté(e) [dernier exemplaire]
est_retourné(e)
est_retourné(e)
est_emprunté(e) [pas dernier exemplaire]
Diagramme d’état d’un livre
Cette transition est
importante pour marquer
que retourner() est bel et
bien un message attendu et
compris par cet automate
dans cet état.
56
GARDES
 Garde
 expression conditionnelle
 évaluée uniquement quand l’événement est déclenché
 peut contenir des attributs de l’objet ou des paramètres de
l’événement associé
 Lorsqu’un même événement est associé à plusieurs transitions,
une garde (condition) peut être ajoutée pour préciser le contexte
et déterminer la transition à effectuer.
 Les gardes associées à un même événement sur les transitions
sortantes d’un état donné, doivent être mutuellement exclusives.
57
ACTION
PRINCIPAUX CONCEPTS
TYPES D’ACTIONS
Les actions peuvent prendre des arguments… les paramètres effectifs
des événements par exemple…
Type
d’action
Description Syntaxe
Affectation Assigne une valeur à une variable. target:=expression
Appel Invocation (synchrone) d’une opération d’un
objet. Peut retourner une valeur.
opname(arg1, arg2, …)
object.opname(arg1, arg2,
…)
Envoi Envoi d’un message (signal) asynchrone. sname(arg1, arg2, …)
Création Création d’un nouvel objet. new Cname(arg1, arg2, …)
Destruction Destruction d’un objet. object.destroy ()
Retour Spécification d’une valeur retournée. return value
Divers Action décrite dans un autre langage… [ description ]
Séquence Séquence d’action action1; action2; …
59
TRANSITION RÉFLEXIVE SUR UN ÉTAT
60
ACTIONS D’UN ÉTAT
61
ACTIONS D’UN ÉTAT
62
ACTIONS D’ENTRÉE ET DE SORTIE
Certaines actions peuvent être rattachées à un état au lieu d’une
transition
 Action d’entrée: Action exécutée chaque fois qu’on entre dans
l’état (quelle que soit la transition qui nous y amène…).
 Notation: entry /action
 Action de sortie: Action exécutée chaque fois qu’on sort de l’état
(quelle que soit la transition qui nous en fait sortir).
 Notation: exit/action
Emprunté
exit/livre.retourné(self)
Sur les rayons
exit/livre.emprunté(self)
emprunter()
retourner()
Diagramme d’état d’un exemplaire de livre
Ordre d’exécution
des actions ?
63
ACTIVITÉ D’UN ÉTAT
64
EXEMPLE
65
TYPES DE TRANSITIONS
 Transition externe: transition standard qui engendre un
changement d’état et toutes les actions correspondantes (actions
d’entrée et de sortie, ainsi que celles de la transition).
 Transition interne: transition qui n’engendre pas de changement
d’état et ne déclenche que les actions associées à cette transition
(pas les actions d’entrée et de sortie)
 Transition de complétion: transition qui n’est pas activée par un
événement. La transition est tirée dès que l’activité, de l’état
qu’elle quitte, se termine. Souvent munie d’une garde.
Saisie mot de passe
entry/ set echo to star; password.reset()
exit/ set echo normal
digit / handle character
help / display help()
clear
Transitions
internes
Transition externe
66
TRANSITION DE COMPLÉTION (TRANSITION
AUTOMATIQUE)
67
ETAT COMPOSITE
68
ÉTAT COMPOSITE
État « spécialisé » composé de plusieurs sous - états.
 Sous - états séquentiels
 Sous - états concurrents
69
ÉTAT COMPOSITE
(SÉQUENTIEL OU CONCURRENT)
 Lorsqu’un état composite est activé, un de ses sous -
états est nécessairement activé.
 Entrer et sortir d’un état composite
 Une transition entrant dans un état composite est implicitement
conduite vers son état initial.
 Une transition vers l’état final d’un état composite active
implicitement une transition de complétion sortant de l’état
composite.
 Lorsqu’une transition entre/sort en traversant un ou
plusieurs états composites imbriqués, toutes les actions
d’entrées/sortie sont exécutées
 Actions d’entrées… de l’état le plus externe en premier.
 Actions de sortie … de l’état le plus interne en premier.
70
SOUS-ÉTATS SÉQUENTIELS
71
ÉTAT COMPOSITE (SÉQUENTIEL) - EXEMPLE
Identification
Sélection
choisir(siège) /
ajouter_à_sélection(siège)
Confirmation
Vente
Entry / vendre()
[identification_réussie]/
Initialiser_sélection()
clic_acheter
clic_recommencer
clic_confirmer
[identification_échouée]
Achat d’un billet
Exit / éjecter_carte()
inactif
insérer_carte
clic_annuler
À remarquer
•Transition interne
•Transitions de complétion
•État intial
•État final
72
SOUS-ÉTATS CONCURRENTS
73
ÉTAT COMPOSITE (CONCURRENT)
EXEMPLE
Labo 1
Projet de
semestre
Examen
final
lab_terminé
[note >= 60]
Cours non terminé
Labo 2
lab_terminé
projet_terminé
réussite
Cours
réussi
Cours
échoué
échec
[note < 60]
Diagramme d’état d’un cours
74
ÉTAT COMPOSITE (CONCURRENT)
EXEMPLE
Autre notation possible
Labo 1
Projet de
semestre
Examen
final
lab_terminé [note >= 60]
Cours non terminé
Labo 2 lab_terminé
projet_terminé
réussite
Cours
réussi
Cours
échoué
échec
[note < 60]
Diagramme d’état d’un cours
fork join
75
TRANSITIONS ENTRE ETATS COMPOSITES
76
RÉFÉRENCE SUR UN
SOUS-DIAGRAMME D’ÉTAT
Attendre
commande
commande
d’aide
Include Run Include Help
commande
d’exécution
entry / afficher écran d’aide
exit / effacer écran d’aide
question /
show réponse
Help
quitter
77
Utilité
 Utilisé pour décrire les séquences d’activités
composant
 un processus d’affaires, système de production, etc. (modèle
d’affaires)
 un cas d’utilisation (modèle d’analyse)
 un algorithme particulier (modèle de conception)
 Permet de décrire les activités d’un cas d’utilisation en
restant à un haut niveau d’abstraction.
 Permet d’exprimer des flots de contrôle séquentiels et
concurrents.
DIAGRAMME D’ACTIVITÉS
78
Particularités
 Forme particulière de diagramme d’états où
 Les états sont remplacés par des activités.
 On ne s’intéresse pas aux états d’un objet, mais plutôt aux états d’un calcul
ou d’une tâche complexe à accomplir. En fait, ce ne sont pas des états mais
des activités.
 Les transitions sont automatiquement déclenchées par la
complétion d’une activité.
 Le passage d’une activité à l’autre se fait automatiquement lorsqu’une
activité est terminée. Une activité (contrairement à un état) n’attend pas
l’occurrence d’un événement pour effectuer une transition. On passe à la
prochaine activité dès que la précédente (dans le diagramme) est terminée.
79
DIAGRAMME D’ACTIVITÉS
UML permet de représenter graphiquement le comportement
d'une méthode ou le déroulement d'un cas d'utilisation, à l'aide
de diagrammes d'activités (une variante des diagrammes d'états-
transitions).
 Une activité représente une exécution d'un mécanisme, un déroulement
d'étapes séquentielles.
 Le passage d'une activité vers une autre est matérialisé par une transition.
Remarque :
 En théorie, tous les mécanismes dynamiques pourraient être
décrits par un diagramme d'activités, mais seuls les
mécanismes complexes ou intéressants méritent d'être
représentés.
 Le diagramme d’activités est le plus approprié pour modéliser
la dynamique d’une tâche, d’un use case lorsque le
diagramme de classes n’est pas encore stabilisé.
80
PRINCIPAUX ÉLÉMENTS DE NOTATION
Activité
Transition
Marqueur d’état initial
Barre de synchronisation
Branchement
Condition [ cond ]
nom_activité
81
NOTION DU DIAGRAMME D’ACTIVITÉS
Diagramme d’activité =
 ensemble d’activités liés par:
 Transition (sequentielle)
 Transitions alternatives (conditionnelle)
 Synchronisation (disjonction et
conjonctions d’activités)
 Itération
 + 2 états: état de départ et état de
terminaison
 Swimlanes: represente le lieu, le
responsable des activités.
Activité
Autre Activité
82
CONDITIONNELLE
•Etat de départ
•Etat de terminaison
•Transition
•Transition
Alternative
[ ] [ ]
Mesurer la température
Chauffer Refroidir
[trop froid] [trop chaud]
Transition conditionnée
Mesurer la température
Chauffer Refroidir
[trop froid] [trop chaud]
83
SYNCHRONISATION
84
Exemple
Variante des diagrammes d’états-transition, organisé par rapport aux actions et destiné
à représenter le comportement interne d’une opération ou d’un cas d ’utilisation.
Mesurer température
Chauffer Refroidir
Aérer
Arrêter chauffage
[trop froid] [trop chaud]
« synchronisation »
ITÉRATIVE
Itération
NOTION DU DIAGRAMME D’ACTIVITÉ
Swimlanes
87
CONSTRUCTION D’UN DIAGRAMME D’ACTIVITÉS
1. Identifiez la portée (« scope ») du diagramme d'activités
Commencez en identifiant ce que vous allez modéliser. Un seul use case? Une
partie d'un use case ? Un « workflow » qui inclut plusieurs use cases ? Une
méthode de classe ?
2. Ajouter l’état de départ et de terminaison
3. Ajouter les activités
Si vous modélisez un use case, introduisez une activité pour chaque use case
principal. Si vous modélisez un « workflow », introduisez une activité pour
chaque processus principal, souvent un use case. Enfin, si vous modélisez une
méthode, il est souvent nécessaire d’avoir une activité pour chaque grand étape de
la méthode.
4. Ajouter des transitions (séquentielles), des transitions alternatives
(conditionelles), des synchronisations entre des activités, des itérations.
5. Identifier des swimlanes et répartir des activités identifiées dans ces
swimlanes.
88
EXEMPLES
Système de vente en ligne
Cas d’utilisation: Commander ordinateur
Afficher la
configuration courante
Saisir les détails
de la vente
Enregistrer la
commande
Envoyer un courriel
de confirmation
Afficher le formulaire
de vente
Saisir la demande
de commande
[temps expiré]
[ok]
[commande incomplète]
[temps non expiré]
EXEMPLES
Exemple – Bibliothèque
Trouver livre
sur étagère
Enregistrer
le retour
Remettre le
livre sur
étagère
Se préparer pour le
prochain membre
Enregistrer le
prêt
Attendre en
ligne
[fin travail]
[emprunt]
[retour]
[retour]
[emprunt]
[au travail]
Membre Libraire

Contenu connexe

Tendances

UML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouriUML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouri
Mansouri Khalifa
 
Diagramme de Séquence
Diagramme de SéquenceDiagramme de Séquence
Diagramme de Séquence
abdoMarocco
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
Lilia Sfaxi
 
Génie Logiciel : Conception
Génie Logiciel : ConceptionGénie Logiciel : Conception
Génie Logiciel : Conception
Mohammed Amine Mostefai
 
Vision par ordinateur
Vision par ordinateurVision par ordinateur
Vision par ordinateur
Radhouani Mejdi
 
UML Part1-Introduction Mansouri
UML Part1-Introduction MansouriUML Part1-Introduction Mansouri
UML Part1-Introduction Mansouri
Mansouri Khalifa
 
système multi agent
système multi agentsystème multi agent
système multi agent
Fatima Zohra BENHACINE
 
Chapitre 1 Représentation d'état des systèmes linéaires
Chapitre 1 Représentation d'état des systèmes linéaires Chapitre 1 Représentation d'état des systèmes linéaires
Chapitre 1 Représentation d'état des systèmes linéaires
sarah Benmerzouk
 
les style d'architecture
les style d'architecture les style d'architecture
les style d'architecture
Mouna Maazoun
 
Modélisation uml avec le diagramme de classe
Modélisation uml avec le diagramme de classeModélisation uml avec le diagramme de classe
Modélisation uml avec le diagramme de classe
amat samiâ boualil
 
Ch 01 poo
Ch 01 pooCh 01 poo
Ch 01 poo
Yassine Badri
 
Chp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat TransitionChp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat Transition
Lilia Sfaxi
 
PROJET JAVA BD MySQL
PROJET JAVA BD MySQLPROJET JAVA BD MySQL
PROJET JAVA BD MySQL
Wilfried Tiani
 
Chapitre v algorithmes gloutons
Chapitre v algorithmes gloutonsChapitre v algorithmes gloutons
Chapitre v algorithmes gloutonsSana Aroussi
 
TP1 Traitement d'images Génie Logiciel avec Matlab
TP1 Traitement d'images Génie Logiciel avec MatlabTP1 Traitement d'images Génie Logiciel avec Matlab
TP1 Traitement d'images Génie Logiciel avec Matlab
Mariem ZAOUALI
 
Exam 15.02.2022.pdf
Exam 15.02.2022.pdfExam 15.02.2022.pdf
Exam 15.02.2022.pdf
GhazaliLoubna
 
Gestion d’une agence de voyage routière (Blondel Seumo)
Gestion d’une  agence  de  voyage  routière (Blondel Seumo)Gestion d’une  agence  de  voyage  routière (Blondel Seumo)
Gestion d’une agence de voyage routière (Blondel Seumo)
Gantner Technologies
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
Amir Souissi
 
Correction Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdfCorrection Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdf
slimyaich3
 

Tendances (20)

UML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouriUML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouri
 
Diagramme de Séquence
Diagramme de SéquenceDiagramme de Séquence
Diagramme de Séquence
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
 
Génie Logiciel : Conception
Génie Logiciel : ConceptionGénie Logiciel : Conception
Génie Logiciel : Conception
 
Vision par ordinateur
Vision par ordinateurVision par ordinateur
Vision par ordinateur
 
UML Part1-Introduction Mansouri
UML Part1-Introduction MansouriUML Part1-Introduction Mansouri
UML Part1-Introduction Mansouri
 
système multi agent
système multi agentsystème multi agent
système multi agent
 
Chapitre 1 Représentation d'état des systèmes linéaires
Chapitre 1 Représentation d'état des systèmes linéaires Chapitre 1 Représentation d'état des systèmes linéaires
Chapitre 1 Représentation d'état des systèmes linéaires
 
les style d'architecture
les style d'architecture les style d'architecture
les style d'architecture
 
Modélisation uml avec le diagramme de classe
Modélisation uml avec le diagramme de classeModélisation uml avec le diagramme de classe
Modélisation uml avec le diagramme de classe
 
Ch 01 poo
Ch 01 pooCh 01 poo
Ch 01 poo
 
Chp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat TransitionChp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat Transition
 
PROJET JAVA BD MySQL
PROJET JAVA BD MySQLPROJET JAVA BD MySQL
PROJET JAVA BD MySQL
 
Chapitre v algorithmes gloutons
Chapitre v algorithmes gloutonsChapitre v algorithmes gloutons
Chapitre v algorithmes gloutons
 
TP1 Traitement d'images Génie Logiciel avec Matlab
TP1 Traitement d'images Génie Logiciel avec MatlabTP1 Traitement d'images Génie Logiciel avec Matlab
TP1 Traitement d'images Génie Logiciel avec Matlab
 
Exam 15.02.2022.pdf
Exam 15.02.2022.pdfExam 15.02.2022.pdf
Exam 15.02.2022.pdf
 
Gestion d’une agence de voyage routière (Blondel Seumo)
Gestion d’une  agence  de  voyage  routière (Blondel Seumo)Gestion d’une  agence  de  voyage  routière (Blondel Seumo)
Gestion d’une agence de voyage routière (Blondel Seumo)
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
 
UML4
UML4UML4
UML4
 
Correction Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdfCorrection Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdf
 

Similaire à DiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdf

DIAGRAMME DE SEQUENCE.pptx
DIAGRAMME DE SEQUENCE.pptxDIAGRAMME DE SEQUENCE.pptx
DIAGRAMME DE SEQUENCE.pptx
b5kftjxcc4
 
DAGRAMMES UML - ANALYSE D'UN PROJET LOGICIEL
DAGRAMMES UML - ANALYSE D'UN PROJET LOGICIELDAGRAMMES UML - ANALYSE D'UN PROJET LOGICIEL
DAGRAMMES UML - ANALYSE D'UN PROJET LOGICIEL
IliasPeyou
 
dokumen.tips_diagramme-de-sequence-uml.pdf
dokumen.tips_diagramme-de-sequence-uml.pdfdokumen.tips_diagramme-de-sequence-uml.pdf
dokumen.tips_diagramme-de-sequence-uml.pdf
viyipim509
 
Chapitre4_ConceptionDynamique (1).pptx
Chapitre4_ConceptionDynamique (1).pptxChapitre4_ConceptionDynamique (1).pptx
Chapitre4_ConceptionDynamique (1).pptx
fatmaezzahranouioui
 
Diagramme d'état transition
Diagramme d'état transitionDiagramme d'état transition
Diagramme d'état transition
abdoMarocco
 
Diagramme d’activités
Diagramme d’activitésDiagramme d’activités
Diagramme d’activités
abdoMarocco
 
Support de cours Conception orientée objets - partie 2.pdf
Support de cours Conception orientée objets - partie 2.pdfSupport de cours Conception orientée objets - partie 2.pdf
Support de cours Conception orientée objets - partie 2.pdf
YasushiTsubakik
 
Chapitre4_ACSI_diag_Seq_diaggrame_de_sequence.pdf
Chapitre4_ACSI_diag_Seq_diaggrame_de_sequence.pdfChapitre4_ACSI_diag_Seq_diaggrame_de_sequence.pdf
Chapitre4_ACSI_diag_Seq_diaggrame_de_sequence.pdf
RimaAlaya
 

Similaire à DiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdf (8)

DIAGRAMME DE SEQUENCE.pptx
DIAGRAMME DE SEQUENCE.pptxDIAGRAMME DE SEQUENCE.pptx
DIAGRAMME DE SEQUENCE.pptx
 
DAGRAMMES UML - ANALYSE D'UN PROJET LOGICIEL
DAGRAMMES UML - ANALYSE D'UN PROJET LOGICIELDAGRAMMES UML - ANALYSE D'UN PROJET LOGICIEL
DAGRAMMES UML - ANALYSE D'UN PROJET LOGICIEL
 
dokumen.tips_diagramme-de-sequence-uml.pdf
dokumen.tips_diagramme-de-sequence-uml.pdfdokumen.tips_diagramme-de-sequence-uml.pdf
dokumen.tips_diagramme-de-sequence-uml.pdf
 
Chapitre4_ConceptionDynamique (1).pptx
Chapitre4_ConceptionDynamique (1).pptxChapitre4_ConceptionDynamique (1).pptx
Chapitre4_ConceptionDynamique (1).pptx
 
Diagramme d'état transition
Diagramme d'état transitionDiagramme d'état transition
Diagramme d'état transition
 
Diagramme d’activités
Diagramme d’activitésDiagramme d’activités
Diagramme d’activités
 
Support de cours Conception orientée objets - partie 2.pdf
Support de cours Conception orientée objets - partie 2.pdfSupport de cours Conception orientée objets - partie 2.pdf
Support de cours Conception orientée objets - partie 2.pdf
 
Chapitre4_ACSI_diag_Seq_diaggrame_de_sequence.pdf
Chapitre4_ACSI_diag_Seq_diaggrame_de_sequence.pdfChapitre4_ACSI_diag_Seq_diaggrame_de_sequence.pdf
Chapitre4_ACSI_diag_Seq_diaggrame_de_sequence.pdf
 

Plus de MbarkiIsraa

NP-complet.ppt
NP-complet.pptNP-complet.ppt
NP-complet.ppt
MbarkiIsraa
 
Format.pptx
Format.pptxFormat.pptx
Format.pptx
MbarkiIsraa
 
correctionTD2JAVA.pdf
correctionTD2JAVA.pdfcorrectionTD2JAVA.pdf
correctionTD2JAVA.pdf
MbarkiIsraa
 
correctionTD-1-vhdl2947.pptx
correctionTD-1-vhdl2947.pptxcorrectionTD-1-vhdl2947.pptx
correctionTD-1-vhdl2947.pptx
MbarkiIsraa
 
PCD YasBas.pptx
PCD YasBas.pptxPCD YasBas.pptx
PCD YasBas.pptx
MbarkiIsraa
 
PLNE.pptx
PLNE.pptxPLNE.pptx
PLNE.pptx
MbarkiIsraa
 
Chapitre3_Partie1.pdf
Chapitre3_Partie1.pdfChapitre3_Partie1.pdf
Chapitre3_Partie1.pdf
MbarkiIsraa
 
Chapitre2_Partie1.pdf
Chapitre2_Partie1.pdfChapitre2_Partie1.pdf
Chapitre2_Partie1.pdf
MbarkiIsraa
 
(GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf
(GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf(GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf
(GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf
MbarkiIsraa
 
support_cours.pdf
support_cours.pdfsupport_cours.pdf
support_cours.pdf
MbarkiIsraa
 
c h02EspaceProbTr.pdf
c h02EspaceProbTr.pdfc h02EspaceProbTr.pdf
c h02EspaceProbTr.pdf
MbarkiIsraa
 
Ordonnanc-Proc_Threads (1).pdf
Ordonnanc-Proc_Threads (1).pdfOrdonnanc-Proc_Threads (1).pdf
Ordonnanc-Proc_Threads (1).pdf
MbarkiIsraa
 
prog_reg.pptx
prog_reg.pptxprog_reg.pptx
prog_reg.pptx
MbarkiIsraa
 
correctionTD-2-vhdl2949.pptx
correctionTD-2-vhdl2949.pptxcorrectionTD-2-vhdl2949.pptx
correctionTD-2-vhdl2949.pptx
MbarkiIsraa
 
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdf
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdfChapitre 3 _Conception et analyse d’algorithme-DPR.pdf
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdf
MbarkiIsraa
 
Chapitre 2 -Complexité des problèmes avec correction.pdf
Chapitre 2 -Complexité des problèmes avec correction.pdfChapitre 2 -Complexité des problèmes avec correction.pdf
Chapitre 2 -Complexité des problèmes avec correction.pdf
MbarkiIsraa
 
Complexité_ENSI_2011.ppt
Complexité_ENSI_2011.pptComplexité_ENSI_2011.ppt
Complexité_ENSI_2011.ppt
MbarkiIsraa
 
Correction-TD1.pdf
Correction-TD1.pdfCorrection-TD1.pdf
Correction-TD1.pdf
MbarkiIsraa
 
UML.Objet.4pp.pdf
UML.Objet.4pp.pdfUML.Objet.4pp.pdf
UML.Objet.4pp.pdf
MbarkiIsraa
 

Plus de MbarkiIsraa (19)

NP-complet.ppt
NP-complet.pptNP-complet.ppt
NP-complet.ppt
 
Format.pptx
Format.pptxFormat.pptx
Format.pptx
 
correctionTD2JAVA.pdf
correctionTD2JAVA.pdfcorrectionTD2JAVA.pdf
correctionTD2JAVA.pdf
 
correctionTD-1-vhdl2947.pptx
correctionTD-1-vhdl2947.pptxcorrectionTD-1-vhdl2947.pptx
correctionTD-1-vhdl2947.pptx
 
PCD YasBas.pptx
PCD YasBas.pptxPCD YasBas.pptx
PCD YasBas.pptx
 
PLNE.pptx
PLNE.pptxPLNE.pptx
PLNE.pptx
 
Chapitre3_Partie1.pdf
Chapitre3_Partie1.pdfChapitre3_Partie1.pdf
Chapitre3_Partie1.pdf
 
Chapitre2_Partie1.pdf
Chapitre2_Partie1.pdfChapitre2_Partie1.pdf
Chapitre2_Partie1.pdf
 
(GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf
(GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf(GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf
(GLII-Spécification, vérification et qualité-chapitres 1 et 2-2013-2014.pdf
 
support_cours.pdf
support_cours.pdfsupport_cours.pdf
support_cours.pdf
 
c h02EspaceProbTr.pdf
c h02EspaceProbTr.pdfc h02EspaceProbTr.pdf
c h02EspaceProbTr.pdf
 
Ordonnanc-Proc_Threads (1).pdf
Ordonnanc-Proc_Threads (1).pdfOrdonnanc-Proc_Threads (1).pdf
Ordonnanc-Proc_Threads (1).pdf
 
prog_reg.pptx
prog_reg.pptxprog_reg.pptx
prog_reg.pptx
 
correctionTD-2-vhdl2949.pptx
correctionTD-2-vhdl2949.pptxcorrectionTD-2-vhdl2949.pptx
correctionTD-2-vhdl2949.pptx
 
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdf
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdfChapitre 3 _Conception et analyse d’algorithme-DPR.pdf
Chapitre 3 _Conception et analyse d’algorithme-DPR.pdf
 
Chapitre 2 -Complexité des problèmes avec correction.pdf
Chapitre 2 -Complexité des problèmes avec correction.pdfChapitre 2 -Complexité des problèmes avec correction.pdf
Chapitre 2 -Complexité des problèmes avec correction.pdf
 
Complexité_ENSI_2011.ppt
Complexité_ENSI_2011.pptComplexité_ENSI_2011.ppt
Complexité_ENSI_2011.ppt
 
Correction-TD1.pdf
Correction-TD1.pdfCorrection-TD1.pdf
Correction-TD1.pdf
 
UML.Objet.4pp.pdf
UML.Objet.4pp.pdfUML.Objet.4pp.pdf
UML.Objet.4pp.pdf
 

DiagrammeSequence&DiagrammaEtatTransition&DiagrammeActivité.pdf

  • 1. Impossible d’afficher l’image. Impossible d’afficher l’image. MODÉLISATION DYNAMIQUE 1
  • 2. ASPECTS DYNAMIQUES DU SYSTÈME  Jusqu’ici, le système a été décrit statiquement:  Le diagramme de classes  Décrit les messages (méthodes ou opérations) que les instances des classes peuvent recevoir mais ne décrit pas l’émission de ces messages  Ne montre pas le lien entre ces échanges de messages et les processus généraux que l’application doit réaliser  Il faut maintenant décrire comment le système évolue dans le temps 2
  • 3. Impossible d’afficher l’image. Impossible d’afficher l’image. Modélisation dynamique Objectifs  Introduire les diagrammes d’interaction  Introduire les diagrammes de comportement 3
  • 4. DIAGRAMMES D'INTERACTIONS  Les diagrammes de séquences et les diagrammes de communication (ou collaboration) d’instances sont deux types de diagrammes d'interaction. Les diagrammes d'interaction représentent une interaction, c'est-à-dire un ensemble d’objets et leurs relations, y compris les messages qu'ils peuvent échanger. Ils présentent une vue dynamique d’un système.  Cas particulier : diagrammes de séquences système : interaction entre acteurs et système  Les diagrammes de séquence sont des diagrammes d'interaction qui mettent l'accent sur le classement chronologique des messages alors que les diagrammes de communication d’instances sont des diagrammes d'interaction qui mettent l'accent sur l'organisation spatiale des éléments qui envoient et reçoivent des messages.  Les diagrammes de séquence et les diagrammes de communication d’instances sont isomorphes, c'est-à-dire que l'un peut être transformé en l'autre. 4
  • 5. DIAGRAMME D’INTÉRACTIONS Modèle conceptuel (Analyse dynamique) Description de l’interaction moyennant les objets (de l’analyse) du système Diagramme d’Interaction Modèle logique (Conception dynamique) Description de l’interaction moyennant les objets (de la conception) du système Diagramme d’interaction Diagramme d’interaction Expression des Besoins (Cas d’utilisation) Description de l’interaction du système avec les acteurs extérieurs 5
  • 6. DIAGRAMMES DE SÉQUENCES  Dérivés des scénarios de OMT :  Montrent des exemples de coopération entre objets dans la réalisation de processus de l’application  Illustrent la dynamique d’enchaînement des traitements à travers les messages échangés entre objets  le temps est représenté comme une dimension explicite (en général de haut en bas)  Les éléments constitutifs d’un scénario sont :  Un ensemble d’objets (et/ou d’acteurs)  Un message initiateur du scénario  La chronologie des messages échangés subséquemment  Les contraintes de temps (aspects temps réel) 6
  • 7. PRÉSENTATION  Diagramme de séquence:  Montre la séquence dans le temps des interactions entre les objets du système au sein d’un scénario.  Objet passif : activation dépend d’un fil externe  Objet actif : possède son propre fil d’exécution  Un diagramme de séquence a deux dimensions:  dimension verticale: le temps; L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du diagramme ; le temps s'écoule "de haut en bas" de cet axe.  dimension horizontale: les objets (et les acteurs) L’ordre de disposition des objets sur l'axe horizontal est sans importance. :c1 :c5 :c3 objets temps 7
  • 8. SYNTAXE GRAPHIQUE  Objets et messages Nom Objet1:NomClasse1 Nom Objet:NomClasse Objets = Instances de classes nom message (paramètres) Message nom message émis par Nom Objet vers Nom Objet1 Temps 8
  • 9. LIGNE DE VIE ET ACTIVATION La «ligne de vie» représente l’existence de l’objet à un instant particulier  Commence avec la création de l’objet  Se termine avec la destruction de l’objet L’activation est la période durant laquelle l’objet exécute une action lui-même ou via une autre procédure 9
  • 10. NOTATION objet1:Classe1 objet2:Classe2 objet3:Classe3 Client op ( ) m1 ( ) m2 ( ) m3 ( ) Objet créé dans le scénario Activité de l’objet Objet existant avant et après l’activation du scénario Ligne de vie 10
  • 11. MESSAGES SIMPLES  Communication entre objets  Des paramètres  Un retour  Cas particuliers  La récursivité  Les messages entraînant la construction d’un objet  Les destructions d’objets 11
  • 12. MESSAGES SYNCHRONE VS ASYNCHRONE  message synchrone Suite à l’envoi de son message, l’expéditeur (objet passif ou actif) perd le contrôle mais demeure en activation (invocation d’opération). Il demeure bloqué jusqu’à ce que le destinataire ait fini de traiter le message. Il retrouve ensuite le contrôle avec la réponse à son message (pouvant être représenté par une flèche pointillée).  message simple L’expéditeur envoie un message au destinataire sans attendre de réponse : (signal).  Si l’expéditeur est un objet passif: l’expéditeur perd le contrôle et termine son activation après l’envoi du message  Si l’expéditeur est un objet actif: l’envoi d’un message simple équivaut à l’envoi d’un message asynchrone. 12
  • 13.  Un objet actif initie et contrôle le flux d’activités. Graphiquement, la ligne pointillée verticale d’un objet actif est remplacée par un double trait vertical  Représentation d’un objet actif (à gauche) et d’une exécution sur un objet passif (à droite): CATÉGORIE DE MESSAGES 13
  • 14. MODE D’INTERACTION PROCÉDURAL (I.E. SYNCHRONE)  Au plus un objet détient le contrôle à la fois.  Un objet obtient le contrôle quand il reçoit un message (i.e. on invoque une de ses méthodes). Ce moment détermine le début de son activation.  Un objet rend le contrôle à son destinateur lorsqu’il lui renvoie sa réponse. Ce moment détermine la fin de son activation.  Lorsqu’un objet en activation a le contrôle, il peut  faire des calculs,  ou envoyer des messages: dans ce cas, l’objet demeure en activation mais cède à son tour le contrôle à son destinataire. Il ne peut rien faire jusqu’à ce qu’il reçoive la réponse de son destinataire (message synchrone ou dit « bloquant »). 14
  • 15.  Les objets sont dits « passif », car on doit leur envoyer un message pour déclencher leur activation.  Un seul fil d’exécution.  Dans ce mode, seul un acteur peut envoyer un message ou faire des calculs sans l’intervention de qui que ce soit. Son activation est constante…  L’identité des objets en activation est gérée dans une pile:  Dessus de la pile = objet en activation qui possède le contrôle  On empile l’identité d’un objet qui débute une activation.  On dépile l’identité d’un objet qui termine une activation.  Les messages sont numérotés de façon à refléter l’imbrication des envois de messages.  Le message 2.2 est envoyé après que la réponse au message 2.1 ait été reçue  Il faut attendre la réponse au message 2.2.3 avant de pouvoir répondre au message 2.2. MODE D’INTERACTION PROCÉDURAL 15
  • 16. EXEMPLE : MODE D’INTERACTION PROCÉDURAL mb :MembreBiblio exemplaire :Exemplaire leLivre:Livre unMembre :EmprunteurDeLivre emprunter(exemplaire) 1:okPourEmprunter 2:emprunter 2.1:estEmprunté activation message ligne de vie message réflexif
  • 17. AUTRES NOTATIONS POUR DES INTERACTIONS AVANCÉES On peut alors avoir besoin de:  Interactions concurrentes  Conditions (gardes) sur les messages:  Ligne de vie à branches multiples.  Itérations  Contraintes temporelles (temps réel) 17
  • 18. MODE D’INTERACTION CONCURRENT (I.E. ASYNCHRONE)  Certains objets disposent d’un propre fil d’exécution. Il ont leur propre contrôle et leur activation est constante. Ces objets sont dits « actifs », car il peuvent faire des calculs et envoyer des messages sans l’intervention de qui que ce soit.  Les objets actifs peuvent envoyer deux types de messages  synchrones: ils attendent la réponse de leur destinataire avant de poursuivre…  asynchrones: ils poursuivent leurs activités sans attendre la réponse à leur message… Celle-ci leur sera signalée. N.b. En mode procédural, tous les messages sont synchrones… 18
  • 19. MODE D’INTERACTION CONCURRENT Il existe différente façon de créer de nouveaux fils de contrôle (threads) 1. À la réception d’un message, un objet peut découpler le fil d’exécution en envoyant plusieurs messages simultanément (fork). o:Obj 1.a: foo() 1.b: bar() Branchement: Lorsque les messages n’ont pas de garde mutuellement exclusive, on en déduit qu’ils sont concurrents.
  • 20. MODE D’INTERACTION CONCURRENT 2. Un acteur peut spontanément décider d’envoyer un message et crée ainsi un nouveau fil d’exécution. 3. Un objet actif peut également découpler le fil d’exécution en envoyant un message asynchrone. • L’objet continue sans attendre le message de retour. • Il octroie ainsi un fil d’exécution indépendant à l’objet destinataire. o1:Obj 1: foo() 2:bar() o2:Obj
  • 21. EXEMPLES DE SCÉNARIOS  Appel téléphonique  Scénario : le numéro appelé est occupé  L'appelant décroche le téléphone  L'appelant commence à composer le numéro  L'appelant termine de composer le numéro  La tonalité "occupée" commence à sonner  L'appelant raccroche le téléphone  Scénario : le numéro appelé n'est pas occupé  L'appelant décroche le téléphone  L'appelant commence à taper le numéro  L'appelant termine de taper le numéro  Le téléphone commence à sonner  L'appelé décroche  La conversation se déroule  L'appelé raccroche le téléphone 21
  • 22. EXEMPLE MODE D’INTERACTION CONCURRENT (ASYNCHRONE) appelant centrale téléphonique appelé 1: décrocher() 2: envoyer_signal() 3: composer_numéro() 4: chercher_destinataire() 5B: activer_sonnerie() 5A: entendre_sonnerie() 6: décrocher() 7B: arrêter_sonnerie() 7A: arrêter_signal_sonnerie() 22
  • 23. MESSAGES AVEC GARDE o:Obj 1.a: [i=0] foo() 1.b: [i=1] bar() o:Obj 1.1: [i=0] foo() 1.2: [i=1] bar() Différence?? • Permet d’exprimer les alternatives de comportement. • Message envoyé seulement si la garde est vraie. • Les gardes doivent être mutuellement exclusives pour signifier que l’envoi est conditionnel (et non concurrent).
  • 24. LIGNE DE VIE À BRANCHES MULTIPLES • Si deux messages, dont l’envoi est conditionnel à l’évaluation d’une garde, sont destinés à un même objet, on doit pouvoir exprimer le comportement de l’objet dans chaque cas… o1:Obj1 3.1.a: [i=0] foo() 3.1.b: [i=1] bar() o2:Obj2
  • 25. EXEMPLE :REPRÉSENTATION DE CONDITIONNELLES objet1:Classe1 op ( ) objet2:Classe2 [x<0] m1 ( x ) [x>0] m2 ( x ) Branchement conditionnel Branchement conditionnel 25
  • 26. ITÉRATION • On ajoute une clause d’itération (introduite par un *) à côté du message pour spécifier le nombre d’itérations ou l’invariant de l’itération: Exemples: *[i:=1..10] Le message est envoyé 10 fois *[x<10] Le message est envoyé de façon répétée jusqu’à ce que x soit plus grand ou égal à 10. *[item not found] Le message est envoyée de façon répétée jusqu’à ce que l’item soit trouvé…. Ne pas répéter la clause d’itération chez le destinataire (elle est implicite)… à moins de vouloir une boucle imbriquée.
  • 29. LES FRAGMENTS D’INTERACTION  Un fragment combiné représente des articulations d'interactions. Il est défini par un opérateur et des opérandes. L'opérateur conditionne la signification du fragment combiné. Les fragments combinés peuvent faire intervenir l'ensemble des entités participant au scénario ou juste un sous-ensemble.  Les principaux opérateurs en UML 2 :  Opérateur "Alternative"  Opérateur "Option"  Opérateur "Break"  Opérateur "Parallel"  Opérateur "Loop" 29
  • 30.  L'opérateur "alt" désigne un choix, une alternative. Il représente des comportements possibles : c'est en quelque sorte l'équivalent du SI...ALORS...SINON : donc, une seule des branches alternatives sera réalisée dans un scénario donné.  La condition d'exécution d'une des branches alternatives (l'équivalent du SI) peut être explicite ou implicite.  L'utilisation de l'opérateur else permet d'indiquer que la branche est exécutée si la condition du alt est fausse. Les fragments combinés 2. Le diagramme de séquence système Les fragments d’interaction 30
  • 31. L'exemple ici montre un opérateur "alt" : - soit l'utilisateur rentre un code correct et dans ce cas le diagramme de séquence relatif à la vérification du code est appelé, - soit l'utilisateur rentre un code erroné, trois fois, et sa carte est gardée. a) Les fragments combinés 2. Le diagramme de séquence système Les fragments d’interaction 31
  • 32. 2. Le diagramme de séquence système a) Les fragments combinés L'opérateur "opt" désigne un fragment combiné optionnel comme son nom l'indique : c'est à dire qu'il représente un comportement qui peut se produire... ou pas. Un fragment optionnel est équivalent à un fragment "alt" qui ne posséderait pas d'opérande else (qui n'aurait qu'une seule branche). L'exemple ici montre un opérateur "opt" : L'utilisateur, si il est mécontent, peut se défouler sur le distributeur de billets. Les fragments d’interaction 32
  • 33. L'opérateur "break" est utilisé pour représenter des scenarii d'exception. Les interactions de ce fragment seront exécutées à la place des interactions décrites en dessous. Il y a donc une notion d'interruption du flot "normal" des interactions. Les fragments combinés 2. Le diagramme de séquence système L'exemple ici montre un opérateur "break" : L'utilisateur, lorsque le distributeur lui demande son code, peut choisir de rentrer son code ou de consulter l'aide. S’il choisit de consulter l'aide, le flot d'interaction relatif à la saisie du code est interrompu. Les fragments d’interaction 33
  • 34.  L'équivalent de ce diagramme de séquence sans l'opérateur break correspond aux deux diagrammes de séquence suivants : Les fragments combinés 2. Le diagramme de séquence système Les fragments d’interaction 34
  • 35. L'exemple ici montre qu’un développeur ayant accès à Internet peut consulter en parallèle, soit le site http://www.developpez. com soit le site http://www.developpez. net/forums/ sans préférence d’ordre. L'opérateur "par" est utilisé pour représenter des interactions ayant lieu en parallèle. Les interactions des différents opérandes peuvent se mélanger, s'intercaler, dans la mesure où l'ordre imposé dans chaque opérande est respecté. Les fragments combinés 2. Le diagramme de séquence système Les fragments d’interaction 35
  • 36. L'opérateur "Loop" (boucle) est utilisé pour décrire un ensemble d'interaction qui s'exécutent en boucle. En général, une contrainte appelée garde indique le nombre de répétitions (minimum et maximum) ou bien une condition booléenne à respecter. L'exemple ici montre un exemple pour l'opérateur "loop" : Le diagramme de séquence indique que lorsque l'utilisateur se trompe trois fois de code, la carte est gardée et le distributeur se remet en mode d'attente d'une carte. Les fragments combinés 2. Le diagramme de séquence système Les fragments d’interaction 36
  • 37.  Une référence (interaction occurrence) peut être vue comme un pointeur ou un raccourci vers un autre diagramme de séquence existant.  Cela équivaut à copier le contenu du diagramme de séquence pointé en lieu et place de la référence.  Cela permet de factoriser des parties de comportement utilisées dans plusieurs scénario. Les références 2. Le diagramme de séquence système Les fragments d’interaction 37
  • 38. Cas d'utilisation principal : Jouer une partie de démineur  Dans la boucle (loop) de jeu, il y a trois possibilités (alt) : perte, gain ou cas normal. Les cas de perte ou de gain arrêtent la partie (break). Sinon, le joueur passe son temps à découvrir ou (alt) marquer des cases.  Ensuite, le joueur pourra (opt) entrer son nom dans les meilleurs scores si ([]) il a le meilleur temps en fonction du niveau choisi.  On peut ajouter la configuration du jeu comme étape optionnelle (opt) avant de commencer à jouer. Exemple 2. Le diagramme de séquence système Les fragments d’interaction 38
  • 39. Exemple Section 3 Les diagrammes comportementaux Chapitre 2 Les diagrammes d’analyse 2. Le diagramme de séquence système 39
  • 40. CONTRAINTES TEMPORELLES  Lecture du scénario et chronologie  Un scénario se lit de haut en bas dans le sens chronologique d’échange des messages.  Des contraintes temporelles peuvent être ajoutées au scénario :Nom classe2 Nom Objet1: demande réponse a b {b-a< 5 sec.} :Nom classe2 Nom Objet1: demande d d’ {d’-d< 1 sec.} 40
  • 41. Le diagramme de séquence système  Le diagramme de séquence système (DSS) décrit les interactions entre les acteurs et le système selon un point de vue temporel (l'accent est mis sur la chronologie des envois/réceptions de messages entre les acteurs et le système).  Le DSS permet la description de la dynamique du système vu de l'extérieur où le système est vu comme une « boîte noire ».  Le système est donc vu de l'extérieur (par les acteurs) sans préjuger de comment il sera réalisé. La « boîte noire » sera ouverte (décrite) seulement en conception. 41
  • 42. 2. Le diagramme de séquence système  Le DSS est typiquement utilisé pour représenter le fonctionnement d'un cas d'utilisation sous la forme d’une séquence de messages échangés entre les acteurs et le système. Il représente la synthèse des scénarios liés aux cas d'utilisation.  Un scénario : une suite spécifique d'événements (d'actions et d'interactions) entre les acteurs et le système (les DSS sont toujours lus du haut vers le bas, pour illustrer l'ordre dans lequel les messages sont envoyés entre les acteurs et le système). Le diagramme de séquence système 42
  • 43. 2. Le diagramme de séquence système système acteur E1 E2 R1 Acteurs/Système Messages (asynchrone ou synchrone) Ligne de vie Barre d’activation commentaire Les principaux concepts Le diagramme de séquence système 43
  • 44. Le bibliothécaire souhaite enregistrer un nouvel ouvrage dans le système de gestion de l’inventaire de la bibliothèque. Pour cela, il fournit au système le nom de l’auteur et le titre de l’ouvrage. Le bibliothécaire sélectionne ensuite le type d’ouvrage à enregistrer. Le système lui retourne la liste des ouvrages de ce type qui ont été écrit par cet auteur et qui sont déjà enregistrés dans le système. Le bibliothécaire insère une description complète de l’ouvrage. Le système retourne l’ensemble de la description sous un format de lecture et confirme l’enregistrement du nouvel ouvrage. 2. Le diagramme de séquence système Exemple Le diagramme de séquence système 44
  • 45. 2. Le diagramme de séquence système Exemple Le diagramme de séquence système 45
  • 46. DIAGRAMME D’ÉTATS-TRANSITIONS  But: Permet de décrire le comportement d’un objet (instance d’une classe) en fonction événements et des messages reçus. Disponible Verrouillé Vendu attribué_sur_abonnement achète verrouiller déverrouiller délai écoulé Diagramme d’état d’un billet de spectacle à vendre sur Internet 46
  • 47. PRINCIPAUX CONCEPTS  État  Transition  Marqueur d’état initial Nom_état événement / action 47
  • 48. PRINCIPAUX CONCEPTS TRANSITION  Une transition (sortante) définit la réponse d’un objet, dans un état donné, à un événement donné.  Les transitions sont étiquetées par un événement et (optionnellement) par une action :  Événement: Tout ce qui survient et peut affecter un objet. Élément déclencheur de la transition.  Action: Opération réalisée lorsqu’une transition est tirée. Emprunté Sur les rayons emprunter() / livre.emprunté(self) retourner() / livre.retourné(self) Diagramme d’état pour la classe Exemplaire_de_livre événement / action
  • 49. PRINCIPAUX CONCEPTS ÉTAT  Décrit un moment pendant la vie d’un objet.  Un objet ne se trouve que dans un seul état à la fois.  Tous les objets d’une classe qui se trouvent dans un même état réagissent de façon identique aux événements.  Les objets qui se trouvent dans un état donné, à un moment donné, partagent l’une et/ou l’autre des caractéristiques suivantes  Ils ont des valeurs d’attributs similaires.  Ils attendent un événement particulier.  Il exécutent une activité particulière.  Un état est généralement décrit par un nom.  En UML, il existe différents types d’état: simple, concurrent, composite, etc. Nom_état
  • 50. COMMENT TROUVER LES ÉTATS SIGNIFICATIFS D’UN OBJET
  • 54. PRINCIPAUX CONCEPTS TYPES D’ÉVÉNEMENTS Un événement peut être paramétré… Type d’événement Description Syntaxe Appel Réception d’un message synchrone (pour lequel l’émetteur attend une réponse). Invocation d’une opération. op(p1:type, p2:type, …) Changement Changement de valeur d’une condition booléenne. Satisfaction soudaine de cette condition. Condition fausse qui devient vraie. when(exp) Signal Réception d’un message asynchrone. sname(p1:typ e, p2:type, …) Temps Temps absolu atteint ou passage d’un certain intervalle de temps. Peut signaler le temps écoulé depuis l’entrée dans un état donné. after(time) 54
  • 55. GARDE
  • 56. GARDES  Une transition peut être conditionnelle à l’évaluation d’une garde.  Si la garde est vraie, la transition est tirée.  Si la garde est fausse, la transition n’a pas lieu.  Notation: événement [garde] Ne peut être emprunté Peut être emprunté est_emprunté(e) [dernier exemplaire] est_retourné(e) est_retourné(e) est_emprunté(e) [pas dernier exemplaire] Diagramme d’état d’un livre Cette transition est importante pour marquer que retourner() est bel et bien un message attendu et compris par cet automate dans cet état. 56
  • 57. GARDES  Garde  expression conditionnelle  évaluée uniquement quand l’événement est déclenché  peut contenir des attributs de l’objet ou des paramètres de l’événement associé  Lorsqu’un même événement est associé à plusieurs transitions, une garde (condition) peut être ajoutée pour préciser le contexte et déterminer la transition à effectuer.  Les gardes associées à un même événement sur les transitions sortantes d’un état donné, doivent être mutuellement exclusives. 57
  • 59. PRINCIPAUX CONCEPTS TYPES D’ACTIONS Les actions peuvent prendre des arguments… les paramètres effectifs des événements par exemple… Type d’action Description Syntaxe Affectation Assigne une valeur à une variable. target:=expression Appel Invocation (synchrone) d’une opération d’un objet. Peut retourner une valeur. opname(arg1, arg2, …) object.opname(arg1, arg2, …) Envoi Envoi d’un message (signal) asynchrone. sname(arg1, arg2, …) Création Création d’un nouvel objet. new Cname(arg1, arg2, …) Destruction Destruction d’un objet. object.destroy () Retour Spécification d’une valeur retournée. return value Divers Action décrite dans un autre langage… [ description ] Séquence Séquence d’action action1; action2; … 59
  • 63. ACTIONS D’ENTRÉE ET DE SORTIE Certaines actions peuvent être rattachées à un état au lieu d’une transition  Action d’entrée: Action exécutée chaque fois qu’on entre dans l’état (quelle que soit la transition qui nous y amène…).  Notation: entry /action  Action de sortie: Action exécutée chaque fois qu’on sort de l’état (quelle que soit la transition qui nous en fait sortir).  Notation: exit/action Emprunté exit/livre.retourné(self) Sur les rayons exit/livre.emprunté(self) emprunter() retourner() Diagramme d’état d’un exemplaire de livre Ordre d’exécution des actions ? 63
  • 66. TYPES DE TRANSITIONS  Transition externe: transition standard qui engendre un changement d’état et toutes les actions correspondantes (actions d’entrée et de sortie, ainsi que celles de la transition).  Transition interne: transition qui n’engendre pas de changement d’état et ne déclenche que les actions associées à cette transition (pas les actions d’entrée et de sortie)  Transition de complétion: transition qui n’est pas activée par un événement. La transition est tirée dès que l’activité, de l’état qu’elle quitte, se termine. Souvent munie d’une garde. Saisie mot de passe entry/ set echo to star; password.reset() exit/ set echo normal digit / handle character help / display help() clear Transitions internes Transition externe 66
  • 67. TRANSITION DE COMPLÉTION (TRANSITION AUTOMATIQUE) 67
  • 69. ÉTAT COMPOSITE État « spécialisé » composé de plusieurs sous - états.  Sous - états séquentiels  Sous - états concurrents 69
  • 70. ÉTAT COMPOSITE (SÉQUENTIEL OU CONCURRENT)  Lorsqu’un état composite est activé, un de ses sous - états est nécessairement activé.  Entrer et sortir d’un état composite  Une transition entrant dans un état composite est implicitement conduite vers son état initial.  Une transition vers l’état final d’un état composite active implicitement une transition de complétion sortant de l’état composite.  Lorsqu’une transition entre/sort en traversant un ou plusieurs états composites imbriqués, toutes les actions d’entrées/sortie sont exécutées  Actions d’entrées… de l’état le plus externe en premier.  Actions de sortie … de l’état le plus interne en premier. 70
  • 72. ÉTAT COMPOSITE (SÉQUENTIEL) - EXEMPLE Identification Sélection choisir(siège) / ajouter_à_sélection(siège) Confirmation Vente Entry / vendre() [identification_réussie]/ Initialiser_sélection() clic_acheter clic_recommencer clic_confirmer [identification_échouée] Achat d’un billet Exit / éjecter_carte() inactif insérer_carte clic_annuler À remarquer •Transition interne •Transitions de complétion •État intial •État final 72
  • 74. ÉTAT COMPOSITE (CONCURRENT) EXEMPLE Labo 1 Projet de semestre Examen final lab_terminé [note >= 60] Cours non terminé Labo 2 lab_terminé projet_terminé réussite Cours réussi Cours échoué échec [note < 60] Diagramme d’état d’un cours 74
  • 75. ÉTAT COMPOSITE (CONCURRENT) EXEMPLE Autre notation possible Labo 1 Projet de semestre Examen final lab_terminé [note >= 60] Cours non terminé Labo 2 lab_terminé projet_terminé réussite Cours réussi Cours échoué échec [note < 60] Diagramme d’état d’un cours fork join 75
  • 76. TRANSITIONS ENTRE ETATS COMPOSITES 76
  • 77. RÉFÉRENCE SUR UN SOUS-DIAGRAMME D’ÉTAT Attendre commande commande d’aide Include Run Include Help commande d’exécution entry / afficher écran d’aide exit / effacer écran d’aide question / show réponse Help quitter 77
  • 78. Utilité  Utilisé pour décrire les séquences d’activités composant  un processus d’affaires, système de production, etc. (modèle d’affaires)  un cas d’utilisation (modèle d’analyse)  un algorithme particulier (modèle de conception)  Permet de décrire les activités d’un cas d’utilisation en restant à un haut niveau d’abstraction.  Permet d’exprimer des flots de contrôle séquentiels et concurrents. DIAGRAMME D’ACTIVITÉS 78
  • 79. Particularités  Forme particulière de diagramme d’états où  Les états sont remplacés par des activités.  On ne s’intéresse pas aux états d’un objet, mais plutôt aux états d’un calcul ou d’une tâche complexe à accomplir. En fait, ce ne sont pas des états mais des activités.  Les transitions sont automatiquement déclenchées par la complétion d’une activité.  Le passage d’une activité à l’autre se fait automatiquement lorsqu’une activité est terminée. Une activité (contrairement à un état) n’attend pas l’occurrence d’un événement pour effectuer une transition. On passe à la prochaine activité dès que la précédente (dans le diagramme) est terminée. 79
  • 80. DIAGRAMME D’ACTIVITÉS UML permet de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une variante des diagrammes d'états- transitions).  Une activité représente une exécution d'un mécanisme, un déroulement d'étapes séquentielles.  Le passage d'une activité vers une autre est matérialisé par une transition. Remarque :  En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités, mais seuls les mécanismes complexes ou intéressants méritent d'être représentés.  Le diagramme d’activités est le plus approprié pour modéliser la dynamique d’une tâche, d’un use case lorsque le diagramme de classes n’est pas encore stabilisé. 80
  • 81. PRINCIPAUX ÉLÉMENTS DE NOTATION Activité Transition Marqueur d’état initial Barre de synchronisation Branchement Condition [ cond ] nom_activité 81
  • 82. NOTION DU DIAGRAMME D’ACTIVITÉS Diagramme d’activité =  ensemble d’activités liés par:  Transition (sequentielle)  Transitions alternatives (conditionnelle)  Synchronisation (disjonction et conjonctions d’activités)  Itération  + 2 états: état de départ et état de terminaison  Swimlanes: represente le lieu, le responsable des activités. Activité Autre Activité 82
  • 83. CONDITIONNELLE •Etat de départ •Etat de terminaison •Transition •Transition Alternative [ ] [ ] Mesurer la température Chauffer Refroidir [trop froid] [trop chaud] Transition conditionnée Mesurer la température Chauffer Refroidir [trop froid] [trop chaud] 83
  • 85. Exemple Variante des diagrammes d’états-transition, organisé par rapport aux actions et destiné à représenter le comportement interne d’une opération ou d’un cas d ’utilisation. Mesurer température Chauffer Refroidir Aérer Arrêter chauffage [trop froid] [trop chaud] « synchronisation »
  • 87. NOTION DU DIAGRAMME D’ACTIVITÉ Swimlanes 87
  • 88. CONSTRUCTION D’UN DIAGRAMME D’ACTIVITÉS 1. Identifiez la portée (« scope ») du diagramme d'activités Commencez en identifiant ce que vous allez modéliser. Un seul use case? Une partie d'un use case ? Un « workflow » qui inclut plusieurs use cases ? Une méthode de classe ? 2. Ajouter l’état de départ et de terminaison 3. Ajouter les activités Si vous modélisez un use case, introduisez une activité pour chaque use case principal. Si vous modélisez un « workflow », introduisez une activité pour chaque processus principal, souvent un use case. Enfin, si vous modélisez une méthode, il est souvent nécessaire d’avoir une activité pour chaque grand étape de la méthode. 4. Ajouter des transitions (séquentielles), des transitions alternatives (conditionelles), des synchronisations entre des activités, des itérations. 5. Identifier des swimlanes et répartir des activités identifiées dans ces swimlanes. 88
  • 89. EXEMPLES Système de vente en ligne Cas d’utilisation: Commander ordinateur Afficher la configuration courante Saisir les détails de la vente Enregistrer la commande Envoyer un courriel de confirmation Afficher le formulaire de vente Saisir la demande de commande [temps expiré] [ok] [commande incomplète] [temps non expiré]
  • 90. EXEMPLES Exemple – Bibliothèque Trouver livre sur étagère Enregistrer le retour Remettre le livre sur étagère Se préparer pour le prochain membre Enregistrer le prêt Attendre en ligne [fin travail] [emprunt] [retour] [retour] [emprunt] [au travail] Membre Libraire