Vous êtes sur la page 1sur 190

Méthode de conception orientée objet

http://www.docsflood.com 1
Plan
• Présentation d’UML
• Les cas d’utilisation
• Les diagramme de classes et diagrammes d’objets
• Les diagrammes d’états-transitions
• Les diagrammes d’activités
• Les diagrammes de séquences
• Les diagrammes de communication

http://www.docsflood.com 2
Présentation d’UML
• Les méthode systémiques comme Merise ont marqué
une première évolution dans les années 80 autour
des idées de SI, de bases de données, de niveaux
de modélisation (conceptuel, organisationnel,
logique, physique) et de séparation données-
traitements.
• Depuis la fin des années 90, l’ACSI connaît une
deuxième évolution autour des idées d’objet
(regroupant données et traitement), de réutilisation
(code et conception).

http://www.docsflood.com 3
Présentation d’UML

• La démarche ne constitue plus à réécrire un modèle


d’un certain niveau dans les termes du niveau suivant
au moyen de règles de traduction.
• On passe d’un niveau à un autre par enrichissement
des éléments existants et adjonction d’éléments
nouveaux, en conservant le même formalisme.

http://www.docsflood.com 4
Histoire
 L’apparition du paradigme objet a permis la naissance de
Présentation d’UML

plusieurs méthodes de modélisation


OMT (Object Modeling Technique), OOSE (Object Oriented
Software Engineering), Booch, …
 Chacune de ces méthodes fournie une notation
graphique et des règles pour élaborer les modèles

http://www.docsflood.com 5
Présentation d’UML - Histoire

 Entre 89 et 94 : le nombre de méthodes orientées objet


est passé de 10 à plus de 50
 Toutes les méthodes avaient pourtant d’énormes points
communs (objets, méthode, paramètres, …)
 Au milieu des années 90, G. Booch, I. Jacobson et J.
Rumbaugh ont chacun commencé à adopter les idées
des autres. Les 3 auteurs ont souhaité créer un langage
de modélisation unifié

http://www.docsflood.com 6
Présentation d’UML - Histoire

http://www.docsflood.com
7
Les différents diagrammes d’UML
Un Diagramme est une représentation graphique d'un
ensemble d'éléments et de relations qui constituent un
système.
• UML définit neuf types de diagrammes divisés en
deux catégories :
1.diagrammes statiques (appelés aussi diagrammes
structurels) : diagrammes de classes, d'objets, de
composants, de déploiements et de cas d'utilisation.
2.diagrammes dynamiques (appelés aussi
diagrammes comportementaux) : diagrammes
d'activités, de séquences, d'états-transitions et de
collaborations.
http://www.docsflood.com 8
Les cas d’utilisation (use cases)
• Un cas d’utilisation représente un ensemble de séquence
d’actions qui sont réalisées par le système et qui produisent un
résultat observable intéressant pour un acteur particulier.
• Diagramme de cas d’utilisation (use case): il représente les
interactions entre le système et les acteurs.

http://www.docsflood.com 9
Acteur
• Un acteur représente un rôle joué par une entité externe
Les cas d’utilisation

(utilisateur humain, dispositif matériel ou autre système)


qui interagit directement avec le système étudié.
• Un acteur peut consulter et/ou modifier l’état du système,
en émettant et/ou en recevant des messages susceptibles
d’être porteurs de données.

http://www.docsflood.com 10
• La même personne physique peut jouer le rôle de
Les cas d’utilisation - Acteur

plusieurs acteurs.
• D’autre part, plusieurs personnes peuvent jouer le même
rôle, et donc agir comme un même acteur.

http://www.docsflood.com 11
comment identifier les acteurs
• Les acteurs candidats sont systématiquement :
Les cas d’utilisation - Acteur

oLes utilisateurs humains directs : faites donc en sorte


d’identifier tous les profils possibles, sans oublier
l’administrateur, l’opérateur de maintenance, etc.
oLes autres systèmes connexes qui interagissent aussi
directement avec le système étudié

http://www.docsflood.com 12
comment représenter les acteurs
Les cas d’utilisation - Acteur

• La représentation graphique standard de l’acteur en UML est


l’icône appelé « stick man », avec le nom de l’acteur sous le
dessin.

http://www.docsflood.com 13
• Autres représentations sont possibles : (1)
comment représenter les
acteurs

http://www.docsflood.com 14
comment représenter les

• Autres représentations sont possibles : (2)


acteurs

http://www.docsflood.com 15
comment représenter les

• Une bonne recommandation consiste à faire prévaloir


l’utilisation de la forme graphique du "stick man" pour
les acteurs humains et une représentation rectangulaire
pour les systèmes connectés.
acteurs

http://www.docsflood.com 16
comment identifier les cas d’utilisation
• L’objectif est le suivant : l’ensemble des cas d’utilisation
Les cas d’utilisation

doit décrire exhaustivement les exigences fonctionnelles


du système.
• Chaque cas d’utilisation correspond donc à une fonction
métier du système, selon le point de vue d’un de ses
acteurs.

http://www.docsflood.com 17
comment identifier Les cas

• Pour chaque acteur, il convient de :


 Rechercher les différentes intentions métier avec
lesquelles il utilise le système
 Déterminer dans le cahier des charges les services
fonctionnels attendus du système.
d’utilisation

Nommer les cas d’utilisation par un verbe à l’infinitif


suivi d’un complément, du point de vue de l’acteur (et
non pas du point de vue du système).

http://www.docsflood.com 18
Les cas d’utilisations :comment les analyser

Pour détailler la dynamique du cas d’utilisation, la procédure la


plus évidente consiste à recenser de façon textuelle toutes les
interactions entre les acteurs et le système.
• Le cas d’utilisation doit avoir un début et une fin
clairement identifiés.
• Il faut également préciser les variantes possibles,
telles que le cas nominal, les différents cas alternatifs
et d’erreurs, tout en essayant d’ordonner
séquentiellement les descriptions, afin d’améliorer
leur lisibilité.
http://www.docsflood.com 19
Les cas d’utilisation :comment les représenter
• Le diagramme de cas d’utilisation est un schéma qui montre les
cas d’utilisation (ovales) reliés par des associations (lignes) à
leurs acteurs (icône du « stick man » ou représentation
graphique équivalente).
• Chaque association signifie simplement
« participe à »
• Un cas d’utilisation doit être relié à au moins un acteur.

