11/02/2025

Ingénierie Informatique et Technologies Emergentes

(IITE)

Modélisation UML
Pr. Fatima zahra SALMAM
[email protected]

Objectifs du cours
✓Apprendre les formalismes et méthodes utilisés en modélisation
d'entreprise.

✓Maitriser la modélisation UML.

✓Découvrir les bases du langage UML et son rôle dans le génie logiciel.

✓Apprendre à utiliser les différents types de diagrammes UML pour

représenter des systèmes.

✓Concevoir une architecture logicielle avant l’implémentation.

Pr. FZ. SALMAM UML - 2024/2025 2

1
 11/02/2025

Introduction
La modélisation en génie logiciel consiste à représenter un système logiciel de
manière abstraite pour mieux le comprendre, le concevoir et le communiquer
avant son développement.
▪ Comprendre les besoins et exigences du client.
▪ Communiquer avec les parties prenantes grâce à des représentations
visuelles.
▪ Concevoir des solutions logicielles robustes et évolutives.
▪ Anticiper les problèmes avant la phase de développement.

Pr. FZ. SALMAM UML - 2024/2025 3

Introduction
Pourquoi modéliser?

▪ Réduire la complexité en divisant le système en composants.

▪ Représenter la réalité telle qu'elle est perçue par les utilisateurs.

▪ Permettre une conception progressive

▪ Améliorer la prise de décision en identifiant les dépendances et interactions.
▪ Documenter le système pour le développement, la maintenance et
l'évolution.

Pr. FZ. SALMAM UML - 2024/2025 4

2
 11/02/2025

Introduction

Réalité Modèles
Modélisation (représentations
(représentations mentales,
schématiques,
connaissances, règlements …)
formulations
rigoureuses …)

Implantation

Pr. FZ. SALMAM UML - 2024/2025 5

Un modèle ?
▪ 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.

Pr. FZ. SALMAM UML - 2024/2025 6

3
 11/02/2025

Type de modélisation
▪ Deux types de modélisation:

❑ La modélisation fonctionnelle.

❑ La modélisation orienté objet.

Pr. FZ. SALMAM UML - 2024/2025 7

Principe de la modélisation fonctionnelle

▪ Accent mis sur ce que FAIT le système ( ses fonctions)

▪ Identification des fonctions du système puis décomposition en sous-fonctions,

récursivement, jusqu’à obtention de fonctions élémentaires, implémentables
directement.

▪ La fonction détermine la structure.

Pr. FZ. SALMAM UML - 2024/2025 8

4
 11/02/2025

Principe de la modélisation orientée objet

▪ Accent mis sur ce qu’EST le système (ses composants).

▪ Identification des composants du système : les objets.

▪ fonction = collaboration entre objets.

▪ Les fonctions sont indépendantes de la structure.

▪ Un objet intègre à la fois des données et des opérations.

Pr. FZ. SALMAM UML - 2024/2025 9

Matériel et logiciel
▪ Systèmes informatiques :
❑ 80% de logiciel
❑ 20% de matériel
▪ Depuis quelques années, la fabrication du matériel est assurée par quelques fabricants
seulement.
❑ Le matériel est relativement fiable.
❑ Le marché est standardisé.
➢ Les problèmes liés à l'informatique sont essentiellement des problèmes de
logiciel.
Pr. FZ. SALMAM UML - 2024/2025 10

10

5
 11/02/2025

La crise du logiciel
▪ Étude sur 8 380 projets (Standish Group, 1995) :
❑ Succès : 16%
❑ Problématique : 53% (budget ou délais non respectés, défaut de fonctionnalités)
❑ Échec : 31% (abandonné).

Le taux de succès décroît avec la taille des projets et la taille des entreprises.

▪ Génie Logiciel (Software Engineering) :

❑ Comment faire des logiciels de qualité ?
❑ Qu'attend-on d'un logiciel ? Quels sont les critères de qualité ?

Pr. FZ. SALMAM UML - 2024/2025 11

11

Critères de qualité d'un logiciel

▪ Utilité : Adéquation entre le logiciel et les besoins des utilisateurs.
▪ Fiabilité
▪ Interopérabilité : Interactions avec d'autres logiciels.
▪ Performance
▪ Portabilité
▪ Réutilisabilité
▪ Facilité de maintenance : la maintenance absorbe une très grosse partie des
efforts de développement.
Pr. FZ. SALMAM UML - 2024/2025 12

