Chapitre 1 : Présentation de UML

Introduction
L’informatisation est le phénomène le plus important de notre époque. Elle s’immisce
maintenant dans la plupart des objets de la vie courante et ce, que ce soit dans l’objet proprement
dit ou bien dans le processus de conception ou de fabrication de cet objet.
Un logiciel ou une application est un ensemble de programmes, qui permet à un
ordinateur ou à un système informatique d’assurer une tâche ou une fonction en particulier
(exemple : logiciel de comptabilité, logiciel de gestion des prêts). Les logiciels, suivant leur taille,
peuvent être développés par une personne seule, une petite équipe, ou un ensemble d’équipes
coordonnées. Or, le développement d’un logiciel est une phase absolument cruciale qui
monopolise l’essentiel du coût d’un produit et conditionne sa réussite et sa pérennité.
L’importance d’une approche méthodologique dans le développement du logiciel s’est imposée à
la suite de la crise de l’industrie du logiciel à la fin des années 1970. Pour apporter une réponse à
cette crise, le génie logiciel a vu le jour.
Le génie logiciel est un domaine de l’ingénierie ayant pour objectif de répondre à un
problème qui s’énonçait en deux constatations :
 D’une part le logiciel n’était pas fiable,
 D’autre part, il était incroyablement difficile de réaliser dans des délais prévus des
logiciels satisfaisant leur cahier des charges.
L’objectif du génie logiciel est d’optimiser le coût de développement du logiciel. Cela a mis à
jour de nombreuses méthodes de modélisation pour développer un logiciel.

I. Pourquoi et comment modéliser ?

1. Qu’est-ce qu’un modèle ?
Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails),
d’une entité (phénomène, processus, système, etc.) du monde réel en vue de le décrire, de
l’expliquer ou de le prévoir. Modèle est synonyme de théorie, mais avec une connotation pratique
: un modèle, c’est une théorie orientée vers l’action qu’elle doit servir.
Concrètement, un modèle permet de réduire la complexité d’un phénomène en éliminant
les détails qui n’influencent pas son comportement de manière significative. Il reflète ce que le
concepteur croit important pour la compréhension et la prédiction du phénomène modélisé, les
limites du phénomène modélisé dépendant des objectifs du modèle
2. Pourquoi modéliser ?
Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement
du système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence.
Un modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et il
est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essentielle
1
pour aboutir à une compréhension commune aux différentes parties prenantes (notamment entre
la maîtrise d’ouvrage et maîtrise d’œuvre informatique) et précise d’un problème donné.
Dans le domaine de l’ingénierie du logiciel, le modèle permet de mieux répartir les tâches
et d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts et des
délais. Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles
pour faire de la génération de code (au moins au niveau du squelette) voire des aller-retours entre
le code et le modèle sans perte d’information. Le modèle est enfin indispensable pour assurer un
bon niveau de qualité et une maintenance efficace. En effet, une fois mise en production,
l’application va devoir être maintenue, probablement par une autre équipe et, qui plus est, pas
nécessairement de la même société que celle ayant créée l’application.
Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes
nontriviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les modèles
employés, la démarche de modélisation n’est pas la même.
3. Qui doit modéliser ?
La modélisation est souvent faite par la maîtrise d’oeuvre informatique (MOE). C’est
malencontreux, car les priorités de la MOE résident dans le fonctionnement de la plate-forme
informatique et non dans les processus de l’entreprise. Il est préférable que la modélisation soit
réalisée par la maîtrise d’ouvrage (MOA) de sorte que le métier soit maître de ses propres
concepts. La MOE doit intervenir dans le modèle lorsque, après avoir défini les concepts du
métier, on doit introduire les contraintes propres à la plate-forme informatique.
Il est vrai que les métiers, dont les priorités sont opérationnelles, ne disposent pas toujours
de la capacité d’abstraction, de la rigueur conceptuelle nécessaires à la formalisation. La
professionnalisation de la MOA a pour but de les doter de ces compétences. Cette
professionnalisation réside essentiellement dans l’aptitude à modéliser le système d’information
du métier : le maître mot est modélisation. Lorsque le modèle du système d’information est de
bonne qualité, sobre, clair, stable, la maîtrise d’oeuvre peut travailler dans de bonnes conditions.
Lorsque cette professionnalisation a lieu, elle modifie les rapports avec l’informatique et déplace
la frontière des responsabilités, ce qui contrarie parfois les informaticiens dans un premier temps,
avant qu’ils n’en voient apparaître les bénéfices.
4. Maîtrise d’ouvrage et maîtrise d’oeuvre
Maître d’ouvrage (MOA) : Le MOA est une personne morale (entreprise, direction etc.),
une entité de l’organisation. Ce n’est jamais une personne.
Maître d’oeuvre (MOE) : Le MOE est une personne morale (entreprise, direction etc.)
garante de la bonne réalisation technique des solutions. Il a, lors de la conception du SI, un devoir
de conseil vis-à-vis du MOA, car le SI doit tirer le meilleur parti des possibilités techniques.

