Université de Batna II - Pôle Fesdis

Département Informatique

Support de cours :

Génie logiciel

Enseignant : Dr Sofiane AOUAG

Cours destiné aux étudiants en L3 SI

Table des matières

0. Introduction
0.1 Description du cours ................................................................................................... 1
0.2 Objectifs du cours ...................................................................................................... 4
1. Chapitre I : Analyse des besoins et définition du problème
1.1 Introduction ............................................................................................................... 5
1.2 Définition du problème................................................................................................ 6
1.3 Grilles de Levesques ................................................................................................... 7
1.3.1 Application des Grilles de Levesque ..................................................................... 8
1.4 Délimitation du périmètre du système ........................................................................ 9
2. Chapitre II : Digramme de cas d’utilisation
2.1 Introduction ............................................................................................................. 10
2.2 Éléments graphiques d’un diagramme de cas d’utilisation ........................................ 10
2.3 Formalisme de diagramme de cas d’utilisation .......................................................... 11
2.3.1 Identifier les acteurs .......................................................................................... 11
2.3.2 formaliser les cas d’utilisation .......................................................................... 12
2.4 Relations et stéréotypes dans le diagramme de cas d’utilisation ............................... 13
2.4.1 Relation d’include ............................................................................................ 13
2.4.2 Relation Extends .............................................................................................. 14
2.4.3 Relation d’héritage (généralisation et spécialisation) ........................................ 15
2.5 Rédaction de cas d’utilisation selon le Formlulaire de Cockburn ............................... 16
2.5.1 Rubriques de Cockburn...................................................................................... 16
2.5.2 Exemple Domaine ............................................................................................ 17
2.6 Conclusion ................................................................................................................. 18
3. Diagramme d’activité
3.1 Introduction ............................................................................................................. 19
3.2 Eléments graphiques de diagramme d’activité .......................................................... 19
3.3 Formalisme d’un diagramme d’activité ..................................................................... 21
3.4 Flot de contrôle et synchronisation dans le diagramme d’activité ............................. 23
3.4.1 Synchronisation disjonctive (embranchement) ................................................ 23
3.4.2 Synchronisation conjonctive (conjonction) ....................................................... 24
3.4.3 Les couloirs dans le diagramme d’activité ........................................................ 25
3.4.4 Flux d’objet ............................................................................................................ 26
3.5 Conclusion ................................................................................................................. 28
4. Chapitre IV : Diagramme de classes
4.1 Introduction ............................................................................................................. 29
4.2 Éléments graphiques d’un diagramme de classes...................................................... 29
4.3 Formalisme d’un diagramme de classes ................................................................... 31
4.3.1 La multiplicité ................................................................................................. 31
4.3.2 Notion d’association ........................................................................................ 32
4.3.3 Association binaire et n-aire ............................................................................ 32
4.3.4 Association avec navigabilité et contraintes ..................................................... 33
4.3.5 Association dérivée .......................................................................................... 34
4.3.6 Classe-Association ........................................................................................... 35
4.4. Relations dans le diagramme de classes ................................................................... 36
4.4.1 Relation d’agrégation et de composition ......................................................... 36
4.4.2 Relation de dépendance ................................................................................. 37
4.4.3 Relation d’Héritage, généralisation et spécialisation ...................................... 37
4.5 Conclusion ................................................................................................................ 38
5. Chapitre V : Diagramme d’objets
5.1 Introduction ............................................................................................................. 39
5.2 Éléments graphiques d’un diagramme d’objets ....................................................... 39
5.3 Formalisme d’un diagramme d’objets ...................................................................... 40
5.3.1 Constructeur et destructeur d’objets .............................................................. 40
5.3.2 Durée de vie d’un Objet .................................................................................. 40
5.3.3 Objet Composite ............................................................................................. 41
5.3.4 Les contraintes dans le diagramme d’objets .................................................... 41
5.3.5 Le langage de contrainte OCL ......................................................................... 43
5.4 Implémentation en java ............................................................................................ 44
5.4.1 Implémentation de la relation bidirectionnelle 1-1.......................................... 45
5.4.2 Implémentation de la relation bidirectionnelle 1-N .......................................... 46
5.4.3 Implémentation de la relation unidirectionnelle 1-N ........................................ 46
5.4.4 Implémentation de la relation unidirectionnelle 1-1 ........................................ 47
5.5 Conclusion ................................................................................................................. 47
Introduction

Introduction

0.1 Description du cours

Il est certain qu’un processus de conception vise en premier lieu l’obtention d’une solution
dîtes acceptable du système informatique. Par analogie avec un architecte qui dessine
plusieurs plans pour arriver au plan final d’architecture de la maison, la conception d’un
système informatique est organisée dans un processus de modélisation qui prévoit aussi
plusieurs visions du même problème pour aider à trouver une solution acceptable. Par
conséquent, la solution finalement retenue n’est guerre obtenue en une seule itération.
Plusieurs étapes sont nécessaires pour raffiner le niveau de détails du système à réaliser. Les
premières étapes donnent une vision macro à très gros grains et permettent d’avancer dans
la compréhension du problème.

Le processus de modélisation requiert souvent des représentations fidèles de la réalité en se

basant sur les méthodes de conception qui utilisent généralement la modélisation à base de
graphiques (Coan et al 2015). L’importance de la représentation graphique du modèle reste
une évidence, vue la précision donnée de cette représentation par rapport à une description
informelle en langage naturelle.

Figure 0.1 Processus de l’analyse

Ce cours aborde la modélisation des systèmes informatiques en se basant sur le langage
(graphique) Uml qui est considéré comme un langage de modélisation très efficace. Avant de
montrer les différents diagrammes Umls, ce cours présente en premier lieu le processus du
développement afin de mettre en évidence l’importance de la phase d’analyse dans les
projets informatiques. Il s’agit d’identifier l’objectif en premier lieu pour structurer les
besoins et rédiger le cas d’utilisation

Un modèle est une abstraction de la réalité qui permet de présenter une ou plusieurs vues
sur le système ; la vue a pour objet d’aider le concepteur à mieux comprendre et donc mieux
maîtriser le système. La cohérence entre les différentes vues du système est importante,
chaque vue cible des catégories différentes d’intervenants ayant des besoins différents (voir
figure ci-dessous). Il est important de rappeler ici que chaque vue représente une étape dans
le cycle de vie de développement de logiciel. Nous avons abordé le processus de
développement logiciel et les différents modèles de cycle de vie d’un logiciel (Modèle en V,
Modèle en cascade et Modèle en spirale) dans la première partie du module (gestion de
projet de développement de logiciel). Ce cours se contente de présenter les étapes d’analyse
et de conception en se basant sur le langage de modélisation UML.

Figure 0.2 Processus de développement logiciel (Jacobson et al 2000)

Un langage de modélisation doit définir la manière de présenter le modèle en offrant une