12

6
 11/02/2025

Cycle de vie d’un logiciel

La qualité du processus de fabrication est garante de la qualité du produit.

▪ Pour obtenir un logiciel de qualité, il faut en maîtriser le processus

d'élaboration.
❑ La vie d'un logiciel est composée de différentes étapes.
❑ La succession de ces étapes forme le cycle de vie du logiciel.
❑ Il faut contrôler la succession de ces différentes étapes.

Pr. FZ. SALMAM UML - 2024/2025 13

13

Étapes du développement
▪ Les étapes de développement d’un logiciel/système informatique:
❑ Expression des besoins : Il traduit l'apport du futur système,
❑ Spécifications : Précision avec des descriptifs, schémas, modèles, …
❑ Analyse : Détermination des éléments du système,
❑ Conception : Rédaction des cahiers des charges de réalisation,
❑ Implémentation : Mise en œuvre et réalisation,
❑ Tests de vérification : Tests unitaires et finals,
❑ Validation : Utilisation d'un cahier de recettes,
❑ Maintenance et évolution : Correction des erreurs, ajouts de fonctionnalité, …

▪ L’organisation de ces activités et leur enchaînement définit le cycle de vie du

système.

Pr. FZ. SALMAM UML - 2024/2025 14

14

7
 11/02/2025

Langages de modélisation
▪ Un langage de modélisation doit définir :
❑ La sémantique des concepts ;
❑ Une notation pour la représentation de concepts ;
❑ Des règles de construction et d'utilisation des concepts.
▪ Des langages à différents niveaux de formalisation:
❑ Langages formels (Z, B, VDM) : le plus souvent mathématiques, au grand
pouvoir d'expression et permettant des preuves formelles sur les spécifications;
❑ Langages semi-formels (MERISE, UML...) : le plus souvent graphiques, au
pouvoir d'expression moindre mais plus faciles d'emploi.

Pr. FZ. SALMAM UML - 2024/2025 15

15

Langages de modélisation
▪ L'industrie du logiciel dispose de nombreux langages de modélisation :
❑ Adaptés aux systèmes procéduraux (MERISE...) ;
❑ Adaptés aux systèmes temps réel (ROOM, SADT...) ;
❑ Adaptés aux systèmes à objets (OMT, Booch, UML...).
▪ Le rôle des outils (Ateliers Génie Logiciel) est primordial pour l'utilisabilité en
pratique des langages de modélisation.
▪ Dans le cadre de ce cours nous allons se concentré sur la modélisation en
utilisant la méthode orientée objet (UML)

Pr. FZ. SALMAM UML - 2024/2025 16

16

8
 11/02/2025

Historique

Années 70 • Les approches cartésiennes

• Orientée traitements.

Années 80 • Les approches systémiques

• Orientée données.

Années 90 • Les approches objet

• Orientée données et traitements.

Pr. FZ. SALMAM UML - 2024/2025 17

17

Historique
▪ Au milieu des années 90, les auteurs de Booch, OOSE et OMT ont décidé de créer un langage de
modélisation unifié avec pour objectifs :
❑ Modéliser un système des concepts à l'exécutable, en utilisant les techniques orientée objet ;
❑ Réduire la complexité de la modélisation ;
❑ Utilisable par l'homme comme la machine :
➢ Représentations graphiques mais disposant de qualités formelles suffisantes pour être
traduites automatiquement en code source;
➢ Ces représentations ne disposent cependant pas de qualités formelles suffisantes pour justifier
d'aussi bonnes propriétés mathématiques que des langages de spécification formelle (Z,
VDM...).
▪ Officiellement UML est né en 1994.

UML v2.0 date de 2005. Il s'agit d'une version majeure apportant des innovations radicales et
étendant largement le champ d'application d'UML. La dernière version actuellement est 2.5.1
Pr. FZ. SALMAM UML - 2024/2025 18

18

9
 11/02/2025

Qu’est-ce qu’UML ?
UML signifie Unified Modelling Language, est un langage pour visualiser,
spécifier, concevoir et documenter tous les aspects d'un système d'information:

▪ Langage : lexique (graphique), syntaxe (diagrammes), sémantique

▪ Visualiser : représentation graphique

▪ Spécification : précis, complet, non-ambigu

▪ Construction : translation vers des langages de programmation

▪ Documentation : des besoins aux tests.

Pr. FZ. SALMAM UML - 2024/2025 19

