Langage de modélisation unifié UML en informatique de gestion

Transcription

Langage de modélisation unifié
UML
P.-A. Sunier
25 mars 2013
http://lgl.isnetne.ch
Table des matières
1
Propos liminaires ................................................................................................................ 2
2
Modèle de cas d'utilisation ................................................................................................. 3
3
2.1
Diagramme de cas d'utilisation .................................................................................... 3
2.2
Description du comportement de cas d'utilisation ....................................................... 5
2.2.1
Comportement perçu par l'acteur – Boîte noire ................................................... 6
2.2.2
Comportement réalisé à l'interne – Boîte blanche ................................................ 7
Modèle d'activité ................................................................................................................ 8
3.1
Choix d'illustration ...................................................................................................... 8
3.2
Diagramme d'activité ................................................................................................... 8
3.3
Organisation des flux ................................................................................................. 11
3.3.1
Choix et débranchements ................................................................................... 11
3.3.2
Optionalités et jointures ..................................................................................... 11
3.4
Choix organisationnels de l’entreprise ...................................................................... 12
4
Modèle d'interaction ......................................................................................................... 13
5
Modèle de machine à états ............................................................................................... 13
6
5.1
Les états ..................................................................................................................... 13
5.2
Les événements.......................................................................................................... 17
5.3
Actions et activités propres à un état ......................................................................... 18
5.4
Les transitions ............................................................................................................ 19
5.5
Eléments de factorisation........................................................................................... 20
5.6
Les états composites .................................................................................................. 21
5.6.1
Etat non orthogonal ........................................................................................... 21
5.6.2
Etat orthogonal ou concurrent ............................................................................ 23
Bibliographie .................................................................................................................... 25
1 Propos liminaires
Nous invitons le lecteur à prendre connaissance de notre document Bases du langage de
modélisation unifié UML [PAS-8]; ce document fait office d'introduction à UML et à notre
vision de son utilité pour le développement de logiciels de gestion.
Nous nous limitons volontairement dans cette présentation du langage UML aux modèles et
diagrammes qui nous semblent les plus pertinents en informatique de gestion.
Langage de modélisation unifié UML
2/25
P-A. Sunier
2 Modèle de cas d'utilisation
Le modèle de cas d'utilisation permet de spécifier les fonctions attendues d'un système.
Un diagramme de cas d'utilisation montre le système offrant des services à son
environnement; l'environnement est représenté par des acteurs.
Les termes fonctions et services utilisés ci-avant sont des synonymes de Cas d'utilisation qui
est peut-être un terme obscure.
2.1 Diagramme de cas d'utilisation
Un diagramme de cas d'utilisation permet de visualiser synthétiquement les services offerts
par un système; toutefois, un ou des diagrammes ne suffisent pas, il y aura lieu de décrire
avec précision le comportement du cas d'utilisation. Si le seul nom donné à un acteur ne suffit
pas à expliquer son rôle ou sa responsabilité, il y a lieu de le documenter.
Figure 1- Diagramme représentant les services offert par le SII de l'institution Arc en ciel
3/25
P-A. Sunier
Avant d'expliquer la lecture du diagramme de la Figure 1, il nous faut décrire Arc en Ciel et
son organisation de gestion des événements.
Arc en Ciel est une institution qui permet à de jeunes gens légèrement
handicapés d’acquérir une formation professionnelle de base.
En plus de la formation professionnelle, Arc en Ciel assure un encadrement
sociologique et éducatif.
Tout événement significatif impliquant un jeune ou un groupe de jeunes est
saisi par le collaborateur ayant connaissance dudit événement
Lorsqu'un événement est de gravité importante le SII doit en informer les
membres de la direction de l'institution.
Tout collaborateur peut participer à une discussion initiée par un événement
en émettant une ou des remarques.
Naturellement, seuls les collaborateurs dûment autorisés peuvent créer des
événements et émettre des remarques.
Dans notre diagramme de la Figure 1, nous pouvons observer les éléments essentiels de
modélisation:
1

Le conteneur nommé System par défaut et représentant la partie du SII que nous
avons modélisé sous forme de cas d'utilisation.

Les cas d'utilisation qui sont les fonctions ou services offerts par le SII.
Les cas d'utilisation peuvent être spécialisés; Saisir un év. individuel est une
spécialisation de Saisir un événement.
Saisir un événement est une généralisation de Saisir un év. individuel et de Saisir
un év. collectif.

