Présentation cours UML.pptx

Cours: UML
1
LOYA Youssouf
youssouf.loya@u-auben.org

Objectifs
2
 Le cours vise à donner aux étudiants des connaissances
sur la modélisation objet à travers le langage UML.
 A l’issue du cours, les étudiants devraient être capables
de :
Modéliser les utilisations d’un système à l’aide d’UML;
Modéliser la structure d’un système à l’aide d’UML;
Modéliser la dynamique d’un système à l’aide d’UML;
Utiliser le langage UML dans le développement d’un
système.

Plan
3
 Introduction
 Modélisation des exigences
 Modélisation des objets du système
 Modélisation de la dynamique du système
 Modélisation de l’architecture logicielle

Prérequis
 Cours de Conception des SI, 1ère année
 Cours d’Algorithmique objet, 2è année
 Cours de Langage C++, 2è année
5

Evaluations
 1 devoir sur table
 Des évaluations à chaud
6

Bibliographie
7
 [1] David Gabay, Joseph Gabay : UML 2, Analyse et
conception
2008 Dunod Paris France
 [2] Pierre-Alain Muller: Modélisation objet avec UML
2000
[3] P a s c a l R oques , F r a n c k V a l l é e: UML 2 en action
De l’analyse des besoins à la conception
2007 Eyrolles

1 – Introduction
Définition
Objectif
Historique
Modélisation avec UML
8

Définition
9
UML = Unified Modeling Language, langage unifié pour la
modélisation objet.
UML est un langage destiné à modéliser des systèmes
(souvent logiciels) perçus comme un ensemble
d’objets, principalement graphique, unifié et semi-
formel.
UML, langage:
Lexique: ensemble des mots du langage
Syntaxe: règles selon lesquelles les éléments du
langage (exemple: les mots) sont assemblés en des
expressions (exemple: phrases, clauses).
sémantique: règles permettant d’attribuer une
signification aux expressions syntaxiques.

Définition
10
UML, destiné à modéliser des systèmes
Un système est un ensemble d’éléments, matériels
ou immatériels, en interaction dynamique, organisé
en fonction d’un but.
Un modèle est une représentation abstraite et
simplifiée (c’est à dire qui exclut certains détails)
d’un système du monde réel en vue de le décrire, de
l’expliquer ou de le prévoir.
Décrire un modèle nécessite d'utiliser un langage.
UML sert à décrire des modèles des systèmes, surtout
des systèmes d’information(SI), existants ou à
construire.

Définition
11
UML, destiné à modéliser des systèmes
Un SI est un ensemble organisé de ressources :
matériel, logiciel, personnel, données, procédures…
permettant d’acquérir, de traiter, de stocker des
informations (sous formes de données, textes, images,
sons, etc.) dans et entre des organisations.

Définition
12
UML, principalement graphique
Les mots sont des boîtes, des cercles, des arcs, des
flèches, ...; c’est-à-dire généralement des graphiques.
La grammaire et la sémantique sont un ensemble de
diagrammes :
qui agencent les mots,
qui sont destinés à exprimer quelque chose de
particulier.
UML, unifié
UML est un langage qui résulte de la fusion de
plusieurs méthodes de conception orientée objet.
UML est standardisé par un consortium international
l'Object Management Group(OMG).

Définition
13
UML, unifié
C'est un langage de modélisation adopté par toutes
les méthodes percevant le système à modéliser comme
un ensemble d’objets et adapté à toutes les phases du
développement.
UML est indépendant de tout langage de
programmation objet.
UML, semi-formel
Si UML dispose d’une syntaxe précise, sa sémantique
n’est pas complètement et formellement définie.

Définition
14
UML n’est ni une méthode, ni un processus.
UML est employé dans l’ensemble des secteurs du
développement informatique et électronique :
Systèmes d’information,
Télécommunication, défense,
Transport, aéronautique, aérospatial,
Domaines scientifiques,

Objectif
15
Visualiser, spécifier, construire, documenter les artefacts
de la conception d’un système.
Artefact = tout élément d'information utilisé ou généré
pendant la totalité du cycle de développement d'un
système logiciel.
Exemple: morceau de code, commentaire, spécification
d'une classe, interview d'un utilisateur potentiel du
système, description du contexte d'installation matériel,
diagramme d'une architecture globale, rapport de
réalisation, manuel utilisateur, etc.
Faciliter la communication entre les membres des équipes
de projet. Sa notation graphique permet aux clients, aux
utilisateurs finals, aux analystes, aux concepteurs,
développeurs, testeurs, mainteneurs, …d’exprimer
visuellement leurs raisonnements, ce qui facilite leur
compréhension.

Historique
16
Foisonnement des méthodes objet
Les méthodes utilisées dans les années 1980 pour
organiser la programmation structurée(Merise, …) étaient
fondées sur la modélisation séparée des données et des
traitements.
Lorsque la POO prend de l’importance au début des
années 1990, la nécessité d’une méthode qui lui soit
adaptée devient évidente.

Historique
17
Conséquence naturelle, mise en place de méthodes objet:
OOD : Object Oriented Design (Booch, 1991)
HOOD : Hierarchical Object Oriented Design (Delatte, 1993)
OOA : Object Oriented Analysis (Schlaer, Mellor, 1992)
OOA/OOD : (Coad, Yourdon, 1991)
OMT : Object Modeling Technique (Rumbaugh, 1991)
OOSE: Object Oriented Software Engineering (Jacobson, 1992)
OOM : Object Oriented Merise (Bouzeghoub, Rochfeld, 1993)
Fusion (Coleman et al., 1994)

Historique
18
Bilan:
Entre 89 et 94 : le nombre de méthodes orientées objet
est passé de 10 à plus de 50;
Chacune avait ses avantages, ses insuffisances et ses
partisans;
Chacune avait ses notations ( ie son langage de
modélisation), or l’industrie a besoin de standards;
Néanmoins, elles utilisaient des concepts assez proches;
Aucune ne parvient pas à s’imposer.

Historique
19
Vers une unification
En 1994,
trois méthodes prédominent:
 OMT de James Rumbaugh (General Electric) fournit une
représentation graphique des aspects statique,
dynamique et fonctionnel d’un système ;
 OOD de Grady Booch, définie pour le Department of
Defense, introduit le concept de paquetage (package) ;
 OOSE d’Ivar Jacobson (Ericsson) fonde l’analyse sur la
description des besoins des utilisateurs (cas d’utilisation,
ou use cases).
Rumbaugh (OMT) rejoint Booch (OOD) chez Rational
Software.
Objectif: créer une méthode en commun (méthode unifiée)

Historique
20
En 1995,
Présentation de UNIFIED METHOD V0.8 lors de la
conférence OOPSLA (Object Oriented Programming
Systems, Languages and Applications).
Jacobson (OOSE) rejoint Booch et Rumbaugh chez
Rational;
En 1996,
Leurs travaux ne visaient plus la constitution d’une
méthode mais la recherche d’un langage de
modélisation commun unique utilisable par toute méthode
objet.

Historique
21
En 1996,
Présentation du langage unifié UML 0.9 (Unified
Modeling Language) lors de OOPSLA
L’initiative est soutenue par de nombreuses sociétés de
développement et de conception d’Ateliers Génie
Logiciel(AGL): Microsoft, Oracle, HP, IBM,…
En 1997,
UML 1.0 sort chez Rational
UML 1.1 adopté par l’OMG(Object Management Group)
comme standard officiel.
UML est la fusion des méthodes orientées dominantes dont OOD,
OMT, OOSE.

Modélisation avec UML
23
UML permet de représenter un système selon diverses
projections complémentaires appelées vues.
Ces vues sont généralement constituées d'un ou plusieurs
diagrammes UML :
qui sont des représentations graphiques qui s'intéressent
à un aspect précis du modèle;
dont chaque type est composé d'éléments de
modélisation prédéfinis
dont la combinaison offre une vue complète des
aspects fonctionnels, statiques et dynamiques d’un
système.

24
Diagrammes UML
Diagrammes structurels ou statiques
Diagrammes décrivant la structure du système et de ses
composants:
Diagramme d’objets;
Diagramme de classes;
Diagramme de composants;
Diagramme de structure composite,
Diagramme de déploiement;
Diagramme de paquetages.

25
Diagrammes UML
Diagrammes de comportement
Diagrammes décrivant la manière dont réagit le système:
Diagramme de cas d’utilisation;
Diagramme d’activités;
Diagramme d’états-transitions;
Diagrammes d’interaction:
Diagramme de séquence;
Diagramme de communication;
Diagramme de vue générale d’interaction;
Diagramme de temps.

26
Axes de modélisation
Les concepteurs orientent leurs modélisations selon trois
axes (vues) sur lesquels ils répartissent les diagrammes :
L’axe fonctionnel qui est utilisé pour décrire ce que
fait le système à réaliser;
L’axe structurel et statique qui est relatif à sa structure;
L’axe dynamique qui est relatif à la construction de ses
fonctionnalités.
Les diagrammes de chaque axe forment un modèle: modèle
fonctionnel, modèle statique, modèle dynamique.

27
Axes de modélisation
Fonctionnel(ce que le système FAIT)
Dynamique(comment le
système EVOLUE)
Statique (ce que le système EST)
Diagramme de Use Cases
(Diagramme d’activités)
(Diagramme de séquence)
Diagramme d’activités
Diagramme d’états/transitions
Diagramme de séquence
Diagramme de communication
Diagramme de classes
Diagramme de composants
Diagramme de déploiement
Diagramme d’objets
Les mêmes modèles (fonctionnel, statique, dynamique) peuvent être utilisés à
différents niveaux d’abstraction, du plus conceptuel à l’implantation.

28
Elaboration de la modélisation
Si UML permet de modéliser un système, il ne définit
pas le processus d’élaboration des modèles:
Dans quel ordre doit-on utiliser les différents types de
digrammes?
A quel moment de la conception d’un système doivent-ils
intervenir?
Seul un processus de développement peut répondre à ces
questions.
Les auteurs d’UML préconisent des processus utilisant
une démarche itérative et incrémentale, guidée par les
besions des utilisateurs du système et centrée sur
l’architecture logicielle.

29
Démarche itérative et incrémentale
Pour modéliser un système complexe, il vaut mieux s’y
prendre en plusieurs fois, en affinant son analyse et sa
conception par étapes.
La démarche itérative et incrémentale consiste à organiser
le développement en une série de développements très
courts de durée fixe nommée itérations; le résultat de
chaque itération est un système partiel exécutable, testé et
intégré. Ainsi le système croît avec le temps de façon
incrémentale.
Le but est de mieux maîtriser la part d’inconnu et
d’incertitude qui caractérisent les systèmes complexes

30
Démarche guidée par les besoins des utilisateurs
Les besoins des utilisateurs servent de fil conducteur tout
au long du développement; à chaque itération:
à la phase d’analyse, on clarifie, affine et valide les
besoins des utilisateurs;
à la phase de conception et de réalisation, on veille à la
prise en compte des besoins des utilisateurs;
à la phase de test, on vérifie que les besoins des
utilisateurs sont satisfaits.

31
Démarche centrée sur l’architecture logicielle
L’architecture d’un système logiciel peut être décrite comme
les différentes vues du système qui doit être construit.
Dès le démarrage du processus, on aura une vue sur
l'architecture à mettre en place.

2 – Modélisation des
exigences
Introduction
Objectifs
Concepts de base
Représentation du diagramme des CU
Description textuelle des cas d’utilisation
32

Introduction
33
Le développement d'un système ou l'amélioration d'un
système répond à un ou plusieurs besoins.
Aussi avant de développer un système, il faut savoir
précisément à QUOI il devra servir, à quels besoins il devra
répondre.
Le système est conçu pour les utilisateurs; donc:
Ils savent ce que le système doit faire mais pas comment;
Ils connaissent l’aspect fonctionnel du système.
Les utilisateurs sont donc les plus aptes à décrire comment
ils s’en servent, c’est-à-dire à décrire les besoins d’utilisation
du système.

Introduction
34
C’est pourquoi le système doit être bâti à partir des
descriptions des utilisateurs.
Grâce au diagramme de cas d’utilisation(DCU), UML permet
de représenter ces besoins fonctionnels des utilisateurs.
Formalisé par Ivar Jacobson dans OOSE en 1992, le DCU
représente les différents utilisateurs du système et la
structure des grandes fonctions qui leur sont
nécessaires.
Le DCU dit ce que le système fait (ou fera), pas comment il
le fait (fera).

Objectifs
35
Capturer les besoins fonctionnels du système
Identifier et trier les catégories d'utilisateurs qui
interagissent avec le système;
Identifier et structurer les besoins des utilisateurs
Délimiter le système.
Bien comprendre ce qui relève du système à concevoir et
à construire et ce qui n’en relève pas
Visualiser graphiquement le cahier de charge
Servir de support de référence tout au long des phases de
développement du système.
Les cas d’utilisation seront consultés et référencés tout au
long du processus de développement du système.

Objectifs
36
Servir de support de référence tout au long des phases de
développement du système.
Les cas d’utilisation seront consultés et référencés tout au
long du processus de développement du système.

Concepts de base
37
Les concepts représentés dans un diagramme de cas
d’utilisation sont:
Le système;
Acteur ;
Cas d’utilisation;
Relation d’interaction.

Concepts de base
38
Acteur
Définition
Un acteur est un rôle joué par une entité externe qui
interagit directement avec le système étudié; le nom de
l’acteur décrit le rôle joué par l’acteur.
 Représentation
Un acteur peut être représenté de trois
manières différentes :
Petit personnage (stick man)
Classe stéréotypée
Combinaison ces 2 représentations
Nom Acteur
<<Actor>>
Nom Acteur
Nom de l’acteur

Concepts de base
39
Acteur
Exemple
Remarque
Une même personne physique peut jouer le rôle de
plusieurs acteurs (Chef d’agence est un client de la
banque).
Plusieurs personnes peuvent jouer le même rôle, et donc
agir comme un même acteur (plusieurs personnes peuvent
jouer le rôle d’administrateur).
Client
<<Actor>>
Imprimante

Concepts de base
40
Acteur
 Catégories d’acteurs
Les acteurs peuvent être de trois types :
Humains: utilisateurs du logiciel à travers son interface
graphique, par exemple;
Logiciels : disponibles qui communiquent avec le système
grâce à une interface logicielle (API, ODBC, …);
Matériels : exploitant les données du système ou qui sont
pilotés par le système (Imprimante, robots, automates, …).

Concepts de base
41
Acteur
Les acteurs peuvent être de trois types :
Secrétaire
Etudiant
Système de Gestion
Scolaire
<<acteur>>
Imprimante
<<acteur>>
Site Web de l'établissement

Concepts de base
42
Acteur
Du point de vue du système, on distingue deux types :
Acteurs principaux: utilisent les fonctions principales
du système. Par exemple, le client pour un distributeur de
billets.
Acteurs secondaires : effectuent des tâches administratives
ou de maintenance. Par exemple, la personne qui recharge
la caisse contenue dans le distributeur.

Concepts de base
43
Acteur
 Relations entre acteurs
La seule relation possible entre deux acteurs est la
généralisation:
 un acteur A est une généralisation de l’acteur
B si A peut être substitué par B.
 La relation de généralisation exprime que l’acteur
spécialisé(ici B) peut réaliser tout ce que l’acteur plus
général(ici A) peut réaliser, plus d’autres fonctionnalités.

Concepts de base
44
Acteur
Relations entre acteurs
La relation de généralisation est représentée par
une flèche à tête triangulaire blanche, orientée
vers l’acteur général.
Identification des acteurs
Pour les identifier :
Quelles sont les entités externes au système qui
interagissent directement avec le système ?
Acteur général
Acteur spécialisé

Concepts de base
45
Acteur
Le logiciel de gestion des réparations est destiné en priorité au
Chef d'atelier, il devra lui permettre de saisir les fiches de
réparations et le travail effectué par les divers employés de l'atelier.
Pour effectuer leur travail, les mécaniciens et autres employés de
l'atelier vont chercher des pièces de rechange au magasin.
Lorsque le logiciel sera installé, les magasiniers ne fourniront des
pièces que pour les véhicules pour lesquels une fiche de réparation
est ouverte; ils saisiront directement les pièces fournies depuis un
terminal installé au magasin. Lorsqu'une réparation est terminée, le
Chef d'atelier va essayer la voiture. Si tout est en ordre, il met la
voiture sur le parc clientèle et bouclera la fiche de réparation
informatisée. Les fiches de réparations bouclées par le Chef
d'atelier devront pouvoir être importées par le comptable dans le
logiciel comptable.

Concepts de base
46
Acteur
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.

