Année universitaire

2020/2021 Tutoriel
Introduction à la
modélisation des
systèmes
d’information
Version 1.0

Réalisé par : UP GL-BD

Noura ABDAOUI

Rahma DHAOUADI

Rahma FERJANI

Avec la participation de :

Sonia MESBAH
 Analyse Fonctionnelle
Diagramme de cas d’utilisation

 L’analyse fonctionnelle consiste à rechercher et à caractériser les services offerts par un

produit placé dans un système pour satisfaire les besoins de son utilisateur.
 L’une des langages les plus utilisés pour modéliser un système complet est le langage de
modélisation UML : Unified Modeling Language.
 Le diagramme le plus adéquat dans la phase d’analyse fonctionnelle est le diagramme
de cas d’utilisation.

1. Diagramme de cas d’utilisation :

Le diagramme de cas d’utilisation est utilisé pour présenter toutes les fonctionnalités offertes
par un système du point de vue utilisateurs et rôles.

Le diagramme de cas d’utilisation est donné par un ensemble d’éléments de base :

2. Acteur :

Un acteur c’est un rôle offert par le système à modéliser joué par une personne externe, un
processus ou une chose qui interagit avec ce système. Donc, un acteur peut être une personne
physique, un dispositif matériel ou un autre système mis en place.

Exemple :

Dans le système « Guichet automatique d’une banque », le client qui vient de retirer de
l’argent est un acteur.

Un acteur se représente par un petit bonhomme comme indiqué dans la figure 1.1 avec son
nom (i.e. son rôle) inscrit dessous ( 1) ou par un classeur avec le stéréotype <<acteur>> au-
dessus (2).

1
 Analyse Fonctionnelle
Diagramme de cas d’utilisation

Figure 1.1 : Représentation d’un acteur

Un Cas d’utilisation CU = Une fonctionnalité complète du système.

Un cas d’utilisation modélise un service rendu par le système, sans imposer le mode de
réalisation de ce service. De point de vue utilisateur, un cas d’utilisation est un ensemble
d’activités fourni par le système et déclenché par un acteur afin d’obtenir un résultat désiré.

Exemple :

Dans le système « Guichet automatique d’une banque », ‘Retirer Argent’ est un cas
d’utilisation que présente une fonctionnalité de base de ce système.

Un cas d'utilisation se représente par une ellipse (figure 1.2) contenant le nom du cas (un
verbe à l'infinitif de préférence).

Figure 1.2 : Représentation d’un Cas d’utilisation

3. Relation d’Association entre acteur et cas d’utilisation :

L’association est un lien entre un acteur et un cas d’utilisation, représenté par un trait
continu comme indiqué dans la figure 1.3, pour attribuer une fonctionnalité du système
à un rôle bien défini.

NB : La seule relation possible entre un acteur et un cas d’utilisation est la relation

d’association.

Dans l’exemple, la relation entre l’acteur ‘client ‘ et le cas ‘retirer argent ‘ est lu
comme suit :
 Tous clients de la banque peuvent réaliser la fonctionnalité « retirer argent ».

2
 Analyse Fonctionnelle
Diagramme de cas d’utilisation

Figure 1.3 : Relation d’association

Un diagramme de cas d’utilisation complet du système du guichet automatique d’une

banque est donné par la figure 1.4.
 Le système et ses frontières sont indiqués par un package ayant le nom du système
en haut.
 Tous les cas d’utilisation doivent être à l’intérieur du système.
 Les acteurs principaux sont placés à l’extérieur du système à gauche.

1.4 : Diagramme de cas d’utilisation du système « Guichet automatique de

distribution des billets d’une banque »

3
 Analyse Fonctionnelle
Diagramme de cas d’utilisation

4. Relations entre deux cas d’utilisation :

Entre deux cas d’utilisation, on distingue 2 types de relation :

Les dépendances stéréotypées : représentées par une flèche avec un trait pointillé