sémantique des concepts ; une notation pour la représentation de concepts ; des règles de
construction et d'utilisation des concepts. L'industrie du logiciel dispose de nombreux
langages de modélisation adaptés aux différents contextes d’utilisation : on peut distinguer
les langages adaptés aux systèmes procéduraux (MERISE...) ; adaptés aux systèmes temps
réel (ROOM, SADT...) ; adaptés aux systèmes à objets (OMT, Booch, UML...).
UML est donc un langage de modélisation destiné en particulier à la modélisation objet. Il
est devenu une norme OMG en 1997 (OMG est un organisme à but non lucratif créé en 1989
à l'initiative de sociétés comme HP, Sun, Philips, etc. (Roques 2006, Roques 2002)). Il
propose un formalisme indépendant d'un langage de programmation donné. Pour ce faire,
UML normalise les concepts de l'objet (énumération et définition exhaustive des concepts)
ainsi que leur notation graphique. Il permet de diviser la visualisation d’un modèle en
diagrammes qui correspondent à des vues différentes.

Les modèles obtenus peuvent être implémentés dans un langage de programmation objet.
On se contente de présenter dans ce cours les 10 principaux diagrammes (figure 0.3), leurs
rôles complémentaires, et montrer comment les diagrammes d’un modèle sont construits
de manière cohérente.

Figure 0.3 Principaux diagrammes UML étudiés

Notons que ces diagrammes peuvent être classés selon leurs aspects et fonctionnement
suivant le point de vue classique de modélisation (statique, fonctionnel et dynamique)
(Roques & Vallée 2003). L’aspect fonctionnel comporte : -les diagrammes de cas d’utilisation, -
de séquence et -d’activité ; l’aspect statique comporte : -les diagrammes de classes,-
paquetage, -objets, -composants et -déploiement ; l’aspect dynamique concerne : -les
diagrammes de séquence,- de communication, -d’activité et -d’états-transitions.

Voici une brève description du contenu de chaque type de diagramme présenté dans la
figure ci-dessus :

Cas d’utilisation: c’est un diagramme visualisant les interactions entre le système et les
utilisateurs (et autres systèmes externes). Il aide dans la visualisation des exigences / besoins
;
Activité : il permet la modélisation des processus métier avec les échanges de données ;
Classes : Ce diagramme permet de présenter les classes (d’analyse et de conception), les
types, les interfaces et relations entre eux ;
Objets : on présente dans ce diagramme les instances de classes définissant une
configuration importante du système ;
Machine à états ou états-transitions: il s’agit de définir les états des classes à travers leur
cycle de vie (de la création / instanciation des objets à leur destruction) et les événements
qui provoquent les transitions / changements d’états ;
Interaction : on distingue deux types de diagrammes d’interaction :
- séquence : ce type de diagramme permet de visualiser en plus des interactions leur
ordre d’exécution qui est considéré comme important;
- communication : on visualise dans ce diagramme les interactions entre objets pour
lesquels les connexions entre objets sont importantes ;
Composants : il s’agit de rassembler des classes ou des composants tels que conçus par
l’équipe de développement pour décomposer le système en parties de logiciel gérables;
Déploiement : il concerne les unités de configuration, d’installation et de déploiement du
produit fini sur un parc de machines.
Paquetages : on rassemble dans ce type de diagramme les éléments de modélisation par
exemple pour les distribuer entre membres de l’équipe de développement ;

Le langage UML possède quelques autres diagrammes qui ne seront pas détaillés dans ce
cours : diagrammes de temps (en anglais, timing), diagrammes de vues globales
d’interactions (en anglais, interaction overview) et diagrammes de structures composites.
L’utilisation des 10 principaux diagrammes, qui seront présentés dans ce cours, sera
largement suffisant aux étudiants de se familiariser avec les concepts liés à la modélisation
informatique et atteindre les objectifs de ce cours.

0.2 Objectifs du cours

L’objectif de ce cours est double: il s’agit d’une part de permettre aux étudiants d’avoir une
vision globale sur l’analyse et la conception des systèmes informatiques afin d’apprendre la
manière d’abstraire la réalité pour mieux comprendre le système à réaliser. D’autre part ce
cours permet l’étude du langage de modélisation Uml en présentant les éléments
méthodologiques d’utilisation des différents types de diagrammes dans un processus de
modélisation.
A la fin de ce cours l’étudiant sera capable de
- Se familiariser avec les concepts liés aux démarches de l’analyse, de conception et de
développement des systèmes informatiques;
- Savoir traduire un besoin fonctionnel en s'appuyant sur les diagrammes UML ;
- Comprendre la représentation et l'intérêt d'utilisation des différents diagrammes
UML pour le développement d’un logiciel ;
- Intégrer les concepts objets nécessaires à une analyse/conception ;
- Maîtriser les 10 principaux diagrammes UML.
Chapitre I :

Analyse des besoins et définition du problème

1.1 Introduction

Le processus d’analyse de besoin est considéré comme la première étape d’analyse du

système à réaliser (ou même le système à améliorer). Ce système doit répondre à un ou
plusieurs besoins qui doivent être analysés et exprimés dans la première étape d’analyse et
de conception. Par exemple, une banque a besoin d’un guichet automatique pour assurer un
service continu à ses clients. Le besoin concerne le fait que la banque possède un guichet
automatique qui permet aux clients de retirer de l’argent même en dehors des heurs de
travail. Notons que celui qui commande le logiciel s’appel le maître d’ouvrage et celui qui
réalise le logiciel on le nome le maître d’œuvre.

Le maître d’ouvrage intervient constamment au cours de projet pour

- Définir et exprimer les besoins ;

- Valider les solutions proposées par le maître d’œuvre ;
- Valider le produit livré.

Le maître d’œuvre est par exemple la société de services en ingénierie informatique (SSII ou
SS2I), qui est une société de services spécialisée en génie informatique. Elle se caractérise
par ses compétences techniques de maîtrise d'œuvre. Le maître d’œuvre est souvent choisi
pour ses compétences techniques, mais aussi pour son savoir faire. Au début du projet, un
maître d’œuvre est capable de recueillir les besoins auprès des maîtres d’ouvrage. Le recueil
des besoins implique une bonne compréhension du métier : par exemple la réalisation d’un
logiciel pour une banque nécessite des connaissances approfondies dans les systèmes
bancaires pour intégrer toutes les contraintes et les exigences du métier. Cette condition est
primordiale pour bien cerner les cas d’utilisation exprimés par le client afin d’apporter des
solutions adéquates (Charroux et al 2005).

Le problème souvent posé pendant la première étape concerne la distinction entre les
besoins, les objectifs et les opportunités. La question qui se pose est : ai-je toutes les
connaissances et les informations pour définir ce que doit faire le système ?

Pour guider le concepteur dans sa démarche, ce cours présente la manière de définition de

problème, la technique d’analyse qui se base sur les grilles de Levesque et présente en fin
des exemples de cas d’utilisation.
1.2 Définition du problème

Le recueil de besoin nécessite de compléter le cahier des charges par des discussions
approfondies avec le maître d’ouvrage et les futurs utilisateurs du système. Le premier
problème posé au niveau de la phase d’analyse est celui de communication. Une expression
de besoin n’est pas facile car elle nécessite des compétences pluridisciplinaires pour assurer
une maitrise des concepts liés aux domaines différents.

Un utilisateur a dit à un informaticien :

« Je sais que tu crois avoir compris ce que tu penses que j’ai dit, mais je ne suis pas sûr que
tu réalises que ce que tu as entendu n’était pas ce que je voulais dire. »

Malheureusement, il y a souvent une différence : « Entre, Ce que je pense ; Ce que je veux

dire ; Ce que je crois dire ; Ce que je dis ; Ce que vous avez envie d’entendre ; Ce que vous
croyez entendre ; Ce que vous entendez ; Ce que vous avez envie de comprendre ; Ce que
vous croyez comprendre ; Ce que vous comprenez… il y a dix possibilités qu’on ait des
difficultés à communiquer. Mais essayons quand même… » – Bernard Werber (Bauchet
2015)

Le problème d’expression de besoin présente toujours des difficultés autant pour les
informaticiens que non informaticiens. L’image d’humour très connue par les chefs de
projets présente le problème réel et comment peut-on exprimer les besoins et livrer ce que
le client a mal décrit.

Figure 1.1 Problème d’expression de besoins

1.3 Grilles de Levesques

Cette section présente une grille d’analyse appelée Grille de Levesque qui peut être utilisée
comme un outil pouvant guider le concepteur à définir le problème. L’idée consiste à trouver
un seul objectif au projet. Il s’agit de classer chaque affirmation pertinente issue des
réunions de travail (brain-storming) ou d’une entrevue avec le client. En analysant les
informations collectées, il faut d’abord procéder par la distinction de 6 classes de faits :
Besoins, Objectif, Symptôme, Problème, Solution et Opportunité. Il faut donc distinguer un
symptôme de problème, un besoin d’un objectif et une solution d’une opportunité. Nous
donnons dans ce qui suit la définition de chaque concept :

Besoin: Exigence liée à la vie d’une personne, d’une organisation….

Exemples :

- Une personne doit manger pour assouvir sa faim.

- La voiture doit assurer sa tenue de route dans les virages.

2- Objectif: But à atteindre, résultat précis (servant de phare au développement)

Exemples :

- Demeurer en bonne santé

- Assurer le transport de l’automobiliste et de ses passagers d’un lieu à un autre

3- Problème: Difficulté à surmonter pour atteindre l’objectif.

Exemples :

- Une personne a de l’urticaire

- Mauvaise tenue de route de la voiture

4- Symptôme : Une manifestation du problème.

- Les boutons sur le visage est un symptôme de l’urticaire.

- La voiture quitte la route lorsqu’elle aborde un virage au-delà de 60 km/h est un -
symptôme de mauvaise tenue de route.

5- Solution: ensemble des décisions et mise en œuvre permettant d’atteindre l’objectif en

palliant les problèmes.

Exemple

- Supprimer la confiture de fraise peut être une solution à l’urticaire

- La révision de la carrosserie peut être une solution à la tenue de route

6- Opportunité: bénéfice apporté au système mais ne répondant pas directement au besoin.

 Exemples

- Supprimer la confiture de fraise peut être une solution à l’urticaire et peut

contribuer à diminuer l’obésité (opportunité).
- La révision de la carrosserie peut être une solution à la tenue de route et une
opportunité d’avoir un nouveau design.

1.3.1 Application des Grilles de Levesque sur l’analyse du problème de gestion de

bibliothèque de MIRABELLE (cas fictif). Une idée extraite de (Lesvesques 1999)

On analyse les faits en fonction de l’objectif défini : si on prend comme

objectif l’amélioration du service à la clientèle ; l’analyse sera résumée dans le tableau ci-
dessous.

Tableau 3.1 Grilles de Levesques

Fait Donnée Observation symptôme problème besoin Objectif opportunité solution

A Lenteur du service *
B Retard dans les rappels *
de prêts
C Files d’attente *
D Pas de compilation de *
stats récentes
E Classifier de nouveaux doc. en *
retard
F Eliminer les retards de *
classement
G Faire le suivi des prêts *
H Compiler régulièrement *
les statistiques
I Utiliser une base de *
données
J Ajouter du personnel *
K Réduire et contrôler les *
dépenses
L Augmenter les revenus *
M Réduire les délais de *
classement
N Améliorer le service à la * X
clientèle
O Limiter le temps de
dépannage du matériel
de la bibliothèque

Exercice : proposer une autre solution en mettant « (L) : augmenter les revenus » comme un
objectif.
1.4 Délimitation du périmètre du système

La délimitation du système nécessite une analyse de sa structure ainsi que son intégration
dans un système supérieur. La délimitation concerne tout simplement le fait de mettre des
limites au système par le fait de spécifier les exigences en matière de développement,
d’achat, d’exploitation ou même de maintenance. Il s’agit d’analyser et documenter les
frontières de systèmes et de sous-systèmes en insistant surtout sur la distinction entre les
décisions de conception et les contraintes d’exploitation. Il faut également identifier et
documenter les interfaces entre systèmes et en décrire les interactions.

Exemple : Nous avons la possibilité de définir deux approches pour la délimitation du

périmètre du système d’étude de caisse de supermarché :

1- Classique : La caissière est hors du système étudié

- Toutes les interactions entre la caissière et le système seront listées dans le
modèle d’usage
2- Originale: La caissière est dans le système étudié
- Les interactions entre la caissière et le client seront alors listées dans le modèle
d’usage.
- Le système pourra alors s’appliquer une borne interactive sans caissière

Figure 1.2 Délimitation du périmètre du système

Les contraintes d’exploitation peuvent concerner :

- Volumes (nombre de données à traiter)

- Performance (temps de réponses)
- Organisation : équipe support interne, ...
- Spécifications techniques
o Existant : parc matériel et environnement logiciel

Remarque : Si on commence dès le début de conception du système de mettre des

contraintes sur le matériel utilisé : par exemple la solution devra utiliser des Pentium IV, 1,5
Ghz. Ceci peut être considéré comme une décision de conception prématurée.
Chapitre II :

Digramme de cas d’utilisation

2.1 Introduction

UML propose de représenter les cas d'utilisation d'un système sous une forme graphique
nommée diagramme de cas d'utilisation appartenant au modèle des besoins. En effet, UML
n’est qu’un langage et il ne sert en première phase de projet qu’à formaliser les besoins,
c'est-à-dire à les représenter sous forme graphique suffisamment simple pour être
compréhensible par les acteurs du projet (Toutes les personnes impliquées dans le projet).
Notons que ces acteurs ne sont pas forcément tous des informaticiens, il leur faut donc un
moyen simple d’exprimer leurs besoins (Gollot 2015). Ceci est le rôle précis du diagramme de
cas d’utilisation : faciliter l’expression des besoins sous forme graphique compréhensible par
toutes les personnes impliquées dans le projet même pour les non informaticiens.

Courtes définitions issues des spécifications UML (Charroux et al 2009) :

● Un cas d'utilisation est une manière spécifique d’utiliser un système. Le cas d’utilisation
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 acteur est une entité externe au système, en interaction avec ce dernier. L'entité est un
rôle joué par un utilisateur, par exemple un comptable, ou par un autre système, un capteur
par exemple.

● Un scénario est un chemin particulier au travers de la description abstraite et générale

fournie par le cas d'utilisation (Muller & Gaertner 2003).

Un diagramme de cas d'utilisation montre acteurs et cas d'utilisation ensemble avec leur
relations. La relation entre un acteur et un cas d'utilisation est appelée association et
correspond au fait que l'acteur participe à un cas d'utilisation. Les cas d'utilisation
représentent les fonctionnalités d'un système, ou d'une entité d'un système, telles qu'elles
sont sollicitées en interaction avec des événements extérieurs. Ils donnent une vision
"haute" et dynamique du système.

2.2 Éléments graphiques d’un diagramme de cas d’utilisation

Acteur : un bonhomme ou une classe stéréotypée <<actor>>. Son rôle est décrit sous ses
pieds.
 Cas d'utilisation : une ellipse. Le nom du cas d'utilisation est placé généralement en
dessous de l'ellipse.

Association : il s’agit de montrer la participation d'un acteur à un cas d'utilisation par un

trait plein pouvant être orienté ou NON.

Figure 2.1 Modèle de Cas d’utilisation.

Exemple :

Acteur non humain

Acteur non humain

Figure 2.2 Cas d’utilisation : Gestion de Bibliothèque (Bauchet 2015).

2.3 Formalisme de diagramme de cas d’utilisation

2.3.1 Identifier les acteurs

Un acteur peut être humain ou purement informatique, hardware ou software. Un acteur

est un élément pouvant communiquer avec le système étudié, extérieur au système étudié,
qui joue un rôle dans le système. Il peut avoir de multiples "personnalités", jouer plusieurs
rôles dans un ou plusieurs cas d'utilisation.
Remarque : Il ne faut pas confondre acteur et individu-utilisateur. Notons qu’un individu
utilisateur peut avoir plusieurs rôles donc être représentatif de plusieurs acteurs.

Exemple

Domaine : site Internet d’achat de billets de transport.

Cas d’utilisation : réserver un billet.

Acteurs Internaute, serveur de la société de transport

Figure 2.3 Cas d’utilisation : réservation de billet.

2.3.2 formaliser les cas d’utilisation

Regroupe dans une vue synthétique les acteurs et les liens s’ils interagissent avec des cas
d’utilisation. Les cas d’utilisation sont des abstractions du dialogue entre les acteurs et le
système. Ils n’entrent pas dans le détail de chaque scénario.

L’ensemble de cas d’utilisation contenus dans le cadre constitue « «un sujet »

Gestion de Bibliothèque

Etudiant

Figure 2.4.A Modèle de gestion de la bibliothèque.

 Gestion de Bibliothèque

Figure 2.4.B Modèle de gestion de la bibliothèque étendu.

2.4 Relations et stéréotypes dans le diagramme de cas d’utilisation

UML propose trois types de relations standards entre cas d'utilisation, <<include>> ,
<<extend>> et la relation d’héritage qui peut être considéré comme une relation de
généralisation ou de spécialisation. Les deux premières sont représentées par un stéréotype
de dépendance, l'autre étant la relation de généralisation représentée en UML par une
flèche creuse à pointe fermée.

2.4.1 Relation d’include

La relation d’inclusion de deux cas d’utilisation est notée par une dépendance stéréotypée
« «include» ». L’inclusion exprime le fait qu’un cas d’utilisation comprend une séquence
d’actions consécutives qu’il est possible de factoriser avec d’autres cas d’utilisation. Lorsque
le système modélisé atteint une certaine taille, il est important de montrer les relations
d’inclusion qui définissent alors des parties du système réutilisables par d’autres parties.

Figure 2.5 Relation d’include.

A --------<<include>>-------> B signifie que A réalise forcément B au cours de son exécution.
On utilise ce stéréotype lorsque que l'on souhaite factoriser un cas d'utilisation partagé
par plusieurs autres cas d'utilisation.

Par exemple, une opération de retrait et une opération de transfert nécessitent toutes les
deux une opération de vérification de l'identité du client.

Figure 2.6 Stéréotype <<include>>

2.4.2 Relation Extends

A <-------<<extends>>-------- B signifie que A réalise potentiellement B au cours de son

exécution. Un cas d'utilisation peut déclarer des points d'extension (extension point). Un
point d'extension localise un endroit (un point) unique dans le cas d'utilisation.

Figure 2.7 Stéréotype <<extends>>

C'est dans les limites de ce point que d'autres cas d'utilisation pourront étendre ( extend ) le
comportement initial du cas d'utilisation. C'est un moyen pratique de mettre en avant une
fonctionnalité optionnelle.

Figure 2.8 Exemple d’utilisation du Stéréotype <<extends>> (Bauchet 2015)

2.4.3 Relation d’héritage (généralisation et spécialisation)

Une relation de généralisation d'un cas d'utilisation B vers un cas d'utilisation A signifie que B
est une spécialisation de A. Contrairement aux deux autres relations, la relation de
généralisation n'est pas un stéréotype. Elle indique qu'un cas d'utilisation est une variation
d'un autre.

Figure 2.9 Relation d’héritage

Par exemple dans le cas d’utilisation "Retirer de l'argent", si il s’agit de retirer de l’argent sur
un compte sur livret le comportement des deux cas d’utilisation peut être tout à fait
différent.
 Figure 2.10 Relation de généralisation

2.5 Rédaction de cas d’utilisation selon le Formlulaire de Cockburn

Pour rédiger un cas d’utilisation, nous avons besoins de préciser en premier lieu le titre du cas
d’utilisation. Un cas d'utilisation (use case) commence toujours par un verbe décrivant une action.
(Retirer de l’argent, emprunter un livre ….).

Il est ici inutile de préciser tous les processus techniques menant aux actions, il suffit de les modéliser
en langage simple et compréhensible. Les cas d'utilisation seront modélisés par des développeurs
sous forme technique dans une seconde étape. Nous nous référons dans cette partie du cours aux
travaux d’Alistair Cockburn (Cockburn, 2001). L'idée est de fournir un format de présentation
textuelle à la fois simple et riche du cas d’utilisation. Ce formulaire sert comme un guide méthodique
de rédaction de cas d’utilisation. Nous nous basons dans ce qui suit sur l’exemple de système de
gestion de bibliothèque pour montrer comment suivre les rubriques de cockburn afin de les utiliser
prochainement dans les futurs projets.

2.5.1 Rubriques de Cockburn

• Titre, Résumé, Acteurs

• Préconditions
• Action départ
• Liste des actions
• Action d’arrêt
• Postconditions
• Exceptions
• Remarques ergonomiques, Contraintes NF
2.5.2 Exemple Domaine :

Système de gestion d’une bibliothèque (Bauchet 2015)

Titre: Emprunter ouvrage.

Résumé: Liste des actions réalisées par un étudiant se présentant pour emprunter un
ouvrage dans la bibliothèque.

Acteurs : Etudiant (E), Hôtesse (H)

Pré-condition(s):

- L’étudiant est inscrit à la bibliothèque

- L’étudiant a trouvé son ouvrage dans les rayons de la bibliothèque

Déclencheur: 0. L’étudiant souhaite emprunter le livre qu’il a en main

Action de fin:

10. E quitte l’accueil avec son ouvrage.

Post-condition(s):

- L’ouvrage n’est plus disponible pour un autre prêt.

Exceptions:

Exception A : L’ouvrage a été réservé

- signale la non-disponibilité de l’ouvrage,

- invite l’étudiant à revenir à la date d’expiration de l’emprunt.

Exception B :

- La carte n’est pas valide ou l’étudiant est banni pour quelques jours car il a rendu son
précédent emprunt trop tard.
- précise les causes du refus de prêt

Remarques ergonomiques : on pourra utiliser un lecteur de code barre pour récupérer les
coordonnées de l’ouvrage.
 Contraintes non fonctionnelles

2.6 Conclusion

Nous avons présenté dans ce chapitre le diagramme de cas d’utilisation et son importance dans le
recueil, d’analyse et d’organisation des besoins. Nous avons également vu que la description d’un
cas d’utilisation se fait par des scénarios qui définissent la suite logique des actions qui constituent ce
cas. Cette séquence doit être représentée en se basant sur le formulaire de Cockburn. Notons qu’il
est possible de définir des scénarios simples ou des scénarios plus détaillés faisant intervenir les
variantes, les cas d’erreurs, etc.

Il est important de noter ici que la description détaillée des scénarios nécessite une représentation
faisant apparaitre des détailles (conditions, boucle, l’enchainement d’actions de haut niveau…) que le
cas d’utilisation ne les représente pas ; et il faut donc utiliser le diagramme d’activité pour les
représenter. Nous présentons dans le chapitre suivant le diagramme d’activité.
Chapitre III :
Diagramme d’activité

3.1 Introduction

A la différence du cas d’utilisation qui montre ce que fait ou doit faire le système ; Un diagramme
d’activité permet de montrer l’enchaînement des activités d’un système ou même d’une opération.
Le diagramme d’activité représente le flot de contrôle qui retrace le fil d’exécution et qui transite
d’une activité à l’autre dans le système. Dans la pratique, les diagrammes d’activité sont bien adaptés
à cette phase de l’analyse qui consiste en l’expression des processus métier comme un ensemble
d’actions coordonnées pour atteindre un but. Dans ce sens il est comme un organigramme.

L’avantage d’un diagramme d’activité par rapport à un simple organigramme réside dans le fait de
son pouvoir d’expliciter des activités parallèles et leur synchronisation. Le diagramme d’activité est
utilisé surtout pour modéliser un workflow dans un ou plusieurs cas d’utilisation. Le diagramme
d’activité est le plus approprié pour modéliser la dynamique d’une tâche ou d’un groupe de tâches.

3.2 Eléments graphiques de diagramme d’activité

Figure 3.1.A Diagramme d’activité (Audibert 2009).

 Figure 3.1.B Représentation graphique des nœuds d'activité

Le premier type de losange est appelée une décision et simule le début d’une instruction « si-
alors ». Les conditions sont appelées des gardes. Le second type de losange signifie la fusion des
branches à la fin du « si-alors » (voir l’exemple d’utilisation des losanges dans la figure 3.2). Il faut
penser aux situations de blocage, pour ce fait les conditions doivent être complètes pour éviter que
l’activité ne soit bloquée ou gelée indéfiniment parce qu’aucune des conditions n’est valide.

Exemple :

Une activité débute par un nœud initial représenté par un disque noir. Cette action marque le
début de l’activité et est suivi d’arêtes représentant le passage à l’action suivante. Le nœud
terminal ou final signifiant la fin de l’activité est représentée par un disque noir entouré d’un second
disque. Entre les deux extrémités, les actions importantes du scénario sont reliées entre elles de
façon à montrer le flot de l’activité : les enchaînements ou séquences et la concurrence
(parallélisme).

L’exemple ci-dessous montre l’enchainement d’activités liées à la réception de commande.

Figure 3.2 Premier exemple d’un diagramme d’activité (Audibert 2009).

Il existe, en plus du nœud initial et nœud final, plusieurs types de nœuds de contrôle :

 nœud de fin de flot (flow final node en anglais) ;

 nœud de décision (decision node en anglais) ;
 nœud de fusion (merge node en anglais) ;
 nœud de bifurcation (fork node en anglais) ;
 nœud d'union (join node en anglais).

3.3 Formalisme d’un diagramme d’activité

Les modèles de diagrammes d’activité servent d’abord à expliquer le fonctionnement d’un

système, en fournissant une vision abstraite de son fonctionnement. L’objectif est de donner une
description informelle permettant d’aller jusqu’à décrire le système à un niveau de détail qui permet
de montrer son exécution. Uml est doté d’un mécanisme offrant la possibilité de décrire les actions
sans entrer dans les détails du langage de programmation.

Les actions sont des étapes discrètes à partir desquelles se construisent les comportements. La
notion d'action est à rapprocher de la notion d'instruction élémentaire d'un langage de
programmation (comme C++ ou Java). Selon (Audibert 2009). Une action peut être, par exemple :

 une affectation de valeur à des attributs ;

 un accès à la valeur d'une propriété structurelle (attribut ou terminaison d'association) ;
 la création d'un nouvel objet ou lien ;
 un calcul arithmétique simple ;
 l'émission d'un signal ;
 la réception d'un signal ;
 …

