UML

Langage de Modélisation
Unifié

Roberton C. Philistin
robertonphilistin@yahoo.fr
37-67-63-45
1
 ULM - Sommaire
 Modélisation
 UML - définition
 Utilité d'UML
 Histoire d'UML
 Standardisation et Certification UML
 Logiciels de modélisation UML
 Le formalisme d'UML

2
 Modélisation

• Représentation simplifiée d’une

entité du monde réel.
• Représentation abstraite d’un
élément dans le monde réel.

3
 Modélisation

• L’objectif principal de la modélisation

est de maitriser la complexité
• Modéliser c’est abstraire la réalité
pour mieux comprendre le système

4
 Pourquoi modéliser?

• Modéliser, c’est décrire de manière visuelle et

graphique les besoins et, les solutions
fonctionnelles et techniques de votre projet
logiciel.
• Mais modéliser pour quoi faire ?

5
 Pourquoi modéliser?

• Avez-vous déjà eu à
constituer un meuble
en kit ou à brancher
un nouvel équipement
électronique?
• Vous serez d’accord
que c’est plus facile à
partir de schéma plutôt
qu’une page de texte,
non ?
6
 Pourquoi modéliser?

• Cet exemple nous

démontre que l’utilisation
de schémas et
d’illustrations rend
quelque chose de
complexe plus
compréhensible.
• C’est exactement ce à
quoi UML sert dans des
projets de réalisation de
logiciels !
7
 Pourquoi modéliser?

• UML nous aide à faire cette description de

façon graphique et devient alors un excellent
moyen pour « visualiser » le(s) futur(s)
logiciel(s).

8
 Pourquoi modéliser?

• Certains diront:
• On n’est pas vraiment obligé de modéliser un
logiciel que l’on doit réaliser, non ?
• À quoi bon modéliser le logiciel, puisque je sais
exactement ce qu’il faut ?
• C’est une perte de temps. La réalisation de ce
logiciel est urgente.
• Etc.

9
 Pourquoi modéliser?

• Est-ce que ça vous viendrait à l’idée de

laisser un maître d’œuvre commencer la
construction d’une maison sans avoir
préalablement fait réaliser des plans par
un architecte ?

10
 Pourquoi modéliser?

• La réponse est bien sûr que NON,

• à moins que l’on veuille bien accepter une
maison qui ne réponde pas à nos besoins, qui
soit bancale ou qui le deviendrait dans peu de
temps, et dans laquelle il serait difficile de faire
des travaux faute de plans.

11
 Pourquoi modéliser?

• Un logiciel qui a été réalisé sans analyse

et sans conception (étapes où l’on
modélise le futur logiciel) risque lui aussi
de ne pas répondre aux besoins, de
comporter des anomalies et d’être très
difficile à maintenir.

12
Langage de Modélisation Unifié

 UML (sigle désignant : Unified Modeling

Language ou «langage de
modélisation unifié») est un langage de
modélisation graphique à base de
pictogrammes.
 Il est apparu dans le monde du génie
logiciel, dans le cadre de la «conception
orientée objet».

13
 Langage de Modélisation
Unifié
• Vous pouvez soit reprendre les normes de ces
diagrammes que nous verrons au fur et à
mesure de ce cours et les dessiner à la main,
• soit utiliser des logiciels gratuits ou payants
pour les réaliser.
• Dans ce cours, j’utiliserai par exemple
StarUml, mais vous pouvez aussi utiliser :
Microsoft Visio, ArgoUml, BoUml,
PowerDesigner, etc.

14
 Langage de Modélisation Unifé

 UML est l'accomplissement de la fusion de

précédents langages de modélisation objet :
Booch, OMT, OOSE.
 Principalement issu des travaux de Grady
Booch, James Rumbaugh et Ivar
Jacobson,
 UML est à présent un standard défini par
l'Object Management Group (OMG).

15
 UML - Utilité

 UML est utilisé pour spécifier, visualiser,

modifier et construire les documents
nécessaires au bon développement
d'un logiciel orienté objet.

16
 UML - Utilité

• Les différents éléments

