COURS MODELISATION AVEC UML

Pré-requis

●Programmation orientée objets,

Concepts de POO : héritage, polymorphisme, etc ...

●Programmation système,

Processus concurrents,

●Méthode MERISE,

Analyse des besoins de l'utilisateur,–Modèles conceptuels et logiques.

●Grafcets et automates.

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 deux dernières décennies 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
 COURS MODELISATION AVEC UML
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 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 œuvre 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.
 COURS MODELISATION AVEC UML
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 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
 COURS MODELISATION AVEC UML
cardinalités... Utiliser le langage de programmation comme support de conception ne 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 œuvre 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 constructiond'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. 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
 COURS MODELISATION AVEC UML
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. 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
 COURS MODELISATION AVEC UML
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...).
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.

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
 COURS MODELISATION AVEC UML
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,

- 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
 COURS MODELISATION AVEC UML
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
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.
 COURS MODELISATION AVEC UML
Document

+ Code Document : int

+ Nom Document : String

+ Type Document : String

+ Calculer Date Rappel : Date

MERISE_UML_Document

C1

De Merise vers UML

Support de Cours

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.
 COURS MODELISATION AVEC UML

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

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.
 COURS MODELISATION AVEC UML

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

Historique de l’approche objet

 COURS MODELISATION AVEC UML
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.
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 :
 COURS MODELISATION AVEC UML
- 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, Classe-Relation,
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.
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.
 COURS MODELISATION AVEC UML

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.
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),
 COURS MODELISATION AVEC UML
- 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

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 MODELISATION AVEC UML

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.
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.
 COURS MODELISATION AVEC UML
- à 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 ».

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,
 COURS MODELISATION AVEC UML
- 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).
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 termes 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 termes 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.
 COURS MODELISATION AVEC UML
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.
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.

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
 COURS MODELISATION AVEC 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
plus courants ci-après) :
- 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

Les diagrammes UML sont dépendants hiérarchiquement et se complètent, de façon à

permettre la modélisation d'un projet tout au long de son cycle de vie.
* Diagrammes structurels ou statiques

Les diagrammes structurels ou statiques rassemblent :

- Diagramme de classes : il représente les classes intervenant dans le système.
- Diagramme d'objets: il sert à représenter les instances de classes (objets) utilisées dans le
système.
- Diagramme de composants : il permet de montrer les composants du système d'un point
de vue physique, tels qu'ils sont mis en oeuvre (fichiers, bibliothèques, bases de données…)

- Diagramme de HYPERLINK : il sert à représenter les éléments matériels (ordinateurs,

périphériques, réseaux, systèmes de stockage…) et la manière dont les composants du
système sont répartis sur ces éléments matériels et interagissent entre eux.
- Diagramme des paquetages: un paquetage étant un conteneur logique permettant de
regrouper et d'organiser les éléments dans le modèle UML, le diagramme de paquetage sert
 COURS MODELISATION AVEC UML
à représenter les dépendances entre paquetages, c’est-à-dire les dépendances entre
ensembles de définitions.
- Diagramme de structure composite : depuis UML 2.x, permet de décrire sous forme de
boîte blanche les relations entre composants d'une classe.
- Diagramme de profils: depuis UML 2.2, permet de spécialiser, de personnaliser pour un
domaine particulier un Meta-modèle de référence d'UML.

* Diagrammes comportementaux
Les diagrammes comportementaux rassemblent :
- Diagramme des cas d'utilisation: il permet d'identifier les possibilités d'interaction entre le
système et les acteurs (intervenants extérieurs au système), c'est-à-dire toutes les
fonctionnalités que doit fournir le système.
- Diagramme états-transitions: permet de décrire sous forme de machine à états finis le
comportement du système ou de ses composants.
- Diagramme d'activité: permet de décrire sous forme de flux ou d'enchaînement d'activités
le comportement du système ou de ses composants.
- Diagramme de séquence: représentation séquentielle du déroulement des traitements et
des interactions entre les éléments du système et/ou de ses acteurs.
- Diagramme de communication : depuis UML 2.x, représentation simplifiée d'un diagramme
de séquence se concentrant sur les échanges de messages entre les objets.
- Diagramme global d'interaction: depuis UML 2.x, permet de décrire les enchaînements
possibles entre les scénarios préalablement identifiés sous forme de diagrammes de
séquences.
- Diagramme de temps : depuis UML 2.3, permet de décrire les variations d'une donnée au
cours du temps.
 COURS MODELISATION AVEC UML

III) Modélisation avec UML : Etude de quelques diagrammes

III.1) Notations communes à tous les diagrammes

Avant d’aborder la mise en œuvre de quelques diagrammes significatifs d’UML, il est

