Slides UML Etat Transitions Activites

Les diagrammes d’états transitions (vue dynamique)
Les diagrammes d’activités
Diagramme état-transitions / Diagrammes

d’activités
David Célestin FAYE
UFR SAT/UGB
David Célestin FAYE Modélisation avec UML 1/96

Plan 2
1 Les diagrammes d’états transitions (vue dynamique)
2 Les diagrammes d’activités

Plan 3

Les Diagrammes d’UML 4

Diagramme
Diagramme Diagramme
De structure comportemental
Diagramme Diagramme Diagramme Diagramme Diagramme de

de classes de packages de d'objets d'activités Cas d'utilisation
Diagramme Diagramme Diagramme de Diagramme Diagramme de

de composants de déploiement Structure composite d'interaction Transition d'état
Diagramme Diagramme de
De séquence communication
Diagramme Diagramme
Vue d'ensemble De timing
Des interactions

Les diagrammes d’états transitions : généralités 5
Z Ils présentent la vue dynamique d’un système

Z Ils sont particulièrement important dans la modélisation du
comportement d’une interface, d’une classe ou d’une
collaboration
Les diagrammes d’états-transitions dérivent le comportement
interne d’un objet à l’aide d’automates à états finis.
Z Le comportement d’un objet est ordonnancé par des
évènements
Z Ce sont des automates à états, composés d’états, de
transitions, d’évènements et d’actions

Les diagrammes d’états transitions : sémantique 6
Rôle
permettent de décrire les changements d’états d’un objet ou d’un
composant, en réponse aux interactions avec d’autres
objets/composants ou avec des acteurs
Utilité
Spécifier le comportement d’un objet :
en définissant explicitement les événements auxquels peut
répondre un objet en fonction de l’état dans lequel il se trouve,
et donc en définissant les événements auxquels il ne peut pas
répondre dans certains états.


état
Un état d’un objet est défini à la fois par la valeur de ses
attributs et de ses liens avec les autres objets.
Il représente ainsi un intervalle de temps.
L’objet est dans un état initial et peut alors changer d’état.
Étudiant
numéro
Inscrire en * Nom * pratiquer
Age
statut
0..*
*
diplôme sport
Ici l’objet Etudiant peut passer d’un état Etudiant à un état de

diplômé à un état de sportif, C’est l’attribut Statut qui va changer de
valeur.

Notion d’automate à états finis

Un automate à états finis est la spécification de la séquence
d’états que subira un objet au cours de son cycle de vie.
Un tel automate représente le comportement d’un classeur
dont les sorties
ne dépendent pas seulement de ses entrées,
mais aussi d’un historique des sollicitations passées.
Cet historique est caractérisé par un état.
Les objets changent d’état en réponse à des événements
extérieurs donnant lieu à des transitions entre états.
Sauf cas particuliers, à chaque instant, chaque objet est dans
un et un seul état.

Etat
un état de l’automate à états finis.
Représente une période de la durée de vie de l’objet (attente
d’un évènement, ou action).
Un état se caractérise par sa durée et sa stabilité, il représente
une conjonction instantanée des valeurs des attributs d’un
objet
Les états sont représentés par des rectangles aux coins arrondis


État global
Le jeu des États(de l’automate d’États finis) actifs à un moment
donné.
état initial, état final

État initial : pseudo-état de départ. L’objet est crée, il rentre
dans l’état initial.
État final :pseudo-état qui indique que le diagramme état
transition est fini.
transition
Une transition représente le passage instantané d’un état vers un
autre
Les transitions sont représentées par des arcs orientés liant les états
entre eux.
événement
Une transition est déclenchée par un événement : c’est l’arrivée
d’un événement qui conditionne la transition
action
Une action est exécutée sur l’objet spécifié à l’entrée du nouvel état
Z Transitions automatiques : événement déclenchant non spécifié

Z possibilité de conditionner une transition, à l’aide de "gardes" :
expressions booléennes, exprimées en langage naturel
Z possibilité de spécifier un paramètre à l’évènement