Concepts de base
47
Acteur
Dans un magasin, un commerçant dispose d’un système de gestion
de son stock d’articles, dont les fonctionnalités sont les suivantes :
- Édition de la fiche d’un fournisseur
- Possibilité d’ajouter un nouvel article (dans ce cas, la fiche
fournisseur est automatiquement éditée. Si le fournisseur n’existe
pas, on peut alors le créer)
- Édition de l’inventaire. Depuis cet écran, on a le choix d’imprimer
l’inventaire, d’effacer un article ou d’éditer la fiche d’un article.

Concepts de base
48
Cas d’utilisation
Définition
Un cas d'utilisation (CU) est l'expression d'un service
réalisé par le système de bout en bout avec un
déclenchement, un déroulement et une fin, pour un
acteur particulier qui en est généralement l'initiateur.
Un CU est déclenché par un événement extérieur au
système appelé événement déclencheur.
Un CU possède un nom : celui de la fonctionnalité
du système qui le prend en charge.
Un CU met en œuvre un dialogue entre le système
et l’entité (acteur) à l’origine de l’événement initiateur.

Concepts de base
49
Cas d’utilisation
Définition
Les cas d'utilisation permettent aux utilisateurs :
de structurer et d'articuler leurs besoins,
de définir la manière dont ils voudraient interagir avec le
système,
de préciser quelles informations ils entendent
échanger avec le système,
décrire ce qui doit être fait pour obtenir le résultat
escompté.

Concepts de base
50
Cas d’utilisation
Définition
En résumé un cas d'utilisation décrit:
Une fonctionnalité du système vue par un acteur et
utile à ce dernier;
Un ensemble de séquences d’actions réalisées par le
système et qui produisent un résultat observable
intéressant pour un acteur particulier ;
Un comportement attendu du système du point de vue
d’un ou plusieurs acteurs;
Un service attendu du système.

Concepts de base
51
Cas d’utilisation
Représentation
Un cas d'utilisation est représenté par une ellipse
en trait plein, contenant son nom donné généralement
sous forme verbe à l’infinitif +complément .
 Exemple
Recenser les CU des exercices ci-dessus

Concepts de base
52
Cas d’utilisation
Structuration des cas d'utilisation
Il est utile de structurer l'ensemble des cas
d'utilisation que l'on a fait apparaître afin de rechercher:
Les comportements partagés;
Les cas particuliers, exceptions, variantes
Les généralisations/spécialisations
UML définit trois types de relations standardisées
entre cas d'utilisation permettant leur structuration

Concepts de base
53
Cas d’utilisation
Relation d'inclusion
Un cas A inclut un cas B si le comportement de A inclut
obligatoirement le comportement défini par le cas B.
La relation d’inclusion est formalisée par la dépendance
«include»:
Le cas d'utilisation cible est une partie du cas d'utilisation
source.
<<include>>

Concepts de base
54
Cas d’utilisation
Exemple:
<<include>>
<<include>>
<<include>>
<<include>>
Retirer de l'argent
Déposer de l'argent
Effectuer des virements
Consulter solde
S'authentifier
Les cas d'utilisation "Déposer de l'argent",
"Retirer de l'argent", "Effectuer des virements"
et "Consulter solde" incorporent de façon
explicite le cas d'utilisation "S'authentifier", à
un endroit spécifié dans leurs enchaînements.

Concepts de base
55
Cas d’utilisation
Intérêts:
La relation d’inclusion permet:
de décomposer un cas d’utilisation complexe en sous
cas d’utilisation plus simples ;
de factoriser des fonctionnalités partagées.
Cas d’utilisation interne
Un cas d’utilisation inclus dans d’autres cas peut ne
pas être directement accessible à un acteur; un tel cas
est appelé cas d’utilisation interne.

Concepts de base
56
Cas d’utilisation
Relation d‘extension
La relation d’extension exprime qu'un cas d’utilisation
peut, sous certaines conditions, s'ajouter au
comportement d'un autre cas d’utilisation.
La relation d’extension est formalisée par la dépendance
«extend»:
Le cas d'utilisation source est une partie du cas
d'utilisation cible dans certains cas.
<<extend>>
<<extend>>
B
A

Concepts de base
57
Cas d’utilisation
Relation d‘extension
La relation d’extension exprime qu'un cas d’utilisation
peut, sous certaines conditions, s'ajouter au
comportement d'un autre cas d’utilisation.
La relation d’extension est formalisée par la dépendance
«extend»:
Le cas d'utilisation source est inséré dans le cas
d'utilisation cible seulement quand une condition appelée
condition d’extension est vraie. Graphiquement, la
condition est exprimée sous la forme d’une note.
<<extend>>
<<extend>>
B
A

Concepts de base
58
Cas d’utilisation
Relation d’extension
Le comportement ajouté s’insère dans le CU étendu à un
point précis appelé point d’extension.
Le point d’extension porte un nom, qui figure dans un
compartiment du cas étendu sous la rubrique points
d’extension, et est éventuellement associé à une
contrainte indiquant le moment où l’extension intervient.
Remarque
Le CU étendu peut fonctionner tout seul.
Contrairement à l’inclusion, l’extension est optionnelle

Concepts de base
59
Cas d’utilisation
Exemple
Cas « Effectuer virement » étendu par le cas « Vérifier solde », après avoir demandé le
montant du virement, si celui-ci dépasse 100000.

Concepts de base
60
Cas d’utilisation
Intérêt
On utilise principalement l’extension pour séparer le
comportement optionnel (les variantes) du comportement
obligatoire.
Relation de généralisation
Un cas A est généralisation d'un cas B si B est un cas
particulier de A.
Exemple :
Un client peut effectuer un virement bancaire. Le virement peut être
effectué sur place ou par Internet. Le client doit être identifié (en
fournissant son code d’accès) pour effectuer un retrait, mais si le montant
dépasse 100000, la vérification du solde de son compte est réalisée.

Concepts de base
61
Cas d’utilisation
Exemple

Concepts de base
62
Cas d’utilisation
Intérêts
Faire apparaître des cas particuliers d'un cas
d'utilisation
Permet de factoriser un comportement commun à un
ensemble de cas d’utilisation proches.

Concepts de base
63
Cas d’utilisation
Exercice
Soient les cas d'utilisation suivants :
Passer une commande
Passer une commande urgente
Suivre une commande
Valider l'utilisateur
Expédier commande totale ou partielle
Le suivi de la commande désigne le processus complet, du passage de la
commande à l'expédition. Il peut toutefois arriver qu'une commande passée
ne soit pas envoyée. Passer une commande urgente est un cas particulier
de passer une commande. Pour passer une commande, il faut
nécessairement valider l'utilisateur.
Représenter ces cas d'utilisation

Concepts de base
64
Cas d’utilisation
Traitements périodiques
Il arrive fréquemment qu’un système doive régulièrement
effectuer une action de façon automatisée, comme vider
des logs, faire une maintenance…
Cette action est bien un objectif que doit remplir le
système, donc un cas d’utilisation, mais l’on ne dispose
pas d’acteur pour le déclencher, et un cas d’utilisation doit
toujours être lié à un acteur.
On introduit alors de façon artificielle un acteur
supplémentaire «Time», «Cron», «Daily schedule »,
«traitements par lots», «déclenchement périodique», …

Concepts de base
65
Cas d’utilisation
Identification des cas d’utilisation
Pour les identifier, il faut répondre aux questions
suivantes:
Quels sont les services rendus par le système ?
Quelles sont les interactions Acteurs/ système ?
Pour chaque acteur identifié
– Rechercher les différentes intentions métiers avec
lesquelles il utilise le système
– Déterminer les services fonctionnels attendus du
système par cet acteur
Quels sont les évènements perçus par le système
(externes, temporels, changement d’état) ?

Concepts de base
66
Système
Le système représente les limites de l’application
considérée et regroupe les cas d’utilisation
Le système est représenté par un rectangle
Nom du système

Concepts de base
67
Relation d’interaction
Définition
La relation d’interaction ou lien de communication entre
un acteur et un cas d’utilisation indique que l’acteur utilise
le système par cette fonctionnalité c’est à que l’acteur en
a besoin.
L’interaction entre un acteur et un cas d’utilisation se
représente comme une association sous la forme d’un lien
éventuellement orienté dans le sens de l’interaction.
Multiplicité
Lorsqu’un acteur peut interagir plusieurs fois avec un cas
d’utilisation, il est possible d’ajouter une multiplicité sur
l’association du côté du cas d’utilisation.

Concepts de base
68
Multiplicité
Le symbole * signifie plusieurs, exactement n s’écrit tout
simplement n, n..m signifie entre n et m, etc.
Préciser une multiplicité sur une relation n’implique pas
nécessairement que les cas sont utilisés en même temps.
Acteur principal-Acteur secondaire
Un acteur est dit principal pour un CU lorsque ce cas rend
service à cet acteur. Les autres acteurs sont dits
secondaires.
Un acteur principal obtient un résultat observable du CU
tandis qu’un acteur secondaire est sollicité pour des
informations complémentaires.
En général, l’acteur principal initie le cas d’utilisation par ses
sollicitations

Concepts de base
69
Acteur principal-Acteur secondaire
Un cas d’utilisation a au plus un acteur principal.
Le stéréotype « primary » vient orner l’association reliant
un cas d’utilisation à son acteur principal, le stéréotype «
secondary » est utilisé pour les acteurs secondaires.

Représentation du DCU
70
Représentation graphique
Le diagramme des cas d'utilisation regroupe dans un
même schéma:
 Les acteurs avec leurs relations;
 Le système étudié représenté par un cadre
rectangulaire;
 Les cas d’utilisations placés à l’intérieur du système
dont ils représentent les fonctionnalités;
 Les interactions entre acteurs et cas d’utilisation;
 Les dépendances entre les cas d’utilisation;
 Les éventuelles notes sur les différents éléments du
diagramme.

71
Représentation graphique
Exemple
<<include>>
<<include>>
<<include>>
<<include>>
<<extend>>
Client
Agent
Technicien
Déposer de l'argent
Retirer de l'argent
Consulter le solde
Effectuer des virements entre comptes
Ravitailler
Réparer
S'authentifier
Retenir la carte
Fournir un login et un mot
de passe