opportun de présenter un certain nombre de notations communes à tous les diagrammes.

a- Notion de classeur
Un classeur est un élément de modèle qui est doté d’une identité, possède des
caractéristiques structurelles (attributs, participation à des relations) et comportementales
(opérations). Exemple de classeur structuré montrant qu'un classeur Moteur est en fait
constitué d'un Allumage et de quatre Bougies :

b- Paquetage (ou package)

C’est un regroupement d’éléments de modèle ou de diagrammes. Il permet ainsi d'organiser
des éléments de modélisation en groupes. Il peut contenir tout type d'élément de modèle :
des classes, des cas d'utilisation, des interfaces, des diagrammes… et même des paquetages
imbriqués (décomposition hiérarchique). Un paquetage se représente comme un dossier avec
son nom inscrit dedans (figure ou diagramme de gauche). Il est possible de représenter
explicitement le contenu d'un paquetage. Dans ce cas, le nom du paquetage est placé dans
l'onglet (figure ou diagramme de droite).

c- Stéréotype
Un stéréotype est une annotation s'appliquant sur un élément de modèle. Il n'a pas de
définition formelle, mais permet de mieux caractériser des variétés d'un même concept. Il
permet donc d'adapter le langage à des situations particulières. Il est représenté par une
chaîne de caractères entre guillemets (<< >>) dans, ou à proximité du symbole de l'élément
de modèle de base. UML utilise aussi les rectangles pour représenter les classes. La notation
n'est cependant pas ambiguë grâce à la présence du stéréotype << use case >>.
Voici un exemple de représentation d’un acteur sous la forme d'un classeur stéréotypé <<
actor >> :
 COURS MODELISATION AVEC UML

d- Note ou Commentaire
Une note contient une information textuelle comme un commentaire, un corps de méthode
ou une contrainte. Graphiquement, elle est représentée par un rectangle dont l'angle
supérieur droit est plié. Le texte contenu dans le rectangle n'est pas contraint par UML. Une
note n'indique pas explicitement le type d'élément qu'elle contient, toute l'intelligibilité d'une
note doit être contenue dans le texte même. On peut relier une note à l'élément qu'elle
décrit grâce à une ligne en pointillés. Si elle décrit plusieurs éléments, on dessine une ligne
vers chacun d'entre eux. L'exemple ci-après montre une note exprimant une contrainte sur
un attribut.

e- Contraintes
Une contrainte constitue une condition ou une restriction sémantique exprimée sous forme
d'instruction dans un langage textuel qui peut être naturel ou formel. En général, une
contrainte peut être attachée à n'importe quel élément de modèle ou liste d'éléments de
modèle. Une contrainte désigne une restriction qui doit être appliquée par une
implémentation correcte du système. On représente une contrainte sous la forme d'une
chaîne de texte placée entre accolades ({}). La chaîne constitue le corps écrit dans un langage
de contrainte qui peut être :
• naturel ;
• dédié, comme OCL ;
• ou encore directement issu d'un langage de programmation.
Exemple 1 :

Ce diagramme exprime que : une personne est née dans un pays, et que cette association ne
peut être modifiée ; une personne a visité un certain nombre de pays, dans un ordre donné,
et que le nombre de pays visités ne peut que croître ; une personne aimerait encore visiter
toute une liste de pays, et que cette liste est ordonnée (probablement par ordre de
préférence).
 COURS MODELISATION AVEC UML
Exemple 2 :

Sur ces deux diagrammes, la contrainte porte sur un attribut qui doit être positif. En bas à
gauche, la contrainte {frozen} précise que le nombre de roues d'un véhicule ne peut pas
varier. Au milieu, la contrainte {subset} précise que le président est également un membre du
comité. Enfin, en bas à droite, la contrainte {xor} (ou exclusif) précise que les employés de
l'hôtel n'ont pas le droit de prendre une chambre dans ce même hôtel.

f- Espace de noms
Les espaces de noms sont des paquetages, des classeurs, etc. On peut déterminer un élément
nommé de façon unique par son nom qualifié, qui est constitué de la série des noms des
paquetages ou des autres espaces de noms depuis la racine jusqu'à l'élément en question.
Dans un nom qualifié, chaque espace de nom est séparé par deux doubles points (::). Par
exemple, si un paquetage B est inclus dans un paquetage A et contient une classe X, il faut
écrire A::B::X pour pouvoir utiliser la classe X en dehors du contexte du paquetage B.

III.2) 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 classes est de modéliser les entités du
système d’information. Le diagramme de classes 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 est le plus important des
diagrammes UML, c’est le seul qui soit obligatoire lors de la modélisation objet d’un système.