http://www.docsflood.com 20
comment représenter Les
cas d’utilisation

http://www.docsflood.com
21
Les cas d’utilisation

scénario
Une fois les cas d’utilisation identifiés, il faut encore les
décrire.
• Scénario :
un scénario représente une succession particulière
d’enchaînements, s’exécutant du début à la fin du cas
d’utilisation. Un cas d’utilisation contient en général
un scénario nominal et plusieurs scénarios alternatifs
(qui se terminent de façon normale) ou d’erreur (qui
se terminent en échec).

http://www.docsflood.com 22
• On peut d’ailleurs proposer une définition différente
pour un cas d’utilisation :
Les cas d’utilisation -

« ensemble de scénarios d’utilisation d’un système


reliés par un but commun du point de vue d’un
acteur »
scénario

http://www.docsflood.com 23
Les cas d’utilisation :fiche de description
• La fiche de description textuelle d’un cas d’utilisation
n’étant pas normalisée par UML, on peut adopter la
structuration suivante :
Sommaire d’identification Inclut titre, résumé, date de création et de modification, version, responsable,
(obligatoire) acteurs…

Description des scénarios Décrit le scénario nominal, les scénarios (ou enchaînements d’erreur), mais aussi
(obligatoire) les préconditions et les postconditions.

Ajoute, si c’est pertinent, les informations suivantes : fréquence, volumétrie,


Exigences non-
disponibilité, fiabilité, intégrité, confidentialité, performances, concurrence, etc.
fonctionnelles
Précise également les contraintes d’interface homme-machine comme des règles
(optionnel)
d’ergonomie, une charte graphique, etc.

http://www.docsflood.com 24
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

• Cette étude de cas concerne un système simplifié de Guichet


Automatique de Banque (GAB), Le GAB offre les services suivants :
1.Distribution d’argent à tout Porteur de carte de crédit, via un lecteur
de cartes et un distributeur de billets.
2.Consultation de solde de compte, dépôt en numéraire et dépôt de
chèques pour les clients porteurs d’une carte de crédit de la banque
adossée au GAB.

http://www.docsflood.com 25
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

N’oubliez pas non plus que :


3.Toutes les transactions sont sécurisées.
4.Il est parfois nécessaire de recharger le distributeur, etc.

http://www.docsflood.com 26
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

• À partir de ces quatre phrases, nous allons


progressivement :
•Identifier les acteurs;
•Identifier les cas d’utilisation;
•Construire un diagramme de cas d’utilisation.

http://www.docsflood.com 27
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

•Question :

•Identifier les acteurs

http://www.docsflood.com 28
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

Étape 1 : Identification des acteurs du GAB


• Quelles sont les entités externes qui interagissent
directement avec le GAB ?

http://www.docsflood.com 29
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

Porteur de carte
Lecteur de cartes
Distributeur de billets
Carte bancaire
Client banque
Les transactions sont sécurisées
Opérateur de maintenance
http://www.docsflood.com 30
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

Porteur de carte (externe)


Lecteur de cartes (interne)
Distributeur de billets (interne)
Carte bancaire (externe)
Client banque (externe)
Les transactions sont sécurisées (par des externes)
Opérateur de maintenance (externe)
http://www.docsflood.com 31
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

Porteur de carte (externe)


Lecteur de cartes (interne)
Distributeur de billets (interne)
Carte bancaire (externe)
Client banque (externe)
Les transactions sont sécurisées (par des externes)
Opérateur de maintenance (externe)
http://www.docsflood.com 32
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

Porteur de carte (externe)


Lecteur de cartes (interne)
Distributeur de billets (interne)
Carte bancaire (externe)
Client banque (externe)
Les transactions sont sécurisées (par qui ?)
Opérateur de maintenance (externe)
http://www.docsflood.com 33
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

Porteur de carte
Client banque
Opérateur de maintenance

http://www.docsflood.com 34
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

•Question :

•Identifier les cas d’utilisation

http://www.docsflood.com 35
Les cas d’utilisation - Etude de cas
Etude d’un guichet automatique de banque (GAB)

•Question :

•Construire un diagramme de cas


d’utilisation

http://www.docsflood.com 36
Etude d’un guichet automatique de banque (GAB)
Diagramme de cas d’utilisation

http://www.docsflood.com 37
http://www.docsflood.com 38
Relations entre cas d'utilisation

• Trois types de relations standard entre cas d'utilisation


sont proposés par UML :
<<include>> : le cas d'utilisation incorpore explicitement
et de manière obligatoire un autre cas d'utilisation à
l'endroit spécifié;
<<extend>> : le cas d'utilisation incorpore implicitement
de manière facultative un autre cas d'utilisation à l'endroit
spécifié;
généralisation : les cas d'utilisation descendants héritent
des propriétés de leur parent.

http://www.docsflood.com 39
Relations entre cas d'utilisation

• Autrement dit :
<<include>> : le cas d'utilisation A inclut obligatoirement
le cas d’utilisation B; ceci permet de factoriser des
fonctionnalités partagées.
<<extend>> : le cas d'utilisation d’utilisation A est une
extension optionnelle du cas d’utilisation B à un certain
point de son exécution.
généralisation : notion d’héritage en orienté-objet.

http://www.docsflood.com 40
Relations entre cas d'utilisation

http://www.docsflood.com 41
http://www.docsflood.com 42
Relations entre cas d'utilisation

On peut également avoir de l’héritage entre acteurs et


entre cas d’utilisation (généralisation/spécialisation).

http://www.docsflood.com 43
Relations entre cas d'utilisation

http://www.docsflood.com 44
Revenons à notre étude de cas (GAB)

• Le Diagramme de cas d’utilisation peut présenter


l’héritage comme suit

http://www.docsflood.com 45
Ancien diagramme

http://www.docsflood.com 46
Nouveau diagramme

http://www.docsflood.com 47
Les cas d’utilisation - Etude de cas
Etude d’une Station Service

