12/05/2021

PROGRAMMATION Pr. ABIOUI

E-mail : h.abioui@uiz.ac.ma
ORIENTÉE OBJET Année Universitaire : 2020/2021

PLAN DU COURS
1. Conception Orientée Objet
­ Introduction à l’approche orientée objet
­ Notion de l’objet et la classe
­ Les Concepts de base de l’orienté objet
­ Encapsulation
­ Abstraction
­ Héritage
­ Polymorphisme

2. Modélisation à l’aide du langage UML

­ Introduction à UML
­ Historique
­ Les diagrammes

3. Java et la programmation objet

1
 12/05/2021

CONCEPTION ?
I N T R O D U C T I O N À L’A P P R O C H E O R I E N T É E O B J E T

• Processus créaBf qui consiste à représenter les diverses

fonc/ons du système permeEant d'obtenir rapidement un ou
plusieurs programmes réalisant les foncBons recherchées
• Une "bonne" concepBon se définit en termes de la sa/sfac/on
des besoins et des spécifica/ons

• Elle se base sur la Modularité

Défini&on

L’A P P R O C H E O R I E N T É E O B J E T
I N T R O D U C T I O N À L’A P P R O C H E O R I E N T É E O B J E T

• Dans l'approche objet les données et les traitements concernant ces données sont
regroupés dans des enBtés appelées objets

2
 12/05/2021

L’APPROCHE ORIENTÉE OBJET

INTRODUCTION À L’APPROCHE ORIENTÉE OBJET

• La POO est uBlisée aujourd'hui dans tous les domaines de l'informaBque : parallélisme,
communicaBon, bases de données,...
• La POO vise le développement des modules réu/lisables. Elle vise la construcBon de
logiciel à parBr d'une bibliothèque de composants élémentaires

• La POO est un mode de concep/on de programmes caractérisé par :

• Une organisa/on en en/té relaBvement autonome : les objets

• Un mécanisme de spécifica/on et de généra/on d'objets au moyen de modèle
générique décrivant leur structure et leur comportement : les classes

L’A P P R O C H E O R I E N T É E O B J E T
I N T R O D U C T I O N À L’A P P R O C H E O R I E N T É E O B J E T

• Dans une approche Orientée Objet (OO), le logiciel est considéré comme une

collecBon d'objets dissociés définis par des propriétés

•Une propriété est soit un aEribut de l'objet ou un comportement de l'objet

• Un objet comprend donc à la fois une structure de données et une collecBon

d'opéraBons (son comportement)

3
 12/05/2021

P O U R Q U O I L’A P P R O C H E O R I E N T É E O B J E T ?
I N T R O D U C T I O N À L’A P P R O C H E O R I E N T É E O B J E T

• Unicité et universalité du paradigme

• Réduire le décalage entre le monde réel et le logiciel;
• Objets réels Þ Objets conceptuels Þ Objets logiciels

• Réu/lisabilité et évolu/vité facilitées par différents concepts

• Encapsula/on, Modularité, Abstrac/on, Héritage, Polymorphisme
• Paradigme qui arrive à maturité
• Bibliothèques de classes, UML, Méthodologie de développement (Agile, etc.)
• Environnements de développement intégrés (IDE)

L’ O B J E T
N O T I O N D E L’ O B J E T E T D E L A C L A S S E

• Un objet représente une entité physique, conceptuelle ou

logique du monde réel
• Entité physique

• Entité conceptuelle

Défini&on
• Entité logicielle

• Un objet a une frontière bien définie, une identité : état et

comportement

4
 12/05/2021

L’ O B J E T
N O T I O N D E L’ O B J E T E T D E L A C L A S S E

• En/té cohérente rassemblant des données et du code travaillant sur ces données
• Structure de données qui répond à un ensemble de messages
• Caractérisé par :

• Son comportement Þ que peut-on faire avec cet objet ?

• Son état Þ comment réagit l'objet quand on applique ces méthodes ?
• Son iden/té Þ comment disBnguer les objets qui ont le même état et le
même comportement ?
• L'objet informaBque est une projecBon de l'objet du monde réel

E TAT E T C O M P O R T E M E N T D ’ U N O B J E T
N O T I O N D E L’ O B J E T E T D E L A C L A S S E

État Comportement

Nom et prénom Préparer un nouveau cours

CIN Préparer des devoirs
Embauche Corriger les examens
Grade Faire de la recherche
Spécialité …
…

Objet : A Objet : B Objet : C

10

5
 12/05/2021

QU'EST CE QU’UNE CLASSE ?

N O T I O N D E L’ O B J E T E T D E L A C L A S S E

• La classe est un mécanisme permeEant de créer des objets

ayant des propriétés communes (aEributs + méthodes)

• Un objet est donc, une instance de la classe:

classe = instancia/on
Définition + aEributs (variables d'instances)
+ méthodes membres

11

QU'EST CE QU’UNE CLASSE ?

N O T I O N D E L’ O B J E T E T D E L A C L A S S E

• L'instancia)on : représente la rela+on entre un objet et sa classe d'appartenance qui a

permis de le créer

• Les a,ributs :(appelés aussi variables d'instances): Ils ont un nom et un type : soit un
type de base (simple ou construit), soit une classe (l'a<ribut référence un objet de la
même ou une autre classe)

• Les méthodes membres : Elles sont les opéra+ons applicables a un objet de la classe.
Elles peuvent modifier tout ou en par+e l’état d’un objet et retourner des valeurs
calculées a par+r de cet état

12

6
 12/05/2021

E N C A P S U L AT I O N
C O N C E P T S D E B A S E D E L’ O R I E N T É O B J E T

• Le mécanisme d’encapsulation consistant à rassembler, au sein d'une même structure, les

données et les traitements Þ les attributs et les méthodes au niveau de la classe

• C'est un principe qui permet de masquer la complexité des objets à l'utilisateur

• Un utilisateur peut utiliser un objet sans savoir comment il fonctionne (ex: un enfant sait
se servir d'un téléviseur, malgré la complexité de cet appareil)

13

E N C A P S U L AT I O N
C O N C E P T S D E B A S E D E L’ O R I E N T É O B J E T

• Un objet possède une interface et une implémentation,

• L'interface est visible et manipulable par l'utilisateur de l'objet
• Et l'implémentation (la façon dont l'objet est construit), qui n'est pas visible par
l'utilisateur (cachée)
• Possibilité de modifier l'implémentation sans modifier l'interface (vue externe de l'objet)
• Þ Facilité de l'évolution de l'objet

• Préservation de l'intégrité des données

• L'accès direct aux attributs est interdit
• L'interaction entre les objets se fait uniquement grâce aux méthodes

14

7
 12/05/2021

ABSTRACTION
CONCEPTS DE BASE DE L’ORIENTÉ OBJET

• C'est un des concepts clés dans les langages de programmaBon

orientée objet (POO)
• Son objecBf principal est de gérer la complexité en masquant les
détails inu3les à l'u3lisateur
• C'est un processus qui consiste à iden3fier les caractéris3ques
intéressantes d'une enBté, en vue d'une uBlisaBon précise
Défini&on

15

MODULARITÉ
C O N C E P T S D E B A S E D E L’ O R I E N T É O B J E T

• Casser un système en sous modules

Administra3on

Scolarité

Système de gestion de
Service de stage
l'université

16

8
 12/05/2021

HÉRITAGE
CONCEPTS DE BASE DE L’ORIENTÉ OBJET

• L’héritage est un principe propre à la programmaBon orientée objet

• Un mécanisme de transmission des propriétés d'une classe vers une sous-classe,
perme=ant de créer une nouvelle classe à par3r d’une classe existante
• Le nom "héritage" (dérivaBon de classe) provient du fait que la classe dérivée (nouvellement
créée) conBent les aEributs et les méthodes de sa superclasse (la classe dont elle dérivé)
• Une classes bénéficie ou hérite des caractéris3ques de la classe la plus générale, à laquelle
elle rajoute ses propres éléments

17

H É R I TA G E
C O N C E P T S D E B A S E D E L’ O R I E N T É O B J E T

• L’héritage permet en gros :

• CréaBon de nouvelles classes basées sur des classes existantes
• Transmission des propriétés (aEributs et méthodes) de la classe mère vers la classe fille

• Deux orientaBons possibles

• Spécialisa3on : Ajout / AdaptaBon des caractérisBques
• Généralisa3on : Regroupement des caractérisBques communes

18

9
 12/05/2021

Q U ’ H É R I T E -T- O N ?
C O N C E P T S D E B A S E D E L’ O R I E N T É O B J E T

• Une sous-classe hérite les aEributs et les

opéraBons de ses parents

• Une sous-classe peut :

• Ajouter des aEributs, des opéraBons
• Redéfinir des opéra3ons héritées

19

INTÉRÊT DE L’HÉRITAGE
CONCEPTS DE BASE DE L’ORIENTÉ OBJET

• L'intérêt majeur de l’héritage est de pouvoir définir de nouveaux aEributs et de nouvelles

méthodes pour la classe dérivée, qui viennent s'ajouter à ceux et celles héritées
• Par ce moyen on crée une hiérarchie de classes de plus en plus spécialisées

• Ceci permet :
• Éviter la duplicaBon du code
• Encourager la réuBlisaBon du code

20

10
 12/05/2021

H É R I TA G E
C O N C E P T S D E B A S E D E L’ O R I E N T É O B J E T

• Héritage simple : une classe ne peut hériter qu'une seule superclasse

• Héritage mul3ple : certains langages orientes objet, tels que le C++, permeEent de faire de
l’héritage mulBple, ce qui signifie qu’ils offrent la possibilité de faire hériter une classe de
deux ou plusieurs superclasses. Ainsi, ceEe technique permet de regrouper au sein d'une
seule et même classe les aEributs et les méthodes de plusieurs classes

21

HÉRITAGE SIMPLE
CONCEPTS DE BASE DE L’ORIENTÉ OBJET

Plus
abstrait

Moins
abstrait

• Les éléments au même niveau hiérarchique devaient être au même niveau d'abstracBon

22

11
 12/05/2021

H É R I TA G E M U LT I P L E
C O N C E P T S D E B A S E D E L’ O R I E N T É O B J E T

• Une classe peut hériter de plusieurs classes

• Il faut u+liser l'héritage mul)ple avec prudence et

seulement si indispensable

• L'héritage mul+ple n'est pas supporté par la plupart

des langages de POO (ex: Java, C#, etc.)

• L’héritage mul+ple est supporté par quelques

langages de programma+on tels que : C++, Eiffel ou
Python

23

P O LY M O R P H I S M E
C O N C E P T S D E B A S E D E L’ O R I E N T É O B J E T

• Poly "Plusieurs" / Morphisme "Formes"

• En POO, une classe dérivée peut redéfinir une méthode héritée de sa classe de base, tout en
gardant le même nom. Ce<e possibilité est la clé de ce que l'on nomme polymorphisme
• C’est donc la capacité d'une classe à redéfinir une méthode héritée à par+r d'une classe mère
• La possibilité de traiter de la même manière des objets de types différents
• Le polymorphisme représente la faculté d'une opéra+on de s'appliquer à des objets de classes
différentes
• Avantages

• Lisibilité du code

• Généricité du code

24

12
 12/05/2021

P O LY M O R P H I S M E
C O N C E P T S D E B A S E D E L’ O R I E N T É O B J E T

25

LES PRINCIPES POUR CRÉER UN MODÈLE

INTRODUCTION À UML

• Un modèle doit être relié au monde réel

• Un modèle influence énormément la façon d'aborder le problème et la solution
• Chaque modèle peut être exprimé à différents niveaux de précision, d’abstraction et de
raffinement
• Þ Les meilleurs modèles permettent de choisir le niveau de détail en fonction de qui
regarde et pourquoi il le regarde
• Les meilleurs modèles sont les plus proches et liés à la réalité
• Une seule vue (modèle) n'est jamais suffisante
• Þ Tous les systèmes gagnent à être décrits avec plusieurs petits modèles relativement
indépendant

26

13
 12/05/2021

U N S E U L M O D È L E N E S U F F I T PA S
INTRODUCTION À UML

• Créer un ou plusieurs modèles différents mais avec un point commun

27

UNIFIED MODELING LANGUAGE (UML)

I N T R O D U C T I O N À UML

• Langage de modélisaBon visuelle et graphique commun conçu pour

les domaines du développement logiciel OO
• DesBné à l'architecture, la concepBon et la mise en œuvre de
systèmes logiciels complexes par leur structure aussi bien que leur
comportement
Défini&on

28

14
 12/05/2021

UNIFIED MODELING LANGUAGE (UML)

I N T R O D U C T I O N À UML

• Langage visuel unifié Þ tout le monde doit parler le même langage

• Langage pour spécifier Þ supposé précis et non ambigu

• Des liens vers plusieurs langages de programmaBon

• Java, C++, VB
Défini&on • GénéraBon de code et reverse engineering

29

HISTORIQUE
I N T R O D U C T I O N À UML

• Années 80 :
§ Méthodes MERISE
§ SéparaBon des données et des traitements
• Début des années 90 :
§ AppariBon de la programmaBon objet Þ nécessite une méthodologie adaptée
§ AppariBon de plus de 50 méthodes entre 1990 et 1995
• 1994 : Consensus sur 3 méthodes
§ OMT de James Rumbaugh : représenta3on graphique des aspects sta3ques,
dynamiques et fonc3onnels d'un système
§ OOD de Grady Booch : concept de package
§ OOSE de Ivar Jacobson : descripBon des besoins de l'u3lisateur

30

15
 12/05/2021

HISTORIQUE
I N T R O D U C T I O N À UML

• Consensus entre OMT, OOD et OOSE pour créer une méthode commune
§ Þ UML : Unified Modeling Language (Langage de Modélisation Unifié)
• 1997 : Définition de la norme UML comme standard de modélisation des systèmes
d'information objet par l'OMG (Object Management Group)

• UML est employé dans l'ensemble des secteurs du développement informatique

§ Système d'information
§ Télécommunication, défense
§ Transport, aéronautique, aérospatial
§ Domaines scientifiques
§ Etc.

31

LES BASES D’UML

INTRODUCTION À UML

• Les éléments Þ Ce sont les abstracBons essenBelles au modèle

• Les relaBons Þ Elles expriment les liens existants entre les différents éléments

• Les diagrammes
§ Un diagramme est une représenta3on visuelle de l'ensemble des éléments qui consBtuent
le système
§ Ils servent à visualiser un système sous différents angles (uBlisateur, administrateur, etc.)
§ Dans les systèmes complexes, un diagramme ne fournit qu'une vue parBelle du système
• Þ L'ensemble des diagrammes réunis permet d'obtenir une vue globale du système à
concevoir

32

16
 12/05/2021

LES DIFFÉRENTES VUES D’UML

INTRODUCTION À UML
• Vue des cas d'utilisation • Vue des processus
Ø Description du modèle vu par les acteurs du
Ø Vue temporelle et technique
système
Ø Mise en œuvre des notions de tâches
Ø Besoins attendus pour chaque acteur
concurrentes, synchronisation, etc.
Ø Le QUOI et le QUI
• Vue de déploiement

• Vue logique Ø Position géographique et architecture

Ø Définition du système vu de l'intérieur physique de chaque élément
Ø COMMENT satisfaire les besoins des acteurs Ø Le OÙ

• Vue d’implémentation
Ø Dépendances entre les modules

33

LES DIAGRAMMES D’UML

INTRODUCTION À UML

34

17
 12/05/2021

Diagramme
des Cas d’U.lisa.on
Diagramme UML

35

MODÈLE ORIENTÉ ‘USE CASE’

LES DIAGRAMMES UML

• Le diagramme des cas d’utilisation constitue la base et la première

étape de l’analyse UML, il permet de :
• Modéliser les besoins des utilisateurs en découpant le système en
fonctionnalités
• Identifier les grandes fonctionnalités et les limites du système

Défini&on
• Représenter les interactions entre le système et ses utilisateurs
• Apporter une vision utilisateur mais pas informatique

36

18
 12/05/2021

MODÈLE ORIENTÉ ‘USE CASE’

LES DIAGRAMMES UML

•Les uses cases :

• Ils doivent être précis et concis
• Ils sont compréhensibles par la majorité
• Ils permettent de synchroniser les différents modèles
• Ils décrivent l'ensemble des fonctions du système et les acteurs

Défini&on
concernés Vérifier le
solde

Client Retirer de
l'argent

37

MODÈLE ORIENTÉ ‘USE CASE’

LES DIAGRAMMES UML

Le diagramme de cas d’uBlisaBon comporte deux composantes

principales :

• La composante graphique : permet d’avoir une vue d’ensemble des

foncBonnalités du système et de situer la fronBère entre le système
et les acteurs extérieurs
Défini&on
• La composante textuelle : décrit sous forme de scénarios, pour
chaque foncBonnalité, comment se déroule chronologiquement une
séance d’interacBon entre un acteur et une foncBonnalité du système

38

19
 12/05/2021

USE CASE : LE COMPORTEMENT DU SYSTÈME

LES DIAGRAMMES UML

• C'est l'ensemble des ac3ons et réac3ons du système

• L'ensemble des fonc3onnalités et des responsabilités du système et de son

environnement sont capturés par le diagramme Use Case
• L'environnement est l'ensemble des acteurs (personnes, logicielles et machines) qui
interagissent avec le système
• Doit être approuvé par les acteurs y compris le client

39

EXIGENCES FONCTIONNELLES ET NON FONCTIONNELLES

LES DIAGRAMMES UML

• Exigences Fonctionnelles
• Définir une fonction du système à développer
• Décrit ce que le système doit faire
• Exemples :
• Inscrire un étudiant, calculer la moyenne, imprimer bulletin, imprimer attestation
• Exigences Non-Fonctionnelles
• Performance, Robustesse, Convivialité, Maintenabilité
• Exemples :
• Le temps de réponse à une inscription ne doit pas dépasser 30 secondes
• Le coût du projet ne doit pas être supérieur à 150K

40

20
 12/05/2021

QU’EST CE QUE L’USE-CASE ?

LES DIAGRAMMES UML

• Un Use Case décrit les exigences fonctionnelles du système

• Décrit la façon dont le système fonctionne
Use Case

Ajouter des
étudiants
Acteur

Programmer des Moodle

quiz

Saisir les notes

Professeur
Apogée
Autre

41

INTÉRÊT DES USE CASE

LES DIAGRAMMES UML
• Communica3on entre les uBlisateurs et les experts du domaine
• IdenBficaBon des acteurs et des cas d'u3lisa3on
Use Case
• Vérifica3on
Ajouter des
étudiants
Acteur

Programmer des Moodle

quiz

Saisir les notes

Professeur
Apogée
Autre

42

21
 12/05/2021

COMPOSANTES D’UN DIAGRAMMES USE CASE

LES DIAGRAMMES UML

• Acteurs : ils sont des personnes, des organisations ou autres systèmes jouant un rôle dans une
ou plusieurs activités du système. Ils sont modélisés par une icône humanoïde ou une icône
adaptée à la nature de l'acteur
• Les cas d'utilisation : séquence d'actions représentant une valeur mesurable pour un acteur du
système. Les Use Case sont représentés en utilisant des ellipses
• Associations : elles représentent les interactions entre les acteurs et les Use Case. Les
associations sont modélisés par des lignes continues
• Frontières du Système (optionnelles) : ce sont des rectangles permettant de représenter les
limitations du système
• Packages (optionnelles) : en UML, les packages sont utilisés pour grouper les Use Case en groupe
en fonction d'un découpage donné du système

43

REPRÉSENTATION D’UN ACTEUR

LES DIAGRAMMES UML

• Chaque acteur doit être nommé par un nom qui reflète son rôle
• ReprésentaBon graphique standard de l’acteur en UML est l’icône appelée s3ck
man, avec le nom de l’acteur sous le dessin
• On peut également figurer un acteur sous d’un classeur stéréotypé, avec le mot-clé
<<Actor>>

• On peut aussi adapter l'icône à la nature de l'acteur

Professeur Université Apogée

44

22
 12/05/2021

COMMENT IDENTIFIER LES ACTEURS ?

LES DIAGRAMMES UML

• Trouver les différents rôles des uBlisateurs

• Þ Etudiant, Enseignant, Administrateur, etc.

• IdenBfier les autres systèmes (Logiciels, Imprimantes, Serveurs, etc.)

• Vérifier que les acteurs interagissent avec le système

• Les étudiants d'une école ne sont pas les acteurs pour le système de
recrutement
• RH est l'acteur

45

LES USE CASE : DÉFINITION

LES DIAGRAMMES UML

• Un Use Case représente un ensemble de séquences d’ac3ons qui sont réalisées

par le système et qui produisent un résultat observable intéressant pour un
acteur parBculier
• Un Use Case représente un dialogue entre un ou plusieurs acteurs et le système
• Un Use Case décrit les ac3ons prises par le système pour délivrer un résultat à un
acteur
• Un Use Case décrit ce qu’un futur système devra faire, sans spécifier comment il
le fera La flèche est optionnelle

Use Case
Association

Acteur

46

23
 12/05/2021

COMMENT IDENTIFIER LES USE CASE ?

LES DIAGRAMMES UML

• DescripBon exhaus3ve des exigences fonc3onnelles

• Se placer du point de vue de chaque auteur
• Comment et pourquoi il se sert du système ?
• Bon niveau d'abstracBon

• Règle de nommage
• Verbe à l'infinitif + complément
• Saisir les notes
• Inscrire les étudiants
• Du point de vue de l'acteur (pas du système)

47

REPRÉSENTATION D’UN USE CASE

LES DIAGRAMMES UML

• Le diagramme de cas d’uBlisaBon est un schéma qui montre les cas d’uBlisaBon (ovales)
reliés par des associaBons (lignes) à leurs acteurs
• Chaque associaBon signifie simplement «parBcipe à»
• Un cas d’uBlisaBon doit être relié à au moins un acteur
• Un cas d’uBlisaBon se représente par une ellipse contenant l’in9tulé du cas d’uBlisaBon
• Dans le cas où l’on désire présenter les aEributs ou les opéraBons du cas d’uBlisaBon, il est
préférable de le représenter sous la forme d’un classeur stéréotypé << use case >>

48

24
 12/05/2021

SYSTÈME : DÉFINITION ET REPRÉSENTATION

LES DIAGRAMMES UML

• Un système représente une applicaBon dans le modèle

UML. Il est idenBfié par un nom et regroupe un
ensemble de cas d’uBlisaBon qui correspondent aux
foncBonnalités offertes par l’applicaBon à son
environnement
• L’environnement est spécifié sous forme d’acteurs liés
aux cas d’uBlisaBon
• Un système se représente par un rectangle contenant le
nom du système et les cas d’uBlisaBon de l’applicaBon

49

REPRÉSENTATION D’UN DIAGRAMME USE CASE

LES DIAGRAMMES UML

50

25
 12/05/2021

TYPES DES RELATIONS ENTRE LES USE CASE

LES DIAGRAMMES UML

• Les relations entre les cas d’utilisation ont pour but de décomposer le système en
fonctionnalités à granularité plus fine

• Il existe principalement trois types de relations :

• Les dépendances stéréotypées, qui sont explicitées par un stéréotype. Les plus
utilisés sont :

§ L’inclusion
§ L’extension
• La relation de généralisation/spécialisation, dite aussi la relation d’héritage

51

L’INCLUSION DES USE CASE : <<INCLUDE>>

LES DIAGRAMMES UML

• Un Use Case inclus est une sous-fonc3on obligatoire du Use Case dans lequel il est inclus
• Permet de décomposer la complexité des Use Case
• L'inclusion se traduit par un trait disconBnu partant de la sous-foncBon et orienté vers le
Use case l'incluant. La flèche est labélisée par le mot-clé << include >>
• Dans cet exemple, On ne peut pas passer de commandes sans payer

52

26
 12/05/2021

L’INCLUSION DES USE CASE : <<INCLUDE>>

LES DIAGRAMMES UML

• Les inclusions Permettent de décomposer la complexité des Use Case, en sous cas
plus simples
• Exemple : Une opération de retrait et une opération de transfert nécessitent toutes deux
une opération de vérification de l'identité du client.
• Effectuer un retrait inclut nécessairement une phase d’authentification avec un code

53

L’INCLUSION DES USE CASE : <<INCLUDE>>

LES DIAGRAMMES UML

• Un Use Case peut inclure un ou plusieurs Use Case

54

27
 12/05/2021

L’INCLUSION DES USE CASE : <<INCLUDE>>

LES DIAGRAMMES UML

• Plusieurs Use Case peuvent inclure un même Use Case

55

L’EXTENSION DES USE CASE : <<EXTEND>>

LES DIAGRAMMES UML

• Les Use Case peuvent définir des points d'extension optionnels

• Un Use Case peut être exécuté sans que ses points d'extensions ne soient réalisés
• Un Use Case peut avoir plusieurs extensions
• Plusieurs Use Case peuvent étendre un point d'extension donné
• Les extensions sont traduits par une ligne discontinu partant du Use Case à étendre vers le Use
Case sur lequel il est étendu. La ligne discontinu est labélisée par le mot-clé <<extend>>

rupture de stock

Extension Points
condition

56

28
 12/05/2021

L’EXTENSION DES USE CASE : <<EXTEND>>

LES DIAGRAMMES UML

• Exemple : Un client peut uBliser un bon de réducBon au moment de la passaBon d’une

commande sur un site e-commerce

57

GÉNÉRALISATION DES USE CASE

LES DIAGRAMMES UML

• Il est possible de généraliser les acteurs ainsi que les use case
• La généralisaBon se traduit par une flèche orientée partant de l'en3té la plus
spécifique vers l'en3té la plus générique

Spécifique Générique

58

29
 12/05/2021

PACKAGE DANS LES USE CASE

LES DIAGRAMMES UML

• Si les Use Case sont nombreux

• Les regrouper par acteur
§ Opérations client Gérer les clients

§ Opérations administrateur
§ Etc.
• Les regrouper par domaine fonc3onnel
§ Gérer les contrats
§ Gérer les clients
§ Etc.

59

DESCRIPTION TEXTUELLE DES USE CASE

LES DIAGRAMMES UML

Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du point de vue des
acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les cas d’utilisation.
Une description textuelle couramment utilisée se compose de trois parties :

Partie 1 : identification du cas d’utilisation

• le nom du cas
• 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
• le nom du ou des responsables
• un numéro de version

60

30
 12/05/2021

DESCRIPTION TEXTUELLE DES USE CASE

LES DIAGRAMMES UML

Par3e 2 : Descrip3on des scénarios

Elle conBent la descripBon du foncBonnement du cas d’uBlisaBon sous la forme d’une séquence de
messages échangés entre les acteurs et le système.
• Les pré-condiBons : Elles indiquent dans quel état doit être le système avant que le cas d’uBlisaBon
puisse être déclenché.
• Les scénarios : décrivent l’enchaînement des informaBons échangées entre les acteurs et le
système. On disBngue le scénario nominal, les scénarios alternaBfs et enfin les scénarios
d’excepBon
• Les post-condiBons : Elles indiquent dans quel état se trouve le système après le déroulement de
la séquence nominale

61

DESCRIPTION TEXTUELLE DES USE CASE

LES DIAGRAMMES UML

Partie 3 : Exigences non fonctionnelles

C’est une rubrique optionnelle. Elle peut être omise.
Si elle est présente, elle contient généralement des spécifications non fonctionnelles
Cette rubrique contient aussi d’éventuelles contraintes liées aux interfaces homme-machine
Ce volet peut aussi contenir des compléments qui peuvent porter sur des sujets variés, tels que :
• l’ergonomie
• la performance attendue
• des contraintes (techniques ou non) à respecter
• des problèmes non résolus (ou questions à poser au client et aux futurs utilisateurs).

62

31
 12/05/2021

RECAPITULATIF : USE CASE

LES DIAGRAMMES UML

Etapes à suivre pour élaborer un diagramme de cas d’utilisation

• Iden:fica:on des acteurs

• Iden:fica:on des Use Case (par acteur)

• Réalisa:on des diagrammes Use Case

• Descrip:on textuelle des Use Case

• Organisa:on des Use Case (Rela:on entre Use Case et entre

Packages)

63

Diagramme
De classes
Diagramme UML

64

32
 12/05/2021

DIAGRAMME DE CLASSES
LES DIAGRAMMES UML

• Permet de donner une vue staBque du système

• Décrit les responsabilités du système
• La base des diagrammes de composantes et de déploiement
• Permet de représenter les classes et leurs relaBons
• Décrit les aEributs et opéraBons des classes

Objec&fs

65

CLASSE
LES DIAGRAMMES UML

• Décrit le domaine de définition d’un ensemble d’objet

• Description abstraite de cet ensemble
• Vue comme la factorisation des éléments communs à un ensemble
d’objets
• Modélisée à l’aide d’un rectangle, comportant 3 zones :
Ø La désignation de la classe
Défini&on
Ø La description des attributs
Ø La description des opérations
• La première zone est obligatoire (le nom), les autres sont optionnelles

66

33
 12/05/2021

NOM D’UNE CLASSE

LES DIAGRAMMES UML

• Le nom de la classe peut être qualifié par un « stéréotype » ou d’autres précisions (auteur
de la classe par exemple)
• Un nom de classe est toujours au singulier : pas de s à la fin, même si conceptuellement
une classe est un ensemble d’instances.

67

ATTRIBUTS
LES DIAGRAMMES UML

• La descripBon complète des aEributs d’une classe comporte les caractérisBques suivantes :
• Nom d’a4ribut : nom unique dans sa classe
• Mul6plicité : la mulBplicité indique le nombre minimum et le nombre maximum
de valeurs possibles de l’aEribut pour une instance de la classe. Par défaut, la
mulBplicité est [1,1]. Exemple : prénom [1,5] si une personne peut avoir au
maximum cinq prénoms (faculta've)
• Type : type de l’aEribut (enBer, réel, etc.)
• Valeur ini6ale : la valeur par défaut à la créaBon de l’aEribut (faculta've)

68

34
 12/05/2021

ATTRIBUTS (SUITE)
LES DIAGRAMMES UML

• 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é ». Par exemple : /surface, /somme,
/moyenne, etc.
• Un attribut est appelé identifiant (marqué avec {id}) de la classe s’il joue un rôle particulier
en permettant de repérer de façon unique chaque instance de la classe.

• Exemple :

69

OPÉRATIONS
LES DIAGRAMMES UML

• La description complète d’une opération d’une classe peut comporter un certain nombre de
caractéristiques :
• Nom d’opération
• Paramètres : chaque paramètre peut être décrit, en plus de son nom, par son
type et sa valeur par défaut. L’absence de paramètres est indiquée par ( )
• Type du résultat : type de valeur retournée. Par défaut, une opération ne
retourne pas de valeur

70

35
 12/05/2021

OPÉRATIONS (SUITE)
LES DIAGRAMMES UML

• Une méthode est l’implémentaBon d’une opéraBon sur une classe. Ainsi, en spécificaBon et
concepBon orientée objet (UML, etc.), on parle d’opéra6ons et en programmaBon orientée
objet (JAVA, C++, etc.), on parle de méthodes.

• Exemple : La classe « Voiture » possède trois opéraBons sans paramètres ni valeur de retour

71

VISIBILITÉ DES ATTRIBUTS ET DES OPÉRATIONS

LES DIAGRAMMES UML

• Trois niveaux de visibilité pour les propriétés :

• Public (+) : C’est le niveau le plus faible; cela revient à se passer de la notion
d’encapsulation et à rendre visibles les attributs et les opérations pour toutes les
classes
• Protégé (#) : C’est relâcher légèrement le niveau d’encapsulation; l’attribut ou
l’opération est visible seulement à l’intérieur de la classe et pour toutes ses sous-
classes
• Privé (-) : C’est le niveau le plus fort; l’attribut ou l’opération est visible seulement
à l’intérieur de la classe

72

36
 12/05/2021

VISIBILITÉ DES ATTRIBUTS ET DES OPÉRATIONS

(EXEMPLE)
LES DIAGRAMMES UML

• La classe voiture possède cinq attributs

• Trois attributs sont des attributs publiques : Marque, Puissance et Cylindrée
• L’attribut Année est un attribut protégé
• L’attribut ChiffreAffaire est un attribut privé, qui ne sera visible qu’à l’intérieur de la classe

73

VISIBILITÉ DES ATTRIBUTS ET DES OPÉRATIONS

(IDÉAL)
LES DIAGRAMMES UML

§ ParBe cachée, protégée, privée

A"ributs

§ Partie dynamique, comportementale

Opéra-ons § Partie visible, publique
§ Interface avec l’extérieur

User

74

37
 12/05/2021

CLASSE ABSTRAITE
LES DIAGRAMMES UML

• Une opéraBon est dite abstraite si on connaît sa signature, mais pas la manière dont elle
peut être uBlisé
• Une classe est dite abstraite lorsqu’elle définit au moins une opéraBon abstraite
• Une classe abstraite se disBngue en UML en ayant le nom de la classe abstraite en italique

75

INTERFACE
LES DIAGRAMMES UML

• Une interface est une classe spéciale dont toutes les opéra6ons sont abstraites
• Une interface se note en UML avec le stéréotype « interface »

76

38
 12/05/2021

PACKAGE
LES DIAGRAMMES UML

• Un package permet de regrouper des classes, des interfaces et des packages

• L’intérêt des packages est de permeEre de structurer les diagrammes et de donner une
vision globale plus claire
• Un package est représenté par un rectangle possédant un onglet dans lequel est inscrit le
nom du package

77

IMPORT DES PACKAGES

LES DIAGRAMMES UML

• La relaBon d’import permet à une classe d’un package d’uBliser les classes d’un autre
package
• La relaBon est monodirecBonnelle, elle comporte un package source et un package cible
• La relaBon d’import s’exprime avec une flèche en poinBllé

78

39
 12/05/2021

RELATIONS ENTRE CLASSES : DÉPENDANCE

LES DIAGRAMMES UML

• La dépendance est la forme la plus faible de rela6on entre classes. Une dépendance entre
deux classes signifie que l’une des deux uBlise l’autre
• Une dépendance peut s’interpréter comme une relaBon de type « uBlise un »
• Elle est habituellement uBlisée lorsqu’une classe uBlise un objet d’une autre classe comme
argument dans la signature d’une opéraBon ou alors lorsque l’objet de l’autre classe est créé
à l’intérieur de l’opéraBon
• Elle est représentée par un trait disconBnu orienté, reliant les deux classes. La dépendance
est souvent stéréotypée « use » pour mieux expliciter le lien sémanBque entre les éléments
du modèle

79

ASSOCIATION
LES DIAGRAMMES UML

• Traduit la relation sémantiques entre deux ou plusieurs classes et

spécifie les connections entre leurs instances
• Relation structurelle spécifiant que les objets d’un type sont connectés
à des objets d’un autre type

Définition

80

40
 12/05/2021

ASSOCIATION / MULTIPLICITÉ
LES DIAGRAMMES UML

• Nombre d’instances d’une classe pouvant être mis en relaBon avec les instances d’une autre
classe
• La mulBplicité est une informaBon portée par le rôle, qui quanBfie le nombre de fois où un
objet parBcipe à une instance de relaBon
• Exemple :
q Un professeur peut enseigner plusieurs cours
q Un cours peut être dispensé par 0 ou un professeur

81

LES DIFFÉRENTS TYPES DE MULTIPLICITÉS

LES DIAGRAMMES UML

Indicateur Signification
1 Un et un seul
0..1 Zéro ou un
n..n’ D’un nombre entier à un autre nombre entier (ex: 0..5 ou 1..3 ou etc.)
* Zéro à plusieurs
0..* Zéro à plusieurs
1..* Un à plusieurs
n Exactement n (entier)

82

41
 12/05/2021

ASSOCIATION BIDIRECTIONNELLE
LES DIAGRAMMES UML

• L’associaBon est représentée par un simple trait conBnu, reliant les deux classes
• Chaque classe parBcipant à l’associaBon connaît le nombre d’instances que peut contenir
l’autre classe

Ø Une société emploie à un ou plusieurs employés

Ø Un employé travaille chez une et une seule société

83

ASSOCIATION BIDIRECTIONNELLE (SUITE)

LES DIAGRAMMES UML

• Sur cet exemple, on peut lire les mulBplicités suivantes :

Ø Une université immatricule zéro ou plusieurs personnes
Ø Une personne est immatriculé par une et une seule université
Ø Une université emploie zéro ou plusieurs personnes
Ø Une personne enseigne dans au plus une université

84

42
 12/05/2021

ASSOCIATION UNIDIRECTIONNELLE
LES DIAGRAMMES UML

• Une relation un peu moins courante entre deux classes

• Une association unidirectionnelle est représentée par une ligne de connexion droite avec
une pointe de flèche ouverte allant de la classe sachante vers la classe connue

85

ASSOCIATION RÉFLEXIVE
LES DIAGRAMMES UML

• Une classe peut s’associer à elle-même

• Cela ne signifie pas que les instances d’une classe sont associées à elles-mêmes
• Les instances de la classe peuvent s’associer à d’autres instances de la même classe

• Dans cet exemple, un employé peut être le manager de zéro ou plusieurs autres employés
• Tout employé est géré par exactement un manager (qui est aussi un employé)

86

43
 12/05/2021

CLASSE D’ASSOCIATION
LES DIAGRAMMES UML

• Une associaBon peut avoir des aEributs = classe d’associa6on

• La classe d’associaBon est uBle quand il y’a des a4ributs qui sont per6nents à l’associa6on,
mais à aucune des classes impliquées

• La classe d’associaBon Job permet de représenter les informaBons spécifiques liées au

travail d’un employé dans une entreprise (par exemple : salaire, date de prise de foncBon,
nombre d’heure, etc.)

87

ASSOCIATION N-AIRE
LES DIAGRAMMES UML

• Une association qui lie plus de deux classes entre elles, est une association n-aire
• L’association n-aire se représente par un losange d’où part un trait allant à chaque classe
• L’association n-aire est imprécise, difficile à interpréter et souvent source d’erreur, elle est
donc très peu utilisée
• La plupart du temps, elle est utilisée au début du projet, puis elle est vite remplacée par un
ensemble d’associations binaires afin de lever toute ambiguïté

À remplacer par

88

44
 12/05/2021

QUALIFICATION D’UNE ASSOCIATION

LES DIAGRAMMES UML

• La qualification d’une association permet de restreindre la multiplicité d’une association

• La qualification se représente par un rectangle placé au niveau de la classe source du
qualificatif
• Par exemple, une banque contient plusieurs comptes, d’où le diagramme suivant :

Banque Compte
1 1..*

• Par contre, si on connaît le N°compte, il y a un et un seul compte, on obtient alors :

Compte
Banque NCompte
1 1

89

QUALIFICATION D’UNE ASSOCIATION

LES DIAGRAMMES UML

90

45
 12/05/2021

AGRÉGATION / COMPOSITION
LES DIAGRAMMES UML

• L’agrégaBon est un type d’associaBon permeEant de traduire la relaBon en « fait par6e de »

• Il existe deux types d’agrégaBon :
Ø Agréga6on
Ø Composi6on (ou dite agréga6on forte)
• L’agrégaBon traduit qu’une classe fait parBe d’une autre mais peut vivre sans l’existence de
la classe dont elle fait parBe

• Dans cet exemple, les pneus du vélo peuvent être créés avant le vélo (dans une autre
compagnie)
• L’agrégaBon se traduit par un losange non rempli du côté de la classe agrégat

91

AGRÉGATION
LES DIAGRAMMES UML
Titre

0..1

1..1

Destinataire E-Mail Fichier

1..* 0..*
* 0..*

Ici, on exprime qu'un fichier peut être attaché à un email (ou a

1..1 plusieurs, ou même à aucun) et qu'un email peut (ou non)
attacher (contenir une copie) une ou plusieurs fichiers.

0..1

Texte

92

46
 12/05/2021

COMPOSITION
LES DIAGRAMMES UML

• La composiBon se traduit par le fait que la classe composant ne peut exister

indépendamment de la classe composée
• La mulBplicité côté composant est toujours exactement 1

• Dans cet exemple, la structure du vélo ne peut exister sans le vélo

• La composiBon se traduit par un losange rempli du côté de la classe composée

93

AGRÉGATION / COMPOSITION (EXEMPLE)

LES DIAGRAMMES UML

94

47
 12/05/2021

GÉNÉRALISATION/SPÉCIALISATION (RAPPEL)
LES DIAGRAMMES UML

• RelaBon entre des classes où l’une des classes partage la structure ou le comportement
d’une autre classe
• Hiérarchie d’abstracBon où des sous-classes héritent d’une ou plusieurs super-classes
Ø Héritage simple
Ø Héritage mulBple
• La généralisaBon est une rela6on non réflexive; une classe ne peut pas dériver d’elle-même
• La généralisaBon est une rela6on non symétrique; si une classe B dérive d’une classe A,
alors la classe A ne peut pas dériver de la classe B
• La généralisaBon est par contre une rela6on transi6ve; si une classe C dérive d’une classe
B qui dérive elle-même d’une classe A, alors C dérive également de A

95

GÉNÉRALISATION / SPÉCIALISATION ET HÉRITAGE

LES DIAGRAMMES UML

• Généraliser = mettre en facteur des classes ® « super-classe »

• Spécialiser = décrire de nouveaux détails ® « sous-classe »

• Une sous-classe (classe fille) hérite des attributs et des opérations de sa super-classe
(classe mère)
• La relation d’héritage est représentée par un triangle vide afin d’indiquer le sens

96

48
 12/05/2021

GÉNÉRALISATION / SPÉCIALISATION ET HÉRITAGE

LES DIAGRAMMES UML

• La sous-classe peut ajouter ses propres a4ributs et opéra6ons

• Elle peut également redéfinir le comportement d’une ou plusieurs opéraBons

• La relaBon d’héritage est comparable à une associaBon de type « est un », « is a » ou « kind

of »
• Une classe peut hériter de plusieurs classes, on parle alors d’un héritage mulBple

97

HÉRITAGE MULTIPLE
LES DIAGRAMMES UML

• Une classe hérite d’une ou plusieurs autres classes

• Il faut u+liser l'héritage mul8ple avec prudence et

seulement si indispensable

• L'héritage mul+ple n'est pas supporté par la plupart

des langages de POO (ex: Java, C#, etc.)

• L’héritage mul+ple est supporté par quelques

langages de programma+on tels que : C++, Eiffel ou
Python

98

49
 12/05/2021

POLYMORPHISME
LES DIAGRAMMES UML

• Poly "Plusieurs" / Morphisme "Formes"

• En POO, une classe dérivée peut redéfinir une méthode héritée de sa classe de base, tout en
gardant le même nom. Ce<e possibilité est la clé de ce que l'on nomme polymorphisme
• C’est donc la capacité d'une classe à redéfinir une méthode héritée à par+r d'une classe mère
• La possibilité de traiter de la même manière des objets de types différents
• Le polymorphisme représente la faculté d'une opéra+on de s'appliquer à des objets de classes
différentes
• Avantages

• Lisibilité du code

• Généricité du code

99

POLYMORPHISME
LES DIAGRAMMES UML

100

50
 12/05/2021

EXEMPLE DE DIAGRAMME DE CLASSE

LES DIAGRAMMES UML

101

Diagramme
D ’o b j e t s
Diagramme UML

102

51
 12/05/2021

DIAGRAMME D’OBJETS
LES DIAGRAMMES UML

• ReprésentaBon d’un ensemble d’objets et de liens, exprimant la

structure staBque
• Un diagramme d’objets est une instance d’un diagramme de classes et
illustre l’état d’un système à un moment donné
• Les diagrammes d’objets s’uBlisent principalement :
Ø Pour montrer un contexte avant ou après une interacBon
Défini&on
Ø Pour faciliter la compréhension des structures de données
complexes
• La notaBon des diagrammes d’objets est dérivée de celle des
diagrammes de classes

103

DIAGRAMME D’OBJETS
LES DIAGRAMMES UML

• Le nom d’un objet est souvent écrit en souligné, et il commence par une minuscule
• Des groupes d’objets instances d’une même classe peuvent se représenter sous une forme
imbriquée
• Le symbole « : » sépare le nom de l’instance du nom de sa classe

104

52
 12/05/2021

DIAGRAMME D’OBJETS
LES DIAGRAMMES UML

• L’état d’un objet est déterminé par les valeurs de ses aEributs :
Ø Il est possible de nommer un état afin d’indiquer clairement dans quel état se
trouve un objet
• Les représentaBons des objets peuvent contenir des aEributs significaBfs

105

DIAGRAMME D’OBJETS
LES DIAGRAMMES UML

106

53
 12/05/2021

DIAGRAMME D’OBJETS
LES DIAGRAMMES UML

• Les objets sont relies par des instances d’associaBons, les liens
• Un lien représente une rela6on entre objets à un instant donné

• A4en6on : la mulBplicité des extrémités des liens est toujours de 1

107

Diagramme
De Séquences
Diagramme UML

108

54
 12/05/2021

INTRODUCTION
LES DIAGRAMMES UML

• Le diagramme de séquences fait partie des diagrammes

comportementaux (dynamiques), plus précisément les
diagrammes d’interactions

• Le diagramme de séquences permet de représenter les

interactions entre :
Objec&f
• Les entités
• Les instances de classes
• Les sous-systèmes

109

INTRODUCTION
LES DIAGRAMMES UML

• Le diagramme de séquences montre quel sont les objets par6cipants à l’exécuBon du use-
case et quels sont les messages qu’ils échangent

• Il représente:
• Une suite spécifique d’événements survenant dans le système
• Une séquence spécifique d’acBons et d’interacBons entre les acteurs et le
système

• DescripBon des instances d’un point de vue temporel

110

55
 12/05/2021

REPRÉSENTATION DES SCÉNARIOS

LES DIAGRAMMES UML

• Principe de base :
• ReprésentaBon graphique de la chronologie des échanges de messages avec le
système ou au sein du système
• Il suit une chronologie de haut en bas
• La « vie » de chaque enBté est représentée ver6calement
• L’échange des messages est représenté horizontalement
• Deux scenarios possibles:
• Normal : Tout se passe bien; correspond au déroulement du cas d’uBlisaBon
• Secondaire : DescripBon des cas alternaBfs (plusieurs choix), d’excepBons et
d’erreurs

111

DIAGRAMME DE SÉQUENCE : VUE GÉNÉRALE

LES DIAGRAMMES UML

• L’axe ver6cal représente le temps

• L’axe horizontal représente les objets/ acteurs

impliqués dans l’interacBon

• Une ligne ver6cale est aEachée à chaque objet/acteur

et représente sa ligne de vie (lifeline)

112

56
 12/05/2021

DIAGRAMME DE SÉQUENCE : VUE GÉNÉRALE

LES DIAGRAMMES UML

113

DIAGRAMME DE SÉQUENCE : VUE GÉNÉRALE

LES DIAGRAMMES UML
Acteur

Instance d’une classe du

diagramme de classe
Jean : acteur
jean objet a : Classe A objet b : Classe B

Appel d’une opération X()

opéra&on
opération Y(args)
Exécu&on/
période d’ac&vité
retourY
Valeur renvoyée retourX

Ligne de vie

114

57
 12/05/2021

COMPOSANTS : OBJETS/ACTEURS/SOUS SYSTÈMES

LES DIAGRAMMES UML

• Dans un diagramme de séquences :

§ Les objets, acteurs et/ou sous systèmes apparaissent dans la par6e supérieure
du diagramme

§ Ils correspondent aux classes parBcipant à l’interacBon

§ Chaque bloc ou objet parBcipant dans le processus est représenté par une barre
ver6cale

§ Remarque : l’ordre dans lequel apparaissent les barres verBcales d’objets, n’a pas
d’importance (lisibilité)

115

COMPOSANTS : LIGNE DE VIE D’UN OBJET

LES DIAGRAMMES UML

• La ligne de vie des objets est représentée par une ligne verBcale en traits poinBllés, placée
sous l’objet concerné
objet a : Classe A
objet b : Classe B

• Cette ligne de vie précise l’existence de l’objet

Créer
concerné durant un certain laps de temps

Détruire
Ligne de vie X

116

58
 12/05/2021

COMPOSANTS : LIGNE DE VIE D’UN OBJET

LES DIAGRAMMES UML

• Représente la durée de vie d’un objet dans un objet a : Classe A

diagramme de séquence
objet b : Classe B

• De nouveaux objets peuvent être crées pendant le cycle Créer

• Un objet est créé quand un message de créa6on lui est Détruire

envoyé Ligne de vie

• La fin de la ligne avec une croix correspond à la X

destruc6on de l’objet

117

COMPOSANTS : PÉRIODE D’ACTIVITÉ

LES DIAGRAMMES UML

• Appelée aussi point de contrôle

• La période d’acBvité dans un diagramme de séquences correspond au temps pendant
lequel un objet fait une ac6on ou aussi le temps nécessaire pour l’exécu6on d’une tache
par cet objet
objet a : Classe A objet b : Classe B
• Représentée par une bande rectangulaire
opération Y(args)
superposée à la ligne de vie de l’objet

retourY

Exécu&on/
Exécu&on/
période d’ac&vité
période d’ac&vité

118

59
 12/05/2021

COMPOSANTS : MESSAGES
LES DIAGRAMMES UML

• Dans un diagramme de séquence, les messages :

§ Sont représentés par des flèches direc6onnelles orientées de l’émeEeur au
récepteur

§ Décrivent la communica6on entre objets (instances des classes)

§ Sont différents de la rela6on structurelle entre les classes

§ Un texte sur la flèche caractérise le message envoyé à l’objet appelé

119

COMPOSANTS : MESSAGES
LES DIAGRAMMES UML

• Le diagramme étant orienté de haut vers le bas, l’ordre d’appari6on des messages
représente l’ordre d’appel des ac6ons
• Un objet peut envoyer des messages à lui même (ces messages sont dits réflexifs)
• Les flèches peuvent être orientées dans un sens ou dans l’autre
• Plusieurs types de messages existent, les plus communs sont :
• L’invocaBon d’une opéraBon : appel d’une méthode de l’objet cible (synchrone)
• L’envoie d’un signal : uBlisé pour la gesBon évènemenBelle (asynchrone)
• CréaBon ou destrucBon d’une instance de classe au cours du cycle principal

120

60
 12/05/2021

COMPOSANTS : MESSAGES
LES DIAGRAMMES UML

• Un message doit toujours contenir : un nom qui fait référence à l’action / méthode de la
classe cible qui doit être appelée et exécutée ou du signal envoyé
• Nous pouvons adjoindre au nom facultativement :
• Une numérotation devant le nom message (séparé du nom du message par 2
point " : "). La numérotation s’effectue séquentiellement à partir de 1
• Les paramètres passés à la méthode ou au signal (entre parenthèses après le
nom du message)

121

TYPES DE MESSAGES
LES DIAGRAMMES UML

• Il existe différents types de messages :

§ Messages synchrones § Messages de destruction
§ Messages asynchrones § Message conditionnel
§ Messages de retour § Message réflexif
§ Message minuté (Time out) § Message itératif
§ Message de créaBon

122

61
 12/05/2021

TYPES DE MESSAGES
LES DIAGRAMMES UML

• Message synchrone
§ Appel bloquant l’émetteur
§ L’émetteur attend la fin de l’exécution du
récepteur
§ Graphiquement, un message synchrone est
représenté par une flèche pleine
§ Les messages synchrones peuvent renvoyer un
message de retour, représentés par des flèches en
traits discontinus
§ Le retour d'un message synchrone peut ne pas
être représenté, le retour est alors implicite
123

TYPES DE MESSAGES
LES DIAGRAMMES UML

• Message asynchrone
§ Les messages asynchrones sont des
messages non bloquants
§ Ils n’interrompent pas l’exécuBon de
l’émeEeur
§ L’émeEeur n’aEend pas la fin de
l’exécuBon du récepteur
§ Graphiquement, un message asynchrone
est représenté par une flèche ouverte
§ Les messages asynchrones peuvent aussi
renvoyer un message de retour (facultaBf)

124

62
 12/05/2021

TYPES DE MESSAGES
LES DIAGRAMMES UML

• Message Minuté
§ Bloque l’expéditeur pendant un temps donné, objet a : Classe A objet b : Classe B
en attendant la prise en compte du message
par le récepteur
Message(20 secondes)
§ Après le délais, l’expéditeur est libéré et peut
envoyer d’autres messages

125

TYPES DE MESSAGES
LES DIAGRAMMES UML

• Message réflexif appelé aussi récursif

§ Dans un message réflexif, l’objet joue les deux rôles à la fois : éme4eur et
récepteur

§ Massage envoyé d’un objet

vers lui-même

126

63
 12/05/2021

TYPES DE MESSAGES
LES DIAGRAMMES UML

• Message réflexif appelé aussi récursif : Exemple

Client GAB

Introduire carte

Vérification de
validité de carte
Demande d’accès

127

TYPES DE MESSAGES
LES DIAGRAMMES UML

• Message conditionnel
§ Un message conditionnel est composé des branches représentant chacune le
message correspondant à un condition indiquée entre crochets

128

64
 12/05/2021

TYPES DE MESSAGES
LES DIAGRAMMES UML

• Message itéra6f : boucles

§ La boucle se note comme le teste,
mais la boucle est précédée d’un
astérisque *

129

MESSAGES ET CLASSES
LES DIAGRAMMES UML

• La noBon de message dans le diagramme de séquence correspond aux méthodes dans les
classes

• La méthode est implémentée du coté du récepteur

• Il est aussi possible de préciser des paramètres à l’envoie des messages

130

65
 12/05/2021

CRÉATION / DESTRUCTION D’OBJETS

LES DIAGRAMMES UML

• Créa%on d’objets
§ En faisant pointer un message de créa6on sur le rectangle symbolisant l’objet
dans le diagramme

• Destruc%on d’objets
§ Représenté par une croix à la fin de la ligne de vie
§ Un objet peut s’auto détruire
§ Un objet peut se détruire par un message pointé sur la croix

131

RÉCAPITULATIF
LES DIAGRAMMES UML

Période d’activité/
point de contrôle

Auto destruction
de l’objet 5
Message de
créa-on de
l’objet 3

Message de Destruc-on
destruc-on de l’objet 3
de l’objet 3

132

66
 12/05/2021

FRAGMENT
LES DIAGRAMMES UML

• Les fragments permeEent de découper un diagramme de séquence en unité́ simple

• Les fragments sont représentés dans des rectangles
• Le type du fragment est précisé́ dans un pentagone à l’intérieur du rectangle

Nom du fragment
(faculta-f)
Type de fragment

Fragment combiné

Contenu du
fragment

133

TYPES : FRAGMENT
LES DIAGRAMMES UML

• alt : Opérateur condiBonnel

• loop : Opérateur d’itéraBon
• opt : Opérateur opBonnel (facultaBf)

• break : Si exécuté, le reste de la séquence est abandonné

• par : ExécuBon en parallèle

• seq : Message d’une même ligne de vie s’exécute séquenBellement

• ref : Pour faire référence à une séquence déjà définie

134

67
 12/05/2021

TYPES : FRAGMENT
LES DIAGRAMMES UML

• L’opérateur condiBonnel alt

§ Modélise des alternaBfs (des choix)
§ Se base sur des condiBons

§ Les condiBons sont spécifiées entre [ ]

§ Les alternaBves sont spécifiées dans des
zones en poinBllés

§ Une clause [ else ] peut être spécifiée

135

TYPES : FRAGMENT
LES DIAGRAMMES UML

• L’opérateur d’itération loop

§ Modélise les itérations (répétitions)
§ La séquence d’activité se répète
tant que la condition d’arrêt n’est
pas vérifiée

136

68
 12/05/2021

TYPES : FRAGMENT
LES DIAGRAMMES UML

• L’opérateur de référence ref

§ Sert à réuBliser des séquences déjà
définies
§ Permet de définir des diagrammes
de séquence plus simples et lisibles

137

FRAGMENT
LES DIAGRAMMES UML

• Il est possible de combiner les opérateurs

138

69
 12/05/2021

Diagramme
D’activités
Diagramme UML

139

DIAGRAMME D’ACTIVITÉ
LES DIAGRAMMES UML

• PermeEent de visualiser un graphe d’acBvité qui représente le

comportement interne :
§ D’un cas d’uBlisaBon
§ D’une méthode
§ D’un processus impliquant un ou plusieurs classes

Objectifs • Les diagrammes d’acBvités permeEent de donner une vision

plus détaillée sur les scénarios des cas d’uBlisaBon
• Il permet de modéliser un workflow (succession de tâche) de
façon dynamique

140

70
 12/05/2021

COMPOSITION D’UN DAC

LES DIAGRAMMES UML

• Un diagramme d’activité comprend :

• Des activités :
Ø Une activité représente une exécution d’un mécanisme, un déroulement d’étape
séquentielles
• Des transitions :
Ø Liens automatiques entre les activités. Il traduisent automatiquement la
transition entre les activités

• Théoriquement, tous les mécanismes dynamiques pourraient être décrits par un DAC,
mais seuls les mécanismes complexes ou intéressants méritent d’être représentés

141

COMPOSITION D’UN DAC

LES DIAGRAMMES UML

v Ac6on
§ Plus peBte unité de traitement pouvant être exprimée en
UML
§ Elle a une incidence sur l’état du système
§ Permet de construire des comportements

Définition § Une acBon peut être, par exemple :

o AffectaBon de valeurs
o CréaBon d’un nouvel objet
o Emission/RécepBon d’un signal

142

71
 12/05/2021

COMPOSITION D’UN DAC

LES DIAGRAMMES UML

v Transition
§ Elle traduit le passage d’une activité à une autre
§ Elle est représentée par des flèches en traits pleins
§ Elle est déclenchée dès que l’action source est terminée
§ Enclenche automatiquement le début de la prochaine

Défini&on activité

143

COMPOSITION D’UN DAC

LES DIAGRAMMES UML

v Nœud d’ac6on
§ AcBvité exécutable consBtuant l’unité fondamentale
d’exécuBon dans une acBvité
§ Liés à des opéraBons qui peuvent s’exécuter
§ Doit avoir obligatoirement un arc entrant

Définition § Représenté par un rectangle aux angles arrondis et conBent

la descripBon textuelle
§ Le nom peut être simple (entrer le nom) ou complexe (une
suite d’acBons)

144

72
 12/05/2021

TYPES DE NŒUDS
LES DIAGRAMMES UML

• Nœud iniBal
• Nœud de fin d’acBvité
• Nœud de fin de flot
• Nœud de décision
• Nœud de fusion
• Nœud de bifurcaBon
• Nœud d’union

145

TYPES DE NŒUDS (SUITE)

LES DIAGRAMMES UML
§ Nœud initial
• Nœud à partir duquel le flot débute lorsque l’activité enveloppée est invoquée
• Graphiquement, un nœud initial est représenté par un petit cercle plein
§ Nœud de fin d’activité
• Lorsque l’un des arcs est activé, l’exécution de l’activité s’achève et tout nœud ou
flot d’activité est abandonné
• Graphiquement, un nœud de fin d’activité est représenté par un cercle vide
contenant un cercle plein
§ Nœud de fin de flot
• Lorsque l’un des arcs est activé, le flot est terminé
• Graphiquement, un nœud de fin de flot est représenté par un cercle vide barré
d’un X
146

73
 12/05/2021

TYPES DE NŒUDS (SUITE)

LES DIAGRAMMES UML

§ Nœud de décision
• Nœud de contrôle permeEant de faire un choix entre plusieurs flots sortants
• Généralement accompagné de condi6ons de garde entre deux [ ] pour
condiBonner le choix
• Graphiquement, il est représenté par un losange
Mesurer la
température

[trop froid] [trop chaud]

Chauffer Refroidir

147

TYPES DE NŒUDS (SUITE)

LES DIAGRAMMES UML

§ Nœud de fusion
• Nœud de contrôle qui rassemble plusieurs flots alternatifs entrants en un seul
flot sortant
• Il ne peut pas être utilisé pour synchroniser des flots concurrents mais pour
accepter un flots parmi plusieurs
• Graphiquement, il est représenté comme un nœud de décision, par un losange
valider Annuler

Retrait de la carte

148

74
 12/05/2021

TYPES DE NŒUDS (SUITE)

LES DIAGRAMMES UML

§ Nœud de bifurca6on ou de débranchement

• C’est un nœud de contrôle qui sépare un
flot en plusieurs flots concurrents
• Possède donc un arc entrant et plusieurs
arcs sortants
• Graphiquement, il est représenté par un trait
plein

149

TYPES DE NŒUDS (SUITE)

LES DIAGRAMMES UML

§ Nœud d’union ou de jointure

• C’est un nœud de contrôle qui synchronise
des flots mulBples
• Un nœud d’union est une
synchronisaBon/parallélisme qui représente
des déroulements parallèles
• Possède donc plusieurs arcs entrants et un
seul arc sortant
• Graphiquement, il est représenté comme un
nœud de bifurcaBon, par un trait plein

150

75
 12/05/2021

DISJONCTION & CONJONCTION D’ACTIVITÉS

LES DIAGRAMMES UML

• La synchronisaBon des transiBons union et bifurcaBon se fait à

l’aide des « barres de synchronisa6on »
Ac:vité 1 Activité 2

• Les transiBons qui partent d’une barre de synchronisaBon ont

lieu en même temps join

q Union (join) : une barre de synchronisaBon ne peut

Ac:vité 3
être franchie que lorsque toutes les transiBons en
entrée sur la barre sont déclenchées
Ac:vité 1
q Bifurca6on (fork) : les transiBons de débranchement
fork
au départ d’une barre de synchronisaBon sont
déclenchées simultanément Activité 2 Activité 3

151

EXEMPLE
LES DIAGRAMMES UML

152

76
 12/05/2021

COULOIRS D’ACTIVITÉS
LES DIAGRAMMES UML

• Les diagrammes d’activités indiquent ce

qui se passe sans préciser qui fait quoi

• Il est possible de diviser un diagramme

d’activités en partitions ou couloirs
d’activités (swim lanes)

• Chaque partition montre quelles actions

sont exécutées par une classe ou une
unité organisationnelle

153

LOTS D’ACTIONS
LES DIAGRAMMES UML

• Il est possible qu’une acBon soit la référence à un autre diagramme

• Généralement traduit par une relaBon de type « include » ou « extend » dans un DCU
• Dans ce cas, l’acBon représente l’ensemble des acBons du DAC de référence
• Les lots d’acBons facilitent la réuBlisaBon des diagrammes
• Ils permeEent d’avoir des DACs plus lisibles
• Possibilité de découper les DACs complexes en sous-diagrammes
• Graphiquement, elle est représentée par une acBon contenant deux cercles reliés par un
trait

154

77
 12/05/2021

LOTS D’ACTIONS
LES DIAGRAMMES UML

155

Diagramme
D ’é t a t s - t r a n s i 7 o n s
Diagramme UML

156

78
 12/05/2021

DIAGRAMME D’ÉTATS-TRANSITIONS
LES DIAGRAMMES UML

• Le diagramme d’états-transiBons décrit le comportement des

objets d’une classe au moyen d’un automate d’états associés à
la classe
• Le comportement est modélisé par un graphe :
§ Nœud = états possibles des objets

Définition § Arcs = transiBons d’état à état

• Une transi3on représente l’exécuBon d’une acBon ou la
réacBon de l’objet sous l’effet d’une occurrence d’événement

157

DIAGRAMME D’ÉTATS-TRANSITIONS (EXEMPLE)

LES DIAGRAMMES UML

158

79
 12/05/2021

CYCLE DE VIE
LES DIAGRAMMES UML

• Le cycle de vie d’un objet d’une classe représente :

§ Les états qui peuvent être pris par les objets d’une classe

§ Les événements qui provoquent la transiBon d’un état à un autre

§ Les ac3ons subies/provoquées qui accompagnent un changement d’état

§ Les ac3vités qui surviennent tant que l’objet est à un état donnée

159

NOTION D’ÉTAT
LES DIAGRAMMES UML

• Un état représente une étape dans le cycle de vie d’un objet

• Chaque objet possède à un instant donné un état particulier
• Chaque état est identifié par un nom
• Un état est stable et durable
• Chaque diagramme d’états-transitions comprend trois types d’états :

État
État ini8al État final
intermédiaire

160

80
 12/05/2021

NOTION DE TRANSITION
LES DIAGRAMMES UML

• Les états sont reliés par des connexions unidirectionnelles appelées transitions

État A État B

• Exemple (place de parking) :

Disponible Réservée

161

NOTION D’ÉVÉNEMENT
LES DIAGRAMMES UML

• Un événement correspond à l’occurrence d’une situa3on donnée dans le domaine étudié

• C’est une informa3on instantanée qui doit être traitée à l’instant où il se produit
événement
État A État B

• La syntaxe d’un événement : Nom de l’événement (Nom du paramètre : Type, …)

• La descrip3on complète d’un événement est donnée par :
§ Nom de l’événement
§ Liste des paramètres
§ Objet expéditeur/desBnataire
§ DescripBon textuelle

162

81
 12/05/2021

TYPES D’ÉVÉNEMENTS
LES DIAGRAMMES UML

• Signal : réception d’un message asynchrone

• Appel d’une opération (synchrone) : liée aux cas d’utilisation, opération du diagramme de
classes, etc.
• Satisfaction d’une condition booléenne : when (cond), évaluée continuellement jusqu’à ce
qu’elle soit vraie
• Temps :
• Date relative : when (date = date)
• Date absolue : after (durée)

163

EN RÉSUMÉ
LES DIAGRAMMES UML

événement
État A État B

• État d’un objet

• SituaBon d’un objet que l’on désire connaître et gérer
• Transi3on
• Passage d’un objet d’un état à un autre. Elle est déclenchée par un événement
• Événement
• SBmulus qui provoque une ou plusieurs transiBons
• À chaque sBmulus peut correspondre une acBon responsable des modificaBons
de l’objet (valeurs des aEributs)

164

82
 12/05/2021

ÉTATS SPÉCIAUX
LES DIAGRAMMES UML

• État de démarrage : obligatoire, unique

• État de fin : opBonnel, peut-être mulBple

Créa8on de l’objet Fin de vie de l’objet

État 1 État X

165

NOTION DE GARDE
LES DIAGRAMMES UML

• Une garde est une condi3on booléenne qui permet ou non le déclenchement d’une
transiBon lors de l’occurrence d’un événement

Événement [condi8on]
État A État B

• Exemple :
Retour [Bon état] Retour [Mauvais état]
Emprunté

En
Disponible
réparation

166

83
 12/05/2021

NOTIONS D’OPÉRATION ET D’ACTION

LES DIAGRAMMES UML

• Une action représente le lien entre les opérations définies dans la spécification d’une classe
et les événements apparaissant dans le diagramme d’états-transitions
• Chaque transition peut avoir une action à exécuter lorsqu’elle est déclenchée
• L’action est considérée comme instantanée et atomique
• Une action correspond à l’exécution d’une des opérations déclarées dans la classe de l’objet
destinataire de l’événement
Événement / Ac8on
• Exemple : État A État B
• Il pleut / ouvrir parapluie
• Salut / serrer main
• L’action a accès aux paramètres de l’événement ainsi qu’aux attributs de l’objet sur lequel
elle s’applique

167

NOTIONS D’OPÉRATION ET D’ACTION (SUITE)

LES DIAGRAMMES UML

• Lorsque l’événement se produit, si la condition est vérifiée, alors l’action est effectuée

168

84
 12/05/2021

ACTION DANS UN ÉTAT

LES DIAGRAMMES UML

• Les états peuvent également contenir des actions

• Elles sont exécutées :
• À l’entrée (entry) ou la sortie (exit) de l’état
• Lorsqu’une occurrence d’événement interne (on) survient

169

ACTION DANS UN ÉTAT (SUITE)

LES DIAGRAMMES UML

• Un événement interne n’entraîne pas l’exécuBon des acBons d’entrée et de sorBe,

contrairement au déclenchement d’une transi3on réflexive

170

85
 12/05/2021

OPÉRATIONS, ACTIONS ET ACTIVITÉS

LES DIAGRAMMES UML

• Contrairement à une action, une activité est une opération qui dure un certain temps
• Les activités sont associées aux états

§ Elles commencent quand on est entré dans l’état

§ Elles s’exécutent jusqu’à la fin si elles ne sont pas interrompues par une
transition sortante (donc tant que l’état ne change pas)
§ Elles peuvent être interrompues car elle ne modifient pas l’état de l’objet

• Les activités (do) sont notées dans la partie inférieure de l’état

171

OPÉRATIONS, ACTIONS ET ACTIVITÉS (SUITE)

LES DIAGRAMMES UML

• Lorsqu’une activité se termine, les transitions automatiques (sans événement), mais

éventuellement protégées par des gardes, sont déclenchées

172

86
 12/05/2021

OPÉRATIONS, ACTIONS ET ACTIVITÉS (SUITE 2)

LES DIAGRAMMES UML

• Il y a six manières d’associer une opéraBon à une transiBon

:
§ L’acBon associée à la transiBon d’entrée (op1)
§ L’acBon d’entrée de l’état (op2)
§ L’ac3vité dans l’état (op3)
§ L’acBon de sor3e de l’état (op4)
§ L’acBon associée aux événements internes
(op5)
§ L’acBon associée à la transi3on de la sorBe de
l’état (op6)

173

EXEMPLE : DAB
LES DIAGRAMMES UML

174

87
 12/05/2021

GÉNÉRALISATION D’ÉTATS
LES DIAGRAMMES UML

AB
e1
A B e1
A B

e2 e2
C e2

175

ÉTATS IMBRIQUÉS - COMPOSITES

LES DIAGRAMMES UML

• Objec3fs :
Ø Hiérarchiser les états
Ø Structurer les comportements complexes
Ø Factoriser les acBons

176

88
 12/05/2021

ÉTATS IMBRIQUÉS - COMPOSITES

LES DIAGRAMMES UML

• Objectifs :
Ø Hiérarchiser les états
Ø Structurer les comportements complexes
Ø Factoriser les actions

177

ÉTATS ORTHOGONAUX
LES DIAGRAMMES UML

• État composite dans lequel plusieurs états sont ac3fs simultanément

(concurrence/parallélisme)
• État acBf global = un état acBf par région

178

89
 12/05/2021

ÉTATS ORTHOGONAUX (SUITE)

LES DIAGRAMMES UML

179

UTILISATION DES DIAGRAMMES ÉTATS-TRANSITIONS

LES DIAGRAMMES UML

• En phase d’analyse :
Ø Description de la dynamique du système vu de l’extérieur
Ø Synthèse des scénarios liés aux cas d’utilisation
Ø Événements = action des acteurs

• En phase de conception :
Ø Description de la dynamique d’un objet particulier
Ø Événements = appels d’opérations

180

90
 12/05/2021

FIN

181

91