Sie sind auf Seite 1von 120

Sommaire

Les modèles de base


Modèles complémentaires

Génie Logiciel
Introduction à UML 2
- Vocabulaire -

Saïd Mahmoudi
Said.mahmoudi@umons.ac.be

 − 

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  1 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Plan : 1 - Sommaire

1 Les modèles de base


Le diagramme de cas d’utilisation
Diagrammes de classes
Diagrammes de séquences

2 Modèles complémentaires
Diagramme de communication (collaboration)

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  2 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Qu’est-ce que UML ?

UML est un langage


UML peut être considéré à la fois comme :
une norme,
un langage de modélisation objet,
un support de communication,
un cadre méthodologique (pas une méthodologie).
Ce n’est pas une méthodologie / un processus
UML laisse la liberté de conception, et peut être combiné avec plusieurs
processus de développement
ex : Rational Unified Process (RUP)
un processus formalisé pour élaborer des modèles

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  3 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Qu’est-ce que UML ?


Historique

1 En 1994
deux méthodologistes bien connus, Rumbaugh et Booch décident de
fusionner et unifier leurs approches, ils travaillent ensemble à la
corporation Rational Software
2 En 1995
un autre méthodologist, Jacobson, se joint à l’équipe son travail met
l’emphase sur l’analyse par cas d’utilisation
3 En 1997
le « Object Management Group » (OMG) lance le processus de
standardisation UML

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  4 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Qu’est-ce que UML ? Historique

Issu en 1996 de la pratique industrielle et de la modélisation des


systèmes logiciels. Unification des méthodes objets de J-B-R
Ivar Jacobson (OOSE)
Grady Booch (BOOCH’93)
James Rumbaugh (OMT)
et Normalisation OMG en 1997.
En 2007 : UML 2.1.2
Historiques des méthodes de développement :
Fonctionnelles : années 60 Inspirée de l’architecture des ordinateurs
études des fonctions en séparant les données du code.
Les premières méthodes d’analyse (années 70) : Découpe cartésienne
(fonctionnelle et hiérarchique) d’un système.
L’approche systémique (années 80) :Modélisation des données +
modélisation des traitements (Merise ...).
Objets : années 80 Modélisation objet avec composition et décomposition
des objets ayant des propriétés et des comportements
Méthodes qui couvrent le cycle de vie d’un logiciel.
UML : de nouvelles techniques sans rejeter les méthodes existantes
Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  5 / 122
Sommaire
Les modèles de base
Modèles complémentaires

Qu’est-ce que UML ?


Historique

La définition du langage UML résulte d’un processus consensuel de


stabilisation des pratiques industrielles éprouvées
UML n’est que le reflet fidèle des pratiques majoritaires utilisées vers la fin
des années 2000 par la profession.
UML ne vise pas l’innovation, mais le consensus
Il y a deux façons de réaliser un consensus : à minima (par intersection)
ou à maxima (par union).
Ces deux tendances se retrouvent dans les groupes d’influence qui gèrent
l’évolution du langage
La tendance maximaliste a souvent été majoritaire ( !)

UML v2.0 date de 2005. Il s’agit d’une version majeure apportant des
innovations radicales et étendant largement le champ d’application d’UML.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  6 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Les points forts d’UML

UML est un langage "semi-formel" et standardisé


Gain de précision
Gage de stabilité
Encourage l’automatisation via l’utilisation d’outils dédiés
UML est un support de communication performant
Il cadre l’analyse des besoins
Il facilite la compréhension de systèmes abstraites et complexes
Son caractère polyvalent et sa souplesse en font un langage universel

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  7 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Les points faibles d’UML

La mise en pratique d’UML nécessite un apprentissage et passe par


une période d’adaptation
UML contient beaucoup (trop ?) de diagrammes ? ,...
on peut commencer avec un sous-ensemble
Le processus, qui n’est pas couvert par UML, reste la clé de la réussite
d’un projet
L’intégration d’UML dans un processus n’est pas triviale
Améliorer un processus est une tâche complexe et longue

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  8 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Modélisation en UML - Vues multiples -

1 Modélisation de la structure statique


les diagrammes de classes
les diagrammes d’objets
les diagrammes de paquetages
les diagrammes de structures composites
Modélisation de l’architecture
le logiciel : les diagrammes de composants
le matériel : les diagrammes de déploiement
2 Modélisation du comportement dynamique
modélisation de l’utilisation
les diagrammes de cas d’utilisation
modélisation des activités et états
les diagrammes d’états / les machines à états
les diagrammes d’activités
modélisation de l’interaction
les diagrammes de séquence
les diagrammes de communication (collaboration)
les diagrammes d’iteractions globales
les diagrammes de temps
Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  9 / 122
Sommaire
Les modèles de base
Modèles complémentaires

Modélisation en UML - Vues multiples -

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  10 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Modélisation en UML - Vues multiples -

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  11 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Qu’est-ce que UML ? Les diagrammes UML

Vues multiples
Diagramme de classes et d’objets : décrit les classes, leurs
inter-relations, et leurs instances
Diagramme de séquence et de communication : montre le
comportement du système par l’interaction des objets qui le composent
Diagramme d’états / machine à états : montre comment le système se
comporte de façon interne et modélise le comportement discrèt piloté
par les évènements
Diagramme de cas d’utilisation : montre les utilisations possibles d’un
logiciel
Diagramme d’activités : modélise le comportement d’un système ou
processus basé sur les flux de contrôle

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  12 / 122