[Link] d’inclusion : utilisée pour modéliser une relation de dépendance forte entre
deux cas d’utilisation A et B. On dit qu’un cas A inclut le comportement du cas B
signifie que une fois A est sollicité, B l'est obligatoirement. Cette relation d’obligation
est modélisée par une flèche avec un trait pointillé ayant le stéréotype « Include » au-
dessus comme indiqué dans la figure 1.5.
NB : le sens de flèche est du cas en cours d’exécution vers le cas obligatoire.

Le cas d’utilisation A dépend de B

1.5 : Représentation de la relation d’inclusion

Exemple :
Le cas ‘réserver une chambre ‘ inclut le cas ‘Payer acompte’. Un client ne peut pas
effectuer une réservation qu’après avoir payé son un acompte.

Réserver une chambre

Payer acompte

4
 Analyse Fonctionnelle
Diagramme de cas d’utilisation

[Link] d’extension : utilisée pour modéliser une relation de dépendance faible entre
deux cas
On dit qu’un cas 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.
Cette relation est modélisée par une flèche avec un trait pointillé ayant le stéréotype
« extend » au-dessus comme indiqué dans la figure 1.6.
NB : le sens de flèche est du cas optionnel vers le cas en cours d’exécution.

1.6 : Représentation de la relation d’extension

Exemple :
Le cas ‘Imprimer reçu‘ étend le cas ‘Consulter solde ‘. Une fois que le client procède pour
une consultation de son solde, il a le choix d’imprimer un reçu.

5. La généralisation/spécialisation :
On dit qu’un cas A est une généralisation du cas B si B est une sorte de A. La
relation est représentée par une flèche avec un trait plein dont la pointe est un
triangle fermé dont le sens est du cas le plus spécifique vers le cas le plus général.

Exemple :
Les cas d’utilisation ‘Virement inter_Bancaire ‘ et ‘Virement intr_Bancaire’ sont des
espèces du cas ‘Virement Argent ‘

5
 Analyse Fonctionnelle
Diagramme de cas d’utilisation

6. Relations entre acteurs :

Il n’y a qu’une seule relation entre deux acteurs : la généralisation.
Un acteur A est une spécification d’un acteur B signifie que l’acteur A dispose de
toutes les fonctionnalités d’acteur B ainsi que d’autres spécifiques à lui.
La relation est représentée par une flèche avec un trait plein dont la pointe est un
triangle fermé dont le sens est de l’acteur spécifique vers l’acteur général.

Exemple :
L’administrateur est une espèce de l’agent du guichet.
Tous les administrateurs sont des agents du guichet qui ont accès aux deux cas présentés
par contre aux agents du guichet qui n’ont accès qu’au cas ‘consulter compte client’.

Attention :
- Un cas d’utilisation modélise un service rendu par le système, sans imposer le mode de
réalisation de ce service. De point de vue utilisateur, un cas d’utilisation est un ensemble
d’activités fourni par le système et déclenché par un acteur afin d’obtenir un résultat désiré.

6
 Analyse Fonctionnelle
Diagramme de cas d’utilisation

 Un service déclenché automatiquement par le système (qui n’est pas déclenché par un
acteur) n’est pas un cas d’utilisation
 Ne pas confondre un cas d’utilisation (s’authentifier) et une action (saisir le login),
dans le diagramme de cas d’utilisation on ne met pas des actions.

- Un acteur c’est un rôle offert par le système à modéliser joué par une personne externe, un
processus ou une chose qui interagit avec ce système. Donc, un acteur peut être une personne
physique, un dispositif matériel ou un autre système mis en place.

 Un acteur (principale ou secondaire) est un élément externe, il ne fait pas partie du

système

7
 Analyse Dynamique
Diagramme de séquence système

L’analyse dynamique d’un système consiste à décrire son comportement lors de son interaction
avec son environnement. Cette modélisation montre le comportement du système, ses
interactions et ses évolutions dans le temps. Elle met l’accent sur la chronologie.

1. Diagramme de séquence système

Le diagramme de séquence est une solution populaire de modélisation dynamique en

langage UML.

