cours cours UML .pdf



Nom original: cours cours UML.pdf
Titre: COURS UML
Auteur: js

Ce document au format PDF 1.4 a été généré par PDFCreator Version 0.9.3 / GPL Ghostscript 8.54, et a été envoyé sur fichier-pdf.fr le 13/01/2012 à 14:54, depuis l'adresse IP 41.214.x.x. La présente page de téléchargement du fichier a été vue 10844 fois.
Taille du document: 370 Ko (79 pages).
Confidentialité: fichier public


Aperçu du document


ECOLE NATIONALE DES INGENIEURS DES TRAVAUX
AGRICOLES DE BORDEAUX
DEPARTEMENT ENTREPRISE ET SYSTEME
UNITE DE FORMATION
INFORMATIQUE ET GENIE DES EQUIPEMENTS


COURS UML
Ce cours a été écrit en grande partie à partir du site http://uml.free.fr (Merci à son
auteur : Laurent Piechocki) ainsi que du cours de Frédéric Di Gallo (CNAM angoulême).

COURS UML13.doc – Mars 2005

J.STEFFE – ENITA de Bordeaux

SOMMAIRE
SOMMAIRE ____________________________________________________________ 2
TABLE DES MATIERES __________________________________________________ 4
INTRODUCTION ________________________________________________________ 1
UML est une norme __________________________________________________________ 3
UML est un langage de modélisation objet._______________________________________ 3
UML est un support de communication _________________________________________ 4
UML est un cadre méthodologique pour une analyse objet__________________________ 5

I). Le contexte d’apparition d’UML __________________________________________ 8
I.1) Approche fonctionnelle versus approche objet ________________________________ 8
I.1.1) L’approche fonctionnelle _______________________________________________________ 8
I.1.2) L’approche objet ____________________________________________________________ 10

I.2) La genèse d’UML _______________________________________________________ 14
I.2.1) Historique des méthodes d’analyse ______________________________________________
I.2.2) Cadre d’utilisation d’UML _____________________________________________________
I.2.3) Points forts d’UML __________________________________________________________
I.2.4) Points faibles d’UML _________________________________________________________

14
15
16
17

II) Démarche générale de modélisation avec UML _____________________________ 18
II.1) Qu'est-ce qu'un modèle ? ________________________________________________ 18
II.1.1) Définition d’un modèle _______________________________________________________ 18
II.1.2) Caractéristiques fondamentales des modèles ______________________________________ 18

II.2 ) Comment modéliser avec UML ? _________________________________________ 18
II.2.1) Proposition de démarche______________________________________________________ 18
II.2.2) La vue « 4+1 » de ph. Kruchten ________________________________________________ 20
II.2.3) Les niveaux d’abstraction _____________________________________________________ 21

II.4 ) L’utilisation de diagrammes _____________________________________________ 23
II.4.1) Définition d’un diagramme ____________________________________________________ 23
II.4.2) caractéristiques des diagrammes UML ___________________________________________ 23
II.4.3) Les différents types de diagrammes UML ________________________________________ 23

III) Les Différents types de diagrammes _____________________________________ 24
III.1) Vues statiques du système _______________________________________________ 24
III.1.1) diagrammes de cas d'utilisation ________________________________________________
III.1.2) diagrammes de classes_______________________________________________________
III.1.3) diagrammes d'objets ________________________________________________________
III.1.4) diagrammes de composants ___________________________________________________
III.1.5) diagrammes de déploiement __________________________________________________

24
30
43
44
44

III.2) Vues dynamiques du système : ___________________________________________ 45
III.2.1) diagrammes de collaboration __________________________________________________
III.2.2) diagrammes de séquence _____________________________________________________
III.2.3) diagrammes d'états-transitions_________________________________________________
III.2.4) diagrammes d'activités_______________________________________________________

45
47
54
56

IV) Le processus unifié ___________________________________________________ 58
IV.1) Le processus unifié est piloté par les cas d’utilisation_________________________ 58
COURS UML13.doc – Mars 2005

J.STEFFE – ENITA de Bordeaux

IV.1.1) Présentation générale________________________________________________________ 58
IV.1.2) Stratégie des cas d’utilisation _________________________________________________ 58

IV.2) Le processus unifié est centré sur l’architecture _____________________________ 60
IV.2.1) Liens entre cas d’utilisation et architecture _______________________________________ 60
IV.2.2) Marche à suivre ____________________________________________________________ 60

IV.3) Le processus unifié est itératif et incrémental _______________________________ 61
IV.4) Le cycle de vie du processus unifié ________________________________________ 62
IV.5) Conclusion : un processus intégré ________________________________________ 64

V) Eléments de comparaisons entre MERISE et UML __________________________ 65
V.1) Les principes __________________________________________________________ 65
V.1.1) L’approche systémique _______________________________________________________
V.1.2) Les cycles de construction du système d’information _______________________________
V.1.3) L’approche fonctionnelle _____________________________________________________
V.1.4) La séparation données-traitements ______________________________________________
V.1.5) L’ approche qui part du général vers le particulier __________________________________

65
65
66
67
67

V.2) La modélisation métier __________________________________________________ 67
V.2.1) Le domaine ________________________________________________________________
V.2.2) L’acteur___________________________________________________________________
V.2.3) Les flux ___________________________________________________________________
V.2.4) Les modèles conceptuels et organisationnels ______________________________________

67
67
68
68

V.3) La démarche___________________________________________________________ 71
V.3.1) Les modèles utilisés _________________________________________________________ 71
V.3.2) les étapes du processus d’élaboration du système d’information _______________________ 72

V.4) Conclusion ____________________________________________________________ 72

CONCLUSION GENERALE ______________________________________________ 73

COURS UML13.doc – Mars 2005

J.STEFFE – ENITA de Bordeaux

TABLE DES MATIERES

INTRODUCTION ________________________________________________________ 1
UML est une norme __________________________________________________________ 3
UML est un langage de modélisation objet._______________________________________ 3
UML est un support de communication _________________________________________ 4
UML est un cadre méthodologique pour une analyse objet__________________________ 5
UML n'est pas une méthode _______________________________________________________ 6
Conclusion ____________________________________________________________________ 6

I). Le contexte d’apparition d’UML __________________________________________ 8
I.1) Approche fonctionnelle versus approche objet ________________________________ 8
I.1.1) L’approche fonctionnelle _______________________________________________________ 8
La découpe fonctionnelle d'un problème informatique : une approche intuitive _______________ 8
La réutilisabilité du code__________________________________________________________ 8
Le revers de la médaille : maintenance complexe en cas d'évolution ________________________ 8
Problèmes générés par la séparation des données et des traitements : _______________________ 8
1ère amélioration : rassembler les valeurs qui caractérisent un type, dans le type _______________ 9
2ème amélioration : centraliser les traitements associés à un type, auprès du type______________ 9
I.1.2) L’approche objet ____________________________________________________________ 10
Le concept d’objet______________________________________________________________ 10
Les autres concepts importants de l'approche objet. ____________________________________ 11
l’encapsulation____________________________________________________________ 11
l’héritage ________________________________________________________________ 11
le polymorphisme _________________________________________________________ 11
l’agrégation ______________________________________________________________ 12
Historique de l’approche objet ____________________________________________________ 13
Inconvénients de l’approche objet__________________________________________________ 13
Solutions pour remédier aux inconvénients de l’approche objet___________________________ 13

I.2) La genèse d’UML _______________________________________________________ 14
I.2.1) Historique des méthodes d’analyse ______________________________________________
Les premières méthodes d'analyse (années 70) ________________________________________
L'approche systémique (années 80)_________________________________________________
L'émergence des méthodes objet (1990-1995) ________________________________________
Les premiers consensus (1995) ____________________________________________________
L'unification et la normalisation des méthodes (1995-1997) _____________________________
I.2.2) Cadre d’utilisation d’UML _____________________________________________________
UML n'est pas une méthode ou un processus _________________________________________
UML est un langage de modélisation _______________________________________________
UML décrit un méta modèle ______________________________________________________
UML est un support de communication _____________________________________________
I.2.3) Points forts d’UML __________________________________________________________
UML est un langage formel et normalisé ____________________________________________
UML est un support de communication performant ____________________________________
I.2.4) Points faibles d’UML _________________________________________________________
La mise en pratique d'UML nécessite un apprentissage et passe par une période d'adaptation. ___
Le processus (non couvert par UML) est une autre clé de la réussite d'un projet. _____________

14
14
14
14
14
14
15
15
16
16
16
16
16
17
17
17
17

II) Démarche générale de modélisation avec UML _____________________________ 18
II.1) Qu'est-ce qu'un modèle ? ________________________________________________ 18
II.1.1) Définition d’un modèle _______________________________________________________ 18
II.1.2) Caractéristiques fondamentales des modèles ______________________________________ 18

COURS UML13.doc – Mars 2005

J.STEFFE – ENITA de Bordeaux

II.2 ) Comment modéliser avec UML ? _________________________________________ 18
II.2.1) Proposition de démarche______________________________________________________
Une démarche itérative et incrémentale _____________________________________________
Une démarche pilotée par les besoins des utilisateurs___________________________________
Une démarche centrée sur l'architecture _____________________________________________
II.2.2) La vue « 4+1 » de ph. Kruchten ________________________________________________
La vue logique_________________________________________________________________
La vue des composants __________________________________________________________
La vue des processus____________________________________________________________
La vue de déploiement __________________________________________________________
La vue des cas d’utilisation _______________________________________________________
II.2.3) Les niveaux d’abstraction _____________________________________________________
Une non-démarcation entre conception et analyse _____________________________________
Les niveaux d’abstraction ________________________________________________________
Conceptualisation _________________________________________________________
Analyse du domaine _______________________________________________________
Analyse applicative ________________________________________________________
Conception_______________________________________________________________

18
19
19
19
20
20
20
21
21
21
21
21
22
22
22
22
22

II.4 ) L’utilisation de diagrammes _____________________________________________ 23
II.4.1) Définition d’un diagramme ____________________________________________________ 23
II.4.2) caractéristiques des diagrammes UML ___________________________________________ 23
II.4.3) Les différents types de diagrammes UML ________________________________________ 23

III) Les Différents types de diagrammes _____________________________________ 24
III.1) Vues statiques du système _______________________________________________ 24
III.1.1) diagrammes de cas d'utilisation ________________________________________________
Définition du cas d'utilisation (use case)_____________________________________________
Eléments de modélisation des cas d'utilisation ________________________________________
L’acteur : ________________________________________________________________
Le cas d’utilisation_________________________________________________________
La relation _______________________________________________________________
La relation de généralisation _________________________________________________
La relation d’inclusion______________________________________________________
La relation d’extension _____________________________________________________
Paquetage________________________________________________________________
Exemple de cas d’utilisation _________________________________________________
Elaboration des cas d'utilisation ___________________________________________________
Utilisation des cas d'utilisation ____________________________________________________
III.1.2) diagrammes de classes_______________________________________________________
Définition du diagramme de classes ________________________________________________
Les notions utilisées par le diagramme de classes______________________________________
La notion de classe ________________________________________________________
La notion d’attribut ________________________________________________________
La notion d’identifiant ______________________________________________________
La notion d’opération ______________________________________________________
La notion de relation _______________________________________________________
L’association _____________________________________________________________
La généralisation / spécialisation______________________________________________
La dépendance ____________________________________________________________
L’interface _______________________________________________________________
Les scénarios _____________________________________________________________
Elaboration d’un diagramme de classes _____________________________________________
Généralités _______________________________________________________________
Règles d’élaboration _______________________________________________________
III.1.3) diagrammes d'objets ________________________________________________________
III.1.4) diagrammes de composants ___________________________________________________
III.1.5) diagrammes de déploiement __________________________________________________