Une classe est une représentation abstraite d’un d’ensemble d’objets, elle contient les
informations nécessaires à la construction de l’objet (c'est-à-dire la définition des attributs et
des méthodes).
 COURS MODELISATION AVEC UML
La classe peut donc être considérée comme le modèle, le moule ou la notice qui va permette
la construction d’un objet. Nous pouvons encore parler de type (comme pour une donnée).
On dit également qu’un objet est l’instance d’une classe (la concrétisation d’une classe).
III.2.1) Représentation des classes

Une classe est représentée par un rectangle (appelé aussi classeur) divisé en 3
compartiments. Le premier compartiment contient le nom de la classe qui représente le type
d’objet instancié et débute par une lettre majuscule. Le nom est centré dans le compartiment
supérieur de la classe et écrit en caractère gras. Il est en italique si la classe est abstraite
(IMPOSSIBLE d’instancié un objet).
Le deuxième compartiment contient les attributs. Le troisième compartiment contient les
méthodes.

Si la modélisation ne s’intéresse qu’aux relations entre les différentes classes du système (et
pas au contenu des classes), nous pouvons ne pas représenter les attributs et les méthodes
de chaque classe (nous ne mettons rien dans le deuxième et troisième compartiment).

Exemples :

Une classe peut être détaillée en indiquant :

La visibilité (encapsulation) des méthodes et des attributs, c’est-à-dire :