72
Construction des DCU
Recenser les acteurs
Identifier les acteurs qui entourent le système
Organiser les acteurs selon une hiérarchisation de
généralisation/spécialisation
Recenser les cas d’utilisation
Identifier les cas d’utilisation
Structurer les cas d'utilisation pour faire apparaître les
comportement partagés (relation d'inclusion), les cas
particuliers (généralisation/spécialisation) ou les options
(relation d'extension)
Pour chaque acteur, spécifier les cas d'utilisation auxquels
il se rapporte.

Description textuelle des cas
d’utilisation
73
Le diagramme de cas d’utilisation décrit les grandes
fonctions d’un système du point de vue des acteurs.
Mais il n’expose pas de façon détaillée le dialogue entre
les acteurs et les cas d’utilisation.
D’où la nécessité de décrire ce dialogue.
Trois façons sont couramment utilisées pour décrire les
cas d’utilisation :
Description textuelle
Description à l’aide de diagrammes de séquences
système (voir plus loin)
Description à l'aide d'un diagramme d'activités(voir plus
loin).

d’utilisation
74
Scénarii d’un CU
Un scénario est:
 Chemin particulier pris lors de l’exécution d’un CU
 Séquence spécifique d’actions et d’interactions ie
d’enchaînements entre une instance d’un acteur et le
système.
 Une séquence de messages qui correspond à une
utilisation du système.
 Instance d’un CU
 Déroulement possible d’un CU

d’utilisation
75
Scénarii d’un CU
Un cas d’utilisation comporte:
 Un scénario principal ou nominal, scénario typique de
succès.
 Zéro ou plusieurs scénarii alternatifs, correspondant aux
traitements alternatifs possibles se terminant avec
succès.
 Zéro ou plusieurs scénarii d’exception, recensant les
échecs dans le déroulement d’une étape de scénario.
Ainsi CU= ensemble de scénarios d’utilisation d’un système
reliés par un but commun du point de vue d’un acteur.

d’utilisation
76
Description textuelle
La description textuelle d’un cas d’utilisation est articulée en
trois rubriques:
Identification du cas d’utilisation
Titre: Nom du cas d’utilisation
Objectif: Décrire succinctement le contexte et les résultats
attendus du cas d’utilisation
Acteurs: Le ou les acteurs concernés par le cas doivent
être identifiés en précisant globalement leur rôle.
Responsable: l’auteur du cas d’utilisation
Date: les dates de création et de modification du cas sont
données ici
Version: la version du cas

d’utilisation
77
Description des scénarii
Description du déroulement du cas sous la forme d’une
séquence de messages échangés entre les acteurs et le
système.
Événement déclencheur: indiquant le début du CU
Pré-conditions: Conditions particulières requises avant
l’exécution du cas.
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énarii alternatifs: flots d’événements qui surviennent peu
régulièrement assurent un fonctionnement correct.
Scénarii d’exception: ne surviennent que rarement qui ne
permettent pas une terminaison correcte du cas d'utilisation.

d’utilisation
78
Description des scénarii
Description du déroulement du cas sous la forme d’une
séquence de messages échangés entre les acteurs et le
système.
Post-conditions: Conditions particulières devant être réunies
après l’exécution du cas (garantie à respecter)
Rubriques optionnelles
Besoins d’I.H.M.(Interface Homme Machine) : contraintes
d ’IHM, copies écran.
Contraintes non-fonctionnelles: Fiabilité, confidentialité, ….
 etc

d’utilisation
79
Exemple: Description du cas « Retirer argent »
Sommaire d’identification
Titre: Retirer de l’argent
Objectif: ce CU permet à un Porteur de carte, qui n’est pas
client de la banque, de retirer de l’argent, si son crédit
hebdomadaire le permet.
Acteurs : Porteur de carte (principal), Système d’autorisation
(secondaire)
Date de création:19/09/2012
Date de modification: 20/09/2012
Version:1.1 Responsable: GO Téré

d’utilisation
80
Description des scénarios
Pré-conditions:
La caisse du GAB est alimentée.
 Aucune carte ne se trouve déjà coincée dans le lecteur.
 La connexion avec le Système d’autorisation est
opérationnelle.
Scénario nominal:
1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB.
2. Le GAB vérifie que la carte introduite est bien une carte bancaire.
3. Le GAB demande au Porteur de carte de saisir son code d’identification.
4. Le Porteur de carte saisit son code d’identification.
5. Le GAB compare le code d’identification avec celui qui est codé sur la puce de la
carte.
6. Le GAB demande une autorisation au Système d’autorisation.
7. Le Système d’autorisation donne son accord et indique le crédit hebdomadaire.

d’utilisation
81
Pré-conditions:
La caisse du GAB est alimentée.
 Aucune carte ne se trouve déjà coincée dans le lecteur.
 La connexion avec le Système d’autorisation est
opérationnelle.
Scénario nominal:
1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB.
2. Le GAB vérifie que la carte introduite est bien une carte bancaire.
3. Le GAB demande au Porteur de carte de saisir son code d’identification.
4. Le Porteur de carte saisit son code d’identification.
5. Le GAB compare le code d’identification avec celui qui est codé sur la puce de la
carte.
6. Le GAB demande une autorisation au Système d’autorisation.
7. Le Système d’autorisation donne son accord et indique le crédit hebdomadaire.

d’utilisation
82
Scénario nominal
8. Le GAB demande au Porteur de carte de saisir le montant désiré du retrait.
9. Le Porteur de carte saisit le montant désiré du retrait.
10. Le GAB contrôle le montant demandé par rapport au crédit hebdomadaire.
11. Le GAB demande au Porteur de carte s’il veut un ticket.
12. Le Porteur de carte demande un ticket.
13. Le GAB rend sa carte au Porteur de carte.
14. Le Porteur de carte reprend sa carte.
15. Le GAB délivre les billets et un ticket.
16. Le Porteur de carte prend les billets et le ticket.

d’utilisation
83
Scénarios alternatifs
A1 : code d’identification provisoirement erroné
L’enchaînement A1 démarre au point 5 du scénario nominal.
5.1.Le GAB indique au Porteur de carte que le code est erroné, pour la première ou
deuxième fois.
5.2.Le GAB enregistre l’échec sur la carte.
Le scénario nominal reprend au point 3.
A2 : montant demandé supérieur au crédit hebdomadaire
10.1. Le GAB indique au Porteur de carte que le montant demandé est supérieur au
crédit hebdomadaire.

d’utilisation
84
Scénarios alternatifs
A3 : ticket refusé
11.1. Le Porteur de carte refuse le ticket.
Scénarios d’exception:
E1 : carte non-valide
L’enchaînement E1 démarre au point 2 du scénario nominal.
2.1. Le GAB indique au Porteur que la carte n’est pas valide (illisible, périmée, etc.),
la confisque ; le cas d’utilisation se termine en échec.

d’utilisation
85
Scénarios d’exception
E2 : code d’identification définitivement erroné
5.1. Le GAB indique au Porteur de carte que le code est erroné, pour la troisième fois.
5.2. Le GAB confisque la carte.
5.3. Le Système d’autorisation est informé ; le cas d’utilisation se termine en échec.
E3 : retrait non autorisé
6.1. Le Système d’autorisation interdit tout retrait.
6.2. Le GAB éjecte la carte ; le cas d’utilisation se termine en échec.

d’utilisation
86
Postconditions
La caisse du GAB contient moins de billets qu’au début du cas d’utilisation
(le nombre de billets manquants est fonction du montant du retrait).
Une transaction de retrait a été enregistrée par le GAB avec toutes les informations
pertinentes (montant, numéro de carte, date, etc.). Les détails de la transaction
doivent être enregistrés aussi bien en cas de succès que d’échec.
Rubriques optionnelles
Besoins d’IHM
Les dispositifs d’entrée-sortie à la disposition de l’acteur principal:
 Lecteur de carte bancaire, Clavier numérique, Ecran pour l’affichage des
messages du GAB, Touches autour de l’écran, Distributeur de billets, Distributeur
de tickets.

d’utilisation
87
Rubriques optionnelles
Exigences non-fonctionnelles
(A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelle
que soit l’action de l’utilisateur.
(B) Résistance aux pannes : si une coupure de courant ou une autre défaillance
survient au cours du cas d’utilisation, la transaction sera annulée, l’argent ne sera
pas distribué. Le système doit pouvoir redémarrer automatiquement dans un état
cohérent et sans intervention humaine.
(C) Résistance à la charge : le système doit pouvoir gérer plus de 1000 retraits
d’argent simultanément

d’utilisation
88
Exercices
Exercice1
Un gérant de bibliothèque désire automatiser la gestion des prêts.
Il commande un logiciel permettant aux utilisateurs de connaître les livres
présents, d'en réserver jusqu'à 2. L'adhérent peut connaître la liste des
livres qu'il a empruntés ou réservés.
L'adhérent possède un mot de passe qui lui est donné à son inscription.
L'emprunt est toujours réalisé par les employés qui travaillent à la
bibliothèque. Après avoir identifié l'emprunteur, ils savent si le prêt est
possible (nombre max de prêts = 5) et s'il a la priorité (il est celui qui a
réservé le livre).
Ce sont les employés qui mettent en bibliothèque les livres rendus et les
nouveaux livres. Il leur est possible de connaître l'ensemble des prêts
réalisés dans la bibliothèque.
Travail à faire
Diagramme des cas d'utilisation
Décrire le cas « Réserver un livre »

d’utilisation
89
Exercices
Exercice 2
L’entreprise RapidPizza regroupe des restaurants à l’enseigne Point Pizza.
Elle livre à domicile des pizzas et d’autres spécialités culinaires. Les Points
Pizza sont tous capables de livrer certaines pizzas classiques ainsi
qu’éventuellement d’autres pizzas spéciales. Actuellement les commandes
se font par téléphone auprès d’un restaurant, limitant le nombre de
commandes acceptables. Chaque client n’a accès qu’aux spécialités du
Point Pizza auquel il s’adresse.
La direction de RapidPizza veut informatiser son processus de commande,
de fabrication et de livraison via un logiciel nommé RapidPizza. Grâce à lui,
elle veut gérer l’ensemble des commandes et des employés, appelés ci-
dessous collaborateurs. RapidPizza rend accessible à tous les clients
l’intégralité des spécialités disponibles : tout plat présent dans au moins un
Point Pizza est proposé. Chaque plat est décrit par son nom et son prix, qui
ne dépend pas du Point Pizza de fabrication

d’utilisation
90
Exercices
Exercice 2
À tout moment il est possible de passer une commande sur RapidPizza : le
client doit donner son numéro de téléphone qui l’identifie de manière
unique. Lors de sa première commande il lui est demandé de saisir en plus
son nom et son adresse, qui sont enregistrés. Les commandes sont
identifiées par un numéro unique. Une même commande peut comporter
plusieurs plats. Pour chaque plat sélectionné il précise la quantité
demandée. Comme une commande peut comporter plusieurs plats et que
certaines spécialités ne sont disponibles que dans certains Points Pizza,
toutes les combinaisons de plats d’une commande ne sont pas forcément
possibles. Dans ce cas la commande est globalement refusée et n’est pas
mémorisée. Le client peut consulter l’état d’une commande. Cela lui permet
notamment de savoir si la livraison d’une commande est en cours. Tant que
la préparation d’une commande n’a pas débuté, il peut l’annuler.

d’utilisation
91
Exercices
Exercice 2
Les Point Pizza sont ouverts 24h/24 : RapidPizza fait appel à de nombreux
collaborateurs aux horaires flexibles et variables. À la signature de leur
contrat un boîtier leur est remis. Il leur suffit d’appuyer sur un bouton pour
signaler leur disponibilité. En appuyant sur un autre bouton ils signalent la
fin de leur disponibilité.
Un livreur utilise son boîtier pour indiquer quand il récupère une commande
au Point Pizza ainsi que quand il l’a livrée au client.
Le gérant peut consulter sur RapidPizza l’état global du système :
commandes, plats, collaborateurs, etc. Il peut affecter un collaborateur à un
Point Pizza ou aux livraisons. Un collaborateur peut changer de lieu de
travail ou de rôle plusieurs fois dans la journée : c’est le gérant qui optimise
le rôle de chacun en fonction des commandes et des disponibilités. Quand
le client passe une commande, il n’indique pas de Point Pizza particulier :
c’est le gérant qui affecte la commande à un Point Pizza.

d’utilisation
92
Exercices
Exercice 2
Dans chaque Point Pizza, un unique collaborateur joue
le rôle de coordinateur en plus de préparer les plats. C’est le seul à interagir
avec RapidPizza : tous les autres collaborateurs sont soit à la préparation
des plats soit à la livraison. Le coordinateur consulte sur RapidPizza les
commandes à réaliser dans son restaurant. Pour chaque plat d’une
commande, il indique si sa réalisation a débuté, si elle est terminée. Quand
tous les plats sont prêts, il prévient oralement l’un de ses livreurs que la
commande est livrable.
Travail à faire
Donner le diagramme de cas d'utilisation
Donner les descriptions des CU «Passer une commande», « Notifier
l’avancement d’une pizza », « Affecter une commande ».

d’utilisation
93
Exercices
Exercice 3
L'entreprise MegaKebab regroupe plus d'une cinquantaine de petit
restaurants appelés "Points Kebab". Cette entreprise est spécialisée dans
la livraison à domicile de ses fameux Kebabs. Jusqu'à présent les
commandes se faisaient par téléphone directement auprès de chaque
restaurant. Un nombre limité de commandes pouvait être traité. Par ailleurs
chaque client devait connaître la carte des plats disponibles auprès du
Point Kebab qu'il contactait. En pratique il ne connaissait que les offres des
points kebab de son quartier.
La direction de MegaKebab souhaite informatiser le processus de
commande / fabrication / livraison via un système logiciel baptisé
CyberKebab. Grâce à ce logiciel, on souhaite gérer à distance et de
manière centralisée l'ensemble des commandes, l'ensemble des Points
Kebabs et l'ensemble des employés appelés "Collaborateurs". Cette
centralisation devrait entre autre permettre de rendre accessible à
l'ensemble des habitants l'intégralité des recettes disponibles.

d’utilisation
94
Exercices
Exercice 3
En réalité le succès des Points Kebab est lié à la diversité des plats
proposés: chaque Point Kebab est capable de préparer le fameux "Kebab",
mais aussi de nombreuses spécialités culinaires comme par exemple des
loukoums, des fallafels, des bricks, etc. Dans un Point Kebab on trouve
même de succulentes "Tartiflettes à la mode Irakienne" dont seul le gérant
connaît la recette exacte. Un autre Point Kebab propose des "loukoums au
sirop d'érable", etc. Suite à un succès grandissant de ces plats rivalisant
favorablement avec les hamburger-ketchup des entreprises concurrentes, il
a été décidé de rendre accessible les informations concernant l'intégralité
des plats proposés sur Internet. Plus précisément, chaque plat est décrit
par un nom, mais également par une photo et par un prix (le prix est le
même dans tous les points kebab).

d’utilisation
95
Exercices
Exercice 3
Dans le cadre d’une politique marketing "Chaud, Chaud ou Remboursé",
une durée est également associée à chaque plat chaud : si le temps écoulé
entre la fin de préparation du plat et la livraison chez le client est supérieur
à cette durée, le client pourra se faire rembourser l'intégralité de sa
commande et se verra même offrir lors de sa prochaine commande des
"cornes de gazelles". Cependant, en pratique, pour ne pas inciter le client à
utiliser cette possibilité, il s'agit de la seule opération qui n'est pas
disponible sur Internet: le client devra remplir une demande écrite de
remboursement sur feuille libre et l'envoyer au gérant de MegaKebab.
A tout moment il est possible de passer une commande par Internet. Le
client doit disposer pour cela d'une carte de crédit qui l'identifiera de
manière unique. Lors d'une première commande il lui sera également
demandé de saisir son nom et de situer son lieu de résidence sur une carte
de la ville. Une même commande peut comporter plusieurs plats. Pour
chaque plat sélectionné le client doit indiquer la quantité désirée.

d’utilisation
96
Exercices
Exercice 3
Après avoir passé sa commande, le client peut à tout moment consulter
l'état de sa commande. Si la commande est en cours de préparation dans
un Point Kebab il pourra même visualiser sa confection grâce à une caméra
WebCam située dans chaque Point Kebab. Si la commande est en cours
de livraison, il pourra suivre le livreur sur la carte. Tant que la commande
n'est pas encore partie du Point Kebab, il pourra l'annuler s'il le désire.
Les Points Kebab sont ouverts 24h/24. Pour assurer un service 24h/24
dans toute la ville, MegaKebab fait appel à un très grand nombre de
collaborateurs. Les collaborateurs, qui sont souvent des étudiants, ont des
horaires extrêmement flexibles. Lors de leur contrat un téléphone portable
leur est remis. Il suffit d'appuyer sur un bouton pour faire part de leur
disponibilité auprès de MegaKebab. Un autre bouton permet d'indiquer
qu'ils ne le sont plus.

d’utilisation
97
Exercices
Exercice 3
A tout moment le gérant peut consulter via Internet l'état du système global.
Il peut affecter un collaborateur soit à un Point Kebab soit à la livraison. En
fait un collaborateur peut ainsi changer de lieu de travail ou de rôle
plusieurs fois dans une journée: le rôle du gérant est d'optimiser l'attribution
de chacun en fonction des commandes. En fait lorsqu'un client passe une
commande, il n'indique pas de Point Kebab particulier; c'est le gérant qui
affecte la commande à un Point Kebab et à un livreur. Notons que sachant
qu'une commande peut être formée de plusieurs plats et que certains plats
sont disponibles uniquement dans certains points kebab, cela voudrait dire
en théorie que certaines commandes devraient être préparées dans
plusieurs points kebab. Pour simplifier il a été jugé préférable d'interdire
cette situation: lorsque le client passe sa commande il lui sera interdit de
former une telle combinaison. Quoi qu'il en soit l'affectation d'une
commande par le gérant est effectuée en fonction de ses propres critères,
mais il cherche en général à optimiser la distance parcourue ainsi que les
activités des Point Kebab et des collaborateurs.

d’utilisation
98
Exercices
Exercice 3
Chaque livreur utilise son propre moyen de transport (bus, vélo, roller,
voiture, etc.). Par contre un appareil appelé "Pilote" lui est remis lors de son
affectation à la livraison. Chaque pilote intègre un GPS permettant de
localiser le livreur de manière extrêmement précise dans la ville via une
liaison satellite. Un écran permet au livreur de consulter les commandes qui
lui ont été affectées. Il peut à tout moment consulter la carte et se situer par
rapport aux points Kebab et aux clients à livrer. Le livreur utilise également
le pilote pour indiquer lorsqu'il récupère une commande auprès du Point
Kebab et lorsqu'il livre la commande au client.
Dans chaque Point Kebab un collaborateur joue le rôle de "coordinateur".
C'est le seul à agir directement avec CyberKebab: les autres collaborateurs
sont à la préparation des plats. Le coordinateur consulte les commandes à
réaliser et a pour charge d'indiquer pour chaque commande lorsque sa
préparation débute, lorsqu'elle se termine et lorsqu’elle est remise au
livreur.

d’utilisation
99
Exercices
Exercice 3
Travail à faire:
Compléter le diagramme des cas d'utilisation du système CyberKebab.
Seuls les acteurs humains sont pris en compte (ni le Pilote, ni le téléphone
ne sont représentés).

d’utilisation
10
Exercices
Exercice 3

3 – Modélisation des objets
du système
Modélisation objet
Diagramme de classes
Diagramme d’objets
Diagramme de paquetages
101

Modélisation objet
102
La modélisation objet consiste à créer une représentation
abstraite, sous forme d'objets, d'entités ayant une
existence matérielle ou bien virtuelle.
Concepts de base
Objet
Un objet informatique est une représentation simplifiée
d’une entité, matérielle ou abstraite, du monde réel.
Un objet encapsule une partie de la connaissance du
monde dans lequel il évolue.
Un objet est caractérisé par son identité, son état et son
comportement.
Objet = Identité + État + Comportement

Modélisation objet
103
Concepts de base
Etat d’un objet
Un attribut d’un objet est une information élémentaire qui
le caractérise. Un attribut est caractérisé par l’ensemble
des valeurs qu’il peut prendre. Un attribut peut être:
multivalué: Il peut prendre plusieurs valeurs distinctes
dans son domaine.
dérivé: Sa valeur alors est fonction d'autres attributs.
composé (ou composite) : Il joue alors le rôle d'un groupe
d'attributs. Exemple: Une adresse peut être un attribut
composé des attributs numéro, type de voie, nom de la
voie.

Modélisation objet
104
Concepts de base
Etat d’un objet
L’état d’un objet est l’ensemble des valeurs des attributs
de l'objet à un instant donné.
L‘état d'un objet évolue au cours du temps
Comportement d’un objet
Une opération est une action atomique qu’un objet peut
accomplir.
Il existe cinq types d’opérations:
Constructeurs : créent et initialisent les objets;
Modificateurs ou mutateurs: changent tout ou partie de
l'état de l'objet;
Sélecteurs ou observateurs ou requêtes : renvoient tout
ou partie de l'état de l'objet;

Modélisation objet
105
Concepts de base
Comportement d’un objet
Il existe cinq types d’opérations:
Itérateurs : visitent l'état d'un objet ou le contenu d'une
structure de données qui contient plusieurs objets;
Destructeurs : détruisent les objets.
Le comportement d’un objet est l’ensemble des
opérations qu’il peut réaliser.
Le comportement d’un objet regroupe ses compétences,
représente ce qu’il sait faire.
Le comportement et l’état d’un objet sont liés:
l‘état est modifié par le comportement;
le comportement à un instant donné dépend de l‘état
courant.

Modélisation objet
106
Concepts de base
Identité d’un objet
L’identité caractérise son existence propre.
L'identité permet de distinguer de manière non ambiguë
un objet et cela indépendamment de son état.
L’identité d’un objet est attribuée implicitement à la
création de l'objet
Message
Chaque opération est déclenchée par l'envoi d'un
message.
Un message à un objet est une demande d'activation de
l'une de ses opérations en vue d'obtenir un service donné.
L'envoi d'un message comporte généralement trois
parties :

Modélisation objet
10
Concepts de base
Message
L'envoi d'un message comporte généralement trois
parties :
l'identification de l'objet destinateur ;
le nom du message, qui correspond au nom de l’opération
à activer à sa réception ;
une liste facultative de données nécessaires à la
réalisation du service demandé.
Interface d’un objet
L’interface d’un objet est l’ensemble de tous ses éléments
directement accessibles de l’extérieur.
L’accès se fait par message dans le but d’obtenir de l’objet
des services.

Modélisation objet
10
Concepts de base
Interface d’un objet
L’accès se fait par message dans le but d’obtenir de l’objet
des services.

Modélisation objet
109
Concepts de base
Classe
Une classe est la description d’un ensemble d'objets ayant
même structure(attributs) et même comportement
(opérations).
Une classe est donc composée:
d'attributs qui décrivent la structure de ses objets ;
de opérations qui décrivent les actions applicables à ses
objets ;
d'une interface qui définit les services accessibles,
auxquels on peut faire appel c'est à dire les opérations
pouvant être invoquées de l'extérieur.
Tout objet est une instance d’une classe.

Modélisation objet
110
Principes fondamentaux
Encapsulation
L’encapsulation consiste à intégrer au sein d'une entité
(l'objet) des données(attributs) et le code capable d'agir
dessus (opérations) en cachant son implémentation et en
ne laissant visible que son interface
L'encapsulation :
assure l'intégrité des données ; tout accès étant contrôlé à
travers les opérations.
facilite la maintenance (l'évolution) des logiciels ; une
modification éventuelle de la structuration des données
d'un objet n'a d'incidence que sur l'objet lui-même, les
utilisateurs des services de l'objet ne seront pas
concernés.

Modélisation objet
111
Encapsulation
La mise en œuvre de l'encapsulation se fait généralement
en définissant des niveaux d'accès (privé, protégé, public,
….) aux attributs et opérations. L’interface de la classe est
constituée alors des propriétés publiques.

Modélisation objet
112
Héritage
C'est le mécanisme permettant de créer une nouvelle
classe à partir d'une classe existante, avec transfert de
toutes ses propriétés (attributs et opérations) vers la
nouvelle classe.
On dit que la classe ainsi obtenue hérite ou dérive de la
classe existante.
La nouvelle classe s'appelle sous-classe, classe dérivée,
classe fille ou classe descendante
La classe existante s'appelle super-classe, classe de base,
classe mère ou classe ancêtre.

Modélisation objet
113
Héritage
L'héritage définit la relation « est un.. », « est une sorte.. »
entre la classe fille et la classe mère.
La relation d'héritage met en œuvre les relations de
généralisation et de spécialisation.
Généralisation: : mise en commun de propriétés
communes à différentes classes dans une super-classe.
Spécialisation: création d'une sous-classe par mise
en avant des propriétés spécifiques à un sous-
ensemble d'objets d'une classe.
La spécialisation d'une classe peut être réalisée
selon deux techniques :

Modélisation objet
114
Héritage
Spécialisation:
La spécialisation d'une classe peut être réalisée
selon deux techniques.
Par enrichissement : cela consiste à doter la sous-classe
de nouveaux attributs et opérations représentant les
caractéristiques propres au sous-ensemble d'objets.
Par substitution : cela consiste à donner une nouvelle
définition à une opération héritée lorsque celle-ci se
révèle inadéquate pour l'ensemble des objets décrits par
la sous-classe. La nouvelle définition masque alors celle
héritée; on parle alors de redéfinition.

Modélisation objet
115
Héritage
L'héritage est :
simple : quand une classe hérite d'une seule classe ;
multiple: quand une classe hérite de plusieurs classes.
L'héritage évite la duplication et encourage la réutilisation.
Polymorphisme
C'est le mécanisme permettant de déclencher des
opérations différentes en réponse à un même message
Le polymorphisme représente en fait la faculté d'une
opération à pouvoir s'appliquer à des objets de classes
différentes et avoir un comportement adapté à ces objets.
Le polymorphisme augmente la généricité du code.

Modélisation objet
116
Polymorphisme
Il existe trois types de polymorphismes:
Polymorphisme de traitement ou surcharge (ad-hoc,
overloading) : possibilité de définir plusieurs opérations de
même nom mais possédant des paramètres différents en
nom ou en type.
Polymorphisme d'héritage (redéfinition, overriding) :
possibilité de redéfinir une opération dans des classes
héritant d’une classe de base.
polymorphisme paramétrique (généricité, template) :
possibilité qu’un même code puisse s’appliquer à
n'importe quel type.

117
Introduction
Le diagramme de classes est la représentation de
l’ensemble des informations gérées dans un domaine,
avec leurs organisations (structuration en classes, relations
entre ces classes).
Le diagramme des classes permet spécifier la structure
des objets dont un système est composé et les liens entre
eux.
Il spécifie QUI sera à l'oeuvre dans le système pour réaliser
les fonctionnalités décrites par les diagrammes de cas
d'utilisation.

118
Représentation des classes
Une classe est représentée par un rectangle à trois
niveaux essentiellement:
Niveau 1 contient le nom de la classe
Niveau 2 contient la description des attributs de la classe
Niveau 3 contient la description des opérations de la
classe
Nom de la classe
Liste des attributs
Liste des opérations

119
Représentation du nom de la classe
Le nom d’une classe est décrit selon le format
<<stéréotype>>Package1:: ... ::PackageN::NomClasse{abstract}{auteur :valeur, état : valeur, ...}
Facultatif
Précise le sens de
la classe; peut être:
interface,
enumeration,
boundary,
control,
entity,
utility,
….
Facultatif
Noms des paquetages
contenant la classe
Obligatoire
Nom de la classe.
Le nom dune classe doit être
significatif, complet et commencer
par une majuscule; s’il comporte
plusieurs mots la 1ère lettre de
chaque mot doit être une majuscule
Facultatif
Indique que
la classe est
abstraite
Facultatif
Informations générales
comme le nom de l’auteur,
l’état de la classe, la date,...

120
Représentation du nom de la classe
Le nom d’une classe est décrit selon le format
<<stéréotype>>Package1:: ... ::PackageN::NomClasse{abstract}{auteur :valeur, état : valeur, ...}
Exemple:

121
Représentation des attributs de la classe
Format général de description d’un attribut
visibilité / nom : type[multiplicité]=valeurinitiale{propriétés}
Facultatif
Définit le niveau d’accès de l’attribut
+(public): attribut visible par tous
#(protégé): attribut visible seulement dans la classe et ses sous-classes
- (privé): attribut visible seulement dans la classe
~(package):attribut visible dans les classes de même paquetage; c’est la visibilité par défaut
Facultatif
Indique que
l’attribut est
calculé Obligatoire
Nom de
l’attribut,
unique dans
la classe
Facultatif
Type de l’attribut; peut être
un type primitif (entier, réel,
booléen, caractère, chaînes
de caractères, date) ou une
classe.
Facultatif
valeur de l’attribut lors
de l’instanciation de la
classe
Facultatif
indique le nombre de valeurs que l’attribut peut contenir.
0..1: 0 ou une valeur n..n (ou n):exactement n valeurs
0..* (ou *): 0 à plusieurs valeurs 1..*: 1 à plusieurs valeurs
m..n: entre m et n

122
Facultatif
Contraintes sur l’attribut. Il existe des contraintes prédéfinies:
readOnly ou frozen: valeur de l’attribut ne peut plus être modifiée une fois la valeur initiale fixée
(attribut constant)
changeable: attribut modifiable à tout moment; contrainte par défaut.
unique: aucun doublon dans les valeurs de l’attribut.
not null: L’attribut doit à tout prix a une valeur
addOnly: Pour un attribut de multiplicité>1, seul l’ajout de valeurs est possible
ordered: Pour un attribut de multiplicité>1, ses valeurs doivent être ordonnées
list: Pour un attribut de multiplicité>1, ses valeurs ne sont pas nécessairement ordonnées;
contrainte par défaut
set: Pour un attribut de multiplicité>1, ses valeurs sont distinctes

123
Exemple:

124
Représentation des attributs dérivés
Un attribut dérivé est un attribut pouvant être calculé à
partir d’autres attributs.
Un attribut dérivé est représenté en précédant, dans sa
description, son nom du signe « / ».
Exemple
Lors de la conception, un attribut dérivé peut être utilisé
comme marqueur jusqu’à ce qu’on puisse déterminer les
règles à lui appliquer.

125
Représentation des attributs de classe
Un attribut de classe est un attribut dont la valeur est
commune et partagée par tous les objets de la classe qui
seront créés.
Un attribut de classe existe en un seul exemplaire et est
attaché à la classe.
Un attribut de classe est représenté en soulignant sa
description.
Exemple

126
Représentation des attributs multivalués
Un attribut multivalué est représenté en ajoutant une
multiplicité dans sa description.
Exemple

127
Représentation des opérations de la classe
Format général de description d’une opération
visibilité nom(paramètre1, ... , paramètreN) :type_retour{propriétés}
sens nom :type [multiplicité]=valeur_défaut
Obligatoire
Nom de
l’opération
Facultatif
Paramètres de l’opération;
chaque paramètre est décrit
par:
Facultatif
Sens de transmission du paramètre
in(par défaut):l’objet appelant l’opération doit fournir la valeur de l’argument à l’entrée de l’opération
out: l’objet responsable de l’opération doit fournir la valeur de l’argument à la sortie de l’opération.
inout: l’objet appelant l’opération doit fournir la valeur du l’argument en entrée, mais celle-ci peut
être modifiée par l’objet responsable de l’opération à la sortie
Obligatoire
Nom du paramètre
Obligatoire
Type du paramètre avec
éventuellement sa multiplicité
facultatif
valeur prise par l’argument si
aucune valeur n’est donnée lors
l’utilisation de cette opération.
Facultatif
type de la valeur
retournée par
l’opération
Facultatif
propriétés correspondent à des
contraintes ou à des informations
complémentaires
query: l’opération n’altère pas l’état de
l’objet
abstract : opération non implémentée
virtual: opération à liaison dynamique
leaf: opération qui ne peut pas être
réimplémentée par une classe fille.
root: opération définie pour la 1ère fois
dans une hiérarchie de classes.
<<pré-condition>>,<<post-condition>>

128
Format général de description d’une opération
visibilité nom(paramètre1, ... , paramètreN) :type_retour{propriétés}
Exemple:

129
Représentation des constructeurs et destructeurs
Les constructeurs sont représentés en précédant, dans
leurs descriptions, leurs noms de l’un des stéréotypes
<<create>> ou <<constructor>>
Le destructeur est représenté en précédant, dan sa
description, son de l’un des stéréotypes <<destructor>> ou
<<destroy>>
Exemple

130
Représentation des opérations de classe
Une opération de classe est une opération qui ne dépend
pas des valeurs propres de chaque objet, mais qui porte sur
les attributs de classe ou uniquement sur ses paramètres
Une opération de classe est représentée en soulignant sa
description.
Exemple

131
Représentation des opérations abstraites
Une opération abstraite est une opération n’admettant pas
d’implémentation dans la classe où elle est déclarée: au
niveau de la classe, on ne peut pas dire comment réaliser
l’opération.
Une opération abstraite est représentée soit en utilisant la
propriété {abstract} soit en écrivant en italique sa description.
Exemple

132
Remarques
Autres compartiments
Deux autres compartiments peuvent être ajoutés:
Le compartiment des responsabilités de la classe pour
énumérer l’ensemble des tâches devant être assurées par
la classe mais pour lesquelles on ne dispose pas encore
assez d’informations.
Le compartiment des exceptions pour énumérer les
situations exceptionnelles devant être gérées par la classe.
Liste des attributs
Nom de la classe
Liste des exceptions
Liste des responsabilités

133
Remarques
Différents niveaux de détail
Il est possible de manipuler les classes en limitant le niveau
de description à un nombre réduit de compartiments selon
les objectifs poursuivis par le modélisateur:
description uniquement du nom et des caractéristiques
générales de la classe
description du nom de la classe et de la liste d’attributs
Nom de la classe
Nom de la classe
Liste des attributs

134
Classe abstraite
Une classe est dite abstraite si elle ne fournit pas
d'implémentation pour certaines de ses opérations.
Une classe abstraite est une classe contenant au
moins une opération abstraite.
Une classe abstraite est non instanciable; elle exprime une
généralisation abstraite, qui ne correspond à aucun objet
existant du monde.
Graphiquement, le nom d’une classe abstraite est suivi de
la contrainte {abstract} ou en italique.
Exemple:

135
Exercices
Exercice 1
Proposer une modélisation, en vue d’une implémentation informatique, de la
situation suivante en mettant en évidence les différents compartiments et ornements
des classes.
Réaliser la modélisation étape par étape, en faisant apparaître, en fonction des
connaissances disponibles, les changements du modèle.
1.Une personne est caractérisée par son nom, son prénom, son sexe et son âge.
Les responsabilités de la classe sont entre autres le calcul de l’âge, le calcul du
revenu et le paiement des charges. Les attributs de la classe sont privés ; le nom, le
prénom ainsi que l’âge de la personne font partie de l’interface de la classe
Personne.
2. Deux types de revenus sont envisagés, le salaire et toutes les sources de revenus
autres que le salaire, qui sont tous deux représentés par des entiers. On calcule les
charges en appliquant un coefficient fixe de 15 % sur les salaires et un coefficient de
20 % sur les autres revenus.
3. Un objet de la classe Personne peut être créé, en particulier, à partir du nom et de
la date de naissance. Il est possible de changer le prénom d’une personne. Par
ailleurs, le calcul des charges ne se fait pas de la même manière lorsque la
personne décède.

136
Exercices
Exercice 2
Le but de ce sujet est d´écrire une application pour aider à la gestion de la
billetterie des différentes salles d'un complexe cinématographique. Les places non
numérotées sont vendues selon deux tarifs :
un tarif "normal" qui est fixé en fonction de la salle et du film qui y est joué,
un tarif réduit (familles nombreuses, militaires, chômeurs, étudiants) qui
correspond à 80% du tarif normal.
Après analyse du problème, il est décidé de représenter les salles de cinéma par
des objets, instances d'une classe SalleCinema définie comme suit :
Les informations caractérisant une salle de cinéma sont :
une chaîne de caractères qui contient le titre du film joué,
un entier qui contient le nombre de places de la salle,
un réel qui contient le prix unitaire d'une place à tarif normal,
un entier qui contient le nombre de places qui ont été vendues à tarif normal,
un entier qui contient le nombre de places qui ont été vendues à tarif réduit.
Les valeurs des trois premières caractéristiques (titre du film, nombre de place, prix
de la place) sont fixées lors de la création d'un nouvel objet SalleCinema (c'est-à-
dire, sont passées en paramètres du constructeur). Quand aux deux autres
variables (nombre de places vendues à tarif normal et nombre de places vendues
à tarif réduit) elles sont bien sûr initialisées à 0.

137
Exercices
Exercice 2
On veut pouvoir disposer des services suivants :
calculer et renvoyer le nombre de places encore disponibles dans la salle.
Vendre des billets pour la salle. Si le nombre de places demandé est supérieur au
nombre de places disponibles la vente n'est pas effectuée et il est affiché un
message indiquant que la vente n'est pas possible. Sinon le nombre de places
vendues à tarif normal ou à tarif réduit (selon qu'il y a réduction ou non, par défaut il
n'y a pas de réduction) est mis à jour et le prix à payer est affiché.
permettre lorsque la vente de billets pour une séance est terminée de remettre à
0 les compteurs de nombre de places vendues en vue de la vente de billets pour la
prochaine séance.
Avoir le chiffre d'affaires produit par la salle pour la séance en cours (total des
ventes depuis la création de l'objet salle ou la dernière remise à zéro du nombre de
places vendues).
Avoir le taux (pourcentage) de remplissage de la salle.
afficher la valeur de chacune des informations de la salle (le titre du film, le
nombre de places de la salle, le nombre de places vendues à tarif normal, le
nombre de places vendues à tarif réduit, le prix de la place). Par exemple, pour une
salle de 60 places jouant le film "Sacré Graal" dont 20 places ont été vendues au
tarif normal (de 750F) et 14 places ont été vendues au tarif réduit l'affichage
pourrait être le suivant :

138
Exercices
Exercice 2
Film Nombre de places : 60,
Prix d'une place : 750 F,
20 places vendues au tarif normal,
14 places joué : Sacré Graal,
vendues au tarif réduit.
Représenter la classe salleCinéma

139
Exercices
Exercice 3
Un article caractérisé par les informations suivantes : Référence, Désignation,
PrixHT, TauxTVA, commun à tous les articles.
Ces informations doivent seulement être accessibles par le biais des accesseurs
(get/set) en lecture/écriture.
La classe décrivant ces articles doit contenir:
des opérations de construction;
Une opération de calcul du prix TTC d’un article qui équivaut à : PrixHT +
(PrixHT*TauxTVA/100).
Une opération d’affichage des informations de l’article.
Représenter la classe de ces articles

140
Représentation des relations
Les objets d’un système communiquent entre eux par envoi
de message.
Mais, pour qu’un objet A puisse envoyer un message à un
objet B, il faut qu’il y ait un lien de A vers B c’est-à-dire une
connexion physique ou conceptuelle entre A et B.
Donc il existe des relations entre les objets d’un système.
Comme les objets ne sont que des instances de classes, il
en résulte que les classes elles-mêmes sont reliées.
Il existe cinq grandes catégories de relations entre classes.

141
Association
Définition
Une association est une relation entre deux classes ou plus,
qui décrit les connexions structurelles bidirectionnelle entre
leurs instances.
Une association indique donc qu'il peut y avoir des liens entre
des instances des classes associées.
Autrement dit, une association décrit un groupe de liens ayant
une structure et une sémantique communes.
Une association représente une relation sémantique
durable entre deux classes.

142
Association
Représentation
Trait plein reliant les classes en relation.
C1 C2
rôle1
mult1
rôle2
mult2
nom
Facultatif
Nom de l’association
Texte unique décrivant la signification de l’association. Utiliser une forme verbale active
(“travaille pour”) ou passive (“employé par”)
Facultatif
Sens de lecture de l’association
Utilisation des signes ou
Facultatif
Forme nominale décrivant le statut de la classe dans l'association.
Le rôle indique comment C1 (resp C2) voit C2(resp C1)
Le rôle est un pseudo-attribut de la classe en face. Peut contenir une visibilité.
Utile dans les associations reflexives ou multiples entre deux classes
Facultatif
Nombre d'instances impliquées dans l'association.
1  1..1 (exactement 1)
*  0..* (0 ou plusieurs)
n  n .. n (exactement n)
1..*  1 ou plusieurs (au moins un)
0..1  0 ou 1 (au plus un)
n..m entre n et m
l,n,m  l, n ou m

143
Association
Représentation
Exemple

144
Association
Navigabilité d’une association
La navigabilité d’une association entre les classes C1 et C2
est la capacité d’une instance de C1 (resp. C2) à accéder aux
instances de C2 (resp. C1)
Une association est par défaut à navigabilité bidirectionnelle:
C1 a un attribut de type C2 et C2 a un attribut de type C1
Cependant, il est fréquent d’avoir besoin d’une seule
direction; l’association est alors orientée pour avoir une
navigabilité restreinte, unidirectionnelle:

145
Association
Navigabilité d’une association
Exemple
Spécification : on veut être en mesure de savoir le client qui a
fait la commande et non toutes les commandes d’un client
Conception :
Implémentation : la classe commande doit avoir un attribut
faisant référence à la classe client

146
Association
Classe-association
Une association peut apporter de nouvelles informations
(attributs ou opérations) qui n’appartiennent à aucune des
deux classes qu’elle relie et qui sont spécifiques à
l’association.
Dans ce cas, l’association doit être promue en classe
Une classe-association est représentée par une classe reliée
à l’association par un trait en pointillé.
Une classe-association peut être remplacée par une classe
intermédiaire qui sert de pivot.

147
Association
Classe association
Exemple

148
Association
Qualification d’une association
Un qualificatif (ou clé) est un attribut (ou un ensemble
d’attributs) d’association dont les valeurs partitionnent
l’ensemble des objets reliés à un objet à travers une
association.
La qualification permet donc la sélection d’un sous-ensemble
des objets qui participent à l’association à l’aide du
qualificatif.
La qualification se représente par un rectangle placé au
niveau de la classe source du qualificatif.
Un qualificatif agit toujours sur une association dont la
multiplicité est plusieurs du côté cible.

149
Association
Qualification d’une association
Exemple
La qualification d’une association permet de restreindre la
multiplicité de l’association.

150
Association
Degré (ou arité) d’une association
Le degré d’une association est le nombre de classes
participant à l’association.
En fonction du degré, on distingue:
Association unaire : relie des instances d'une même
classe.
Association binaire : relie 2 classes distinctes

151
Association
Degré (ou arité) d’une association
Le degré d’une association est le nombre de classes
participant à l’association.
En fonction du degré, on distingue:
 association ternaire : relie 3 classes distinctes
peut être remplacée par

152
Association
Contraintes sur les associations
Permettent d’imposer des règles à respecter lors du passage
à l’implémentation(codage)
Il est possible d’attribuer toutes sortes de contraintes à une
association
Les contraintes sont représentées entre accolades et
peuvent être exprimées dans n’importe quel langage
Il existe un certain de contraintes prédéfinies souvent
utilisées.

153
Association
 Sur une extrémité
C1 C2
{contrainte }
Il existe des contraintes prédéfinies:
readOnly ou frozen: interdit l’ajout, la suppression ou la mise à jour des liens d’un objet vers
les objets de la classe associée, après l’initialisation du premier.
changeable ou variable: lien modifiable; contrainte par défaut.
addOnly: autorise l’ajout de nouveaux objets, mais pas leur suppression ni leur mise à jour.
ordered: Elle indique que les objets seront ordonnés à chaque opération de création,
modification, suppression, …
list: Elle indique que les objets ne sont pas nécessairement ordonnées; contrainte par défaut
set: Elle indique que les objets sont distincts;

154
Association
 Sur une extrémité
Exemples
C1 C2
{contrainte }
2
parent
0..*
enfant
Personne
{frozen}
1
1..*
1
0..*
Personne Liste
Enfants
{addOnly}

155
Association
 Entre deux extrémités
Exemple:
C1 C2
{contrainte }

156
Association
 Entre deux associations
Exemple:
C1 C2
{contrainte }
Il existe des contraintes prédéfinies:
subset: inclusion, indique qu’une collection est incluse dans une autre.
xor: exclusion, Indique que parmi un groupe d’associations, une seule est valide à la fois
etc

157
Association
 Entre deux associations
Exemple:
C1 C2
{contrainte }

158
Association
 Exercices
Modéliser avec un diagramme de classes les énoncés suivants (il y a toujours au
moins un classe Personne) :
Un comité est composé d'au moins 2 personnes qui sont ses membres. L'unique
président du comité est également un membre du comité.
Un hôtel a plusieurs clients et un ou plusieurs employés. Les employés de l'hôtel
n'ont pas le droit de prendre une chambre dans ce même hôtel.
Une personne est née dans un pays et cela ne peut être modifié. Une personne a
visité un certain nombre de pays, dans un ordre donné, et le nombre de pays
visités ne peut que croître. Une personne aimerait encore visiter toute une liste
de pays, et selon un ordre de préférence.

159
Agrégation
Une agrégation est un cas particulier d’association
exprimant un lien de contenance, d’appartenance entre les
deux objets associés
L'agrégation permet de définir qu'un objet d’une classe
(composite ou ensemble) est l'assemblage d'un ou de
plusieurs objets d’un autre classe (sous-objet ou composant
ou élément).
Agrégat ou Composé
Agrégé

160
Agrégation
L'agrégation est représentée par un trait dont l’extrémité du
côté de l’agrégat est terminée par un losange vide:
Exemple:

161
Agrégation
Les sous-objets doivent avoir une relation structurelle ou
fonctionnelle avec l'objet dont ils sont les composants
Exemple: Un clavier fait partie d'un ordinateur.
L'agrégation est une relation antisymétrique : si un objet A
fait partie d'un objet B, alors B ne fait pas partie d'un objet
A (même indirectement).
L’agrégation est une relation transitive : si un objet A fait
partie d'un objet B, et que B fait partie d'un objet C, alors A
doit faire partie d'un objet C.
Dans une agrégation, les parties (les composants) sont
séparables de l’agrégat (le tout).
Dans une agrégation, les composants peuvent appartenir
plusieurs agrégats.

162
Composition
Une composition est une agrégation forte dans laquelle la
vie des composants (éléments) est liée à celle de l’agrégat
(composé) :
Création/Copie/Destruction du composite 
Création/Copie/Destruction de ses composants
Ainsi, contrairement à l’agrégation, une
instance de composant ne peut être liée qu’à
un seul agrégat.

163
Composition
La composition est représentée par un trait dont l’extrémité
du côté du composé est terminée par un losange plein:
Exemple:

164
Héritage
Représentation
L’héritage est représenté par une flèche à tête triangulaire
blanche pointant sur la classe mère:
Superclasse
Sous classe

165
Héritage
Représentation
Exemple:
Compte
-
-
-
N°Compte
Solde
Client
: string
: float=10000
: Personne
+
+
+
+
<<Constructor>> Compte ()
Deposer (montant : float)
Retirer (somme: float)
AvoirSolde ()
: void
: void
: float
CompteEpargne
+
+
<<Constructor>> CompteEpargne ()
AvoirInterets ()
- Taux : float=5.5
+ AttribuerTaux () :void

166
Héritage
Généralisation/spécialisation
La relation d'héritage met en œuvre les relations de
généralisation et de spécialisation.

167
Héritage
Contraintes sur la relation d’héritage
C1
C2
C3
{contrainte }
contrainte peut être:
disjoint: les sous-classes n'ont aucune instance en commun
overlapping ou chevauchement: les sous-classes peuvent avoir une ou plusieurs instances en
commun
complete: la généralisation ne peut pas être étendue
incomplete: les sous-classes spécifiées ne couvrent pas la super-classe

168
Héritage
Exercices
Les modems et claviers sont des périphériques d’entrée/sortie(il en existe d'autres).
Une transaction boursière est un achat ou une vente
Un répertoire contient des fichiers
Une pièce contient des murs
Un compte bancaire peut appartenir à une personne physique ou morale
 A l'université, un bâtiment d'enseignement dispose d'un certain nombre de salles
et de chaises. A un instant donné, une chaise est obligatoirement à l'intérieur d'une
salle. Une chaise peut être déplacée dans une autre salle selon les besoins.
Deux personnes peuvent être mariées.
Un pays possède plusieurs villes et une seule capitale.
Un dessin est soit du texte, soit une forme géométrique, soit un groupe de dessins.
Des personnes utilisent un langage pour un projet.
Une personne joue dans une équipe pour une certaine durée.
Élaborer les diagrammes de classe correspondants en choisissant le type de relation
approprié (généralisation, composition, agrégation ou association).

169
Héritage
Exercices
Définir et représenter les relations qui doivent exister entre les différentes entités
suivantes en justifiant votre réponse :
Un cas d'utilisation "Acheter un produit" et un cas d'utilisation "Vérifier la
disponibilité du produit"
Une classe "Ordinateur" et une classe "Système d'Exploitation"
Une classe "Outil" et une classe "Marteau".
Un acteur "Peintre", un acteur "Artiste" et un acteur "Chanteur"
Un cas d'utilisation "Jouer à la loterie" et un cas d'utilisation "Gagner à la loterie"
Une classe "Document" et une classe "Feuille".

170
Héritage
Héritage multiple
Autorisé en UML
Construction d’une classe à partir de plusieurs classes
différentes.
Peut être source des conflits qu’il faut résoudre
Exemple:
Les étudiants sont des personnes qui peuvent s'inscrire et se désinscrire à
l'université.
Les enseignants, identifiés par un numéro, sont des personnes qui dispensent des
cours à l'université. Un cours, caractérisé par son intitulé et ses crédits, n'est
dispensé que par un seul enseignant. Les doctorants peuvent s'inscrire et se
désinscrire à l'université comme les étudiants et dispenser des cours comme les
enseignants.
Proposer une modélisation de cette situation en utilisant l'héritage multiple.

171
Dépendance
Définition
Une dépendance désigne le cas où une entité
(classe, interface, paquetage, instance, opération, attribut,
cas d’utilisation, …), appelée client utilise d’une manière
quelconque une autre entité, appelée serveur.
Les relations d’association, d’agrégation, de composition, de
généralisation sont des relations de dépendance
particulières qui ont une sémantique forte et ont donc une
notation particulière.

172
Dépendance
Représentation
La dépendance est représentée par une flèche discontinue
orientée du client vers le serveur:
Types de dépendances
La dépendance est un concept très général pouvant signifier
différents types de relations entre deux entités.
Pour préciser le type de dépendance, on dispose de
différents types de stéréotypes normalisés.

173
Dépendance
Types de dépendances
Stéréotype Signification
«call» La source appelle une opération de la cible
«create» La source crée une instance de la cible.
«derive» La source est dérivée de la cible.
«instanciate» La source est une instance de la cible.
«permit» ou
«friend»
La cible autorise la source à accéder à ses fonctionnalités privées.
«realize» La source implante une spécification ou interface définie par la cible.
«substitute» La source peut être substituée à la cible.
«use» La source a besoin de la cible pour son implantation.
«access» On peut accéder, depuis la source, à un élément de la cible
«import» On peut amener dans la source un élément de la cible
«bind» La source est une classe instance de la cible qui est une classe
générique.

174
Stéréotypes de classes
Définition
Les stéréotypes sont une classe d’éléments de modélisation,
utilisée pour définir une utilisation particulière d’un élément de
modélisation.
Un stéréotype est représenté par son nom entre << >>.
Un stéréotype peut être associé à un pictogramme
particulier qui le rend aisément identifiable.
<<actor>>
nomActeur
nomActeur

175
Interface
Définition
Une interface est une classe sans attribut dont toutes
les opérations sont abstraites.
Le rôle d’une interface est de décrire un ensemble
d’opérations assurant un service cohérent qu’une
classe, un paquetage ou un composant peut offrir.
Les éléments qui utilisent l'interface peuvent exploiter tout ou
partie de l'interface.

176
Interface
Représentation
Une interface est représentée par un classeur avec le
stéréotype <<interface>>:
ou par un cercle:
<<interface>>
Nom_interface
Nom_interface

177
Interface
Propriétés et relations
Comme les classes abstraites, les interfaces ne peuvent être
instanciées.
Relation de réalisation
Une interface doit être réalisée par au moins une classe.
Une classe réalise une interface si elle est capable
d’exécuter toutes les opérations de l’interface, qu’elle hérite
alors.
La relation de réalisation est représentée par un trait
discontinu terminé par une flèche triangulaire avec le
stéréotype «realize» si l’interface est représenté par un
classeur et par un trait plein si l’interface est représente par
un cercle.

178
Interface
Relation de réalisation
Relation d’utilisation
Une classe (classe cliente de l’interface) peut utiliser
une interface (interface requise). La classe utilisatrice
de l’interface est reliée au symbole de l’interface par
une flèche en pointillé avec le stéréotype <<use>> ou par un
trait plein terminé par un arc(UML2)
Toute classe implémentant l'interface pourra alors être utilisée.
C1
Interface
C <<realize>> interface
<<interface>>
C <<use>>
interface
<<interface>> C1
interface1

179
Interface
Relation d’héritage
Exemple:
Une interface peut hériter
d'une autre interface

180
Interface
Exemple:

181
Classe énumération
Définition
Une classe énumération est type de classe, permettant de
définir une énumération.
Une énumération est un type de données UML, possédant
un nom, et utilisé pour énumérer un ensemble fini de
littéraux correspondant à toutes les valeurs possibles que
peut prendre une expression de ce type.

182
Classe énumération
Représentation
Une énumération est représentée par un classeur possédant
le stéréotype «enumeration»:
Exemple
<<enumeration>>
Nom_enum
Liste des littéraux
<<enumeration>>
Sexe
Masculin
Féminin

183
Classe utilitaire
Définition
Une classe utilitaire est une classe dont tous les membres
ont une portée de classe; les attributs et les opérations
deviennent des variables et des procédures et fonctions
globales.
Une classe utilitaire ne peut pas être instanciée.

184
Classe utilitaire
Représentation
Une classe utilitaire est représentée par un classeur
possédant le stéréotype «utility»:
Exemple
<<utility>>
Nom_classe
Liste attributs
Liste opérations
<<utility>>
Math
PI: real=3.14
sinus(Angle): real
cosinus(Angle): real
tangente(Angle): real

Classe générique
Définition
Une classe générique ou classe paramétrable ou modèle de
classes est une classe paramétrée par d’autres types.
Représentation
Exemple
185
paramètretype
C

186
Instanciation de classes génériques
La production effective d’une classe de la famille que
définit une classe générique s’appelle instanciation.
L’instanciation d’une classe générique peut se faire deux
manières:
En utilisant une dépendance stéréotypée « bind »
Exemple
paramètretype
C
C1
<<bind>> <paramètretype->typeréel>
<<bind(typeréel)>>
ou

187
Instanciation de classes génériques
En indiquant dans la classe obtenue, les types utilisés,
entre chevrons:
Exemple
C1<paramètretype->typeréel>

Stéréotypes de Jacobson
Pour rendre les modèles plus précis et plus lisibles,
Jacobson a préconisé de différencier dès l’analyse trois 3
types de classes afin de faciliter l’implémentation
Classes Boundary (classes façade, classes IHM)
classes servant à modéliser les interactions entre le système
et ses acteurs.
Le plus souvent un objet <<boundary>> est un objet
d’interface utilisateur (UI)permettant de recueillir des
données ou de présenter de l’information: formulaire ou boîte
de dialogue (Fenêtre « Windows », page web, …. )
Il y a au moins une classe <<boundary>> par paire
acteur-cas d’utilisation
188

Classes Boundary (classes façade, classes IHM)
 Représentations:
189
ou
<<boundary>>
Nom_classe
Liste attributs
Liste opérations

Classes Control
Classes contenant la cinématique de l’application c’est-à-dire
elles sont utilisées pour représenter la coordination,
l’enchaînement et le contrôle d’autres objets.
Elles contrôlent le comportement des cas d’utilisation,
représentent des règles de gestion.
Elles font la transition entre les classes <<boundary>> et les
classes métier
Elles ne donnent pas forcément lieu à de vrais objets de
conception.
On a une seule classe <<control>> par cas d’utilisation.
190

Classes Control
191
<<control>>
Nom_classe
Liste attributs
Liste opérations
ou

Classes Entity
Classes représentant les objets métier, contenant
des informations durables et persistantes.
192
<<entity>>
Nom_classe
Liste attributs
Liste opérations
ou

Règles d’interactions entre les classes
Les classes « Boundary » ne peuvent être reliées qu’aux
classes « Control ».
Les classes « Control » ont accès aux classes « Boundary »,
aux classes « Entity » et aux autres contrôles.
Les classes « Entity » ont accès aux autres classes «Entity
» et ne sont reliées qu’aux classes « Control ».
193

Elaboration d’un diagramme de classes
A partir d’une description du système :
194
1. Identifier un premier ensemble de classes candidates
2. Identifier les associations et les attributs
3. Identifier les généralisations
4. Lister les traitements, choisir les opérations
5. Vérifier le modèle obtenu
6. Itérer jusqu’à satisfaction …
a.Supprimer les transitivités
b.S’assurer que le schéma répond à la demande

Implémentation d’un diagramme de classes en C++
Implantation des classes
Classe UML Classe C++
Attributs:
Attribut d’une classe UML Donnée membre de la classe
C++ correspondante
Les visibilités deviennent:
Pas d’initialisation hors du constructeur sauf pour les attributs de
classe
Attribut de classe Donnée membre statique
Attribut avec la propriété {frozen} Donnée membre constante
195
Visibilité UML Mode d’accès C++
+ public
- private
# protected
~ Pas d’équivalent

Implantation des classes
Opérations:
Opération d’une classe UML Fonction membre de la classe
C++ correspondante
Les visibilités deviennent:
Opération de classe Fonction membre statique
Opération abstraite Fonction membre virtuelle pure
196
Visibilité UML Mode d’accès C++
+ public
- private
# protected
~ Pas d’équivalent

Implantation des associations
Association binaire
Multiplicité mult1=1 ou mult1=0..1 et mult2=1 ou mult2=0..1
L'association est implémentée par ajout dans la classe A (resp. B)
d'un unique attribut, pointeur ou référence sur la classe B (resp. A).
L'instance pointée par l'attribut est supposée avoir été créée
auparavant
197
A B
mult1 mult2

Association binaire
Multiplicité mult1=0..* et mult2=0..*
L'association est implémentée par ajout dans la classe A (resp. B)
d'un attribut correspondant à une collection d‘éléments.
Chaque élément représente un lien vers une instance de la classe B
(resp. A).
Collection : peut être implémentée en tableau dynamique, liste
chainée, std : :vector, std : :list,...
198
A B
mult1 mult2

Association binaire
Association avec sens de navigation.
Pour une association unidirectionnelle, la classe cible ne contient
aucune référence sur la classe source.
Association réflexive
L'association réflexive est implémentée par ajout dans la classe
de deux références ou collections de références sur la classe
si l’association est bidirectionnelle et d’une référence ou collection
de références sur la classe si elle est unidirectionnelle.
Classe association
 L’implémentation de la classe-association se fait par ajout d'une
classe
199
A B
mult1 mult2

Implantation de l’agrégation
Implémentation similaire à une association binaire: l’implémentation
de l'agrégation en C++ se fait habituellement au travers d'un
pointeur ou d'une référence qui pointe ou fait référence à l'objet
agrégé déjà créé en dehors de l'objet conteneur (chaque objet a sa
propre durée de vie).
Implantation de la composition
L’implémentation de la composition en C++ se fait habituellement
soit directement au travers d'un attribut normal en utilisant la liste
d'initialisation pour la création de l'objet composite, soit à l'aide d'une
variable dynamique, en rajoutant un destructeur pour libérer cette
variable dynamique..
200

Implantation de l’héritage
L’héritage est implémenté grâce à la notion d’héritage
C++.
Exercices
201

Passage du diagramme de classes au schéma relationnel
Règle n°1: Transformation d’une classe
Toute classe est transformée en relation.
Les attributs de la classe deviennent les attributs de la
relation.
Il est nécessaire de définir la clé de la relation en fonction
des attributs ou une clé propre si nécessaire.
Exemple:
202
Produit
Réf_produit
Libellé
Prixvente
Produit (Réf_produit, Libellé, Prix_vente)

Règle n°2: Transformation d’une association de
multiplicité
(?..1) d’un côté
Chaque classe se transforme en une relation(Règle n°1).
La clé de la relation correspondant à la classe qui est
associée à la multiplicité(?..1) devient la clé étrangère de
la relation correspondant à l’autre classe.
Exemple:
203

Règle n°3: Transformation d’une association de
multiplicité
(?..n) des deux côtés de l’association
Chaque classe se transforme en une relation(Règle n°1).
L’association se transforme en une relation ayant comme
attributs la clé de chacune des deux classes, plus
d’éventuels autres attributs. La concaténation de ces clés
forme généralement la clé de cette relation.
Exemple:
204

Règle n°4: Transformation d’une agrégation
L’agrégation se transforme de la manière qu’une
association.
Exemple:
Règle n°5: Transformation d’une composition
La classe composite se transforme en relation
 La classe composant se transforme en relation
on ajoute à la clé relation issue de la classe composant
(dite clé locale) la clé étrangère vers la classe composite
pour construire une clé primaire composée.
Exemple:
205

Règle n°6: Transformation de l’héritage
Il y a trois manières possibles de transformer.
Distinction
La super classe se transforme en une relation.
Chaque sous-classe se transforme en une relation; La clé
de la relation correspondant à la super classe devient clé
étrangère dans les relations issues des sous-classes.
Exemple:
206
Cette transformation est
appropriée quand l’héritage est
incomplet et disjoint.

Transformation descendante(push down)
Chaque sous-classe se transforme en une relation dont
les attributs sont les attributs de la super classe et les
attributs de la sous-classe
Exemple:
207
Cette transformation est
appropriée quand l’héritage est
complet et disjoint.

Transformation ascendante(push up)
Créer une relation avec tous les attributs des classes
Ajouter un attribut pour distinguer les types des objets
Exemple:
208

Exercices
Exercice 1
Déterminer le Modèle Relationnel
209

210
Définition
Le diagramme d’objets est la représentation des objets
d’un système (ie les instances des classes) et leurs liens
(ie les instances des relations) à un instant donné.
Il donne une vue figée du système à un moment précis.
Alors que le diagramme de classes modélise des règles, le
diagramme d'objets modélise des faits.
Un diagramme d’objets est composé :
d’objets,
de liens.

211
Concepts
Objet
Exemple
nom_de_l’objet : nom _de_ la_classe
Attribut1=val1
Attribut2=val2
Attributn=valn
Facultatif
Nom de la classe
Facultatif
Nom de l’objet
Facultatif
Attributs avec leurs valeurs

212
Concepts
Lien
Les objets sont reliés par des instances d’associations,
appelées liens.
Un lien représente une relation entre objets à un instant
donné.
La multiplicité des extrémités des liens est toujours de 1.
Un lien se représente comme une association mais s'il a un
nom, il peut être souligné.

213
Concepts
Lien
Exemple

214
Concepts
Lien
Exemple

215
Concepts
Lien
Exemple

216
Concepts
Lien
Exemple

217
Utilité
Le diagramme d’objets peut être utilisé pour:
Illustrer le diagramme de classes en montrant un exemple
qui explique le diagramme.
Préciser certains aspects du système
Exprimer une exception en modélisant des cas particuliers
Prendre une image d'un système à un moment donné
Montrer un contexte

Diagramme de paquetages
218
Introduction
Notion introduite véritablement par UML car
superficiellement décrite par OMT (module, sheet) et
par Booch (subsystem)
Elément d’organisation, le paquetage n’a pas de réalité
concrète dans le système physique final.
Notion fondamentale pour la gestion de gros systèmes
nécessitant la mise en place d’une organisation
hiérarchique et répartie.
En UML 1, les paquetages faisaient partie du digramme de
classe et regroupaient exclusivement des ensembles de
classes.
UML 2 propose un diagramme spécifique: diagramme de
paquetages.

219
Définition
Un paquetage est un regroupement d’éléments de
modélisation partageant un thème commun.
Un paquetage permet de regrouper sous une même
appellation un ensemble d’éléments de modélisation
UML, appelés membres du paquetage, tels que :
des classes, des composants, des nœuds, des
collaborations, des cas d’utilisation, …
des diagrammes de classes, de communication, de
séquence, de cas d’utilisation, …
d’autres paquetages
Bref, un paquetage est susceptible de contenir
n’importe quel élément de modélisation UML.

220
Objectifs
Décomposer un système complexe selon une
organisation hiérarchique. La meilleure façon d’aborder les
gros systèmes consiste à les décomposer en sous-
systèmes élémentaires.
Structurer un système complexe selon une organisation
modulaire. Le paquetage permet de mettre en œuvre un
découpage en couches, soit à base d’interfaces
client/serveur, soit selon les différentes vues
architecturales du système.

221
Objectifs
Répartir l’effort de modélisation sur l’ensemble des acteurs
impliqués dans la construction du système. Un gros
système nécessite la participation de nombreux
intervenants sur lesquels il faut répartir la charge de
travail.
Répartir les tâches de modélisation selon les
compétences de chacun. Le paquetage favorise la mise
en place d’une organisation où l’on attribue à chaque
intervenant une unité de travail répondant à ses
compétences.

222
Représentations
Un paquetage est représenté par un dossier
Représentation globale
Le nom du paquetage se trouve dans le grand rectangle.

223
Représentations
Représentation détaillée
Les membres sont représentés dans le grand rectangle et
le nom du paquetage inscrit dans le petit rectangle.

224
Représentations
Représentation détaillée
Exemple:

225
Représentations
Représentation éclatée
Les membres sont reliés par un lien par le symbole ⊕ au
paquetage dont le nom est inscrit dans le grand rectangle.

226
Espace de nom et visibilité
Un paquetage définit un espace de nommage
Nom complet d’un membre = nom du membre préfixé par
tous les paquetages englobant.
Exemple: GestionProduits::Catalogue::Boulon
Deux membres ne peuvent pas avoir le même nom dans
un paquetage.
Deux membres dans deux paquetages différents sont
différents, quel que soit leurs noms

227
Espace de nom et visibilité
Les membres d’un paquetage peuvent avoir une visibilité
déclarée:
soit de type public (+): un membre public est visible et
accessible de l’extérieur du paquetage; c’est le type de
visibilité par défaut. Un membre public est désigné par un
signe + devant son nom.
soit de type privé (-): un membre privé visible uniquement
par:
Les autres membres de son paquetage
Les membres qu’il englobe, s’il est un paquetage. Un
membre privé est désigné par un signe – devant son
nom.

228
Dépendances entre paquetages
Dépendance de type «import»
Elle correspond à l’importation par un paquetage B de tous
les éléments publics d’un paquetage A.
Ces éléments:
auront la visibilité « public » dans le paquetage B
seront accessibles au paquetage B sans avoir à utiliser
explicitement le nom du paquetage A.

229
Dépendance de type «access»
Elle correspond à l’accès par un paquetage B de tous les
éléments publics d’un paquetage A.
Ces éléments auront la visibilité privé dans le paquetage B.

230
Dépendance de type «merge»
Elle correspond à la fusion de 2 paquetages en un seul.

231
Facteurs de regroupement
Critères fonctionnels : cohérence fonctionnelle.
Critères d’interface (réduire les interactions, éviter les
couplages, simplifier ou diminuer le nombre de liens, etc.)
Critères de ressources (mettre ensemble les
éléments qui utilisent les mêmes ressources, etc.)
etc

4 – Modélisation de la
dynamique du système
Introduction
Diagrammes d’interaction
Diagramme d’états-transitions
Diagramme d’activité
232

Introduction
233
Le modèle dynamique permettre décrire:
Le comportement du système: Comment interagissent les
objets du système pour atteindre un but ? Cet aspect est
montré à travers les diagrammes d’interaction.
L’évolution du système dans le temps:
Comment évoluent les états des objets ? Le diagramme
d’états-transitions permet de décrire cet aspect
Modélisation de flux Diagramme d'activité

Diagrammes d’interaction
234
Introduction
Objectifs
Les diagrammes de cas d'utilisation modélisent à
QUOI sert le système, en organisant les interactions
possibles avec les acteurs.
Les diagrammes de classes permettent de spécifier
la structure et les liens entre les objets dont le système est
composé : il spécifie QUI sera à l'œuvre dans le système
pour réaliser les fonctionnalités décrites par les
diagrammes de cas d'utilisation.

235
Introduction
Objectifs
Les diagrammes d'interaction permettent de
décrire COMMENT les objets du système coopèrent
entre eux et avec les acteurs pour réaliser les services
attendus du système.
Un diagramme d'interaction sert :
Pendant la capture des besoins, à décrire les interactions
entre les acteurs et le système (= boîte noire) c'est à dire
à décrire les scénarios des cas d'utilisation. Les acteurs
interagissent avec le système au moyen d'IHM(Interface
Homme-Machine).

