Le document présente une introduction à la modélisation UML, en abordant son historique, ses diagrammes, et les besoins des utilisateurs à travers les 4+1 vues. UML est défini comme un langage de modélisation graphique standardisé, permettant de représenter, construire et documenter des systèmes logiciels. Les différentes vues, telles que les besoins des utilisateurs, les aspects fonctionnels, et l'architecture, sont détaillées avec des diagrammes spécifiques pour chaque aspect.

1. 1- Introduction à la modélisation UML
Pr. Abdelhay HAQIQ (ahaqiq@esi.ac.ma)

2. Plan
❑ Historique de la modélisation
❑ Diagrammes UML
❑ Diagrammes UML par rapport aux 4+1 Vues
❑ Besoins des utilisateurs
❑ Aspects fonctionnels
❑ Architecture
Pr. Abdelhay HAQIQ UML 2

3. Plan
❑ Historique de la modélisation
❑ Diagrammes UML
❑ Diagrammes UML par rapport aux 4+1 Vues
❑ Besoins des utilisateurs
❑ Aspects fonctionnels
❑ Architecture
Pr. Abdelhay HAQIQ UML 3

4. Pourquoi modéliser ?
o Un modèle est une simplification de la réalité qui permet de mieux comprendre le système à
développer.
o Il permet de:
– Simplifier la problématique posée par le client
– Visualiser le système comme il est ou comme il devrait l'être.
– Valider le modèle vis à vis des clients
– Spécifier les structures de données et le comportement du système.
– Fournir un guide pour la construction du système.
– Documenter le système et les décisions prises.
o Cela permet de :
– Minimiser au maximum les erreurs lors de la phase de programmation, car durant cette phase, les
erreurs sont beaucoup plus coûteuses en temps, donc en argent.
– Assurer la cohérence et éviter la redondance des données
– Assurer la conformité du logiciel aux exigences du client
Pr. Abdelhay HAQIQ UML 4

5. Historique
Il existe deux approches de modélisation et de programmation :
o Approche fonctionnelle
– 1960 – fin 1970
– L'important c'est les traitements
– Séparation nette des données et traitements
▪ MERISE
o Approche objet
– 1980 – début 1990 : premières génération
– L'important c'est l'objet
– Objet = données + traitements
Pr. Abdelhay HAQIQ UML 5

6. MERISE
o MERISE est une méthode française née dans les années 70, développée initialement
par Hubert Tardieu. Elle fut ensuite mise en avant dans les années 80, à la demande du
Ministère de l'Industrie qui souhaitait une méthode de conception des SI.
o Signification de MERISE :
– MERISE = Methode pour Rassembler les Idées Sans Effort
– MERISE = Méthode Eprouvée pour Retarder Indéfiniment la Sortie des Etudes
– MERISE = Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise
o Elle possède un certain nombre de modèles qui sont répartis sur 4 niveaux :
– niveau conceptuel : MCC, MCT, MCD
– niveau organisationnel : MOT, MOD, MOC
– niveau logique : MLD, MLT, MLC
– niveau physique : MPD, MPT, MPC
Pr. Abdelhay HAQIQ UML 6

7. Historique
Début des années 1990 :
o Plusieurs équipes proposent alors des méthodes qui, pour la plupart, modélisent les mêmes
concepts fondamentaux dans différents langages, avec une terminologie, des notations et
des définitions différentes:
– méthode OOD de Grady Booch (1991)
– méthode OMT de James Rumbaugh (1991)
– méthode OOSE de Ivar Jacobson (1991)
– méthode OOA/OOD de Coad and Yourdon (1992)
– méthode de Schlaer and Mellor (1992)
– Etc.
o Les différents protagonistes conviennent rapidement du besoin d’unifier ces langages en un
standard unique;
– D’où la naissance de UML (Unified Modeling Language)
Pr. Abdelhay HAQIQ UML 7

8. Historique
o Fin 1994
– OMT + OOD
– Unified Method (oct 1995)
o Fin 1995
– Unified Method + OOSE
– UML 0.9 (juin 1996)
o Début 1997
– UML 1.0 (jan 1997)
o Fin 1997
– OMG (Object Management Group) retient UML 1.1 comme norme de modélisation
❖ OMG (Object Management Group) : association américaine à but non lucratif créée en 1989 dont
l’objectif est de standardiser et promouvoir le modèle objet sous toutes ses formes
Pr. Abdelhay HAQIQ UML 8