• Considérons le système informatique qui gère une


station-service de distribution d’essence. On
s’intéresse à la modélisation de la prise d’essence
par un client.

http://www.docsflood.com 48
Les cas d’utilisation - Etude de cas
Etude d’une Station Service
1. Le client se sert de l’essence de la façon suivante. Il prend un pistolet
accroché à une pompe et appuie sur la gâchette pour prendre de
l’essence. Qui est l’acteur du système ? Est-ce le client, le pistolet ou la
gâchette ?
2. Le pompiste peut se servir de l’essence pour sa voiture. Est-ce un nouvel
acteur ?
3. La station a un gérant qui utilise le système informatique pour des
opérations de gestion. Est-ce un nouvel acteur ?
4. La station-service a un petit atelier d’entretien de véhicules dont s’occupe
un mécanicien. Le gérant est remplacé par un chef d’atelier qui, en plus
d’assurer la gestion, est aussi mécanicien. Comment modéliser cela ?

http://www.docsflood.com 49
Les cas d’utilisation - Etude de cas
Etude d’une Station Service - Correction
1. Le client est l’acteur du système. Le pistolet et la gâchette sont
des ressources utilisées par le système.
2. Si le pompiste fait uniquement les tâches d’un client, il est
inutile de créer un nouvel acteur. Il sera lui-même client.
3. Oui, le gérant est un nouvel acteur.
4. Un nouvel acteur, le chef d’atelier, est créé à la place du gérant.
Il hérite d’un autre acteur: le mécanicien.

http://www.docsflood.com 50
Les cas d’utilisation - Etude de cas
Etude d’une Station Service - Correction

http://www.docsflood.com 51
Les cas d’utilisation - Etude de cas
Etude d’une Agence de voyages
Choisissez et dessinez les relations entre les cas suivants :
1. Une agence de voyages organise des voyages où l’hébergement se fait en
hôtel. Le client doit disposer d’un taxi quand il arrive à la gare pour se
rendre à l’hôtel.

http://www.docsflood.com 52
Les cas d’utilisation - Etude de cas
Etude d’une Agence de voyages

2. Certains clients demandent à l’agent de voyages d’établir une facture


détaillée. Cela donne lieu à un nouveau cas d’utilisation appelé « Etablir
une facture détaillée ». Comment mettre ce cas en relation avec les cas
existants ?
3. Le voyage se fait soit par avion, soit par train. Comment modéliser cela ?

http://www.docsflood.com 53
Les cas d’utilisation - Etude de cas
Etude d’une Agence de voyages –
Correction

http://www.docsflood.com 54
Les cas d’utilisation - Etude de cas
Etude d’une Agence de voyages –
Correction
• Certains clients demandent à l’agent de voyages d’établir une facture
détaillée. Cela donne lieu à un nouveau cas d’utilisation appelé «
Etablir une facture détaillée ». Comment mettre ce cas en relation
avec les cas existants ?

http://www.docsflood.com 55
Les cas d’utilisation - Etude de cas
Etude d’une Agence de voyages –
Correction

http://www.docsflood.com 56
Les cas d’utilisation - Etude de cas
Etude d’une Agence de voyages –
Correction
• Le voyage se fait soit par avion, soit par train. Comment
modéliser cela ?

http://www.docsflood.com 57
Les cas d’utilisation - Etude de cas
Etude d’une Agence de voyages – Correction

http://www.docsflood.com 58
Les cas d’utilisation - Etude de cas
Etude d’un Etablissement scolaire
 Dans un établissement scolaire, on désire gérer la réservation des salles de
cours ainsi que du matériel pédagogique (ordinateur portable ou/et Vidéo
projecteur). Seuls les enseignants sont habilités à effectuer des
réservations (sous réserve de disponibilité de la salle ou du matériel).
 Le planning des salles peut quant à lui être consulté par tout le monde
(enseignants et étudiants).
 Par contre, le récapitulatif horaire par enseignant (calculé à partir du
planning des salles) ne peut être consulté que par les enseignants.
 Enfin, il existe pour chaque formation un enseignant responsable qui seul
peut éditer le récapitulatif horaire pour l’ensemble de la formation.

http://www.docsflood.com 59
Les cas d’utilisation - Etude de cas
Etude d’un Etablissement scolaire - Correction

http://www.docsflood.com 60
Les cas d’utilisation - Etude de cas
Logiciel dédié à l’industrie textile
• En vue de la mise en place d’un logiciel dédié à l’industrie
textile, nous étudions principalement quelques fonctionnalités
permettant de recueillir l’information sur les produits
développés dans l’entreprise. Tout le personnel de l’entreprise
peut consulter le système, soit pour vérifier qu’un produit
particulier existe, soit pour un parcours libre des informations.
Toute consultation doit être précédée par une authentification
légère dans laquelle la personne précise son nom et son service
à des fins de statistiques ultérieures.

http://www.docsflood.com 61
Les cas d’utilisation - Etude de cas
Logiciel dédié à l’industrie textile

• Les ingénieurs peuvent effectuer différentes opérations de mise


à jour pour les produits dont ils sont responsables : ajout, retrait
et modification des informations sur les produits. Ces opérations
doivent être précédées d’une authentification plus approfondie
lors de laquelle l’ingénieur précise son nom, son service et
introduit un mot de passe qui est vérifié en contactant le
système de gestion du personnel.

http://www.docsflood.com 62
Les cas d’utilisation - Etude de cas
Logiciel dédié à l’industrie textile
• Toutes les opérations (consultations et mises à jour) donnent
lieu à un enregistrement dans un journal des accès et peuvent
optionnellement s’accompagner d’une impression des
documents accédés.

• Représenter le diagramme des cas d'utilisation de ce système.

http://www.docsflood.com 63
http://www.docsflood.com 64
Description textuelle d’un cas d’utilisation
• À chaque cas d’utilisation doit être associée une description textuelle
des interactions entre l’acteur et le système et les actions que le
système doit réaliser en vue de produire les résultats attendus par les
acteurs.

http://www.docsflood.com 65
Description textuelle d’un cas d’utilisation