public : élément non encapsulé visible par tous (+)
private : élément encapsulé visible seulement dans la classe (-)
protected : élément encapsulé visible dans la classe et dans les sous-classes (#)
package : élément encapsulé visible dans les classes du même paquetage (~)
Le type de chaque attribut ;
La signature de chaque méthode ;
 COURS MODELISATION AVEC UML
Le type de valeur retournée par chaque méthode ;

La direction des paramètres des méthodes :

Devant le nom du paramètre, il est possible d’indiquer par un mot clé (in, out, inout), la
direction dans laquelle celui-ci est transmis :
- in La valeur du paramètre est transmise à l’appel de la méthode (par l’appelant de la
méthode) et ne peut pas être modifiée (c’est le comportement par défaut si aucune direction
n’est spécifiée).
- out La valeur finale du paramètre est transmise au retour de l’appel de la méthode (à
l’appelant de la méthode).
- inout La valeur du paramètre est transmise à l’appel et au retour.
Exemple :
Considérons la méthode régler(heures : int, minutes : int) : void de la classe Horloge de
l’exemple précédent. L’appelant de la méthode veut affecter les attributs heures et minutes
avec des valeurs qu’il va donner.
✗ La direction des paramètres sera alors in :
régler(in heures : int, in minutes : int) : void
Considérons maintenant la méthode getTime(heures : int, minutes : int) : void de la classe
Horloge. L’appelant de la méthode veut récupérer les valeurs des attributs heures et minutes.
✗ La direction des paramètres sera alors out :
getTime(out heures : int, out minutes : int) : void
Remarque : Comme une méthode ne peut retourner qu’une seule valeur, et que dans notre
cas nous avons besoin de connaître deux valeurs (les heures et les minutes), le retour se fera
par les arguments (en utilisant les références ou les pointeurs en C++).
Valeurs par défauts des attributs et des paramètres des méthodes :
Nous indiquons les valeurs par défauts des attributs lors de leur construction et les valeurs
par défauts des paramètres des méthodes s’ils ne sont pas clairement spécifiés lors de
l’appel.

Attributs et méthodes de classe (ou attributs et méthodes statiques)

Une classe peut contenir des attributs et des méthodes qui lui sont propres et auxquels nous
 COURS MODELISATION AVEC UML
pouvons accéder sans nécessairement instancier des objets. Un attribut de classe
n’appartient pas à un objet en particulier mais à toute la classe (il n’est pas instancié avec
l’objet). Un attribut ou une méthode de classe est représenté par un nom souligné.
Cela permet également d’avoir une information commune à tous les objets instanciés.

Les contraintes :
Une contrainte est une condition écrite entre 2 accolades. Elle peut être exprimée dans :
✗ Un langage naturel (description textuelle)
✗ Un langage formel (C++, java, OCL…).
Remarques : OCL (Object Contraint Language) est un langage spécialement conçu pour
exprimer des contraintes. En voici quelques unes qui peuvent être bien utiles :
✗ {readOnly} : si une telle contrainte est appliquée à un attribut, alors la valeur de celui-ci ne
peut plus être modifiée une fois la valeur initiale fixée (équivalent à un attribut constant).
✗ {query} : une méthode peut être déclarée comme étant de type requête (query) si le code
implémentant celle-ci ne modifie nullement l’état de l’objet, donc aucun de ses attributs.
✗ {ordered} {list} : lorsqu’une multiplicité supérieure à 1 est précisée, il est possible d’ajouter
une contrainte pour préciser si les valeurs sont ordonnées {ordered} ou pas {list}. Très
souvent, dans ce dernier cas, nous ne précisons même pas cette deuxième contrainte, c’est le
mode par défaut.
✗ {unique} : on demande cette fois-ci qu’il n’y ait aucun doublon dans les valeurs de la
collection.
✗ {not null} : L’attribut doit à tout prix être initialisé (utile dans le cas des pointeurs).

Les attributs calculés (dérivé) :

Une classe peut avoir des attributs calculés, c'est-à-dire que leurs valeurs sont proposées au
travers d’une fonction utilisant les autres attributs précédemment exprimés. Un tel attribut
possède un nom précédé du signe « / » et suivi d’une contrainte permettant de le calculer.
Exemple : Soit la classe Gasoil vu précédemment, à laquelle nous ajoutons l’attribut
prixDuPlein.
 COURS MODELISATION AVEC UML

La multiplicité (ou cardinalité) :

La multiplicité indique le nombre de valeur que l’attribut peut contenir (l’attribut est souvent
un tableau de valeurs, statique ou dynamique). La multiplicité se note entre crochets après le
type de valeur que contient l’attribut. On peut avoir par exemple :
0..1 pour Zéro ou une fois
1..1 (ou 1) pour Une et une seule fois
0..* (ou *) pour De zéro à plusieurs fois
1..* pour De une à plusieurs fois
m..n pour Entre m et n fois
n..n (ou n) pour n fois

Exemple : Une station météo doit relever la température à intervalle de temps régulier. Elle
doit pouvoir stocker 100 relevés.

Constructeur et destructeurs :
Les stéréotypes peuvent être utilisés pour identifier des opérations particulières comme les
constructeurs (stéréotype « create ») et le destructeur (stéréotype « destroy »).
Exemple : Il est possible de mettre en place une gestion de notes, avec le calcul de la
moyenne, de la valeur maxi, etc. au travers d’une classe adaptée nommée Notes.

Les énumérations :
 COURS MODELISATION AVEC UML
Une énumération est un type possédant un nombre fini et arbitraires de valeurs possibles,
construite sur mesure par le développeur, pour typer des variables bien particulières, comme
le représentation des jours de la semaine ou des mois de l’année.
Représentation : En UML, une énumération ne se définit pas par une classe, mais par un
classeur stéréotypé « enumeration ». Il s’agit d’un type de données, possédant un nom, et
utilisé pour énumérer un ensemble de littéraux correspondant à toutes les valeurs possibles
que peut prendre une expression de ce type.

Les modèles de classe :

Les modèles (templates) sont une fonctionnalité avancée de l’orientée objet. Un modèle est
une classe paramétrée qui permet ainsi de choisir le type des attributs au besoin suivant le
paramètre précisé, dans le coin supérieur droit dans un rectangle dont les côtés sont en
pointillés.
Exemple : Ces modèles de classes sont particulièrement utiles pour toutes les collections qui
stockent des valeurs d’un même type, soit sous forme de tableaux dynamiques ou de listes.
La classe vector, issue de la STL en est un parfait exemple.
• Stéréotypes de Jacobson :
À l’intérieur d’un système, il existe très souvent des classes qui possèdent un rôle bien
particulier qui serait intéressant de visualiser d’une façon non équivoque dans votre
diagramme de séquence.
C’est le cas notamment :
✔ Pour les classes qui représentent des composants de l’IHM.
✔ Pour la classe qui contrôle globalement le système avec la prise en compte de la gestion
événementielle.
✔ Pour les classes qui implémentent la persistance des attributs (associées à une base de
données).
Jackobson distingue les trois stéréotypes suivants :
✔ « boundary » : classes qui servent à modéliser les interactions entre le système et ses
acteurs.
✔ « control » : classes utilisées pour représenter la coordination, l’enchaînement et le
contrôle d’autres objets.
✔ « entity » : classes qui servent à modéliser des informations durables et souvent
persistantes.
 COURS MODELISATION AVEC UML

III.2.2) Les Relations entre les classes

III.2.2.1) La Relation de dépendance
La dépendance est la forme la plus faible de relation entre classes. Une dépendance entre
deux classes signifie que l’une des deux utilise l’autre. Typiquement, il s’agit d’une relation
transitoire, au sens où la première interagit brièvement avec la seconde sans conserver à
terme de relation avec elle (liaison ponctuelle).
Une dépendance peut s’interpréter comme une relation de type «utilise un ». Elle est
habituellement utilisée lorsqu'une classe utilise un objet d'une autre classe comme argument
dans la signature d’une méthode ou alors lorsque l'objet de l'autre classe est créé à l'intérieur
de la méthode. Dans les deux cas la durée de vie de l'objet est très courte, elle correspond à
la durée d'exécution de la méthode.
Notation : Elle est représentée par un trait discontinu orienté, reliant les deux classes. La
dépendance est souvent stéréotypée (« use ») pour mieux expliciter le lien sémantique entre
les éléments du modèle.
Exemple