Sommaire
Les modèles de base
Modèles complémentaires

Qu’est-ce que UML ? Les diagrammes UML

Diagramme de composants : montre comment les différents


composants du logiciel sont organisés logiquement. Les diagrammes de
composants permettent de décrire l’architecture physique et statique
d’une application en terme de modules : fichiers sources, librairies,
exécutables, etc.
Diagramme de déploiement : montre comment les différents
composants (machines) du matériel (hardware) sont organisés
physiquement
Diagramme d’interaction global : depuis UML 2.x, (Interaction Overview
Diagram) : permet de décrire les enchaînements possibles entre les
scénarios préalablement identifiés sous forme de diagrammes de
séquences (variante du diagramme d’activité).
Diagramme de temps : depuis UML 2.x, (Timing Diagram) : permet de
décrire les variations d’une donnée au cours du temps.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  13 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Sommaire

1 Les modèles de base


Le diagramme de cas d’utilisation
Diagrammes de classes
Diagrammes de séquences

2 Modèles complémentaires

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  14 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les diagrammes de cas d’utilisation

Les diagrammes de cas d’utilisation représentent un ensemble de cas


d’utilisation et d’acteurs et leurs relations

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  15 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les diagrammes de cas d’utilisation

Les diagrammes de cas d’utilisation représentent un ensemble de cas


d’utilisation et d’acteurs et leurs relations

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  15 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les diagrammes de cas d’utilisation

Les diagrammes de cas d’utilisation représentent un ensemble de cas


d’utilisation et d’acteurs et leurs relations

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  15 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les diagrammes de cas d’utilisation

Les diagrammes de cas d’utilisation permettent


d’analyser et définir les besoins d’un système
de délimiter les frontières du système
d’identifier les relations entre le système et son environnement
de faciliter la communication entre les informaticiens et les experts du
domaine
aux utilisateurs d’articuler leurs désirs

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  16 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Eéléments du diagramme de cas d’utilisation

Diagramme composé de six éléments :


Système : fixe les limites du système entre les acteurs (externes) et les
fonctions (internes),
Acteur : rôle joué par quelque chose qui intervient dans le
fonctionnement du système. Il y a 4 catégories d’acteurs :
1 Les acteurs principaux (ex : usager, client, etc),
2 Les acteurs secondaires (ex : opérateur de maintenance, administrateur,
etc),
3 Le matériel externe (ex : capteur, imprimante, etc),
4 Les auteurs systèmes (ex : serveur, etc).

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  17 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Eéléments du diagramme de cas d’utilisation

Cas d’utilisation : identifie une fonction clé ds système. Ce dernier doit


pouvoir l’accomplir
Dépendance : identifie une relation de communication entre deux cas
d’utilisation
Généralisation : définit une relation entre 2 acteurs ou 2 cas
d’utilisations lorsque l’un d’entre eux hérite de l’autre.
Association : identifie une interaction entre les acteurs et les cas
d’utilisation. Elle doit être expliquée dans une description narrative qui
fournit un ensemble de scénarios. Ces derniers jouent le rôle de test
lors de l’évaluation de l’analyse, la conception et l’évaluation des cas
d’utilisation.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  18 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Notations du diagramme de cas d’utilisation

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  19 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Notations du diagramme de cas d’utilisation

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  20 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les acteurs du cas d’utilisation

Ce sont des personnes ou des systèmes


Plus exactement, il s’agit de rôles joués par une entité externe en
relation avec le système.
Les icônes employés varient :

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  21 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les acteurs du cas d’utilisation

Acteurs principaux :
Personnes qui utilisent les fonctions principales du système

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  22 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les acteurs du cas d’utilisation

Acteurs secondaires :
Personnes qui effectuent des tâches administratives ou de maintenance

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  23 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les cas d’utilisation

Le cas d’utilisation
Un ensemble de séquences d’actions qu’un système peut exécuter
Typiquement, une description textuelle
Parfois, on utilise les diagrammes de séquences et de communication
Toujours lié à, et déclenché par, un acteur (c.à.d. un utilisateur)
Exceptions : les cas d’extension et d’inclusion (à voir plus tard)
Fournit toujours un résultat de valeur à un acteur
Un cas d’utilisation est lié à un acteur
un cas d’utilisation doit :
couvrir l’ensemble des étapes à suivre dans l’accomplissement d’une
tâche donnée
être écrit, dans la mesure du possible, d’une façon indépendante de
toute interface utilisateur

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  24 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les cas d’utilisation


les associations

Relie un acteur à un cas d’utilisation,


Indique que l’acteur communique avec le cas d’utilisation,
C’est une association bidirectionnelle,
L’acteur accède au cas d’utilisation
Le cas d’utilisation fournit des fonctionnalités à l’acteur.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  25 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les cas d’utilisation


les stéréotypes et les dépendances

Stéréotypes : notés «stéréotype»


Etendent UML sans le modifier
Quantificaturs des éléments d’un modèle
N’agissent pas sur l’implémentation des éléments
Stéréotypes «include» :
Indique qu’un cas d’utlisation délègue une tâche à un autre : dépendance
forte !

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  26 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les cas d’utilisation


les stéréotypes et les dépendances - « Include » -

Le comportement décrit par la cas d’utilisation source comprend


