UML

INTRODUCTION

Hanifi Majdoulayne

2022- 2023
Introduction

• Pour construire cette maison , Il faut établir un plan

avant
• La réalisation d’une application peut passer par
plusieurs étapes :
 Définition des besoins
 Analyse et conception
 Développement
 Test
 Validation
 Déploiement
 Maintenance
 ...
Introduction
• Où est UML dans tout ça ?

• UML permet de modéliser toutes les étapes du

développement d’une application de l’analyse au
déploiement (en utilisant plusieurs diagrammes).
• Un langage de modélisation unifié
• Ce n’est pas un langage de programmation
• Indépendant de tout langage de programmation (objet
ou autre)
• Un langage basé sur des notations graphiques
• Constitué de plusieurs graphes ( diagrammes)
permettant de visualiser la future application de
plusieurs angles différents
• Une norme maintenue par l’OMG (Object
Management Group : organisation mondiale créée en
1989 pour standardiser le modèle objet)
 Chapitre 1
1. Introduction à UML
2. Phases de l’UML
3. Les différents diagrammes de l’UML
4. Comment modéliser un projet informatique
5. Diagramme de contexte
6. Diagramme de package
7. Exemples
8. Conclusion
4
 Introduction à UML

• Un projet informatique :
une phase d’analyse.
une étape de conception.

• La phase d’analyse : on cherche à bien comprendre et à

décrire de façon précise les besoins des utilisateurs ou des
clients.
 Introduction à UML
1. Que souhaitent-ils faire avec le logiciel?
2. Quelles fonctionnalités veulent-ils ?
3. Pour quel usage ?
4. Comment l’action devrait-elle fonctionner ?
 l’analyse des besoins .

Après validation de notre compréhension du besoin, nous

imaginons la solution.
6
 Introduction à UML
• La phase de conception :
apporter plus de détails à la solution
cherche à clarifier des aspects
techniques, tels que l’installation des
différentes parties logicielles sur du
matériel.

7
 Introduction à UML
• Pour réaliser ces deux phases dans un projet informatique :
des méthodes, des conventions
et des notations.
• UML fait partie des notations les plus utilisées aujourd’hui.
• Nous allons définir ce langage (UML) et ses outils : les
diagrammes.
• Nous verrons comment ce langage peut contribuer à la
phase d’analyse des besoins et du domaine d’un projet
informatique.
8
 Introduction à UML
• UML est un langage de modélisation graphique.
• Défini par l’OMG (Object Management Group)
• C’est un standard industriel pour la conception orienté objet
des applications.
• Il est utilisé principalement pour les phases de conception
des programmes ainsi que pour la production de la
documentation.
• C’est un langage constitué d’un ensemble de schémas,
appelés des diagrammes, qui donnent chacun une vision
différente du projet à traiter.
9
 Introduction à UML

• UML nous fournit donc des diagrammes pour représenter

le logiciel à développer : son fonctionnement, sa mise en
route, les actions susceptibles d’être effectuées par le
logiciel, etc.
• Une partie du code peut être générée automatiquement à
partir d’un diagramme.
• Inversement, certains diagrammes peuvent être générés
automatiquement à partir du code (C++, JAVA)
10
 Introduction à UML
• Les diagrammes UML se répartissent en trois categories :
1. Les diagrammes de structure (statiques) : Les premiers
réalisés lors de la conception d’un système, ces
diagrammes permettent de définir l’architecture du
système.
– Diagramme de paquetages
– Diagramme de classe
– Diagramme d’objets
– Diagramme de composants
– Diagramme de déploiement
11
 Introduction à UML

• Les diagrammes UML se répartissent en trois categories :

2. Les diagrammes de comportement : ils précisent le

comportement du système.
– Diagramme de cas d’utilisation
– Diagramme états/transitions
– Diagramme d’activité

12
 Introduction à UML

• Les diagrammes UML se répartissent en trois categories :

3. Les diagrammes d’interactions (dynamiques): Ils
précisent les interactions entre les différents acteurs ou
différents composants du système.
– Diagramme de séquence
– Diagramme de communication
– Diagramme de temps

13
Introduction à UML

14
 Introduction à UML
• Lors de l’analyse et de la conception, il est parfois inutile
de décrire tous les diagrammes UML.
• De même, dans un diagramme, il est inutile de tout
décrire.
• Le degré de la precision est fonction du contexte, de la
complexité du système, de l’étape de conception…
• Il est possible de commencer l’analyse par le
comportement, ou par la structure, mais également par les
deux en parallèle!
15
 Introduction à UML