9. Historique
Les versions se succèdent :
o Début 1998
– UML 1.2
o En 1998
– UML 1.3
o En 2001
– UML 1.4
o En 2003
– UML 1.5
o En 2005
– UML 2.0
o En 2008
– UML 2.2
o La dernière version diffusée par l'OMG est UML 2.5.1 depuis Décembre 2017
Pr. Abdelhay HAQIQ UML 9

10. Plan
❑ Historique de la modélisation
❑ Diagrammes UML
❑ Diagrammes UML par rapport aux 4+1 Vues
❑ Besoins des utilisateurs
❑ Aspects fonctionnels
❑ Architecture
Pr. Abdelhay HAQIQ UML 10

11. UML
o UML (Unified Modeling Langage) est un langage de modélisation graphique, et n’est pas une méthode
o Il est conçu pour représenter, construire et documenter des systèmes logiciels utilisant les techniques
orientées objet.
o Il permet la création de plusieurs modèles d’un même système, chacun privilégiant un aspect différent :
fonctionnel, dynamique, statique
o UML offre un standard de modélisation, pour:
– visualiser : chaque symbole graphique a une sémantique
– spécifier : de manière précise et complète, sans ambiguïté,
– construire : les classes, les relations SQL peuvent être générées automatiquement
– documenter : les différents diagrammes, notes, contraintes, exigences seront présentés dans un document.
o UML propose 13 types de diagrammes, 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.
o Les 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. Abdelhay HAQIQ UML 11

12. Axes de modélisation des diagrammes
Pr. Abdelhay HAQIQ UML 12

13. Hiérarchie des diagrammes
Pr. Abdelhay HAQIQ UML 13

14. Plan
❑ Historique de la modélisation
❑ Diagrammes UML
❑ Diagrammes UML par rapport aux 4+1 Vues
❑ Besoins des utilisateurs
❑ Aspects fonctionnels
❑ Architecture
Pr. Abdelhay HAQIQ UML 14

15. Les 4+1 Vues
o 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 :
Pr. Abdelhay HAQIQ UML 15

16. Plan
❑ Historique de la modélisation
❑ Diagrammes UML
❑ Diagrammes UML par rapport aux 4+1 Vues
❑ Besoins des utilisateurs
❑ Aspects fonctionnels
❑ Architecture
Pr. Abdelhay HAQIQ UML 16

17. Les 4+1 Vues : Besoins des utilisateurs
o Besoins des utilisateurs : décrit le contexte, les acteurs ou les utilisateurs du projet logiciel, les
fonctionnalités du logiciel mais aussi les interactions entre ces acteurs et ces fonctionnalités.
o On utilise dans cette vue :
– le diagramme de package
– le diagramme de cas d’utilisation
Pr. Abdelhay HAQIQ UML 17

18. Vue Besoins des utilisateurs
o Diagramme de packages permet de décomposer le système en catégories ou parties plus
facilement observables, appelés « packages ». Cela permet également d’indiquer les acteurs
qui interviennent dans chacun des packages.
Pr. Abdelhay HAQIQ UML 18

19. Vue Besoins des utilisateurs
o Diagramme de cas d’utilisation représente les fonctionnalités (ou dit cas d’utilisation)
nécessaires aux utilisateurs. On peut faire un diagramme de cas d’utilisation pour le logiciel
entier ou pour chaque package.
Pr. Abdelhay HAQIQ UML 19

20. Plan
❑ Historique de la modélisation
❑ Diagrammes UML
❑ Diagrammes UML par rapport aux 4+1 Vues
❑ Besoins des utilisateurs
❑ Aspects fonctionnels
❑ Architecture
Pr. Abdelhay HAQIQ UML 20

21. Les 4+1 Vues : Aspects fonctionnels
o Aspects fonctionnels : permet de définir qui utilisera le logiciel, pour quoi faire, et comment
les fonctionnalités vont se dérouler, etc.
– La vue logique a pour but d’identifier les éléments du domaine, les relations et interactions
entre ces éléments. Cette vue organise les éléments du domaine en « catégories ».
– La vue des processus démontre :
▪ la décomposition du système en processus et actions
▪ les interactions entre les processus
▪ la synchronisation et la communication des activités parallèles
Pr. Abdelhay HAQIQ UML 21

22. Vue Logique
o Deux diagrammes peuvent être utilisés pour la vue logique :
– Diagramme de classe
– Diagramme d’objets
o Diagramme de classes :
– Dans la phase d’analyse, ce diagramme représente les entités (des informations) manipulées
par les utilisateurs.
– Dans la phase de conception, il représente la structure objet d’un développement orienté
objet.
o Diagramme d’objets sert à illustrer les classes complexes en utilisant des exemples
d’instances.
Pr. Abdelhay HAQIQ UML 22