• La description textuelle d’un cas d’utilisation est articulée


en six points :
 Objectif
 Acteurs concernés
 Pré conditions
 Post conditions
 Scénario nominal
 Scénarios alternatifs

http://www.docsflood.com 66
Description textuelle d’un cas d’utilisation

• Objectif – Décrire succinctement le contexte et les


résultats attendus du cas d’utilisation.
• Acteurs concernés – Le ou les acteurs concernés par le cas
doivent être identifiés en précisant globalement leur rôle.
• Pré conditions – Si certaines conditions particulières sont
requises avant l’exécution du cas, elles sont à exprimer à
ce niveau.

http://www.docsflood.com 67
Description textuelle d’un cas d’utilisation

• Post conditions – Par symétrie, si certaines conditions


particulières doivent être réunies après l’exécution du cas, elles
sont à exprimer à ce niveau. Par souci de simplification, ce
point n’est pas toujours traité.
• Scénario nominal – Il s’agit là du scénario principal qui doit se
dérouler sans incident et qui permet d’aboutir au résultat
souhaité.
• Scénarios alternatifs – Les autres scénarios, secondaires ou
correspondant à la résolution d’anomalies, sont à décrire à ce
niveau. Le lien avec le scénario principal se fait à l’aide d’une
numérotation hiérarchisée (1.1a, 1.1b...) rappelant le numéro
de l’action concernée.
http://www.docsflood.com 68
Description textuelle d’un cas d’utilisation

• D’autres concepteurs préfèrent décomposer la fiche


descriptive du cas d’utilisation en 4 volets :
1. L’identification
2. La description des scénarios
3. La fin et les post-conditions
4. Les compléments

http://www.docsflood.com 69
1. L’identification
Nom : ……………………………………......
Acteur(s) : ……………………………………......
Description : ……………………………………......
Auteur : ……………………………………......
Date(s) : ……………………………………......
Préconditions : ……………………………………......
Démarrage : ……………………………………......

http://www.docsflood.com 70
2. La description des scénarios
• Le scénario nominal

• Les scénarios alternatifs

• Les scénarios d’exception

http://www.docsflood.com 71
3. La fin et les post-conditions
• La fin du cas d’utilisation

• Les post-conditions

http://www.docsflood.com 72
4. Les compléments
Les compléments peuvent porter sur des sujets variés :
• L’ergonomie
• La performance attendue
• Des contraintes (techniques ou non) à respecter
• Des problèmes non résolus (ou questions à poser au client et aux
futurs utilisateurs)

http://www.docsflood.com 73
Exemple de description textuelle d’un cas
d’utilisation
• Nous allons nous intéresser à un cas d’utilisation simple (sans relation
avec d’autres cas d’utilisation), par exemple :
« Consulter catalogue produits ».
• Nous allons voir la fiche descriptive du cas d’utilisation « Consulter
catalogue produits » dont voici le diagramme correspondant.

http://www.docsflood.com 74
http://www.docsflood.com 75
Description textuelle d’un cas d’utilisation

• Voici la synthèse des 4 volets de la fiche


descriptive du cas d’utilisation
« Consulter catalogue produits ».

http://www.docsflood.com 76
1. L’identification
Cas n°1
Nom : Consulter catalogue produit (package « Gestion des achats »)
Acteur(s) : Acheteur (client ou commercial)
Description : La consultation du catalogue doit être possible pour un
client ainsi que pour les commerciaux de l’entreprise.
Auteur : Prénom & Nom de l’auteur
Date(s) : 23/12/2014 (première rédaction)
Préconditions : L’utilisateur doit être authentifié en tant que client ou
commercial (Cas d’utilisation « S’authentifier » – package «
Authentification »)
Démarrage : L’utilisateur a demandé la page
« Consultation catalogue »

http://www.docsflood.com 77
2. La description des scénarios
Le scénario nominal :
1. Le système affiche une page contenant la liste des catégories de
produits.
2. L’utilisateur sélectionne une des catégories.
3. Le système recherche les produits qui appartiennent à cette catégorie.
4. Le système affiche une description et une photo pour chaque produit
trouvé.
5. L’utilisateur peut sélectionner un produit parmi ceux affichés.
6. Le système affiche les informations détaillées du produit choisi.
7. L’utilisateur peut ensuite quitter cette description détaillée.
8. Le système retourne à l’affichage des produits de la catégorie (retour à
l’étape 4)

http://www.docsflood.com 78
2. La description des scénarios
Les scénarios alternatifs
2.a L’utilisateur décide de quitter la consultation de la liste des catégorie
de produits.
2.b L’utilisateur décide de quitter la consultation du catalogue.
5.a L’utilisateur décide de quitter la consultation de la catégorie de
produits choisie.
5.b L’utilisateur décide de quitter la consultation du catalogue.
7.a L’utilisateur décide de quitter la consultation de la catégorie de
produits choisie.
7.b L’utilisateur décide de quitter la consultation du catalogue.

http://www.docsflood.com 79
3. La fin et les post-conditions

Fin : Scénario nominal : aux étapes 2, 5 ou 7, sur décision de


l’utilisateur
Post-conditions : Aucun

http://www.docsflood.com 80
4. Les compléments
Ergonomie
L’affichage des produits d’une catégorie devra se faire par groupe de 15 produits. Toutefois, afin d’éviter
à l’utilisateur d’avoir à demander trop de pages, il devra être possible de choisir des pages avec 30, 45
ou 60 produits.
Performance attendue
La recherche des produits, après sélection de la catégorie, doit se faire de façon à afficher la page des
produits en moins de 5 secondes.
Problèmes non résolus
Nous avons fait la description basée sur l’information que les produits appartiennent à une catégorie.
Est-ce qu’il existe des sous-catégories ?
Si tel est le cas, la description devra être revue.
Est-ce que la consultation du catalogue doit être possible uniquement par catégorie ou est-ce qu’on
doit prévoir d’autres critères de recherche de produits ?
Doit-on prévoir un affichage trié sur des critères choisis par l’utilisateur (par exemple : par tranche de
prix, par disponibilité, etc.) ?

