BAZOMANZA Wilfried, ISC

L1 Informatique de Gestion
Année universitaire: 2021-2022
La modélisation UML ( 45 heures)
▪ Introduction au langage UML
▪ Chapitre 1- La modélisation UML et les modèles
▪ Chapitre 2: Les diagrammes UML
▪Chapitre 3- Exercices (15 heures)
- Les techniques de programmation n’ont cessé de progresser depuis
l’époque de la programmation en langage binaire (cartes perforées,
switch) à nos jours.

- Evolution dictée par le besoin de concevoir et de maintenance

des applications plus complexes

- La programmation structurée a permis de développer et de

maintenir des applications plus ambitieuses. L’algorithmique ne
suffisant plus à elle seule, le GENIE LOGICIEL est venu placer la
méthodologie au cœur du développement logiciel. Utilisation de la
METHODE MERISE
La taille des applications ne cessant de croître, la programmation
structurée a rencontré des limites faisant place à la
PROGRAMMATION ORIENTEE OBJET (Simula 67 en 1967, Smalltalk
en 1976, C++ en 1982, Java en 1995, . . .)

La technique Objet est la conséquence ultime de la modularisation

dictée par la maîtrise de la conception et de la maintenance
d’applications plus complexes.

Cette nouvelle technique de programmation a nécessité la

conception de nouvelles méthodes de modélisation.
UML (Unified Modeling Langage ou Langage de Modélisation Objet
Unifié) est né de la fusion de trois (3) méthodes qui s’imposaient
dans le domaine de la modélisation objet au milieu des années 1990:
- OMT (James Rumbaugh) :Object Modeling Technique
- OOSE (Ivar Jacobson): Object Oriented Software Engineering
(Objectory)
- Booch (Grady Booch)
-

-
D’important acteurs industriels (IBM, Microsoft, Oracle, DEC, HP,
Rational, Unisys, etc.) s’associent alors à l’effort et proposent UML
1.0 à l’OMG (Object Management Group) qui l’accepte en novembre
1997 dans sa version 1.1.

La version d’UML en cours à la fin 2006 est UML 2.0 qui s’impose
plus que jamais en tant que langage de modélisation standardisé
pour la modélisation des logiciels
Les modèles sont regardés et manipulés par les utilisateurs au
moyen de deux grandes vues graphiques:

❑ Vue statique
❑ vue dynamique

A chaque vue correspondent un ou plusieurs diagrammes.

UML 2.0 définit aujourd’hui plus de 13 types diagrammes

différents :
Chapitre 1: Modélisation UML et Modèles
1.1.Vues graphiques des diagrammes UML
-Analyse

❑ Diagramme de cas d’utilisation : décrit les fonctions du système selon

le point de vue de l’utilisateur futur,
❑ Diagramme de séquence : Scénarios de base entre acteur et système,
❑ Diagramme d’activités : structure d’une opération en actions.

-Conception

❑ Diagramme d’objets : illustration des objets et leur relations

❑ Diagramme de collaboration : représentation des interactions entre
objets
❑ Diagramme de classe : structure des données du système définies
comme un ensemble de relations entre classes.
❑ Diagramme d’états transition : représentation du comportement des
objets d’une classe en terme d’états et de transitions d’états
-Implémentation

❑ Diagramme de déploiement : description du déploiement des

composants sur les dispositifs matériels.
❑ Diagramme de composants : architecture des composants physiques
d’une application.

- Test

❑ Modèle de cas d’utilisation

❑ Les scénarios de base
❑ Activités
Représentation des besoins

La phase d’analyse des besoins nécessite :

❑ de comprendre les besoins à couvrir
❑ d’exprimer et de formaliser les besoins

Moyens pour représenter les besoins en UML

❑ Diagramme de cas d’utilisation : organisation générale, utilisation
système par ses acteurs
❑ Diagramme de séquence : pour chaque cas d’utilisation : description
temporelle de l’interaction d’un acteur sur le système= scénario
❑ Diagramme objets/classes : informations échangées entre système et
acteurs
❑ Diagramme de collaboration : interactions entre objets métiers et
système.
Cas d’utilisation :
 Constat : Le système existe pour servir ses