1.1. Concepts de base

Le diagramme de séquences système se base sur les concepts suivants :
 Système : objet unique et obligatoire
 Message : C’est le véhicule de la communication entre les acteurs et le système.
1.2. Avantages de diagramme de séquence Système
Les diagrammes de séquence système peuvent constituer des références utiles pour les
entreprises et d'autres organisations. Grace à la réalisation de ce diagramme c’est facile
de :
 Représenter les détails d'un cas d'utilisation UML
 Voir comment les acteurs interagissent avec le système pour modéliser le
déroulement d'un process.
 Schématiser et comprendre le fonctionnement détaillé d'un scénario existant ou
à venir.

1.3. Représentation graphique

Pour comprendre ce qu'est un diagramme de séquence, on doit connaître ses symboles
et ses composants. Prenons l’exemple ci-dessous.

8
 Analyse Dynamique
Diagramme de séquence système

 Symbole de paquetage, utilisé dans la notation UML 2.0 pour accueillir les
éléments interactifs du diagramme de séquence système. Également connue sous le nom de
« cadre », cette forme rectangulaire est représentée par un petit rectangle intérieur qui
contient l'intitulé du diagramme.

 Entité humaine qui interagit avec le système, qui est extérieure à lui. Le client
est un acteur principal pour le cas s’utilisation ‘consulter solde’. L’acteur principal à
présenter à gauche de système.

 Boite d’activation : Représente le temps nécessaire pour qu'un objet accomplisse une
tâche. Plus la tâche nécessite de temps, plus la boîte d'activation est longue.

9
 Analyse Dynamique
Diagramme de séquence système

 Représente le système en langage UML. Le symbole système

montre comment le DAB va se comporter dans le contexte d’interaction avec l’acteur. C’est
un objet unique.
 Ligne pointillée : représente le passage du temps qui se prolonge vers le bas par une ligne
verticale en pointillés.
 Flèche continu : représente une requête, on utilise ce symbole lorsqu'un un acteur demande
la réalisation d’un service par le système. Dans l’exemple ci-dessus, le client souhaite
consulter son compte via le DAB.
 Flèche interrompu : un message de réponse. Il est représenté par une ligne en pointillés
terminée par une pointe de flèche, ces messages sont des réponses aux appels.

 C’est le symbole d’un acteur système secondaire. À

présenter à droite du système. La caisse enregistreuse dans un magasin doit

10
 Analyse Dynamique
Diagramme de séquence système

vérifier le solde de la carte avant le payement donc elle interagit avec le service
monétique pour valider le payement.

NB : Les acteurs secondaires peuvent être des êtres humains (bonhommes) ou bien
des systèmes externes (acteurs système). On doit toujours les présenter à droite du
système.

2. Fragments combinés

 Représentent un ensemble d’interactions au niveau du diagramme de séquence système.

 Permettent de décrire les diagrammes de séquence de manière plus compacte
 Peuvent faire intervenir l’ensemble des entités participant au scénario ou juste un sous-
ensemble
 Utilisés pour modéliser des scénarios ou une situation qui ne se produira qu'à certaines
conditions
 Définis par : un opérateur d’interaction (ref, opt, loop, alt…), condition de garde [] et une
ou plusieurs opérations d’interaction (conditionnée par la condition de garde)

2.1. Fragment « Atl »

11
 Analyse Dynamique
Diagramme de séquence système

 « Alt » est une instruction de test avec une ou plusieurs alternative(s) :

Si le livre recherché existe