24
24
24
24
25
26
26
27
28
28
29
30
30
30
30
31
31
32
32
33
33
34
37
40
42
29
43
43
43
43
44
44

III.2) Vues dynamiques du système : ___________________________________________ 45
III.2.1) diagrammes de collaboration __________________________________________________ 45

COURS UML13.doc – Mars 2005

J.STEFFE – ENITA de Bordeaux

Objectifs du diagramme de collaboration ____________________________________________
Les interactions ________________________________________________________________
Les messages__________________________________________________________________
III.2.2) diagrammes de séquence _____________________________________________________
Les interactions ________________________________________________________________
Les activations_________________________________________________________________
Les catégories de message _______________________________________________________
Les messages réflexifs___________________________________________________________
Les contraintes temporelles_______________________________________________________
La ligne de vie_________________________________________________________________
III.2.3) diagrammes d'états-transitions_________________________________________________
Caractéristiques et règles de construction ____________________________________________
Etat_____________________________________________________________________
Evénements et transitions ___________________________________________________
Les traitements____________________________________________________________
La hiérarchie des états ______________________________________________________
Les états prédéfinis ________________________________________________________
III.2.4) diagrammes d'activités_______________________________________________________
Le déroulement séquentiel des activités _____________________________________________
La synchronisation _____________________________________________________________
Les couloirs d'activités __________________________________________________________

45
45
46
47
48
48
49
51
52
52
54
54
54
54
55
55
55
56
56
56
57

IV) Eléments de comparaisons entre MERISE et UML _________________________ 58
IV.1) Les principes__________________________________________________________ 65
IV.1.1) L’approche systémique ______________________________________________________
IV.1.2) Les cycles de construction du système d’information _______________________________
Le cycle de vie ________________________________________________________________
Le cycle d’abstraction ___________________________________________________________
Le cycle de décision ____________________________________________________________
IV.1.3) L’approche fonctionnelle_____________________________________________________
IV.1.4) La séparation données-traitements _____________________________________________
IV.1.5) L’ approche qui part du général vers le particulier _________________________________

65
65
66
66
66
66
67
67

IV.2) La modélisation métier _________________________________________________ 67
IV.2.1) Le domaine _______________________________________________________________
IV.2.2) L’acteur __________________________________________________________________
IV.2.3) Les flux __________________________________________________________________
IV.2.4) Les modèles conceptuels et organisationnels _____________________________________
Les modèles conceptuels_________________________________________________________
Le modèle conceptuel des données ____________________________________________
Le concept de propriété _____________________________________________________
Le concept d’entité ________________________________________________________
Le concept d’association ____________________________________________________
La normalisation du modèle _________________________________________________
Le modèle conceptuel des traitements __________________________________________
Les événements ___________________________________________________________
Les opérations ____________________________________________________________
La synchronisation_________________________________________________________
Les modèles organisationnels _____________________________________________________
Le modèle organisationnel des traitements ______________________________________
Le modèle organisationnel des données ________________________________________

67
67
68
68
68
68
68
68
69
69
70
70
70
70
70
70
71

IV.3) La démarche __________________________________________________________ 71
IV.3.1) Les modèles utilisés_________________________________________________________ 71
IV.3.2) les étapes du processus d’élaboration du système d’information ______________________ 72

IV.4) Conclusion____________________________________________________________ 72

CONCLUSION GENERALE ______________________________________________ 73

COURS UML13.doc – Mars 2005

J.STEFFE – ENITA de Bordeaux

INTRODUCTION
Pour faire face à la complexité croissante des systèmes d’information, de nouvelles
méthodes et outils ont été créées. La principale avancée des quinze dernières années réside
dans la programmation orientée objet (P.O.O.).
Face à ce nouveau mode de programmation, les méthodes de modélisation classique
(telle MERISE) ont rapidement montré certaines limites et ont dû s’adapter (cf.
MERISE/2).
De très nombreuses méthodes ont également vu le jour comme Booch, OMT …
Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception
« orientée objet », l’Object Management Group (OMG) a eu comme objectif de définir une
notation standard utilisable dans les développements informatiques basés sur l’objet. C’est
ainsi qu’est apparu UML (Unified Modified Language « langage de modélisation objet
unifié »), qui est issu de la fusion des méthodes Booch, OMT (Object Modelling
Technique) et OOSE (Object Oriented Software Engineering).
Issu du terrain et fruit d'un travail d'experts reconnus, UML est le résultat d'un large
consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à
son développement.
En l'espace d'une poignée d'années seulement, UML est devenu un standard
incontournable.
Ceci nous amène à nous questionner sur :
- les apports réels d’UML dans la modélisation
- la place des méthodes dites « traditionnelles » telle que MERISE.
UML est en effet apparu très tardivement, car l’approche objet se pratique depuis de
très nombreuses années déjà.
Simula, premier langage de programmation à implémenter le concept de type abstrait
à l'aide de classes, date de 1967 ! En 1976 déjà, Smalltalk implémente les concepts
fondateurs de l'approche objet : encapsulation, agrégation, héritage. Les premiers
compilateurs C++ datent du début des années 80 et de nombreux langages orientés objets
"académiques" ont étayé les concepts objets (Eiffel, Objective C, Loops...).
Il y donc déjà longtemps que l'approche objet est devenue une réalité. Les concepts
de base de l'approche objet sont stables et largement éprouvés. De nos jours, programmer
"objet", c'est bénéficier d'une panoplie d'outils et de langages performants. L'approche
objet est une solution technologique incontournable. Ce n'est plus une mode, mais un
réflexe quasi-automatique dès lors qu'on cherche à concevoir des logiciels complexes qui
doivent "résister" à des évolutions incessantes.
Toutefois, l’approche objet n’est pas une panacée :
- elle est moins intuitive que l'approche fonctionnelle.
Malgré les apparences, il est plus naturel pour l'esprit humain de décomposer un
problème informatique sous forme d'une hiérarchie de fonctions atomiques et de données,
qu'en terme d'objets et d'interaction entre ces objets.
Or, rien dans les concepts de base de l'approche objet ne dicte comment modéliser la
structure objet d'un système de manière pertinente. Quels moyens doit-on alors utiliser

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

1

pour mener une analyse qui respecte les concepts objet ? Sans un cadre méthodologique
approprié, la dérive fonctionnelle de la conception est inévitable...
- l'application des concepts objet nécessite une très grande rigueur.
Le vocabulaire précis est un facteur d'échec important dans la mise en oeuvre d'une
approche objet (risques d'ambiguïtés et d'incompréhensions). Beaucoup de développeurs
(même expérimentés) ne pensent souvent objet qu'à travers un langage de programmation.
Or, les langages orientés objet ne sont que des outils qui proposent une manière
particulière d'implémenter certains concepts objet. Ils ne valident en rien l'utilisation de ces
moyens techniques pour concevoir un système conforme à la philosophie objet.
Connaître C++ ou Java n'est donc pas une fin en soi, il faut aussi savoir se servir de
ces langages à bon escient. La question est donc de savoir "qui va nous guider dans
l'utilisation des concepts objet, si ce ne sont pas les langages orientés objet ?".
Enfin, comment comparer deux solutions de découpe objet d'un système si l'on ne
dispose pas d'un moyen de représentation adéquat ? Il est très simple de décrire le résultat
d'une analyse fonctionnelle, mais qu'en est-il d'une découpe objet ?

Pour remédier à ces inconvénients majeurs de l'approche objet, il faut donc :
1) un langage (pour s'exprimer clairement à l'aide des concepts objets)
Le langage doit permettre de représenter des concepts abstraits (graphiquement par
exemple), limiter les ambiguïtés (parler un langage commun, au vocabulaire précis,
indépendant des langages orientés objet), faciliter l'analyse (simplifier la comparaison et
l'évaluation de solutions).
2) une démarche d'analyse et de conception objet
Une démarche d’analyse et de conception objet est nécessaire afin de ne pas effectuer une
analyse fonctionnelle et se contenter d'une implémentation objet, mais penser objet dès le
départ, définir les vues qui permettent de décrire tous les aspects d'un système avec des
concepts objets.
Il faut donc disposer d'un outil qui donne une dimension méthodologique à
l'approche objet et qui permette de mieux maîtriser sa richesse.
La prise de conscience de l'importance d'une méthode spécifiquement objet
("comment structurer un système sans centrer l'analyse uniquement sur les données ou
uniquement sur les traitements, mais sur les deux"), ne date pas d'hier. Plus de 50 méthodes
objet sont apparues durant le milieu des années 90 (Booch, Classe-Relation, Fusion,
HOOD, OMT, OOA, OOD, OOM, OOSE...). Aucune ne s'est réellement imposée.
L'absence de consensus sur une méthode d'analyse objet a longtemps freiné l'essor
des technologies objet. Ce n'est que récemment que les grands acteurs du monde
informatique ont pris conscience de ce problème. L'unification et la normalisation des
méthodes objet dominantes (OMT, Booch et OOSE) ne datent que de 1995. UML est le
fruit de cette fusion.
UML, ainsi que les méthodes dont il est issu, s'accordent sur un point : une analyse
objet passe par une modélisation objet.
Qu’est-ce qu’un modèle ?
Un modèle est une abstraction de la réalité. L'abstraction est un des piliers de
l'approche objet. Il s'agit d'un processus qui consiste à identifier les caractéristiques
intéressantes d'une entité en vue d'une utilisation précise. L'abstraction désigne aussi le

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

2

résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques essentielles d'une
entité, retenues par un observateur.
Un modèle est une vue subjective, mais pertinente de la réalité. Un modèle définit
une frontière entre la réalité et la perspective de l'observateur. Ce n'est pas "la réalité", mais
une vue très subjective de la réalité. Bien qu'un modèle ne représente pas une réalité
absolue, un modèle reflète des aspects importants de la réalité, il en donne donc une vue
juste et pertinente.
Le caractère abstrait d'un modèle doit notamment permettre de faciliter la
compréhension du système étudié. Il réduit la complexité du système étudié, permet de
simuler le système, le représente et reproduit ses comportements. Concrètement, un modèle
réduit (décompose) la réalité, dans le but de disposer d'éléments de travail exploitables par
des moyens mathématiques ou informatiques.
UML permet donc de modéliser une application selon une vision objet.
L’appréhension d’UML est complexe car UML est à la fois :
- une norme,
- un langage de modélisation objet,
- un support de communication,
- un cadre méthodologique.

UML est une norme
Fin 1997, UML est devenu une norme OMG (Object Management Group).
L'OMG est un organisme à but non lucratif, créé en 1989 à l'initiative de grandes
sociétés (HP, Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fédère plus
de 850 acteurs du monde informatique. Son rôle est de promouvoir des standards qui
garantissent l'interopérabilité entre applications orientées objet, développées sur des
réseaux hétérogènes.
L'OMG propose notamment l'architecture CORBA (Common Object Request Broker
Architecture), un modèle standard pour la construction d'applications à objets distribués
(répartis sur un réseau).
CORBA fait partie d'une vision globale de la construction d'applications réparties,
appelée OMA (Object Management Architecture) et définie par l'OMG. Sans rentrer dans
les détails, on peut résumer cette vision par la volonté de favoriser l'essor industriel des
technologies objet, en offrant un ensemble de solutions technologiques non
propriétaires, qui suppriment les clivages techniques.
UML a été adopté (normalisé) par l'OMG et intégré à l'OMA, car il participe à cette
vision et parce qu'il répond à la "philosophie" OMG.

UML est un langage de modélisation objet.
Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec des
concepts abstraits, indépendants des langages d'implémentation et des contraintes
purement techniques. Les langages de programmation ne sont pas un support d'analyse
adéquat pour "concevoir objet". Ils ne permettent pas de décrire des solutions en terme de
concepts abstraits et constituent un cadre trop rigide pour mener une analyse itérative.
Pour conduire une analyse objet cohérente, il ne faut pas directement penser en terme
de pointeurs, d'attributs et de tableaux, mais en terme d'association, de propriétés et de
cardinalités... Utiliser le langage de programmation comme support de conception ne

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

3

revient bien souvent qu'à juxtaposer de manière fonctionnelle un ensemble de mécanismes
d'implémentation, pour résoudre un problème qui nécessite en réalité une modélisation
objet.
L’approche objet nécessite une analyse réfléchie, qui passe par différentes phases
exploratoires.
Bien que raisonner en terme d'objets semble naturel, l'approche fonctionnelle reste la
plus intuitive pour nos esprits cartésiens... Voilà pourquoi il ne faut pas se contenter d'une
implémentation objet, mais se discipliner à "penser objet" au cours d'une phase d'analyse
préalable.
Toutes les dérives fonctionnelles de code objet ont pour origine le non respect des
concepts de base de l'approche objet (encapsulation...) ou une utilisation détournée de ces
concepts (héritage sans classification...). Ces dérives ne sont pas dues à de mauvaises
techniques de programmation ; la racine du mal est bien plus profonde : programmer en
C++ ou en Java n'implique pas forcément concevoir objet...
Les difficultés de mise en oeuvre d'une approche "réellement objet" ont engendré
bien souvent des déceptions, ce qui a longtemps constitué un obstacle important à l'essor
des technologies objet. Beaucoup ont cédé au leurre des langages de programmation
orientés objet et oublié que le code n'est qu'un "moyen". Le respect des concepts
fondamentaux de l'approche objet prime sur la manière dont on les implémente. Ne penser
qu'à travers un langage de programmation objet détourne de l'essentiel.
Pour sortir les technologies objet de cette impasse, l'OMG propose UML.
UML comble une lacune importante des technologies objet. Il permet
d'exprimer et d'élaborer des modèles objet, indépendamment de tout langage de
programmation. Il a été pensé pour servir de support à une analyse basée sur les concepts
objet.
UML est un langage formel, défini par un métamodèle.
Le métamodèle d'UML décrit de manière très précise tous les éléments de
modélisation (les concepts véhiculés et manipulés par le langage) et la sémantique de ces
éléments (leur définition et le sens de leur utilisation).
En d'autres termes : UML normalise les concepts objet.
Un métamodèle permet de limiter les ambiguïtés et encourage la construction
d'outils. Il permet aussi de classer les différents concepts du langage (selon leur niveau
d'abstraction ou leur domaine d'application) et expose ainsi clairement sa structure. Enfin,
on peut noter que le métamodèle d'UML est lui-même décrit par un méta-métamodèle de
manière standardisée, à l'aide de MOF (Meta Object Facility : norme OMG de description
des métamodèles).
Véritable clé de voûte de l'OMA, UML est donc un outil indispensable pour tous
ceux qui ont compris que programmer objet, c'est d'abord concevoir objet. UML n'est pas à
l'origine des concepts objets, mais il en constitue une étape majeure, car il unifie les
différentes approches et en donne une définition plus formelle.