Les diagrammes d’états transitions : Représentation 12
diagramme d’états transitions

L’organisation des états et des transitions pour un classeur donné
est représentée dans un diagramme d’états-transitions.
Le modèle dynamique comprend plusieurs diagrammes d’états.

Attention : Chaque diagramme d’états ne concerne qu’une
seule classe.
Chaque automate à états finis s’exécute concurremment et
peut changer d’état de façon indépendante des autres.

Etat initial
évènement
Etat final
évènement (paramètre)
évènement[Cond]
État intermédiaire État intermédiaire
évènement
évènement/action
Etat final


Exemple : Interrupteur d’une lampe
on
Allumé
on off
Eteint
off
si la lampe est dans l’état « Allumé », l’évènement « off » la
fait passer à l’état « Eteint »
si la lampe est dans l’état « Eteint », l’évènement « on » la
fait passer à l’état « Allumé »

Exemple : diagramme d’états d’un réveil
On veut modéliser un réveil matin qui dispose de trois
boutons : alarm on/off, arrêt de la sonnerie et réglage de
l’alarme.
A tout moment, le réveil dispose d’une heure d’alarme, l’heure
à laquelle il doit sonner
Chaque appui sur les boutons constitue un événement qui
déclenche une transition, si le réveil était dans un état sensible
à l’événement.


Exemple de diagramme d’états-transitions
créée
ouverte
normal maximisée
maximiser()
init2
maximiser()
init1
positionner()
H
dimensionner() History
minimiser() minimiser()
minimisée

Evénement déclencheur
Les transitions d’un diagramme d’états-transitions sont déclenchées
par des événements déclencheurs qui peuvent être :
événement de type call généré par l’ appel de méthode sur
l’objet courant .
événement de type change généré implicitement par le passage
de faux à vrai de la valeur de vérité d’une condition booléenne
événement de type signal généré par la réception d’un signal
asynchrone, explicitement émis par un autre objet
un événement de type after généré par l’écoulement d’une
durée déterminée après un événement donné . Par défaut, le
temps commence à s’écouler dès l’entrée dans l’état courant.

Evénements call et signal

Syntaxe :
nomEvenement(params)
Chaque paramètre a la forme :
param:ClasseParam
événements de type : méthodes déclarées au niveau du
diagramme de classes.
signaux : déclarés par la définition d’une classe portant le
stéréotype signal, ne fournissant pas d’opérations, et dont les
attributs sont interprétés comme des arguments.

Evénements change et after

Syntaxe de change :
when(conditionBooleenne))
Il prend la forme d’un test continu et se déclenche
potentiellement à chaque changement de valeurs des variables
intervenant dans la condition.
Syntaxe de after :
after(duree)
Le paramètre s’évalue comme une durée, par défaut écoulée
depuis l’entrée dans l’état courant.


Transition conditionnelle
Syntaxe :
nomEvenement(params) [garde] / activite
indique qu’une instance peut changer d’état et exécuter
certaines activités, si un événement déclencheur se produit et
que les conditions de garde sont vérifiées.
garde : condition qui doit être remplie pour pouvoir déclencher
la transition,
activité : instructions
[cond] à effectuer .
Etat 1 Etat 2a
[non cond]
Etat 2b

Point de décision
Les points de jonction
pseudo-états particuliers (petit cercle plein) permettant de
partager des segments de transition.
Objectifs : représenter des alternatives pour le franchissement
d’une transition.
un raccourci d’écriture permettant des représentations plus
compactes.
Les points de choix

Les points de choix (losange) sont plus que des raccourcis
d’écriture.


Point de décision
e1[a>0 and b<0]