également le comportement décrit par le cas d’utilisation destination.
Les inclusions permettent essentiellement de factoriser une partie de la
description d’un cas d’utilisation qui serait commune à d’autres cas
Permet de décomposer un cas complexe en sous-cas plus simple.
Cependant, il ne faut surtout pas abuser de ce type de décomposition

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  27 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les cas d’utilisation


les stéréotypes et les dépendances

Stéréotypes «extend» :
Indique qu’un cas pourrait avoir besoin d’un autre
Dépendance faible car conditionnelle
Le sense de la flèche est inversé par rapport au stéréotype «include»,
Indique que le cas source étends les objectifs du cas destination,

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  28 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les cas d’utilisation


les stéréotypes et les dépendances - « Extend » -

CU source étend CU destination, lorsque le cas d’utilisation source peut


être appelé au cours de l’exécution du cas d’utilisation destination.
le cas d’utilisation source ajoute son comportement au cas d’utilisation
destination.
Le comportement ajouté est inséré au niveau d’un point d’extension
défini dans le cas d’utilisation destination.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  29 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les cas d’utilisation


les stéréotypes et les dépendances - « Extend » -

Exemple :

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  29 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les cas d’utilisation


La généralisation

Notion d’héritage appliquée aux cas d’utilisation


Appelée aussi relation "est un"
Ligne pleine terminée par un triangle vide
Le triangle est toujours du côté de l’origine de l’héritage

le cas d’utilisation enfant est une


spécialisation du cas d’utilisation parent
(enfant est un cas particulier de parent)
Le cas d’utilisation parent peut être abstrait
Cette relation de
généralisation/spécification est présente
dans la plupart des diagrammes UML et se
traduit par le concept d’héritage dans les
langages orientés objet.
Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  30 / 122
Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Construction du diagramme des cas d’utilisation

1 Définition du contexte
2 Identification des acteurs,
3 Identification des cas d’utilisation,
4 Définition des associations entre cas et acteurs,
5 Trouver les améliorations possibles,
6 Evaluation des dépendances «include»,
7 Evaluation des dépendances «extend»,
8 Trouver les opportunités de généralisation.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  31 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Description textuelle des cas d’utilisation


- description narrative -

Une description textuelle couramment utilisée se compose de trois parties


1 La première partie permet d’identifier le cas. Elle doit contenir :

Le nom du cas (identificateur représentatif) ;


notes de style :
choisir une forme verbale décrivant une action
l’acteur est généralement le sujet
identification concise mais précise
éviter les connecteurs (et, ou, puis, ...)
terme provenant autant que possible du métier
utiliser par exemple le style MajMin
terme générique comme "Gérer" en cas de besoin
Exemple : Gérer = Créer, Supprimer, Ajouter, Modifier, ...
Exemple : GérerLesDroits

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  32 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Description textuelle des cas d’utilisation


- description narrative -

Une description textuelle couramment utilisée se compose de trois parties


1 La première partie permet d’identifier le cas. Elle doit contenir :

Le nom du cas (identificateur représentatif) ;


Un résumé de son objectif ;
Les acteurs impliqués (principaux et secondaires) ;
Les dates de création et de mise à jour de la description courante ;
Le nom des responsables ;
Un numéro de version.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  32 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Description textuelle des cas d’utilisation


- description narrative -

Une description textuelle couramment utilisée se compose de trois parties


1 La première partie permet d’identifier le cas.
2 La deuxième partie contenant la description du fonctionnement du cas
d’utilisation sous la forme d’une séquence de messages échangés entre
les acteurs et le système.
les préconditions. Elles indiquent dans quel état est le système avant le
déroulement de la séquence (le distributeur est alimenté en billets par
exemple).
L’enchainement des méssages : Scénarios
Scénario nominal
Scénario alternatifs
Scénario d’exception
Les post conditions. Elles indiquent dans quel état se trouve le système
aprés le déroulement de la séquence nominale (une transaction a été
enregistrée par la banque par exemple).

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  33 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Description textuelle des cas d’utilisation


- description narrative -

Une description textuelle couramment utilisée se compose de trois parties


1 La première partie permet d’identifier le cas.
2 La deuxième partie contenant la description du fonctionnement du cas
d’utilisation sous la forme d’une séquence de messages échangés entre
les acteurs et le système.
3 La troisième partie est une rubrique optionnelle.
Elle contient généralement des spécifications non fonctionnelles
(spécifications techniques, ...). Elle peut éventuellement contenir une
description des besoins en termes d’interface graphique.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  34 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Description textuelle des cas d’utilisation


- Exemple -

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  35 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Description textuelle des cas d’utilisation


- Exemple -

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  36 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exercice

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.
Modéliser cette situation par un diagramme de cas d’utilisation

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  37 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  38 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exercice

Dans un magasin, un commerçant dispose d’un système de gestion de son


stock d’articles, dont les fonctionnalités sont les suivantes :
Edition de la fiche d’un fournisseur
Possibilité d’ajouter un nouvel article (dans ce cas, la fiche fournisseur
est automatiquement éditée. Si le fournisseur n’existe pas, on peut alors
le créer)
Edition de l’inventaire. Depuis cet écran, on a le choix d’imprimer
l’inventaire, d’effacer un article ou d’éditer la fiche d’un article).
Modéliser cette situation par un diagramme de cas d’utilisation

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  39 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Les diagrammes de classes

Les diagrammes de cas d’utilisation modélisent à QUOI sert le système.