• Le langage UML ne préconise aucune démarche, ce n’est
donc pas une méthode, c’est une norme de représentation.
• Chacun est libre d’utiliser les types de diagramme qu’il
souhaite, dans l’ordre qu’il veut.
• Il suffit que les diagrammes réalisés soient cohérents entre
eux, avant de passer à la réalisation du logiciel.

16
 Introduction à UML

Pourquoi modéliser?
Modéliser, c’est décrire de manière visuelle et graphique les
besoins et, les solutions fonctionnelles et techniques de
n’importe quel projet logiciel.

Mais modéliser pour quoi faire ?

17
 Introduction à UML
• Un document de texte décrivant de façon précise ce qui doit être
réalisé dans un projet informatique contiendrait plusieurs dizaines
de pages.
• En général, peu de personnes ont envie de lire ce genre de
document.
• De plus, un long texte de plusieurs pages est source
d’interprétations et d’incompréhension.
• UML nous aide à faire cette description de façon graphique et
devient alors un excellent moyen pour visualiser le futur logiciel.

18
 Les étapes de la modélisation
• Nous allons à partir d’une étude de cas, suivre pas à pas
l’analyse des besoins d’un projet en réalisant le premier
diagramme.
• On procèdera à l’analyse des besoins d’un projet
informatique

créer une boutique en ligne.

19
 Les étapes de la modélisation
• Identifier les premiers besoins grâce aux différents échanges
avec le client.
• Découvrir au fur et à mesure les différents besoins et actions
que le client souhaite intégrer dans son projet de logiciel : la
boutique en ligne.
• Décrypter son discours au fur et à mesure afin de préciser
ses besoins. C’est ce qu’on appelle la modélisation des
besoins fonctionnels.
• Nous essaierons donc de répondre aux questions suivantes :
20
 Les étapes de la modélisation

• Qui sont les utilisateurs ?

• Que veulent-ils faire avec le logiciel ?

21
 Les étapes de la modélisation
• Il ne sert à rien de commencer à coder sans avoir compris
les besoins des utilisateurs au préalable.
Sinon risque de créer un logiciel qui
n’est pas utile, et qui est non
satisfaisant pour les utilisateurs.
• Analyser les besoins, c’est découvrir des éléments de plus
en plus précis.
Voici les étapes :
22
 Les étapes de la modélisation
Etape 1: 
• On commence par décrire le contexte du logiciel à créer.
• Qu’est-ce que c’est le contexte ?
C’est l’environnement direct du logiciel.
Il s’agit là de décrire QUI devra utiliser le logiciel.
• Se poser la question : à qui le logiciel devra servir ?

23
 Les étapes de la modélisation
Etape 2 : 
• On décompose ensuite le logiciel en plusieurs parties distinctes.
c’est ce qu’on appellee la decomposition en packages.
• La décomposition peut se faire en réfléchissant à des familles
de fonctionnalités qui seraient nécessaires.
• Les questions à se poser ?
• Quelles sont les grandes parties qui doivent composer le
logiciel ?
• Pour une partie précise, qui, parmi les utilisateurs identifiés
l’utilisera ?
24
 Les étapes de la modélisation
Etape 3 :
• Chaque partie est alors analysée séparément, en précisant
qui devra pouvoir faire quoi grâce à cette partie du
logiciel.

• C’est ce qu’on appelle définir les cas d’utilisation.

25
 Les étapes de la modélisation
• Pour illustrer chacune des étapes citées, on utilise un
diagramme précis, que nous détaillerons au fur et à
mesure de la présentation.

• Pour décrire le contexte, on réalise un diagramme de

contexte dans lequel on indiquera qui aura une utilité du
futur logiciel.

26
 Les étapes de la modélisation
• Pour expliquer la décomposition du logiciel en parties
distinctes, on se sert d’un diagramme de package.
• Celui-ci nous permettra d’indiquer qui aura besoin de
chacune des parties.
• Enfin, pour illustrer ce que le logiciel doit permettre de
faire, on utilise un diagramme de cas d’utilisation.

27
 Les étapes de la modélisation
• En fait, chaque diagramme est une précision du précédent.

• On propose de découvrir l’analyse des besoins d’un projet

de logiciel : créer la boutique en ligne d’une entreprise de
papeterie.

• Nous découvrirons pas à pas la démarche à suivre.

28
 Les étapes de la modélisation