II. Historique de UML

2
 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).

III. Définition de UML

UML permet 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.
1. 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.
3
 2. 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 ! Une méthode propose
un processus, qui régit notamment l'enchaînement des activités de production d'une entreprise.
UML a été pensé pour permettre de modéliser les activités de l'entreprise, pas pour les régir.
3. UML est un langage pseudo-formel
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.
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.
4. UML cadre l'analyse objet
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. Il offre différentes vues (perspectives) complémentaires
d'un système, qui guident l'utilisation des concept objets ; ainsi que plusieurs niveaux
d'abstraction, qui permettent de mieux contrôler la complexité dans l'expression des solutions
objets.
5. 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.

4
IV. Les points forts d'UML
1. UML est un langage formel et normalisé
 gain de précision
 gage de stabilité
 encourage l'utilisation d'outils
2. UML est un support de communication performant
 Il cadre l'analyse.
 Il facilite la compréhension de représentations abstraites complexes.
 Son caractère polyvalent et sa souplesse en font un langage universel.

V. Les points faibles d'UML

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

2. Le processus (non couvert par UML) est une autre clé de la réussite d'un projet.

Or, l'intégration d'UML dans un processus n'est pas triviale et améliorer un processus
est un tâche complexe et longue. Les auteurs d'UML sont tout à fait conscients de
l'importance du processus, mais l'acceptabilité industrielle de la modélisation objet passe
d'abord par la disponibilité d'un langage d'analyse objet performant et standard.

VI. Caractéristiques de UML

UML n’est pas une méthode (i.e. une description normative des étapes de la modélisation) :
ses auteurs ont en effet estimé qu’il n’était pas opportun de définir une méthode en raison de la
diversité des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet
de représenter, de communiquer les divers aspects d’un système d’information (aux graphiques
sont bien sûr associés des textes qui expliquent leur contenu). UML est donc un métalangage car
il fournit les éléments permettant de construire le modèle qui, lui, sera le langage du projet.
Il est impossible de donner une représentation graphique complète d’un logiciel, ou de tout autre
système complexe, de même qu’il est impossible de représenter entièrement une statue (à trois
dimensions) par des photographies (à deux dimensions). Mais il est possible de donner sur un tel
système des vues partielles, analogues chacune à une photographie d’une statue, et dont la