Nous décrivons ci-dessous les types d'actions les plus courants prédéfinis dans la notation UML.

Action appeler ( call operation )

 L'action call operation correspond à l'invocation d'une opération sur un objet de manière
synchrone ou asynchrone. Lorsque l'action est exécutée, les paramètres sont transmis à
l'objet cible. Si l'appel est asynchrone, l'action est terminée et les éventuelles valeurs de
retour seront ignorées. Si l'appel est synchrone, l'appelant est bloqué pendant l'exécution
de l'opération et, le cas échéant, les valeurs de retour pourront être réceptionnées.

Action comportement ( call behavior )

 L'action call behavior est une variante de l'action call operation car elle invoque
directement une activité plutôt qu'une opération.

Action envoyer ( send )

  Cette action crée un message et le transmet à un objet cible, où elle peut déclencher un
comportement. Il s'agit d'un appel asynchrone (i.e. qui ne bloque pas l'objet appelant) bien
adapté à l'envoi de signaux (send signal).

Action accepter événement ( accept event )

 L'exécution de cette action bloque l'exécution en cours jusqu'à la réception du type

d'événement spécifié, qui généralement est un signal. Cette action est utilisée pour la
réception de signaux asynchrones.

Action accepter appel ( accept call )

 Il s'agit d'une variante de l'action accept event pour les appels synchrones.

Action répondre ( reply )

 Cette action permet de transmettre un message en réponse à la réception d'une action de

type accept call.

Action créer ( create )

 Cette action permet d'instancier un objet.

Action détruire ( destroy )

 Cette action permet de détruire un objet.

Action lever exception ( raise exception )

 Cette action permet de lever explicitement une exception.

Figure 3.3 Représentation des actions dans le diagramme d’activité (Audibert 2009).
 3.4 Flot de contrôle et synchronisation dans le diagramme d’activité

Les actions qui se déroulent en même temps sont dites concurrentes. Elles sont modélisées entre
deux traits épais comme des chemins parallèles. Les séquences d’actions en parallèle débutent en
même temps, sont toutes exécutées, mais par définition ne finissent pas au même instant. La fin de
l’action join intervient lorsque toutes les actions en parallèle se terminent ; join est donc un point de
synchronisation.

Il est possible de synchroniser les transitions à l'aide des "barres de synchronisation". Une barre de
synchronisation permet d'ouvrir et de fermer des branches parallèles au sein d'un flot d'exécution :

- Les transitions qui partent d'une barre de synchronisation ont lieu en même temps.
- On ne franchit une barre de synchronisation qu'après réalisation de toutes les
transitions qui s'y rattachent.

Figure 3.4 la synchronisation dans le diagramme d’activité.

3.4.1 Synchronisation disjonctive (embranchement)

Un embranchement est la décomposition du flux de contrôle en deux ou plusieurs flux de

contrôle. Il permet de spécifier des activités concurrentes.
 Figure 3.5 Synchronisation disjonctive (embranchement) dans le diagramme d’activité.

3.4.2 Synchronisation conjonctive (conjonction) :

Une jonction est la recomposition du flux de contrôle de deux ou plusieurs flux de contrôle en un
seul.

- Un embranchement permet de spécifier la synchronisation d'activités concurrentes.

- Les flux qui sortent d'un embranchement doivent balancer les flux qui entrent dans
la jonction correspondante.

Figure 3.6 Synchronisation conjonctive (conjonction) dans le diagramme d’activité

3.4.3 Les couloirs dans le diagramme d’activité

Les partitions appelées des couloire (Swimlanes en anglais) dans le diagramme d’activité
sont généralement utilisés pour organiser un diagramme d'activités. Il s’agit de définir des
"couloirs d'activités" selon les différents responsables des actions représentées. Les couloirs
sont un genre de paquet pour la responsabilité d'organisation des activités dans une classe.

Un diagramme d'activité peut être divisé visuellement en des lignes solides verticales des
deux côtés. Chaque couloire représente la responsabilité d'une partie de l'activité globale, et
peut par la suite être mis en application par un ou plusieurs objets.

Figure 3.7 Les couloires dans le diagramme d’activité.

3.4.4 Flux d’objet

Un flux d'objet représente la participation d'un objet dans un flux de contrôle.

- Les flux d'objets sont représentés par des relations de dépendance entre
objets et états d'action ou d'activités.
- Les flux d'objets sont représentés par des flèches :

Représentation des Pins d’entrée

et de sortie sur une activité

Figure 3.8.A. Flux d’objet dans le diagramme d’activité

 Figure 3.8.B. Flux d’objet dans le diagramme d’activité

Exercice : Construire un diagramme d’activité représentant l’utilisation d’une cafetière électrique:

1. premier état : chercher du café ;
2. dernier état: servir du café.

Figure 3.9. Exemple du diagramme d’activité correspondant à l’utilisation de la cafetière

3.5 Conclusion

Nous avons montré que le diagramme d’activité est utilisé dans la phase de conception afin
d’offrir une description détaillée du diagramme de cas d’utilisation. Le diagramme d’activité
offre une vue centrée sur les traitements. Cette vue permet de modéliser efficacement le
cheminement de flots de contrôle et flots de données. L’objectif n’est pas certes de fixer
complètement le choix d’implémentation, mais de fournir une vision abstraite de
traitement. Par exemple, l’expression de mécanismes concurrents n’implique pas forcément
le fait d’imposer une architecture parallèle spécifique.

Après avoir montré comment concevoir une vue permettant de visualiser les traitements,
nous allons aborder dans le chapitre suivant le diagramme de classes qui montre la structure
interne du système.
Chapitre IV : Diagramme de classes
4.1 Introduction ............................................................................................................. 29
4.2 Éléments graphiques d’un diagramme de classes...................................................... 29
4.3 Formalisme d’un diagramme de classes ................................................................... 31
4.3.1 La multiplicité ................................................................................................. 31
4.3.2 Notion d’association ........................................................................................ 32
4.3.3 Association binaire et n-aire ............................................................................ 32
4.3.4 Association avec navigabilité et contraintes ..................................................... 33
4.3.5 Association dérivée .......................................................................................... 34
4.3.6 Classe-Association ........................................................................................... 35
4.4. Relations dans le diagramme de classes ................................................................... 36
4.4.1 Relation d’agrégation et de composition ......................................................... 36
4.4.2 Relation de dépendance ................................................................................. 37
4.4.3 Relation d’Héritage, généralisation et spécialisation ...................................... 37
4.5 Conclusion ................................................................................................................ 38
Chapitre IV :
Diagramme de classes

4.1 Introduction

Compte tenu de l’importance du diagramme de classes dans la modélisation orientée-objet, il est le

seul diagramme obligatoire lors du processus de modélisation. Il permet de fournir une
représentation abstraite des objets du système qui vont interagir pour réaliser les cas d'utilisation.
Notons qu'un même objet peut intervenir dans la réalisation de plusieurs cas d'utilisation. A la
différence du diagramme d’activité qui offre une vue dynamique centrée sur les traitements, Il s'agit
dans le diagramme de classes de représenter une vue statique du système, car on ne tient pas
compte du facteur temporel dans le comportement du système.
Une classe peut être extraite des cas d’utilisation, par un analyste programmeur, et après analyse et
factorisation opérées par un ingénieur de développement, peut être considérée comme valide et
ajoutée dans le package correspondant. Pour distinguer ces étapes de modélisation, on doit ajouter
au nom de la classe toutes les informations nécessaires.
Une classe est considérée comme un ensemble d’objets possédant même structure et même
comportement. Une classe permet la description de la structure et du comportement des objets,
c'est-à-dire les intentions de la classe. Elle est considérée comme un modèle à partir duquel les
objets sont créés (instanciation).
Le diagramme de classes permet de modéliser les classes du système et leurs relations. Les
principaux éléments de cette vue statique sont les classes, qui possèdent des attributs et des
opérations, et leurs relations. Les relations entre classes peuvent être de différents types :
l’association (binaire), la généralisation spécialisation ou héritage, l’agrégation, etc. Une association
possède un sens de lecture du verbe la nommant, une navigabilité indiquant dans quel sens
l’association peut être parcourue. Chaque extrémité de l’association possède un rôle spécifiant le
rôle de la classe dans l’association par rapport à l’autre extrémité, ainsi qu’une multiplicité.

4.2 Éléments graphiques d’un diagramme de classes

Une classe est un concept abstrait représentant des éléments variés comme ( Audibert 2009):

 des éléments concrets (ex. : des avions),

 des éléments abstraits (ex. : des commandes de marchandises ou services),
 des composants d'une application (ex. : les boutons des boîtes de dialogue),
 des structures informatiques (ex. : des tables de hachage),
 des éléments comportementaux (ex. : des tâches), etc.

Une classe est un classeur. Elle est représentée par un rectangle divisé en trois à cinq compartiments.
Le premier indique le nom de la classe, le deuxième ses attributs et le troisième ses opérations. Un
compartiment des responsabilités peut être ajouté pour énumérer l'ensemble de tâches devant être
assurées par la classe, mais pour lesquelles on ne dispose pas encore assez d'informations. Un
compartiment des exceptions peut également être ajouté pour énumérer les situations
exceptionnelles devant être gérées par la classe.

Figure 4.1. Diagramme de classes.

Le nom de la classe doit évoquer le concept décrit par la classe. Il commence par une majuscule. On
peut ajouter des informations subsidiaires comme le nom de l'auteur de la modélisation, la date, etc.
Pour indiquer qu'une classe est abstraite, il faut ajouter le mot-clef abstract.

On peut ajouter aux méthodes définies sur les classes un ensemble de contraintes (types ou
propriété). Le type du paramètre peut être un nom de classe, un nom d'interface ou un type de
donnée prédéfini. Les propriétés correspondent à des contraintes ou à des informations
complémentaires comme les exceptions, les préconditions, les postconditions ou encore l'indication
qu'une méthode est abstraite (mot-clef abstract), etc.

Notons qu’un principe de conception important dans la modélisation objet consiste à protéger le
cœur d’un système des accès intempestifs venant de l’extérieur. C’est le principe de coffre-
fort appelé principe d’encapsulation en modélisation objet : seuls les détenteurs d’une clé peuvent
l’ouvrir. UML définit quatre niveaux d’encapsulation d’une propriété d’une classe :

- Le mot clé Public ou le caractère + : propriété ou classe visible partout

- Aucun caractère, ni mot clé : propriété ou classe visible uniquement dans le paquetage où la
classe est définie.
- Le mot clé Protected ou le caractère # : propriété ou classe visible dans la classe et par tous
ses descendants.
- Le mot clé Private ou le caractère - : propriété ou classe visible uniquement dans la classe.

Les attributs dérivés peuvent être calculés à partir d'autres attributs et de formules de calcul. Lors de
la conception, un attribut dérivé peut être utilisé comme marqueur jusqu'à ce que vous puissiez
déterminer les règles à lui appliquer.

Les attributs dérivés sont symbolisés par l'ajout d'un « / » devant leur nom.
 Figure 4.2. Attribut dérivé d’une classe (Coan et al 2015).

4.3 Formalisme d’un diagramme de classes

Les classes sont les éléments de base d’un diagramme de classes. Une application nécessite sans
doute la modélisation de plusieurs classes. Après avoir identifié les classes dont on a besoin, il
convient de les relier entre elles. Les relations entre classes expriment le lien sémantique ou
structurel. Les relations les plus utilisées sont l’association, l’agrégation, la composition, la
dépendance et l’héritage.

4.3.1 La multiplicité

La multiplicité est définie par un ensemble non vide d’entiers positifs à l’exclusion d’un ensemble ne
contenant que zéro {0}. Elle apparaît à chaque extrémité d’une relation et indique le nombre d’objets
de la classe apparaissant à cette extrémité pouvant s’associer à un seul et unique objet de la classe
apparaissant dans l’autre extrémité.

Exemple : Un objet de la classe Voiture est composé d’au moins trois roues et d’au plus dix roues. Et
chaque roue se compose d’un seul pneu et d’une seule jante.

3..10

Figure 4.3. Multiplicité.

4.3.2 Notion d’association

Figure 4.4. Notion d’association.

Dans la première version (figure 4.4), l'association apparaît clairement et constitue une entité
distincte. Dans la seconde, l'association se manifeste par la présence de deux attributs dans chacune
des classes en relation. C'est en fait la manière dont une association est généralement implémentée
dans un langage objet quelconque, mais pas dans tout langage de représentation.

La question de savoir s'il faut modéliser les associations en tant que telles a longtemps fait débat.
UML a tranché pour la première version, car elle se situe plus à un niveau conceptuel (par opposition
au niveau d'implémentation) et simplifie grandement la modélisation d'associations complexes
(comme les associations plusieurs à plusieurs par exemple).

4.3.3 Association binaire et n-aire

Figure 4.5. Association binaire.

Une association binaire est matérialisée par un trait plein entre les classes associées. Elle peut être
ornée d'un nom, avec éventuellement une précision du sens de lecture. Quand les deux extrémités
de l'association pointent vers la même classe, l'association est dite réflexive (Solnon 2015 ).

Une personne travail pour une et une seule entreprise. L’entreprise emploie au moins une personne.
L’entreprise est l’employeur des personnes qui travaillent pour elle et une personne a un statut
d’employé dans l’entreprise.
 Figure 4.6. Association n-aire.

Une association n-aire lie plus de deux classes. Dans une association n-aire, la multiplicité
apparaissant sur le lien de chaque classe s'applique sur une instance de chacune des classes, à
l'exclusion de la classe-association et de la classe considérée. En effet, une multiplicité minimale de 1
(ou plus) sur une extrémité implique qu'il doit exister un lien (ou plus) pour TOUTES les combinaisons
possibles des instances des classes situées aux autres extrémités de l'association n-aire. On
représente une association n-aire par un grand losange avec un chemin partant vers chaque classe
participante. Le nom de l'association, le cas échéant, apparaît à proximité du losange.

4.3.4 Association avec navigabilité et contraintes

Une association entre deux classes indique que les propriétés sont échangées ou partagées par les
classes reliées. L’ajout de contraintes à une association ou bien entre associations apporte plus
d’information car cela permet de mieux préciser la portée et le sens de l’association. 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 l’extrémité navigable et on empêche la navigabilité par une croix du côté
de l’extrémité non navigable. Par défaut, une association est navigable dans les deux sens.

Par exemple, sur la figure ci-dessous, l’extrémité 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, l’extrémité du côté de la classe Produit est navigable : chaque objet
commande contient une liste de produits.

Figure 4.7.A Navigabilité

Figure 4.7.B Notations ayant la même sémantique.

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 ont la même
signification : l'association ne peut être traversée que dans un sens.

Figure 4.8. Navigabilité et contraintes.

Dans la figure ci-dessus, un polygone est défini par un ensemble de points jouant le rôle de sommets.
Les sommets du polygone ne sont accessibles que par la classe et par ses descendants. La navigabilité
est possible uniquement du polygone vers les points.

L’ajout de l’attribut sommets dans la classe Polygone permet de modéliser l’association entre les
classes Polygone et Point et mettre en évidence la navigabilité de la relation.

4.3.5 Association dérivée

Une association dérivée est une association qui peut se déduire d’une asscociation existante ; elle est
donc conditionnée ou peut être déduite à partir d’une autre association. Graphiquement, une
association dérivée est symbolisée par l’ajout d’un slash avant le nom de l’association. Dans la figure
ci-dessous, l’asssociation dérivée /emploie indique que la personne qui travail dans une entreprise
est la même que celle associée à l’une des ses services.

Figure 4.9. Association dérivée.

4.3.6 Classe-Association

Parfois, une association doit posséder des propriétés qui ne sont disponible dans aucune des classes
qu’elle lie. Comme, dans le modèle objet, seules les classes peuvent avoir des propriétés, cette
association devient alors une classe appelée « Classe-Association ».

Par exemple, l'association Emploie entre une société et une personne possède comme propriétés le
salaire et la date d'embauche. En effet, ces deux propriétés n'appartiennent ni à la société, qui peut
employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs emplois. Il s'agit donc
bien de propriétés de l'association Emploie. Les associations ne pouvant posséder de propriété, il
faut introduire un nouveau concept pour modéliser cette situation : celui de classe-association.

Une classe-association possède les caractéristiques des associations et des classes : elle se connecte
à deux ou plusieurs classes et possède également des attributs et des opérations.

Une classe-association est caractérisée par un trait discontinu entre la classe et l'association qu'elle
représente.

Figure 4.10. Classe-association.

Notons qu’il n'est pas possible de rattacher une classe-association à plus d'une association puisque la
classe-association constitue elle-même l'association. Dans le cas où plusieurs classe-associations
doivent disposer des mêmes caractéristiques, elles doivent hériter d'une même classe possédant ces
caractéristiques, ou l'utiliser en tant qu'attribut.

Qualification d’une association pour limiter son impacte sur les classes associées

Généralement, une classe peut être décomposée en sous-classes ou posséder plusieurs propriétés.
Une telle classe rassemble un ensemble d'éléments (d'objets). Quand une classe est liée à une autre
classe par une association, il est parfois préférable de restreindre la portée de l'association à
quelques éléments ciblés (comme un ou plusieurs attributs) de la classe. Ces éléments ciblés sont
appelés un qualificatif. Un qualificatif permet donc de sélectionner un ou des objets dans le jeu des
objets d'un objet (appelé objet qualifié) relié par une association à un autre objet. L'objet sélectionné
par la valeur du qualificatif est appelé objet cible. L'association est appelée association qualifiée. Un
qualificatif agit toujours sur une association dont la multiplicité est plusieurs (avant que l'association
ne soit qualifiée) du côté cible.
Un objet qualifié et une valeur de qualificatif génèrent un objet cible lié unique. En considérant un
objet qualifié, chaque valeur de qualificatif désigne un objet cible unique.

L’objectif dans la figure ci-dessous est de modéliser l’association entre une personne et une banque.
L’unique lien entre les deux est le fait de posséder au plus 2 comptes. La banque assure bien d’autres
activités qui ne concernent pas le client. Pour mettre en évidence le fait que le lien entre la banque
et une personne se limite à la possession de plusieurs compte, on ajoute une classe Compte qui
représente la classe Banque dans l’association avec la classe Personne.

0..2 Posséder *
Banque #Compte Personne
e Client

Figure 4.11. Une classe qualifiante est collée à la classe principale (Charroux et al 2005).

4..4 Relations dans le diagramme de classes

Après avoir présenté la structure du diagramme de classes et son formalisme en détaillant ses
relations structurelles (Associations), nous allons présenter dans cette section les autres types de
relation qui sont très utiles dans la modélisation objet.

4.4.1 Relation d’agrégation et de composition

Une agrégation est une forme particulière d’association. Elle représente la relation d’inclusion
structurelle ou comportementale d’un élément dans un ensemble. Contrairement à l’association,
l’agrégation est une relation transitive. Graphiquement, l’agrégation se distingue d’une association
par l’ajout d’un losange vide du côté de l’agrégat.

La composition est une agrégation particulière. Cela signifie que toute composition peut être
remplacée par une agrégation mais avec perte d’information. La relation de composition décrit une
contenance structurelle entre instances. Ceci implique que l’élément composite est responsable de la
création de la copie et de la destruction de ses composants. Dans la figure ci-dessous la tête est le
tronc sont des composites d’un homme. Un homme peut très bien perdre une jambe ou un bras et
donc la relation entre bras et jambe est une agrégation.

Figure 4.12. Agrégation et composition.

4.4.2 Relation de dépendance

Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre des
éléments du modèle. Elle est représentée par un trait discontinu orienté. Elle indique que la
modification de la cible peut impliquer une modification de la source. La dépendance est souvent
stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle.

On utilise souvent une dépendance quand une classe en utilise une autre comme argument dans la
signature d'une opération. Par exemple, le diagramme de la figure ci-dessous montre que la
classe Confrontation utilise la classe Stratégie, car la classe Confrontation possède une
méthode confronter dont deux paramètres sont du type Stratégie. Si la classe Stratégie, notamment
son interface, change, alors des modifications devront également être apportées à la
classe Confrontation.

Figure 4.13. Relation de dépendance (Audibert 2009).

4.4.3 Relation d’Héritage, généralisation et spécialisation

La généralisation décrit une relation entre une classe générale (classe de base ou classe parent) et
une classe spécialisée (sous-classe). La classe spécialisée est intégralement cohérente avec la classe
de base, mais comporte des informations supplémentaires (attributs, opérations, associations). Un
objet de la classe spécialisée peut être utilisé partout où un objet de la classe de base est autorisé.

Dans le langage UML, ainsi que dans la plupart des langages objet, cette relation de généralisation se
traduit par le concept d'héritage. On parle également de relation d'héritage. Ainsi, l'héritage permet
la classification des objets.

Le symbole utilisé pour la relation d'héritage ou de généralisation est une flèche avec un trait plein
dont la pointe est un triangle fermé désignant le cas le plus général.

Les propriétés principales de l'héritage sont :

 la classe enfant possède toutes les caractéristiques de ses classes parents, mais elle ne peut
accéder aux caractéristiques privées de cette dernière ;
 une classe enfant peut redéfinir (même signature) une ou plusieurs méthodes de la classe
parent. Sauf indication contraire, un objet utilise les opérations les plus spécialisées dans la
hiérarchie des classes ;
 toutes les associations de la classe parent s'appliquent aux classes dérivées ;
 l’héritage multiple concerne le fait qu’une classe fille peut avoir plus d’une classe mère.
 Figure 4.13. Relation d’héritage.

4.5 Conclusion

Nous avons commencé, dans ce chapitre par la définition de la notion de classe qui adopte un niveau
élevé d’abstraction afin de modéliser d’une façon concise un ensemble d’objets. Nous avons
présenté dans le formalisme de diagramme de classes la notion d’association afin de faciliter la
compréhension de la modélisation d’un diagramme de classes en utilisant uniquement des
associations. Nous avons ensuite présenté les autres types de relations et leurs différences qui
permettent de modéliser la diversité des cas rencontrés lors de la modélisation objet.

La concrétisation du modèle de classes nécessite de définir le diagramme d’objets qui permet de

présenter les liens concrets entre les entités généralisées dans le diagramme de classes. Nous allons
border dans le chapitre suivant le diagramme d’objet et présenter la manière de concrétiser le
diagramme de classes afin d’arriver à la phase d’implémentation.
Chapitre V : Diagramme d’objets

5.1 Introduction ............................................................................................................. 39

5.2 Éléments graphiques d’un diagramme d’objets ....................................................... 39
5.3 Formalisme d’un diagramme d’objets ...................................................................... 40
5.3.1 Constructeur et destructeur d’objets .............................................................. 40
5.3.2 Durée de vie d’un Objet .................................................................................. 40
5.3.3 Objet Composite ............................................................................................. 41
5.3.4 Les contraintes dans le diagramme d’objets .................................................... 41
5.3.5 Le langage de contrainte OCL ......................................................................... 43
5.4 Implémentation en java ............................................................................................ 44
5.4.1 Implémentation de la relation bidirectionnelle 1-1.......................................... 45
5.4.2 Implémentation de la relation bidirectionnelle 1-N .......................................... 46
5.4.3 Implémentation de la relation unidirectionnelle 1-N ........................................ 46
5.4.4 Implémentation de la relation unidirectionnelle 1-1 ........................................ 47
5.5 Conclusion ................................................................................................................. 47
Chapitre V :
Diagramme d’objets

5.1 Introduction

Le diagramme d’objets permet la représentation d’une instanciation du diagramme de classes en

représentant les objets (i.e. instances de classes) et leurs liens (i.e. instances de relations). Un
diagramme d’objets peut être utilisé pour illustrer le modèle de classes en montrant un exemple qui
explique le modèle en précisant certains aspects du système. Il s’agit de mettre en évidence des
détails imperceptibles, qui ne sont pas modélisés, dans le diagramme de classes, par exemple
l’expression d’une exception ou la prise d’une image (snapshot) d'un système à un moment donné.
Le diagramme de classes modélise les règles et le diagramme d’objets modélise des faits. Il permet
de donner une vue figée de l'état d'un système à un instant donné.

5.2 Éléments graphiques d’un diagramme d’objets

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’objets,
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ée pour lever l’ambiguïté. Les attributs reçoivent des
valeurs. Quand certaines valeurs d'attribut d'un objet ne sont pas renseignées, on dit que l'objet est
partiellement défini.

Figure 5.1. Instanciation d’un diagramme de classes (Audibert 2009).

L’objet entrep, modélise lui une entreprise particulière (PERTNE) qui emploie trois personnes. La
relation de dépendance d'instanciation (stéréotypée << instanceof >>) décrit la relation entre un
classeur et ses instances. Elle relie, en particulier, les liens aux associations et les objets aux
classes. Dans un diagramme d’objets, les relations du diagramme de classes deviennent des liens. La
relation de généralisation ne possède pas d'instance, elle n'est donc jamais représentée dans un
diagramme d’objets. Graphiquement, un lien se représente comme une relation, mais, s'il y a un
nom, il est souligné. Naturellement, on ne représente pas les multiplicités.

Par exemple, le diagramme de classes de la figure 5.1 montre qu'une entreprise emploie au moins
deux personnes et qu'une personne travaille dans au plus deux entreprises. Le diagramme d’objets

Figure 5.2. Dépendance d'instanciation entre les classeurs et leurs instances (Charroux et al 2005).

5.3 Formalisme d’un diagramme d’objets

Un diagramme d’objets est particulièrement utile pour décrire comment les objets dans le
système fonctionnent ensemble dans un scénario donné. Un diagramme d’objets représente une
configuration donnée. 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.

5.3.1 Constructeur et destructeur d’objets

Un constructeur est une méthode d'instanciation et d'initialisation d’objets dans la mémoire. Le

destructeur est une méthode de finalisation et de destruction de l’objet dans la mémoire. Toute
classe a un constructeur et un destructeur par défaut, fournis par le compilateur. Les constructeurs
et destructeurs appellent les constructeurs par défaut et les destructeurs des classes de base et des
données membres de la classe. Leur redéfinition permet de gérer certaines actions qui doivent avoir
lieu lors de la création d'un objet et de leur destruction. Par exemple, si l'objet doit contenir des
variables allouées dynamiquement, il faut leur réserver de la mémoire à la création de l'objet ou au
moins mettre les pointeurs correspondants à NULL. À la destruction de l'objet, il convient de restituer
la mémoire allouée, s'il en a été alloué (Roques & Vallée 2003).

5.3.2 Durée de vie d’un Objet

Les objets ne sont pas des éléments statiques et leur durée de vie ne correspond pas forcément à la
durée d'exécution du programme.

La durée de vie d'un objet passe par trois étapes :

 la déclaration de l'objet et l'instanciation ;

 l'utilisation de l'objet en appelant ses méthodes ;

  la suppression de l'objet : elle se fait en utilisant le destructeur d’objets. Il est à noter qu’en
java, cette étape est automatique grâce à la machine virtuelle. La restitution de la mémoire
inutilisée est prise en charge par le récupérateur de mémoire (garbage collector).

5.3.3 Objet Composite

Un objet composite est constitué d'un ou de plusieurs objets similaires (ayant des fonctionnalités
similaires). L'idée est de manipuler un groupe d’objets de la même façon que s'il s'agissait d'un seul
objet. Les objets ainsi regroupés doivent posséder des opérations communes, c'est-à-dire un
"dénominateur commun". Dans l’exemple ci-dessous un livre est constitué d’un N chapitres il est
donc composite, la relation entre classes est une composition. Un objet livre est un objet composite.