236
Introduction
Objectifs
Un diagramme d'interaction sert :
Pendant la conception, à décrire les interactions entre
les objets du système(= boîte blanche). Les objets
interagissent en s'échangeant des messages.
Ainsi un diagramme d'interaction représente une
interaction.

237
Introduction
Interaction
Une interaction est un échange de messages entre un
ensemble d'objets en vue de réaliser une tâche donnée
Les éléments d’une interaction:
Participants: objets le plus souvent, instance d’acteur,
système lui-même
 Messages entre participants, déclenchant des opérations
Liens: supports de messages
Rôles joués par les extrémités de liens (participants)
Les diagrammes d’interaction vont donc se focaliser
sur les messages spécifiques échangés par des
participants, et sur la façon dont ces messages
concourent à la réalisation de fonctionnalités

238
Introduction
Interaction
Il y a quatre types de diagrammes permettant la
représentation des interactions
Diagramme de séquence;
Diagramme de communication;
Diagramme global d’interaction;
Diagramme de temps.

239
Diagramme de séquences
Objectifs
Il met l’accent sur la représentation temporelle d’une
interaction en montrant la séquence dans le temps
des messages entre les participants à une interaction;
Il permet de représenter les scénarios des cas d’utilisation
Il permet de représenter:
Les diverses entités, appelées participants, mises en
jeu dans la réalisation d’une fonctionnalité;
Les échanges (messages) entre les entités dans le
cadre de cette fonctionnalité;
Le déroulement dans le temps de ces échanges.