utilisateurs d’où cas d’utilisation (use cases)

 Idée : description du comportement du système

du point de vue de son utilisateur(facilite
l’expression des besoins)
-Facilitent la structuration des besoins des utilisateurs
-Donnent une représentation simple et expressive
-Expriment les limites et les objectifs du système

Un cas d’utilisation correspond à une manière spécifique

d’utiliser le système

C’est la représentation d’une fonctionnalité, déclenchée en

réponse à une stimulation du système.
La représentation d’un cas d’utilisation met en
jeu trois concepts :

- l’acteur
- le cas d’utilisation et
- l’interaction entre l’acteur et le cas
d’utilisation.
 Acteur : entité externe qui agit sur le système.
❑ prend les décisions contrairement à un élément
logiciel
❑ possède un rôle par rapport au système
❑ Soit utilisateur
❑ Soit un autre système
 Acteurs et utilisateurs

Ne pas confondre acteur et personne utilisant le

système :

 Une même personne peut jouer plusieurs rôles

 Plusieurs personnes peuvent jouer un même rôle
 Un acteur n’est pas forcément une personne
physique
Ainsi par exemple, l’administrateur d’un système de
messagerie peut être aussi utilisateur de cette même
messagerie. Il sera considéré, en tant qu’acteur du
système:

❑ dans le rôle d’administrateur d’une part et

❑ dans celui d’utilisateur d’autre part.
Deux catégories d’acteurs :

❑ les acteurs principaux : les acteurs qui utilisent les

fonctions principales du système (client, fournisseur).

❑ les acteurs secondaires : les acteurs qui effectuent

les tâches de maintenance, administration et
paramétrage du système (manager de la BD)
Trois groupes d’acteurs :

❑ Les êtres humains: Client, Etudiant, Gérant,

Comptable, ...
❑ Le matériel externe: Les périphériques
informatiques (capteurs, imprimantes)
❑ Les systèmes informatiques avec lequel le
système interagit (autres applications informatiques).
Un cas d’utilisation correspond à un certain nombre
d’actions que le système devra exécuter en réponse à
un besoin d’un acteur.

Un cas d’utilisation doit produire un résultat

observable pour un ou plusieurs acteurs ou parties
prenantes du système.

Une interaction permet de décrire les échanges entre

un acteur et un cas d’utilisation
Relation entre cas d’utilisation

❑ Il n’y a pas de communication entre cas d’utilisation d’un système mais

simplement des relations d’utilisation (uses c.à.d. utilise, et Extend c.à.d.
étend)

❑ Les communications entre les acteurs ne sont pas représentées.

Relation d’utilisation « uses »: une relation
d’utilisation entre cas d’utilisation signifie qu’une
instance du cas d’utilisation source comprend
également le comportement décrit par le cas
d’utilisation destination.
Relation d’extension «Etend »:
Une relation d’extension entre cas d’utilisation signifie
que le cas d’utilisation source étant le comportement
du cas d’utilisation destination.
Relation de généralisation

Une relation de généralisation de cas d’utilisation peut

être définie conformément au principe de la
spécialisation-généralisation déjà présentée pour les
classes.
Tout système peut être décrit par un certain
nombre de cas d’utilisation correspondant aux
besoins exprimés par l’ensemble des utilisateurs.
À chaque utilisateur, vu comme acteur, correspondra
un certain nombre de cas d’utilisation du système.

L’ensemble de ces cas d’utilisation se représente sous

forme d’un diagramme.
Etude de cas 1

Dans un établissement scolaire, on désire gérer la réservation des

salles de cours ainsi que du matériel pédagogique (ordinateur portable
ou/et Vidéo projecteur).

Seuls les enseignants sont habilités à effectuer des réservations (sous

réserve de disponibilité de la salle ou du matériel).

Le planning des salles peut quant à lui être consulté par tout le
monde
(enseignants et étudiants).