http://www.docsflood.com 81
Exemple de description textuelle d’un cas
d’utilisation complexe
• Il s’agit dans ce cas de cas d’utilisation dont le scénario renvoie vers
d’autre cas d’utilisation.
• Etudions le cas suivant : « enregistrer un achat ».
• La particularité de ce cas d’utilisation est qu’il soit lié à plusieurs
autres cas d’utilisation avec des relations « include » et « extend »
comme on a vu précédemment sur le diagramme de cas d’utilisation
correspondant :

http://www.docsflood.com 82
http://www.docsflood.com 83
1. L’identification
Cas n°2
Nom : Enregistrer un achat (package « Gestion des achats »)
Acteur(s) : Acheteur (client ou commercial)
Description : L’enregistrement d’un achat doit pouvoir être utilisé en
ligne, par un client ainsi que par les commerciaux de l’entreprise.
L’enregistrement comprend les produits demandés et le règlement de
l’achat.
Auteur : Prénom & Nom de l’auteur
Date(s) : 23/12/2014 (première rédaction)
Préconditions : L’utilisateur doit être authentifié en tant que client ou
commercial (Cas d’utilisation « S’authentifier » – package «
Authentification »)
Démarrage : L’utilisateur a demandé la page
« Enregistrer des achats »

http://www.docsflood.com 84
2. La description des scénarios
Le scénario nominal :
1. Le système vérifie le type d’utilisateur connecté (si commercial ou
client)
2. Si l’utilisateur est le commercial, le système fait appel au cas
d’utilisation interne « sélectionner un client »
3. Le système affiche des informations concernant le client
4. Le système fait appel au cas d’utilisation interne
« Constituer panier »
5. Le système fait appel au cas d’utilisation interne
« Saisir information pour livraison»
6 Le système fait appel au cas d’utilisation interne
« Enregistrer le règlement»
7. Le système enregistre définitivement l’achat
8. Le système affiche le récapitulatif de l’achat.

http://www.docsflood.com 85
2. La description des scénarios
Les scénarios d’exception
2.a Le système n’affiche aucun utilisateur sélectionné.
Il affiche « Veuillez sélectionner le client concerné par l’achat » (retour à
l’étape 2)
6.a L’enregistrement du règlement n’a pas réussi.
Le système récapitule les informations dans un message qui est envoyé au
département commercial.
(Arrêt du cas d’utilisation)
7.a L’enregistrement définitif de l’achat n’a pas réussi.
Le système récapitule les informations dans un message qui est envoyé au
département commercial.
(Arrêt du cas d’utilisation)

http://www.docsflood.com 86
3. La fin et les post-conditions
Fin
• Scénario nominal : sur décision de l’utilisateur, après le point 8
(affichage du récapitulatif de l’achat)
• Scénario d’exception : après le point 6 ou 7, si l’enregistrement du
règlement ou de l’achat définitif ne réussit pas.
Post-conditions
• Scénario nominal : l’achat et son règlement ont été enregistrés en
base de données.
• Scénario d’exception : l’achat a été récapitulé dans un message et a
été envoyé au service commercial de l’entreprise.

http://www.docsflood.com 87
4. Les compléments
Ergonomie
L’enregistrement d’un achat doit pouvoir se faire avec un
maximum de 3 pages. Les éventuels messages aux utilisateurs
doivent être fournis à l’aide de fenêtres pop-up.
Problèmes non résolus
Nous avons décrit le cas où un utilisateur est soit un
commercial, soit un client connu (indiqué par la précondition).
Est-ce bien ainsi que cela devra fonctionner ? Serait-il
envisageable de dérouler l’ensemble des actions liées à la
constitution du panier avant de s’enregistrer comme client ?

http://www.docsflood.com 88
Les diagrammes structurels
(ou statiques)

• DIAGRAMME DE CLASSE
ET
DIAGRAMME D’OBJET

http://www.docsflood.com 89
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Objet :
Un objet est un concept, une abstraction ou
une chose qui a un sens dans le contexte du
système à modéliser.
• Chaque objet a une identité et peut être distingué
des autres sans considérer a priori les valeurs de
ses propriétés.

http://www.docsflood.com 90
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Objet :
Exemples d’objets physiques (une chaise, une
voiture, une personne, un vélo) et d’objets de
gestion (la Commande n° 12,
le Client Durand).

http://www.docsflood.com 91
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Objet :

http://www.docsflood.com 92
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Objet :
• Un objet est caractérisé par les valeurs de ses
propriétés qui lui confèrent des états significatifs
suivant les instants considérés.

http://www.docsflood.com 93
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Classe :
Une classe décrit un groupe d’objets ayant les
mêmes propriétés (attributs), un même
comportement (opérations), et une sémantique
commune (domaine de définition).

http://www.docsflood.com 94
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Classe :
• Un objet est une instance d’une classe.
• La classe représente l’abstraction de ses objets.
• Au niveau de l’implémentation, c’est-à-dire au cours de
l’exécution d’un programme, à l’identificateur d’un objet
correspond une adresse mémoire.

http://www.docsflood.com 95
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Classe : Formalisme général et exemple
• Une classe se représente à l’aide d’un rectangle
comportant plusieurs compartiments.
• Les trois compartiments de base sont :
• la désignation de la classe,
• la description des attributs,
• la description des opérations.

http://www.docsflood.com 96
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Classe : Formalisme général et exemple
• Deux autres compartiments peuvent être aussi indiqués :
• la description des responsabilités de la classe,
• la description des exceptions traitées par la classe.

http://www.docsflood.com 97
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Classe : Formalisme général et exemple

http://www.docsflood.com 98
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Attribut :
• Un attribut est une propriété élémentaire d’une classe.
Pour chaque objet d’une classe, l’attribut prend une valeur
(sauf cas d’attributs multivalués).

http://www.docsflood.com 99
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Attribut : Formalisme et exemple

http://www.docsflood.com 100
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Attribut : Caractéristiques
• La description complète des attributs d’une classe
comporte un certain nombre de caractéristiques
qui doivent respecter le formalisme suivant :
Visibilité/Nom attribut : type [= valeur initiale
{propriétés}]

