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

Présentation cours UML.pptx

Présentation cours UML.pptx

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Présentation cours UML.pptx

Similaire à Présentation cours UML.pptx (20)

Dernier

Dernier (20)

Présentation cours UML.pptx

Notes de l'éditeur