Le système est composé d’objets qui interagissent entre eux et avec les
acteurs pour réaliser ces cas d’utilisation.
Les diagrammes de classes permettent de spécifier la structure et les
liens entre les objets dont le système est composé.

Le diagramme des classes permet de fournir une représentation abstraite


des objets du système qui vont intéragir ensemble pour réaliser les cas
d’utilisation.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  40 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Classes et objets

Une classe est la description d’un ensemble d’objets ayant une


sémantique, des attributs, des méthodes et des relations en commun.
Elle spécifie l’ensemble des caractéristiques qui composent des objets
de même type. Une classe est composée d’un nom, d’attributs et
d’opérations. Selon l’avancement de la modélisation, ces informations
ne sont pas forcement toutes connues. D’autres compartiments peuvent
être ajoutés : responsabilités, exceptions, etc.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  41 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Propriétés : attributs et opérations

Les attributs et les opérations sont les propriétés d’une classe. Leurs
noms commencent par une minuscule.
Un attribut décrit une donnée de la classe.
Les types des attributs et leurs initialisations ainsi que les modificateurs
d’accès peuvent être précisés dans le modèle,
Les attributs prennent des valeurs lorsque la classe est instanciée : ils sont en
quelque sorte des variables attachées aux objets.
Une opération est un service offert par la classe (un traitement que les
objets correspondant peuvent effectuer).
Un attribut peut être initialisé et sa visibilité est définie lors de sa
déclaration.
Syntaxe de la déclaration d’un attribut :
modifAcces nomAtt : nomClasse [ multi ]= valeurInit

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  42 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Compartiment des opérations

Une opération est définie par nom son ainsi que par les types de ses
paramètres et le type de sa valeur de retour.

La syntaxe de la déclaration d’une opération est la suivante :


modifAcces nomOperation ( parametres ) : ClasseRetour
La syntaxe de la liste des paramètres est la suivante :
nomClasse1 nomParam1 , ... , nomClasseN nomParamN

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  43 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Méthodes et Opérations

Une opération est la spécification d’une méthode (sa signature)


indépendamment de son implantation.
Une opération de classe est une propriété de la classe, et non de ses
instances.
UML 2 autorise également la définition des opérations dans n’importe quel
langage donné.

Une opération décrit les types des paramètres et le type de la valeur de


retour.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  44 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Encapsulation

L’encapsulation est un principe de conception consistant à protéger le


coeur d’un système des accès intempestifs venant de l’extérieur.
En UML, utilisation de modificateurs d’accès sur les attributs ou les
classes :
Public ou + : propriété ou classe visible partout
Protected ou # : propriété ou classe visible dans la classe et par tous ses
descendants.
Private ou − : propriété ou classe visible uniquement dans la classe.
Aucun caractère, ni mot-clé, ou : ( e ) propriété ou classe visible
uniquement dans le paquetage.
Attriut dérivé (/) : Valeur calculé à partir d’autres attributs,
Contraintes ({...}) : Règles nécessaires pour garantir l’intégrité de
l’attribut.
Attribut de classe (souligné),
Un attribut a un nom unique dans une classe,

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  46 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Représentation complète d’une classe

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  47 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Relations entre classes

Une relation d’héritage est une relation de généralisation/spécialisation


permettant l’abstraction
Une dépendance est une relation unidirectionnelle exprimant une
dépendance sémantique entre les éléments du modèle.

Une association représente une relation sémantique entre les objets


d’une classe.
Une relation d’agrégation décrit une relation de contenance ou de
composition.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  48 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Multiplicités

Les relations expriment souvent les liens entre les objets.


La notion de multiplicité permet le contrôle du nombre d’objets
intervenant dans chaque instance de la relation.
Exemple : un objet de la classe Voiture est composé d’au moins trois
roues et d’au plus dix roues.

La syntaxe est MultMin..MultMax.


∗ à la place de MultMax signifie plusieurs sans préciser de nombre.
n..n se note aussi n, et 0..∗ se note ∗.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  49 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Associations

Une association est une relation structurelle entre objets.


Une association est souvent utilisée pour agréger les liens.
Elle est représentée par un trait entre classes.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  50 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Navigabilité d’une association

La navigabilité permet de spécifier dans quel(s) sens il est possible de


traverser l’association à l’exécution. La navigabilité indique s’il est
possible de traverser une association.
On interdit la navigation par une croix (X) du côté qui n’est pas
atteignable.

On peut représenter les associations navigables dans un seul sens par


des attributs. Les attributs sont toujours navigables.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  51 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Association avec contraintes

L’ajout de contraintes à une association ou bien entre associations


apporte plus d’informations car cela permet de mieux préciser la portée
et le sens de l’association.
Les contraintes sont mises entre accolades et peuvent être exprimées
dans n’importe quel langage, mais il vaurt mieux utiliser OCL.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  52 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Association avec contraintes

La contrainte frozen précise que le nombre de roues d’un véhicule ne peut


pas varier.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  52 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Classe-association

Une association peut être raffinée et avoir ses propres attributs, qui ne
sont disponibles dans aucune des classes qu’elle lie.
Une classe association est caractérisée par l’ajout d un trait
discontinu entre la classe et l’association qu’elle représente.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  53 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Association qualifiée

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 : qualificatif.
Un qualificatif d’association est une liste d’attributs dans une association
binaire où les valeurs des attributs sélectionnent un ou plusieurs objets
liés.
Permet de limiter l’impact de l’association qualifiée sur les classes
associées.