représentables sont :
 Activité d'un objet/logiciel
 Acteurs
 Processus
 Schéma de base de données
 Composants logiciels
 Réutilisation de composants

17
 UML - Utilité

 Grâce aux outils de modélisation UML, il

est également possible de générer
automatiquement une partie de code, par
exemple en langage Java, à partir des
divers documents réalisés.

18
UML - Histoire

19
 UML - Formalisme

 UML 2.5 propose 15 types de diagrammes

 UML n'étant pas une méthode, leur
utilisation est laissée à l'appréciation de
chacun,

20
 UML - Formalisme

 Le diagramme de classes est généralement

considéré comme l'élément central d'UML ;
 mais des méthodologies, telles que l'Unified
Process, axent l'analyse en tout premier lieu sur
les diagrammes de cas d'utilisation (Use Case).
 On peut se contenter de modéliser seulement
partiellement un système, par exemple certaines
parties critiques.

21
 UML - Formalisme

UML se décompose en plusieurs

sous-ensembles :
 Les vues

 Les diagrammes

 Les modèles d'élément

22
 UML – Formalisme (Vues)

 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.
23
 UML – Formalisme (Vues)

Différentes vues qui peuvent se superposer pour

collaborer à la définition du système :

Vue Vue

D’implémentation logique

Vue

Des cas d’utilisation

Vue Vue

Du déploiement Des processus

24
 UML – Formalisme (Vues)

 Vue des cas d'utilisation : c'est la

description du modèle vu par les acteurs du
système. Elle correspond aux besoins
attendus par chaque acteur (c'est le QUOI et
le QUI).
 Vue logique : c'est la définition du système
vu de l'intérieur. Elle explique comment
peuvent être satisfaits les besoins des
acteurs (c'est le COMMENT).

25
 UML – Formalisme (Vues)
 Vue d'implémentation : cette vue définit les
dépendances entre les modules.
 Vue des processus : c'est la vue temporelle
et technique, qui met en œuvre les notions de
tâches concurrentes, stimuli, contrôle,
synchronisation, etc.
 Vue de déploiement : cette vue décrit la
position géographique et l'architecture
physique de chaque élément du système
(c'est le OÙ)
 Note : le POURQUOI, n'est pas défini dans UML. 26
 UML – Formalisme (diagrammes)

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

27
 UML – Formalisme (diagrammes)
Les 15 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.

28
 UML – Formalisme (diagrammes)

 Diagramme de classes (Class diagram) : il

représente les classes intervenant dans le
système.
 Diagramme d'objets (Object diagram) : il sert à
représenter les instances de classes (objets)
utilisées dans le système.
 Diagramme de composants (Component
diagram) : il permet de montrer les composants du
système d'un point de vue physique, tels qu'ils sont
mis en œuvre (fichiers, bibliothèques, bases de
données…)
29
 UML – Formalisme (diagrammes)

 Diagramme de déploiement
(Deployment diagram) : il sert à
représenter les éléments matériels
(ordinateurs, périphériques, réseaux,
systèmes de stockage…) et la manière
dont les composants du système sont
répartis sur ces éléments matériels et
interagissent entre eux.

30
 UML – Formalisme (diagrammes)

 Diagramme des paquetages (Package

diagram) : un paquetage étant un
conteneur logique permettant de regrouper
et d'organiser les éléments dans le modèle
UML,
 le diagramme de paquetage sert à
représenter les dépendances entre
paquetages, c’est-à-dire les dépendances
entre ensembles de définitions.

31
 UML – Formalisme (diagrammes)

• Diagramme de structure composite

(Composite Structure Diagram) : depuis UML
2.x, permet de décrire sous forme de boîte
blanche les relations entre composants d'une
classe.
• Diagramme de profils (Profil Diagram) : depuis
UML 2.2, permet de spécialiser, de
personnaliser pour un domaine particulier un
meta-modèle de référence d'UML.

32
 UML - Formalisme

 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 diagrammes.

 Exemple d'élément : cas d'utilisation (CU
ou cadut'), classe, association, etc.

33
Éléments de modélisation

34
Les éléments de modélisation de
type commun

35