UML

Modélisation conceptuelle des données

Approche orientée objet

Logo d'UML

1
 Plan
Introduction UML
Diagramme de classes
Diagramme des cas d’utilisation.
Diagramme de séquence

22
 Cycle de vie d’un logiciel

3 UML: Langage de Conception orientée objets (COO)

Analyse

Conception

Développement &
Implémentation

Tests

Maintenance

3
I- Qu'est-ce que UML ?
UML(Unified Modeling Language) : langage de modélisation unifié

Langage = syntaxe + sémantique :

• syntaxe : notations graphiques consistant essentiellement
en des représentations conceptuelles d'un système
• sémantique : sens précis pour chaque notation

Définition: UML est un langage graphique visuel qui

permet de représenter, de communiquer les divers
aspects d’un système (d’information).
Logo d'UML

4
I- Qu'est-ce que UML ?

 UML est un support méthodologique au concepteurs et développeurs

 pour l’analyse et la conception technique de leur systèmes.

 UML est un support de communication performant,

 facilite la représentation et la compréhension de solutions objet.

 UML (dernière version 2.5.1 (2017)) possède 14 diagrammes qui sont

des vues partielles du modèle à décrire.

5
 Modélisation objet

Un modèle est une représentation abstraite de la réalité

qui exclut certains détails du monde réel.
o Il permet de réduire la complexité d'un phénomène en éliminant les
détails qui n'influencent pas son comportement de manière
significative.
o Il reflète ce que le concepteur croit important pour la compréhension et
la prédiction du phénomène modélisé,
o les limites du phénomène modélisé dépendent des objectifs
du modèle.

6
 Modélisation objet

 Modéliser un système avant sa réalisation permet de mieux

comprendre le fonctionnement du système.

 C'est un bon moyen de maîtriser sa complexité et d'assurer sa

cohérence.
 Un modèle est un langage commun, précis, qui est connu par tous les
membres de l'équipe .

 C’est un un vecteur privilégié pour communiquer.

7
 Conception: Problématique
8

8
UML est caractérisé par :

• utilise l’approche orientée objet

• normalisé, riche
• Formel : sa notation limite les ambiguïté et les
incompréhensions
• langage ouvert
 INDÉPENDANT du langage de programmation
 Domaine d'application : permet de modéliser n'importe
quel système
• Supporté par plusieurs outils (AGL) : Objecteering, Open
tools, Rational Rose, PowerAMC, WinDesign, …

9
 UML : Domaines d’utilisation

UML avec ces 14 diagrammes permet de :

• Représenter le cahier des charges du projet

• Les classes et les manière dont elles s’organisent entre elles
• Accompagner un projet tout au long de sa vie
• Il y a un diagramme pour chaque phase du projet
• UML est puissant
• Peut modéliser même le fonctionnement des systèmes
complexe (moteur d’une voiture, institutions )
• Transport, finance, santé, Sécurité, Industrie…

10
14 diagrammes, à partir UML 2.2 :

11
 Diagrammes d’UML
Diagrammes d’UML utilisés pour représenter différents points de vues

Cas d’utilisation
Objets Composants

Classes Vue logique statique Vue Implémentation

(Structure des objets) (composants logiciels)

Vue externe
(fonctions système)
Séquence Vue déploiement
Vue logique dynamique
(Environnement
(Comportement)
d’implantation)
Collaboration

États Activités
Déploiement
transitions
UML
Diagramme de structure…

Diagrammes de classes

13
Concepts de l'approche par objets
Exemple classe compte

Compte
- N°Compte : String
- Solde : float
- Client : Personne
+ <<Constructor>> Compte ()
+ Deposer (float somme) : void
+ Retirer (float somme) : float
+ AvoirSolde () : String

14
Concepts de l'approche par objets: Les classes
Héritage: Généralisation et spécification

Hiérarchie de classes
Relation entre éléments
Associations

• Relation existant entre une, deux ou plusieurs classes.

• Une association porte un nom (signification)
• Représentée par une ligne rectiligne
• une association fonctionne (généralement) dans les 2 sens
(bidirectionnelle)

16
Relation entre éléments
Associations : rôle d’une association

• Décrit le rôle d’une classe dans une association

17
Relation entre éléments
Associations : rôle d’une association

Utile surtout dans deux cas :

• Lorsqu’on a plusieurs associations entre deux classes avec
des rôles différents
• une relation réflexive : relation entre deux instances d’une
même classe

Pilote Personne Personne

Avion 0..4
femme

Passager
0..1
mari

18
Relation entre éléments
Associations : Classe-Association

• Une association peut avoir des attributs = classe-association