19

Qu’est-ce qu’UML ?
▪ UML fournit un support de communication : un langage graphique comportant
des diagrammes standards représentant des 'vues' d'un système d'information.

▪ UML permet d'exprimer et d'élaborer des modèles objets, indépendamment de

tout langage de programmation.

▪ Un Diagramme?
➢Représentation graphique d'un ensemble d'éléments et de relations qui
constituent un système.

Pr. FZ. SALMAM UML - 2024/2025 20

20

10
 11/02/2025

Pourquoi utiliser UML ?

▪ Facilite la communication entre les équipes (développeurs, analystes, clients).

▪ Permet de visualiser la structure et le comportement d'un système.

▪ Aide à identifier les erreurs avant l'implémentation.

▪ Documente le système de manière claire et standardisée.

Pr. FZ. SALMAM UML - 2024/2025 21

21

Phase de modélisation
A ❖ La capture des besoins
N
L
❖ L’analyse des besoins
Y
S
E ❖ L’analyse du domaine et des objets métiers
C
O
❖ Modélisation de l’architecture
N
C
E ❖ Spécification des composants
P
T
I ❖ Conception interne
O
Pr. FZ. SALMAM N UML - 2024/2025 22

22

11
 11/02/2025

Analyse et Conception
▪ On doit :
❑ Bien comprendre les demandes et exigences des utilisateurs finaux
❑ Bien communiquer avec le client
❑ Tenir compte des changements du cahier des charges
❑ Empêcher la découverte tardive de défauts sérieux dans le projet
❑ Traiter au plus tôt tous les points critiques du projet
❑ Bien maîtriser la complexité (coût, temps, ressources humaines et matérielle)
❑ Favoriser la réutilisation
❑ Définir une architecture robuste
❑ Faciliter le travail en équipe
▪ Nous avons, donc, besoin de:
❑ Modèles (version abstraite du système avant son implémentation)
❑ Méthodologie (la stratégie suivie pour élaborer le projet)
Pr. FZ. SALMAM UML - 2024/2025 23

23

Eléments représentables en UML

▪ Les différents éléments représentables dans UML sont :
❑ Activité d'un objet/logiciel

❑ Acteurs

❑ Processus

❑ Schéma de base de données

❑ Composants logiciels

❑ Réutilisation de composants

Pr. FZ. SALMAM UML - 2024/2025 24

24

12
 11/02/2025

Domaines d’utilisation d’UML

▪ Systèmes à forte composante logicielle
❑ Les systèmes d’information pour les entreprises
❑ Les services bancaires et financiers
❑ Les télécommunications
❑ Les transports
❑ L’électronique médicale

❑ Les services distribués et les applications WEB

❑ La défense / l’aérospatiale

▪ Pas limité à un domaine précis !

Pr. FZ. SALMAM UML - 2024/2025 25

25

Le formalisme d'UML
▪ UML se décompose en plusieurs sous-ensembles
❑ Les vues : Les vues sont les observables du système. Elles décrivent le système d'un point
de vue donné, qui peut être organisationnel, dynamique, temporel, architectural,
géographique, logique, etc. En combinant toutes ces vues, il est possible de définir (ou
retrouver) le système complet.
❑ Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci décrivent le
contenu des vues, qui sont des notions abstraites. Les diagrammes peuvent faire partie de
plusieurs vues.
❑ Les modèles d'élément : Les modèles d'élément sont les briques des diagrammes UML,
ces modèles sont utilisés dans plusieurs types de diagramme.

Pr. FZ. SALMAM UML - 2024/2025 26

26

13
 11/02/2025

Les 4+1 Vues

▪ Une façon de mettre en œuvre UML est de considérer différentes vues qui
peuvent se superposer pour collaborer à la définition du système :
→ Services du système → Configuration du système

Vue logique Vue des composants

COMMENT Dépendances

Besoins des
utilisateurs → Comportement du système
QUOI et QUI

→ Performance du système → Topologie du système

Vue des processus Vue de déploiement

Temporelle et Technique OU
Pr. FZ. SALMAM UML - 2024/2025 27

27

Diagrammes UML
▪ UML permet de construire plusieurs modèles d’un système selon les vues:
❑ certains montrent le système du point de vue des utilisateurs,
❑ d’autres montrent sa structure interne,
❑ d’autres encore donnent une vision globale ou détaillée des fonctionnalités
du système.