Voici le detail du projet.

• Le client : est le directeur d’une petite entreprise

commerciale, spécialisé dans les produits de bureau.

29
 Les étapes de la modélisation
• Que vend-il ?

Voici la liste des produits qu’il vend sur place :

1. Matériel de base : crayons, stylos, gommes, papier,

cahiers, etc. 
2. Matériel électronique : ordinateurs, imprimantes,
téléphones, etc. 
3. Mobilier : tables, bureaux, chaises, armoires, etc.  30
 Les étapes de la modélisation
• Pourquoi nous contacte-t-il ?
• L’entreprise doit faire face à la concurrence de grandes
enseignes.
• Moderniser toute sa démarche commerciale.
• Passer au e-commerce, c’est-à-dire vendre ses produits sur
Internet.
• L’entreprise espère ainsi obtenir une meilleure visibilité et
obtenir une augmentation des ventes.
31
 Les étapes de la modélisation
• Que souhaite faire le directeur de l’entreprise sur le site
de vente en ligne ?
1. Le client doit pouvoir consulter les produits et
éventuellement procéder à un achat en ligne.
2. Les commerciaux de la société doivent pouvoir consulter
le catalogue des produits en ligne et enregistrer les achats
des clients. 

32
 Les étapes de la modélisation

3. Le service des livraisons doit pouvoir consulter les

commandes pour préparer les colis et les livrer au client.
4. Le technicien doit pouvoir vérifier d’éventuelles
remarques ou messages signalant un dysfonctionnement
lors de l’achat en ligne.

33
 Les étapes de la modélisation

5. Le service administratif de la société doit pouvoir :

- Ajouter de nouveaux produits au catalogue en ligne.
- Modifier les descriptions ou les prix des produits.
- Retirer si besoin des produits que l’on ne souhaite plus
proposer.

34
 Les étapes de la modélisation

6. Le directeur, quant à lui, souhaite avoir une vision

globale des ventes.
• A travers le site, il souhaite pouvoir :
- faire un suivi du chiffre d’affaires par mois, sur une
certaine durée .
- voir quels produits sont les plus vendus sur une durée
donnée. 
35
 Diagramme de contexte
Définir le contexte du futur logiciel:

• Ce diagramme n’est pas officiellement désigné comme

diagramme UML.
• Il ne fait donc pas partie des diagrammes officiels.
• il est utile pour la définition des acteurs, avant de
commencer à s’intéresser à d’autres aspects, tels que les
packages et les cas d’utilisation.
36
 Diagramme de contexte
• On commencera par considérer que le futur logiciel
correspond à une boîte noire qui doit fournir des services à
son environnement.
• Environnement : les utilisateurs qui ont besoin de ce
logiciel.
• Dans l’UML, on appelle ce qu’on doit analyser, concevoir
et réaliser : le système.
• Ici, le système est donc le site de vente en ligne.

37
 Diagramme de contexte

système

• Cette « boîte noire » sera donc utile à un ou plusieurs

utilisateurs.
• En UML, on devrait parler d’acteurs et non d’utilisateurs.

38
 Diagramme de contexte
Les acteurs :
• Un acteur correspond à une entité (humain ou non) qui
aura une interaction avec le système. Parmi les acteurs,
nous distinguons :
1. les acteurs principaux : qui agissent
directement sur le système. Il s’agit d’entités qui ont des
besoins d’utilisation du système.
• On peut donc considérer que les futurs utilisateurs du
logiciel sont les acteurs principaux. 

39
 Diagramme de contexte
2. les acteurs secondaires : n’ont pas de
besoin direct d’utilisation. Ils peuvent être soit consultés par
le système à développer, soit récepteur d’informations de la
part du système.
• Cela est généralement un autre système (logiciel) avec
lequel le nôtre doit échanger des informations. 

40
 Diagramme de contexte
• Pour les acteurs de type humain, ils sont représentés par
un bonhomme en fil de fer.
• On indique leur rôle en dessous.

Acteur

41
 Diagramme de contexte
• Pour représenter un acteur de type non-humain, on peut
utiliser une représentation graphique différente et/ou
ajouter une indication supplémentaire (appelé le
stéréotype).
• Vous pouvez voir les différentes représentations du même
acteur dans le schéma suivant.

42
 Diagramme de contexte
① Représentation d’un acteur de type non-humain

« système »
logiciel comptable

Acteur non humain sous forme de bonhomme en fil de fer avec indication du
stéréotype « système »
43
 Diagramme de contexte