• Les classes association sont utiles quand il y a des attributs qui sont
pertinents à l’association, mais à aucune des classes impliquées.

Personne Entreprise
1..*
0..1

Emploi
- Période : int
- Salaire : float

19
Relation entre éléments
Associations : degré d’une association

degré d’une association = nombre de classes participantes

 Association unaire : relie 2 instances d'une classe
 association binaire : relie 2 classes
 association ternaire : relie 3 classes
 association n-aire : relie n classes

20
Relation entre éléments
Associations : Multiplicité

Multiplicité = nombre de participations d’une classe dans une

association
 indiquée à chaque extrémité d’une association
 sous la forme min..max
 min, max = 0, 1, *

 Exemple général

 Exemple concret

21
Relation entre éléments
Associations : Multiplicité
 Exemple ternaire

 Pour un couple d’instances de la classe A et de la classe B,

il y a au min. r1 instances de la classe C et au max. r2 instances,
…
…

22
Relation entre éléments
Associations : Multiplicité

Notation abrégée des multiplicités :

1  1..1 (exactement 1)
*  0..* (0 ou plusieurs)
n  n .. n (exactement n)
1..*  1 ou plusieurs (1 ou plus)
0..1  0 ou 1 (au plus un)
1..100  entre 1 et 100
2,4,5  2, 4 ou 5

23
UML: Diagramme de classe

Exemple 1: de diagramme de classe

24
Etapes pour établir un diagramme
A partir d’une description du système :

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 (S’assurer que le schéma répond à la
demande)
6. Itérer jusqu’à satisfaction …

25
UML
Diagrammes de comportement

Diagrammes de cas d’utilisation

26
Diagramme des cas d’utilisation

• Décrit, sous forme d’actions et de réactions, le

comportement d’un système du point de vue d’un
utilisateur.
• Permet de définir les limites du système et ses relations
avec l’environnement.
• Sert à modéliser les aspects dynamiques d'un système
(Contrairement aux diagrammes de classes).
• Fait ressortir les acteurs et les fonctions offertes par le
système.
• Utilisé pour modéliser les exigences (besoins) du client

27
Diagrammes des cas d'utilisation

Comportent plusieurs éléments :

• Acteurs
• Cas d'utilisation
• Relations de dépendances, de généralisations et
d'associations

28
Acteurs

• UML n’emploi pas le terme d’utilisateur mais d’acteur.

• Le terme acteur ne désigne pas seulement des
utilisateurs humains mais également les autres systèmes
(machines, programmes, …)
• Un acteur est un rôle joué par une entité externe qui agit
sur le système (Comptabilité, service commercial, …), en
échangeant de l’information (en entrée et en sortie)

29
Acteurs

Peut être représenté de deux manières différentes :

1. Petit personnage (stick man)

2. Classe stéréotypée

Nom Acteur

<<Acteur>>
Nom Acteur

30
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, …)

31
Acteurs (Exemple)

<<acteur>>
Secrétaire Site Web de l'établissement

Etudiant
Système de Gestion
Scolaire
<<acteur>>
Imprimante

32
Acteurs

Mais du point de vue 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.

33
Acteurs

Un acteur peut être une spécialisation

d'un autre acteur déjà défini.
Acteur général
Dans ce cas, on utilise la relation de
généralisation/spécialisation.

Acteur spécialisé

34
Cas d'utilisation

Les cas d’utilisations

• Permettent de modéliser les attentes (besoins) des
utilisateurs
• Représentent les fonctionnalités du système
• Suite d’événements, initiée par des acteurs, qui
correspond à une utilisation particulière du système
• L’image d’une fonctionnalité du système, déclenchée
en réponse à la stimulation d’un acteur externe.

35
Cas d'utilisation

Un cas d'utilisation est représenté par une ellipse en trait

plein, contenant son nom.

Nom Cas Utilisation

36
Structuration des cas d'utilisation

Après avoir identifié les acteurs et les cas d'utilisation, il est

utile de restructurer l'ensemble des cas d'utilisation que l'on
a fait apparaître afin de rechercher les :
• Comportements partagés
• Cas particuliers, exceptions, variantes
• Généralisations/spécialisations.

37
Structuration des cas d'utilisation

UML définit trois types de relations standardisées entre cas

d'utilisation :
1. Une relation d'inclusion, formalisée par la dépendance
«include»
2. Une relation d'extension, formalisée par la dépendance
«extend»
3. Une relation de généralisation/spécialisation

38
Relation d'inclusion

Lors de la description des cas d'utilisation, il apparaît qu'il