5
juxtaposition donnera une idée utilisable en pratique sans risque d’erreur grave. UML offre
une manière élégante de représenter le système selon différentes vues
complémentaires grâce aux diagrammes. Ces diagrammes permettent de définir une
application selon plusieurs points de vue :
 Fonctionnel (cas d'utilisation)
 Statique (classes, objets, structure composite)
 Dynamique (séquence, états, activité, interaction, communication, temps)
 Implémentation (composants, déploiement, paquetage)
Les diagrammes seuls ne permettent pas de définir toutes les contraintes de spécification
requises d’où l’utilisation du langage textuel de contraintes OCL en complément s'applique sur
les éléments de la plupart des diagrammes
UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes
pour représenter des concepts particuliers du système d’information. Ils se répartissent en deux
grands groupes :
1. Diagrammes structurels ou diagrammes statiques (UML Structure)
– diagramme de classes (Class diagram)
– diagramme d’objets (Object diagram)
– diagramme de composants (Component diagram)
– diagramme de déploiement (Deployment diagram)
– diagramme de paquetages (Package diagram)
– diagramme de structures composites (Composite structure diagram)
2. Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
– diagramme de cas d’utilisation (Use case diagram)
– diagramme d’activités (Activity diagram)
– diagramme d’états-transitions (State machine diagram)
– Diagrammes d’interaction (Interaction diagram)
– diagramme de séquence (Sequence diagram)
– diagramme de communication (Communication diagram)
– diagramme global d’interaction (Interaction overview diagram)
– diagramme de temps (Timing diagram)
Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tous
produits à l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les
6
diagrammes d’activités, de cas d’utilisation, de classes, d’objets, de séquence et d’états-
transitions. Les diagrammes de composants, de déploiement et de communication sont surtout
utiles pour la maîtrise d’oeuvre à qui ils permettent de formaliser les contraintes de la réalisation
et la solution technique.
Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation (cf. section 2) représente la structure des grandes
fonctionnalités nécessaires aux utilisateurs du système. C’est le premier diagramme du modèle
UML, celui où s’assure la relation entre l’utilisateur et les objets que le système met en oeuvre.
Diagramme de classes
Le diagramme de classes (cf. section 3) est généralement considéré comme le plus
important dans un développement orienté objet. Il représente l’architecture conceptuelle du
système : il décrit les classes que le système utilise, ainsi que leurs liens, que ceux-ci représentent
un emboîtage conceptuel (héritage) ou une relation organique (agrégation).
Diagramme d’objets
Le diagramme d’objets permet d’éclairer un diagramme de classes en l’illustrant par des
exemples. Il est, par exemple, utilisé pour vérifier l’adéquation d’un diagramme de classes à
différents cas possibles.
Diagramme d’états-transitions
Le diagramme d’états-transitions représente la façon dont évoluent (i.e. cycle de vie) les
objets appartenant à une même classe. La modélisation du cycle de vie est essentielle pour
représenter et mettre en forme la dynamique du système.
Diagramme d’activités
Le diagramme d’activités n’est autre que la transcription dans UML de la représentation
du processus telle qu’elle a été élaborée lors du travail qui a préparé la modélisation : il montre
l’enchaînement des activités qui concourent au processus.
Diagramme de séquence et de communication
Le diagramme de séquence représente la succession chronologique des opérations
réalisées par un acteur. Il indique les objets que l’acteur va manipuler et les opérations qui font
passer d’un objet à l’autre. On peut représenter les mêmes opérations par un diagramme de
communication, graphe dont les noeuds sont des objets et les arcs (numérotés selon la
chronologie) les échanges entre objets. En fait, diagramme de séquence et diagramme de
communication sont deux vues différentes mais logiquement équivalentes (on peut construire
l’une à partir de l’autre) d’une même chronologie. Ce sont des diagrammes d’interaction .
VII. Comment modéliser avec UML ?
1. Proposition de démarche

7
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.
1.1. 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.
1.2. 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.
1.3. 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

8
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 ».

Vue des
Vue logique
composants

Vue de
Vue des processus
déploiement
Vue des cas d'utilisation
2. La vue « 4+1 » de ph. Kruchten
2.1. 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...
2.2. 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 :

9
• 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).
2.3. 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).
2.4. 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...).
2.5. 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.

10
3. Les niveaux d’abstraction
3.1. 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.
3.2. Les niveaux d’abstraction
3.2.1. 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.
3.2.2. 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...
3.2.3. Analyse applicative

11
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.
3.2.4. 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.

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.

12
 Chapitre 2 : Le diagramme de cas d’utilisation
Introduction
UML permet de définir et de visualiser un modèle, à l'aide de 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, 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).
La structure des diagrammes UML et la notation graphique des éléments de modélisation
est normalisée. Il existe 2 types de vues du système qui comportent chacune leurs propres
diagrammes :
• les vues statiques :
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.

◦ diagrammes de cas d'utilisation

◦ diagrammes d'objets
◦ diagrammes de classes
◦ diagrammes de composants
◦ diagrammes de déploiement
• les vues dynamiques :
◦ diagrammes de collaboration

13
◦ diagrammes de séquence
◦ diagrammes d'états-transitions
◦ diagrammes d'activités

I. Définition du diagramme de cas d’utilisation (use case)

Le diagramme de cas d’utilisation décrit les fonctionnalités d’un point de vue utilisateur, sous
la forme d’actions et de réactions ; l’ensemble des fonctionnalités est déterminé en examinant les
besoins fonctionnels de tous les utilisateurs.
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). Le but est d’identifier :
 Les catégories d’utilisateurs (acteurs) susceptible de mettre en œuvre une ou plusieurs
fonctionnalités du système
 Les besoins du système : chaque fonctionnalité doit répondre à un des besoins