UML est un support de communication
UML est avant tout un support de communication performant, qui facilite la
représentation et la compréhension de solutions objet.
Sa notation graphique permet d'exprimer visuellement une solution objet, ce qui
facilite la comparaison et l'évaluation de solutions.
L'aspect formel de sa notation limite les ambiguïtés et les incompréhensions.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

4

Son indépendance par rapport aux langages de programmation, aux domaines
d'application et aux processus, en font un langage universel.
La notation graphique d'UML n'est que le support du langage. La véritable force
d'UML, c'est qu'il repose sur un métamodèle. En d'autres termes : la puissance et l'intérêt
d'UML, c'est qu'il normalise la sémantique des concepts qu'il véhicule !
Qu'une association d'héritage entre deux classes soit représentée par une flèche
terminée par un triangle ou un cercle, n'a que peu d'importance par rapport au sens que cela
donne à votre modèle. La notation graphique est essentiellement guidée par des
considérations esthétiques, même si elle a été pensée dans ses moindres détails.
Par contre, utiliser une relation d'héritage, reflète l'intention de donner à votre modèle
un sens particulier. Un "bon" langage de modélisation doit permettre à n'importe qui de
déchiffrer cette intention de manière non équivoque. Il est donc primordial de s'accorder
sur la sémantique des éléments de modélisation, bien avant de s'intéresser à la manière de
les représenter.
Le métamodèle UML apporte une solution à ce problème fondamental.
UML est donc bien plus qu'un simple outil qui permet de "dessiner" des
représentations mentales... Il permet de parler un langage commun, normalisé mais
accessible, car visuel.

UML est un cadre méthodologique pour une analyse objet
Une autre caractéristique importante d'UML, est qu'il cadre l'analyse. UML permet
de représenter un système selon différentes vues complémentaires : les diagrammes. Un
diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du
modèle ; c'est une perspective du modèle.
Chaque type de diagramme UML possède une structure (les types des éléments de
modélisation qui le composent sont prédéfinis) et véhicule une sémantique précise (il offre
toujours la même vue d'un système).
Combinés, les différents types de diagrammes UML offrent une vue complète des
aspects statiques et dynamiques d'un système. Les diagrammes permettent donc d'inspecter
un modèle selon différentes perspectives et guident l'utilisation des éléments de
modélisation (les concepts objet), car ils possèdent une structure.
Une caractéristique importante des diagrammes UML, est qu'ils supportent
l'abstraction. Cela permet de mieux contrôler la complexité dans l'expression et
l'élaboration des solutions objet.
UML opte en effet pour l'élaboration des modèles, plutôt que pour une approche qui
impose une barrière stricte entre analyse et conception. Les modèles d'analyse et de
conception ne diffèrent que par leur niveau de détail, il n'y a pas de différence dans les
concepts utilisés. UML n'introduit pas d'éléments de modélisation propres à une activité
(analyse, conception...) ; le langage reste le même à tous les niveaux d'abstraction.
Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction.
L'élaboration encourage une approche non linéaire, les "retours en arrière" entre niveaux
d'abstraction différents sont facilités et la traçabilité entre modèles de niveaux différents est
assurée par l'unicité du langage.
UML favorise donc le prototypage, et c'est là une de ses forces. En effet, modéliser
une application n'est pas une activité linéaire. Il s'agit d'une tâche très complexe, qui
nécessite une approche itérative, car il est plus efficace de construire et valider par étapes,
ce qui est difficile à cerner et maîtriser.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

5

UML permet donc non seulement de représenter et de manipuler les concepts objet, il
sous-entend une démarche d'analyse qui permet de concevoir une solution objet de manière
itérative, grâce aux diagrammes, qui supportent l'abstraction.

UML n'est pas une méthode
UML est un langage qui permet de représenter des modèles, mais il ne définit pas le
processus d'élaboration des modèles. Qualifier UML de "méthode objet" n'est donc pas
tout à fait approprié.
Une méthode propose aussi un processus, qui régit notamment l'enchaînement des
activités de production d'une entreprise. Or UML n'a pas été pensé pour régir les activités
de l'entreprise.
Les auteurs d'UML sont tout à fait conscients de l'importance du processus, mais ce
sujet a été intentionnellement exclu des travaux de l'OMG. Comment prendre en compte
toutes les organisations et cultures d'entreprises ? Un processus est adapté (donc très lié) au
domaine d'activité de l'entreprise ; même s'il constitue un cadre général, il faut l'adapter au
contexte de l'entreprise. Bref, améliorer un processus est une discipline à part entière, c'est
un objectif qui dépasse très largement le cadre de l'OMA.
Cependant, même si pour l'OMG, l'acceptabilité industrielle de la modélisation objet
passe d'abord par la disponibilité d'un langage d'analyse objet performant et standard, les
auteurs d'UML préconisent d'utiliser une démarche :
guidée par les besoins des utilisateurs du système,
centrée sur l'architecture logicielle,
itérative et incrémentale.
D'après les auteurs d'UML, un processus de développement qui possède ces qualités
fondamentales "devrait" favoriser la réussite d'un projet.
Une source fréquente de malentendus sur UML a pour origine la faculté d'UML de
modéliser un processus, pour le documenter et l'optimiser par exemple. En fin de compte,
qu'est-ce qu'un processus ? Un ensemble d'activités coordonnées et régulées, en partie
ordonnées, dont le but est de créer un produit (matériel ou intellectuel). UML permet tout à
fait de modéliser les activités (c'est-à-dire la dynamique) d'un processus, de décrire le rôle
des acteurs du processus, la structure des éléments manipulés et produits, etc...
Une extension d'UML ("UML extension for business modeling") propose d'ailleurs
un certain nombre de stéréotypes standards (extensions du métamodèle) pour mieux
décrire les processus.
Le RUP ("Rational Unified Process"), processus de développement "clé en main",
proposé par Rational Software, est lui aussi modélisé (documenté) avec UML. Il offre un
cadre méthodologique générique qui repose sur UML et la suite d'outils Rational.

Conclusion
Comme UML n'impose pas de méthode de travail particulière, il peut être intégré à
n'importe quel processus de développement logiciel de manière transparente. UML est une
sorte de boîte à outils, qui permet d'améliorer progressivement vos méthodes de travail,
tout en préservant vos modes de fonctionnement.
Intégrer UML par étapes dans un processus, de manière pragmatique, est tout à fait
possible. La faculté d'UML de se fondre dans le processus courant, tout en véhiculant une
démarche méthodologique, facilite son intégration et limite de nombreux risques (rejet des
utilisateurs, coûts...).

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

6

Intégrer UML dans un processus ne signifie donc pas révolutionner ses méthodes de
travail, mais cela devrait être l’occasion de se remettre en question.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

7

I). Le contexte d’apparition d’UML
I.1) Approche fonctionnelle versus approche objet
I.1.1) L’approche fonctionnelle
La découpe fonctionnelle d'un problème informatique : une
approche intuitive
La découpe fonctionnelle d’un problème (sur laquelle reposent les langages de
programmation structurée) consiste à découper le problème en blocs indépendants. En ce
sens, elle présente un caractère intuitif fort.

La réutilisabilité du code
Le découpage d’un problème en blocs indépendants (fonctions et procédures) va permettre
aux programmeurs de réutiliser les fonctions déjà développées (à condition qu’elles soient
suffisamment génériques). La productivité se trouve donc accrue.

Le revers de la médaille : maintenance complexe en cas
d'évolution
Le découpage en blocs fonctionnels n'a malheureusement pas que des avantages. Les
fonctions sont devenues interdépendantes : une simple mise à jour du logiciel à un point
donné, peut impacter en cascade une multitude d'autres fonctions. On peut minorer cet
impact, pour peu qu'on utilise des fonctions plus génériques et des structures de données
ouvertes. Mais respecter ces contraintes rend l'écriture du logiciel et sa maintenance plus
complexe.
En cas d'évolution majeure du logiciel (passage de la gestion d'une bibliothèque à celle
d'une médiathèque par exemple), le scénario est encore pire. Même si la structure générale
du logiciel reste valide, la multiplication des points de maintenance, engendrée par le
chaînage des fonctions, rend l'adaptation très laborieuse. Le logiciel doit être retouché dans
sa globalité :
- on a de nouvelles données à gérer (ex : DVD)
- les traitements évoluent : l’affichage sera différent selon le type (livre, CD,
DVD …)