Figure 5.3.A Objet Composite.

Figure 5.3.B Instanciation d’un objet Composite.

5.3.4 Les contraintes dans le diagramme d’objets

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.

Si une contrainte possède un nom, on présente celui-ci sous forme d'une chaîne suivie d'un double
point (:), le tout précédant le texte de la contrainte.

Figure 5.4. Représentation des contraintes.

La figure 5.4 présente quelques contraintes prédéfinies ({frozen}, {ordered} et {addonly}). Frozen
précise que le nombre de payés dans lequel la personne est née ne peut pas varier ici nombre=1.
Une personne ne peut naitre que dans un seul payé. Le addonly signifie que le payé est une instance
que l’on peut ajouter mais on ne peut le retirer. Ordered signifie que les valeurs sont ordonnées.
UML permet d'associer une contrainte à un, ou plusieurs, élément(s) (Audibert 2009) de modèle de
différentes façons :

 en plaçant directement la contrainte à côté d'une propriété ou d'une opération dans un

classeur ;
 en ajoutant une note associée à l'élément à contraindre ;
 en plaçant la contrainte à proximité de l'élément à contraindre, comme une extrémité
d'association par exemple ;
 en plaçant la contrainte sur une flèche en pointillés joignant les deux éléments de modèle à
contraindre ensemble, la direction de la flèche constituant une information pertinente au
sein de la contrainte ;
 en plaçant la contrainte sur un trait en pointillés joignant les deux éléments de modèle à