nécessités par un ou plusieurs catégories d’utilisateurs
Les cas d’utilisation identifient les utilisateurs du système (acteurs) et leurs interactions avec
le 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.
Le diagramme des cas d’utilisation se base sur le cahier des charges pour être construit ; il
fait donc partie en terme de gestion de projet de la spécification du système.
II. Les éléments de construction d’un diagramme de cas d’utilisation
1. 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. Un acteur est un type stéréotypé représentant une
abstraction qui réside juste en dehors du système à modéliser.

14
 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.
Il se représente par un petit bonhomme avec son nom inscrit dessous

Il est également possible de représenter un acteur sous la forme d’un classeur stéréotypé

2. Cas d’utilisation
Un cas d’utilisation est une unité cohérente d’une fonctionnalité visible
de l’extérieur. Il réalise un service de bout en bout, avec un déclenchement,
un déroulement et une fin, pour l’acteur qui l’initie. Un cas d’utilisation
modélise donc un service rendu par le système, sans imposer le mode de
réalisation de ce service. 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.

15
 Un cas d’utilisation se représente par une ellipse contenant le nom du
cas (un verbe à l’infinitif), et optionnellement, au-dessus du nom, un
stéréotype

Dans le cas où l’on désire présenter les attributs ou les opérations du cas d’utilisation, il est
préférable de le représenter sous la forme d’un classeur stéréotypé « use case »

3. La relation
Elle exprime l’interaction existant entre un acteur et un cas
d’utilisation. Il existe 3 types de relations entre cas d’utilisation :
◦ la relation de généralisation
◦ la relation d’extension
◦ la relation d’inclusion
3.1. la relation 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. Un cas A est une généralisation d’un cas B si B est
un cas particulier de A. Dans la figure, la consultation d’un compte via Internet est un cas
particulier de la consultation. Cette relation de généralisation/spécialisation est présente dans la
plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés
objet.

16
 3.2. 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. Un
cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B : le
cas A dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. Cette
dépendance est symbolisée par le stéréotype « include ». Par exemple, l’accès aux informations
d’un compte bancaire inclut nécessairement une phase d’authentification avec un identifiant et un
mot de passe.

17
 Les inclusions permettent essentiellement de factoriser une partie de la description d’un
cas d’utilisation qui serait commune à d’autres cas d’utilisation (cf. le cas S’authentifier).
3.3. Relation d’extension
La relation d’extension est probablement la plus utile car elle a une sémantique qui a un
sens du point de vue métier au contraire des deux autres qui sont plus des artifices
d’informaticiens. On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas
d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut
éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est
optionnelle. Cette dépendance est symbolisée par le stéréotype « extend ».
L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle le point
d’extension. Une extension est souvent soumise à condition. Graphiquement, la condition est
exprimée sous la forme d’une note. L’exemple de la banque où la vérification du solde du compte
n’intervient que si la demande de retrait dépasse 20 euros.
4. Relations entre acteurs

18
 La seule relation possible entre deux acteurs est la généralisation : un acteur A est une
généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas, tous les
cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.
Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein dont
la pointe est un triangle fermé désignant l’acteur le plus général (comme nous l’avons déjà vu
pour la relation de généralisation entre cas d’utilisation). Par exemple, la figure montre que le
directeur des ventes est un préposé aux commandes avec un pouvoir supplémentaire : en plus de
pouvoir passer et suivre une commande, il peut gérer le stock. Par contre, le préposé aux
commandes ne peut pas gérer le stock.

Remarques : 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înes
de caractères entre guillemets (« ») dans, ou à proximité du symbole de l’élément de modèle de
base.
III. Comment identifier les acteurs ?
UML n’emploie pas le terme d’utilisateur mais d’acteur. Les acteurs d’un
système sont les entités externes à ce système qui interagissent (saisie de données, réception
d’information, . . .) avec lui. Les acteurs sont donc à l’extérieur du système et dialoguent avec lui.
Ces acteurs permettent de cerner l’interface que le système va devoir offrir à son environnement.
Oublier des acteurs ou en identifier de faux conduit donc nécessairement à se tromper sur
l’interface et donc la définition du système à produire. Il faut faire attention à ne pas confondre
acteurs et utilisateurs (utilisateur avec le sens de la personne physique qui va appuyer sur un
bouton) d’un système. D’une part parce que les acteurs inclus les utilisateurs humains mais aussi
les autres systèmes informatiques ou hardware qui vont communiquer avec le système. D’autre
part parce que un acteur englobe tout une classe d’utilisateur. Ainsi, plusieurs utilisateurs peuvent
avoir le même rôle, et donc correspondre à un même acteur, et une même personne physique peut
jouer des rôles différents vis-à-vis du système, et donc correspondre à plusieurs acteurs.

