A.

U : 2023/2024

UML
Chapitre 1 :
Préparé par : Pr. Baidada chafik
PLAN

• Modélisation

• Historique d’UML2

• Diagrammes des cas d'utilisation

2
Modélisation

3
 Modélisation

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

exclut certains détails du monde réel.

• 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.
• Il reflète ce que le concepteur croit important pour la
compréhension et la prédiction du phénomène modélisé,
les limites du phénomène modélisé dépendent des
objectifs du modèle.

4
Modélisation

Deux approches principales :

• Approche fonctionnelle
• 1960 – fin 1970
• l'important c'est les traitements
• Séparation nette des données et traitements
• Approche objet
• 1980 – début 1990 : premières génération
• L'important c'est l'objet
• Objet = données + traitements

5
 Modélisation
• Approche fonctionnelle :La sémantique des concepts ;
• Décomposer la fonction globale jusqu'à obtenir des fonctions simples à
appréhender et donc à programmer.
C'est la fonction qui donne la forme du système

6
 Modélisation orientée objets

• La Modélisation Orientée Objet (COO) est la méthode qui

conduit à des architectures logicielles fondées sur les objets du
système, plutôt que sur une décomposition fonctionnelle.

C'est la structure du système qui lui donne sa forme.

• On peut partir des objets du domaine (briques de base) et

remonter vers le système global : approche ascendante.

Attention, l'approche objet n'est pas seulement ascendante !

7
 Avantages de MOO

• La réutilisation : Plus l'application est complexe et plus l'approche

POO est intéressante en terme de productivité. Le niveau de
réutilisabilité est supérieur à la programmation procédurale.
• Abstraction : Les entités objets de la POO sont proches de celles
du monde réel. Les concepts utilisés sont donc proches des
abstractions familières que nous exploitons.
• Modularité : les objets forment des modules compacts regroupant
des données et un ensemble d'opérations.
• sûreté: L'encapsulation et le typage des classes offrent une
certaine robustesse aux applications.

8
PLAN

• Modélisation

• Historique d’UML2

• Diagrammes des cas d'utilisation

9
Historique

- 2002 UML
2.0

- 1999 UML
1.3
Soumission à l’OMG
- 1997 U M L 1.1

- 1997 UML
1.0
- 1996 U M L 0.9

- 1995 Méthode unifiée 0.8

- 1993 Booch’93 O M T-2

Autres méthodes Booch’91 O M T-1 O O SE Partenaires OMG

10
 Qu’est ce que UML ?

UML(Unified Modeling Language) un 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

11
 Axes de modélisation
▪ Axe structurel
• modélisation statique du système
• quels objets manipule le système ?
• détermination du QUOI
▪ Axe fonctionnel ( interaction)
• modélisation des traitements offerts par le système
• que fait le système ?
• détermination du COMMENT
▪ Axe comportemental / dynamique
• modélisation dynamique du système
• sous quelles conditions agit le système ?
• détermination du QUAND
12
 Diagrammes d'UML

UML2 comprend 14 de diagrammes :

Diagramme UML2.0

Diagramme de structure Diagramme de comportement

Diagramme Diagramme Diagramme Diagramme Diagramme

Diagramme Diagramme
d’objets de cas d’utilisation d’interaction d’état-transitions
de classe de composants d’activité

Diagramme
Diagramme Diagramme Diagramme de Diagramme Diagramme
Diagramme de déploiement
des de séquence communication de temps d’interaction
de structures paquetages globale
composites

13
PLAN

• Modélisation

• Historique d’UML2

• Diagrammes des cas d'utilisation

14
UML
Diagrammes de cas d’utilisations

15
16
 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.

17
 Diagramme des cas d'utilisation

Comporte plusieurs éléments :

• Acteurs

• Cas d'utilisation

• Relations de dépendances, de généralisations et

d'associations

18
 Relation entre cas

Cas d’utilisation

Act1e9 urs

Acteurs
 Cas d'utilisation
Les cas d’utilisations :
• sont des unités cohérentes représentant une
fonctionnalité visible de l'extérieur
• Un cas d’utilisation est un service rendu à un acteur sans
imposer le mode de réalisation de ce service
• Un cas d'utilisation est représenté par une ellipse en
trait plein, contenant son nom ou une classe
stéréotypée.

Nom Cas Utilisation

20
 Acteurs