contraindre ensemble dans le cas où la contrainte est bijective ;
 en utilisant une note reliée, par des traits en pointillés, à chacun des éléments de modèle,
subissant la contrainte commune, quand cette contrainte s'applique sur plus de deux
éléments de modèle.

Le diagramme de la figure 5.4 introduit des nouvelles contraintes et montre comment les utiliser. La
liste est encore longue, mais le pouvoir expressif de ces contraintes reste insuffisant et l’utilisation
d’un langage de contraintes devient une véritable nécessité. Le langage de contraintes objet OCL
apporte une solution élégante à cette insuffisance.
 5.3.5 Le langage de contrainte OCL

C'est avec OCL (Object Constraint Language) qu'UML formalise l'expression des contraintes. Il s'agit
donc d'un langage formel d'expression de contraintes bien adapté aux diagrammes d'UML, et en
particulier au diagramme de classes.

OCL existe depuis la version 1.1 d'UML et est une contribution d'IBM. OCL fait partie intégrante de la
norme UML depuis la version 1.3 d'UML. Dans le cadre d'UML 2.0, les spécifications du langage OCL
figurent dans un document indépendant de la norme d'UML, décrivant en détail la syntaxe formelle
et la façon d'utiliser ce langage.

Figure 5.5. Diagramme d’objets valide mais ne respectant parfaitement les spécifications.