Problèmes générés par la séparation des données et des
traitements :
Examinons le problème de l'évolution de code fonctionnel plus en détail...
Faire évoluer une application de gestion de bibliothèque pour gérer une médiathèque, afin
de prendre en compte de nouveaux types d'ouvrages (cassettes vidéo, CD-ROM, etc...),
nécessite :
- de faire évoluer les structures de données qui sont manipulées par les fonctions,
COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

8

-

d'adapter les traitements, qui ne manipulaient à l'origine qu'un seul type de
document (des livres).
Il faudra donc modifier toutes les portions de code qui utilisent la base documentaire, pour
gérer les données et les actions propres aux différents types de documents.
Il faudra par exemple modifier la fonction qui réalise l'édition des "lettres de rappel" (une
lettre de rappel est une mise en demeure, qu'on envoie automatiquement aux personnes qui
tardent à rendre un ouvrage emprunté). Si l'on désire que le délai avant rappel varie selon
le type de document emprunté, il faut prévoir une règle de calcul pour chaque type de
document.
En fait, c'est la quasi-totalité de l'application qui devra être adaptée, pour gérer les
nouvelles données et réaliser les traitements correspondants. Et cela, à chaque fois qu'on
décidera de gérer un nouveau type de document !

1ère amélioration : rassembler les valeurs qui caractérisent un
type, dans le type
Une solution relativement élégante à la multiplication des branches conditionnelles et des
redondances dans le code (conséquence logique d'une trop grande ouverture des données),
consiste tout simplement à centraliser dans les structures de données, les valeurs qui leurs
sont propres.
Par exemple, le délai avant rappel peut être défini pour chaque type de document. Cela
permet donc de créer une fonction plus générique qui s’applique à tous les types de
documents.

2ème amélioration : centraliser les traitements associés à un type,
auprès du type
Pourquoi ne pas aussi rassembler dans une même unité physique les types de données et
tous les traitements associés ?
Que se passerait-il par exemple si l'on centralisait dans un même fichier, la structure de
données qui décrit les documents et la fonction de calcul du délai avant rappel ? Cela nous
permettrait de retrouver immédiatement la partie de code qui est chargée de calculer le
délai avant rappel d'un document, puisqu'elle se trouve au plus près de la structure de
données concernée.
Ainsi, si notre médiathèque devait gérer un nouveau type d'ouvrage, il suffirait de modifier
une seule fonction (qu'on sait retrouver instantanément), pour assurer la prise en compte de
ce nouveau type de document dans le calcul du délai avant rappel. Plus besoin de fouiller
partout dans le code...
Ecrit en ces termes, le logiciel serait plus facile à maintenir et bien plus lisible. Le stockage
et le calcul du délai avant rappel des documents, serait désormais assuré par une seule et
unique unité physique (quelques lignes de code, rapidement identifiables).
Pour accéder à la caractéristique "délai avant rappel" d'un document, il suffit de récupérer
la valeur correspondante parmi les champs qui décrivent le document. Pour assurer la prise
en compte d'un nouveau type de document dans le calcul du délai avant rappel, il suffit de

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

9

modifier une seule fonction, située au même endroit que la structure de données qui décrit
les documents.
Document
Code document
Nom document
Type document
Calculer date rappel

Centraliser les données d'un type et les traitements associés, dans une même unité
physique, permet de limiter les points de maintenance dans le code et facilite l'accès à
l'information en cas d'évolution du logiciel.

I.1.2) L’approche objet
Le concept d’objet
Les modifications qui ont été apportées au logiciel de gestion de médiathèque, nous ont
amené à transformer ce qui était à l'origine une structure de données, manipulée par des
fonctions, en une entité autonome, qui regroupe un ensemble de propriétés cohérentes et de
traitements associés. Une telle entité s'appelle... un objet et constitue le concept fondateur
de l'approche du même nom.
Un objet est une entité aux frontières précises qui possède une identité (un nom).
Un ensemble d'attributs caractérise l'état de l'objet.
Un ensemble d'opérations (méthodes) en définissent le comportement.
Un objet est une instance de classe (une occurrence d'un type abstrait).
Une classe est un type de données abstrait, caractérisé par des propriétés (attributs et
méthodes) communes à des objets et permettant de créer des objets possédant ces
propriétés.

Docum ent
+ code docum ent : int
+ nom docum ent : String
+ T ype docum ent : String
+ Calculer date rappel () : Date
Classe : regroupement d’objets

MERISE_UML_document
C1
De Merise vers UML
Support de cours

Objet : instance d’une classe

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

10

Les autres concepts importants de l'approche objet.
l’encapsulation
L’encapsulation consiste à masquer les détails d'implémentation d'un objet, en définissant
une interface.
L'interface est la vue externe d'un objet, elle définit les services accessibles (offerts) aux
utilisateurs de l'objet.
L'encapsulation facilite l'évolution d'une application car elle stabilise l'utilisation des
objets : on peut modifier l'implémentation des attributs d'un objet sans modifier son
interface.
L'encapsulation garantit l'intégrité des données, car elle permet d'interdire l'accès direct aux
attributs des objets.

l’héritage
L'héritage est un mécanisme de transmission des propriétés d'une classe (ses attributs et
méthodes) vers une sous-classe.
Une classe peut être spécialisée en d'autres classes, afin d'y ajouter des caractéristiques
spécifiques ou d'en adapter certaines.
Plusieurs classes peuvent être généralisées en une classe qui les factorise, afin de regrouper
les caractéristiques communes d'un ensemble de classes.
La spécialisation et la généralisation permettent de construire des hiérarchies de classes.
L'héritage peut être simple ou multiple.
L'héritage évite la duplication et encourage la réutilisation.
Oeuvre
T itre
Auteur

Heritage_2

Heritage_1
Film

Livre

Heritage_3
Roman

Heritage_4
BD

le polymorphisme
Le polymorphisme représente la faculté d'une même opération de s'exécuter différemment
suivant le contexte de la classe où elle se trouve.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

11

Ainsi, une opération définie dans une superclasse peut s'exécuter de façon différente selon
la sous-classe où elle est héritée.
Ex : exécution d'une opération de calcul des salaires dans 2 sous-classes spécialisées : une
pour les cadres, l'autre pour les non-cadres.
Le polymorphisme augmente la généricité du code.
Oeuvre
Titre
Auteur

Heritage_1

Heritage_2

Film

Livre

Dupliquer sur support()
{
papier
}

Dupliquer sur support()
{
magnétique
}

l’agrégation
Il s'agit d'une relation entre deux classes, spécifiant que les objets d'une classe sont des
composants de l'autre classe.
Une relation d'agrégation permet donc de définir des objets composés d'autres objets.
L'agrégation permet d'assembler des objets de base, afin de construire des objets plus
complexes.
Eau : molécule
Hygrogène : atome

Hygrogène : atome
Oxygène : atome

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

12

Historique de l’approche objet
Les concepts objet sont stables et éprouvés (issus du terrain) :
- Simula, 1er langage de programmation à implémenter le concept de type abstrait
(à l'aide de classes), date de 1967 !
- En 1976 déjà, Smalltalk implémente les concepts fondateurs de l'approche objet
(encapsulation, agrégation, héritage) à l'aide de :
o classes
o associations entre classes
o hiérarchies de classes
o messages entre objets
- Le 1er compilateur C++ date de 1980, et C++ est normalisé par l'ANSI.
- De nombreux langages orientés objets académiques ont étayés les concepts
objets : Eiffel, Objective C, Loops…
Les concepts objet sont anciens, mais ils n'ont jamais été autant d'actualité :
- L'approche fonctionnelle n'est pas adaptée au développement d'applications qui
évoluent sans cesse et dont la complexité croit continuellement.
- L'approche objet a été inventée pour faciliter l'évolution d'applications
complexes.
De nos jours, les outils orientés objet sont fiables et performants
- Les compilateurs C++ produisent un code robuste et optimisé.
- De très nombreux outils facilitent le développement d'applications C++ :
o bibliothèques (STL, USL, Rogue Wave, MFC...)
o environnements de développement intégrés (Developper Studio,
Sniff+...)
o outils de qualimétrie et de tests (Cantata++, Insure++, Logiscope...)
o bases de données orientées objet (O2, ObjectStore, Versant...)

Inconvénients de l’approche objet
L'approche objet est moins intuitive que l'approche fonctionnelle.
L'application des concepts objets nécessite une grande rigueur : le vocabulaire est précis
(risques d'ambiguïtés, d'incompréhensions).

Solutions pour remédier aux inconvénients de l’approche objet
Il faut bénéficier d’un langage pour exprimer les concepts objet qu'on utilise, afin de
pouvoir :
- représenter des concepts abstraits (graphiquement par exemple).
- limiter les ambiguïtés (parler un langage commun).
- faciliter l'analyse (simplifier la comparaison et l'évaluation de solutions).
Il faut également une démarche d'analyse et de conception objet, pour :
- ne pas effectuer une analyse fonctionnelle et se contenter d'une implémentation
objet, mais penser objet dès le départ.
- définir les vues qui permettent de couvrir tous les aspects d'un système, avec
des concepts objets.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

13

I.2) La genèse d’UML
I.2.1) Historique des méthodes d’analyse
Les premières méthodes d'analyse (années 70)
Découpe cartésienne (fonctionnelle et hiérarchique) d'un système.

L'approche systémique (années 80)
Modélisation des données + modélisation des traitements (Merise ...).

L'émergence des méthodes objet (1990-1995)
Prise de conscience de l'importance d'une méthode spécifiquement objet :
- comment structurer un système sans centrer l'analyse uniquement sur les
données ou uniquement sur les traitements (mais sur les deux) ?
- Plus de 50 méthodes objet sont apparues durant cette période (Booch, ClasseRelation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) !
- Aucun méthode ne s'est réellement imposée.

Les premiers consensus (1995)
-

-

-

OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un
système
o issue du centre de R&D de General Electric.
o Notation graphique riche et lisible.
OOD (Grady Booch) : vues logiques et physiques du système
o Définie pour le DOD, afin de rationaliser de développement
d'applications ADA, puis C++.
o Ne couvre pas la phase d'analyse dans ses 1ères versions (préconise
SADT).
o Introduit le concept de package (élément d'organisation des modèles).
OOSE (Ivar Jacobson) : couvre tout le cycle de développement
o Issue d'un centre de développement d'Ericsson, en Suède.
o La méthodologie repose sur l'analyse des besoins des utilisateurs.

L'unification et la normalisation des méthodes (1995-1997)
En octobre 1994, G. Booch (père fondateur de la méthode Booch) et J. Rumbaugh
(principal auteur de la méthode OMT) ont décidé de travailler ensemble pour unifier leurs
méthodes au sein de la société Rational Software. Un an après, I . Jacobson (auteur de la
méthode OOSE et des cas d’utilisation) a rejoint Rational Software pour travailler sur
l’unification. Unified Modified Language (UML) est né.
Les travaux sur ce langage ont continué avec son adoption par de grands acteurs industriels
comme HP, Microsoft, Oracle ou Unisys. Ce travail a abouti en 1997 à UML 1.0. Le
langage a été soumis par Rational Software et ses partenaires à l’OMG comme réponse à
un appel d’offres sur la standardisation des langages de modélisation.
L’appel d’offres de l’OMG a recueilli un avis favorable, puisque 6 réponses concurrentes
sont parvenues à l’OMG. IBM et Object Time (méthode ROOM pour les systèmes temps
réel réactifs) ont décidé de rejoindre l’équipe UML ; leur proposition était en fait une
extension d’UML 1.0.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

14

Certains autres auteurs qui ont répondu à l’appel d’offres ont abandonné leur proposition
pour rejoindre à leur tour UML. En novembre 1997, UML a été adopté par l’OMG.
Autres méthodes

Booch 91

1993

Booch 93

1995

OMT 1

OOSE

OMT 2

Unified method 0,8

1996

UML 0.9

soumis à l'OMG
jan 1997

UML 1.0

adopté par l'OMG
Nov 1997

Partenaires : IBM, HP,
Microsoft, Oracle

UML 1.1

UML est donc le résultat d’un large consensus et tient compte des dernières avancées en
matière de modélisation et de développement logiciel.
L'OMG RTF (nombreux acteurs industriels) centralise et normalise les évolutions d'UML
au niveau international et de nombreux groupes d'utilisateurs UML favorisent le partage
des expériences.

I.2.2) Cadre d’utilisation d’UML
UML n'est pas une méthode ou un processus
Si l'on parle de méthode objet pour UML, c'est par abus de langage.
Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modélisation.
Une méthode propose aussi un processus, qui régit notamment l'enchaînement des activités
de production d'une entreprise. Or, UML a été pensé pour permettre de modéliser les
activités de l'entreprise, pas pour les régir.
Des méthodes orientées objet les plus connues, seules les méthodes OOSE et BOOCH
incluent cet aspect « processus » de manière explicite et formelle. Ces 2 auteurs se sont
d’ailleurs toujours démarqués des autres sur ce point.
Par leur nature, les processus doivent être adaptés aux organisations, à leurs domaines
d’activité, à leur culture …
De ce fait, ni la normalisation ni la standardisation d’un processus de développement
logiciel ne peut faire l’objet d’un consensus international suffisant pour aboutir à un
standard acceptable et utilisable.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

15

UML est un langage de modélisation
UML est un langage de modélisation au sens de la théorie des langages. Il contient de ce
fait les éléments constitutifs de tout langage, à savoir : des concepts, une syntaxe et une
sémantique.
De plus, UML a choisi une notation supplémentaire : il s’agit d’une forme visuelle fondée
sur des diagrammes. Si l’unification d’une notation est secondaire par rapports aux
éléments constituant le langage, elle reste cependant primordiale pour la communication et
la compréhension.

UML décrit un méta modèle
UML est fondé sur un métamodèle, qui définit :
- les éléments de modélisation (les concepts manipulés par le langage),
- la sémantique de ces éléments (leur définition et le sens de leur utilisation).
Un métamodèle est une description très formelle de tous les concepts d'un langage. Il
limite les ambiguïtés et encourage la construction d'outils.
Le métamodèle d'UML permet de classer les concepts du langage (selon leur niveau
d'abstraction ou domaine d'application) et expose sa structure.
Le métamodèle UML est lui-même décrit par un méta-métamodèle (OMG-MOF).
UML propose aussi une notation, qui permet de représenter graphiquement les éléments de
modélisation du métamodèle.
Cette notation graphique est le support du langage UML.
UML offre :
- différentes vues (perspectives) complémentaires d'un système, qui guident
l'utilisation des concept objets
- plusieurs niveaux d'abstraction, qui permettent de mieux contrôler la complexité
dans l'expression des solutions objets.

UML est un support de communication
Sa notation graphique permet d'exprimer visuellement une solution objet.
L'aspect formel de sa notation limite les ambiguïtés et les incompréhensions.
Son aspect visuel facilite la comparaison et l'évaluation de solutions.
Son indépendance (par rapport aux langages d'implémentation, domaine d'application,
processus...) en font un langage universel.

I.2.3) Points forts d’UML
UML est un langage formel et normalisé
Il permet ainsi :
- un gain de précision
- un gage de stabilité
- l'utilisation d'outils

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

16

UML est un support de communication performant
Il cadre l'analyse et facilite la compréhension de représentations abstraites complexes. Son
caractère polyvalent et sa souplesse en font un langage universel.

I.2.4) Points faibles d’UML
La mise en pratique d'UML nécessite un apprentissage et passe
par une période d'adaptation.
Même si l'Espéranto est une utopie, la nécessité de s'accorder sur des modes d'expression
communs est vitale en informatique. UML n 'est pas à l'origine des concepts objets, mais
en constitue une étape majeure, car il unifie les différentes approches et en donne une
définition plus formelle.

Le processus (non couvert par UML) est une autre clé de la
réussite d'un projet.
L'intégration d'UML dans un processus n'est pas triviale et améliorer un processus est un
tâche complexe et longue.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

17

II) Démarche générale de modélisation avec UML
II.1) Qu'est-ce qu'un modèle ?
II.1.1) Définition d’un modèle
Un modèle est une abstraction de la réalité
L'abstraction est un des piliers de l'approche objet : il s'agit d'un processus qui
consiste à identifier les caractéristiques intéressantes d'une entité, en vue d'une utilisation
précise.
L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des
caractéristiques essentielles d'une entité, retenues par un observateur.
Un modèle est une vue subjective mais pertinente de la réalité. Un modèle définit une
frontière entre la réalité et la perspective de l'observateur. Ce n'est pas "la réalité", mais une
vue très subjective de la réalité.
Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des
aspects importants de la réalité, il en donne donc une vue juste et pertinente.

II.1.2) Caractéristiques fondamentales des modèles
Le caractère abstrait d'un modèle doit notamment permettre :
- de faciliter la compréhension du système étudié : un modèle réduit la
complexité du système étudié.
- de simuler le système étudié : un modèle représente le système étudié et
reproduit ses comportements.

II.2 ) Comment modéliser avec UML ?
II.2.1) Proposition de démarche
UML est un langage qui permet de représenter des modèles, mais il ne définit pas le
processus d'élaboration des modèles : UML n’est donc pas une méthode de modélisation.
Cependant, dans le cadre de la modélisation d'une application informatique, les auteurs
d'UML préconisent d'utiliser une démarche :
- itérative et incrémentale,
- guidée par les besoins des utilisateurs du système,
- centrée sur l'architecture logicielle.
D'après les auteurs d'UML, un processus de développement qui possède ces qualités
devrait favoriser la réussite d'un projet.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

18

Une démarche itérative et incrémentale
Pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y
prendre en plusieurs fois, en affinant son analyse par étapes.
Cette démarche doit aussi s'appliquer au cycle de développement dans son ensemble, en
favorisant le prototypage.
Le but est de mieux maîtriser la part d'inconnu et d'incertitudes qui caractérisent les
systèmes complexes.

Une démarche pilotée par les besoins des utilisateurs
Avec UML, ce sont les utilisateurs qui guident la définition des modèles :
Le périmètre du système à modéliser est défini par les besoins des utilisateurs (les
utilisateurs définissent ce que doit être le système). Le but du système à modéliser est de
répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système).
Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de
développement (itératif et incrémental) :
- à chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins
des utilisateurs.
- à chaque itération de la phase de conception et de réalisation, on veille à la prise
en compte des besoins des utilisateurs.
- à chaque itération de la phase de test, on vérifie que les besoins des utilisateurs
sont satisfaits.

Une démarche centrée sur l'architecture
Une architecture adaptée est la clé de voûte du succès d'un développement.
Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du
logiciel (adaptabilité, performances, fiabilité...).
Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires,
qui permettent de définir un modèle d'architecture (publication IEEE, 1995). Ph. Kruchten
défend l’idée que l’architecture logicielle doit être une discipline à part entière. Il propose
que plusieurs perspectives concourent à l’expression de l’architecture d’un système et il
explique qu’il est nécessaire de garantir la séparation et l’indépendance de ces différentes
perspectives. L’évolution de l’une des perspectives ne doit pas avoir d’impact (sinon
limité) sur les autres.
La relation entre les différentes perspectives a été représentée par ph. Kruchten dans
le schéma suivant, dit « schéma 4+1 vues ».

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

19

Vue
logique

Vue des
composants
Vue des cas d'utilisation

Vue des
processus

Vue de
déploiement

II.2.2) La vue « 4+1 » de ph. Kruchten
La vue logique
Cette vue concerne « l’intégrité de conception ».
Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation, elle modélise les
éléments et mécanismes principaux du système.
Elle identifie les éléments du domaine, ainsi que les relations et interactions entre ces
éléments « notions de classes et de relations » :
- les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
- ils sont indispensables à la mission du système,
- ils gagnent à être réutilisés (ils représentent un savoir-faire).
Cette vue organise aussi (selon des critères purement logiques), les éléments du domaine
en "catégories" :
- pour répartir les tâches dans les équipes,
- regrouper ce qui peut être générique,
- isoler ce qui est propre à une version donnée, etc...

La vue des composants
Cette vue concerne « l’intégrité de gestion ».
Elle exprime la perspective physique de l’organisation du code en termes de modules, de
composants et surtout des concepts du langage ou de l’environnement d’implémentation.
Dans cette perspective, l’architecte est surtout concerné par les aspects de gestion du code,
d’ordre de compilation, de réutilisation, d’intégration et d’autres contraintes de
développement pur. Pour représenter cette perspective, UML fournit des concepts adaptés
tels que les modules, les composants, les relations de dépendance, l’interface …
Cette vue de bas niveau (aussi appelée « vue de réalisation »), montre ainsi :
- l'allocation des éléments de modélisation dans des modules (fichiers sources,
bibliothèques dynamiques, bases de données, exécutables, etc...). Cette vue
identifie les modules qui réalisent (physiquement) les classes de la vue logique.
- l'organisation des composants, c'est-à-dire la distribution du code en gestion de
configuration, les dépendances entre les composants...
- les contraintes de développement (bibliothèques externes...).
- l'organisation des modules en "sous-systèmes", les interfaces des sous-systèmes
et leurs dépendances (avec d'autres sous-systèmes ou modules).

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

20

La vue des processus
Cette vue concerne « l’intégrité d’exécution ».
Cette vue est très importante dans les environnements multitâches ; elle exprime la
perspective sur les activités concurrentes et parallèles. Elle montre ainsi :
- la décomposition du système en terme de processus (tâches).
- les interactions entre les processus (leur communication).
- la synchronisation et la communication des activités parallèles (threads).

La vue de déploiement
Cette vue concerne « l’intégrité de performance ». Elle exprime la répartition du système à
travers un réseau de calculateurs et de nœuds logiques de traitements . Cette vue est
particulièrement utile pour décrire la distribution d’un système réparti.
Elle montre :
- la disposition et nature physique des matériels, ainsi que leurs performances.
- l'implantation des modules principaux sur les nœuds du réseau.
- les exigences en terme de performances (temps de réponse, tolérance aux fautes
et pannes...).

La vue des cas d’utilisation
Cette vue est particulière en ce sens qu’elle guide toutes les autres.
Cette vue permet :
- de trouver le « bon » modèle
Les cas d’utilisation permettent de guider la modélisation. L’utilisation des scénarios et des
cas d’utilisation s’avère plus rigoureuse et plus systématique que les entretiens et l’analyse
des documents pour découvrir les abstractions du domaine.
- d’expliquer et de justifier ses choix
Il est en effet nécessaire d’expliquer le système, de justifier les choix qui ont guidé sa
conception et son fonctionnement pour pouvoir le construire, le maintenir et le tester. Pour
cela UML offre des concepts adaptés tels que les scénarios et les cas d’utilisation.

II.2.3) Les niveaux d’abstraction
Une non-démarcation entre conception et analyse
UML opte pour l'élaboration des modèles, plutôt que pour une approche qui impose une
barrière stricte entre analyse et conception :
- les modèles d'analyse et de conception ne diffèrent que par leur niveau de détail,
il n'y a pas de différence dans les concepts utilisés.
- UML n'introduit pas d'éléments de modélisation propres à une activité (analyse,
conception...) ; le langage reste le même à tous les niveaux d'abstraction.
Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction :
- l'élaboration encourage une approche non linéaire (les "retours en arrière" entre
niveaux d'abstraction différents sont facilités).
- la traçabilité entre modèles de niveaux différents est assurée par l'unicité du
langage.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