III.2.2.2) Les Associations entre Classes

 COURS MODELISATION AVEC UML
Alors que la dépendance autorise simplement une classe à utiliser des objets d’une autre
classe, l’association signifie qu’une classe contiendra une référence (ou un pointeur) de
l'objet de la classe associée sous la forme d’un attribut.

Cette relation est plus forte. Elle indique qu’une classe est en relation avec une autre pendant
un certain laps de temps. La durée de vie des deux objets concernés n’est cependant pas
associée étroitement (un objet peut être détruit sans que l’autre le soit nécessairement).

L’association est représentée par un simple trait continu, reliant les deux classes. Le fait que
deux instances soient ainsi liées permet la navigation d’une instance vers l’autre, et vice versa
(chaque classe possède un attribut qui fait référence à l’autre classe).

Exemple :

L’association peut être détaillée en indiquant :

Le nom de l’association :
L’association peut être ornée d’un texte, avec un éventuel sens de lecture, qui permet de
nous informer de l’intérêt de cette relation. Nous rajoutons une phrase courte permettant de
préciser le contexte de cette association.
Le rôle :
Chaque extrémité d’une association peut être nommée. Ce nom est appelé rôle et indique la
manière dont l’objet est vu de l’autre côté de l’association. Lorsqu’un objet A est lié à un
autre objet B par une association, cela se traduit souvent par un attribut supplémentaire dans
A qui portera le nom du rôle B. (et inversement).

La cardinalité (ou multiplicité) :

La cardinalité indique le nombre d’instances de classe étant en relation avec la classe situé à
l’autre extrémité de l’association. En l’absence de spécification, la cardinalité vaut 1.

Association réflexives (ou récursive) :

Une association qui lie une classe avec elle-même est une association réflexive.
 COURS MODELISATION AVEC UML

Contraintes et associations :
Nous avons déjà vu la notion de contrainte appliquées à des attributs. Nous pouvons aussi
proposer des contraintes au niveau des associations.

Exemples :

la navigabilité :
La navigabilité indique s'il est possible de traverser une association. On représente
graphiquement la navigabilité par une flèche du côté de la terminaison navigable et on
empêche la navigabilité par une croix du côté de la terminaison non navigable. Par défaut,
une association est navigable dans les deux sens.

Par exemple, sur la figure, la terminaison du côté de la classe Commande n'est pas navigable :
cela signifie que les instances de la classe Produit ne stockent pas de liste d'objets du type
Commande. Inversement, la terminaison du côté de la classe Produit est navigable : chaque
objet commande contient une liste de produits.
 COURS MODELISATION AVEC UML
Lorsque l'on représente la navigabilité uniquement sur l'une des extrémités d'une
association, il faut remarquer que, implicitement, les trois associations représentées sur la
figure 3.8 ont la même signification : l'association ne peut être traversée que dans un sens.
Voici deux modélisations équivalentes :

III.2.2.3) Les Associations n-aires et les Classes associations

Association n-aire :
Une association qui lie plus de 2 classes entre elles, est une association n-aire. L’association n-
aire se représente par un losange d’où part un trait allant à chaque classe. L’association n-aire
est imprécise, difficile à interpréter et souvent source d’erreur, elle est donc très peu utilisée.
La plupart du temps nous nous en servons que pour esquisser la modélisation au début du
projet, puis elle est vite remplacée par un ensemble d’associations binaires afin de lever toute
ambiguïté.

remplacer par

Classe-Association :
Une association peut apporter de nouvelles informations (attributs et méthodes) qui
n’appartiennent à aucune des deux classes qu’elle relie et qui sont spécifiques à l’association.
Ces nouvelles informations peuvent être représentées par une nouvelle classe attachée à
l’association via un trait en pointillés.
Exemple 1 :
 COURS MODELISATION AVEC UML

Remarque : Comme pour l’association ternaire, nous pouvons convertir la classe association
en un ensemble d’associations binaires.

Autres exemples :
 COURS MODELISATION AVEC UML