Par contre, le récapitulatif horaire par enseignant (calculé à partir du

planning des salles) ne peut être consulté que par les enseignants.
Enfin, il existe pour chaque formation un enseignant responsable qui
seul peut éditer le récapitulatif horaire pour l’ensemble de la
formation.
Etude de cas 2
Une bibliothèque universitaire souhaite automatiser sa gestion. Cette bibliothèque est gérée
par un gestionnaire chargé des inscriptions et des relances des lecteurs quand ceux-ci n’ont
pas rendu leurs ouvrages au-delà du délai autorisé. Les bibliothécaires sont chargés de
gérer les emprunts et la restitution des ouvrages ainsi que l’acquisition de nouveaux
ouvrages.

Il existe trois catégories d’abonné. Tout d’abord les étudiants qui doivent seulement
s’acquitter d’une somme forfaitaire pour une année afin d’avoir droit à tous les services de la
bibliothèque.
L’accès à la bibliothèque est libre pour tous les enseignants.

Enfin, il est possible d’autoriser des étudiants d’une autre université à s’inscrire
exceptionnellement comme abonné moyennant le versement d’une cotisation. Le nombre
d’abonné externe est limité chaque année à environ 10 % des inscrits. Un nouveau service
de consultation du catalogue général des ouvrages doit être mis en place.

Les ouvrages, souvent acquis en plusieurs exemplaires, sont rangés dans des rayons de la
bibliothèque. Chaque exemplaire est repéré par une référence gérée dans le catalogue et le
code du rayon où il est rangé.

Chaque abonné ne peut emprunter plus de trois ouvrages. Le délai d’emprunt d’un ouvrage
est de trois semaines, il peut cependant être prolongé exceptionnellement à cinq semaines.
Il est demandé d’élaborer le diagramme des cas d’utilisation (DCU).
Définition et rôle
Les diagrammes d’états-transitions d’UML décrivent le
comportement interne d’un objet à l’aide d’un automate à
états finis.

Ils présentent les séquences possibles d’états et d’actions

qu’une instance de classe peut traiter au cours de son cycle de
vie en réaction à des événements discrets (de type signaux,
invocations de méthode)

Le diagramme d’états-transitions est le seul diagramme, de la

norme UML, à offrir une vision complète et non ambiguë de
l’ensemble des comportements de l’élément auquel il est
attaché.
Etat-transition et événement

L’état d’un objet est défini, à un instant donné, par l’ensemble

des valeurs de ses propriétés.
Le passage d’un état à un autre état s’appelle transition. Un
événement est un fait survenu qui déclenche une transition.
Types d’événements (4) :

• Type appel de méthode (call) – C’est le type le plus courant que nous
traiterons dans la suite de la présentation.
• Type signal – Exemple : clic de souris,
• Type changement de valeur (vrai/faux) – C’est le cas de l’évaluation
d’une expression booléenne.
• Type écoulement du temps – C’est un événement lié à une condition de
type after (durée) ou when (date).
Formalisme
Formalisme (action et activités)
Représentation du diagramme d’état-transition d’un objet

L’enchaînement de tous les états caractéristiques d’un objet constitue le diagramme

d’état.

Un diagramme d’états débute toujours par un état initial et se termine par un

ou plusieurs états finaux sauf dans le cas où le diagramme d’états représente une
boucle. À un événement peut être associé un message composé d’attributs.
Exemple: Représentation du diagramme d’état-transition d’un objet Client (tiré
de la gestion commerciale)
Le diagramme d’état-transition de l’objet « personnel » caractérisé par trois états :

• En prévision d’arrivée : si la date prévisionnelle est postérieure à la date du jour.

• En activité : état qui correspond à un personnel ayant une date d’arrivée renseignée.
• Parti : état qui correspond à un personnel ayant une date de départ renseignée.
Compléments sur le diagramme d’état-transition

Composition et décomposition d’état

Le diagramme d’état-transition peut être décrit à plusieurs niveaux.

Au premier niveau: le diagramme comprendra des états élémentaires et des états
composites.
Les états composites seront ensuite décrits à un niveau élémentaire
dans un autre diagramme. On peut aussi parler d’état composé et d’état composant.

Sous-machine d’état
Point d’entrée et de sortie

Sur une sous-machine d’état, il est possible de repérer un point d’entrée et

un point de sortie particuliers..
Point de jonction