21

Les niveaux d’abstraction
Conceptualisation
L'entrée de l'analyse à ce niveau est le dossier d'expression des besoins client. A ce niveau
d'abstraction, on doit capturer les besoins principaux des utilisateurs.
Il ne faut pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins.
Le but de la conceptualisation est :
- de définir le contour du système à modéliser (de spécifier le "quoi"),
- de capturer les fonctionnalités principales du système, afin d'en fournir une
meilleure compréhension (le modèle produit sert d'interface entre les acteurs du
projet),
- de fournir une base à la planification du projet.

Analyse du domaine
L'entrée de l'analyse à ce niveau, est le modèle des besoins clients (les "cas d'utilisation"
UML).
Il s'agit de modéliser les éléments et mécanismes principaux du système.
On identifie les éléments du domaine, ainsi que les relations et interactions entre ces
éléments :
- les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
- ils sont indispensables à la mission du système,
- ils gagnent à être réutilisés (ils représentent un savoir-faire).
A ce stade, on organise aussi (selon des critères purement logiques), les éléments du
domaine en "catégories", pour répartir les tâches dans les équipes, regrouper ce qui peut
être générique, etc...

Analyse applicative
A ce niveau, on modélise les aspects informatiques du système, sans pour autant rentrer
dans les détails d'implémentation.
Les interfaces des éléments de modélisation sont définis (cf. encapsulation). Les relations
entre les éléments des modèles sont définies.
Les éléments de modélisation utilisés peuvent être propres à une version du système.

Conception
On y modélise tous les rouages d'implémentation et on détaille tous les éléments de
modélisation issus des niveaux supérieurs.
Les modèles sont optimisés, car destinés à être implémentés.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

22

II.4 ) L’utilisation de diagrammes
UML permet de définir et de visualiser un modèle, à l'aide de diagrammes.

II.4.1) Définition d’un diagramme
Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du
modèle. C'est une perspective du modèle, pas "le modèle".
Chaque type de diagramme UML possède une structure (les types des éléments de
modélisation qui le composent sont prédéfinis).
Un type de diagramme UML véhicule une sémantique précise (un type de diagramme offre
toujours la même vue d'un système).
Combinés, les différents types de diagrammes UML offrent une vue complète des aspects
statiques et dynamiques d'un système.
Par extension et abus de langage, un diagramme UML est aussi un modèle (un diagramme
modélise un aspect du modèle global).

II.4.2) caractéristiques des diagrammes UML
Les diagrammes UML supportent l'abstraction. Leur niveau de détail caractérise le niveau
d'abstraction du modèle.
La structure des diagrammes UML et la notation graphique des éléments de modélisation
est normalisée (document "UML notation guide").
Rappel : la sémantique des éléments de modélisation et de leur utilisation est définie par le
métamodèle UML (document "UML semantics").

II.4.3) Les différents types de diagrammes UML
Il existe 2 types de vues du système qui comportent chacune leurs propres diagrammes :
- les vues statiques :
o diagrammes de cas d'utilisation
o diagrammes d'objets
o diagrammes de classes
o diagrammes de composants
o diagrammes de déploiement
- les vues dynamiques :
o diagrammes de collaboration
o diagrammes de séquence
o diagrammes d'états-transitions
o diagrammes d'activités

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

23

III) Les Différents types de diagrammes
III.1) Vues statiques du système
Le but de la conceptualisation 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.
Le modèle conceptuel joue un rôle central, il est capital de bien le définir.

III.1.1) diagrammes de cas d'utilisation
Définition du cas d'utilisation (use case)
Les use cases 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 partent du principe que les objectifs du système sont tous motivés.
La détermination et la compréhension des besoins sont souvent difficiles car les
intervenants sont noyés sous de trop grandes quantités d'informations : il faut clarifier et
organiser les besoins des clients (les modéliser). Pour cela, les cas d’utilisation identifient
les utilisateurs du système (acteurs) et leurs interactions avec le système. Ils permettent de
classer les acteurs et structurer les objectifs du système.
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.
Les use cases ne doivent donc en aucun cas décrire des solutions d'implémentation.
Leur but est justement d'éviter de tomber dans la dérive d'une approche fonctionnelle, où
l'on liste une litanie de fonctions que le système doit réaliser.

Eléments de modélisation des cas d'utilisation
L’acteur :
La première étape de modélisation consiste à définir le périmètre du système, à
définir le contour de l’organisation et à le modéliser. Toute entité qui est en dehors de cette
organisation et qui interagit avec elle est appelé acteur selon UML.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

24

Un acteur est un type stéréotypé représentant une abstraction qui réside juste en
dehors du système à modéliser.
Un acteur représente un rôle joué par une personne ou une chose qui interagit avec le
système. (la même personne physique peut donc être représentée par plusieurs acteurs en
fonction des rôles qu’elle joue).
Pour identifier les acteurs, il faut donc se concentrer sur les rôles joués par les entités
extérieures au périmètre.
Dans UML, il n’y a pas de notion d’acteur interne et externe. Par définition, un acteur
est externe au périmètre de l’étude, qu’il appartienne ou pas à la société.
Enfin, un acteur n’est pas nécessairement une personne physique : il peut être un
service, une société, un système informatique …
Il existe 4 catégories d’acteurs :
- les acteurs principaux : les personnes qui utilisent les fonctions principales du
système
- les acteurs secondaires : les personnes qui effectuent des tâches administratives
ou de maintenance.
- le matériel externe : les dispositifs matériels incontournables qui font partie du
domaine de l’application et qui doivent être utilisés.
- les autres systèmes : les systèmes avec lesquels le système doit interagir.

Formalisme :

Nom acteur
Le cas d’utilisation
Le cas d’utilisation (ou use case) correspond à un objectif du système, motivé par un
besoin d’un ou plusieurs acteurs.
L'ensemble des use cases décrit les objectifs (le but) du système.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

25

Formalisme :
Nom d u use case

La relation
Elle exprime l’interaction existant entre un acteur et un cas d’utilisation.
Formalisme :

retirer argent

Prospect

Il existe 3 types de relations entre cas d’utilisation :
- la relation de généralisation
- la relation d’extension
- la relation d’inclusion

La relation de généralisation
Dans une relation de généralisation entre 2 cas d’utilisation, le cas d’utilisation enfant est
une spécialisation du cas d’utilisation parent.
Formalisme et exemple :

cas d'utilisation parent

cas d'utilisation enfant

Virement bancaire

virement par internet

NB : un acteur peut également participer à des relations de généralisation avec d’autres
acteurs. Les acteurs « enfant » seront alors capables de communiquer avec les mêmes cas
d’utilisation que les acteurs « parents ».

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

26

Formalisme et exemple :

retirer argent

Prospect

obtenir informations compte
Client agence

La relation d’inclusion
Elle indique que le cas d’utilisation source contient aussi le comportement décrit dans le
cas d’utilisation destination. L’inclusion a un caractère obligatoire, la source spécifiant à
quel endroit le cas d’utilisation cible doit être inclus. Cette relation permet ainsi de
décomposer des comportements et de définir des comportements partageables entre
plusieurs cas d’utilisation.
Formalisme :

Virement

<<include>>

Identification

Pour réaliser l’objectif « virement », on utilise obligatoirement « identification ».

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

27

La relation d’extension
Elle indique que le cas d’utilisation source ajoute son comportement au cas d’utilisation
destination. L’extension peut être soumise à condition. Le comportement ajouté est inséré
au niveau d’un point d’extension défini dans le cas d’utilisation destination. Cette relation
permet de modéliser les variantes de comportement d’un cas d’utilisation (selon les
interactions des acteurs et l’environnement du système).

Formalisme :

Cas d'utilisation source

<<extend>>

Cas d'utilisation destination

Exemple :
Virement

<<extend>>

Vérification solde compte

Paquetage
Un paquetage (package) est un groupement d’élément de modélisation. Un paquetage peut
contenir aussi bien des paquetages emboîtés que des éléments de modélisation ordinaires.
Le système entier peut être pensé comme un unique paquetage de haut niveau comprenant
l’ensemble. Tous les éléments de modélisation d’UML, y compris les diagrammes, peuvent
être organisés en paquetage.
Les uses cases peuvent être organisés en paquetages (packages).

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

28

Exemple de cas d’utilisation

Virement
Client local

<<extend>>
<<include>>
virement par internet

Identification

Vérification solde compte

Client distant

Les scénarios
Un cas d’utilisation est une abstraction de plusieurs chemins d’exécution. Une instance de
cas d’utilisation est appelée : « scénario ».
Chaque fois qu’une instance d’un acteur déclenche un cas d’utilisation, un scénario est créé
(le cas d’utilisation est instancié). Ce scénario suivra un chemin particulier dans le cas
d’utilisation.
Un scénario ne contient pas de branche du type « Si condition … alors » car pendant
l’exécution, la condition est soit vraie, soit fausse, mais elle aura une valeur.
Après la description des cas d’utilisation, il est nécessaire de sélectionner un ensemble de
scénarios qui vont servir à piloter l’itération en cours de développement.
Le choix et le nombre de scénarios à retenir est une étape difficile à réaliser : l’exhaustivité
est difficile, voire impossible à atteindre. Le nombre d’instances pour un cas d’utilisation
peut être très important, voire infini.
Les scénarios peuvent être classés en :
- scénarios principaux : il correspond à l’instance principal du cas d’utilisation.
C’est souvent le chemin « normal » d’exécution du cas d’utilisation qui
n’implique pas d’erreurs.
- Scénarios secondaires : il peut être un cas alternatif (un choix), un cas
exceptionnel ou une erreur.
Les scénarios sont utiles pour :
- analyser et concevoir le système
- justifier les choix effectués (ils serviront à la documentation des cas
d’utilisation)
- tester : les scénarios constituent le meilleur moyen de spécifier les tests.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

29

Elaboration des cas d'utilisation
Un cas d’utilisation doit être avant tout simple, intelligible et décrit de manière claire et
concise. Le nombre d’acteurs qui interagissent avec le cas d’utilisation est souvent limité.
Il y a souvent un acteur pas cas d’utilisation.
Lors de l’élaboration d’un cas d’utilisation, il faut se demander :
- quelles sont les tâches de l’acteur ?
- quelles informations l’acteur doit-il créer, sauvegarder, modifier ou lire ?
- l’acteur devra-t-il informer le système des changements externes ?
- le système devra-t-il informer l’acteur des conditions internes ?
- quelles sont les conditions de démarrage et d’arrêt du cas d’utilisation ?
Les cas d’utilisation peuvent être présentés à travers de vues multiples : un acteur avec tous
ses cas d’utilisation, un cas d’utilisation avec tous ses acteurs …
Un cas d’utilisation est une abstraction : il décrit de manière abstraite une famille de
scénarios. Il ne faut donc pas réaliser trop de cas d’utilisation car cela constituerait un
manque d’abstraction. Dans n’importe quels système, il y a relativement peu de cas
d’utilisation mais beaucoup de scénarios. Un grand nombre de cas d’utilisation signifie par
conséquent que l’essence du système n’est pas comprise.