existe des sous-ensembles communs à plusieurs cas
d'utilisation, il convient donc de factoriser ces fonctionnalités
en créant de nouveaux cas d'utilisation qui sont utilisés par
les cas d'utilisation qui les avaient en commun.

39
Relation d'inclusion

A inclut B : le cas A inclut obligatoirement le comportement

définit par le cas B; permet de factoriser des fonctionnalités
partagées
Le cas d'utilisation pointé par la flèche (dans notre cas B) est
une sous partie de l'autre cas d'utilisation (A, dans notre
exemple).

<<include>>

40
Relation d'inclusion

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
Retirer de l'argent
cas d'utilisation "S'authentifier", à un
endroit spécifié dans leurs
enchaînements.
<<include>>
Déposer de l'argent

<<include>>

S'authentifier

<<include>>

Effectuer des virements

<<include>>

Consulter solde

41
Relation d'extension

La relation stéréotypée «extend» permet d'étendre les

interactions et donc les fonctions décrites dans les cas
d'utilisation, mais sous certaines contraintes.

42
Relation d'extension

Le CU source (B) ajoute, sous certaines conditions, son

comportement au CU destination (A)
En d’autres termes, le CU B peut être appelé au cours
de l’exécution du CU A
A
B Point d'insertion
<<extend>>

Le comportement ajouté s’insère au niveau d’un point

d’extension définit dans le CU destination

43
Relation d'extension

Le cas d'utilisation de destination peut fonctionner tout seul,

mais il peut également être complété par un autre cas
d'utilisation, sous certaines conditions.
On utilise principalement cette relation pour séparer le
comportement optionnel (les variantes) du comportement
obligatoire.
Exemple : Au moment de l'authentification, il se peut que le
guichet retient la carte.

S'authentifier
Retenir la carte
<<extend>>

44
Relations d’inclusion VS d'extension

• La relation « extend" montre une possibilité d'exécution

d'interactions qui augmenteront les fonctionnalités du cas
étendu, mais de façon optionnelle, non obligatoire,
• La relation "include" suppose une obligation d'exécution
des interactions dans le cas de base.

45
Relation d'héritage

Il peut également exister une relation d'héritage entre cas

d'utilisation.
Cette relation exprime une relation de
spécialisation/généralisation au sens classique.

46
Relation d'héritage : Exemple

Dans un système d'agence de voyage, un acteur "Touriste"

peut participer à un cas d'utilisation de base qui est
"Réserver voyage", qui suppose par exemple, des
interactions basiques au comptoir de l'agence. Une
réservation peut être réalisée par téléphone ou par Internet.

47
Relation d'héritage : Exemple

On voit qu'il ne s'agit pas d'une relation "extend", car la

réservation par Internet n'étend pas les interactions ni les
fonctionnalités du cas d'utilisation "Réserver voyage".
Les deux cas d'utilisation "Réservation voyage" et "Réserver
voyage par Internet" sont liés : la réservation par Internet est
un cas particulier de réservation.
De façon générale en objet, une situation de cas particulier
se traduit par une relation de généralisation/spécialisation.

48
Relation d'héritage : Exemple

Reserver voyage

Réserver voyage par téléphone Réserver voyage par Internet

49
Structuration entre cas d’utilisation

Résumé
Les cas peuvent être structurées par des relations :
• A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de
factoriser des fonctionnalités partagées
• A étend B : le cas A est une extension optionnelle du
cas B à un certain point de son exécution.
• A généralise B : le cas B est un cas particulier du
cas A.

50
Relations entre cas d’utilisation : Exemple

Un client peut effectuer un retrait bancaire. Le retrait 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 500DH, la vérification
du solde de son compte est réalisée.

51
Relations entre cas d’utilisation

<<extend>> Vérification solde compte

Virement

Montant > 500 DH

<<include>>

Virement par Internet

Virement sur place

Identification

Client distant
Client local
52
UML
Diagramme d’interaction

Diagrammes de séquences

53
54
Diagramme de séquences

• Représente les interactions entre objets en précisant

la chronologie des échanges de messages
• Représente une instance d’un cas d’utilisation (les
scénarios possible d’un cas d’utilisation donné)
• Montre sous forme de scénarios, la chronologie des
envoies de messages issus d’un cas d’utilisation
• Le diagramme de séquence fait ressortir :
 Les acteurs
 Les objets
 Les messages

55
Diagramme de séquences

Obj et_1 Obj et_2 Obj et_3

Message_1

Message_2

Li gne de vi e de
l 'obj et

56
Diagramme de séquences

• Un objet est représenté par un rectangle et une ligne