Lorsque l’on veut relier plusieurs états vers d’autres états, un point de
jonction permet de décomposer une transition en deux parties en indiquant
si nécessaire les gardes propres à chaque segment de la transition.
À l’exécution, un seul parcours sera emprunté, c’est celui pour lequel toutes
les conditions de garde seront satisfaites.
Point de choix

Le point de choix se comporte comme un test de type : si condition faire

action1 sinon faire action2.
État historique

La mention de l’historisation d’un état composite permet de pouvoir indiquer

la réutilisation du dernier état historisé en cas de besoin.
Exercice 1

Soit à représenter le diagramme d’état-transition d’un objet personnel

en suivant les événements de gestion depuis le recrutement jusqu’à la
mise en retraite.

Après le recrutement, une personne est considérée en activité dès sa

prise de fonction dans l’entreprise. Au cours de sa carrière, nous
retiendrons seulement les événements : congé de maladie et prise de
congé annuel.

En fin de carrière, nous retiendrons deux situations : la démission et la

retraite.
Exercice 2

Ma montre affiche l’heure, si j’appuie 2X sur le bouton 1, la montre passe en mode

“modification”. Chaque pression sur le bouton 2, incrémente l’heure d’une unité. Si
j’appuie encore une fois sur le bouton 1, je peux régler les minutes de la même façon
que les heures. Si j’appuie une quatrième fois sur le bouton 1, la montre affiche à
nouveau l’heure courante

Exercice 3
Un ensemble de personnes décident d’établir un contrat. Pour ce faire elles rédigent
un projet par itération successive. Le contrat est ensuite informellement accepté par
les parties, et devient ce que l’on appelle un préaccord. A ce stade il peut toujours
être l’objet de modification et revenir à l’état de projet. Une fois le préaccord
définitivement établi, le contrat est signé par les parties. Dès ce moment les
partenaires sont liés. Une fois signé, le contrat peut être rendu exécutoire par une
décision d’une des parties. Un contrat en exécution peut faire l’objet de discussions
qui sont réglées par un arbitre désigné à cet effet. Le contrat une fois exécuté prend
fin.
Les diagrammes d’activités permettent de mettre l’accent sur les
traitements. Ils sont donc particulièrement adaptés à la modélisation du
cheminement de flots de contrôle et de flots de données. Ils permettent ainsi
de représenter graphiquement le comportement d’une méthode ou le
déroulement d’un cas d’utilisation.

Le diagramme d’activité présente un certain nombre de points communs

avec le diagramme d’état-transition puisqu’il concerne le comportement
interne des opérations ou des cas d’utilisation.

En pratique, les diagrammes d’activités sont adaptés à la description des cas

d’utilisation,
Cependant le comportement visé ici s’applique aux flots de contrôle et aux
flots de données propres à un ensemble d’activités et non plus relativement
à une seule classe,

Les concepts communs ou très proches entre le diagramme d’activité et le

diagramme d’état-transition sont :

❑ transition,
❑ nœud initial (état initial),
❑ nœud final (état final),
❑ ⊗ nœud de fin flot (état de sortie),
❑ ◊ nœud de décision (choix).

Le formalisme reste identique pour ces nœuds de contrôle.

Les concepts spécifiques au diagramme d’activité sont :

❑ nœud de bifurcation,
❑ nœud de jonction,
❑ nœud de fusion,
❑ pin d’entrée et de sortie,
❑ flot d’objet,
❑ partition.
Description du diagramme d’activités:

❑ Action
- Une action est le plus petit traitement qui puisse être exprimé en UML
- Elle possède une incidence sur le système ou en extrait une information
- Il s’agit d’une notion à rapprocher de la notion d’instruction élémentaire
d’un langage de Programmation
- (types d’actions: TP)

Formalisme

Une action est représentée par un rectangle dont les coins sont arrondis
comme pour les états du diagramme d’état-transition
Description du diagramme d’activités:

❑ Transition et flot de contrôle

Dès qu’une action est achevée, une transition automatique est déclenchée
vers l’action suivante. Il n’y a donc pas d’événement associé à la transition.
L’enchaînement des actions constitue le flot de contrôle.

Formalisme
Description du diagramme d’activités:

❑ Activité

- Une activité représente le comportement d’une partie du système en