② Représentation d’un acteur de type non-humain

« système »
Logiciel comptable

Acteur non humain sous forme de boite avec indication du stéréotype « système
»

44
 Diagramme de contexte
③ Représentation d’un acteur de type non-humain

Logiciel comptable

Acteur non humain sous forme de bonhomme en fil de fer avec une grande
bande noire sur la tête.

45
 Diagramme de contexte
Représentation d’un acteur de type non-humain

• La représentation graphique des acteurs non-humains diffère

en fonction de l’outil de modélisation utilisé.

• Dans cette présentation , nous utiliserons la 1ère

représentation.

46
 Diagramme de contexte

• l’environnement du système est composé d’acteurs :

 qui agissent sur le système
 ou avec lesquels le système aura une interaction.

47
 Diagramme de contexte
• À cette étape, rien ne garantit que notre vision de
l’environnement de notre boutique en ligne soit complète.
• Les diagrammes qui seront réalisés par la suite peuvent
nous obliger à revenir en arrière afin d’ajouter ou de
retirer des acteurs.
• Nous avons ici, une possibilité d’itération.

48
 Diagramme de contexte
A. Contexte de notre projet (la boutique en ligne d’une
socièté)
• Voici la demande de la société:
1. Le client doit pouvoir consulter les produits et
éventuellement procéder à un achat en ligne.
2. Les commerciaux de la société doivent pouvoir consulter
le catalogue des produits en ligne et enregistrer les achats
des clients. 

49
 Diagramme de contexte
3. Le service des livraisons doit pouvoir consulter les
commandes pour préparer les colis et les livrer au client.

4. Le technicien doit pouvoir vérifier d’éventuelles

remarques ou messages signalant un dysfonctionnement
lors de l’achat en ligne.

50
 Diagramme de contexte

5. Le service administratif de la société doit pouvoir :

- ajouter de nouveaux produits au catalogue en ligne ;
- modifier les descriptions ou les prix des produits ;
- retirer si besoin des produits que l’on ne souhaite plus
proposer.

51
 Diagramme de contexte

6. Le directeur, quant à lui, souhaite avoir une vision

globale des ventes.
• A travers le site, il souhaite pouvoir :
- faire un suivi du chiffre d’affaire par mois, sur une
certaine durée ;
- voir quels produits sont les plus vendus sur une durée
donnée. 
52
 Diagramme de contexte
Il s’agit là d’acteurs principaux, puisqu’ils devront tous
utiliser le système pour des actions précises (voir la figure
suivante).

client commercial livraison technicien administrateur directeur

Les acteurs principaux

53
 Diagramme de contexte
• On imagine mal un site commercial sans paiement en
ligne. Il faut évidemment le proposer au client.
• Pour cela, il nous faudra donc un échange avec un système
externe : le système bancaire.
Nous venons d’identifier un acteur
secondaire qui sera représenté par un
bonhomme de fil de fer avec un
stéréotype « système ».
54
Diagramme de contexte

« système »
système bancaire

L’acteur secondaire
55
 Diagramme de contexte
• Nous avons tous les éléments pour réaliser le diagramme
de contexte.
• Les acteurs sont placés à côté de la boîte noire, en
fonction de leur type.
• On place généralement les acteurs principaux à gauche du
système et les acteurs secondaires à droite.

56
 Diagramme de contexte

client

commercial
système
« système »
système bancaire
livraison
technicien

directeur
administarteur
Diagramme de contexte 57
 Diagramme de contexte
• Nous venons de créer notre premier diagramme
(diagramme de contexte).
• Maintenant, nous allons découvrir le contenu du système.
B. La décomposition en package.

diagramme de packages

58
 Diagramme de packages

• Les besoins très différents des acteurs et le nombre de

fonctionnalités dont le futur logiciel devra disposer nous
semble assez souvent compliqué.
• Pour y voir clair et pour nous faciliter la tâche, on peut
découper le futur logiciel en parties distinctes, en fonction
des « familles » de fonctionnalités et de façon à pouvoir les
analyser séparément.

59
 Diagramme de packages

• Chacune de ces parties correspond à un domaine fonctionnel

ou package.
• On va essayer d’identifier les parties bien distinctes parmi
les fonctionnalités de notre site.
• Pour ce faire, on se pose la question suivante :
Est-ce que le logiciel comporte des parties différentes qui
pourraient être analysées séparément ?

60
 Diagramme de packages