240
Représentation
Un diagramme de séquence a deux dimensions
Dimension verticale : le temps
L'ordre d'envoi d'un message est déterminé par sa
position sur l'axe vertical du diagramme ; le temps
s'écoule de haut vers bas.
Dimension horizontale : les participants (objets, acteurs)
L’ordre de disposition des participants sur l'axe horizontal
est sans importance.

241
Concepts
Participant
Définition
Un participant est un émetteur ou un receveur d’un
message dans une interaction.
Un participant peut être un objet du système, un utilisateur
ou le système lui-même.
Représentation
Un participant est représenté par un rectangle dans lequel
figure le nom de l’objet lorsque le participant est un objet.
nom_de_l’objet/nom_du_rôle: nom _de_ la_classe

242
Concepts
Participant
Représentation
Le nom de l’objet est souligné et peut prendre l’une des
formes simplifiées suivantes :
Un participant est par un stickman lorsque le participant est
un utilisateur
nomObjet: nomClasse /nomRôle: nomClasse nomObjet : nomClasse /nomRôle
utilisateur:Acteur

243
Concepts
Participant
Ligne de vie
La ligne de vie d’un participant représente l’existence du
participant pendant une période de temps au cours d’une
interaction.
La ligne de vie est représentée par une ligne verticale en
pointillé en dessous du participant. La vie du participant
s’écoule du haut vers le bas le long de la ligne de vie
utilisateur:Role