termes d’actions et de transitions.
- Elle définit un comportement décrit par un séquencement organisé
d’unités dont les éléments simples sont les actions
Description du diagramme d’activités:

Une activité est composée de trois types de nœuds :

- nœud d’exécution (action, transition),

- nœud de contrôle (nœud initial, nœud final, flux de sortie, nœud de
bifurcation, nœud de jonction, nœud de fusion-test, nœud de test-décision,
pin d’entrée et de sortie),
- nœud d’objet.
Une activité peut recevoir des paramètres en entrée et en produire en sortie.
Description du diagramme d’activités:

❑ Formalisme d’une activité

.
Description du diagramme d’activités:

❑ Noeud de bifurcation (fourche)

Un nœud de bifurcation (fourche) permet à partir d’un flot unique entrant de

créer plusieurs flots concurrents en sortie de la barre de synchronisation.
Description du diagramme d’activités:

❑ Nœud de jonction (synchronisation)

Un nœud de jonction (synchronisation) permet, à partir de plusieurs flots

concurrents en entrée de la synchronisation, de produire un flot unique
sortant.
Description du diagramme d’activités:

❑ Nœud de test-décision

Un nœud de test-décision permet de faire un choix entre plusieurs flots

sortants en fonction des conditions de garde de chaque flot.
Un nœud de test-décision n’a qu’un seul flot en entrée.
On peut aussi utiliser seulement deux flots de sortie : le premier
correspondant à la condition vérifiée et l’autre traitant le cas sinon.
Description du diagramme d’activités:

❑ Nœud de fusion-test
Un nœud de fusion-test permet d’avoir plusieurs flots entrants possibles et
un seul flot sortant. Le flot sortant est donc exécuté dès qu’un des flots
entrants est activé.
Exemple:

Diagramme d’activités
modélisant le fonctionnement
d’une borne bancaire.
Description du diagramme d’activités:

❑ Pin d’entrée et de sortie

Un pin d’entrée ou de sortie représente un paramètre que l’on peut

spécifier en entrée ou en sortie d’une action. Un nom de donnée et un type
de donnée peuvent être associés au pin. Un paramètre peut être de type
objet.
Chaque paramètre se représente dans un petit rectangle. Le nom du
paramètre ainsi que son type sont aussi à indiquer
Description du diagramme d’activités:

❑ Flot de données et nœud d’objet

Un nœud d’objet permet de représenter le flot de données véhiculé entre

les actions. Ce nœud représente l’existence d’un objet généré par une action
dans une activité et utilisé par d’autres actions,

Les objets peuvent se représenter de deux manières différentes : soit en

utilisant le pin d’objet soit en représentant explicitement un objet.
Description du diagramme d’activités:

❑ Partition

UML permet aussi d’organiser la présentation du diagramme d’activité en

couloir d’activités. Chaque couloir correspond à un domaine de
responsabilité d’un certain nombre d’actions.
1. Identifiez la portée (« scope ») du diagramme d'activité
Commencez en identifiant ce que vous allez modéliser. Un seul use case?
Une partie d'un use case ? Un « workflow » qui inclut plusieurs use cases ?
Une méthode de classe ?
2. Ajouter l’état de départ et de terminaison
3. Ajouter les activités

Si vous modélisez un use case, introduisez une activité pour chaque use case
principal. Si vous modélisez un « workflow », introduisez une activité pour
chaque processus principal, souvent un use case. Enfin, si vous modélisez une
méthode, il est souvent nécessaire d’avoir une activité pour chaque grand
étape de la méthode.
4. Ajouter des transitions (séquentielles), des transitions alternatives
(conditionelles), des synchronisations entre des activités, des iterations.
5. Identifier des swimlanes et répartir des activités identifiées dans ces
swimlanes.
 Construire un diagramme d’activité
représentant l’utilisation d’une cafetière
électrique:
▪ premier état: chercher du café
▪ dernier état: Servir du café

67
68
 Construire un diagramme d’activité pour modéliser
le processus de commander d’un produit. Le
processus concerne les acteurs suivants:
▪ Client: qui commande un produit et qui paie la facture
▪ Caisse: qui encaisse l’argent du client
▪ Vente: qui s’occupe de traiter et de facturer la commande
du client
▪ Entrepôt: qui est responsable de sortir les articles et
d’expédier la commande.