Un compte dans une banque appartient à au plus deux personnes.


une personne peut posséder plusieurs comptes dans plusieurs
banques.
une instance du couple Personne, compte est en association avec
une instance unique de la classe Banque.
Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  54 / 122
Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Association qualifiée

Les multiplicités opposées indiquent combien une paire (objet source,


valeurs des qualificatifs) sélectionne d’objets.

La qualification d’une association permet principalement :


1 de transformer une multiplicité indéterminée ou infinie en une multiplicité
finie
2 de limiter l’impact de l’association sur les classes associées.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  55 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Association qualifiée

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  56 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Relation d’agrégation

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.
On représente l’agrégation par l’ajout d’un losange vide du côté de
l’agrégat.

Une agrégation dénote une relation d’un ensemble à ses parties. L’ensemble
est l’agrégat et la partie l’agrégé.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  57 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Relation de composition

La relation de composition décrit une contenance structurelle entre


instances. On utilise un losange plein.

Propriétés de la composition
La destruction et la copie de l’objet composite (l’ensemble) impliquent
respectivement la destruction ou la copie de ses composants (les
parties).
Une instance de la partie n’appartient jamais à plus d’une instance de
l’élément composite.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  58 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Relation de composition

La relation de composition décrit une contenance structurelle entre


instances. On utilise un losange plein.

Propriétés de la composition
La destruction et la copie de l’objet composite (l’ensemble) impliquent
respectivement la destruction ou la copie de ses composants (les
parties).
Une instance de la partie n’appartient jamais à plus d’une instance de
l’élément composite.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  58 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Composition et agrégation

La composition est aussi dite agrégation forte. Pour décider de mettre


une composition plutôt qu’une agrégation, on doit se poser les
questions suivantes :
Est-ce que la destruction de l’objet composite (du tout) implique
nécessairement la destruction des objets composants (les parties) ? C’est
le cas si les composants n’ont pas d’autonomie vis-à-vis des composites.
Lorsque l’on copie le composite, doit-on aussi copier les composants, ou
est-ce qu’on peut les «réutiliser», auquel cas un composant peut faire
partie de plusieurs composites ?

Si on répond par l’affirmative à ces deux questions, on doit utiliser une


composition.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  59 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Relation d’héritage, propriétés

La classe enfant possède toutes les propriétés de


ses classes parentes (attributs et opérations)
La classe enfant est la classe spécialisée (ici Carré)
La classe parent est la classe générale (ici Rectangle)
Toutefois, elle n’a pas accès aux propriétés privées.
Une classe enfant peut redéfinir (même signature) une
ou plusieurs méthodes de la classe parent.
Sauf indications contraires, un objet utilise les
opérations les plus spécialisées dans la hiérarchie des
classes.
La surcharge d’opérations (même nom, mais
signatures des opérations différentes) est possible dans
toutes les classes.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  60 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Relation d’héritage, propriétés

Toutes les associations de la classe parent s’appliquent, par défaut, aux


classes dérivées.
Une instance d’une classe peut être utilisée partout où une instance de
sa classe parent est attendue (principe de la substitution).
Par exemple, toute opération acceptant un objet d’une classe Animal doit
accepter tout objet de la classe Chat (l’inverse n’est pas toujours vrai).

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  61 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Interface

Le rôle d’une interface est de regrouper un ensemble d’opérations


assurant un service cohérent offert par une classe en particulier.
Une interface est définie comme une classe, avec les mêmes
compartiments. Les principales différences sont :
la non-utilisation du mot-clé «abstract», car l’interface et toutes ses
méthodes sont, par définition, abstraites ;
l’ajout du stéréotype «interface» avant le nom de l’interface.
Toutes les classes implémentant une interface doivent implémenter
toutes les oprétaions décrites dans l’interface
Une interface spécifie un contrat que respecte la classe qui l’implémente
On utilise une relation de type réalisation entre une interface et une
classe qui l’implémente.
Les classes implémentant une interface doivent implémenter toutes les
opérations décrites dans l’interface.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  62 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exemples d’interfaces

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  63 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Implémentation d’une interface

public interface Vehicule {


public void seDeplacer ();
}

public class Voiture implements Vehicule


{
public void seDeplacer () {
// CODE DE LA METHODE
}
}

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  65 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Association dérivée

Une association dérivée est conditionnée ou peut être déduite à partir


d’une autre association.
On utilise le symbole «/».
Souvent un ensemble de contraintes, exprimées en OCL, est ajouté à une
association dérivée pour définir les conditions de dérivation.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  66 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Attributs de classe

Par défaut, les valeurs des attributs définis dans une classe diffèrent
d’un objet à un autre.
Parfois, il est nécessaire de définir un attribut de classe qui garde une
valeur unique et partagée par toutes les instances. Graphiquement, un
attribut de classe est souligné

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  67 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Opérations de classe

Une opération de classe est une propriété de la classe, et non de ses


instances.
Elle n’a pas accès aux attributs des objets de la classe.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  68 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Classe active

Une classe passive (par défaut) sauvegarde les données et offre les
services aux autres.
Une classe active initie et contrôle le flux d’activités.
Graphiquement, une classe active est représentée comme une classe
standard, avec une épaisseur de trait plus prononcée.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  69 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Diagrammes de classes à différents niveaux

On peut utiliser les diagrammes de classes pour représenter un