19
Chaque acteur doit être nommé. Ce nom doit refléter sont rôle car un acteur représente un
ensemble cohérent de rôles joués vis-à-vis du système.
Pour trouver les acteurs d’un système, il faut identifier quels sont les différents rôles que vont
devoir jouer ses utilisateurs (ex : responsable clientèle, responsable d’agence, administrateur,
approbateur, . . .). Il faut également s’intéresser aux autres systèmes avec lesquels le système va
devoir communiquer comme :
– les périphériques manipulés par le système (imprimantes, hardware d’un distributeur de
billet, . . .) ;
– des logiciels déjà disponibles à intégrer dans le projet ;
– des systèmes informatiques externes au système mais qui interagissent avec lui, etc.
Pour faciliter la recherche des acteurs, on peut imaginer les frontières du système. Tout ce qui est
à l’extérieur et qui interagit avec le système est un acteur, tout ce qui est à l’intérieur est une
fonctionnalité à réaliser.
Vérifiez que les acteurs communiquent bien directement avec le système par émission ou
réception de messages. Une erreur fréquente consiste à répertorier en tant qu’actera des entités
externes qui n’interagissent pas directement avec le système, mais uniquement par le biais d’un
des véritables acteurs. Par exemple, l’hôtesse de caisse d’un magasin de grande distribution est
un acteur pour la caisse enregistreuse, par contre, les clients du magasins ne correspondent pas à
un acteur car ils n’interagissent pas directement avec la caisse.
IV. Comment recenser les cas d’utilisation ?
L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences
fonctionnelles du système. Chaque cas d’utilisation correspond donc à une fonction métier du
système, selon le point de vue d’un de ses acteurs. Aussi, pour identifier les cas d’utilisation, il
faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se
sert du système. Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon
niveau d’abstraction. Trouver le bon niveau de détail pour les cas d’utilisation est un problème
difficile qui nécessite de l’expérience.
Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément
en vous plaçant du point de vue de l’acteur et non pas de celui du système. Par exemple, un
distributeur de billets aura probablement un cas d’utilisation Retirer de l’argent et non pas
Distribuer de l’argent.
De par la nature fonctionnelle, et non objet, des cas d’utilisation, et en raison de la difficulté de
trouver le bon niveau de détail, il faut être très vigilant pour ne pas retomber dans une
décomposition fonctionnelle descendante hiérarchique. Un nombre trop important de cas
d’utilisation est en général le symptôme de ce type d’erreur.
Dans tous les cas, il faut bien garder à l’esprit qu’il n’y a pas de notion temporelle dans un
diagramme de cas d’utilisation.

20
 V. Description textuelle des cas d’utilisation
Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du
point de vue des acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les
cas d’utilisation. Bien que de nombreux diagrammes d’UML permettent de décrire un cas, il est
recommandé de rédiger une description textuelle car c’est une forme souple qui convient dans
bien des situations. Une description textuelle couramment utilisée se compose de trois parties.
1. La première partie permet d’identifier le cas, elle doit contenir les informations qui suivent.
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.
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
Dates : Les dates de créations et de mise à jour de la description courante. Responsable : Le nom
des responsables.
Version : Le numéro de version.
2. La deuxième partie contient la description du fonctionnement du cas sous la forme d’une
séquence de messages échangés entre les acteurs et le système. Elle contient toujours une
séquence nominale qui décrit de déroulement normal du cas. À la séquence nominale s’ajoutent
fréquemment des séquences alternatives (des embranchement dans la séquence nominale) et des
séquences d’exceptions (qui interviennent quand une erreur se produit).
Les préconditions : elles décrivent dans quel état doit être le système (l’application) avant que ce
cas d’utilisation puisse être déclenché.
Des scénario : Ces scénarii sont décrits sous la forme d’échanges d’évènements entre l’acteur et
le système. On distingue le scénario nominal, qui se déroule quand il n’y a pas d’erreur, des
scénario alternatifs qui sont les variantes du scénario nominal et enfin les scénario d’exception
qui décrivent les cas d’erreurs.
Des postconditions : Elles décrivent l’état du système à l’issue des différents scénarii.
3. La troisième partie de la description d’un cas d’utilisation est une rubrique optionnelle. Elle
contient généralement des spécifications non fonctionnelles (spécifications techniques, . . .). Elle
peut éventuellement contenir une description des besoins en termes d’interface graphique.