La figure ci-dessus présente un diagramme d’objets valide vis-à-vis du diagramme de classes mais ne
respecte pas la spécification attendue :

- Une personne a un compte dans une banque où elle n'est pas cliente
- Une personne est cliente d'une banque mais sans y avoir de compte

OCL peut s'appliquer sur la plupart des diagrammes d'UML (Barbier et al 2005) et permet de
spécifier des contraintes sur l'état d'un objet ou d'un ensemble d’objets comme :

 les invariants doivent être respectés en permanence;

 les préconditions doivent être vérifiées avant l'exécution,
 les postconditions doivent être vérifiées après l'exécution ;
 des ensembles d’objets destinataires pour un envoi de message ;
 une expression OCL décrit une contrainte à respecter et pas le « code » d'une méthode.

Dans une contrainte OCL associée à un objet, on peut :

- Accéder à l'état interne de cet objet (ses attributs)

- Naviguer dans le diagramme : accéder de manière transitive à tous les objets (et leur état)
avec qui il est en relation
L’usage d’OCL dans l’application bancaire peut être résumé comme suit (Cariou 2015) :

context Compte
inv: proprié[Link] >= 18// Le propriétaire d'un compte doit avoir plus de 18 ans
inv: solde > 0 // Pour toutes les instances de la classe Compte, l'attribut solde doit toujours être positif
context Compte : débiter(somme : int)
pre: somme > 0 //précondition solde >0
post: solde = solde@pre – somme // Postcondition : la somme à débiter doit être positive pour que l'appel
de l'opération soit valide. Après l'exécution de l'opération, l'attribut solde doit avoir pour valeur la différence de
sa valeur avant l'appel et de la somme passée en paramètre
context Compte
inv: [Link] -> includes (propriétaire) // une personne ne peut avoir un compte dans une banque où
elle n'est pas cliente et une personne est cliente d'une banque mais sans y avoir de compte