système à différents niveaux d’abstraction :
Le point de vue spécification met l’accent sur les interfaces des classes
plutôt que sur leurs contenus.
Le point de vue conceptuel capture les concepts du domaine et les liens
qui les lient. Il s’intéresse peu à la manière éventuelle d’implémenter ces
concepts et aux relations ainsi qu’aux langages d’implémentation.
Le point de vue implémentation, le plus courant, détaille le contenu et
l’implémentation de chaque classe.
Les diagrammes de classes s’étoffent à mesure qu’on va de hauts
niveaux à de bas niveaux d’abstraction (de la spécification vers
l’implémentation)

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  70 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Construction d’un diagramme de classes

1 Trouver les classes du domaine étudié.


2 Trouver les associations entre classes. Souvent, verbes mettant en
relation plusieurs classes.
3 Trouver les attributs des classes. Souvent, substantifs correspondant
à un niveau de granularité plus fin que les classes. Les adjectifs et les
valeurs correspondent souvent à des valeurs d’attributs.
4 Organiser et simplifier le modèle en utilisant l’héritage
5 Tester les chemins d’accès aux classes
6 Itérer et raffiner le modèle.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  71 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exercice

Une académie souhaite gérer les cours dispensés dans plusieurs collèges. Pour cela,
on dispose des renseignements suivants :
Chaque collège possède un site Internet
Chaque collège est structuré en départements, qui regroupent chacun des enseignants
spécifiques. Parmi ces enseignants, l’un d’eux est responsable du département.
Un enseignant se définit par son nom, prénom, tél, mail, date de prise de fonction et son
indice.
Chaque enseignant ne dispense qu’une seule matière.
Les étudiants suivent quant à eux plusieurs matières et reçoivent une note pour chacune
d’elle.
Pour chaque étudiant, on veut gérer son nom, prénom, tél, mail, ainsi que son année
d’entrée au collège.
Une matière peut être enseignée par plusieurs enseignants mais a toujours lieu dans la
même salle de cours (chacune ayant un nombre de places déterminé).
On désire pouvoir calculer la moyenne par matière ainsi que par département
On veut également calculer la moyenne générale d’un élève et pouvoir afficher les
matières dans lesquelles il n’a pas été noté
Enfin, on doit pouvoir imprimer la fiche signalétique (, prénom, tél, mail) d’un enseignant
ou d’un élève.
Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  72 / 122
Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Elaborez le diagramme de classes correspondant. Pour simplifier l’exercice,


on limitera le diagramme à une seule année d’étude.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  73 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  74 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exercices supplémentaires

L’université comporte des personnels administratifs et techniques, des enseignants,


des étudiants et des chercheurs (qui sont tous des personnes). Certains étudiants
peuvent être des chercheurs (les doctorants) ou des enseignants (les assistants
enseignants). Certaines personnes (étudiants ou non) peuvent être à la fois
chercheurs et enseignants.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  75 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exercices supplémentaires

ACHAT DE VOITURE :
Une personne physique peut avoir jusqu’à trois sociétés (personnes morales) qui
l’emploient. Chaque personne physique possède un numéro de sécurité sociale qui
l’identifie. Une voiture a un numéro d’immatriculation. Une voiture est la propriété
d’une personne (physique ou morale). Un emprunt dans une banque peut être
demandé pour l’achat d’une voiture.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  76 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Diagrammes de séquences

Objectif des diagrammes de séquence

Les diagrammes de cas d’utilisation listent des interactions avec des


acteurs en spécifiant les grandes fonctions d’un système.
Les diagrammes de séquences permettent de décrire comment les
éléments d’un système et les acteurs interagissent.
Les objets au coeur d’un système, interagissent lorsqu’ils s’échangent des
messages.
Les acteurs interagissent avec le système au moyen d’IHM

Un diagramme de séquences montre l’échange d’informations entre différents


classeurs (acteurs, classes, etc.).

On peut utiliser ces diagrammes à différents niveaux d’abstraction.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  77 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exemple d’interaction

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  78 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Ligne de vie

Les participants à une interaction sont appelés « lignes de vie ».


Une ligne de vie représente un participant unique à une interaction.
Une ligne de vie est définie par son rôle (le rôle d’un objet ou d’un acteur
dans l’interaction)

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  79 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Syntaxe des diagrammes de séquences

Un diagramme de séquence se représente par un rectangle contenant,


dans le coin supérieur gauche, un pentagone accompagné du mot-clé «
sd » pour « sequence diagram »
Le mot clé est suivi du nom de l’interaction
Dans le pentagone, on peut aussi faire suivre le nom par la liste des
lignes de vie impliquées, précédée par le mot clé « lifelines : »
Des attributs peuvent être indiqués près du sommet du rectangle
contenant le diagramme.
Dans ce cas, les attributs pourront être utilisés partout dans le diagramme
pour stocker des valeurs intermédiaires,
spécifier des passages de paramètres...

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  80 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exemple de diagramme d’interaction

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  81 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Syntaxe des lignes de vie

Une ligne de vie se représente par un rectangle auquel est accrochée


une ligne verticale pointillée.
La ligne verticale représente le temps qui s’écoule du haut vers le bas
Le haut de la ligne correspond à la création de l’objet.
Le rectangle contient un identifiant dont la syntaxe est :
<nomLigneDeVie >[< selecteur >]: < nomClasseur >
Dans le cas d’une collection, le sélecteur permet de choisir un objet
parmi n.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  83 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Messages