• 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)
• Le terme acteur ne désigne pas seulement des utilisateurs humains
mais également les autres systèmes (machines, programmes, …)
Remarques:
• La même personne physique peut jouer le rôle de plusieurs acteurs (Chef d’agence
est un client de la banque).
• D’autres part, 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).

21
Acteurs

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

• Petit personnage (stick man)

Nom Acteur

<<Acteur>>
• Classe stéréotypée Nom Acteur

22
 Acteurs ( exemple)

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

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

23
 Acteurs
Une relation d'association est chemin de communication entre un acteur
et un cas d'utilisation et est représenté un trait continu

24
 Acteurs
Un acteur peut être une spécialisation
d'un autre acteur déjà défini.
Dans ce cas, on utilise la relation de Acteur général

généralisation/spécialisation.

Acteur spécialisé

25
 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

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

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

26
 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>>

27
Relation d'inclusion
Les cas d'utilisation "Déposer de
l'argent", "Retirer 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
<<include>>
enchaînements.
Déposer de l'argent

<<include>>

S'authentifier

<<include>>
Effectuer des virements

<<include>>

Consulter solde

28
 Relation d'inclusion

• Quand un cas est trop complexe (faisant intervenir un trop grand

nombre d'actions), on peut procéder à sa décomposition en cas plus
simples.

29
 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 et relatif généralement
à une condition
30
 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.

31
Relation d'extension

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

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

34
 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". Une réservation peut être
réalisée par téléphone ou par Internet.

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

36
Relation d'héritage : Exemple

Reserver voyage

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

37
 Relations entre cas d’utilisation : Exemple

Petit exercice:
Un client peut effectuer un virement bancaire. Le virement peut
être effectué sur place par un client local ou effectué à distance
par un client distant via Internet. Les deux clients doivent être
identifié pour effectuer un virement , mais si le montant dépasse
500DH, la vérification du solde de son compte est réalisée.

38
 Relations entre cas d’utilisation

<<extend>> Vérification solde compte

Virem ent

Montant > 500 DH

<<include>>

Virement par Internet

Virement sur place

Identification

Client distant
Client local
40
 Description des cas d’utilisation
• 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.
• ➔ nécessité de décrire ce dialogue
• Deux façons sont couramment utilisées pour décrire les cas
d’utilisation :
• Description textuelle
• Description à l’aide d’un diagramme de séquence (voir la suite du
cours )

40
Description des cas d’utilisation (description textuelle)

• Il faut commence par l’identification du cas d’utilisation

puis la description des scénarios correspondant :
Exemple : ( cas d’authentification dans un site web)

•Identification
• Nom du cas : authentification
• Objectif : détaille les étapes permettant à utilisateur à se connecter
• Acteurs : Utilisateurs

41
Description textuelle Exemple :

• Exemple

42
 Diagramme des cas d'utilisation ( exemple)
Déposer de l'argent Retenir la carte

Client

<<include>>
Retirer de l'argent <<extend>>

<<include>>

Consulter le solde <<include>>

S'authentifier

<<include>>

Effectuer des virements entre c om ptes

Agent Fournir un login et un m o t

d e passe
Ravitailler

echnicien

R é p a re r

44
 Exercice :

• considérons est un site de commerce en ligne qui permet de

préparer ses achats en ligne avant de venir les chercher plus tard au
magasin. Sur l'écran de la borne automatique de magasin, il y a deux
options : « commande sur place » ou « retrait de marchandises ».
Pour retirer les marchandises, il faut obligatoirement saisir le code
client et procéder au paiement si ce n'est pas encore fait sur le site.

45
 Exercice :

• considérons est un site de commerce en ligne qui permet de

préparer ses achats en ligne avant de venir les chercher plus tard au
magasin. Sur l'écran de la borne automatique de magasin, il y a deux
options : « commande sur place » ou « retrait de marchandises ».
Pour retirer les marchandises, il faut obligatoirement saisir le code
client et procéder au paiement si ce n'est pas encore fait sur le site.

45
 UML
Diagrammes de séquences

46
 Diagramme de séquences

• Représenter les interactions entre objets et acteurs en

précisant la chronologie des échanges de messages

• Montre sous forme de scénarios, la chronologie des envoies

de messages issus d’un cas d’utilisation

• Représente une instance d’un cas d’utilisation (les scénarios

possible d’un cas d’utilisation donné)

47
 Diagramme de séquences
• Le diagramme de séquence modélise l’aspect dynamique du
système
• Il s’agit d’une séquence d’interaction d’un point de vue
temporel des acteurs et le système.
Cas d’utilisation :
Est documenté par

Diagramme de séquence système Diagramme de séquence

Analyse Conception

• Le système est une boite noire
• Le système est modélisé comme une
seul entité
• on ne s’intéresse as au composant du
système
• Le système est une boite blanche
• Le système est modélisé comme étant
un ensemble d’entité
• On s’intéresse à chaque composante du
système intervenant dans le CU 48
Diagramme de séquences

49
Diagramme de séquences

• Le diagramme de séquence fait ressortir trois concepts :

• Objet et acteur
• Message
• Ligne de vie

50
 Diagramme de séquences ( Objet)

• Les objets sont identifiés par l’intermédiaire des cas

d’utilisations (acteurs ) ou par le diagramme de classe
• Un objet est représenté par un rectangle et une ligne
verticale (ligne de vie de l’objet)
• un acteur est représenté par un bonhomme suivi et une
ligne verticale
• Les objets et acteurs communiquent en échangeant des
messages représentés par des flèches orientées de
l’émetteur au récepteur
• L’ordonnancement verticale des messages indique la
chronologie

51
Diagramme de séquences

Acteur

Objet

52
Diagramme de séquences ( message)

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

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

53
 Diagramme de séquences : Exemple

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

Le compte reçoit le message et déclenche l’opération vérifier solde
Le compte retourne le résultat (le solde actuel)
54
 Diagramme de séquences
Plusieurs concepts additionnels :

• Période d’activité
• Types de messages
• Création et destruction d’objets
• Fragments combinés

55
 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

56
 Messages
• 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 (d’appel)
• Message de retour
• Message synchrone
• Message asynchrone
• Message récursif

57
 Message simple
Message pour lequel on ne spécifie aucune information d’envoi ou
de réception
Objet_1 Objet_2

Message_1

58
 Message de retour
Message qui survient en réponse à à un message.
Il est représenté en flèche pointillée

59
 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)