verticale (ligne de vie de l’objet)
• Les objets communiquent en échangeant des messages
représentés par des flèches orientées de l’émetteur au
récepteur
• L’ordonnancement vertical des messages indique la
chronologie

57
Diagramme de séquences

• Un message reçu par un objet déclenche l’exécution

d’une opération
• Un message envoyé par objet correspond :
 Demander un service d’un autre objet
 Renvoyer le résultat d’un opération

58
Diagramme de séquences :
Exemple

Compte
- N°Compte : String
- Solde : float
+ <<Constructor>> Compte (int n, float s)
+ déposer (float somme) : void
+ retirer (float somme) : float
+ consulter () : float

Le client demande un service (retirer de l’argent) à l’objet Compte

Le compte reçoit le message et déclenche l’opération de même nom
Le compte retourne le résultat (le solde actuel)
59
Diagramme de séquences

Plusieurs concepts additionnels :

• Période d’activité
• Types de messages
• Création et destruction d’objets
• Structures de contrôles

60
Période d’activité

Correspond au temps pendant lequel un objet fait une action

Représentée par une bande rectangulaire superposée à la
ligne de vie de l’objet

Objet_2 Objet_1

Message_1

61
Messages: Types de message

• Traduisent les interactions (échange d’informations) entre

objets
• Représentés par des flèches orientées de l’émetteur au
récepteur
• Plusieurs types :
 Message simple
 Message minuté (Timeout)
 Message synchrone
 Message asynchrone
 Message récursif

62
Message simple

Message pour lequel on ne spécifie aucune information

d’envoi ou de réception

Objet_1 Objet_2

Message_1

63
Message minuté (Timeout)

Bloque l’expéditeur pendant un temps donné, en attendant

la prise en compte du message par le récepteur
Après le délai, l’expéditeur est libéré et peut envoyer

Obj et_2 Obj et_1

Message_1 (20 secondes)

64
Message minuté (Timeout) :
Exemple

La porte d’un ascenseur s’ouvre pendant un certain délai

avant d’être refermée.

Ascenseur Porte

ouvrir (2 secondes)

fermer

65
Message synchrone (appel de procédure)

Bloque l’expéditeur jusqu’à la prise en compte du message

par le récepteur
Le contrôle est passé de l’émetteur au récepteur qui devient
à son tour émetteur (actif)

Obj et_2 Obj et_1

Message_1

66
Message synchrone (appel de
procédure) : Exemple
Communication client serveur : Sockets

Client Serveur

Sollitation

Acceptation

Requête

Réponse

67
Message asynchrone

• N’interrompt pas l’exécution de l’expéditeur

• L’expéditeur peut émettre sans attendre la réponse du
récepteur
Obj et_2 Obj et_1

M essage_1

68
Message récursif

Appelé aussi message réflexive

Message envoyé d’un objet vers lui-même.

Objet_1

Message_1

69
Message récursif : Exemple

Lorsque le client introduit sa carte de guichet, ce dernier

vérifie la validité de la carte avant de demander le code
d’accès
Client GAB

Introduire carte

Vérification validité

Demande code accès

70
Les test (branchements) :
Exemple

Pour accéder au centre de recherche, l’utilisateur doit

présenter son badge. S’il a droit d’accès, un voyant vert est
allumé et la porte s’ouvre
Utilisteur Système

Présente son badge

Vérifier droit d'accès

[OK]voyant vert

ouvrir porte

71
Description des cas d’utilisation (description par
diagramme de séquence)

Système

Guichetier Système Central

Saisie du numéro de compte client
Demande de validité de compte

OK Vérfification

Demande type opération

Retrait(somme)
Compte suffisamment approviosionné

Débiter le compte
Compte débité
Autorisation de délivrer somme

72
Bibliographie

 P. Roques; UML 2 par la pratique : études de cas et exercices corrigés, 2009,

Éditeur : Eyrolles
 The Unified Modeling Language User Guide , G. Booch, J. Rumbaugh, I.
Jacobson, 1999, Addison Wesley
 UML La notation unifiée de modélisation objet, M. Lai, Masson
 L. DEBRAUWER, UML 2 Initiation, exemples et exercices corrigés, 2012, ENI
(3ième édition).
 http://laurent-audibert.developpez.com/Cours-UML/

73
Ressources sur UML

– Site officiel d'UML : http://www.uml.org/

– Site français sur UML (plus vieux) : http://uml.free.fr/
– Site d'IBM sur UML : http://www.ibm.com/software/rational/uml/
– Site officiel de l'OMG : http://www.omg.org/
– Sondage : http://www.volle.com/travaux/gtmodelisation5.htm

74