Les principales informations contenues dans un diagramme de


séquence sont les messages échangés entre les lignes de vies,
présentés dans un ordre chronologique.
Un message définit une communication particulière entre des lignes de
vie (objets ou acteurs).
Plusieurs types de messages existent, dont les plus courants :
l’envoi d’un signal ;
l’invocation d’une opération (appel de méthode) ;
la création ou la destruction d’un objet.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  84 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Principaux types de messages

Un message synchrone bloque l’expéditeur jusqu’au retour du


destinataire. Le flôt de contrôle passe de l’émetteur au récepteur.
Typiquement : appel de méthode
Si un objet A invoque une opération d’un objet B, A reste bloqué tant que B
n’a pas terminé.

On peut associer aux messages d’appel de la méthode un message de


retour (en pointillés) marquant la reprise du contrôle par l’objet émetteur
du message synchrone.
Un message asynchrone n’interrompt pas l’exécution de l’expéditeur.
Le message envoyé peut être pris en compte par le récepteur à tout
moment ou ignoré.
Typiquement : envoi de signal (voir stéréotype de classe « signal »)

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  85 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Création et destruction de lignes de vie

La création d’un objet est matérialisée par une flèche qui pointe sur le
sommet d’une ligne de vie.
On peut aussi utiliser un message normal portant le nom «create»

La destruction d’un objet est matérialisée par une croix qui marque la
fin de la ligne de vie de l’objet.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  86 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Messages et événements

On distingue les événements d’envoi et de réception d’un message.

La réception d’un message provoque une activité sur la ligne de vie

La ligne d’activité représente un traitement en réponse à la réception d’un


message
Dans le cas synchrone, càd un appel de méthode, l’activité cesse à la fin
de l’exécution de la méthode, avec l’envoi du message de retour

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  87 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Syntaxe des messages

La syntaxe des messages est :


<nomSignalOuOperation >(< arguments >)
La syntaxe des arguments est la suivante :
<nomParametre >=< valeurArgument >
Si on veut un argument modifiable :
<nomParametre >:< valeurArgument >
Exemples :
appeler("Capitaine Hadock", 54214110)
afficher(x,y)
initialiser(x=100)
f(x :12)
Dans le cas de signaux, les arguments correspondent aux attributs du
signal.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  89 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Messages de retour

Le récepteur d’un message synchrone rend la main à l’émetteur du


message en lui envoyant un message de retour
Un message de retour est souvent porteur du résultat de la méthode
appelée

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  90 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Syntaxe des messages de retour

La syntaxe des messages de retour est :


<attributCible >=
<nomSignalOuOperation >(< arguments >)
:< valeurRetournee >
La syntaxe des arguments est la suivante :
<nomParametre >=< valeurArgument >
Les messages de retour sont représentés en pointillés.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  92 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exemple d’appels de méthodes

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  93 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Implémentation

public class Conducteur{


private Voiture voiture ;
public void addVoiture ( Voiture voiture ){
if( voiture != null ){
this . voiture = voiture ;
}
}
public void conduire (){
voiture . demarrer (); }
public static void main ( String [] argv ){
conducteur . conduire ();
}
}
public class Voiture {
public void demarrer (){...}}

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  95 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Utilisation des diagrammes de séquences

Description des cas d’utilisation (diagrammes de séquence système)


A chaque cas d’utilisation, on associe un diagramme de séquence pour
montrer comment se déroulent les interactions entre les acteurs et le
système pour réaliser le cas.
Modélisation de l’interaction entre les objets suite à une sollicitation
du système
Pour montrer comment les objets à l’intérieur du système intéragissent
entre eux.
Spécification d’un algorithme
Depuis UML 2.0, avec les fragments combinés (boucles, tests, par...), on
dispose de tout le nécessaire pour représenter n’importe quel algorithme.
... spécification d’un processus quelconque.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  96 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exercice

On souhaite gérer les différents objets qui concourent à l’activité d’un


magasin de vente de fleurs.
Le client demande au vendeur des renseignements des renseignements sur les
compositions florales
Le vendeur lui fournit toutes les informations nécessaires
Le client commande alors la composition de son choix et le vendeur émet le bon
de fabrication qu’il transmet à son ouvrier fleuriste.
Le vendeur édite ensuite la facture correspondante.
L’ouvrier fleuriste crée la composition puis archive le bon de fabrication
Il remet alors la composition au vendeur
La facture est remise au client pour règlement une fois le bouquet réalisé
Une fois la facture réglée, le client récupère sa composition et quitte le magasin.
Modéliser cette situation à l’aide d’un diagramme de séquence et d’un
diagramme de collaboration (communication).

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  97 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  98 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  99 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Exercices suppleméntaire

CONVERSATION TELEPHONIQUE :
Décrire par un diagramme de séquences une conversation téléphonique (je décroche,
tonalité, je compose le numéro, sonnerie...).

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  100 / 122


Sommaire Le diagramme de cas d’utilisation
Les modèles de base Diagrammes de classes
Modèles complémentaires Diagrammes de séquences

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  101 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Sommaire

1 Les modèles de base

2 Modèles complémentaires
Diagramme de communication (collaboration)

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  102 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Diagrammes de séquences

Les diagrammes de séquence permettent de modéliser l’échange


d’informations entre différents classeurs
Ils sont un type de diagrammes d’interaction

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  103 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Diagrammes d’interactions