69
70
Le logiciel de gestion des réparations est destiné en priorité au chef d'atelier, il
devra lui permettre de saisir les fiches de réparations et le travail effectué
par les divers employés de l'atelier.
Pour effectuer leur travail, les mécaniciens et autres employés de l'atelier
vont chercher des pièces de rechange au magasin. Lorsque le logiciel sera
installé, les magasiniers ne fourniront des pièces que pour les véhicules
pour lesquels une fiche de réparation est ouverte; ils saisiront
directement les pièces fournies depuis un terminal installé au magasin.
Lorsqu'une réparation est terminée, le chef d'atelier va essayer la voiture. Si
tout est en ordre, il met la voiture sur le parc clientèle et bouclera la fiche de
réparation informatisée. Les fiches de réparations bouclées par le chef
d'atelier devront pouvoir être importées par le comptable dans le logiciel
comptable.
Exercice 3. Créer un diagramme d’activité pour tout le traitement d’une
réparation.
Exercice 4. Créer un diagramme d’activité pour le use case « Créer une fiche
de réparation »
71
72
Exercice 2. Créer un diagramme d’activité pour le use case « Créer une fiche
de réparation »
Pour créer une fiche de réparation, le chef d’atelier saisit les critères de
recherche de voitures dans le système. Le logiciel de gestion des
réparation lui donne la liste des voitures correspondant aux critères entrés.
Si la voiture existe, le chef d’atelier va sélectionner la voiture. Le logiciel
va, ensuite, fournir les informations sur le véhicule. Si la voiture est sous
garantie, le chef devra saisir la date de demande de réparation. Si la
voiture n’existe pas, le chef va saisir les informations concernant ce
nouveau véhicule. Dans tous les cas, le chef d’atelier devra saisir la date de
réception et de restitution. Si le dommage de la voiture est payé par
l’assurance, le logiciel va fournir une liste d’assurances au chef d’atelier. Ce
dernier sélectionnera l’assurance adéquate. Enfin, le logiciel enregistre la
fiche de réparation.

73
[ ] [ ]

[ ]

[ ]

[ ]

[ ]

74
1. 4. Diagramme Séquence Système

1.5. Diagramme Séquence

UC, scénario, scénario nominal
Un UC est une abstraction.
Les scénarios correspondent aux instances concrètes d’un UC.
Le scénario nominal est le scénario pour lequel le UC est conçu.
Les scénarios alternatifs sont les scénarios alternatifs au scénario nominal.
Définition d’un diagramme de séquence « système »
Le diagramme de séquence « système » décrit, pour un UC, ou pour un
scénario d’un UC, les échanges entre l’utilisateur et le système (c’est-à-
dire le logiciel à réaliser) et plus généralement les échanges entre le
système et tous les acteurs du système.
On peut choisir de se limiter au diagramme de séquence système du
scénario nominal pour éviter d’alourdir le diagramme. Les scénarios
alternatifs pourront être présentés dans un diagramme d’activité.
Attention : ne pas confondre avec le diagramme de séquence « objet »
Le diagramme de séquence « objet » décrit les échanges de messages entre
les objets, autrement dit, les appels de méthode d’un objet par un autre. Ce
diagramme relève de l’analyse organique. Il sera détaillé dans un autre
cours.
Version textuelle du diagramme séquence Système
La séquence des échanges entre l’utilisateur et le système pour un UC
donné peut être présentée de façon uniquement textuelle. Dans ce
cas, on présente tous les scénarios de l’UC et non pas seulement le
scénario nominal.
Description textuelle du UC : « save as »
On peut aussi décrire les scénarios de façon uniquement textuelle
(on n’utilisera pas cette méthode).
En général dans ce cas, on décrit à la fois le cas nominal et les cas
alternatifs.
Syntaxe des descriptions textuelles des diagrammes de séquence «
système »
On décrit l’enchaînement nominal, puis les alternatives. Les
alternatives peuvent conduire à la fin de l’UC ou à un retour à une
étape du cas nominal. Toute sortie de l’UC s’accompagne d’une
description des post-conditions.
Syntaxe des diagrammes de séquence « système »
Dans cet exemple, on a 2 acteurs secondaires qui sont des machines :
le système central (un logiciel) et l’imprimante (une machine
physique).
Remarques:
On a choisi d’entrer dans l’UC par l’ouverture du compte et d’en
sortir avec un compte ouvert. On pourrait aussi choisir de fermer le
compte dans l’UC ou d’entrer dans l’UC avec un compte ouvert.
Remarques :
La description textuelle permet de représenter les alternatives et les
répétitions. On n’a pas présenter cette possibilité dans les
diagrammes de séquence, toutefois la syntaxe UML le permet,
quoique ce soit peu recommandé et peu utilisé pour des questions de
lisibilité.
Pour représenter les alternatives, on préférera l’utilisation de
diagrammes d’activités.
Modularité, Test, Boucle et autres contraintes
- Modularité
On peut regrouper dans un module une séquence d’échanges entre
l’utilisateur et le système. Ce module pourra être utilisé dans
d’autres diagrammes de séquence sans avoir à re-détailler son
contenu.
Test, Boucle et autres contraintes
 DCL est le pivot essentiel de la modélisation