▪ Les modèles se complètent et peuvent être assemblés.

▪ Ils sont élaborés tout au long du cycle de vie du développement d’un système
depuis le recueil des besoins jusqu’à la phase de conception.

Pr. FZ. SALMAM UML - 2024/2025 28

28

14
 11/02/2025

Diagrammes UML
▪ UML 2.5.1 propose 14 types de diagrammes.

▪ UML n'étant pas une méthode, leur utilisation est laissée à l'appréciation de
chacun, même si le diagramme de classes est généralement considéré comme
l'élément central d'UML.

▪ Les 14 diagrammes UML sont dépendants hiérarchiquement et se complètent,

de façon à permettre la modélisation d'un projet tout au long de son cycle de vie.

Pr. FZ. SALMAM UML - 2024/2025 29

29

Axes de modélisation des diagrammes UML

▪ UML modélise le système selon trois modes de représentations:
❑ Fonctionnel : décrit les services fonctionnels rendus par le système;

❑ Statique : décrit la structure statique du système (structure de données);

❑ Dynamique : concerne le dynamique fonctionnel du système (opérations sur les

données).

▪ Les trois représentations sont nécessaires et complémentaires pour schématiser

la façon dont le système est composé et le fonctionnement de ses composants.

Pr. FZ. SALMAM UML - 2024/2025 30

30

15
 11/02/2025

Axes de modélisation des diagrammes UML

Statique ou structurels
Diagramme de Classes
Diagramme d’Objets
Diagramme de Composants
Diagramme de Déploiement
Diagramme des paquetages
Diagramme de structure composite
Diagramme de profils

Fonctionnel ou comportementaux Dynamique ou d’interaction

Diagramme des cas d’utilisation Diagramme de Séquence
Diagramme d’états-transitions Diagramme de communication
Diagramme d’activité Diagramme global d'interaction
Diagramme de temps
Pr. FZ. SALMAM UML - 2024/2025 31

31

Quatre distinctions capitales

▪ Développement = Conception + Réalisation
❑ La conception: consiste à comprendre et prévoir ce qu’il a à faire.
❑ La réalisation (implémentation): consiste à faire concrètement ce qu’il y a à faire.

▪ Conception = Analyse fonctionnelle + Analyse organique

❑ L’analyse fonctionnelle s’occupe des fonctions (ou des services) que le système offre à
ses utilisateurs.
➢ Ce sont les « cas d’utilisation » (vocabulaire UML). On parle ici du QUOI.
❑ L’analyse organique s’occupe de la façon dont sera construit le système pour répondre
aux attentes de l’analyse fonctionnelle. On parle ici du COMMENT

Pr. FZ. SALMAM UML - 2024/2025 32

32

16
 11/02/2025

Quatre distinctions capitales