Les diagrammes de communication et les diagrammes de séquences


sont deux types de diagramme d’interaction
Un diagramme de séquence montre des interactions sous un angle
temporel, en mettant l’emphase sur le séquencement temporel de
messages échangés entre des lignes de vie
Un diagramme de communication montre une représentation spatiale
des lignes de vie.
Ils représentent la même chose, mais sous des formes différentes.
A ces diagrammes, UML 2.0 en ajoute un troisième : le diagramme de
timing (de temps).
Son usage est limité à la modélisation des systèmes qui s’exécutent sous
de fortes contraintes de temps, comme les systèmes temps réel.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  104 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Diagrammes de séquences et de communications

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  105 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Diagrammes de séquences et de communications

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  106 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Syntaxe des diagrammes d’interaction

Un diagramme de communication se représente par un rectangle


contenant, dans le coin supérieur gauche, un pentagone accompagné
du mot-clé «com»
Le mot clé est suivi du nom de l’interaction
Dans le pentagone, on peut aussi faire suivre le nom par la liste des
lignes de vie impliquées, précédée par le mot clé «lifelines :»
Des attributs peuvent être indiqués près du sommet du rectangle
contenant le diagramme.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  107 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Diagramme de communication

Le diagramme de communication donne une représentation spatiale


des interactions, plutôt que temporelle.
Relations entre les lignes de vie qui communiquent.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  108 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Rôles et connecteurs

Le rôle permet de définir le contexte d’utilisation de l’interaction.


Si la ligne de vie est un objet, celui-ci peut avoir plusieurs rôles au cours
de sa vie.
Les relations entre les lignes de vies sont appelées « connecteurs ».
Un connecteur se représente de la même façon qu’une association mais la
sémantique est plus large : un connecteur est souvent une association
transitoire.
Comme pour les diagrammes de séquence, la syntaxe d’une ligne de
vie est :
<nomRole >[< selecteur >]: < nomClasseur >

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  110 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Types de messages

Comme dans les diagrammes de séquence, on distingue deux types de


messages :
Un message synchrone bloque l’expéditeur jusqu’au retour du
destinataire. Le flot de contrôle passe de l’émetteur au récepteur.

Un message asynchrone n’interrompt pas l’exécution de l’expéditeur. Le


message envoyé peut être pris en compte par le récepteur à tout moment
ou ignoré.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  111 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Représentation des messages

Les flèches représentant les messages sont tracées à côté des


connecteurs qui les supportent.

Attention
Bien faire la distinction entre les messages et les connecteurs : on pourrait
avoir un connecteur sans message, mais jamais l’inverse.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  112 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Implémentation de messages synchrones

public class Conducteur {


private Voiture voiture ;
public void addVoiture ( Voiture voiture ){
if( voiture != null ){
this . voiture = voiture ;
}
}
public void conduire (){
voiture . demarrer ();
}
public static void main ( String [] argv ){
conducteur . conduire ();
}
}
public class Voiture {
public void demarrer (){...}
}
Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  114 / 122
Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Multiplicité

Les connecteurs permettent de rendre compte de la multiplicité

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  115 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Numéros de séquence des messages

Pour représenter les aspects temporels, on adjoint des numéros de


séquence aux messages.
Des messages successifs sont ordonnés selon un numéro de séquence
croissant (1, 2, 3, ... ou encore 3.1, 3.2, 3.3, ...).
Des messages envoyés en cascade (ex : appel de méthode à l’intérieur
d’une méthode) portent un numéro d’emboîtement avec une notation
pointée :
1.1, 1.2, ... pour des messages appelés par une méthode dont l’appel portait
le numéro 1
2.a.1, 2.a.2, ... pour des messages appelés par une méthode dont l’appel
portait le numéro 2.a

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  116 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Equivalence avec un diagramme de séquence

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  117 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Equivalence avec un diagramme de séquence

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  118 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Messages simultanés

Lorsque des messages sont envoyés en parallèle, on les numérote avec


des lettres
1.a, 1.b,... pour des messages simultanés envoyés en réponse à un
message dont l’envoi portait le numéro 1

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  119 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Syntaxe des messages

Syntaxe complète des messages est :


[<numeroSéquence>][<expression>] :<message>
la syntaxe «message» a la même forme que dans les diagrammes de
séquence, «numéroSéquence» représente le numéro de séquencement
des messages et «expression» précise une itération ou un
embranchement.
Exemple :
2 : affiche(x,y) : message simple.
1.3.1 : trouve("Hadock") : appel emboîté.
4 [x < 0] : inverse(x,couleur) : conditionnel.
3.1 *[i :=1..10] : recommencer() : itération.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  120 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Exercices supplémentaires

ASCENSEUR :
Décrire par un diagramme de communications pour le fonctionnement d’un ascenseur
(une personne appuie sur un bouton, l’ascenseur arrive, les portes s’ouvrent, la
personne entre...).

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  121 / 122


Sommaire
Les modèles de base Diagramme de communication (collaboration)
Modèles complémentaires

Exercices supplémentaires

BUREAU DE POSTE :
A la poste, les personnes arrivent dans une file d’attente. Avec deux guichets, décrire
par un diagramme de collaborations l’arrivée, l’attente et la prise en charge des
personnes.

Saïd Mahmoudi Said.mahmoudi@umons.ac.be Génie Logiciel  −  122 / 122