http://www.docsflood.com 101
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Attribut : Caractéristiques
– Visibilité : ….
– Nom d’attribut : nom unique dans sa classe.
– Type : type primitif (entier, chaîne de caractères…) dépendant
des types disponibles dans le langage d’implémentation ou type
classe matérialisant un lien avec une autre classe.
– Valeur initiale : valeur facultative donnée à l’initialisation d’un
objet de la classe.
– {propriétés} : valeurs marquées facultatives (ex. : « interdit »
pour mise à jour interdite).

http://www.docsflood.com 102
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Attribut : Caractéristiques
• Un attribut peut avoir des valeurs multiples. Dans ce cas, cette
caractéristique est indiquée après le nom de l’attribut (ex. : prénom
[3] pour une personne qui peut avoir trois prénoms).
• Un attribut dont la valeur peut être calculée à partir d’autres
attributs de la classe est un attribut dérivé qui se note « /nom de
l’attribut dérivé »

http://www.docsflood.com 103
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Opération :
• Une opération est une fonction applicable aux objets
d’une classe. Une opération permet de décrire le
comportement d’un objet.
• Une méthode est l’implémentation d’une opération.

http://www.docsflood.com 104
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Opération : Formalisme et exemple

http://www.docsflood.com 105
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Opération : Caractéristiques
• La description complète des opérations d’une
classe comporte un certain nombre de
caractéristiques qui doivent respecter le
formalisme suivant :
Visibilité Nom d’opération (paramètres) [:[type
résultat] {propriétés}]

http://www.docsflood.com 106
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Opération : Caractéristiques
– Visibilité : ….
– Nom d’opération : utiliser un verbe représentant l’action à réaliser.
– Paramètres : liste de paramètres (chaque paramètre peut être décrit, en
plus de son nom, par son type et sa valeur par défaut). L’absence de
paramètre est indiquée par ( ).
– Type résultat : type de(s) valeur(s) retournée(s) dépendant des types
disponibles dans le langage d’implémentation. Par défaut, une opération
ne retourne pas de valeur, ceci est indiqué par exemple par le mot réservé
« void » dans le langage C++ ou Java.
– {propriétés} : valeurs facultatives applicables (ex. : {query} pour un
comportement sans influence sur l’état du système)
http://www.docsflood.com 107
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET

Exemples de classes et représentation d’objets

http://www.docsflood.com 108
(1) Le nom d’un objet peut être désigné sous trois
formes :
nom de l’objet, désignation directe et
explicite d’un objet ;
nom de l’objet : nom de la classe, désignation
incluant le nom de la classe ;
: nom de la classe, désignation anonyme d’un
objet d’une classe donnée.
http://www.docsflood.com 109
Exemples d’objets

http://www.docsflood.com 110
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Classe : Visibilité des attributs et opérations
• Chaque attribut ou opération d’une classe peut être de
type public, protégé, privé ou paquetage.
• Les symboles + (public), # (protégé), - (privé) et ~
(paquetage) sont indiqués devant chaque attribut ou
opération pour signifier le type de visibilité autorisée pour
les autres classes.