▪ Analyse organique = Architecture système + Analyse détaillée
❑ L’architecture système (s’occupe de l’organisation des sous-systèmes logiciels et matériels du
système complet. C’est aussi à ce niveau qu’on situera l’architecture des données.
❑ L’analyse détaillée s’occupe du découpage en procédure et en fonctions informatiques de chacun
des sous-systèmes. A ce niveau vont apparaître les en-têtes des fonctions, voir leurs pseudo-code.

▪ Données et Traitements
❑ Les données sont analysées pour elle-même, indépendamment des traitements qu’on leur appliquera
(structures, stockage, …).
❑ Les traitements sont les processus qui permettent la saisie, la validation ou la mise-à-jour des
données ou la production du savoir à partir des données. (les méthodes des objets).

Pr. FZ. SALMAM UML - 2024/2025 33

33

Diagrammes UML
▪ Dans ce cours nous allons couvrir les diagrammes UML qui correspondent chacun
à une étape de la conception:
1. Analyse fonctionnelle : avec des diagrammes des cas d’utilisation, de séquence et
d’activités.

2. Analyse des données : avec un diagramme des classes.

3. Analyse organique détaillée : avec des diagrammes de séquence, d’objets, et d’états

transition.

4. Architecture : avec des diagrammes de composants et de déploiement (optionnel).

Pr. FZ. SALMAM UML - 2024/2025 34

34

17
 11/02/2025

En résumé !
▪ UML est un langage standard de modélisation, pas une méthode.

▪ UML est un langage de modélisation orienté objet.

▪ UML convient pour toutes les méthodes objet.

Pr. FZ. SALMAM UML - 2024/2025 35

35

Outils UML
▪ Il y a plusieurs outils pour la modélisation UML. Ils peuvent être regroupés en trois
catégories:
❑ Les outils de dessin des diagrammes (comme Visio et OmniGraffle) ne sont pas vraiment le
meilleur choix car mettent plus le focus sur l’apparence visuel.

❑ Les éditeurs de diagramme UML (comme Violet UML and UMLet) supportent explicitement
l’édition des différents éléments des diagramme UML et respectent la sémantique des diagrammes.

❑ Les outils CASE (Computer Aided Software Engineering) (comme Papyrus, Rational Rose,
ArgoUML, …) permet l’utilisation d’UML pour la construction de modèles détaillés et puissants. Ils
incluent typiquement : la génération de code (génération de squelettes dans différents langages
cibles à partir des models UML) et le reverse engineering (lire le code existant et générer ou mettre
à jour les diagrammes existant).
Pr. FZ. SALMAM UML - 2024/2025 36

36

18
 11/02/2025

Diagramme de cas d’utilisation

« Use Case »

37

But de la modélisation : Rappel

▪ Le but de la modélisation est de comprendre et structurer les besoins du client.

▪ Il ne faut pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins !

▪ Une fois identifiés et structurés, ces besoins :

❑ définissent le contour du système à modéliser (ils précisent le but à atteindre),

❑ permettent d'identifier les fonctionnalités principales (critiques) du système.

▪ Le modèle conceptuel doit permettre une meilleure compréhension du système.

▪ Le modèle conceptuel doit servir d'interface entre tous les acteurs du projet.

▪ Les besoins des clients sont des éléments de traçabilité dans un processus intégrant
UML.
Pr. FZ. SALMAM UML - 2024/2025 38

38

19
 11/02/2025

Modélisation des besoins

▪ Avant de développer un système, il faut savoir précisément à QUOI il devra servir,
c.à.d. : à quels besoins il devra répondre.

Avec UML, on modélise les besoins au moyen de diagrammes de cas d'utilisation

Pr. FZ. SALMAM UML - 2024/2025 39

39

Diagramme des Cas d’utilisation « Use case »

▪ Les « use case » permettent de structurer les besoins des utilisateurs et les objectifs
correspondants d’un système.

▪ Ils centrent l'expression des exigences du système sur ses utilisateurs.

▪ Ils se limitent aux préoccupations "réelles" des utilisateurs ;

▪ Ils ne présentent pas de solutions d'implémentation et ne forment pas un inventaire fonctionnel

du système.

▪ Ils identifient les utilisateurs du système (acteurs) et leur interaction avec le système.

▪ Ils permettent de classer les acteurs et structurer les objectifs du système.

▪ Ils servent de base à la traçabilité des exigences d'un système dans un processus de
développement intégrant UML.
Pr. FZ. SALMAM UML - 2024/2025 40

40

20
 11/02/2025

Diagramme des Cas d’utilisation « Use case »

▪ Chaque cas d’utilisation décrit le comportement du système à la suite d'une stimulation
externe.

▪ Un diagramme des cas d’utilisation = Acteurs + Cas d’utilisation + Relations

▪ La frontière du système est délimitée par un cadre rectangulaire.

▪ Le nom du système figure à l’intérieur du cadre, en haut.

▪ Les cas d’utilisation à l’intérieur.

▪ Les acteurs sont à l’extérieur du système. Ils interagissent avec lui.

Pr. FZ. SALMAM UML - 2024/2025 41

41

Exemple : Diagramme de cas d'utilisation

Frontière du système Borne interactive d’une banque Nom du système

Acteur

Retirer argent cas d'utilisation

Effectuer un virement
Client

Consulter compte
Relation de type : association

Pr. FZ. SALMAM UML - 2024/2025 42

42

21
 11/02/2025

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

▪ Acteur : entité externe qui interagit avec le système :fournir, recevoir, échanger de
l’information

▪ Tout ce qui doit échanger de l’information avec le système : personne, machine,

organisation, autre système, imprimante…)

▪ Les acteurs sont identifiés en observant les utilisateurs directs du système ainsi que les
autres systèmes en interaction avec celui-ci.
« acteur »
Nom de l’acteur

Pr. FZ. SALMAM UML - 2024/2025 43

43

Acteur
▪ Un acteur représente un rôle joué par un utilisateur qui interagit avec le système

▪ Un acteur correspond à un rôle (pas forcément à une personne physique ).