OCL propose un ensemble de primitives utilisables sur les ensembles :

- size() : retourne le nombre d'éléments de l'ensemble
- isEmpty() : retourne vrai si l'ensemble est vide
- notEmpty() : retourne vrai si l'ensemble n'est pas vide
- includes(obj) : vrai si l'ensemble inclut l'objet obj
- excludes(obj) : vrai si l'ensemble n'inclut pas l'objet obj
- …

5.4 Implémentation en java

Nous allons montrer comment implémenter une classe simple ainsi que l’instanciation de ces objets
dans la classe main. Notons qu’on s’est basé sur les exemples d’implémentations présentés dans le
livre de UML2 de l’apprentissage à la pratique de Laurent Audibert (Audibert 2009) .

Figure 5.6 exemple d’une classe A.

Code de la classe en java

public class A {
public String a1;
package String a2;
protected String a3;
private String a4;
public void op1() {
...
}
public void op2() {
...
}
}
Instanciation de l’objet dans la fonction main

…
public static void main(String[] args){
A a = new A(); // instanciation de la
classe A et l’objet instanciée
exécutera automatiquement le
constructeur.
}
…

5.4.1 Implémentation de la relation bidirectionnelle 1-1

Figure 5.7 Relation bidirectionnelle 1-1.

public class A {
private B rb;
public void addB( B b ) {
if( b != null ){
if ( [Link]() != null ) { // si b est déjà connecté à un
autre A
[Link]().setB(null); // cet autre A doit se déconnecter
}
[Link]( b );
[Link]( this );
}
}
public B getB() { return( rb ); }
public void setB( B b ) { [Link]=b; }
}