III.2.2.3) Les Associations particulières : Composition et Agrégation
La composition et l’agrégation sont des cas particuliers d’association.
La composition indique qu’un objet A (appelé conteneur) est constitué d’un autre objet B.
Cet objet A n’appartient qu’a l’objet B et ne peut pas être partagé avec un autre objet C’est
une relation très forte, si l’objet A disparaît, alors l’objet B disparaît aussi. Ex : Un cheval
possède une tête et 4 jambes. Elle se représente par un losange plein du côté de l’objet
conteneur.
L’agrégation indique qu’un objet A possède un autre objet B, mais contrairement à la
composition, l’objet B peut exister indépendamment de l’objet A. La suppression de l’objet A
n’entraîne pas la suppression de l’objet B. L’objet A est plutôt à la fois possesseur et
utilisateur de l’objet B. Ex : Un cheval possède une selle sur son dos. Elle se représente par un
losange vide du côté de l’objet conteneur.

Un Agrégat est une Association non-symétrique. C’est une relation de dominance et de

subordination où une classe fait partie d'une autre classe ou une action sur une classe
implique une action sur une autre classe. Ici, une classe peut appartenir à plusieurs agrégats

Par contre, une Composition est une Agrégation forte dans laquelle la
Création/Copie/Destruction du composite entraîne la Création/Copie/Destruction de ses
composants. Un composant appartient à au plus un composite (multiplicité maxi côté
conteneur = 1)
 COURS MODELISATION AVEC UML

III.2.2.4) La relation d’Héritage

Le mécanisme d’héritage permet de mettre en relation des classes ayant des caractéristiques
communes (attributs et comportements) en respectant une certaine filiation. L’héritage
indique qu’une classes B est une spécialisation d’une classe A. La classe B (appelé classe fille,
classe dérivée ou sous classe) hérite des attributs et des méthodes de la classe A (appelée
classe mère, classe de base ou super classe). Il se représente par un triangle vide afin
d’indiquer le sens de la généralisation (inverse de la spécialisation).
Les seules contraintes prédéfinies en UML pour la généralisation sont :
. {disjoint} (par défaut) : les sous-classes n’ont aucune instance en commun
. {overlapping} : les sous-classes peuvent avoir une ou plusieurs instances en commun

{overlapping} précise ici qu’il existe des véhicules amphibies qui sont issus d’un croisement
des sous classes de véicules.
. {complete} (liste exhaustive de classe) ou {incomplete} (les sous-classes spécifiées ne
couvrent pas la super-classe)
 COURS MODELISATION AVEC UML

{incomplete} exprime ici l’idée que des instances de la Classe Personne sont des avocats, des
vendeurs, des enseignants ou d’autres personnes. {complete} exprime l’idée qu’un
enseignant ne peut être autre chose qu’un permanent ou un vacataire.

III.2.2.5) Les Classes concrètes – Les Classes Abstraites

UML permet de spécifier une classe de manière incomplète en ne définissant pas certaines
opérations. Ces classes dites abstraites, n’étant pas complètement spécifiées, ne peuvent pas
être instanciées. Ce sont les classes enfants qui compléteront cette spécification en
définissant les opérations non encore définies. Ces classes sont appelées des classes
concrètes ; toutes les classes sont par défaut complètes, c’est-à-dire avec des opérations
définies. Les opérations non définies sont dites abstraites et sont écrites en italique dans les
diagrammes de classes. Dès qu’une opération est abstraite, sa classe devient abstraite. Une
seconde utilisation des classes abstraites est d’empêcher l’instanciation de la classe.

Ici, un Média peut être transporté, dupliqué, affiché. Le transport et la duplication sont
indépendants du type de Média (copie de fichiers). Par contre, tout Média peut être affiché
et ce n’est pas la même chose pour le Livre, la Vidéo, le Graphique ou le Texte. Un Média ne
peut pas définir comment il s’affiche tant qu’il ne sait pas ce qu’il est.
 COURS MODELISATION AVEC UML
Il n’existe pas d’instance de la classe Média. Un Média n’existe qu’en tant que Livre, Texte,
Graphique ou Vidéo.
III.2.2.6) Les Interfaces et les Relations de réalisation

Une interface permet de décrire le comportement d’une classe, c’est-à-dire un savoir-faire

sous la forme d’une liste de déclarations d’opérations sans leur définition. Une interface ne
peut donner lieu à aucune instance. Toutes les opérations d’une interface sont abstraites.
Ainsi, une interface est équivalente à une classe abstraite, avec la particularité
supplémentaire qu’une interface ne possède pas d’attribut. Une classe peut déclarer qu’elle
« réalise » une interface, c’est-à-dire qu’elle définit un corps à toutes les opérations
abstraites de l’interface. Une telle classe peut ensuite être utilisée partout où un objet
respectant le contrat de l’interface est attendu. Si une classe ne réalise pas toutes les
opérations abstraites de l’interface, alors cette classe est abstraite. Une classe enfant de cette
dernière classe peut compléter la concrétisation en définissant les dernières opérations
abstraites ; la classe enfant devient alors concrète.