Utilisation des cas d'utilisation
La portée des cas d’utilisation dépasse largement la définition des besoins du système. Les
cas d’utilisation interviennent tout au long du cycle de vie du projet, depuis le cahier des
charges jusqu’aux tests.
Intervenant
Utilisateur
Rôle des cas
Exprimer
d’utilisation

Analyste
Architecte
Comprendre
Concevoir

Programmeur Testeur
réaliser
vérifier

III.1.2) diagrammes de classes
Définition du diagramme de classes
Le diagramme de classes exprime la structure statique du système en termes de classes et
de relations entre ces classes.
L’intérêt du diagramme de classe est de modéliser les entités du système d’information.
Le diagramme de classe permet de représenter l’ensemble des informations finalisées qui
sont gérées par le domaine. Ces informations sont structurées, c’est-à-dire qu’elles ont
regroupées dans des classes. Le diagramme met en évidence d’éventuelles relations entre
ces classes.
Le diagramme de classes comporte 6 concepts :
- classe
- attribut
- identifiant
- relation
- opération
- généralisation / spécialisation

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

30

Les notions utilisées par le diagramme de classes
La notion de classe
Définition : une classe est une description abstraite (condensée) d’un ensemble d’objets du
domaine de l’application : elle définit leur structure, leur comportement et leurs relations.
Représentation : les classes sont représentées par des rectangles compartimentés :
- le 1er compartiment représente le nom de la classe
- le 2ème compartiment représente les attributs de la classe
- le 3ème compartiment représente les opérations de la classe
Formalisme :
NOM CLASSE
Attribut_1 : int
Attribut_2 : int
Attribut_3 : int
Operation_1 () : void
Operation_2 () : void

Les compartiments d’une classe peuvent être supprimés (en totalité ou en partie) lorsque
leur contenu n’est pas pertinent dans le contexte d’un diagramme. La suppression des
compartiments reste purement visuelle : elle ne signifie pas qu’il n’y a pas d’attribut ou
d’opération.
Formalisme de représentation simplifiée :

NOM CLASSE

Formalisme de représentation avec chemin complet :

nom paquetage :: NOM CLASSE

Le rectangle qui symbolise une classe peut contenir un stéréotype et des propriétés.
UML définit les stéréotypes de classe suivants :
- « classe implémentation » : il s’agit de l’implémentation d’une classe dans un
langage de programmation
- « énumération » : il s’agit d’une classe qui définit un ensemble d’identificateurs
formant le domaine de la valeur.
- « métaclasse » : il s’agit de la classe d’une classe, comme en Smalltalk
- « powertype » : une classe est un métatype : ses instances sont toutes des soustypes d’un type donné
- « processus » : il s’agit d’une classe active qui représente un flot de contrôles
lourd
- « thread » : il s’agit d’une classe active qui représente un flot de contrôles léger
- « type » : il s’agit d’une classe qui définit un domaine d’objets et les opérations
applicables à ces objets.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

31

-

« utilitaire » : il s’agit d’une classe réduite au concept de module et qui ne peut
être instanciée.

La notion d’attribut
Définition : Une classe correspond à un concept global d’information et se compose d’un
ensemble d’informations élémentaires, appelées attributs de classe.
Un attribut représente la modélisation d’une information élémentaire représentée par son
nom et son format.
Par commodité de gestion, on choisit parfois de conserver dans un attribut le résultat d’un
calcul effectué à partir d’autres classes : on parle alors d’attribut dérivé. Pour repérer un
attribut dérivé : on place un / devant son nom.
Formalisme :
NOM CLASSE
Attribut_1 : int
Attribut_2 : int
Attribut_3 : int
Operation_1 () : void
Operation_2 () : void