http://www.docsflood.com 111
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Classe : Visibilité des attributs et opérations
• Les droits associés à chaque niveau de confidentialité sont :
• Public (+) – Attribut ou opération visible par tous.
• Protégé (#) – Attribut ou opération visible seulement à
l’intérieur de la classe et pour toutes les sous-classes de la classe.
• Privé (-) – Attribut ou opération seulement visible à l’intérieur
de la classe.
• Paquetage (~) – Attribut ou opération ou classe seulement
visible à l’intérieur du paquetage où se trouve la classe.
http://www.docsflood.com 112
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Classe : Visibilité des attributs et opérations

Dans cet exemple, tous les


attributs sont déclarés de type
privé, les opérations
« démarrer » et « freiner » sont de
type public, l’opération
« rouler » est de type
privé et l’opération « arrêter » est
de type protégé.

http://www.docsflood.com 113
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Attribut ou opération de niveau classe
• Un attribut ou une opération peut être défini non pas au
niveau des instances d’une classe, mais au niveau de la
classe. Il s’agit soit d’un attribut qui est une constante pour
toutes les instances d’une classe soit d’une opération
d’une classe abstraite ou soit par exemple d’une opération
« créer » qui peut être définie au niveau de la classe et
applicable à la classe elle-même.

http://www.docsflood.com 114
Attribut ou opération de niveau classe :
Formalisme et exemple

C’est le soulignement de l’attribut


ou de l’opération qui caractérise
cette propriété.
Dans cet exemple, l’attribut
« ristourne » est de type classe et
l’opération
« créer » est une opération
exécutable au niveau de la classe.

http://www.docsflood.com 115
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Association, multiplicité, navigabilité et contraintes
:

http://www.docsflood.com 116
Lien et association
• Un lien est une connexion physique ou
conceptuelle entre instances de classes donc entre
objets. Une association décrit un groupe de liens
ayant une même structure et une même
sémantique. Un lien est une instance d’une
association. Chaque association peut être
identifiée par son nom.
• Une association entre classes représente les liens
qui existent entre les instances de ces classes.

http://www.docsflood.com 117
Lien et association : Rôle d’association
• Le rôle tenu par une classe vis-à-vis d’une
association peut être précisé sur l’association. Par
exemple :

http://www.docsflood.com 118
Multiplicité
• La multiplicité indique un domaine de valeurs pour
préciser le nombre d’instances d’une classe vis-à-
vis d’une autre classe pour une association donnée.
La multiplicité peut aussi être utilisée pour d’autres
usages comme par exemple un attribut multi-
valué.
• Le domaine de valeurs est décrit selon plusieurs
formes :

http://www.docsflood.com 119
Multiplicité
• Intervalle fermé – Exemple : 3 ..15
• Valeurs exactes – Exemple : 3, 5, 8
• Valeur indéterminée notée * – Exemple : 1..*
• Dans le cas où l’on utilise seulement *, cela traduit
une multiplicité 0..*
• Dans le cas de multiplicité d’associations, il faut
indiquer les valeurs minimale et maximale
d’instances d’une classe vis-à-vis d’une instance
d’une autre classe.
http://www.docsflood.com 120
Multiplicité : Formalisme et exemple

http://www.docsflood.com 121
Navigabilité
• La navigabilité indique si l’association fonctionne
de manière unidirectionnelle ou bidirectionnelle,
elle est matérialisée par une ou deux extrémités
fléchées. La non-navigabilité se représente par un «

• Les situations possibles de navigabilité sont
représentées comme suit :

http://www.docsflood.com 122
Navigabilité

http://www.docsflood.com 123
Navigabilité : Exemple

http://www.docsflood.com 124
Contraintes
• D’autres propriétés particulières (contraintes) sont
proposées dans UML pour préciser la sémantique
d’une association.

http://www.docsflood.com 125
Contraintes
Ordre de tri
• Pour une association de multiplicité supérieure à 1,
les liens peuvent être :
• non ordonnés (valeur par défaut),
• ordonnés ou triés lorsque l’on est au niveau de
l’implémentation (tri sur une valeur interne).

http://www.docsflood.com 126
Contraintes
Propriétés de mise à jour de liens
• Il est possible d’indiquer des contraintes
particulières relatives aux conditions de mise à jour
des liens.
• {interdit} : interdit l’ajout, la suppression ou la mise
à jour des liens.
• {ajout seul} : n’autorise que l’ajout de liens.

http://www.docsflood.com 127
Association de dimension supérieure à 2 et
classe-association
• Une association de dimension supérieure à 2 se
représente en utilisant un losange permettant de
relier toutes les classes concernées.
• Une classe-association permet de décrire soit des
attributs soit des opérations propres à l’association.
Cette classe-association est elle-même reliée par
un trait en pointillé au losange de connexion. Une
classe-association peut être reliée à d’autres
classes d’un diagramme de classes.

http://www.docsflood.com 128
Association de dimension supérieure à 2 et
classe-association
Exemple
• Exemple d’une association de dimension 3
comprenant une classe-association
« Affectation ». La classe-association Affectation
permet de décrire les attributs propres à
l’association de dimension 3 représentée.

http://www.docsflood.com 129
http://www.docsflood.com 130
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Agrégation et composition entre classes

http://www.docsflood.com 131
Agrégation
• L’agrégation est une association qui permet de
représenter un lien de type
« ensemble » comprenant des « éléments ». Il s’agit
d’une relation entre une classe représentant le
niveau « ensemble » et 1 à n classes de niveau «
éléments ».

http://www.docsflood.com 132
Agrégation : Formalisme

http://www.docsflood.com 133
Agrégation : Exemple

Dans cet exemple, nous avons modélisé le fait qu’un ordinateur


comprend une UC, un clavier et un écran.
http://www.docsflood.com 134
Composition
• La composition est une relation d’agrégation dans
laquelle il existe une contrainte de durée de vie
entre la classe « composant » et la classe « composé
». Autrement dit la suppression de la classe
« composé » implique la suppression de la ou des
classes « composant ».

http://www.docsflood.com 135
Composition : Formalisme

http://www.docsflood.com 136
Composition : Exemple

http://www.docsflood.com 137
Composition : Autre formalisme peut être
utilisé

http://www.docsflood.com 138
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Association qualifiée, dépendance et classe
d’interface

http://www.docsflood.com 139
Qualification
• La qualification d’une relation entre deux classes
permet de préciser la sémantique de l’association et
de qualifier de manière restrictive les liens entre les
instances.
• Seules les instances possédant l’attribut indiqué
dans la qualification sont concernées par
l’association.

http://www.docsflood.com 140
Qualification : Formalisme et exemple

http://www.docsflood.com 141
Qualification : Formalisme et exemple

http://www.docsflood.com 142
Dépendance
• La dépendance entre deux classes permet de
représenter l’existence d’un lien sémantique.
• Une classe B est en dépendance de la classe A si des
éléments de la classe A sont nécessaires pour
construire la classe B.

http://www.docsflood.com 143
Dépendance
• Une dépendance est une relation unidirectionnelle
exprimant une dépendance sémantique entre des
éléments du modèle. Elle est représentée par un
trait discontinu orienté. Elle indique que la
modification de la cible peut impliquer une
modification de la source. La dépendance est
souvent stéréotypée pour mieux expliciter le lien
sémantique entre les éléments du modèle

http://www.docsflood.com 144
Dépendance

http://www.docsflood.com 145
Interface
• Une classe d’interface permet de décrire la vue externe
d’une classe. La classe d’interface, identifiée par un
nom, comporte la liste des opérations accessibles par
les autres classes. Le compartiment des attributs ne fait
pas partie de la description d’une interface.
• L’interface peut être aussi matérialisée plus
globalement par un petit cercle associé à la classe
source.
• La classe utilisatrice de l’interface est reliée au symbole
de l’interface par une flèche en pointillé. La classe
d’interface est une spécification et non une classe
réelle.
http://www.docsflood.com 146
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Généralisation et spécialisation

http://www.docsflood.com 147
Généralisation et spécialisation

http://www.docsflood.com 148
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
Classe abstraite
• Une classe abstraite est une classe qui n’a pas
d’instance directe mais dont les classes
descendantes ont des instances. Dans une relation
d’héritage, la super-classe est par définition une
classe abstraite. C’est le cas de la classe Employé
dans l’exemple suivant :

http://www.docsflood.com 149
http://www.docsflood.com 150
DIAGRAMME DE CLASSE ET DIAGRAMME
D’OBJET
L’héritage multiple
• Dans certains cas, il est nécessaire de faire hériter
une même classe de deux classes
« parentes » distinctes. Ce cas correspond à un
héritage multiple.

http://www.docsflood.com 151
http://www.docsflood.com 152
Exercice
• Il est demandé de représenter le diagramme de classe d’une
gestion technique de documents. Chaque document est
composé d’un ou plusieurs feuillets. Un feuillet comporte du
texte et des objets géométriques qui constituent deux types
d’objets graphiques supportant des opérations de type :
sélectionner, copier, couper, coller et déplacer.
• Nous considérons les quatre objets géométriques suivants :
cercle, ellipse, carré, rectangle. Il est demandé d’utiliser les
propriétés de la généralisation et la spécialisation afin de
représenter au mieux ces objets géométriques.

http://www.docsflood.com 153
http://www.docsflood.com 154
DIAGRAMME D’ÉTAT-TRANSITION

• L’état d’un objet est défini, à un instant donné, par


l’ensemble des valeurs de ses propriétés.
• Le passage d’un état à un autre état s’appelle
transition. Un événement est un fait survenu qui
déclenche une transition.
• Une condition, peut être associée à une transition.

http://www.docsflood.com 155
DIAGRAMME D’ÉTAT-TRANSITION

http://www.docsflood.com 156
DIAGRAMME D’ÉTAT-TRANSITION
• La figure suivante donne un premier exemple d’état-transition.
• Dans cet exemple, pour un employé donné d’une entreprise, nous
pouvons considérer les deux états significatifs suivants :
état recruté, état en activité.

http://www.docsflood.com 157
DIAGRAMME D’ÉTAT-TRANSITION

http://www.docsflood.com 158
DIAGRAMME D’ÉTAT-TRANSITION
Action et activité :
• Une action est une opération instantanée qui ne peut être
interrompue ; elle est associée à une transition.
• Une activité est une opération d’une certaine durée qui peut être
interrompue, elle est associée à un état d’un objet.

http://www.docsflood.com 159
DIAGRAMME D’ÉTAT-TRANSITION

http://www.docsflood.com 160
DIAGRAMME D’ÉTAT-TRANSITION
Exemple :

http://www.docsflood.com 161
Représentation du diagramme d’état-
transition d’un objet
• L’enchaînement de tous les états caractéristiques d’un objet constitue
le diagramme d’état.
• Un diagramme d’états débute toujours par un état initial et se
termine par un ou plusieurs états finaux sauf dans le cas où le
diagramme d’états représente une boucle.

http://www.docsflood.com 162
Représentation du diagramme d’état-
transition d’un objet

http://www.docsflood.com 163
Représentation du diagramme d’état-
transition d’un objet
Exemple :

• L’exemple suivant donne un premier exemple fictif d’une gestion


commerciale qui montre le diagramme d’état-transition de l’objet
client.

http://www.docsflood.com 164
http://www.docsflood.com 165
Représentation du diagramme d’état-
transition d’un objet
Exercice :
• Soit à représenter le diagramme d’état-transition d’un objet
personnel en suivant les événements de gestion depuis le
recrutement jusqu’à la mise en retraite.
• Après le recrutement, une personne est considérée en activité dès sa
prise de fonction dans l’entreprise. Au cours de sa carrière, nous
retiendrons seulement les événements : congé de maladie et prise de
congé annuel. En fin de carrière, nous retiendrons deux situations : la
démission et la retraite.

http://www.docsflood.com 166
Représentation du diagramme d’état-
transition d’un objet
Corrigé :
Ce corrigé ne représente qu’une solution parmi d’autres variantes
possibles suivant la lecture faite de l’énoncé. Ici, nous avons retenu les
états caractéristiques : recruté, activité, en congé, en arrêt, parti et
retraite.

http://www.docsflood.com 167
http://www.docsflood.com 168
DIAGRAMME D’ACTIVITÉ

• Le diagramme d’activité présente un certain nombre


de points communs avec le diagramme d’état-
transition. 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 à
une seule classe.

http://www.docsflood.com 169
DIAGRAMME D’ACTIVITÉ

Action :
• Une action correspond à un traitement qui modifie
l’état du système.
• Une action est représentée par un rectangle dont les
coins sont arrondis comme pour les états du
diagramme d’état-transition

http://www.docsflood.com 170
DIAGRAMME D’ACTIVITÉ

Action :

http://www.docsflood.com 171
DIAGRAMME D’ACTIVITÉ

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.

http://www.docsflood.com 172
DIAGRAMME D’ACTIVITÉ

Transition et flot de contrôle :

http://www.docsflood.com 173
DIAGRAMME D’ACTIVITÉ

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.
http://www.docsflood.com 174
DIAGRAMME D’ACTIVITÉ
Activité :

Symbole de représentation d’un état


http://www.docsflood.com composite 175
DIAGRAMME D’ACTIVITÉ

Nœud de bifurcation (fourche) :


• 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.

http://www.docsflood.com 176
http://www.docsflood.com 177
http://www.docsflood.com 178
DIAGRAMME D’ACTIVITÉ

Nœud de jonction (synchronisation) :


• Un nœud de jonction (synchronisation) permet, à partir de
plusieurs flots concurrents en entrée de la synchronisation,
de produire un flot unique sortant. Le nœud de jonction est
le symétrique du nœud de bifurcation.

http://www.docsflood.com 179
http://www.docsflood.com 180
DIAGRAMME D’ACTIVITÉ

Nœud de test-décision :
• 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 nœud de
test-décision n’a qu’un seul flot en entrée. On peut
aussi utiliser seulement deux flots de sortie : le
premier correspondant à la condition vérifiée et
l’autre traitant le cas sinon.

http://www.docsflood.com 181
http://www.docsflood.com 182
http://www.docsflood.com 183
DIAGRAMME D’ACTIVITÉ

Nœud de fusion-test :
• Un nœud de fusion-test permet d’avoir plusieurs
flots entrants possibles et un seul flot sortant. Le flot
sortant est donc exécuté dès qu’un des flots entrants
est activé.

http://www.docsflood.com 184
http://www.docsflood.com 185
DIAGRAMME D’ACTIVITÉ

Flot de données et nœud 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.

http://www.docsflood.com 186
http://www.docsflood.com 187
DIAGRAMME D’ACTIVITÉ

Partition :

• UML permet aussi d’organiser la présentation du


diagramme d’activité en couloir d’activités. Chaque
couloir correspond à un domaine de responsabilité
d’un certain nombre d’actions.
• Les flots d’objets sont aussi représentés dans le
diagramme. L’ordre relatif des couloirs de
responsabilité n’est pas significatif.
http://www.docsflood.com 188
DIAGRAMME D’ACTIVITÉ

Représentation du diagramme d’activité

http://www.docsflood.com 189
http://www.docsflood.com 190