Client Serveur

Objet_2 Objet_1

Sollitation

Acceptation

Message_1 Requête

Réponse

Communication client serveur : Sockets

60
 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

Objet_2 Objet_1

Message_1

61
 Message récursif
• Appelé aussi message réflexive
• Message envoyé d’un objet vers lui-même.
Client GAB
Objet_1

Introduire carte

Vérification validité
Message_1
Demande code accès

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 62
 Création et destruction d’objets
Un message peut créer ou détruire un objet

Objet_1 Objet_3

Message_1
Objet_2

Création d’objet
Message_2

Objet créé au cours de l’exécution du scénario Destruction d’objet

Objet détruit dans un scénario

63
Fragments combinés

64
Fragments combinés

• Les fragments combinés permettent de décrire des diagrammes de séquence

de manière compacte.
• Il existe une dizaine d’opérateurs définis dans la notation UML 2.x.
Principalement 4 utilisés:

alt)
• Alternative (

• Option (opt)

• Boucle (loop)

• Parallèle (par)

65
Fragments combinés alternative (alt)
▪ fragment représente un choix

▪ Similaire à un « switch » en C

66
On remarque ici une référence (ref) ver6s7 un diagramme défini ailleurs.
Fragments combinés option (opt)
• Équivalent à un opérateur alternative avec une seule condition
• Il ne possède pas l'opérande else ➔ une sorte de SI...ALORS.
• Cas particulier du alt.
• Les interactions contenues dans le fragment ne seront réalisées que si la
condition de garde est vérifiée.

68
Fragments combinés boucle (loop)
▪ Opérateur loop
▪ Permet de spécifier une boucle

69
Fragments combinés : boucle

1. Boucle qui s’exécute possiblement une infinité de fois

2. Boucle qui s’exécute 10 fois

3. Permet de spécifier une boucle

➔ La boucle s’exécute au minimum 5 fois et au maximum 10 fois

➔Si la condition est fausse, on sort de la boucle,

quel que soit le nombre d’exécutions de la boucle
70
Fragments combinés Exemple: boucle (loop)

71
 Fragments combinés parallèle (par)

Spécifie l’exécution en parallèle de plusieurs sous fragments

72
Fragments combinés Exemple: parallèle (par)

Module 3 : Spécification des exigences 73

Fragments combinés imbriqués

74
 CONCLUSION

• Diagramme de cas d’utilisation

Montre les relations possible entres les différents acteurs

Montre les relations possible entres les services du systéme

• Diagramme de séquence

Interactions entre les objets de l’application avec les acteurs

75