244
Concepts
Participant
Période d’activation
La période d’activation représente le temps durant lequel
un participant est actif, c’est-à-dire en train d’exécuter une
action directe ou indirecte.
Elle est représentée par une bande rectangulaire
superposée à la ligne de vie du participant.

245
Concepts
Messages
Définition
Un message est la matérialisation d'une communication
entre un émetteur (source) et un récepteur (destination),
avec transmission des informations nécessaires pour
qu'une activité s'ensuive.
La réception d’un message est considérée par l’objet
récepteur comme un événement qu’il faut traiter ou pas.
Ainsi la réception d’un message peut déclencher une
opération, l’émission d’un signal ou la création/destruction
d’un objet.

246
Concepts
Messages
Définition
Un message est la matérialisation d'une communication
entre un émetteur (source) et un récepteur (destination),
avec transmission des informations nécessaires pour
qu'une activité s'ensuive.
La réception d’un message est considérée par l’objet
récepteur comme un événement qu’il faut traiter ou pas.
Ainsi la réception d’un message peut déclencher une
opération, l’émission d’un signal ou la création/destruction
d’un objet.

247
Concepts
Messages
Définition
Un message est représentée sous forme de flèche
étiquetée par le nom de l’opération ou du signal invoqué; la
forme de la flèche dépend du type de message.
Types et représentations de messages