UML

 permet de donner la représentation statique

du système à développer

 Représentation basée sur les concepts de

classes et associations
La description du diagramme de classe est fondée
sur :
• le concept d’objet,
• le concept de classe comprenant les attributs et
les opérations,
• les différents types d’association entre classes.
1. le concept d’objet
Un objet est un concept, une abstraction ou une chose
qui a un sens dans le contexte du système à modéliser.

Chaque objet a une identité et peut être distingué des

autres sans considérer a priori les valeurs de ses
propriétés.

 Objets physiques: une chaise, une voiture, une personne, un vélo

 Objets de gestion: la Commande n° 12, le Client Durand
Nom de l’objet NomObjet:NomClasse
2. Classe, attribut et opération
Une classe décrit un groupe d’objets ayant les mêmes
propriétés (attributs), un même comportement
(opérations), et une sémantique commune (domaine de
définition).

Formalisme de la classe: rectangle à 3 compartiments

 la désignation de la classe,
 la description des attributs,
 la description des opérations.
Deux autres compartiments peuvent être aussi indiqués :

• la description des responsabilités de la classe,

• la description des exceptions traitées par la classe.
Un attribut est une propriété élémentaire d’une classe.
Pour chaque objet d’une classe, l’attribut prend une valeur
(sauf cas d’attributs multivalués).
Un attribut peut avoir des valeurs multiples. Dans ce cas,
cette caractéristique est indiquée après le nom de l’attribut
(ex. : prénom [3]).
Un attribut dont la valeur peut être calculée à partir
d’autres attributs de la classe est un attribut dérivé qui se
note « /nom de l’attribut dérivé »
Opération
Une opération est une fonction applicable aux objets d’une
classe. Une opération permet de décrire le comportement
d’un objet. Une méthode est l’implémentation d’une
opération.
 La signature d’une méthode correspond au nom de la
méthode et la liste des paramètres en entrée.
Visibilité des attributs et opérations
 Chaque attribut ou opération d’une classe peut être de
type:
 + (public): Attribut ou opération visible par tous.,
 # (protégé): visible seulement à l’intérieur de la classe et
pour toutes les sous-classes de la classe,
 - (privé): seulement visible à l’intérieur de la classe
 ~ (paquetage): Attribut ou opération ou classe seulement
visible à l’intérieur du paquetage où se trouve la classe
3. Association, multiplicité, navigabilité et contraintes
Lien et association
Un lien est une connexion physique ou conceptuelle entre
instances de classes donc entre objets.

Une association décrit un groupe de liens ayant une même

structure et une même sémantique

Une association entre classes représente les liens qui existent

entre les instances de ces classes
Formalisme lien et association

Rôle d’association
Le rôle tenu par une classe vis-à-vis d’une association peut être précisé sur
l’association.
Multiplicité
La multiplicité indique un domaine de valeurs pour
préciser le nombre d’instance d’une classe vis-à-vis d’une
autre classe pour une association donnée (Cardinalités en
MERISE: notation inversée)
Association de dimension supérieure à 2 et classe-association
Une association de dimension supérieure à 2 se représente
en utilisant un losange permettant de relier toutes les
classes concernées.
Une classe-association permet de décrire soit des attributs
soit des opérations propres à l’association
Agrégation et composition entre classes
L’agrégation est une association qui permet de
représenter un lien de type « ensemble » comprenant des «
éléments »
 Composition