Les acteurs qui sont les bénéficiaires directs ou indirects des services offert par le SII.
Les acteurs sont qualifiés de principal lorsqu'ils sollicitent le SII et en obtiennent un
résultat; l'acteur Collaborateur est l'acteur principal du cas d'utilisation Saisir un év.
individuel et par contre, l'acteur f() de direction en est un acteur secondaire.
Les acteurs peuvent être spécialisés tout comme les cas d'utilisation; une f() de
direction est un1 Collaborateur.

Les liens de communication qui permettent aux acteurs principaux d'invoquer les cas
d'utilisation, à leur tour, les cas d'utilisation peuvent donner un résultat aux acteurs
secondaires.

Les associations «include» et «extend» entre cas d'utilisation.
L'association «include» oblige à utiliser un cas d'utilisation; le cas d'utilisation
Plus rigoureusement, il y aurait lieu de dire: "Une f() de direction est une sorte de collaborateur".
4/25
P-A. Sunier
Emettre une remarque doit obligatoirement faire appel au cas d'utilisation
S'identifier.
L'association «extend» va étendre un cas d'utilisation si la condition d'extension est
satisfaite; le cas d'utilisation Saisir un événement va s'étendre à Informer f() de
direction si l'événement est grave.
2.2 Description du comportement de cas d'utilisation
Le comportement de cas d'utilisation peut être décrit en tant que boîte noire, ce que l'acteur
perçoit du comportement et en tant que boîte blanche, ce que le système réalise comme
comportement.
Les deux visions du comportement peuvent être décrites textuellement ou à l'aide de
modèles/diagrammes dynamiques.
A notre sens, un diagramme de séquence est un bon choix pour montrer le comportement sous
forme de boîte noire et un diagramme de communication ou d'activité est pertinent pour
montrer le comportement sous forme de boîte blanche.
Pour illustrer ce concept de boîte noire et de boîte blanche, nous reprenons le cas ArcPizzas
du document d'introduction [PAS-8].
Figure 2 - Diagramme du cas d'utilisation Dispatcher commande
d'ArcPizzas
5/25
P-A. Sunier
2.2.1 Comportement perçu par l'acteur – Boîte noire
Le diagramme de séquence cicontre montre le service offert
par le système lorsque l'acteur
Caissier utilise le cas
d'utilisation Attribuer livreur
de la Figure 2.
Nous ne montrons que:
- les messages échangés entre
l'acteur et le système;
- les messages que le système
s'envoie à lui-même pour
répondre aux sollicitations
de l'acteur.
L'extrême simplicité du
diagramme de séquence, boîte
noire, permet de nous
concentrer sur les 2 aspects
essentiels que sont:
- les résultats attendus par
l'acteur (les messages en
retour du système);
- les opérations que devra
effectuer le système pour
répondre aux sollicitations
de l'acteur (les messages
que s'envoie le système).
Ce diagramme est utilisé dans
le dialogue avec la maîtrise
d'ouvrage (utilisateurs) pour
convenir de ce que le système
devra offrir comme service.
Figure 3 - Diagramme de séquence structuré du cas d'utilisation
Attribuer livreur
6/25
P-A. Sunier
2.2.2 Comportement réalisé à l'interne – Boîte blanche
Le diagramme de communication ci-dessous montre les éléments constitutifs du système qui
vont réaliser le service spécifié par le diagramme de séquence de la Figure 3. Les messages
échangés entre l'acteur et le système sont pris en charge par un écran; les messages internes
au système sont représentés par une collaboration entre formulaires, contrôleurs et entités de
données.
Figure 4 - Diagramme de communication montrant la réalisation du cas d'utilisation Attribuer livreur
Dans un diagramme de communication pratiqué en analyse2, nous ne montrons que 3 "sortes"
d'objets en plus des acteurs:
-
Les interfaces hommes/machines3 (boundary) qui permettent aux acteurs d'interagir
avec le système (informatique).
Les contrôleurs (controler) qui vont réaliser les traitements nécessaires à répondre aux
sollicitations des acteurs.
Les entités (entity) qui vont assurer la persistance des données.
Ce diagramme est utilisé dans le dialogue au sein de la maitrise d'œuvre (analystes,
concepteurs, développeurs) pour convenir de la manière dont le système sera réalisé et
comment les différentes parties communiquent.
2
3
Spécification des modalités de réalisation "informatique" d'un cas d'utilisation.
Ecrans, claviers, souris, formulaires…
7/25
P-A. Sunier
3 Modèle d'activité
Le modèle d'activité représente la dynamique interne ou le comportement, sous forme
d'enchaînement d'activités et/ou d'actions d'un processus, d'un traitement ou de manière plus
générale de toute activité que l'on désire décrire.
3.1 Choix d'illustration
A notre sens et en informatique de gestion, le
diagramme d'activité est particulièrement pertinent
pour décrire un cas d'utilisation métier. Lorsque
l'on parle de cas d'utilisation métier, le système
auquel l'on s'intéresse n'est pas le système
d'information de l'entreprise mais, l'entreprise en
tant que système et tout particulièrement son
système opérant qui est le métier de l'entreprise;
les acteurs proviennent de l'environnement de
l'entreprise, ce sont ses clients, fournisseurs,
partenaires…; les cas d'utilisation sont les services
offerts par l'entreprise à son environnement.
Figure 5 - Entreprise-système et son soussystème d'information
3.2 Diagramme d'activité
Pour présenter le modèle d'activité, nous reprenons le cas pratique ArcPizzas [PAS-20] et
plus particulièrement le diagramme d'activité décrivant le cas d'utilisation Commander une
pizza qui permet à un client de passer une commande.
Ce diagramme, Figure 6, est particulièrement intéressant car il nous permet de décrire les
choix organisationnels d'ArcPizzas permettant de faire le lien entre le traitement de
l'information comme "recevoir une commande d'un client" et les opérations métier comme
"fabriquer une pizza par le pizzaiolo".
Nous nous appuyons sur la Figure 6 pour décrire les éléments essentiels du modèle d'activité:

Les activités ou actions qui sont des parties de l'activité globale qu'il s'agit de décrire;
sans que cette terminologie ne soit utilisée, on pourrait dire qu'une activité est décrite
dans un diagramme sous forme de sous-activités et actions reliées entre elles par des
flux de contrôle ou d'objets. L'activité Prendre commande guichet, sous la
responsabilité du caissier, est une partie de l'activité déployée par l'entreprise pour
réaliser le cas d'utilisation Commander une pizza.
8/25
P-A. Sunier

Les flux4 de contrôle qui montrent le passage d'une activité/action à une autre. De par
les choix organisationnels d'ArcPizzas, nous n'avons pas de flux de contrôle entre
activités/actions. Par contre, nous développons cela plus en détail au chapitre 0.
Figure 6 - Diagramme d'activité (partiel) décrivant le cas d'utilisation métier Commander une pizza

Les objets qui vont faire office de "relai" pour passer d'une activité à une autre; l'objet
Ticket à fabriquer va servir de relai entre le SII et le pizzaiolo.

Les flux d'objets qui montrent la consommation, production ou transformation
d'objets par les activités/actions; le SII produit l'objet Ticket à fabriquer et le
transmet au pizzaiolo.

Les travées5 qui représentent les responsabilités en charge de chacune des
activités/actions; les responsabilités et la répartition des activités/actions relèvent de
choix d'organisation du système considéré; il appartient au caissier (responsabilité
Caissier) d'attribuer (activité Attribuer un livreur) un livreur pour les commandes à
livrer.
4
Certains auteurs parlent de flots au lieu de flux; à notre sens, le terme de flux nous semble approprié pour le
contrôle et le terme flot pour les objets. Par souci de simplification et par habitude, nous retenons le terme de
flux autant pour le contrôle que pour les objets.
5
Swimlane en anglais.
9/25
P-A. Sunier

Les choix qui permettent de séparer un flux sur la base de critères logiques; le choix
Livraison à domicile? va diriger le flux de contrôle vers l'activité Livrer domicile si
la réponse est Oui et Livrer client guichet si la réponse est Non. Oui et Non sont des
gardes; une garde autorise ou pas le flux de contrôle ou d'objet; une garde est notée
entre crochets, par exemple [Oui].

Les fusions ou optionalités6 qui permettent de fusionner des flux pour simplement
rendre les diagrammes plus faciles à lire. Les flux sortants des activités Prendre
commande guichet et Prendre commande téléphone mènent tout deux à la création
de l’objet Commande ; pour éviter de surcharger le diagramme, nous mettons le
symbole de fusion pour n’avoir qu’un seul flux menant à Commande.

Les débranchements7 qui permettent de paralléliser des flux de contrôle ou d’objets.
Le débranchement représenté dans la travée Client permet au caissier de délivrer la
pizza au client sans devoir simultanément lui donner le ticket ; le ticket peut être
donné avant, après ou en même temps.

Les jointures8 qui obligent la présence de l’ensemble des flux entrants pour passer la
barre de jointure ; en sortie de jointure, il peut y avoir plusieurs flux sortants. La
jointure représentée dans la travée Pizzaiolo oblige le pizzaiolo à ne fabriquer une
pizza seulement s'il dispose du ticket de fabrication et des ingrédients nécessaires.