248
Concepts
Messages
Type signification Représentation
synchrone L’expéditeur est bloqué pendant le traitement du
message par le receveur. Exemple: appel
d’opération
asynchrone L'expéditeur continue son exécution pendant le
traitement du message. Exemple: envoi de signal
de retour Si le traitement d’un message doit retourner des
valeurs à la fin, cela se fait par un message de
retour. Non impératif pour un message synchrone.
minuté L’expéditeur est bloqué pendant un temps donné .

249
Concepts
Messages
réflexif
ou
interne
Un objet peut s’envoyer un message à lui-même.
Cela se représente par une flèche qui revient en boucle
sur la ligne de vie du participant.
récursif L’envoi de messages récursifs se représente par un
dédoublement de la bande d’activation.
trouvé Message dont on connaît le destinataire mais pas
l’émetteur. Représenté par une flèche partant d’un disque
noir vers la ligne de vie d’un objet.
perdu message dont on connaît l’émetteur mais pas le
récepteur. Représenté par une flèche partant de la ligne
de vie d’un objet vers un disque noir.

de création Message entraînant la création d'objets
Représenté par une flèche pointée sur le
rectangle qui symbolise l’objet créé; la flèche peut
être stéréotypée par <<create>>
de destruction Message entraînant la destruction d'objets. La
destruction est indiquée par la fin de la ligne de vie
et par une croix (X), soit à la hauteur du message
qui cause la destruction et qui peut être stéréotypé
par <<destroy>>, soit après le dernier message
envoyé par un objet qui se détruit.
avec délai de
transmission
Message avec délais de transmission non
négligeables. Représenté par une flèche oblique
250
Concepts
Messages
nomObjet
<<create>>
nomObjet
<<destroy>>
X
nomObjet
X

251
Concepts
Messages
Étiquette de message
Les étiquettes décrivent les messages auxquels elles
sont attachées.
Syntaxe générale
[garde] numero itération: attributRetourné:=msg(arguments):valeurDeRetour
Facultatif
Condition booléenne autorisant
ou non l’envoi d’un message.
Facultatif
Numéro de séquence
du message.
Facultatif
Marque la répétitivité d’envois de message.
*[ clause d’itération ]:envoi séquentiel de n instances du même message
*||[ clause d’itération ]:envoi parallèle de n instances du même message.
Facultatif
Liste de valeurs
retournées par le
message.
Obligatoire
Nom de l’opération ou
du signal invoqué par
l’intermédiaire de ce
message.
Facultatif
Liste des paramètres
du message, séparés
par des virgules
Facultatif
Valeur de retour au moment de la mise en
place du message

252
Concepts
Exemples

253
Concepts
Exemples

254
Concepts
Exemples

255
Concepts
Exemples

256
Fragment d’interaction combiné
Définition et représentation
Un fragment d’interaction combiné est une partie d’un
diagramme de séquence nommée, c’est-à-dire associée à
une étiquette.
L’étiquette contient un opérateur d’interaction qui permet de
décrire les modalités d’exécution des messages à
l’intérieur du fragment. Les opérandes sont des portions de
fragment.

257
Les principales modalités sont les boucles, les
branchements conditionnels, les alternatives, les
envois simultanés, etc. En fait UML définit 13 opérateurs :
alt, opt, loop, par, strict/weak, break, ignore/consider,
critical, negative, assertion et ref.
Un fragment est représenté par un cadre dont le coin
supérieur gauche contient un pentagone dans lequel
figure l’opérateur d’interaction suivi éventuellement du
nom du fragment

258
Les fragments d’interaction permettent de représenter
les diagrammes de séquences de manière compacte.
opérateur

259
Fragment d’interaction avec opérateur option
L’opérateur option noté opt comporte un opérande
qui est le fragment et une condition de garde associée,
placée entre crochets([]).
Le fragment s’exécute si la condition de garde est vraie et
ne s’exécute pas dans le cas contraire.
Représentation:
opt

260
Fragment d’interaction avec opérateur alternative
L’opérateur alternative noté alt est un opérateur
conditionnel possédant plusieurs opérandes (qui sont
des portions du fragment) séparés par des pointillés.
Chaque opérande détient une condition de garde.
Seul l’opérande dont la condition est vraie est exécuté. La
condition else est vraie si aucune autre condition n’est
vraie.
alt est l’équivalent d’une exécution d’une structure de choix
multiples

261
Représentation:
[condition n]
[else]
alt
[condition 1]

262
Exemple:

263
Fragment d’interaction avec opérateur boucle
L’opérateur boucle noté loop permet d’exécuter la
séquence d’interaction du fragment tant la garde qui lui est
associée est vraie.
La garde s’écrit sous la forme suivante:
loop [min, max, condition]
Le contenu du fragment est exécuté min fois, puis continue à
s’exécuter tant que la condition est vraie et que le nombre
d’exécution de la boucle ne dépasse pas max fois.
Chaque paramètre min, max et condition est optionnel.

264
Par exemple:
loop[3]→La séquence s’exécute 3 fois.
loop[1,3,code=faux] → La séquence s’exécute 1 fois puis un
maximun de 2 autres fois si code=faux.
Représentation:
loop [min, max, condition]

265
Exemple:

266
Fragment d’interaction avec opérateur référence
L’opérateur référence noté ref permet d’appeler une
séquence d’interactions nommée décrite ailleurs
Représentation:
ref

267
Fragment d’interaction avec opérateur référence
Exemple:

268
Un diagramme de séquence se représente
globalement dans un grand cadre avec indication du nom
du diagramme précédé de l’étiquette sd en haut à gauche
sd nom diagramme

269
Utilisation des diagrammes de séquences
Les diagrammes de séquences peuvent être utilisés à
différents niveaux de détail et pour servir différents buts à
plusieurs étapes du cycle de vie du développement.
Diagramme de séquence système (DSS)
DSS permet de décrire le comportement du système vu de
l’extérieur (par les acteurs) sans préjuger de comment il
sera réalisé.
DSS permet en effet de décrire les interactions entre le
système vu comme une « boîte noire » et son
environnement représenté par les acteurs
DSS est de ce fait une alternative visuelle des descriptions
textuelles des cas d’utilisation.

270
Exemple:

271
Exemple:

272
Diagramme de séquences de fonctionnement(DSF)
DSF permet d’écrire les interactions internes du système :
les interactions entre les objets.
DSF voit les réalisations de cas d’utilisation comme des
interactions dans une société d’objets.
Exemple:

273
Exemple:

274
DSF permet de faire apparaître les trois types d’objets de
Jacobson
Exemple: Gestion d'une bibliothèques : La saisie d'un nouveau livre

275
Exemple: Gestion d'une bibliothèques : La saisie d'un nouveau livre

276
Exemple: Gestion d'une bibliothèques : Affichage de l’auteur d'un livre

277
Exemple: Gestion d'une bibliothèques : Affichage de l’auteur d'un livre

278
DSF peut être à contrôle décentralisé (en escalier):

279
DSF peut être à contrôle décentralisé (ou en escalier)
Exemple: Cas d’utilisation « Obtenir les détails des
commandes d’une librairie »

280

281

282
DSF peut être à contrôle centralisé (ou en fourche):

283
DSF peut être à contrôle centralisé (ou en fourche):
Exemple: Cas d’utilisation « Obtenir les détails des
commandes d’une librairie »

284

285
Objectifs
Le diagramme de communication se concentre sur
l’organisation structurelle (spatiale) dans laquelle les objets
d’une interaction s’envoient et reçoivent des messages.
Il permet de représenter:
Les diverses entités, appelées rôles, mises en jeu dans la
réalisation d’une fonctionnalité;
Les échanges (messages) entre les entités dans le
cadre de cette fonctionnalité;
Les liens entre ces entités pendant l’échange des
messages.

286
Concepts
Rôle
 Définition
Un rôle est un participant à un échange de message dans
une interaction.
 Représentation
Un rôle est représenté comme dans le diagramme d’objets,
par un rectangle dans lequel figure le nom de l’objet
lorsque le participant est un objet.

287
Concepts
Message
 Définition
Cf Diagramme de séquence
 Représentation
Un message est représenté par une flèche.
La forme de la flèche dépend du type de messages;
on a les mêmes messages que dans les diagrammes de
séquences

288
Concepts
Message
 Etiquette
[’[’garde’]’] [seq][itération] [résultat :=]msg[’(’arguments’)’]
seq est le numéro de séquence du message. On numérote
les messages par envoi et sous-envoi désignés par des
chiffres séparés par des points
Lien d’interaction
connexion physique ou conceptuelle entre deux rôles
servant de chemin de communication sur lequel passent
les messages.
Représenté par un trait plein entre les rôles.

Diagramme d’états-transitions
289
Objectifs
Alors que les diagrammes d'interaction modélisent les
interactions entre les objets du système, le diagramme
d'états-transitions modélise les effets de ces interactions
sur la configuration interne des objets.
Le diagramme d’états décrit les différents états par
lesquels passe une instance quelconque d’une classe en
réponse aux interactions avec d'autres objets et son
comportement pendant ces moments.
Le diagramme d'états est donc utilisé pour modéliser le
cycle de vie des objets d'une classe.

290
Concepts
Le diagramme d’états présente les états significatifs
d’un objet pour le problème posé.
Il montre les transitions autorisées entre les différents états
de l’objet.
Il donne des précisions sur les événements déclencheurs
des transitions.
Il indique les traitements effectués par l’objet lorsqu’une
transition est effectuée ou lorsqu’il est dans un état donné.

291
Concepts
Etat
L’état d’un objet représente une situation durable de sa vie
pendant laquelle:
il satisfait certaines conditions,
il exécute une activité,
il attend des évènements.
L'état d'un objet est défini à la fois par les valeurs de
ses attributs et par les valeurs de ses associations
avec d'autres objets.

292
Concepts
Etat
L'état d'un objet a une durée finie, quantifiable à l'échelle
du système, correspondant au temps qui sépare deux
événements.
Un objet possède autant d’états que de configurations
possibles pour ses valeurs d’attributs.
Mais parmi la multitude d’états que peut posséder un
objet, seuls certains d’entre eux sont significatifs,
dignes d’intérêt.
On distingue trois types d’états

293
Concepts
Etat
État initial
L'état initial d'un objet correspond à l'état dans lequel
il est crée.
Un diagramme d'états a toujours un et un seul état initial
L'action de création est généralement associée à cet état.
État final
L'état final d'un objet correspond à l'état à partir duquel il
ne peut plus changer d'état.
Il est possible d'avoir zéro ou plusieurs états finaux qui
correspondent chacun à une condition de fin différente.
Les événements conduisant à ce type d'état sont
généralement associés à une action de destruction ou
d'archivage.

294
Concepts
Etat
État intermédiaire
Etape de la vie de l'objet
L’état est représenté par un rectangle aux coins
arrondis contenant le nom de l'état et éventuellement
les actions effectuées par
l’objet pendant qu’il est dans
l’état

295
Concepts
Etat
État intermédiaire
Exemple:
Etats d’une instance de personne
Etats d’une commande
commande en enregistrement
entry: contrôle client
do: contrôle article
Urgence / priorité
exit: décision
commande valide
entry: mise en attente
exit/^: bon de préparation
commande invalide

296
Concepts
Evènement
Définition
Fait ayant lieu à un moment donné.
Fait instantané venant de l'extérieur du système et
survenant à un instant donné
Représentation d’un moment précis dans le temps
Cela peut être:
Une modification intervenue dans l’environnement
Exemple: Réservation annulée, Commande annulée
Vérification de conditions d’erreur
Exemple: nombre d’emprunts > 5
Un événement peut porter des paramètres qui
matérialisent le flot d’informations entre objets.

297
Concepts
Evènement
Définition
On distingue plusieurs types d’évènements
Evènement appel (call)
Un événement d'appel représente la réception de l'appel
d'une opération par un objet.
Exemple: événements de création ou de destruction
d’objets
Un évènement appel est noté:
<nom_événement> ( [ <paramètre> : <type> [; <paramètre> : <type> ... ] ] )

298
Concepts
Evènement
Evènement signal(signal)
Un signal est destiné explicitement à véhiculer une
communication asynchrone à sens unique entre deux
objets.
L'objet expéditeur crée et initialise explicitement une
instance de signal et l'envoie à un objet explicite ou à tout
un groupe d'objets.
Il n'attend pas que le destinataire traite le signal pour
poursuivre son déroulement.
Un évènement signal est un évènement causé par l’envoi
ou la réception d’un signal.
Un évènement signal est noté:
<nom_événement> ( [ <paramètre> : <type> [; <paramètre> : <type> ... ] ] )

299
Concepts
Evènement
Évènement de changement
Évènement engendré par la satisfaction d’une
expression booléenne suite à un changement de
valeurs d’un ou plusieurs attributs ou à une modification de
liens.
Le passage de l’expression de faux à vrai entraîne le
déclenchement de l’événement de changement.
Un évènement de changement est noté: when(condition)

300
Concepts
Evènement
Évènement temporel
Évènement engendré par l’occurrence d’un temps
absolu ou l’écoulement d’une durée.
Un évènement temporel est noté:
after(temps) ou when(condition)
Évènements internes à un état
Événement à l'entrée : Entry
Événement à la sortie : Exit
Événements sans changement d'état

301
Concepts
Evènement
Évènements internes à un état
Effet des événements internes : Interruption de l'activité
avec sauvegarde du contexte
Evènements internes

302
Concepts
Evènement
Évènements externes à un état
Evènement de transition vers l'état : evt-in
Evènement de transition depuis l'état : evt-out
Evènement de transition depuis l'état vers lui-même: evt-self
Effet de evt-self : Réinitialisation de l'état, interruption de
l'activité sans sauvegarde du contexte.

303
Concepts
Transition
Définition
Une transition est le changement d'état d'un objet,
causé par un événement.
L’état source d’une transition est l’état dans lequel se
trouve l’objet avant l’apparition de l’événement.
L’état cible d’une transition est l’état dans lequel se
retrouve l’objet après la survenue de l’événement.
Notation
Une transition est modélisée sous la forme d’une flèche
reliant les deux états, étiquetée par une description
textuelle de la transition

304
Concepts
Transition
Notation
La description textuelle est constituée de trois éléments :
Un événement déclencheur
Une condition de garde
Une action

305
Concepts
Transition
Condition de franchissement
Expression booléenne optionnelle qui doit être
vérifiée pour que la transition puisse être déclenchée
lors de la survenue de l’événement déclencheur de la
transition.
Elle est notée entre crochet[ ].
On distingue plusieurs types de transitions

306
Concepts
Transition
Transition externe
Transition standard qui engendre un changement
d’état et toutes les actions correspondantes (actions
d’entrée et de sortie, ainsi que celles de la transition)
Transition automatique ou d’achèvement ou de
complétion
Une transition automatique se déclenche lorsque l’activité
de son état source est terminée.

307
Concepts
Transition
Transition interne
Transition qui n’engendre pas de changement d’état
et ne déclenche que les actions associées à cette
transition.
Transition réflexive
Une transition réflexive possède le même état d’origine et
de destination.

308
Concepts
Transition
Différents types de transitions en résumé
Transitions externes
Transition externe
Transition réflexive
Transitions internes

309
Concepts
Exemples de diagrammes
Etats d’une personne

310
Concepts
Exemples de diagrammes
Etats d’une commande

311
Concepts
Transitions composites
But : Regrouper ou diviser des transitions mutuellement
exclusives
Utilisation de deux pseudo-états particuliers.
Point de jonction
Evaluation des gardes avant le franchissement de
la transition
Dans l ’état A, la transition X
n’est activée que si l’une des
branches a>100, a<0, a=50 est
activable.

312
Concepts
Point de jonction
Exemple: Ces deux représentations sont équivalentes
Bien adapté pour représenter des chemins optionnels

313
Concepts
Point de décision
Evaluation des gardes lorsque le point de décision est
atteint.
Dans l ’état A, si la transition X
est activée, ce n ’est qu’au
niveau du point de choix que
l ’on regarde si une des
transitions est activable.

314
Concepts
Point de décision
Exemple:

315
Concepts
Actions et activités
Une action est une opération instantanée et atomique,
donc ininterruptible. Une action est associée à un
événement. Elle a accès aux paramètres de l’événement et
aux attributs de l’objet.
Une activité est séquence interruptible d’actions qui
nécessite un certain temps d’exécution. Une activité est
non atomique. Elle peut être interrompue à tout moment
par un événement.

316
Concepts
Action d’une transition
Une action sur une transition est une action exécutée
lorsque la transition est déclenchée et la condition de
franchissement (quand elle existe) est vraie.
Action à exécuter au cours de la transition; syntaxe laissée libre