▪ La même personne physique (ou autre entité) peut jouer le rôle de plusieurs acteurs
(vendeur, client)

▪ Les acteurs peuvent être classés (hiérarchisés) en faisant une sorte d’héritage.

Pr. FZ. SALMAM UML - 2024/2025 44

44

22
 11/02/2025

Représentation d’un acteur

▪ Un acteur peut être représenté de deux manières différentes :

❑ Par un petit bonhomme ayant son nom inscrit dessous.

❑ Par un rectangle contenant le stéréotype «acteur » avec son nom juste en dessous.
Nom acteur

▪ Il est recommandé d’ajouter un commentaire sur l’acteur pour préciser son rôle.

« Acteur »
Nom Acteur

Pr. FZ. SALMAM UML - 2024/2025 45

45

Représentation d’un acteur

Pr. FZ. SALMAM UML - 2024/2025 46

46

23
 11/02/2025

Type d’acteurs
▪ on distingue deux types :

❑ Acteurs principaux : utilisent les fonctions principales du système.

➢ Par exemple, le client pour un distributeur de billets.

➢ On utilise le stéréotypée « primary ».

❑ Acteurs secondaires : effectuent des tâches administratives ou de maintenance.

➢ Par exemple, la personne qui recharge la caisse contenue dans le distributeur.

➢ On utilise le stéréotypée « secondary ».

▪ En général, l’acteur principal initie le cas d’utilisation par ses sollicitations.

▪ Un acteur secondaire est sollicité pour des informations complémentaires.

Pr. FZ. SALMAM UML - 2024/2025 47

47

Un «cas d’utilisation»
▪ Un cas d’utilisation se représente par une ellipse contenant son nom : Nom du cas d’utilisation

▪ Les cas d’utilisations représentent le dialogue entre l’acteur et le système de manière

abstraite.

▪ Permet à un acteur d'atteindre un but (c'est une manière d'utiliser le système).

▪ Ensemble de scénarios au sein d’une description unique.

▪ Nommez les cas d’utilisation par un verbe à l’infinitif suivi d’un complément, du point
de vue de l’acteur (et non pas du point de vue du système).

Un cas d’utilisation est une séquence d’activités ou d’actions organisées en étapes

distinctes, et qu’un système effectue en réponse à une sollicitation extérieure.

Pr. FZ. SALMAM UML - 2024/2025 48

48

24
 11/02/2025

Relation entre acteur et cas d’utilisation

▪ Relation d’association: C’est le chemin de communication entre un acteur et un cas
d’utilisation et est représenté un trait continu.

▪ 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:
❑ * pour plusieurs;
Borne interactive d’une banque
❑ n pour exactement n;

❑ n..m pour entre n et m

❑ etc. * Effectuer un virement

Client

Pr. FZ. SALMAM UML - 2024/2025 49

49

Relations entre cas d’utilisation

▪ Après avoir identifié 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.

▪ Il existe principalement deux types de relations :

❑ Les dépendances stéréotypées, qui sont explicitées par un stéréotype. Les plus utilisées sont :
l’inclusion et l’extension.

❑ La généralisation/spécialisation.

Pr. FZ. SALMAM UML - 2024/2025 50

50

25
 11/02/2025

Relation d’inclusion
▪ Un cas A est inclus dans un cas B si le comportement décrit par le cas A fait partie du
comportement de B. On dit que le cas B dépend de A.

▪ L’inclusion est représentée par une flèche avec un trait pointillé stéréotypée «inclut»
ou «include», si B inclut A, flèche dirigée de B vers A.

▪ Lorsque B est sollicité, A l’est obligatoirement.

Pr. FZ. SALMAM UML - 2024/2025 51

51

Relation d’inclusion
▪ Exemple:
Borne interactive d’une banque

Retirer argent « include »

« include »
Effectuer un virement S’authentifier
Client
« include »
Consulter compte

Pr. FZ. SALMAM UML - 2024/2025 52

52

26
 11/02/2025

Relation d’inclusion
▪ La relation d’inclusion permet de :

❑ Factoriser une partie commune à plusieurs cas d’utilisation.

❑ Décomposer un cas complexe en sous cas plus simples.

▪ Un cas d’utilisation est dit interne sil n’est pas relié directement à un acteur.

▪ Les relations entre cas d’utilisation ne sont pas obligatoires. Elles permettent de
clarifier et d’enrichir les cas d’utilisation.