Les nœuds de début et de fin qui fixent les bornes d'un diagramme d'activité. Il y a
toujours un nœud de début mais pas nécessairement de fin; il peut y avoir
graphiquement plusieurs nœuds de fin pour ne pas alourdir la représentation
graphique.
6
Merge en anglais
Fork en anglais
8
Join en anglais
7
10/25
P-A. Sunier
3.3 Organisation des flux
3.3.1 Choix et débranchements
OU
Sortie
ET
Sortie
La sortie d'un choix ne peut se faire que par les flux
dont la garde est franchissable.
En sortie du choix Livraison à domicile?, le
contrôle ira vers l'activité:
- Livrer domicile si la réponse est Oui;
- Livrer client guichet si la réponse est Non.
La sortie d'un débranchement amène à une
exécution parallèle de chacun des flux sortants.
En sortie du débranchement représenté dans la
travée Client, les objets Ticket et Pizza sont
délivrés parallèlement et sans préséance entre eux.
3.3.2 Optionalités et jointures
OU
Entrée
ET
Entrée
L'entrée dans une fusion ou optionalité ne requiert
qu'un des flux parmi ceux possibles.
Il suffit d'un des deux flux de contrôle sortants des
activités Prendre commande guichet ou Prendre
commande téléphone pour que la fusion menant à
la création d'une commande soit franchissable.
L'entrée dans une jointure ne peut se faire que
lorsque tous les flux entrants sont présents.
La jointure fait office de synchronisation entre
activités et/ou objets.
La jointure représentée dans la travée Pizzaiolo
oblige le pizzaiolo à ne fabriquer une pizza qu’à
condition qu’il dispose du ticket de fabrication et
des ingrédients nécessaires.
11/25
P-A. Sunier
3.4 Choix organisationnels de l’entreprise
Figure 7 - Flux d'objet (communication asynchrone)
Nous avons retenu comme choix
d'organisation du travail du
pizzaiolo de lui donner les ordres
de fabrication par l'intermédiaire
d'un ticket.
Le fait de passer par cet objet
Ticket permet une communication
asynchrone entre le pizzaiolo et le
SII ou le caissier; cette
communication asynchrone
permet au pizzaiolo de ne pas être
dérangé pendant qu'il confectionne
une pizza et au caissier de ne pas
dépendre de la disponibilité du
pizzaiolo pour transmettre sa
commande.
La Figure ci-contre montre un flux
de contrôle entre le caissier et le
pizzaiolo. Les deux collaborateurs
doivent se synchroniser pour que
le caissier puisse passer la
commande au pizzaiolo. La
synchronisation de communication
impliquerait très souvent que:
- le caissier dérange le pizzaiolo;
- le caissier doit attendre que le
pizzaiolo soit disponible.
Figure 8 - Flux de contrôle (communication synchrone)
12/25
P-A. Sunier
4 Modèle d'interaction
Nous prions le lecteur de se référer au chapitre Modèle d'interaction de notre cours Bases du
langage de modélisation unifié - UML [PAS-8] pour une explication du modèle d'interaction
et de sa déclinaison en modèle de séquence ou modèle de communication.
5 Modèle de machine à états
Nous prions le lecteur de se référer au chapitre Modèle de machine à état de notre cours
Bases du langage de modélisation unifié - UML [PAS-8] pour une explication des concepts
de base du modèle de machine à états.
Ci-après, nous nous attacherons plus particulièrement à décrire les éléments particuliers du
modèle et les modalités de l'utilisation de ce modèle en informatique de gestion.
Nous utiliserons très souvent dans la suite de ce chapitre le terme "objet"; dans notre vision
d'UML utilisé en informatique de gestion, le terme "objet" est à assimiler à "occurrence
d'entité".
5.1 Les états
L'état d'un objet résulte de la conjonction de la valeur de ses attributs et l'existence ou non de
liens vers d'autres objets.
Figure 9 - Partie du MCD relatif aux commandes
13/25
P-A. Sunier
A propos du MCD de la Figure 9:

Lors de la création d'une commande à livrer, CdeALivrer, la valeur de l'attribut
DateHreRechercheLivreur est nulle.