23. Vue Logique : Diag. de classe
Pr. Abdelhay HAQIQ UML 23

24. Vue Logique : Diag. d’objets
o Une instance est un exemple concret de contenu d’une classe. En illustrant une partie des
classes avec des exemples (grâce à un diagramme d’objets), on arrive à voir un peu plus
clairement les liens nécessaires
Pr. Abdelhay HAQIQ UML 24

25. Les 4+1 Vues
o La vue des processus démontre :
– la décomposition du système en processus et actions
– les interactions entre les processus
– la synchronisation et la communication des activités parallèles
o La vue des processus s’appuie sur plusieurs diagrammes :
▪ diagramme de séquence
▪ diagramme d’activité
▪ diagramme de communication (anciennement appelé collaboration)
▪ diagramme d’état-transition
▪ diagramme global d’interaction
▪ diagramme de temps
Pr. Abdelhay HAQIQ UML 25

26. Vue Processus : Diag. de séquence
o Diagramme de séquence permet de décrire les différents scénarios d’utilisation du système.
Pr. Abdelhay HAQIQ UML 26

27. Vue Processus : Diag. d’activité
o Diagramme d’activité représente le déroulement des actions, sans utiliser les objets. En
phase d’analyse, il est utilisé pour consolider les spécifications d’un cas d’utilisation.
Pr. Abdelhay HAQIQ UML 27

28. Vue Processus : Diag. de communication
o Diagramme de communication (appelé également diagramme de collaboration) permet de
mettre en évidence les échanges de messages entre objets. Cela nous aide à voir clair dans les
actions qui sont nécessaires pour produire ces échanges de messages. Et donc de compléter,
si besoin, les diagrammes de séquence et de classes.
Pr. Abdelhay HAQIQ UML 28

29. Vue Processus : Diag. d’état-transition
o Diagramme d’état-transition permet de décrire le cycle de vie des objets d’une classe.
Pr. Abdelhay HAQIQ UML 29

30. Vue Processus : Diag. global d’interaction
o Diagramme global d’interaction permet de donner une vue d’ensemble des interactions du
système. Il est réalisé avec le même graphisme que le diagramme d’activité. Chaque élément
du diagramme peut ensuite être détaillé à l’aide d’un diagramme de séquence ou d’un
diagramme d’activité
Pr. Abdelhay HAQIQ UML 30

31. Vue Processus : Diag. de temps
o Diagramme de temps est destiné à l’analyse et la conception des systèmes ayant des contraintes temps-réel.
Il s’agit là de décrire les interactions entre les objets avec des contraintes temporelles fortes
Pr. Abdelhay HAQIQ UML 31
Un exemple de diagramme de temps avec un seul axe temporel
Un exemple de diagramme de temps avec un axe temporel par état

32. Plan
❑ Historique de la modélisation
❑ Diagrammes UML
❑ Diagrammes UML par rapport aux 4+1 Vues
❑ Besoins des utilisateurs
❑ Aspects fonctionnels
❑ Architecture
Pr. Abdelhay HAQIQ UML 32

33. Les 4+1 Vues : Architecture
o Aspect lié à l’architecture du logiciel : permet de définir les composantes à utiliser (exécutables,
interfaces, base de données, librairies de fonctions, etc.) et les matériels sur lesquels les composants
seront déployés.
– La vue des composants (vue de réalisation) : met en évidence les différentes parties qui
composeront le futur système (fichiers sources, bibliothèques, bases de données, exécutables, etc.)
– La vue de déploiement : décrit les ressources matérielles et la répartition des parties du logiciel sur
ces éléments
Pr. Abdelhay HAQIQ UML 33

34. Vue des composants
o La vue des composants comprend deux diagrammes.
– Le diagramme de structure composite décrit un objet complexe lors de son exécution
– Le diagramme de composants décrit tous les composants utiles à l’exécution du système
(applications, librairies, instances de base de données, exécutables, etc.).
Pr. Abdelhay HAQIQ UML 34

35. Vue du déploiement
o La vue de déploiement décrit les ressources matérielles et la répartition des parties du
logiciel sur ces éléments. Il contient le diagramme de déploiement qui correspond à la
description de l’environnement d’exécution du système (matériel, réseau…) et de la façon
dont les composants y sont installés
Pr. Abdelhay HAQIQ UML 35