Le lien de réalisation qui est aussi (de manière non adéquate) appelé lien d’implantation
entre une classe abstraite et une classe concrète est modélisé similairement au lien
d’héritage, la différence étant le trait qui est en pointillé. Il est possible de spécifier des
hiérarchies d’interfaces, ainsi que des hiérarchies impliquant des interfaces, des classes
abstraites et des classes concrètes. Bien sûr, dans de telles hiérarchies, une interface ne peut
pas hériter d’une classe, qu’elle soit abstraite ou concrète ; c’est toujours l’inverse, c’est-à-
dire une classe abstraite ou concrète réalisant le contrat d’une interface, qui peut être
dessinée.

Graphiquement, la réalisation se représente par un trait discontinu terminé par une flèche
triangulaire parfois, mais pas nécessairement, stéréotypé « realize ».
Exemple 1 :

Exemple 2 :
 COURS MODELISATION AVEC UML
La relation de réalisation se représente en fait comme une relation d'héritage avec une ligne
en pointillés. La raison de cette notation est que cette relation dénote une forme d'héritage
partiel : héritage comportemental mais pas structurel. Une classe qui réalise (implémente)
une interface est dans l'obligation de définir les méthodes décrites par l'interface (notion de
contrat à respecter) comme lorsqu'une classe concrète redéfinie les méthodes abstraites
héritées de sa classe parente abstraite.

III.3) Diagramme d’objets

Un diagramme d’objets est particulièrement utile quand vous voulez décrire comment les
objets dans le système « travaillent » ensemble dans un scénario donné. Un diagramme
d’objets représente une configuration donnée. La notation UML de l’objet est très simple. Un
objet est un rectangle avec le nom de l’objet et le nom de la classe séparés par le signe « : »
et soulignés. Le nom de l’objet est facultatif : sans nom d’objet, l’objet est dit « anonyme ».
Lorsque deux classes sont reliées par deux associations, le nom de l’instance d’association
dessinée doit être précisé pour lever l’ambiguïté. Clairement, un diagramme d’objets doit
respecter les contraintes d’un diagramme de classes : par exemple, ne pas tracer de liens
entre deux objets dont les classes ne sont pas reliées dans le diagramme de classes.
✗ Le diagramme d’objets fait partie des diagrammes structurels (statique).
✗ Il représente les objets d’un système (c.a.d. les instances des classes) et leurs liens (c.a.d.
les instances des associations) à un instant donné.
✗ Il donne une vue figée du système à un moment précis.
✗ A un diagramme de classe correspond une infinité de diagrammes d’objets.
✗ Nous nous servirons du diagramme d’objet pour donner des exemples, des cas de figure,
qui permettront d’affiner le diagramme de classe et de mieux le comprendre.
Exemples de Représentation graphique
Chaque objet est représenté dans un rectangle dans lequel figure le nom de l’objet (souligné)
et éventuellement la valeur de un ou plusieurs de ses attributs. Comme pour la
représentation d’une classe, la représentation d’un objet pourra être plus ou moins détaillée.
Exemple :
 COURS MODELISATION AVEC UML

Exemple 2 :
Soit le diagramme de classe suivant :

Avec le diagramme objet ci-dessous on définit une instance particulière du diagramme de

classe (qui est le combat entre Mohamed Ali et George Foreman qui a eu lieu le 24
septembre 1974 à Kinshasa) :

III.4) Diagramme des cas d’utilisations

III.4.1) Introduction

Les cas d’utilisation représentent les fonctionnalités que le système doit satisfaire. Chaque
cas d’utilisation peut être complété par un ensemble d’interactions successives d’une entité
en dehors du système (l’utilisateur) avec le système lui-même. Les cas d’utilisation
permettent :
 COURS MODELISATION AVEC UML
de connaître le comportement du système sans spécifier comment ce comportement est
réalisé, de définir les limites précises du système, de comprendre l’attente des utilisateurs et
des experts du domaine. Les cas d’utilisation sont aussi des instruments de validation et
d’évaluation de l’avancement du système en cours et en fin de construction.
III.4.2) Principaux éléments des diagrammes de cas d’utilisation

L'acteur
Il représente un élément externe qui interagit avec le système. Cet élément peut être un
utilisateur ou un système tiers (autre ordinateur, autre programme, base de donnée).
Tous les éléments extérieurs qui stimulent le système et tous les éléments extérieurs qui sont
utilisés par le système sont représentés par des acteurs.
Dans le cas d'acteurs non-humains il est possible de définir une « Interface » qui représente
les opérations offertes par cet acteur.
Il est possible de représenter un acteur sous forme d'un bonhomme comme ci-dessous à
gauche ou sous forme d'un classeur comme ci-dessous à droite.