Etat 1
e1[a
>0 a Etat 3
e1 nd b
[a > =0]
0a
nd
b>
0 ] Etat 4
]
<0
n db
0a =0]
2 [a> nd b
e 0 a Etat 5
>
Etat 2 e2[a
0]
e2[a>0 and b>


Point de décision
[b>0]
Etat 3
Etat 1 e1[a>
0]
[b=0]
Etat 4
>0]
Etat 2 e2[a [b<0]
Etat 5


Point de jonction :Exemple
Inscrire étudiant à matière
/afficher
[étudiant trouvé] code étudiant
Chercher étudiant inscrire étudiant
[étudiant non trouvé]

créer étudiant


Point de jonction :Exemple
Réception Message Vocal Réception Message SMS Réception Message Fax
[Réponse=SMS] [Réponse=voix] [Réponse=Fax]
Création Message Vocal Création Message SMS Création Message Fax

Utilisation des points de choix

Les gardes après le point de choix sont évaluées au moment où il
est atteint.
Cela permet de baser le choix sur des résultats obtenus en
franchissant le segment avant le point de choix.
Si, quand le point de choix est atteint, aucun segment en aval
n’est franchissable, le modèle est mal formé.
Contrairement aux points de jonction, les points de choix ne
sont pas de simples racourcis d’écriture.


Exemple
Saisie Ok/validerEntree() [Entrée valide] Demander

formulaire confirmation
[Else]
Afficher
problème


Exemple
Création Message Vocal

[voix]
Sélection Format Message Création Message SMS

[SMS]
Création Message Fax

[fax]

Les diagrammes d’états transitions : 29
Actions dans un état-Transition interne)

Un objet reste dans un état durant une certaine durée et des
transitions internes peuvent intervenir.
Une transition interne ne modifie pas l’état courant, mais suit
globalement les règles d’une transition simple entre deux états.
Chaque transition interne est décrite selon la syntaxe suivante :
nomEvenement(params) [garde] / activiteARealiser

Actions dans un état-Transition interne

Les actions propres à un état peuvent être documentées
directement à l’intérieur de l’état
UML définit un certain nombre de champs qui permettent de
décrire les actions dans un état :
entry / action : action exécutée à l’entrée de l’état
exit / action : action exécutée à la sortie de l’état
on événement / action : action exécutée à chaque fois que
l’événement cité survient
do / action : action récurrente ou significative, exécutée dans
l’état


Évènement réflexif
L’évènement peut arriver plusieurs fois et les actions doivent être à
chaque fois exécutées
rencontre
entry/bonjour
exit/au revoir
salut/serrer main

Les diagrammes d’états transitions : Super état 32

Super état(Etat composite)
état qui englobe d’autres états et transitions
permet de structurer les diagrammes d’états-transitions
Permet de factoriser les transitions de sortie du composite
→ Chaque transition de sortie s’applique à tous les sous-états
Une seule transition d’entrée
E1
SE1 T1
E2
T3
T2
SE1


Composer numéro
Debut Numéroter
[numero.valide()]
entry/tonalité « prêt » chiffer(n) entry/numero.append(n)
exit/cesser tonalité
chiffer(n)


Vérifier PIN
Entrer PIN
/vérifier PIN [pin invalide]
[pin OK]
éteindre
[pin OK]
Rechercher réseau
éteindre
réseau trouvé
Prêt Eteint
éteindre


Verifier PIN
[pin OK] éteindre
Rechercher réseau
éteindre
réseau trouvé
Prêt Eteint
éteindre



Etats composites et états initiaux/finaux

Les transitions peuvent avoir pour cible la frontière d’un état
composite. Elle sont alors équivalentes à une transition ayant
pour cible l’état initial de l’état composite.
Une transition ayant pour source la frontière d’un état
composite est équivalente à une transition qui s’applique à
tout sous-état de l’état composite source.


Etats composites et états initiaux/finaux
créée
ouverte
normal maximisée
maximiser()
init2
maximiser()
init1
positionner()
H
dimensionner() History
minimiser() minimiser()
minimisée

Historique
Par défaut un automate n’a pas de mémoire
Un pseudo-état historique est noté par un H cerclé.
la notation H offre un mécanisme pour mémoriser le dernier
sous-état visité et pour le rejoindre lors d’une transition
entrant dans le super-état qui l’englobe
Une transition ayant pour cible le pseudo-état historique est
équivalente à une transition qui a pour cible le dernier état
visité dans la région contenant le H.


generalisation
+60 ans
En activité
Retraite
Perte d'emploi embauche
+60 ans
Chômage


generalisation
En activité
+60 ans
Perte d'emploi embauche Retraite
Chômage

États concurrents
Dans un même état, plusieurs automates peuvent s’exécuter
en parallèle
L’exécution d’un automate peut être contrainte par l’exécution
d’un autre
L’exécution peut-être synchronisée
Un objet peut alors être simultanément dans plusieurs états
concurrents.


Exemple états concurrents
A
B C
BE1 CE1
T4
T1 T2
T3
T5
BE2
CE2
BE3 T6
T7


Exemple contraintes
A
B C
BE1 CE1
T4[in CE1]
T1 T2
T3
T5
BE2
CE2
BE3 T6
T7


Exemple synchronisation
Une transition fork correspond à la création de deux états
concurrentes.
Une transition join correspond à une barrière de
synchronisation qui supprime la concur-
fork join
E2 E4
T1
E4
E4 E5

Les diagrammes d’états transitions : Quelques conseils 46
Pas de transition sans événement

L’automate doit en général être déterministe
Si plusieurs transitions partant d’un état ont le même
événement, alors il doit y avoir des gardes qui garantissent le
déterminisme
Tous les états doivent être accessibles depuis l’état initial
S’il y a des états terminaux alors, pour chaque état non
terminal, il doit exister un chemin de cet état vers un état
terminal (...en général)

Les diagrammes d’états transitions : Quelques conseils 47
Seuls les états quelque peu stables sont pertinents

Les attributs constants (possédant toujours la même valeur
une fois que l’objet est construit) n’interviennent pas dans la
recherche des états
Les attributs qui changent de valeur aident souvent à déduire
les états possibles
→ C’est le cas les attributs booléens
Il est souvent intéressant d’insérer de manière systématique un
état de création de l’objet (initialisation des attributs) et un
état de destruction
Une attention particulière est à porter sur les événements et
les actions

Plan 48

Les Diagrammes d’UML 49

Diagramme
Diagramme Diagramme
De structure comportemental
Diagramme Diagramme Diagramme Diagramme Diagramme de

de classes de packages de d'objets d'activités Cas d'utilisation
Diagramme Diagramme Diagramme de Diagramme Diagramme de

de composants de déploiement Structure composite d'interaction Transition d'état
Diagramme Diagramme de
De séquence communication
Diagramme Diagramme
Vue d'ensemble De timing
Des interactions

Les diagrammes d’activités 50
Variante des diagrammes d’états-transitions

présente un certain nombre de points communs avec le
diagramme d’état-transition
seulement celui-ci se focalise sur les transitions et les activités
il concerne le comportement interne des opéra- tions ou des
cas d’utilisation.
Cependant le comportement visé ici s’applique aux flots de
contrôle et aux flots de données propres à un ensemble
d’activités et non plus relativement à une seule classe.

Les diagrammes d’activités s’utilisent dans l’analyse

fonctionnelle pour décrire le fonctionnement externe du
système (vue du point de vue de l’utilisateur).
On peut par exemple l’utiliser pour préciser le comportement
d’un cas d’utilisation avec tous ses scénarios alternatifs.
Diagramme d’activité utile pour la représentation des processus
métiers et des cas d’utilisation.


Les diagrammes d’activités permettent de mettre l’accent sur

les traitements
leur représentation sous forme d’organigrammes les rend
facilement intelligibles et beaucoup plus accessibles que les
diagrammes d’états-transitions.
Au niveau macroscopique, les diagrammes d’activités permettent de

décrire les enchaînements de fonctionalités. Ils complétent donc
bien les cas d’utilisation au niveau de l’analyse des besoins.
Au niveau microscopique, les diagrammes d’activités permettent,

par exemple, de décrire l’algorithme d’une action d’un
diagramme d’états.

concepts communs ou très proche entre DET et DA

transition
nœud initial (état initial),
nœud final (état final)
nœud de fin flot (état de sortie),
nœud de décision (choix).
⇒ formalisme identique pour ces nœuds de contrôle.

concepts spécifiques au diagramme d’activité :

nœud de bifurcation,
nœud de jonction,
nœud de fusion,
pin d’entrée et de sortie,
flot d’objet,
partition.

Action
traitement qui modifie l’état du système ou en extrait une
information
La notion d’action proche de la notion d’instruction
élémentaire d’un langage de programmation.
Les actions sont des étapes discrètes à partir desquelles se
construisent les comportements.

Exemple d’action
une affectation de valeur à des attributs ;
un accès à la valeur d’une propriété structurelle (attribut ou
terminaison d’association) ;
la création d’un nouvel objet ou lien ;
un calcul arithmétique simple ;
l’émission d’un signal ;
la réception d’un signal ;
...

types d’actions prédéfinis dans la notation UML.

Action appeler (call operation)
invocation d’une opération sur un objet de manière synchrone
ou asynchrone.
Lorsque l’action est exécutée, les paramètres sont transmis à
l’objet cible.
Si l’appel est asynchrone, l’action est terminée et les
éventuelles valeurs de retour seront ignorées.
Si l’appel est synchrone, l’appelant est bloqué pendant
l’exécution de l’opération et, le cas échéant, les valeurs de
retour pourront être réceptionnées.


Action comportement (call behavior )
variante de l’action call operation
elle invoque directement une activité plutôt qu’une opération.
Action envoyer (send )

Cette action crée un message et le transmet à un objet cible,
où elle peut déclencher un comportement.
Il s’agit d’un appel asynchrone (i.e. qui ne bloque pas l’objet
appelant) bien adapté à l’envoi de signaux (send signal).


Action accepter événement (accept event)
L’exécution de cette action bloque l’execution en cours jusqu’à
la réception du type d’événement spécifié, qui généralement
est un signal.
Cette action est utilisée pour la réception de signaux
asynchrones.
Action accepter appel (accept call)

Il s’agit d’une variante de l’action accept event pour les appels
synchrones.


Action répondre (reply)
Cette action permet de transmettre un message en réponse à
la réception d’une action de type accept call.
Action créer (create)

Cette action permet d’instancier un objet.
Action détruire (destroy)

Cette action permet de détruire un objet.
Action lever exception (raise exception)

Cette action permet de lever explicitement une exception.


Actions : Formalisme et exemple
Une action est représentée par un rectangle dont les coins sont
arrondis comme pour les états du diagramme d’état-transition
Commander un produit
Régler la facture
Expédier le produit Gérer la commande
Recevoir le produit


Transition et flot de contrôle
Dès qu’une action est achevée, une transition automatique est
déclenchée vers l’action suivante. Il n’y a donc pas
d’événement associé à la transition.
L’enchaînement des actions constitue le flot de contrôle.
transition
action1 action2

Activité
Une activité représente le comportement d’une partie du
système en termes d’actions et de transitions.
Une activité est composée de trois types de nœuds :
nœud d’exécution(action,transition),
nœud de contrôle (nœud initial, nœud final, flux de sortie,
nœud de bifurcation, nœud de jonction, nœud de fusion-test,
nœud de test-décision, pin d’entrée et de sortie),
nœud d’objet.
Une activité peut recevoir des paramètres en entrée et en
produire en sortie.


Formalisme et exemple d’activité
Activité : traiter commande
Saisir Contrôler Editer

Commande Commande Commande

Groupe d’activités (activity group)

Groupe d’activités
Un groupe d’activités est une activité regroupant des nœuds et des
arcs.
Les nœuds et les arcs peuvent appartenir à plus d’un groupe.

Un diagramme d’activités est lui même un groupe d’activités.


Nœud d’activité (activity node)
Nœud d’activité
Un nœud d’activité est une étape le long du flot d’une activité. Il
existe trois familles de nœuds d’activités :
les nœuds d’exécutions (executable node ) ;
les nœuds objets (object node ) ;
et les nœuds de contrôle (control nodes ).
Nœud d'action Nœud d'objet
Noeud s de contrôle

Nœud exécutable (executable node)
Nœud exécutable (executable node)

un nœud exécutable est un nœud d’activité qu’on peut exécuter.
Possède un gestionnaire d’exception qui peut capturer les

exceptions levées par le nœud, ou un de ses nœud, imbriquées.
nœud d’action.
nœud d’activité structurée.


Nœud d’action
Nœud d’action
Unité fondamentale de fonctionnalité exécutable dans une

activité.
Les actions sont généralement liées à des opérations qui sont
directement invoquées.
Doit avoir au moins un arc entrant.
Commander un produit
Régler la facture
Expédier le produit Gérer la commande

nœud d’activité structurée (structured activity node)

Portion structurée d’une activité donnée qui n’est partagée
avec aucun autre nœud structuré.
Graphiquement, le contour d’un nœud d’activité structurée est
en pointill".
Les transition d’une activité structurée doivent avoir leurs
nœuds source et cible dans le même nœud d’activité
structurée.
Les nœud et les arcs arcs contenus par nœud d’activité
structuré ne peuvent pas être contenus dans un autre nœud
d’activité structuré.

Nœud de contrôle
Un nœud de contrôle est un nœud d’activité abstrait utilisé pour
coordonner les flots entre les nœud d’une activité.
nœud initial (initial node en anglais) ;

nœud de fin d’activité (final node en anglais)
nœud de fin de flot (flow final en anglais) ;
nœud de décision (decision node en anglais) ;
nœud de fusion (merge node en anglais) ;
nœud de bifurcation (fork node en anglais) ;
nœud d’union (join node en anglais).


Nœud de bifurcation (fourche) ou de débranchement (fork node)
Un nœud de bifurcation (fourche) permet à partir d’un flot unique
entrant de créer plusieurs flots concurrents en sortie de la barre de
synchronisation.
Formalisme et exemple

Nœud d’union ou de jointure (join node)

Un nœud d’union, nœud de contrôle qui synchronise des flots
concurrents en entrée en un flot unique sortant.
Un tel nœud possède donc plusieurs arcs entrants et un seul
arc sortant.
Lorsque tous les arcs entrants sont activés, l’arc sortant l’est
également.
Le nœud de jonction est le symétrique du nœud de bifurcation.

Formalisme et exemple


Un Nœud de test-décision
permet de faire un choix entre plusieurs flots sortants en
fonction des conditions de garde de chaque flot.
un seul flot en entrée et plusieurs arcs sortants.
On peut aussi utiliser seulement deux flots de sortie : le
premier correspondant à la condition vérifiée et l’autre traitant
le cas sinon.
les arcs sortants sont généralement accompagnés de conditions
de garde pour conditionner le choix.
Si, quand le nœud de décision est atteint, aucun arc en aval
n’est franchissable (i.e. aucune condition de garde n’est vraie),
c’est que le modèle est mal formé.


exemple
Examen candidature
[Rejet Canditaure] [Acceptation Canditaure]
Lettre de refus Convocation
transition
Entretien

Nœud de fusion-test(merge node)

Un Nœud de fusion-test est un nœud de contrôle qui rassemble
plusieurs flots alternatifs entrants en un seul flot sortant.
Il n’est pas utilisé pour synchroniser des flots concurrents
(c’est le rôle du nœud d’union) mais pour accepter un flot
parmi plusieurs.
Le flot sortant est donc exécuté dès qu’un des flots entrants
est activé.


exemple
contacter par téléphone
contacter par SMS inscrire
contacter par courrier

Pin d’entrée ou de sortie

paramètre que l’on peut spécifier en entrée ou en sortie d’une
action. Un nom de donnée et un type de donnée peuvent être
associés au pin.
Un paramètre peut être de type objet.
L’activité ne peut déuter que si l’on affecte une valeur à
chacun de ses pins d’entrée.
Quand l’activité se termine, une valeur doit être affectée à
chacun de ses pins de sortie.
Les valeurs sont passées par copie : une modification des
valeurs d’entrée au cours du traitement de l’action n’est visible
qu’à l’intérieur de l’activité.


exemple
pin d’entrée ou de sortie
x:int
res=x+y res:int
y:int

Pin de valeur (value pin)

Un pin valeur est un pin d’entrée qui fournit une valeur à une
action sans que cette valeur ne provienne d’un arc de flot
d’objets.
Un pin valeur est toujours associé à une valeur spécifique.
Graphiquement, un pin de valeur se représente comme un pin
d’entrée avec la valeur associée écrite à proximité.

Flot d’objet
Un nœud d’objet permet de représenter le flot de données
véhiculé entre les actions.
Les objets peuvent se représenter de deux manières
différentes : soit en utilisant le pin d’objet soit en représentant
explicitement un objet.
le type du pin récepteur doit être identique ou parent (au sens
de la relation de généralisation) du type du pin émetteur.
On peut également préciser des contraintes entre accolades,
soit à l’intérieur, soit en dessous du rectangle du nœud d’objet.

Nœud de fin d’activité

Lorsque l’un des arcs d’un nœud de fin d’activité est activée,
l’exécution de l’activité enveloppante s’achève.
Si l’activité a été invoquée par un appel synchrone, un
message contenant les valeurs sortantes est transmis en retour
à l’appelant.
Nœud de fin de flot

Lorsqu’un flot d’exécution atteint un nœud de fin de flot, le
flot en question est terminé, mais cette fin de flot n’a aucune
incidence sur les autres flots actifs de l’activité enveloppante.
Les nœuds de fin de flot sont particuliers et à utiliser avec
parcimonie.


exemple
Flot de données
Action 1 Action 2
: type1 : type1
Nœud d'objet
Action 1 [Type 1] Action 2
{contrainte}


Des extensions aux diagrammes d’activité ont été proposées pour
représenter aussi l’organisation(style MOT avec des couloirs ou
swimlane
Les partitions, souvent appelées couloirs ou lignes d’eau
(swimlane) permettent d’organiser les nœuds d’activités dans
un diagramme d’activités en opérant des regroupements
L’ordre des couloirs de responsabilité n’est pas significatif.
Les partitions correspondent à des unités d’organisation du
modèle. On peut, par exemple, les utiliser pour spécifier la
classe responsable de la mise en œuvre d’un ensemble tâche.
les partitions sont délimitées généralement par des lignes
continues verticales mais elle peuvent être horizontales ou
même courbes.




Les diagrammes d’activités : 89

Exemple

Equivalence diagramme d’état et diagramme d’activité 90

Diagramme d’activité du « save as »

Equivalence diagramme d’état et diagramme d’activité 91

Diagramme d’état du « save as »

Résumé 92
Z Modèle permettent appréhender la réalisation d’un système

informatique
Z Diagrammes UML permettent d’aider à la réflexion, à la
discussion (clients, architectes, développeurs, etc.)
Z Pas de solution unique mais un ensemble de solutions plus ou
moins acceptables suivant les contraintes du client, et les
logiciels et matériels disponibles
Z Une solution acceptable est obtenue par itérations successives

MERISE vs UML 93
Z Merise et UML permettent entre autre de modéliser les

données
Z MERISE : approche disjointe et parallèle des données et des
traitements (modèles spécifiques).
Z UML : approche objet qui intégre données et traitements
(approche composants).
Z UML est un langage de modélisation
Z MERISE propose un langage ET une méthode

MERISE vs UML 94
Z Solution UML :
centrée sur les besoins utilisateurs (cas d’utilisation),
itérative et incrémentale,
le même concept d’objet peut parcourir tout le cycle
d’abstraction.
Z démarche MERISE :
proche du cycle de développement en cascade (on procède une
phase après l’autre),
conduite par les différents modèles proposés

MERISE & UML 95
Z Merise méthode de conception plus orienté vers la

compréhension et formalisation de besoins et la description de
la solution(acteurs/flux, MCT/MOT, MCD/MLD) que vers la
production logicielle
Z Merise reste très utilisé pour la modélisation des BD
relationnelles(MCD,MLD) uml est très adapté pour concevoir
et développer des systèmes logiciels développes dans des
langages objets (Java, J2EE, VB,C#,.NET)
Z UML est orienté principalement vers la conception et le
developpement de système logiciels dans des langages objets
Merise et UML apparaissent plus complémentaires que concurrents

MERISE & UML 96
Z Des éléments de Merise et de UML peuvent très bien être

utilisés ensemble
Z Exemple : Apllication Web/BD
cahier de charges avec les cas d’utilisation UML
conception de la base de données avec
Z Merise et UML apparaissent plus complémentaires que
concurrents

Slides UML Etat Transitions Activites

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Slides UML Etat Transitions Activites

Transféré par

Droits d'auteur :

Formats disponibles

Les diagrammes d’états transitions (vue dynamique)

Les diagrammes d’activités

Diagramme état-transitions / Diagrammes

David Célestin FAYE

David Célestin FAYE Modélisation avec UML 1/96

1 Les diagrammes d’états transitions (vue dynamique)

2 Les diagrammes d’activités

David Célestin FAYE Modélisation avec UML 2/96

1 Les diagrammes d’états transitions (vue dynamique)

2 Les diagrammes d’activités

David Célestin FAYE Modélisation avec UML 3/96

Les Diagrammes d’UML 4

Diagramme Diagramme Diagramme Diagramme Diagramme de

Diagramme Diagramme Diagramme de Diagramme Diagramme de

David Célestin FAYE Modélisation avec UML 4/96

Les diagrammes d’états transitions : généralités 5

Z Ils présentent la vue dynamique d’un système

David Célestin FAYE Modélisation avec UML 5/96

Les diagrammes d’états transitions : sémantique 6

David Célestin FAYE Modélisation avec UML 6/96

Les diagrammes d’états transitions : sémantique 7

Ici l’objet Etudiant peut passer d’un état Etudiant à un état de

David Célestin FAYE Modélisation avec UML 7/96

Les diagrammes d’états transitions : sémantique 8

Notion d’automate à états finis

David Célestin FAYE Modélisation avec UML 8/96

Les diagrammes d’états transitions : sémantique 9

David Célestin FAYE Modélisation avec UML 9/96

Les diagrammes d’états transitions : sémantique 10

état initial, état final

Les diagrammes d’états transitions : sémantique 11

Z Transitions automatiques : événement déclenchant non spécifié

David Célestin FAYE Modélisation avec UML 11/96

Les diagrammes d’états transitions : Représentation 12

diagramme d’états transitions

Le modèle dynamique comprend plusieurs diagrammes d’états.

David Célestin FAYE Modélisation avec UML 12/96

Les diagrammes d’états transitions : Représentation 13

David Célestin FAYE Modélisation avec UML 13/96

Les diagrammes d’états transitions : Représentation 14

Les diagrammes d’états transitions : Représentation 15

David Célestin FAYE Modélisation avec UML 15/96

Les diagrammes d’états transitions : Représentation 16

David Célestin FAYE Modélisation avec UML 16/96

Les diagrammes d’états transitions : Représentation 17

David Célestin FAYE Modélisation avec UML 17/96

Les diagrammes d’états transitions : Représentation 18

Evénements call et signal

David Célestin FAYE Modélisation avec UML 18/96

Les diagrammes d’états transitions : Représentation 19

Evénements change et after

David Célestin FAYE Modélisation avec UML 19/96

Les diagrammes d’états transitions : Représentation 20

David Célestin FAYE Modélisation avec UML 20/96

Les diagrammes d’états transitions : Représentation 21

Les points de choix

David Célestin FAYE Modélisation avec UML 21/96

Les diagrammes d’états transitions : Représentation 22

e1[a>0 and b<0]

David Célestin FAYE Modélisation avec UML 22/96

Les diagrammes d’états transitions : Représentation 23

David Célestin FAYE Modélisation avec UML 23/96

Les diagrammes d’états transitions : Représentation 24