public class B {
private A ra;
public void addA( A a ) {
if( a != null ) {
if ([Link]() != null) { // si a est déjà connecté à un
autre B
[Link]().setA( null ); // cet autre B doit se déconnecter
}
[Link]( a );
[Link]( this );
}
}
public void setA(A a){ [Link]=a; }
public A getA(){ return(ra); }
}
5.4.2 Implémentation de la relation bidirectionnelle 1-N

Figure 5.8 Relation bidirectionnelle 1-N.

public class A {
private ArrayList <B> rb;
public A() { rb = new ArrayList<B>(); }
public ArrayList <B> getArray() {return(rb);}
public void remove(B b){[Link](b);}
public void addB(B b){
if(  ){
if ([Link]()!=null) [Link]().remove(b);
[Link](this);
[Link](b);
}
}
}

public class B {
private A ra;
public B() {}
public A getA() { return (ra); }
public void setA(A a){ [Link]=a; }
public void addA(A a){
if( a != null ) {
if( ![Link]().contains(this)) {
if (ra != null) [Link](this);
[Link](a);
[Link]().add(this);
}
}
}
}

5.4.3 Implémentation de la relation unidirectionnelle 1-N

Figure 5.9 Relation unidirectionnelle 1-N.

public class A {
private ArrayList <B> rb;
public A() { rb = new ArrayList<B>(); }
public void addB(B b){
if(  ) {
[Link](b);
}
}
}

public class B {
... // B ne connaît pas l'existence de A
}
5.4.4 Implémentation de la relation unidirectionnelle 1-1

Figure 5.10 Relation unidirectionnelle 1-1.

public class A {
private B rb;
public void addB( B b ) {
if( b != null ) {
[Link]=b;
}
}
}

public class B {
... // La classe B ne connaît pas l'existence de la
classe A
}

5.5 Conclusion

Nous avons présenté dans ce chapitre le diagramme d’objets qui représente une ou plusieurs
instanciations du diagramme de classes pour faciliter la validation de celui-ci. Nous avons vu qu’un
diagramme d’objets représente un état du système en utilisant l’ensemble des contraintes
prédéfinies. Ces contraintes doivent être formulées en utilisant le langage OCL. Nous avons montré
que l’utilisation d’OCL permet d’organiser le travail.

Ce chapitre a montré comment implémenter le diagramme de classes afin de s’orienter sur le point
de vue implémentation. L’objectif était de présenter des exemples de contenu d’implémentation
facilitant la compréhension du diagramme d’objets et son utilisation dans le système. Un diagramme
d’objets donc ne montre pas l'évolution du système dans le temps. Pour représenter ce fait, en se
basant sur les interactions au fil du temps, il faut utiliser le diagramme d’interaction. Le chapitre
suivant présentera le diagramme d’interaction.