Alors Affichage des détails du livre
Sinon Si le livre n’existe pas
Alors Affichage d’un message d’erreur
Fin si

 Symbolise des choix (qui en général s'excluent mutuellement) entre deux séquences de
messages ou plus. Pour représenter les alternatives, on utilise la forme rectangulaire
comportant un intitulé et une ligne en pointillés à l'intérieur.
 Vérifier l’existence du livre : est un message interne au niveau de notre système
Bibiliothèque pour vérifier la disponibilité du livre. Le système peut envoyer un message
à lui-même: un message réflexif.

12
 Analyse Dynamique
Diagramme de séquence système

2.2. Fragment « Opt »

 « Opt » est une instruction de test sans alternatives :

{Si condition est vraie
Alors traitements
Fin si}

2.3. Fragment « Ref »

13
 Analyse Dynamique
Diagramme de séquence système

 « Ref » : permet de référencer un autre diagramme de séquence. « Authentification » est

un cas d’utilisation utilisé comme référence pour la réalisation des autres scénarios.

2.4. Fragment « Loop »

 « Loop » : exprime des échanges répétitifs de messages entre les acteurs et le système

Tant que Condition est vraie Répéter traitements

Alors traitements Jusqu’à Condition vraie

14
 Analyse Dynamique
Diagramme de séquence système

Attention :

 La base de données fait partie du système, ce n’est pas un acteur secondaire.

 On utilise les messages réflexifs (internes) au niveau de la ligne de vie du système
uniquement.

15
 Analyse Statique
Diagramme de classe d’analyse

Introduction

Le diagramme de classes d’analyse s’intègre dans le cadre de l’analyse statique. Cette

dernière permet d’élaborer une représentation de la structure statique du système.
Le diagramme de classes d’analyse représente d’une manière préliminaire les classes qui
composent le système en considérant leurs attributs et opérations respectifs. Ce diagramme met
en relief également les relations éventuelles entre ces différentes classes.

Dans la suite de ce tutorial, nous allons traiter l’exemple suivant, afin de mieux expliciter les
notions de base de ce diagramme :

La société « maVoiture » est spécialisée dans la vente des véhicules pour les
particuliers (être moral) ou les entreprises (raison sociale). Un particulier est une
personne dotée d’un id, nom, prénom, âge, statut marital. Quant à l’entreprise, elle est
caractérisée par un id, titre, date de fondation.
Afin de fidéliser ses clients, la société offre un espace d’échange commun afin
d’encourager les différents acheteurs à recommander les uns les autres. Ainsi, un
acheteur peut recommander d’autres acheteurs comme il peut lui-même être
recommandé par autrui.
Dans ce cadre, il est possible d’acheter une ou plusieurs voitures chacune faisant
partie d’une collection particulière. En effet, une collection regroupe un ensemble de
voitures. Une voiture ne doit pas figurer en dehors du contexte d’une collection. De plus,
une collection sera supprimée une fois toutes les instances de voitures respectives sont
supprimées.
Il est à noter qu’une voiture (ayant les caractéristiques suivantes : immatricule,
couleur, marque) est composée de plusieurs éléments. Un élément quant à lui est
caractérisé par un id, date de fabrication, poids, matériau, prix. De plus, un élément peut
être composé ou non d’autres éléments. Si nous supprimons une voiture du système
(endommagée ou présentant un défaut particulier), les éléments peuvent avoir une
existence. Ces éléments peuvent être par exemple vendus séparément ou bien peuvent
remplacer leurs équivalents défectueux dans d’autres voitures. Ainsi une voiture ne
pourrait avoir une existence qu’après la prise en considération de ses éléments. Par
contre un élément tel que le moteur, la roue, le châssis, peut figurer même en dehors du
cadre d’une voiture en particulier.
Les opérations de vente sont archivées en vue d’être consultées et traitées le cas
échéant. Une opération d’achat emmagasine la date de vente et la réduction si elle a eu
lieu.

16
 Analyse Statique
Diagramme de classe d’analyse

Notion de classe

D’une façon générale, une classe est la description formelle d’un ensemble d’objets ayant une
sémantique et des caractéristiques communes. Respectivement à notre étude de cas,
différentes classes (figure 1) peuvent être mises en exergue telles que : Acheteur, Voiture,
Elément etc.

Figure 1 : Les classes Acheteur, Voiture et Elément

Une classe est dotée d’un nom, d’une liste d’attributs et d’une liste d’opérations. Dans ce qui
suit, nous allons voir la notion d’attribut et d’opération.

Notion d’attribut

Un attribut représente une information élémentaire ou une propriété d’une classe. La classe
Voiture par exemple possède une immatricule, une couleur et une marque comme attributs
(figure 2)

Figure 2 : Les attributs de la classe Voiture

Un objet est une instance d’une classe. C’est une entité discrète dotée d’une identité, d’un état
et d’un comportement que l’on peut invoquer. Dans notre exemple, la classe « Voiture » est une
entité abstraite qui peut être instanciée de sorte à en avoir des exemples réels et concrets de
voitures tels que voiture V1 de marque Mercedes, V2 de marque Clio, V3 de marque Peugot
etc.

17
 Analyse Statique
Diagramme de classe d’analyse

NB. Il est possible de spécifier les modificateurs de visibilité (private, public, protected, by
default) pour les différents attributs ainsi que leurs types (int, float, String etc.) mais à ce stade
ce n’est pas obligatoire.
La syntaxe à respecter est : [modificateur de visibilité] nomAttribut : type

Notion d’opération

Une opération représente un service proposé par une classe en particulier. En orienté objet, on
l’appelle souvent une méthode. Au niveau de classe Acheteur (figure 3), par exemple, nous
pouvons ajouter toutes les opérations manipulant un objet particulier de la classe concernée
telles que : afficherAcheteur(), supprimerAcheteur() etc.

Figure 3 : Les opérations des classes Acheteur et Voiture

NB. Il est possible de spécifier les modificateurs de visibilité (private, public, protected, by
default) pour les différentes méthodes ainsi que les différents paramètres s’ils existent. Le type
de retour peut être également précisé s’il s’agit d’une fonction. Mais à ce stade ce n’est pas
obligatoire d’ajouter tous ces détails.

La syntaxe à respecter est : [modificateur de visibilité] nomOpération (arg1 : type, arg2 : type,
…, argn : type) : type de retour/void

Notion d’association

Une association représente une relation sémantique durable entre deux classes. Respectivement
à notre exemple un acheteur peut acheter une ou plusieurs voitures. Ce qui peut être traduit
comme suit (figure 4) :

18
 Analyse Statique
Diagramme de classe d’analyse

Figure 4 : Association binaire entre la classe Acheteur et Voiture

Le nom d’une association est facultatif. Par contre les cardinalités comme sera introduit en
dessous sont obligatoires.

Notion de multiplicités

Les multiplicités, nommées aussi cardinalités, se mettent aux deux extrémités d’une association
sous forme d’un nombre min et un nombre max. D’une façon générale, les cardinalités
(multiplicités) d’une association entre une classe X et Y sont déduites directement en posant
une question dans les deux sens :
- Combien d’objets de types Y peuvent être associés à un objet de type X en particulier ?
- Combien d’objets de types X peuvent être à un objet de type Y en particulier ?
Selon notre étude de cas :
« Un acheteur peut acheter une ou plusieurs voitures »

Comme application numérique par rapport à notre exemple (figure 5), nous pouvons poser ces
2 questions :

1- Un acheteur, combien pourrait-il acheter de voiture(s) en général ?

 La réponse est 1 ou plusieurs

 1 ou plusieurs se traduit en 1..*
 Cette cardinalité se met à côté de la classe Voiture

2- Une voiture peut être achetée par combien d’acheteur(s) ?

 La réponse est 0 ou 1. Le « 1 » pour dire qu’une voiture peut être affectée qu’à un
seul acheteur. « 0 » pour dire qu’elle n’est pas encore vendue.
 La cardinalité 0..1 se met à côté de la classe Acheteur

19
 Analyse Statique
Diagramme de classe d’analyse

Figure 5 : Les cardinalités d’une l’association

NB. Les multiplicités peuvent être abréviés implicitement comme suit :

 1..1 peut être réduit à 1
 0..* peut être réduit à *

Si nous changeons de contexte, les cardinalités changent également. Dans une entreprise
voulant faciliter la gestion de son parking, par exemple, une voiture n’est affectée qu’à une
personne et une personne peut avoir 0 ou 1 voiture (figure 6).

Figure 6 : Définition des multiplicités selon le contexte

Notion de Classe d’association

Selon notre étude de cas, « les opérations de vente sont archivées en vue d’être consultées et
traitées le cas échéant. Une opération d’achat emmagasine la date de vente et la réduction si
elle a eu lieu. »

La relation « acheter » porte des informations telles que « date de vente » et « réduction ». Ces
détails concernent la classe Acheteur et la classe Voiture en même temps. En effet, un acheteur
peut acheter différentes voitures selon différentes dates et différents taux de réduction. Ainsi,
la date et la réduction appartiennent plutôt à la transaction d’achat elle-même. Pour résoudre ce
problème, nous avons fait recours à la notion de classe d’association. Ce qui veut dire
l’association « acheter » devient une classe intermédiaire entre Acheteur et Voiture comme suit
(figure 7) :

20
 Analyse Statique
Diagramme de classe d’analyse

Figure 7 : Classe d’association

NB. La classe peut garder le nom de l’association ou bien elle peut changer de nom.

Notion d’Héritage

Le mécanisme d’héritage permet de mettre en relation des classes ayant des caractéristiques
communes (attributs et comportements) en respectant une certaine filiation.
L’héritage indique qu’une classes B est une spécialisation d’une classe A.
La classe B (appelé classe fille, classe dérivée ou sous classe) hérite des attributs et des
méthodes de la classe A (appelée classe mère, classe de base ou super classe). Il se représente
par un triangle vide afin d’indiquer le sens de la généralisation (inverse de la spécialisation).

Selon notre étude de cas :

« La société « maVoiture » est spécialisée dans la vente des véhicules pour les particuliers
(être moral) ou les entreprises (raison sociale). Un particulier est une personne dotée d’un id,
nom, prénom, âge, statut marital. Une entreprise est caractérisée par id, titre, date de
fondation ». Ce qui précède peut-être modélisée comme suit (figure 8) :

21
 Analyse Statique
Diagramme de classe d’analyse

Figure 8 : Héritage entre les classes

En effet, Acheteur est considérée comme une classe mère alors que EtreMoral et RaisonSociale
sont les classes filles. Les classes filles héritent tous les attributs et de toutes les méthodes de la
classe mère. EtreMoral et RaisonSociale héritent par exemple l’attribut en commun idAcht.

Notion de Composition

La composition indique qu’un objet A (appelé conteneur) est constitué d’un autre objet B. Cet
objet A n’appartient qu’à l’objet B et ne peut pas être partagé avec un autre objet.
C’est une relation très forte, si l’objet A disparaît, alors l’objet B disparaît aussi.
Elle se représente par un losange plein du côté de l’objet conteneur

A partir de notre étude de cas, voici cette partie traitant la notion encours :

« Dans ce cadre, il est possible d’acheter une ou plusieurs voitures chacune faisant partie d’une
collection particulière. En effet, une collection regroupe un ensemble de voitures. Une voiture
ne doit pas figurer en dehors du contexte d’une collection. De plus, une collection sera
supprimée une fois toutes les instances de voitures respectives sont supprimées ».

Ainsi, une voiture n’appartient qu’à une seule collection. Si cette collection est supprimée,
toutes les voitures en question le sont aussi. De même, si tous les objets de type Voiture sont
supprimés du système alors la collection qui les regroupe n’aura plus d’existence. Ce qui
précède interpelle la notion de dépendance forte nommée aussi relation de composition. La
composition explicite une dépendance dans les 2 sens à savoir le composite, dans notre cas la
Collection, et l’élément dans notre cas la Voiture. Ce type d’association est shématisé par une
relation avec un losange plein du côté de du composite (figure 9).
22
 Analyse Statique
Diagramme de classe d’analyse

Figure 9 : Relation de composition

Notion d’Agrégation

L’agrégation indique qu’un objet A possède un autre objet B, mais contrairement à la

composition, l’objet B peut exister indépendamment de l’objet A. La suppression de l’objet A
n’entraîne pas la suppression de l’objet B

Selon notre étude de cas :

« Il est à noter qu’une voiture (ayant les caractéristiques suivantes : immatricule, couleur,
marque) est composée de plusieurs éléments. Un élément quant à lui est caractérisé par un id,
date de fabrication, poids, matériau, prix. Si nous supprimons une voiture du système
(endommagée ou présentant un défaut particulier), les éléments peuvent avoir une existence.
Ces éléments peuvent être par exemple vendus séparément ou bien peuvent remplacer leurs
équivalents défectueux dans d’autres voitures. Ainsi une voiture ne pourrait avoir une existence
qu’après la prise en considération de ses éléments. Par contre un élément tel que le moteur, la
roue, le châssis, peut figurer même en dehors du cadre d’une voiture en particulier ».

Ceci peut être modélisé via une relation d’agrégation (figure 10). Une agrégation relie deux
classes dites Agrégat et Element. Elle exprime une relation de contenance. Respectivement à
notre cas, une Voiture en particulier (agrégat) contient une ou plusieurs instances de la classe
Element (élément). Comme l’agrégation explicite une dépendance faible, l’un des deux objets
(de type Voiture ou Element) peut exister sans l’autre.

Une voiture contient 1 ou plusieurs éléments. Un élément généralement appartient à une seule
voiture à moins qu’il y aura un changement. Ainsi, dans le cas général, un élément peut être
affecté à une voiture ou plus.

23
 Analyse Statique
Diagramme de classe d’analyse

Ce type d’association est représenté via une relation avec un losange vide du côté de l’agrégat.

Figure 10 : Relation d’agrégation

Notion d’association réflexive

Une association réflexive relie une classe vers elle-même.

Selon notre étude de cas, deux exemples peuvent expliciter ce type d’association. Commençons
par le premier exemple :

« Afin de fidéliser ses clients, la société offre un espace d’échange en commun afin
d’encourager les différents acheteurs à recommander les uns les autres. Ainsi, un acheteur
peut recommander d’autres acheteurs comme il peut lui-même être recommandé par autrui ».

Ceci peut être représenté via une association réflexive d’un Acheteur vers lui-même (figure 11).
Ainsi, un acheteur peut recommander 0 ou plusieurs acheteurs (0..*) et peut lui-même être
recommandé par (0..*).

24
 Analyse Statique
Diagramme de classe d’analyse

Figure 11: Association réflexive

Passons au deuxième exemple :

« Un élément peut être composé ou non d’autres éléments. »
Ceci peut être représenté sous forme d’une association réflexive d’un Element vers un autre.
Seulement, cette relation réflexive est de nature particulière à savoir une agrégation (figure 12).

Figure 12 : Association réflexive de type agrégation

Un objet de type Elément (élément) peut appartenir à un autre Element (agrégat) en particulier.
Cet agrégat peut être composé par 1 ou plusieurs éléments élémentaires.

Exemple complet

25
 Analyse Statique
Diagramme de classe d’analyse

Nous représentons dans la suite (figure 13) la totalité du diagramme de classes d’analyse
respectivement à notre étude de cas.

Figure 13 : Diagramme de classes d’analyse complet

Attention :

 On met la méthode dans la classe sur laquelle on va subir l’action et n’ont pas
dans la classe (généralement l’objet représentant l’acteur) qui va invoquer la
méthode.

26
 Analyse Statique
Diagramme de classe d’analyse

Conclusion :

Le diagramme de classes d’analyse permet de représenter le système selon un axe statique.

Dans ce tutoriel, nous avons abordé les notions les plus pertinentes relatives à ce diagramme à
travers un exemple concret. Cependant, la modélisation adoptée reste toujours subjective,
discutable et surtout varie d’un contexte à un autre. La question qui se pose maintenant, quelles
sont les modifications à apporter à ce diagramme pour obtenir le diagramme de classes de
conception ?

27