Lorsque le caissier choisit un livreur, le cas d'utilisation Attribuer livreur va créer le
lien attribue entre les occurrences d'entités CdeALivrer et Livreur.
Avant de se terminer, le cas d'utilisation Attribuer livreur va mettre la date et l'heure
courante dans l'attribut DateHreRechercheLivreur; ainsi, il sera possible de
déterminer si:
o la recherche d'un livreur a été effectuée et un livreur a été trouvé;
(attribut DateHreRechercheLivreur non nul +
lien attribue existe);
o la recherche d'un livreur a été effectuée et aucun livreur n'a été trouvé;
(attribut DateHreRechercheLivreur non nul +
lien attribue n'existe pas);
o la recherche d'un livreur n'a pas encore été effectuée;
(attribut DateHreRechercheLivreur nul +
lien attribue n'existe pas);

Si aucun livreur n'est disponible et que le client ne peut accepter de décaler l'heure de
livraison, le cas d'utilisation Attribuer livreur va mettre la date et l'heure courante
dans l'attribut DateHreAnnulation.

Lorsqu'un livreur est attribué et 30' avant l'heure de fin de cuisson, le cas d'utilisation
Dispatcher commande va créer une occurrence de TicketFabrication et l'associer à
Commande.
La structure de données relative à l'entité CdeALivrer ayant été explicitée, nous pouvons
maintenant expliciter les états de sa machine à états associée et représentée (partiellement) en
Figure 10:

L'état A traiter résulte de la création de la commande après que toutes les données
obligatoires ont été saisies.

L'état Livreur indisponible résulte d'une valeur dans l'attribut
DateHreRechercheLivreur et de l'absence de lien attribue.

L'état Commande annulée résulte d'une valeur dans l'attribut DateHreAnnulation.

L'état Livreur attribué résulte d'une valeur dans l'attribut
DateHreRechercheLivreur et de l'existence d'un lien attribue.

L'état Fabrication ordonnée résulte de l'existence d'un lien genere montrant qu'un
ticket de fabrication a été créé et envoyé au pizzaiolo.
Remarque: Une occurrence de Commande est créée automatiquement lors de la
création d'une occurrence de CdeALivrer; cette occurrence de Commande généralise
ou factorise les éléments (attributs et associations) communs à toutes les sortes de
commande telles qu'une commande par Internet, une commande au guichet ou encore
une commande téléphonique.
14/25
P-A. Sunier
Figure 10 - Diagramme de machine à états partielle de l'entité CdeALivrer
En certaines situations, il peut être utile d'enregistrer les états successifs des objets dans un
souci de traçabilité; pour notre gestion des commandes la structure d'enregistrement pourrait
correspondre au modèle de données ci-dessous.
Figure 11 - Partie de MCD relatif à l'enregistrement de la chronologie des états d'une commande
15/25
P-A. Sunier
Note méthodologique:
Une entité doit être créée pour pouvoir modéliser ses états par une machine à état.
Figure 12 - relation structurelle entre une entité de données et la description de son comportement par un
modèle à état
Par contre, dès que ce lien est établi, il n'y a pas de règle de préséance entre MCD et machine
à états. Dans certaines situations, il est intéressant de modéliser la structure de données et
ensuite d'en déduire son comportement et ses états; dans d'autres situations, la démarche peut
être inversée.
Que l'on choisisse de démarrer par le MCD ou par la machine à états, il pertinent d'affiner les
deux modèles en les validant l'un l'autre par confrontations successives.
Figure 13 - Processus de travail de modélisation des aspects statique et dynamique d'une entité de données
16/25
P-A. Sunier
5.2 Les événements
Les événements déclenchent une transition entre états ou une action à l'intérieur d'un état; ils
peuvent être classés en trois familles ou types:



externes qui sont déclenchés par un acteur humain ou matériel; nous parlons d'externe
car l'acteur ne fait pas partie du SII;
internes qui sont déclenchés par un changement d'état d'un autre objet du SII; par
exemple, une commande passe dans l'état payée si un paiement a été créé et enregistré
dans le SII;
temporels qui sont déclenchés par l'atteinte d'un point temporel.
Pour illustrer les 3 types d'événements, nous proposons cicontre une partie de la machine à états de commandes à livrer
passées par une entreprise; dans ce cas, ArcPizzas envoie une
facture à l'entreprise et celle-ci s'en acquitte au guichet ou par
virement bancaire.
Cette partie de modèle est à placer dans le contexte du
modèle plus complet présenté au chapitre Modèle de
machine à états du document [PAS-8]
- L'événement Livraison effectuée est déclenché par le
caissier au retour du livreur, c'est un événement externe.
- L'événement at(Fin de semaine) est déclenché par
l'horloge interne d'un matériel utilisé pour l'informatisation
du SII, c'est un événement temporel.
Figure 14 - Machine à états
partielle de commande à livrer
pour entreprises
L'événement when(paiement créé) est déclenché par le
SII lors du paiement relatif à la commande facturée; c'est
un événement interne au SII.
Remarque:
Nous retenons d'utiliser les mots-clés:
 at pour un événement temporel, atteinte d'un point de rendez-vous (date, heure…);
 after pour un événement temporel, durée écoulée;
 when pour un événement interne, un objet créé, modifié ou supprimé.
Certains auteurs préconisent de rechercher tous les événements auxquels doit réagir un SII
pour servir de bases à l'élaboration de ses spécifications [Pour plus de détails PAS-30].
17/25
P-A. Sunier
5.3 Actions et activités propres à un état
Comme nous l'avons vu précédemment, tout objet est dans un et un seul état à un moment
donné. Pour chacun des états d'un objet, il est possible de définir une activité à mener ou des
actions ponctuelles à conduire.
Pour illustrer ce concept, nous nous
appuyons sur l'état Livreur indisponible de
la machine à états des commandes à livrer
d'ArcPizzas [PAS-8].
Une activité menée au sein d'un état est
marquée par l'entête do/
L'activité Recontacter client pour décision
est à réaliser lorsqu'une commande est dans
Figure 15 - Représentation des activités et actions au cet état et la transition de sortie se
sein d'un état
déclenchera lorsque cette activité se
terminera et que la décision du client sera
connue.
Les actions sont ponctuelles, elles peuvent être déclenchées:

lorsque l'objet entre dans l'état; l'action est alors marquée de l'entête entry/.
Lorsqu'une commande entre dans l'état Livreur indisponible l'action de recherche
une variante d'horaire de livraison est exécutée;

lorsque l'objet sort de l'état; l'action est alors marquée de l'entête exit/.
Lorsqu'une commande sort de l'état Livreur indisponible l'action d'enregistrement du
choix du client est exécutée;

lorsque l'objet réagit à un événement sans pour autant quitter son état; l'action de
réaction est alors marquée du nom de l'événement, pour notre exemple:
LivraisonAnnulée/.
Ce couple événement et action sans quitter l'état est nommé Transition interne.
Les actions peuvent être gardées par des pré-conditions tout comme des post-conditions
peuvent être spécifiées.
[Voir la Figure 18 pour une illustration de pré-condition]
18/25
P-A. Sunier
5.4 Les transitions
Les transitions sont déclenchées par la survenance d'un événement.
Une transition permet:
 de passer d'un état à un autre;
 de quitter un état et d'y revenir. Il s'agit d'une transition réflexive ou d'une transition
propre. Lors d'une transition réflexive ou propre:
o si une action de sortie d'état existe, elle est exécutée;
o si une action de transition existe, elle est exécutée;
o si une action d'entrée d'état existe, elle est exécutée;
 de rester dans un état mais de réagir à un événement en exécutant une action. Il s'agit
d'une transition interne.
Les transitions peuvent être gardées; malgré la survenance de l'événement, la transition n'est
exécutée que si la garde est franchissable.
Toute transition et pas seulement la transition interne peut s'accompagner d'une action à
exécuter après avoir quitté l'état précédent et avant d'entrer dans l'état suivant (précédent et
suivant peuvent être un même état lors de transition propre ou réflexive).
Figure 16 - Machine à états partielle de commande à livrer pour entreprises
Pour illustrer notre propos, nous avons repris la machine à états de la Figure 14; nous y avons
ajouté les deux états Payée partiellement et FactureAnnulée; nous avons affiné les
spécifications pour illustrer l'enrichissement des transitions.
19/25
P-A. Sunier
A propos de la Figure 16:

Les transitions en sortie de l'état Facturée déclenchées par l'événement interne
when(paiement créé) sont gardées. Les gardes dirigent la commande vers l'état
Payée partiellement ou Payée.
La transition gardée par l'expression [paiement > facture] déclenche l'action
Créditer client (différence) avant d'entrer dans l'état Payée.

La transition propre sur l'état Payée partiellement permet de prendre autant de
paiements partiels que nécessaires; la sortie de cet état ne se fera que lorsqu'un
paiement partiel permettra de quittancer la facture.

La transition interne Réclamation client / Modifier facture de l'état Facturée permet
à ArcPizzas de modifier une facture lors d'une réclamation d'un client.
La modification peut consister à modifier le montant à payer et dans ce cas, la
commande reste dans l'état Facturée.
La modification peut consister en une annulation de la facture; dans ce cas,
l'événement annulationFacture va mener la commande dans l'état FactureAnnulée.
5.5 Eléments de factorisation
Lorsqu'un même événement déclenche deux (ou plus)
transitions, une garde autorise une seule des transitions; pour
alléger la lecture du diagramme, il est possible de mettre un
choix [Voir Chapitre 3.3.1] en sortie de l'état.
Lorsque plusieurs transitions mènent à un même état, il est
possible de mettre un nœud de jointure pour alléger la lecture
du diagramme. Le nœud de jointure peut recevoir plusieurs
transitions en entrée et avoir plusieurs transitions en sortie.
Pour faciliter la lecture des diagrammes, nous conseillons de
n'utiliser la jointure que pour factoriser des transitions entrantes
et de gérer les sorties multiples avec un nœud de choix (sauf
pour les états concurrents que nous verrons plus loin).
Si plusieurs transitions en sortie d'un nœud de jointure sont
possibles, des gardes doivent assurer qu'en toute situation, une
et une seule transition soit franchissable; le nœud de jointure
fait alors office de choix.
20/25
P-A. Sunier
Pour illustrer notre propos (Figure 17), nous avons factorisé quelques unes des transitions de
la Figure 16, en cherchant à rendre le modèle plus aisé à lire.
A notre sens, il ne faut pas exagérer avec la factorisation au risque de produire des
diagrammes qui deviennent difficiles à lire!
Figure 17 - Machine à états partielle de commande à livrer pour entreprises factorisée
5.6 Les états composites
Un état peut être décomposé en une ou plusieurs régions; chaque région va recevoir une
machine à états contenant un ou plusieurs super états. Un état composite est nommé super état
par certains auteurs
Un état composite ne contenant qu'une seule région est appelé un état non orthogonal.
Un état composite contenant plusieurs régions est appelé état orthogonal ou état concurrent.
5.6.1 Etat non orthogonal
L'objet représenté par un état non orthogonal (une seule région) est dans l'état de sa région.
Pour illustrer le concept d'état orthogonal, nous avons repris la machine à états de la Figure
16; afin de rendre l'exercice plus intéressant, nous avons pris en compte que ArcPizzas
journalise chaque fin de mois toutes les commandes payées (passées par les entreprises) afin
d'alimenter un outil de reporting.
Dès lors, nous avons rajouté l'état Journalisée atteint par la transition temporelle de fin de
mois.
21/25
P-A. Sunier
Techniquement et afin de rendre le diagramme plus lisible, nous n'avons plus qu'une seule
garde [paiement >= facture] sur les transitions when(paiement créé); c'est en entrée de l'état
Payée.Totalement que nous déclencherons l'action consistant à créditer le client du surplus
payé, CréditeClient, si la pré-condition paiement > facture est vraie.
Naturellement, ce choix n'est pas lié au super état et nous aurions pu le faire précédemment.
Figure 18 - Machine à états partielle de commande à livrer pour entreprises avec super états

Un pseudo état initial doit marquer l'initialisation de la machine à états décrivant un
super état, l'état Payée dans notre cas.

Un pseudo état de fin n'est pas obligatoire comme pour toute machine à états; nous
n'en avons pas mis car une commande peut rester "indéfiniment" dans l'état
Payée.Partiellement.
Par contre, la sortie de cet état Payée sur l'événement at(Fin de mois) ne se réalisera
que si la commande est dans le sous-état Payée.Totalement; elle passera alors dans
l'état Journalisée.
22/25
P-A. Sunier
5.6.2 Etat orthogonal ou concurrent
L'objet représenté par un état orthogonal
ou concurrent (plusieurs régions) est dans
un état résultant de la conjonction de
l'ensemble des sous états de ses régions.
Tout objet dans l'état EtatConcurrent
(Figure ci-contre) sera obligatoirement
dans un sous état de la région I et un sous
état de la région II; par exemple:
Region I.EtatB et Region II.EtatX.
Figure 19 - Etat concurrent
Pour illustrer le concept d'état orthogonal (Figure 20), nous avons fait une consolidation de
l'ensemble des modalités de gestion des commandes d'ArcPizzas.
Figure 20 - Machine à états concurrents des différentes commandes

3 régions composent l'état concurrent Dispatchée:
o Livraison; cette région prend en charge le comportement des commandes à
livrer;
o Fabrication; cette région prend en charge le traitement de l'information
relative à la fabrication des pizzas;
23/25
P-A. Sunier
o Facturation; cette région prend en charge la traitement financier des
commandes d'entreprises9.

Nous n'avons pas mis de nœud de fin dans chacune des 3 régions car il faut prendre en
compte les exceptions qui empêchent une fin normale, par exemple:
o la livraison ne peut pas se faire car le client est absent;
o la fabrication ne peut pas se faire car le four tombe en panne;
o l'entreprise n'honore pas la facture qui lui a été adressée.

La sortie de l'état concurrent est déclenchée par l'événement temporel at(Délai
d'archivage dépassé); elle se fait depuis n'importe quel sous état des 3 régions pour
prendre en compte les exceptions évoquées précédemment.
Nous avons retenu comme principe que les commandes sont conservées en l'état au
sein du SII10 jusqu'au délai légal de conservation des documents financiers et autres;
passé ce délai les commandes peuvent être historisées.

La région Livraison reprend les éléments du modèle que nous avons réalisé en [PAS8 Chapitre Modèle de machine à états]; elle ne concerne que les commandes à livrer.
Les commandes à prendre au guichet restent dans le pseudo état initial.

L'état Fabrication.Ordonnée est atteint pour autant que ce soit une commande à
prendre au guichet ou que ce soit une commande à livrer dans l'état
Livraison.Attribuée.

La transition du pseudo état initial de la région Facturation vers son état Facturée
est déclenchée par l'événement d'atteinte de l'état Livrée dans la région Livraison.
Afin de rendre les 3 régions indépendantes les unes des autres, nous nous basons sur
l'atteinte de l'état Livraison.Livrée et non sur les conditions de la transition y menant
qui est propre à la région Livraison.

Le comportement des commandes dans l'état Facturation.Payée et ses différents sous
états sont décrits au sein d'une machine à états qui lui est propre; elle est reproduite en
Figure 21.
9
Nous admettons que les commandes de privés sont payées à la livraison qu'elle se fasse au guichet ou à
domicile.
10
En informatique de gestion, les données sont conservées au sein de bases de données; pour accéder à des
informations comme les commandes, il y a lieu de passer par l'intermédiaire de traitements informatiques (les
interfaces et contrôleurs évoqués en [PAS-8 Chapitre Modèle de communication]). Dès lors, l'archivage consiste
simplement à présenter un filtre aux utilisateurs par lequel il va choisir une période temporelle de travail; par
exemple, les commandes de l'année civile en cours, de l'an passé ou des cinq dernières années.
Une fois passé le délai légal de conservation des documents, il est possible: de conserver les données à des fins
d'exploitation d'un patrimoine informationnel potentiellement intéressant, ce que nous conseillons - de supprimer
les données, ce que nous déconseillons – de faire un mixte entre les deux, c'est-à-dire de supprimer les données
mais en ayant pris soin auparavant d'avoir créé une copie informatique ou papier pour une historisation des
documents. Les documents historisés sont consultables en tant que fichiers textes et ne nécessitent pas d'autres
ressources qu'un lecteur de fichier.
24/25
P-A. Sunier
Un état non orthogonal peut être représenté au sein d'une région du super état comme nous
l'avons fait en Figure 18; il peut aussi être représenté dans un diagramme spécifique comme
nous l'avons fait ci-dessous pour l'état Payée.
Figure 21 - Machine à états représentant les super états de l'état généralisé Payée de la région Facturation
du Figure précédente

La machine à états ne comporte pas de pseudo état final pour permettre, comme
évoqué précédemment, de garder une trace des factures partiellement payées et pour
lesquelles le débiteur a fait défaut pour le règlement du solde.
6 Bibliographie
[PAS-8]
HEG-Arc – Bases du langage de modélisation unifié - UML
P.-A. Sunier, 2013
http://lgl.isnetne.ch/BachelorII/Modelisation/UML/UML_Bases.pdf
[PAS-20]
Bases de modélisation du système d'information de l'entreprise
Eléments théoriques en complément du cas pratique ArcPizzas
P.-A. Sunier, octobre 2012
http://lgl.isnetne.ch/BachelorII/Modelisation/BasesSI/BasesModelisationSI.pdf
[PAS-30]
Les événements
P.-A. Sunier, 2005-2013
http://lgl.isnetne.ch/methodologie-2005HES/chapitre_310/evenements.pdf
25/25
P-A. Sunier

Langage de modélisation unifié UML en informatique de gestion

Transcription

Documents pareils

UML-2-par-la-pratique-etude-de-cas-et-exercices

Exemples de diagrammes SysML sur un portail automatique

Formation UML complète Plan de cours

TD Modelisation Vente Par Correspondance

uml 2 analyse et conception

1. Diagramme de cas d`utilisation

95 study of uml diagrams using an application which simulated the

Analyse et conception avec UML 2.0 - EGILIA

P50 Maquettage d`un outil pédagogique pour une méthode de