21
Remarques : 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.

VI. Élaboration 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 quel 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.

22
 Chapitre 3 : Diagramme de classe et d’objet

I. 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. Le diagramme de classes est considéré comme le plus important de
la modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation. Alors que le
diagramme de cas d’utilisation montre un système du point de vue des acteurs, le diagramme de
classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets
du système qui vont interagir ensemble pour réaliser les cas d’utilisation
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

II. Notion de classe

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

Son 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
23
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 sous-types 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.
◦ « utilitaire » : il s’agit d’une classe réduite au concept de module et qui ne peut être instanciée.

III. La notion d’attribut

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 :

24
 NOM CLASSE
Attribut_1 :int
Attribut_2 :int
Attribut_3 :int

Operation_1 ():void
Operation_2 ():void

UML définit 3 niveaux de visibilité pour les attributs :

◦ public (+) : l’élément est visible pour tous les clients de la classe
◦ protégé (#) : l’élément est visible pour les sous-classes de la classe
◦ privé (-) : l’élément n’est visible que par les objets de la classe dans laquelle il est déclaré.
Formalisme :
NOM CLASSE
+ Attribut public : int
# Attribut protégé : int
- Attribut privé : int

IV. 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. Son formalisme :
FACTURE
+No facture : n
+ Date : double
+ Montant : double
+ / Montant TVA: n

25
 V. La notion d’opération
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. Son formalisme :
FACTURE
+No facture : n
+ Date : double
+ Montant : double
+ / Montant TVA: n
Editer () :void
Consulter () : void
Créer (): void

Comme pour les attributs, on retrouve 3 niveaux de visibilité pour les opérations :
◦ public (+) : l’opération est visible pour tous les clients de la classe
◦ protégé (#) : l’opération est visible pour les sous-classes de la classe
◦ privé (-) : l’opération n’est visible que par les objets de la classe dans laquelle elle est
déclarée.
Son formalisme :
FACTURE
+No facture: int
+Date: Date
+Montant: double
+/ Montant TVA: double
+ Op publique ()
# Op protégée ()
- Op privée ()

26
 VI. 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
◦ la généralisation/spécialisation
◦ la dépendance
1. 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 Un et un seul
0..1 Zéro ou un
N ou * N (entier naturel)
M..N De M à N (entiers naturels)
0..* De zéros à plusieurs
1..* De 1 à plusieurs

Formalisme et exemple en employant les noms des rôles et leur multiplicité :

Société 0..1 0..* personne

Employeur employé

27
Formalisme et exemple en employant le nom de l’association et la multiplicité des rôles :
Société 0..1 0..* personne
Employer

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

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

28
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 commander Produit

numcom codeprod

Qtitécom

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

commande lignecommande 1..1 Produit

0..*
numcom qtitécom codeprod
1..1 0..*

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.
1.2. 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
29
Formalisme et exemple :
véhicule
Type 0..*

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..* véhicule

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

1.3. 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.
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 :

30
 véhicule

1..* 1..*

Chassis Moteur
1..1
1..1

2. La 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.
Formalisme et exemple :

31
La specialisation 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 :

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 :
• La contrainte de partition
Elle indique que toutes les instances d’une classe correspondent à une et une seule instance des
classes liées.
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.

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.

32
Exemple :

3. 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 :

3.1. 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.
Les mots-clés sont :
◦ « 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.
◦ « raffine »
Représente une relation de dépendance entre des éléments sémantiques différents (analyse et
conception par exemple).
◦ « 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)
◦ « trace »
Représente l’historique des constructions présentes dans les différents modèles.
3.2. Liaison

33
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).
◦ « lie »
3.3. Permission
Un élément (source) a le droit d’accéder à un espace de nommage (cible)
◦ « 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.
3.4. Utilisation
Un élément (source) requiert la présence d’un autre élément (cible) pour son bon fonctionnement
ou son implémentation.
◦ « utilise »
◦ « « 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.
◦ « crée »
Représente le classificateur source qui crée une instance du classificateur cible ◦ « 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.
Formalisme :
Classe
A

<<derive>>

Classe
B

34
 VII. 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.
Exemple et formalisme :

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.

35
VIII. Élaboration d’un diagramme de classes
1. 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.
2. 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.

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

36