Pr. FZ. SALMAM UML - 2024/2025 53

53

Relation d’extension
▪ On dit qu’un cas d’utilisation B étend un cas d’utilisation A lorsque B peut être
appelé au cours de l’exécution de A.

▪ L’extension est représentée par une flèche avec un trait pointillé stéréotypée « extend »
ou «étend», si B étend A, flèche dirigée de B vers A.

▪ Exécuter A peut éventuellement entraîner l’exécution de B.

▪ Le comportement ajouté s’insère au niveau d’un point d’extension définit dans A.

Pr. FZ. SALMAM UML - 2024/2025 54

54

27
 11/02/2025

Relation d’extension
▪ Le cas d'utilisation étendu peut fonctionner tout seul, mais il peut également être
complété par un autre cas d'utilisation, sous certaines conditions.

▪ Une extension est souvent soumise à une condition.

❑ Graphiquement, la condition est exprimée sous la forme d’une note.

▪ On utilise principalement cette relation pour séparer le comportement optionnel (les

variantes) du comportement obligatoire.

Pr. FZ. SALMAM UML - 2024/2025 55

55

Relation d’extension
▪ Exemple : La vérification du solde du compte n’intervient que si la demande de retrait
d’argent dépasse 200 DHs. Borne interactive d’une banque

Retirer argent
« include »
Effectuer un virement
Point d’extension :
vérificationSolde {après
avoir demandé le montant}
« include »
« extend »
S’authentifier
Client Vérifier le solde

« include »
Condition: {Si montant>200} Consulter compte
Points d’extension: vérificationSolde
Pr. FZ. SALMAM UML - 2024/2025 56

56

28
 11/02/2025

Relations d’inclusion VS d’extension

▪ La relation «extend» montre une possibilité d'exécution des 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.

Pr. FZ. SALMAM UML - 2024/2025 57

57

Relations de généralisation
▪ Un cas A est une généralisation d’un cas B si B est un cas particulier de A.

▪ La relation de généralisation est représentée par une flèche avec un trait plein dont la pointe est
un triangle fermé désignant le cas le plus général.

▪ Cette relation se traduit par le concept d’héritage dans les langages orientés objet.

Pr. FZ. SALMAM UML - 2024/2025 58

58

29
 11/02/2025

Relations de généralisation
Borne interactive d’une banque
▪ Exemple :
Retirer argent
« include »
Effectuer un virement
Point d’extension :
vérificationSolde {après
avoir demandé le montant}
« include »
« extend »
S’authentifier
Client Vérifier le solde

« include »
Condition: {Si montant>200} Consulter compte
Points d’extension: vérificationSolde

Consulter sur Internet

Pr. FZ. SALMAM UML - 2024/2025 59

59

Relations de généralisation
▪ La seule relation possible entre deux acteurs est la généralisation.

▪ Un acteur A est une généralisation d’un acteur B si B peut se remplacer par A.

▪ Dans ce cas, on utilise la relation de généralisation/spécialisation:

▪ Si A généralise B, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l'inverse n'est
pas vrai.

Acteur général

Acteur spécialisé
Pr. FZ. SALMAM UML - 2024/2025 60

60

30
 11/02/2025

Comment recenser les cas d’utilisation ?

▪ Se placer du point de vue de chaque acteur et déterminer comment il utilise le système.

▪ Éviter la redondance.

▪ Ne pas faire apparaître les détails des cas d’utilisation (ne pas réduire un cas à une
action).

▪ Rester au niveau des grandes fonctions du système.

▪ Garder à l’esprit qu’il n’y a pas de notion temporelle dans un diagramme de cas
d’utilisation.

▪ Remarque: L’ensemble des cas d’utilisation doit couvrir exhaustivement tous les
besoins fonctionnels du système.
Pr. FZ. SALMAM UML - 2024/2025 61

61

Exercice 1 :
Système « Gestion d’un établissement scolaire »

Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi
que du matériel pédagogique (ordinateur portable ou/et Vidéo projecteur). Seuls les
enseignants sont habilités à effectuer des réservations (sous réserve de disponibilité de la
salle ou du matériel).
Le planning des salles peut quant à lui être consulté par tout le monde (enseignants et
étudiants).
Cependant, 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.

Réaliser le diagramme de cas d’utilisation qui décrit le système à produire.

Pr. FZ. SALMAM UML - 2024/2025 62

62

31