La composition est une relation d’agrégation dans laquelle
il existe une contrainte de durée de vie entre la classe «
composant » et la ou les classes « composé ».
Interface
Une classe d’interface permet de décrire la vue externe
d’une classe.
La classe d’interface, identifiée par un nom, comporte la
liste des opérations accessibles par les autres classes.

Le compartiment des attributs ne fait pas partie de la

description d’une interface.

L’interface peut être aussi matérialisée plus globalement

par un petit cercle associé à la classe source.
La classe utilisatrice de l’interface est reliée au symbole de
l’interface par une flèche en pointillé.

La classe d’interface est une spécification et non une classe

réelle.

Une classe d’interface peut s’assimiler à une classe

abstraite.
Généralisation et spécialisation
Diagramme de classes vers Base de données
relationnelle:

Outils PowerDesigner:
https://www.youtube.com/watch?v=i6pMPM11bbs
Un paquetage regroupe des éléments de la modélisation appelés aussi
membres, portant sur un sous-ensemble du système.

Le découpage en paquetage doit traduire un découpage logique du système

à construire qui corresponde à des espaces de nommage homogènes.

Représentation d’un paquetage

- Représentation globale

- Représentation détaillée

- Représentation éclatée
Exemples
Les paquetages sont des constructions UML qui peuvent être utilisées pour organiser les
éléments d'un classifieur UML dans différents types de diagrammes UML.
Les diagrammes de package sont le plus souvent utilisés dans les :

•Diagrammes de cas d'utilisation : chaque cas d'utilisation est représenté comme un

paquetage individuel.
•Diagrammes de classes : les classes sont organisées en paquetages.

Les paquetages peuvent également être utilisés dans d'autres types de modélisations
UML:
- Organiser et structurer des éléments tels que des classes, des entités de données et
des cas d'utilisation.
- En utilisant la structure des diagrammes de paquetages dans d'autres diagrammes
UML, vous pouvez simplifier n'importe quel type de modélisation et faciliter davantage
sa compréhension.
Dépendance entre paquetages

- Deux types de dépendance: import et access

« import »
Ce type de dépendance permet, pour un paquetage donné, d’importer
l’espace de nommage d’un autre paquetage.

Ainsi tous les membres du paquetage donné ont accès à tous les noms des
membres du paquetage importé sans avoir à utiliser explicitement le nom du
paquetage concerné.

Ce type de dépendance correspond à un lien ayant une visibilité « public ».

Dépendance entre paquetages

« access »

Ce type de dépendance permet, pour un paquetage donné, d’avoir accès à

l’espace de nommage d’un paquetage cible.

L’espace de nommage n’est donc pas importé et ne peut être transmis à

d’autres paquetages par transitivité.

Ce type de dépendance correspond à un lien ayant une visibilité « privé ».

Les éléments de Clients externes sont importés dans Domaine client et ensuite dans
Domaine tiers.
Cependant, les éléments de Clients internes sont seulement accessibles par le paquetage
Domaine client et donc pas à partir du paquetage Domaine tiers.
Fusion entre paquetages

UML propose aussi une opération de fusion entre deux paquetages.

Le lien de dépendance comporte dans ce cas le mot-clé « merge ».

Ce type de lien permet de fusionner deux paquetages et d’obtenir ainsi un

paquetage contenant la fusion des deux paquetages d’origine

Rôle des paquetages dans la fusion

- Le paquetage à fusionner
- Le paquetage recevant
- Le paquetage résultat
Rôle des paquetages dans la fusion

- Le paquetage à fusionner
Paquetage entrant dans la fusion, mais préservé après la fusion;

- Le paquetage recevant
Paquetage d’origine avant la fusion, mais non conservé après la fusion

- Le paquetage résultat
Paquetage contenant le résultat de la fusion et écrasant le contenu du
paquetage d’origine.