Le cas d'utilisation
Un cas d'utilisation représente une fonctionnalité du système. Cette fonctionnalité est définie
par une action déclenchante, un ou plusieurs déroulements possibles et éventuellement une
fin. Les différents déroulements aussi appelés scénarii seront modéliser par des diagrammes
de séquence, d'activité ou d'état. Le cas d'utilisation se représente par une ellipse contenant
un nom décrivant la fonctionnalité et éventuellement un stéréotype.
Remarque : Le nom du use case doit se composer d'un verbe à l'infinitif qui décrit une action.
Pour que l'ensemble du modèle soit cohérent il faut choisir tous les verbes soit du point de
vue du système soit du point de vue de l'utilisateur (ce qui est généralement préférable).

Description textuelle du cas d'utilisation

Le cas d'utilisation est habituellement doublé d'une description textuelle qui précise sa
description. Cette description se compose habituellement des points suivants :
• Nom : Utiliser une tournure à l’infinitif (ex : Réceptionner un colis).
• Objectif : Une description résumée permettant de comprendre l’intention principale
du cas d’utilisation. Cette partie est souvent renseignée au début du projet dans la
phase de découverte des cas d’utilisation.
 COURS MODELISATION AVEC UML
• Acteurs principaux : Ceux qui vont réaliser le cas d’utilisation (la relation avec le cas
d’utilisation est illustrée par le trait liant le cas d’utilisation et l’acteur dans un
diagramme de cas d’utilisation)
• Acteurs secondaires : Ceux qui ne font que recevoir des informations à l’issue de la
réalisation du cas d’utilisation
• Les pré-conditions qui décrivent l'état du système avant que ce cas d’utilisation puisse
être déclenché.
• Description de la séquence nominale qui décrit le déroulement normal du cas avec
éventuellement référence au diagramme de séquence associé.
• Description éventuelle des séquences alternatives avec éventuellement référence au
diagramme de séquence associé.
• Description des séquences d’exceptions avec éventuellement référence au
diagramme de séquence associé.
• Liste des cas non traités.
• Les post-conditions qui décrivent le système à la fin du traitement.
• Les besoins en interfaces graphiques.
• Tous les autres besoins pas forcément techniques mais juridiques, commerciaux ou
autres.
Exemple de Diagramme de cas d'utilisation
Le diagramme des cas d'utilisation se présente comme ci-dessous :

La relation d'association Acteur – Cas d'utilisation

Les acteurs et les cas d'utilisation sont reliés par des associations qui peuvent être primaires
ou secondaires. L'association primaire est réservée à l'acteur « primaire » pour lequel la
fonctionnalité est produite et l'association secondaire est utilisée pour le ou les acteurs
« secondaires » utilisés par le système pour réaliser la fonctionnalité.
L'utilisation des multiplicités est possible pour définir le nombre (0..1, 1, 1..*, 0..*, n, n..m, *)
d'utilisations possibles du cas d'utilisation. Cette multiplicité ne donne aucune indication de
simultanéité.
 COURS MODELISATION AVEC UML

Les relations entre cas d'utilisation

De nombreuses relations de dépendance peuvent être définies entre les cas d'utilisation par
l'utilisation des stéréotypes notés « stereotype ». Cependant il faut faire attention à ne pas
essayer de représenter la chronologie des actions par l'intermédiaire de ces relations. La
chronologie des traitements se représente par des diagrammes dynamiques comme les
diagrammes de séquence, d'état ou d'activité.
Dans l'exemple ci-dessous nous avons les principales relations d'associations entre cas
d'utilisation :
• L'inclusion « include » : Cela implique obligatoirement l'inclusion d'un cas d'utilisation
dans un autre comme ici « Retire argent » fait obligatoirement appel à
« S'authentifier ».
• L'extension « extended » : Cela permet éventuellement l'extension d'un cas
d'utilisation par un autre comme ici « Vérifier solde » peut étendre « Effectuer
virement ».
• Le point d'extension : Il est possible de préciser exactement à quel moment une
extension est appelée comme ci-dessous par un « Extension points » ici
« verification_solde {après avoir demandé le montant}.
• La condition d'extension : Il est possible d'ajouter en note sous quelle condition
l'extension doit se produire comme ci-dessous si le montant est supérieur à 20€.
• L'héritage : Il permet de définir la spécialisation d'un cas d'utilisation comme ici
consulter un compte depuis le DAB ou consulter le compte depuis Internet.
 COURS MODELISATION AVEC UML

Les relations entre acteurs

Enfin, il est possible de définir une relation d'héritage entre acteurs afin d'éviter de
surcharger les diagrammes. Un acteur qui hérite d'un autre acteur hérite de toutes ses
associations.