317
Concepts
Actions d’un état
Une action d’état est une action interne associée à un
état et dont les conditions de déclenchement sont liées soit
à la survenue d’un événement, soit à l’entrée ou à la sortie
de l’état.
Un état peut comporter :
Une action en entrée
A chaque fois que l’objet entre dans l’état, c’est-à-dire à la
survenue de l’évènement Entry, l’action est exécutée.

318
Concepts
Actions d’un état
Un état peut comporter :
Une action en sortie
A chaque fois que l’objet sort de l’état, c’est-à-dire à la
survenance de l’évènement Exit, l’action est exécutée.
Plusieurs actions internes sur événement sans
changement d’état
A chaque fois qu’un événement sans changement
d’état survient, une transition interne est déclenchée
et l’action associée est exécutée.

319
Concepts
Activité d’un état
Une activité d’état est une activité associée à un état et
s’exécutant tant que l’objet se trouve dans cet état ou
jusqu’à ce que le traitement associé soit terminé.
L’activité se déclenche une fois que l’objet se retrouve dans
l’état associé à celle-ci.
Si l’état possède une action en entrée, celle-ci sera
déclenchée avant que ne démarre l’activité.
La survenue d’un événement sur action interne interrompt
l’activité le temps du traitement de l’action interne.

320
Concepts
Activité d’un état
L’activité d’un état est précédée du mot-clé « Do »

321
Concepts
Ordre d’exécution des actions et des activités

322
Concepts
Ordre d’exécution des actions et des activités

323
Etats particuliers
Etat composite ou composé
Définition
État regroupant un ensemble d'états
Les états qui le composent un
état composite sont appelés
sous-états.
Notation abrégée
Pour indiquer qu’un état est
composite et que sa définition est
donnée sur un autre diagramme:

324
Etats particuliers
Objectifs
Structurer les comportements complexes
Assemblage d'états
Décomposition en sous-diagrammes
Généralisation d'états
Regroupement des états au comportement commun, dans
un super-état
Possibilité d'y associer une généralisation d'événements.

325
Etats particuliers
Sous-états séquentiels ou disjoints
Des sous-états d’un état composé d’un objet sont
séquentiels, si à un instant donné, l’objet ne peut se
trouver que dans un seul de ces sous-états
La transition de sortie d’un état composite s’applique à tous
ses sous états
La transition d’entrée d’un état composite ne concerne
qu’un seul sous-état.

326
Etats particuliers
Sous-états séquentiels ou disjoints
séquentiels, si à un instant donné, l’objet ne peut se
trouver que dans un seul de ces sous-états
La transition de sortie d’un état composite s’applique à tous
ses sous états
La transition d’entrée d’un état composite ne concerne
qu’un seul sous-état.

327
Etats particuliers
Sous-états concurrents
concurrents, si l’objet se trouve simultanément dans tous
ces sous-états.

328
Etats particuliers
Les différents sous-états concurrents sont appelés régions.
Les régions sont séparées entre elles par des lignes
pointillées.
Chaque région peut posséder un état initial et plusieurs
états finaux.
Le déclenchement d’une transition vers l’état composite
entraîne l’activation de tous les états initiaux des
différentes régions.

329
Etats particuliers
La terminaison des activités de l’état composite intervient
lorsque tous les états finaux de toutes les régions sont
atteints ou qu’une transition sortant de l’état englobant est
déclenchée.
Exemple:

330
Etats particuliers
Transitions concurrentes ou simultanées
Les états A et C sont atteints
simultanément ;
Les états B et D sont quittés
simultanément.
on ne peut quitter D pour E
que si dans le même temps,
on quitte A.

331
Etats particuliers
Etats historiques
Il est possible, lorsque un objet quitte un état composé, de
mémoriser le sous-état actif pour y revenir. Pour cela, on
utilise un pseudo état de mémoire qui représente dans l’état
composé le dernier sous-état actif mémorisé.
On représente le pseudo état historique par un H cerclé.
Une transition ayant pour cible l’état historique est
équivalente à une transition ayant pour cible le dernier état
visité dans la région contenant le H.
H* (historique profond) est un état valable pour tous les
niveaux d’imbrication.

332
Etats particuliers
Etats historiques

333
Objectifs
Les diagrammes d'activité offrent une manière
graphique et non ambiguë pour modéliser les traitements.
Un diagramme d’activités est un graphe orienté qui décrit
un enchaînement d’actions ou d’activités qui peut être
soumis à des branchements ou à des synchronisations et
qui réalise un traitement donné.
Il s’intéresse aux étapes d’une tâche complexe à accomplir.
Le diagramme d‘activités permet de modéliser le
comportement d’un système sous formes d’actions ainsi
que l’ordre dans lequel elles doivent être exécutées.

334
Objectifs
Le diagramme d'activités peut être utilisé à trois niveaux :
Processus métier
Description des règles de séquencement des activités qui
doivent être appliquées pour un processus.
Modélisation du fonctionnement de l’organisation.
Cas d’utilisation
Description d’une famille de scénarios.
Description des enchaînements d’écrans dans une IHM.
Logique complexe
d'une opération d'une classe, d'une collaboration:
Description des délégations entre objets dans un système
logiciel.

335
Concepts de base
Le diagramme d'activités comprend des activités et des
transitions
Activité
Une activité permet de réaliser un but précis (modification
de l’état du système, retour de valeur…)
Une activité décrit un comportement défini par une suite
d’actions.
Une activité est représentée globalement par un rectangle
avec les bords arrondis.
Traiter facture

336
Concepts de base
Activité
Une activité peut être représentée par plusieurs nœuds
d’activité (nœuds d’action, nœuds de contrôle et nœuds
d’objets) reliés par des flèches (transitions).
Transition
Dès qu’une activité est achevée une transition automatique
est déclenchée vers l’activité suivante.
Il n’y a donc pas d’événement associé à la transition.
Une transition est modélisée sous la forme d’une flèche
reliant les deux actions ou activités:
Action source Action cible

337
Concepts de base
Nœud d’action
Un nœud d’action présente une action dans une activité.
Une action est le plus petit traitement qui puisse être
exprimé en UML.
Une action a une incidence sur l’état du système ou bien
en extrait une information.
Une action peut être appréhendée soit à un niveau
élémentaire proche d’une instruction en terme de
programmation soit à un niveau plus global
correspondant à une ou plusieurs opérations.
Une action peut être affecter une valeur à un attribut, créer
ou détruire un objet, effectuer une opération, …

338
Concepts de base
Nœud d’action
Une action représente une étape simple de l’activité.
Une action quelconque est représentée sous forme
de rectangle aux angles arrondis contenant le nom
ou une brève description de l’action.

339
Concepts de base
Nœuds de contrôle
Un nœud de contrôle est un nœud utilisé pour coordonner
les flots (ou flux) entre les nœuds d'une activité.
Il existe plusieurs types de nœuds de contrôle

340
Concepts de base
Nœud initial
Le nœud initial constitue le point de départ d’une activité
Une activité peut posséder plusieurs nœuds initiaux.
Nœud final d’activité
Un nœud final d’activité permet de mettre fin à toute
l’activité.
Une activité peut posséder plusieurs nœuds finaux.
Nœud final de flux(ou flot)
Un nœud final de flux permet de mettre fin à un chemin
partiel d’exécution dans une activité.

341
Concepts de base
Nœud de décision
Un nœud de décision représente un choix entre plusieurs
flux:
Un flot d’entrée pour plusieurs flots de sortie;
On ne peut choisir qu’un flot de sortie.
Les gardes ( [ condition ] ) indiquent les conditions pour
emprunter un flot:
Les gardes doivent être mutuellement exclusives;
[else] indique le flot à choisir si les autres gardes sont
fausses.

342
Concepts de base
Nœud de fusion
Un nœud de fusion ou de confluence est un nœud qui
rassemble plusieurs flots alternatifs entrants en un seul flot
sortant.
Il met fin à un comportement conditionnel initié par une
décision.
On a plusieurs flots entrants et un seul flot sortant; il suffit
qu’un seul flot soit prêt pour continuer.

343
Concepts de base
Nœud de bifurcation ou de débranchement
Un nœud de bifurcation permet de scinder le flux courant,
au sein d’une activité, en plusieurs flux concurrentiels
(parallèles).
Un nœud de bifurcation possède donc un flot entrant et
plusieurs flots sortants.

344
Concepts de base
Nœud d’union
Un nœud d'union ou de jointure ou de synchronisation ou
de jonction permet de synchroniser plusieurs flots d’une
activité et de les réunir au sein d’un même flot.
Un nœud d’union possède donc plusieurs flots entrants et
un seul flot sortant.
Le flot sortant est activé seulement quand tous les flots
entrants sont activités.

345
Concepts de base
Nœuds d’objet
Les activités s ’opèrent sur des objets ou par des objets.
Un nœud d'objet représente un objet généré par une action
dans une activité et utilisé par d'autres actions.
Un nœud d’objet permet de représenter le flot de données
véhiculé entre les actions
Le même objet peut manipulé par plusieurs activités.
Dans ce cas il apparaît plusieurs fois et chaque apparition
dénotant un point différent de sa vie.
Un nœud d’objet est représenté par:

346
Concepts de base
Nœuds d’objet
Exemple

347
Activités composées
Une activité peut être composée d'autres activités; dans ce
cas, un diagramme d'activités spécifique en décrit la
composition en sous-activités.
Dans les diagrammes où elle est présente une activité
composée est représentée avec un symbole de rateau.

Réception
commande
Exécution
commande Envoi facture
Traitement
paiement
Livrer
Clore
l'ordre
Le râteau signifie que
l’activité est
décomposable en sous
activités

Livrer
Livraison
normale
Livraison
urgente
Livraison
normale
Livraison
urgente
Exécution
commande
Clore
l'ordre

350
Couloirs d’activité
Les couloirs d’activités appelés aussi partitions, travées,
ou lignes d’eau(swimlanes) permettent de représenter les
différentes responsabilités au sein d’un diagramme
d’activités.
Chaque responsabilité (couloir) est assurée par un ou
plusieurs objets.
Chaque action ou activité est allouée à une travée
donnée.
Le partitionnement peut se faire en fonction:
Des endroits géographiques (ou des services) où les
activités se déroulent. Par exemple: Service client, service
comptabilité, service facturation, …

351
Le partitionnement peut se faire en fonction:
Des personnes responsables des activités(qui exécutent
les actions). Par exemple: Le client, le caissier, le gérant,..
Des entités logiques du système. Par exemple: Réseau,
Base de données, Système de paiement, …
D’un mixte des trois. Par exemple: Le client, le caissier, le
système de paiement, le service de facturation, …
Exemple:

352
Exemple:

353
Communication
Le diagramme d’activités permet une représentation
graphique d’actions associées à une communication:
Envoi de signal
Réception d’évènement
Attente temporelle
Cela permet de mieux mettre en valeur les échanges dans
les diagrammes d’activité.

354
Communication
Exemple:

355
Région d’activité interruptible
Une région d'activité interruptible entoure un groupe
d'actions, qui peuvent être interrompues quand une
situation anormale se produit(évènement).
Une région interruptible est représentée par un cadre
arrondi en pointillés
L’évènement d’interruption apparaît comme une flèche
«éclair » partant de l’intérieur de la région interruptible
et se dirigeant vers la bordure du gestionnaire
d’interruption.

356
Région d’activité interruptible
Exemple: Construire le diagramme d'activités d'une
commande d'un client.
L'activité débute à la réception d'une
commande.
Toute la suite de l'activité est
interruptible quand une situation
anormal se produit.
Le client est libre d'annuler sa
commande à tout moment.
Un fois que le la commande est
envoyé il devient impossible de
l'annuler: la transaction est
enregistrée et le dossier clôture.

357
Lien entre diagramme d’activités et diagramme d’états
Le diagramme d’activités permet une représentation
Diagramme d’états

358
Elaboration du diagramme d’activités
 Ajouter les transitions entre les activités /actions
S’agit-il d’un cas d’utilisation? Un processus métier
englobant plusieurs cas d’utilisation? Une méthode d’une
classe?
Ajouter au diagramme une note avec le nom et une
description du processus
 Ajouter les nœuds initiaux et finaux
Ajouter les nouds initiaux et finaux, afin que le lecteur
sache où l’activité commence et se termine.
 Ajouter les activités/actions
Ajouter une activité pour chaque étape majeur du
processus.
Ajouter les actions pour chaque activité et les actions
individuelles du processus.

359
Elaboration du diagramme d’activités
 Identifier le processus à représenter
Relier les activités / actions
 Ajouter les branchements
Indiquer les décisions à prendre (décision / fusion).
Indiquer si deux activités peuvent être réalisées en
parallèle (bifurcation /jointure).
 Ajouter les flots d’objets
Insérer les objets importants dans les diagrammes.
Montrer les changements de valeur et d’état utiles à la
compréhension du diagramme.
 Ajouter les partitions
Identifier des partitions et répartir les actions identifiées
dans ces partitions.

360
Exercices
 Exercice 1: organisation d’un examen
Le service scolarité :
planifie l’examen,
prépare les copies,
puis, une fois l’examen corrigé, saisit et affiche les notes,
et archive les copies
L’enseignant prépare un sujet et corrige les copies
Les étudiants rédigent une solution et prennent
connaissance de leur note après affichage.
Rédiger un diagramme d’activités (en remettant les choses
dans l’ordre).

361
Exercices
 Exercice 2: Atelier
Le logiciel de gestion des réparations est destiné en priorité au Chef
d'atelier, il devra lui permettre de saisir les fiches de réparations et le
travail effectué par les divers employés de l'atelier. Pour effectuer
leur travail, les mécaniciens et autres employés de l'atelier vont
chercher des pièces de rechange au magasin. Lorsque le logiciel
sera installé, les magasiniers ne fourniront des pièces que pour les
véhicules pour lesquels une fiche de réparation est ouverte; ils
saisiront directement les pièces fournies depuis un terminal installé
au magasin. Lorsqu'une réparation est terminée, le Chef d'atelier va
essayer la voiture. Si tout est en ordre, il met la voiture sur le parc
clientèle et bouclera la fiche de réparation informatisée. Les fiches
de réparations bouclées par le Chef d'atelier devront pouvoir être
importées par le comptable dans le logiciel comptable.
Créer un diagramme d’activité pour tout le traitement d’une
réparation

362
Exercices
 Exercice 3: Fiche de réparation
Pour créer une fiche de réparation, le chef d’atelier saisit les critères de
recherche de voitures dans le système.
Le logiciel de gestion des réparations lui donne la liste des voitures
correspondant aux critères entrés.
Si la voiture existe dans la liste, le chef d’atelier va sélectionner la voiture.
Le logiciel va, ensuite, fournir les informations sur le véhicule.
Si la voiture est sous garantie, le chef saisit la date de demande de
réparation.
Si la voiture n’existe pas, le chef saisit les informations concernant ce
nouveau véhicule.
Dans tous les cas, le chef d’atelier entre la date de réception et de restitution.
Si le dommage de la voiture est payé par l’assurance, le logiciel fournit une
liste d’assurances au chef d’atelier.
Ce dernier sélectionne l’assurance adéquate.
Enfin, le logiciel enregistre la fiche de réparation.
Rédiger un diagramme d’activités pour le cas d’utilisation « créer (ouvrir) une
fiche de réparation »

363
Exercices
 Exercice 4: Commander un produit
Construire un diagramme d’activité pour modéliser le
processus de commande d’un produit.
 Le processus concerne les acteurs suivants:
Client: qui commande un produit et qui paie la facture
Caisse: qui encaisse l’argent du client
Vente: qui s’occupe de traiter et de facturer la commande
du client
Entrepôt: qui est responsable de sortir les articles et
d’expédier la commande.

364
Exercices
 Exercice 5: Inscription
Pour s’inscrire dans une formation, le candidat doit :
Remplir les formulaires
Les formulaires sont vérifiés. S’ils sont incorrects, le
candidat demande de l’aide avant de remplir à nouveau
les formulaires
Si les formulaires sont corrects, l’inscription est soumise
Si l’inscription est acceptée, le candidat pourra, d’une
part, payer les taxes (droits d’inscription, etc.), et d’autre
part, comparaître à la journée d’accueil.

365
Exercices
 Exercice 6: Commande fournisseur
Une commande Fournisseur est rédigée puis envoyée
A la réception de l’accusé de réception, la commande est
validée.
Si 2 semaines après l’envoi de la commande, l’accusé de
réception du fournisseur n’est toujours pas parvenu, la
commande est annulée.
Créer un diagramme d’activité pour le traitement d’une
commande fournisseur

Présentation cours UML.pptx

Contenu connexe

Tendances

Similaire à Présentation cours UML.pptx

Dernier

Présentation cours UML.pptx

Notes de l'éditeur