Dans notre projet de boutique en ligne, on distingue deux parties :
• La partie « Gestion de l’achat » qui contiendrait l’achat à
proprement parler, la préparation de la commande et la
vérification des remarques et problèmes liés à l’achat en ligne.
• La partie « Gestion administrative », incluant :
- les tâches liées au catalogue : ajouter ou retirer un produits,
modifier le produit, etc. 
- les vérifications des ventes : chiffre d’affaires et produits
les plus vendus par exemple. 
61
 Diagramme de packages
• Nous aurons donc deux packages.
• Un package est représenté sous forme de dossier :

Gestion des achats Gestion administrative

Les packages du système

62
 Diagramme de packages

A éviter:
• Décomposer le système en fonction des acteurs. Un
package peut être utilisé par plusieurs acteurs !
• Il n’est donc pas utile de faire des packages « client »,
« livraison », « technicien », « administration » et «
directeur ».

63
 Diagramme de packages

Réalisation de diagramme:

• Il ne nous reste plus qu’à réaliser le diagramme de packages,

en mettant en évidence les acteurs qui interviennent dans
chacun de ces packages.

• Pour cela, on représente au centre le système, qui comprend

les deux packages que nous avons trouvés : la gestion des
achats et la Gestion administrative.
64
 Diagramme de packages

• Autour de cela, nous devons donc relier les acteurs

principaux et secondaires au package correspondant !

• Le Client, le Commercial, la Livraison et le Technicien sont

les acteurs principaux, et le système bancaire est l’acteur
secondaire du package Gestion des achats.

• L’administration et le directeur sont les acteurs principaux

du package Gestion administrative.
65
 Diagramme de packages

client

Gestion des achats

commercial

« système »
système bancaire
livraison
technicien
Gestion administrative

directeur
administarteur
66
 Etude de cas 1
1. Considérons une station-service de distribution d'essence.
Les clients se servent de l'essence et le pompiste remplit les
cuves.
Le client se sert de l'essence de la façon suivante : il prend un
pistolet accroché à une pompe et appuie sur la gâchette pour
prendre de l'essence.

Question : Qui est l'acteur principal du système ? Est-ce le

client, le pistolet ou la gâchette ?
67
 Etude de cas 1

• C'est le client.

• Un acteur est toujours extérieur au système.

68
 Etude de cas 1
2. Ahmed, dont le métier est pompiste, peut se
servir de l'essence pour sa voiture. Pour modéliser
cette activité de Ahmed, doit-on définir un nouvel
acteur ? Comment modélise-t-on ça ?

69
 Etude de cas 1
• Ahmed est ici considéré comme un client. Pour définir les
acteurs, il faut raisonner en termes de rôles.

Système

Service escence

client

70
 Etude de cas 1

Question : Lorsque Ahmed vient avec son camion citerne

pour remplir les réservoirs des pompes, est-il considéré
comme un nouvel acteur ? Comment modélise-t-on cela ?

71
 Etude de cas 1

système

client Service essence

pompiste

Gestion remplissage

Ahmed est considéré comme pompiste. 72

 Etude de cas 1

3. Certains pompistes sont aussi qualifés pour opérer des

opérations de maintenance en plus des opérations habituelles
des pompistes telles que le remplissage des réservoirs. Ils sont
donc réparateurs en plus d'être pompistes.
Question : Comment modéliser cela ?

73
 Etude de cas 1

Gestion service

client

Gestion remplissage pompiste

technicien
Gestion maintenance

74
 Etude de cas 2

Gestion de bibliothèque :
• Un gérant de bibliotèque désire automatiser la gestion des prêts.
• Il commande un logiciel permettant aux utilisateurs de connaître les livres presents et
d'en réserver . 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é lors de 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.
75
 Etude de cas 2

1. Quels sont les acteurs de ce projet?

2. Construire de diagramme de contexte et de package.

76
 Etude de cas 2

Gestion des prêts

Gestionnaire de
adhérent
livres

« système »
Gestion des livres
SI bibliothèque
emprunteur

Gestion d’authentification

employé
77
 Conclusion
Nous avons donc identifié les acteurs, et les grandes familles
de fonctionnalités (packages). Après, il s’agit de définir plus
en détail les besoins de chaque acteur dans chaque package,
en répondant à ces questions : QUI devra pouvoir faire
QUOI grâce au logiciel ? Par exemple, que souhaite faire le
technicien sur le site ? Que souhaite faire le client ? Etc.
C’est l’étape de diagramme de cas d’utilisation

78