Visibilité et portée des attributs :
UML définit 3 niveaux de visibilité pour les attributs :
1- public (+) : l’élément est visible pour tous les clients de la classe
2- protégé (#) : l’élément est visible pour les sous-classes de la classe
3- privé (-) : l’élément n’est visible que par les objets de la classe dans laquelle il
est déclaré.
Formalisme :
NO M CL A S S E
+
#
-

A ttri b u t p u b l i c
A ttri b u t p ro té g é
A ttri b u t p ri vé

: int
: int
: int

La notion d’identifiant
L’identifiant est un attribut particulier, qui permet de repérer de façon unique chaque objet,
instance de la classe.
Formalisme :
FACT URE
+
+
+
+

COURS UML13.doc – janv 2003

No facture
Date
M ontant
/ M ontant T VA

:
:
:
:

n
doubl e
doubl e
n

J.STEFFE – ENITA de Bordeaux

32

La notion d’opération
Définition : l’opération représente un élément de comportement des objets, défini de
manière globale dans la classe.
Une opération est une fonctionnalité assurée par une classe. La description des opérations
peut préciser les paramètres d’entrée et de sortie ainsi que les actions élémentaires à
exécuter.
Formalisme :

ERU TCAF
n:
erutcaf oN +
e lbuod :
etaD +
e lbuod :
t n at n o M +
n : A V T t n at n o M / +
d iov :
)( ret idE
d iov : )( ret lusnoC
d iov :
)( reérC
Visibilité et portée des opérations :
Comme pour les attributs, on retrouve 3 niveaux de visibilité pour les opérations :
1- public (+) : l’opération est visible pour tous les clients de la classe
2- protégé (#) : l’opération est visible pour les sous-classes de la classe
3- privé (-) : l’opération n’est visible que par les objets de la classe dans laquelle
elle est déclarée.
Formalisme :

ERU TCAF
tn i :
erutcaf oN
etaD :
etaD
e lbuod :
tnatnoM
e lbuod : AV T tnatnoM /
)( euq i lbup pO
)( eégétorp pO
)( eév irp pO

+
+
+
+
+
#
-

La notion de relation
S’il existe des liens entre objets, cela se traduit nécessairement par des relations qui
existent entre leurs classes respectives.
Les liens entre les objets doivent être considérés comme des instances de relations entre
classes.
Il existe plusieurs types de relations entre classes :
- l’association

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

33

-

la généralisation/spécialisation
la dépendance

L’association
L’association est la relation la plus courante et la plus riche du point de vue sémantique.
Une association est une relation statique n-aire (le plus souvent : elle est binaire) : c’est-àdire qu’elle relie plusieurs classes entre elles.
L’association existe entre les classes et non entre les instances : elle est introduite pour
montrer une structure et non pour montrer des échanges de données.
Une association n-aire possède n rôles qui sont les points terminaux de l’association ou
terminaisons.
Chaque classe qui participe à l’association joue un rôle. Les rôles sont définis par 2
propriétés :
- la multiplicité : elle définit le nombre d’instances de l’association pour une
instance de la classe. La multiplicité est définie par un nombre entier ou un
intervalle de valeurs. La multiplicité est notée sur le rôle (elle est notée à
l’envers de la notation MERISE).
1
0..1
N ou *
M..N
0..*
1..*

Un et un seul
Zéro ou un
N (entier naturel)
De M à N (entiers naturels)
De zéros à plusieurs
De 1 à plusieurs

Formalisme et exemple en employant les noms des rôles et leur multiplicité :
S O C IE T E

0 ..1
e m p lo ye u r

0 ..*
e m p lo yé

P E RSO NNE

Formalisme et exemple en employant le noms de l’association et la multiplicité des rôles :
S O C IE T E
0 ..1

e m p lo ye r

0 ..*

P E RSO NNE

La multiplicité peut également s’exprimer par des symboles :

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

34

Les valeurs de multiplicité expriment les contraintes liées au domaine de l’application. Il
est donc important de déterminer les valeurs de multiplicité optimales pour trouver le bon
équilibre entre complexité et efficacité. La surestimation des valeurs de multiplicité
entraîne un surcoût de taille de stockage et en vitesse d’exécution (requête avec plus de
jointures).
- la navigabilité
La navigabilité n’a rien à voir avec le sens de lecture de l’association. Une navigabilité
placée sur une terminaison cible indique si ce rôle est accessible à partir de la source.
Par défaut les associations sont navigables dans les 2 sens. Dans certains cas, une seule
direction de navigation est utile : l’extrémité d’association vers laquelle la navigation est
possible porte alors une flèche.
Formalisme :
A

B

Dans l’exemple ci-dessus, les instances de A voient les instances de B mais les instances
de B ne voient pas les instances de A.
Les classes-association
Les attributs d’une classe dépendent fonctionnellement de l’identifiant de la classe. Parfois,
un attribut dépend fonctionnellement de 2 identifiants, appartenant à 2 classes différentes.
Par exemple, l’attribut « quantité commandée » dépend fonctionnellement du numéro de
commande et du code produit. On va donc placer l’attribut « quantité commandée » dans
l’association « comporter ».
Dans ce cas, l’association est dite « porteuse d’attributs ».
Une association porteuse d’attributs est appelée classe-association.
Commande

comporter

Produit
Code produit

No commande

Qté commandée

Exemple :
Toute classe-association peut être remplacée par une classe intermédiaire et qui sert de
pivot pour une paire d’association.
Exemple :
Commande
No commande

0..*

Ligne commande
Quantité commandée

1..1

Produit

0..*

Code produit

1..1

De même, toute association (qui ne contient pas d’attributs) impliquant 3 classes ou plus
peut donner lieu à une décomposition avec une classe intermédiaire.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

35

L’agrégation
Dans UML, l’agrégation n’est pas un type de relation mais une variante de l’association.
Une agrégation représente une association non symétrique dans laquelle une des extrémités
joue un rôle prédominant par rapport à l’autre extrémité.
L’agrégation ne peut concerner qu’un seul rôle d’une association.
L’agrégation se représente toujours avec un petit losange du côté de l’agrégat.
Le choix d’une association de type agrégation traduit la volonté de renforcer la dépendance
entre classes. C’est donc un type d’association qui exprime un couplage plus fort entre les
classes. L’agrégation permet de modéliser des relations de type maître et esclaves.
L’agrégation permet de modéliser une contrainte d’intégrité et de désigner l’agrégat
comme contrainte.
A travers une telle contrainte, il est possible de représenter par exemple :
- la propagation des valeurs d’attributs d’une classe vers une autre classe
- une action sur une classe qui implique une action sur une autre classe
- une subordination des objets d’une classe à une autre classe
Formalisme et exemple :
TYPE

0..*

VEHICULE

1..1

L’exemple ci-dessus montre que l’on veut gérer une classification de véhicules. Chaque
véhicule est classifié selon son type. En conséquence, il sera possible de prendre
connaissance pour un véhicule de l’ensemble des caractéristiques du type de véhicule
auquel il est associé.
NB : un agrégat peut être multiple. Dans l’exemple ci-dessous, un véhicule peut appartenir
à plusieurs types.
TYPE

0..*

VEHICULE

1..*

Cas particulier des associations réflexives :
On peut avoir des cas d’agrégation réflexive dès que l’on modélise des relations
hiérarchiques ou des liens de parenté par exemple.
PERSONNE

2
parent

*
enfant

La composition
La composition est un cas particulier de l’agrégation dans laquelle la vie des composants
est liée à celle des agrégats. Elle fait souvent référence à une contenance physique. Dans la
composition l’agrégat ne peut être multiple.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

36

La composition implique, en plus de l’agrégation, une coïncidence des durées de vie des
composants : la destruction de l’agrégat (ou conteneur) implique automatiquement la
destruction de tous les composants liés.
Formalisme et exemple :
VEHICULE

1..*

1..1
CHASSIS

1..*

1..1
MOTEUR

La généralisation / spécialisation
Le principe de généralisation / spécialisation
Le principe de généralisation / spécialisation permet d’identifier parmi les objets d’une
classe (générique) des sous-ensembles d’objets (des classes spécialisées) ayant des
définitions spécifiques. La classe plus spécifique (appelée aussi classe fille, classe dérivée,
classe spécialisée, classe descendante …) est cohérente avec la classe plus générale
(appelée aussi classe mère, classe générale …), c’est-à-dire qu’elle contient par héritage
tous les attributs, les membres, les relations de la classe générale, et peut contenir d’autres.
Les relations de généralisation peuvent être découvertes de 2 manières :
- la généralisation : il s’agit de prendre des classes existantes déjà mises en
évidences) et de créer de nouvelles classes qui regroupent leurs parties
communes ; il faut aller du plus spécifique au plus général.
- La spécialisation : il s’agit de sélectionner des classes existantes (déjà
identifiées) et d’en dériver des nouvelles classes plus spécialisées, en spécifiant
simplement les différences.
Ces 2 démarches, même si elles sont fondamentalement différentes, mènent au même
résultat, à savoir la constitution d’une hiérarchie de classes reliées par des relations de
généralisation.
La relation de généralisation est très puissante car elle permet de construire simplement de
nouvelles classes à partir de classes existantes. Cependant, elle est très contraignante dans
le sens où elle définit une relation très forte entre les classes. Ainsi, l’évolution d’une
classe de base entraîne une évolution de toutes les classes qui en dérivent. Cet effet boule
de neige peut avoir des conséquences aussi bien positives (quand c’est l’effet recherché)
que négatives.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

37

Formalisme et exemple :
Instrum ent
Code instrum ent
date fabri cati on
Nom i nstrum ent

A corde

A percussi on

Nb de cordes

A vent

Nb de percussi ons

Nb de pistons

La spécialisation multiple
Les classes peuvent avoir plusieurs superclasses ; dans ce cas, la généralisation est dite
multiple et plusieurs flèches partent de la sous-classe vers les différentes superclasses. La
généralisation multiple consiste à fusionner plusieurs classes en une seule classe.
Formalisme et exemple :
Salarié

Client

Client spécial

Bénéficie

Tarif préférentiel

La classe « client spécial » est une spécialisation de client et de salarié. Ce modèle permet
d’indiquer que l’on accorde des tarifs préférentiels aux salariés.
Les contraintes sur les associations
Il existe plusieurs types de contraintes sur les associations :

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

38

- La contrainte de partition
Elle indique que toutes les instances d’une classe correspondent à une et une seule instance
des classes liées.
Société

{partition}
Client

Prospect

Toutes les sociétés sont soit clientes, soit considérées comme des prospects.
- la contrainte d’exclusion
Elle permet de préciser qu’une instance d’association exclut une autre instance.
Par exemple, un employé ne peut être à la fois directeur financier et directeur commercial.

Ici, un employé ne peut pas être à la fois directeur commercial et directeur financier. Mais
tout employé n’est pas directeur commercial ou directeur financier (contrainte de
partition).
- la contrainte de totalité
Toutes les instances d’une classe correspondent au moins à une des instances des classes
liées.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

39

Société

{Totalité}
Partenaire

Client privilégié

Toute société est au moins partenaire ou client privilégiée. Et elle peut être les 2 à la fois.
- la contrainte d’inclusion
Elle permet de préciser qu’une collection est incluse dans une autre collection. (la flèche de
la relation de dépendance indique le sens de la contrainte).
Par exemple, on pourra indiquer que le contractant d’un contrat fait obligatoirement partie
des individus assurés.
Exemple :

La dépendance
Les relations de dépendance sont utilisées lorsqu’il existe une relation sémantique entre
plusieurs éléments qui n’est pas de nature structurelle. Une relation de dépendance définit
une relation unidirectionnelle entre un élément source et un élément cible.
Une dépendance est une relation entre deux éléments de modélisation dans laquelle toute
modification effectuée sur un élément de modélisation (l'élément influent) affecte l'autre
élément (élément dépendant).
UML définit 4 types de relation de dépendance. Pour chaque type de dépendance, un mot
clé ou stéréotype entre guillemets peut être ajouté à la relation de dépendance pour préciser
sa nature.
Les 4 types de relation sont :
- abstraction
Il s’agit d’une relation de dépendance entre éléments qui représentent un même concept à
différents niveaux d’abstraction ou selon des points de vue distincts.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

40

Les mots-clés sont :
o « « dérive » »
Représente un élément défini ou calculé à partir d’un autre. Par exemple, un attribut ou un
rôle peut dériver d’autres attributs ou rôles.
o « « raffine » »
Représente une relation de dépendance entre des éléments sémantiques différents (analyse
et conception par exemple).
o « « réalise » »
Représente une relation de dépendance entre une spécification (cible) et l’élément qui
implémente cette spécification (source)
o « « trace » »
Représente l’historique des constructions présentes dans les différents modèles.
- Liaison
Les paramètres formels d’une classe ou collaboration paramétrables doivent être liés à des
valeurs. Cette dépendance crée une liaison entre la classe ou collaboration paramétrable (la
cible) et la classe ou collaboration paramétrée (source).
o « « lie » »
- Permission
Un élément (source) a le droit d’accéder à un espace de nommage (cible)
o « « ami » »
Représente un élément source (paquetage, classe, opération …) qui a accès à l’élément
destination (paquetage, classe, opération …) quelle que soit la spécification de visibilité de
ce dernier.
- Utilisation
Un élément (source) requiert la présence d’un autre élément (cible) pour son bon
fonctionnement ou son implémentation.
o « « utilise » »
o « « appelle » »
Représente une relation de dépendance entre une opération qui invoque une opération
d’une autre classe. Cette relation est représentée en connectant les opérations ou les classes
qui possèdent ces opérations.
o « « crée » »
Représente le classificateur source qui crée une instance du classificateur cible
o « « instancie » »
Représente une relation de dépendance entre classificateurs due à la création d’une
instance du classificateur cible par une opération du classificateur source.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

41

Formalisme :
Classe A

<<derive>>
Classe B

L’interface
Une interface définit le comportement visible d’une classe. Ce comportement est défini par
une liste d’opérations ayant une visibilité « public ». Aucun attribut ou association n’est
défini pour une interface.
Une interface est en fait une classe particulière (avec le stéréotype « « interface » »).
UML représente les interfaces :
- soit au moyen de petits cercles reliés par un trait à l’élément qui fournit les
services décrits par l’interface
- soit au moyen de classes avec le mot clé « « interface » ». Cette notation permet
de faire figurer dans le compartiment des opérations la liste des services de
l’interface.
Les relations possibles sur une interface sont :
- la fourniture
Cette relation spécifie qu’une classe donnée fournit l’interface à ses clients : c’est-à-dire
que la classe possède cette interface.
Une classe peut fournir plusieurs interfaces à ses clients et chaque interface définit un des
services de la classe. Cette technique permet de réduire la visibilité d’une classe.
En effet, une classe qui expose ses opérations publiques les expose à toutes les autres
classes du modèle. Le concept d’interface permet à une classe de définir plusieurs profils
en permettant à chaque classe de n’utiliser que le profil qui l’intéresse. Une classe peut
ainsi être vue avec plusieurs perspectives différentes en fonction de la classe qui l’utilise,
ce qui augmente la réutilisabilité.
- l’utilisation
Cette relation concerne toute classe client qui souhaite accéder à la classe interface de
manière à accéder à ses opérations. C’est une relation d’utilisation standard.
- la réalisation
Cette relation n’est utilisée que pour les interfaces.
Une réalisation est une relation entre une classe et une interface. Elle montre que la classe
réalise les opérations offertes par l'interface.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

42

Exemple et formalisme :
«« utilise »»

Crédit

Entreprise
«« utilise »»

Banque

Client
«« utilise »»

« « interface » »
Assurance

L’exemple ci-dessus illustre la modélisation de 2 interfaces crédit et assurance d’une classe
banque. Une relation de réalisation indique que la classe banque réalise l’interface
assurance.

Elaboration d’un diagramme de classes
Généralités
Un diagramme de classes est une collection d'éléments de modélisation statiques (classes,
paquetages...), qui montre la structure d'un modèle.
Un diagramme de classes fait abstraction des aspects dynamiques et temporels.
Pour un modèle complexe, plusieurs diagrammes de classes complémentaires doivent être
construits.
On peut par exemple se focaliser sur :
- les classes qui participent à un cas d'utilisation (cf. collaboration),
- les classes associées dans la réalisation d'un scénario précis,
- les classes qui composent un paquetage,
- la structure hiérarchique d'un ensemble de classes.
Pour représenter un contexte précis, un diagramme de classes peut être instancié en
diagrammes d'objets.

Règles d’élaboration
Les règles de normalisation des modèles entité-relation, issues de l’algèbre relationnelle,
peuvent être utilement appliquées à un modèle de classes UML, même si UML ne contient
aucune préconisation sur ces règles.
Ces règles aident à conduire les travaux de modélisation en évitant le plus possible la
redondance de l’information, tout en restant fidèle aux règles de gestion.

III.1.3) diagrammes d'objets
Le diagramme d’objets permet de mettre en évidence des liens entre les objets. Les objets,
instances de classes, sont reliés par des liens, instances d’associations.
A l’exception de la multiplicité, qui est explicitement indiquée, le diagramme d’objets
utilise les mêmes concepts que le diagramme de classes. Ils sont essentiellement utilisés
pour comprendre ou illustrer des parties complexes d’un diagramme de classes.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

43

Exemple :
Salarié : Dupont
1..1
Supérieur

Diriger

Salarié

0..*
Subordonné

Salarié : Martin

Salarié : Durand

III.1.4) diagrammes de composants
Les diagrammes de composants décrivent les composants et leurs dépendances dans
l’environnement de réalisation.
En général, ils ne sont utilisés que pour des systèmes complexes.
Un composant est une vue physique qui représente une partie implémentable d’un système.
Un composant peut être du code, un script, un fichier de commandes, un fichier de
données, une table … Il peut réaliser un ensemble d’interfaces qui définissent alors le
comportement offert à d’autres composants.
Formalisme :
Fichier
Consultation

Archivage

UML définit 5 stéréotypes aux composants :
- « « document » » : un document quelconque
- « « exécutable » » : un programme qui peut s’exécuter
- « « fichier » » : un document contenant un code source ou des données
- « « bibliothèque » » : une bibliothèque statique ou dynamique
- « « table » » : une table de base de données relationnelle
Pour montrer les instances des composants, un diagramme de déploiement peut être utilisé.

III.1.5) diagrammes de déploiement
Les diagrammes de déploiement montrent la disposition physique des différents matériels
(les nœuds) qui entrent dans la composition d’un système et la répartition des instances de
composants, processus et objets qui « vivent » sur ces matériels.
Les diagrammes de déploiement sont donc très utiles pour modéliser l’architecture
physique d’un système.

COURS UML13.doc – janv 2003

J.STEFFE – ENITA de Bordeaux

44




Télécharger le fichier (PDF)

cours cours UML.pdf (PDF, 370 Ko)

Télécharger
Formats alternatifs: ZIP







Documents similaires


cours cours uml
9 exrcices de diagramme de classe
9 exrcices de diagramme de classes
inge3 diagclasses 1
mc 18 10 10
5 oom oct2005 v5

Sur le même sujet..