CONCEPTION ORIENTÉE OBJET

- UML -
Filière SMI – S5
Pr. Anas EL ANSARI
[Link]@[Link]

2023/2024
 Plan
Chapitre 1. Introduction à la conception orientée objet.

Chapitre 2. Diagramme de cas d’utilisation.

Chapitre 3. Diagramme de classes.

Chapitre 4. Diagramme d’objets.

Chapitre 5. Diagramme de séquences.

Chapitre 6. Diagramme des paquetages.

Chapitre 7. Diagramme des composants.

Chapitre 8. Diagramme d’état-transition.

Chapitre 9. Diagramme d’activités.

2
 Plan
Chapitre 1. Introduction à la conception orientée objets.
➢ Système d’information

➢ Génie logiciel

➢ Conception / modélisation.

➢ Approche fonctionnelle vs Approche Objet

➢ Langage UML.

➢ Les vues UML

➢ Les diagrammes et outils UML.

3
Introduction à la conception orientée objets

➢ Système d’information :

• Un système d’information est un ensemble organisé de

Système de
ressources (matériel, logiciel, personnel, et données)
pilotage
permettant de collecter, traiter, diffuser, ou stocker des
informations.
Système
d’information

Système
opérant
Entreprise / Organisation

4
Introduction à la conception orientée objets

➢ Système d’information :

• Le système d'information comporte des ressources humaines, matérielles et logicielles;

• Le matériel est relativement fiable et le marché est standardisé.

• Les problèmes dans ce système sont généralement des problèmes de logiciel.

5
Introduction à la conception orientée objets

➢ Génie logiciel :

• Domaine de recherche ayant pour objectif d'optimiser le développement d’un logiciel en

adoptant une approche méthodologique.

• Logiciel : ensemble de programmes permettant à un système informatique (Ordinateur)

d'assurer une tâche ou une fonction particulière.

6
Introduction à la conception orientée objets

➢ Génie logiciel :

• Développement d'un logiciel (Étude du Standish Group, 1995)

o 16,2% seulement des projets étaient conformes aux prévisions initiales,
o 52,7% avaient subi des dépassements en coût et délai,
o 31,1% ont été purement abandonnés durant leur développement.

• Le développement des logiciels dans un contexte professionnel suit souvent des règles strictes
encadrant la conception et permettant le travail en groupe et la maintenance du code.

7
Introduction à la conception orientée objets

➢ Génie logiciel :

• Le génie logiciel touche au différentes phases du cycle de développement d’un logiciel :

o L'analyse du besoin,
o L'élaboration des spécifications (cahier des charges),
o La conception,
o Le développement,
o La phase de test,
o La maintenance.

 L’ objectif est de produire des logiciels de qualité, répondant aux besoins exprimés, de
prévoir et réduire les coûts et les délais, et faciliter la maintenance.

8
Introduction à la conception orientée objets

➢ Conception / modélisation :

• En informatique, la modélisation permet de concevoir la structure et la dynamique des

éléments d’un système/logiciel, ainsi que l'organisation des informations;

• Un modèle est une représentation abstraite et simplifiée d'une entité (système, processus, etc.)
du monde réel en vue de la décrire ou de l'expliquer.

• Modéliser un système avant sa réalisation permet de mieux comprendre son fonctionnement.

C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence.

• Méthodes et langages de modélisation: Merise, UML, OMT, OOSE, etc.

9
Introduction à la conception orientée objets

➢ Approche fonctionnelle vs Approche Objet :

• L'approche fonctionnelle/structurée :

o Privilégie la fonction comme moyen d'organisation du logiciel.

o Utilisée avec les langages de programmation procéduraux (Pascal, C, etc.)

o Conception avec Merise;

10
Introduction à la conception orientée objets

➢ Approche fonctionnelle vs Approche Objet :

• L'approche Objet :

o Considère le logiciel comme une collection d'objets possédant des caractéristiques.

o Utilisée avec les langages de programmation orientée objet (C++, Java, etc.)

o Conception avec UML;

11
Introduction à la conception orientée objets

➢ Langage UML ( Unified Modeling Language) :

• Langage de modélisation unifié à base de diagrammes graphique permettant de modéliser un

système selon une approche objet;

• UML est à la fois :

o Une norme (adopté par l’OMG)

o Un langage de modélisation objet,

o Un support de communication.

• UML n’est pas une méthode.

12
Introduction à la conception orientée objets

➢ Langage UML ( Unified Modeling Language) :

• UML se décompose en plusieurs parties :

o Les vues : ce sont les observables du système. Elles décrivent le système d'un point de vue
donné, qui peut être organisationnel, dynamique, temporel, architectural, logique, etc. En
combinant toutes ces vues, il est possible de définir (ou retrouver) le système complet.

o Les diagrammes : ce sont des ensembles d'éléments graphiques. Ils décrivent le contenu des
vues, qui sont des notions abstraites. Ils peuvent faire partie de plusieurs vues.

o Les modèles d'élément : ce sont les éléments graphiques des diagrammes.

13
Introduction à la conception orientée objets

➢ Les vues UML :

• Cinq façons de voir un système, chacune présentant le système selon un point de vue différent.

• L’utilisation de vues permet de traiter séparément les intérêts des divers groupes d’intervenants
(utilisateurs, développeurs, chefs de projets, etc.)

Vue des cas

d’utilisation

14
Introduction à la conception orientée objets

➢ Les vues UML :

• La vue « logique » décrit les aspects statiques et dynamiques d’un système en termes de
classes, d’objets, de connexions et de communications.

• La vue « processus » capte les aspects de concurrence et de synchronisation (processus, fil

d’exécution, etc.). Elle se rapporte aux objets actifs et aux interactions.

15
Introduction à la conception orientée objets

➢ Les vues UML :

• La vue « d’implémentation/développement » représente l’organisation statique des modules

(exécutable, codes source, paquetages, etc.) dans l’environnement de développement.

• La vue « du déploiement/physique » décrit les différentes ressources matérielles et

l’implantation logicielle tenant compte de ces ressources.

16
Introduction à la conception orientée objets

➢ Les vues UML :

• La vue « cas d’utilisation » se concentre sur la cohérence en présentant des scénarios

d’utilisation qui mettent en œuvre les éléments des quatre premières vues. Cette vue est
construite en premier, juste après l’établissement du cahier des charges, pour fixer les contours
du système à réaliser et ses fonctionnalités appelées cas d’utilisation.

17
Introduction à la conception orientée objets

➢ Les diagrammes UML :

• Un diagramme UML est une représentation visuelle d'un aspect d'un système.

• Les diagrammes UML illustrent les aspects quantifiables d'un système qui peuvent être décrits
visuellement, tels que les relations, le comportement, la structure ou la fonctionnalité.

• Les diagrammes sont dépendants hiérarchiquement et se complètent, de façon à permettre la

modélisation d'un projet tout au long de son cycle de vie.

• Il existe 14 diagrammes (depuis UML 2.3):

o 7 Diagrammes de structure ou statiques
o 7 Diagrammes de comportement ou dynamiques

18
Introduction à la conception orientée objets

➢ Les diagrammes de structure / statiques :

• Diagramme de classes : représentation des classes intervenant dans le système.

• Diagramme d'objets : représentation des objets utilisées dans le système.

• Diagramme de composants : représentation des composants du système d'un point de vue

physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de données…)

• Diagramme de déploiement : représentation des éléments matériels (ordinateurs,

périphériques, réseaux, systèmes de stockage…) et la manière dont les composants du
système sont répartis sur ces éléments matériels et interagissent entre eux.

19
Introduction à la conception orientée objets

➢ Les diagrammes de structure / statiques :

• Diagramme des paquets : représentation des dépendances entre les paquets (un paquet étant
un conteneur logique permettant de regrouper des éléments dans le modèle UML).

• Diagramme de structure composite : représentation sous forme de boîte blanche des relations
entre composants d'une classe.

• Diagramme de profils : spécialisation et personnalisation pour un domaine particulier.

20
Introduction à la conception orientée objets

➢ Les diagrammes de comportement / dynamiques :

• Diagramme des cas d’utilisation : représentation des possibilités d'interaction entre le système
et les acteurs (intervenants extérieurs au système), c'est-à-dire de toutes les fonctionnalités
que doit fournir le système.

• Diagramme états-transitions : représentation sous forme de machine à états finis du

comportement du système ou de ses composants.

• Diagramme d'activité : représentation sous forme de flux ou d'enchaînement d'activités du

comportement du système ou de ses composants.

21
Introduction à la conception orientée objets

➢ Les diagrammes de comportement / dynamiques :

• Diagramme de séquence : représentation de façon séquentielle du déroulement des

traitements et des interactions entre les éléments du système et/ou de ses acteurs.

• Diagramme de communication/collaboration : représentation de façon simplifiée d'un

diagramme de séquence se concentrant sur les échanges de messages entre les objets.

• Diagramme global d'interaction : représentation des 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 : représentation des variations d'une donnée au fil du temps (UML 2.3).

22
Introduction à la conception orientée objets

➢ Les outils UML :

• Logiciels libres;
o ArgoUML
o Umbrello
o BoUML

• Logiciels propriétaires :
o EclipseUML
o StarUML
o Rational rose

23
 Plan
Chapitre 2. Diagramme de cas d’utilisation.
➢ Rôle et Objectifs

➢ Éléments des diagrammes de cas d'utilisation.

➢ Relations dans les diagrammes de cas d'utilisation

➢ Modélisation des besoins avec UML.

➢ TD (Étude des cas).

25
Diagramme de cas d’utilisation

➢ Rôle et Objectifs :

• Modéliser les besoins des utilisateurs/clients;

• Faire ressortir les acteurs et les fonctionnalités offertes par le système.

• Décrire le comportement d’un système du point de vue d’un utilisateur;

• Modéliser les aspects dynamiques d'un système;

26
Diagramme de cas d’utilisation

➢ Éléments des diagrammes de cas d'utilisation :

• Acteurs

• Cas d'utilisation

• Relations de dépendances, de généralisations et d'associations;

27
Diagramme de cas d’utilisation

➢ Éléments des diagrammes de cas d'utilisation :

• Acteurs :

o UML n’emploi pas le terme d’utilisateur mais d’acteur.

o Le terme acteur ne désigne pas seulement des utilisateurs humains mais également les
autres systèmes (machines, programmes, …)

o Un acteur représente un rôle joué par une personne externe, un processus ou une chose
qui interagit avec le système;

o Représentation :
<<acteur>>
Client
Client
28
Diagramme de cas d’utilisation

➢ Éléments des diagrammes de cas d'utilisation :

• Acteurs :

o Un acteur peut être une spécialisation d'un autre acteur déjà défini;
Acteur général
o Dans ce cas, on utilise la relation de généralisation/spécialisation (héritage)

o Exemple :
Client

Acteur spécialisé
Client fidèle
29
Diagramme de cas d’utilisation

➢ Éléments des diagrammes de cas d'utilisation :

• Les cas d’utilisation :

o Permettent de modéliser les attentes (besoins) des utilisateurs

o Représentent les fonctionnalités du système

o Suite d’événements, initiée par des acteurs, qui correspond à une utilisation du système.

o Représentation :
Nom du cas d’utilisation

30
Diagramme de cas d’utilisation

➢ Éléments des diagrammes de cas d'utilisation :

• Les relations de dépendances, de généralisations et d'associations: il est important de

restructurer l'ensemble des cas d'utilisation afin de rechercher les :

o Comportements partagés

o Cas particuliers, exceptions, variantes

o Généralisations/spécialisations.

31
Diagramme de cas d’utilisation

➢ Relations dans les diagrammes de cas d'utilisation :

• UML définit trois types de relations standardisées entre cas d'utilisation :

▪ Une relation d'inclusion, formalisée par la dépendance «include»

▪ Une relation d'extension, formalisée par la dépendance «extend»

▪ Une relation d'héritage

32
Diagramme de cas d’utilisation

➢ Relations dans les diagrammes de cas d'utilisation :

• La relation d'inclusion «include» :

o A inclut B : le cas A inclut obligatoirement le comportement définit par le cas B, cela permet
de factoriser des fonctionnalités partagées.

o Le cas d'utilisation pointé par la flèche (dans notre cas B) est une sous partie de l'autre cas
d'utilisation (A, dans notre exemple).
A
o Exemple : B

Consulter les notes

S’authentifier

33
Diagramme de cas d’utilisation

➢ Relations dans les diagrammes de cas d'utilisation :

• La relation d’extension «extend» :

o Le cas d’utilisation (CU) source (B) ajoute, sous certaines conditions, son comportement
au CU destination (A)

o En d’autres termes, le CU (B) peut être appelé au cours de l’exécution du CU (A).

A
o Exemple :
B

Consulter les notes

Imprimer les relevés

34
Diagramme de cas d’utilisation

➢ Relations dans les diagrammes de cas d'utilisation :

• La relation d'héritage :

o Cette relation exprime une relation de spécialisation/généralisation au sens classique.

o A généralise B : le cas B est un cas particulier du cas A. A

o Exemple:

Payer la facture

Payer en ligne Payer à la livraison

35
Diagramme de cas d’utilisation

➢ Modélisation des besoins avec UML :

• Comment identifier les acteurs ?

o Pour trouver les acteurs d'un système, il faut identifier les différents rôles que vont devoir
jouer ses utilisateurs (exemple :administrateur, client, responsable clientèle,…).

o Identifier les autres systèmes avec lesquels le système va devoir communiquer comme :

▪ des machines (imprimantes, hardware d'un distributeur de billets…) ;

▪ des logiciels déjà disponibles à intégrer dans le projet ;

▪ des systèmes informatiques externes au système, mais qui interagissent avec lui, etc.

36
Diagramme de cas d’utilisation

➢ Modélisation des besoins avec UML :

• Comment recenser les cas d'utilisation ?

o Pour identifier les cas d'utilisation, il faut se placer du point de vue de chaque acteur et
déterminer comment et surtout pourquoi il se sert du système.

o Il faut éviter les redondances et limiter le nombre de cas avec un bon niveau d'abstraction.

o Nommez les cas d'utilisation avec un verbe à l'infinitif suivi d'un complément en vous
plaçant du point de vue de l'acteur et non pas de celui du système.

o Par exemple, un distributeur de billets aura probablement un cas d'utilisation Retirer de

l'argent et non pas Distribuer de l'argent.

37
Diagramme de cas d’utilisation

➢ TD (Étude des cas) :

❑ Exercice 1:

L'authentification d'une personne dans un système se fait par un login correct et un mot de passe
correct.

Q1 - Modélisez le cas d’utilisation de « s'Authentifier »?

Q2 - Modifier le modèle précédent pour prendre en compte la saisie du nom et du mot de passe;

Q3- Après la saisie du mot de passe, on peut saisir un code supplémentaire qui n'est pas
obligatoire. Modifier le modèle précédent.

38
Diagramme de cas d’utilisation

➢ TD (Étude des cas) :

❑ Exercice 1

39
Diagramme de cas d’utilisation

➢ TD (Étude des cas) :

❑ Exercice 2:

Dans un guichet automatique bancaire, un client peut retirer de l'argent s'il possède
suffisamment de fond. Il peut aussi consulter son compte ou payer ses factures. S'il retire de
l'argent ou s'il paye ses facture il est possible de consulter son compte.

Q1 – Identifier les acteurs.

Q2 – Tracer le diagramme de cas d’utilisation.

40
Diagramme de cas d’utilisation

➢ TD (Étude des cas) :

❑ Exercice 2

41
Diagramme de cas d’utilisation

➢ TD (Étude des cas) :

❑ Exercice 3:

On souhaite gérer la réservation des salles de cours et les matériaux pédagogiques (ordinateur
portable et/ou Vidéo projecteur) dans une école privée. Dans cette école on peut trouver des
enseignant et des étudiants, la réservation peut se faire uniquement par des enseignants selon
la disponibilité de la salle ou du matériel. L'école affiche un planning des salles qui peut être
consulté par les enseignants et les étudiants. Le récapitulatif horaire par enseignant, édité par
un professeur responsable, n'est consulté que par les professeurs.

Q – Modélisez cette situation par un diagramme de cas d'utilisation

42
Diagramme de cas d’utilisation

➢ TD (Étude des cas) :

❑ Exercice 3

43
Diagramme de cas d’utilisation

➢ TD (Étude des cas) :

❑ Exercice 4:

On souhaite qu’un client se connecte à un serveur (le système étudié) par des protocoles
comme FTP ou telnet...

▪ Le protocole FTP permet le transfert des fichiers, nécessite une identification.

▪ Le protocole telnet sert pour exécuter les commandes, nécessite une identification.

▪ HTTP pour le transfert des données (pages html).

▪ Mail permet de transférer les fichier, nécessite une identification

Q – Modélisez ce système par un diagramme de cas d'utilisation

44
Diagramme de cas d’utilisation

➢ TD (Étude des cas) :

❑ Exercice 4

45
Diagramme de cas d’utilisation

➢ TD (Étude des cas) :

❑ Exercice 4

46
 Plan
Chapitre 3. Diagramme de classes.
➢ Introduction

➢ Notions de base de l’approche objet

➢ Les classes.

➢ Relations entre classes

➢ TD (Étude des cas).

48
Diagramme de classes

➢ Le diagramme de classes :

• Considéré comme le plus important de la conception orientée objet;

• Permet de donner une vue statique du système et sa structure;

• Sert à modéliser les classes du système (organisation des données et des traitements) et leurs
relations.

49
Diagramme de classes

➢ Notions de base de l’approche objet :

• Classe : C’est un type de données abstrait qui précise des caractéristiques (attributs et
méthodes) communes à toute une famille d'objets et qui permet de créer (instancier) des objets
possédant ces caractéristiques.

50
Diagramme de classes

➢ Notions de base de l’approche objet :

• Objet : C’est une instance d'une classe. C'est une entité discrète dotée d'une identité, d'un état
et d'un comportement que l'on peut invoquer. Les objets sont des éléments individuels d'un
système en cours d'exécution.

51
Diagramme de classes

➢ Notions de base de l’approche objet :

• Abstraction : C’est le processus qui consiste à représenter des objets qui appartiennent au
monde réel dans le monde du programme que l’on écrit. Il consiste à extraire des variables
pertinentes attachées aux objets, et à gérer la complexité en masquant les détails inutiles.

52
Diagramme de classes

➢ Notions de base de l’approche objet :

• Encapsulation : C’est un mécanisme consistant à rassembler les données et les méthodes au

sein d’une structure en cachant l’implémentation de l’objet, c’est-à-dire en empêchant l’accès
aux données par un autre moyen que les services proposés.

53
Diagramme de classes

➢ Notions de base de l’approche objet :

• L'héritage : C’est un mécanisme de transmission des caractéristiques d'une classe (ses attributs
et méthodes) vers une sous-classe afin d'y ajouter des caractéristiques spécifiques ou d'en
adapter certaines. L'héritage évite la duplication et encourage la réutilisation.

54
Diagramme de classes

➢ Notions de base de l’approche objet :

• Polymorphisme : Représente la faculté d'une méthode à pouvoir s'appliquer à des objets de

classes différentes. Le polymorphisme augmente la généricité, et donc la qualité, du code.

55
Diagramme de classes

➢ Notions de base de l’approche objet :

• L’agrégation : Il s'agit d'une relation entre deux classes, spécifiant que les objets d'une classe
sont des composants de l'autre classe. Une relation d'agrégation permet donc de définir des
objets composés d'autres objets. L'agrégation permet donc d'assembler des objets de base, afin
de construire des objets plus complexes.

56
Diagramme de classes

➢ Notions de base de l’approche objet :

• La composition : Il s'agit d'une agrégation forte. L’existence de l'objet composant est liée a celle
de son composé.

 A "possède" B = Composition: B n'a aucune signification ou finalité dans le système sans A

 A "utilise" B = Agrégation: B existe indépendamment (conceptuellement) de A

Professeur
Faculté

Département

57
Diagramme de classes

➢ Les classes :

• Tout système orienté objet est organisé autour des classes;

• C’est la description formelle d'un ensemble d'objets ayant une

sémantique et des caractéristiques communes;

• Les caractéristiques d'un objet permettent de spécifier son état

Nom_de_la_classe
(attributs) et son comportement (opérations); - attribut_1 : Type1
- attribut_2 : Type2
• Les attributs correspondant aux données des objets de la classe. …
+ operation1() : Type2
• Les opérations correspondant à des méthodes (fonctions) associées aux + opération2() : Type1
+ opération3() : Void
objets de la classe.
…

58
Diagramme de classes

➢ Les classes :

• Les attributs :
o Un attribut est une propriété (caractéristique) d’un objet;
o Exemple : un client a un nom, un prénom, une adresse, …
o Un attribut doit (généralement) avoir une valeur;
o Syntaxe (entre accolades, les mentions optionnelles) : Nom_de_la_classe

{-,#,+,~} nomAttribut : TypeAttribut {[multiplicité]} {=valeurInitiale} - attribut_1 : Type1

- attribut_2 : Type2
o {-,#,+,~} : un symbole pour définir la visibilité de l’attribut : …
-privé, #protégé, +publique, ~paquetage. + operation1() : Type2
+ opération2() : Type1
o Multiplicité : définit le nombre de valeurs dans une collection (tableau)
+ opération3() : Void
…

59
Diagramme de classes

➢ Les classes :

• Les attributs : La visibilité

o - privé : limite la visibilité de l’attribut à la classe elle-même.
o # protégé : limite la visibilité de l’attribut à la classe elle-même et à ses sous-classes
o + publique : ne limite pas la visibilité de l’attribut
o ~ paquetage : limite la visibilité de l’attribut au package de la classe. Nom_de_la_classe
- attribut_1 : Type1
- attribut_2 : Type2
…
+ operation1() : Type2
+ opération2() : Type1
+ opération3() : Void
…

60
Diagramme de classes

➢ Les classes :

• Les attributs : Le Type

o Le type d’un attribut peut être :
❑ Un type de base : entier, réel, …
❑ Une expression complexe : tableaux, enregistrements, …
❑ Une classe Nom_de_la_classe

o Exemples d’attributs : - attribut_1 : Type1

- attribut_2 : Type2
❑ - couleur : Enum{Rouge, Vert, Bleu} …

❑ # b : Boolean = true + operation1() : Type2

+ opération2() : Type1
❑ - client : Personne. + opération3() : Void
…

61
Diagramme de classes

➢ Les classes :

• Les attributs : Cas particuliers

o Attribut dérivé : calculé à partir d'autres attributs, il est précédé d’un /
▪ - largeur : Réel
▪ - longueur : Réel
▪ - /surface : Réel Nom_de_la_classe
o Attribut de classe (static en Java ou en C++) : un attribut qui garde une - attribut_1 : Type1
valeur unique et partagée par toutes les instances de la classe. - attribut_2 : Type2
▪ - distance : Réel …

▪ - distanceMax : Réel + operation1() : Type2

+ opération2() : Type1
+ opération3() : Void
…

62
Diagramme de classes

➢ Les classes :

• Les opérations :
o Un service offert par la classe;
o Une fonction ou une transformation qui peut être appliquée aux
objets d’une classe;
o Permet de décrire le comportement d’un objet. Nom_de_la_classe
o Syntaxe (entre accolades, les mentions optionnelles) : - attribut_1 : Type1
- attribut_2 : Type2
{-,#,+,~} nomOpération ({LISTE_PARAMS}) {:TypeRetour}
…
o LISTE_PARAMS : les paramètres séparés par des virgules. + operation1() : Type2
+ opération2() : Type1
o Chaque paramètre s’écrit comme suit :
+ opération3()
nomParamètre : TypeParamètre{=valeur_initiale} …

63
Diagramme de classes

➢ Les classes :

• Les opérations : Cas particuliers

o méthode abstraite : Une méthode est dite abstraite lorsqu'on connaît son entête, mais pas la
manière dont elle peut être réalisée (on connaît sa déclaration, mais pas sa définition).
o méthode de classe : ne peut manipuler que des attributs de classe et ses propres
paramètres. Cette méthode n'a pas accès aux attributs des instances de la classe. L'accès à
une méthode de classe ne nécessite pas l'existence d'une instance de cette classe.
- opération1() : Réel Nom_de_la_classe
- attribut_1 : Type1
- attribut_2 : Type2
…
+ operation1() : Type2
+ opération2() : Type1
+ opération3()
… 64
Diagramme de classes

➢ Les classes : Classe abstraite

• Une classe abstraite est toujours héritée, on ne peut pas l’instancier. En effet sa fonction étant de
généraliser, elle n'a de sens que si des classes en héritent.

• Une classe est dite abstraite lorsqu'elle définit au moins une méthode abstraite ou lorsqu'une
classe parent contient une méthode abstraite non encore réalisée.

• On note les classes abstraites en italique.

65
Diagramme de classes

➢ Les relations entre classes :

• Associations :

▪ Relation existant entre une, deux ou plusieurs classes.

▪ Une association porte un nom (signification)

▪ Représentée par une ligne rectiligne

▪ Une association fonctionne (généralement) dans les 2 sens (bidirectionnelle)

66
Diagramme de classes

➢ Les relations entre classes :

• Associations :

▪ Nom : Décrit la nature (signification) de l’association

▪ Sens de lecture : Montre la direction de lecture de l’association

▪ Rôle d’une association : Décrit le rôle d’une classe dans une association

67
Diagramme de classes

➢ Les relations entre classes :

• Associations :

▪ Multiplicité (Cardinalités) : nombre de participations d’une classe dans une association,

indiquée à chaque extrémité d’une association sous la forme min..max

▪ min, max = 0, 1, *

68
Diagramme de classes

➢ Les relations entre classes :

• Associations :
▪ Notation abrégée des multiplicités :
1 => 1..1 (exactement 1)
* => 0..* (0 ou plusieurs)
n => n .. n (exactement n)
1..* => 1 ou plusieurs (1 ou plus)
0..1 => 0 ou 1 (au plus un)
1..100 => entre 1 et 100
2,4,5 => 2, 4 ou 5

69
Diagramme de classes

➢ Les relations entre classes :

• Associations :

Degré d’une association = nombre de classes participantes

▪ Association unaire (réflexive) : relie 2 instances d'une classe
▪ association binaire : relie 2 classes
▪ association ternaire : relie 3 classes
▪ association n-aire : relie n classes

70
Diagramme de classes

➢ Les relations entre classes :

• Classe-Association :

▪ Une association peut avoir des attributs = classe-association

71
Diagramme de classes

➢ Les relations entre classes :

• Classe-Association :

▪ Les classes-association sont utiles quand il y a des attributs qui sont pertinents à
l’association, mais à aucune des classes impliquées.

Personne Entreprise
1..*
0..1

Emploi
- période : int
- salaire : float

72
Diagramme de classes

➢ Les relations entre classes :

• Agrégation :

Type particulier d’association dans laquelle :

▪ Deux classes : Classe agrégat (composé), classes agrégée (composant)

▪ Entre les deux, il existe une relation de type « est composé de ».

Agrégat Agrégée

73
Diagramme de classes

➢ Les relations entre classes :

• Agrégation :

Type particulier d’association dans laquelle :

▪ Les parties (les composants) sont séparables de L’agrégat (le tout).

▪ La suppression d’une équipe n’implique pas la suppression des personnes qui la composent.

74
Diagramme de classes

➢ Les relations entre classes :

• Composition :

▪ C’est un cas particulier d’une agrégation dans lequel la vie des composants (élément) est liée à
celle de l’agrégat (composé) : si l’agrégat est détruit / déplacé, ses composants le sont aussi.

▪ D’un autre côté, et contrairement à l’agrégation, une instance de composant ne peut être liée
qu’a un seul agrégat.

▪ La composition se représente par un losange noir (plein).

Professeur
Faculté

Département
75
Diagramme de classes

➢ Les relations entre classes :

• Généralisation / Spécialisation (Héritage) :

▪ L’héritage est la relation entre une classe et une ou plusieurs de ses versions raffinées.

▪ On appelle la classe de base la super-classe et les autres classes les sous-classes.

▪ C’est une relation de type « est un » ou « est une sorte de ».

▪ La notation utilisée pour l’héritage est le triangle

76
Diagramme de classes

➢ Les relations entre classes :

• Généralisation / Spécialisation (Héritage) :

▪ Généraliser = mettre en facteur des classes  « super-classe »
▪ Spécialiser = décrire de nouveaux détails  « sous-classes »

▪ Une sous-classe hérite des attributs et opérations de sa super-classe (classe mère), et peut
ajouter ses propres attributs et méthodes ou redéfinir le comportement d’une méthode.

77
Diagramme de classes

➢ Les relations entre classes :

• Généralisation / Spécialisation (Héritage) :

▪ Une classe peut hériter de plusieurs super-classes = Héritage multiple

78
Diagramme de classes

➢ TD (Étude des cas) :

❑ Exercice 1 :

Dessiner les diagrammes de classes correspondant aux situations suivantes :

1. Un répertoire contient des fichiers

2. Une pièce contient des murs

3. Les modems et claviers sont des périphériques

4. Une transaction boursière est un achat ou une vente

5. Un compte bancaire peut appartenir à une personne physique ou morale

79
Diagramme de classes

➢ TD (Étude des cas) :

❑ Exercice 1

3 4

1 2

5
80
Diagramme de classes

➢ TD (Étude des cas) :

❑ Exercice 2 :

Chaque personne possède un nom, un prénom, le sexe et l'âge. On peut calculer les revenus et
les charges de chaque personne. Les attributs de la classe sont privés ; Les opérations de la classe
personne sont publiques.

Tracer le diagramme de classe correspondant.

81
Diagramme de classes

➢ TD (Étude des cas) :

❑ Exercice 2

Personne
- nom : String
- prénom : String
- sexe : String
- age : Integer
+ calculer_revenue() : Float
+ calculer_charge() : Float

82
Diagramme de classes

➢ TD (Étude des cas) :

❑ Exercice 3 :

Soit un système d'information qui concerne le suivi des personnels d'un ensemble d'agences
locales. Chaque agence se trouve dans une région, chaque région est pilotée par une direction
régionale. La direction régionale se charge d'un ensemble d'agences locales. Une direction
régionale est caractérisée par un code et un libellé.

Dessiner le diagramme de classes correspondant.

83
Diagramme de classes

➢ TD (Étude des cas) :

❑ Exercice 3

84
Diagramme de classes

➢ TD (Étude des cas) :

❑ Exercice 4 :

Soit un document composé d'un ou plusieurs feuillets. Le feuillet comporte des objets graphiques
et des texte. Les objets graphiques supportent des opérations de type : sélectionner, copier,
couper, coller et déplacer. On suppose les deux objets graphiques suivants: cercle et rectangle.

Dessiner le diagramme de classes correspondant.

85
Diagramme de classes

➢ TD (Étude des cas) :

❑ Exercice 4

86
 Plan
Chapitre 4. Diagramme d’objets.
➢ Introduction

➢ Les objets.

➢ Les liens.

➢ TD (Étude des cas).

88
Diagramme d’objets

➢ Le diagramme d’objets :

• Est une instance d’un diagramme de classes et représente les objets d’un système à un moment
donné, exprimant la structure statique;

• Utilisé principalement pour:

o Illustrer le diagramme de classes ( en montrant un exemple expliquant le modèle);

o Exprimer une exception (en modélisant des cas particuliers…);

o Préciser certains aspects du système (détails imperceptibles dans le diagramme de classes);

o Vérifier l’adéquation d’un diagramme de classes à différents cas possibles.

89
Diagramme d’objets

➢ Le diagramme d’objets (Exemple)

Entreprise Personne
0..1 1..* - nom : String
- nom : String
Diagramme de classes - prénom : String

IAM:Entreprise PDG:Personne
- nom = ‘‘Ahizoune’’
Diagramme d’objets - nom : ‘‘Maroc Télécom’’
- prénom = ‘‘Abdeslam’’

:Personne DRH:Personne
- nom = ‘‘X’’ - nom = ‘‘Hamani’’
- prénom = ‘‘Y’’ - prénom = ‘‘Naïma’’

90
Diagramme d’objets

➢ Le diagramme d’objets :

• Composé d’objets (instances des classes) et de liens (instances des relations)

• La notation des diagrammes d’objets est dérivée de celle des diagrammes de classes;

IAM:Entreprise PDG:Personne
- nom = ‘‘Ahizoune’’
- nom : ‘‘Maroc Télécom’’
- prénom = ‘‘Abdeslam’’

:Personne DRH:Personne
- nom = ‘‘X’’ - nom = ‘‘Hamani’’
- prénom = ‘‘Y’’ - prénom = ‘‘Naïma’’

91
Diagramme d’objets

➢ Les objets :

• Représentation:
Nom de l'objet Nom de l'objet : Classe : Classe

• On peut faire apparaître des valeurs d'attributs dans un objet:

: Voiture
Couleur = ‘‘rouge’’

• L’état d’un objet est déterminé par les valeurs de ses attributs;

• Un groupe d’objets (instances d’une même classe) est représenté comme suit:

: Classe

92
Diagramme d’objets

➢ Les objets :

• Il est possible de nommer l’état dans lequel se trouve un objet:

: Télévision [allumée]

• Possibilité de modéliser les changements d’états des objets;

«devient»
: Télévision [allumée] : Télévision [éteinte]

93
Diagramme d’objets

➢ Les liens :

• Les objets sont reliés par des instances d’associations : les liens.

• Un lien représente une relation entre objets à un instant donné. : Produit

• Exemple 1 : : Client
Acheter * : Produit
Client * Produit : Client

: Produit
: Client

Diagramme de classes : Produit

: Client

Diagramme d’objets
94
Diagramme d’objets

➢ Les liens :

• Les objets sont reliés par des instances d’associations : les liens.

• Un lien représente une relation entre objets à un instant donné.

• Exemple 2 :

Passager
* : Personne
Bus Personne : Bus
1
Conducteur
: Personne
Diagramme de classes

Diagramme d’objets
95
Diagramme d’objets

➢ Les liens :

• Les objets sont reliés par des instances d’associations : les liens.

• Un lien représente une relation entre objets à un instant donné.

• Exemple 3 :
Professeur : Professeur
1..*
Salle 1..* 1..* Etudiant : Salle : Etudiant

Diagramme de classes Diagramme d’objets

96
Diagramme d’objets

➢ Les liens (Association réflexive)

• Une association entre objets de la même classe est dite réflexive;

Patron
Collaborateur jean-Luc: Personne pierre: Personne
Personne *

1
Patron
Patron
denis: Personne

Diagramme de classes Diagramme d’objets

97
Diagramme d’objets

➢ Les liens (Composition) : Objet Composite

Diagramme de classes

Représentations possibles en Diagramme d’objets

98
Diagramme d’objets

➢ TD (Étude des cas) :

❑ Exercice 1:

Un objet nommé b747 de classe Avion et en état « détresse » est en relation avec luna, une tour
de contrôle. Un ensemble d'autres avions anonymes dont l'état est « à terre » sont aussi liés à
luna. La tour de contrôle communique avec p123, une caserne de pompiers.

Question : Dessinez le diagramme d'objets correspondant à la situation décrite ci-dessus.

99
Diagramme d’objets

➢ TD (Étude des cas) :

❑ Exercice 1

b747 : Avion [détresse]

: Avion [à terre]

luna : Tour

p123 : Caserne

100
Diagramme d’objets

➢ TD (Étude des cas) :

❑ Exercice 2 :

En se basant sur le diagramme de classe ci-dessous, dessinez le diagramme d'objets

correspondant à votre situation dans cette séance.

Professeur
1..*
1..* 1..*
Salle Etudiant

101
Diagramme d’objets

➢ TD (Étude des cas) :

❑ Exercice 2

elAnsari : Professeur

sm1 : Salle smiS5 : Etudiant

102
 Plan
Chapitre 5. Diagramme de séquences.
➢ Diagramme de séquences : Définition et utilité

➢ Acteurs et Objets

➢ Ligne de vie

➢ Messages

➢ Structures de contrôle

➢ TD (Étude des cas).

104
Diagramme de séquences

➢ Diagramme de séquences?

• Un diagramme dynamique d’UML;

• Variante du diagramme de communication (collaboration en UML 1);

• Description de l’ordre des interactions entre les acteurs et les objets

qui composent le système selon un ordre chronologique.

• Le temps s’écoule selon une dimension verticale du haut en bas;

• Les objets sont organisés horizontalement;

• L’échange entre les différents éléments se fait moyennant des messages.

105
Diagramme de séquences

➢ Le diagramme de séquences: utilité ?

• Documentation des cas d’utilisation:

o Description des interactions en des termes proches de l’usager;

o Une interaction se traduit par un envoi de message entre objets;

o Les étiquettes des messages correspondent à des événements se produisant dans le système;

• Décrire la réalisation des cas d'utilisation sur le système décrit par le diagramme de classes.

• Représenter graphiquement la chronologie des échanges de messages avec le système ou au sein

du système.

106
Diagramme de séquences

➢ Le diagramme de séquences: utilité ?

107
Diagramme de séquences

➢ Le diagramme de séquences :

• Éléments de base du diagramme de séquence :

o Acteurs et Objets (instances des classes)

o Les lignes de vie

o Messages (cas d'utilisation, appels d’opération)

• La vie de chaque entité représentée verticalement;

• Échanges de messages représentés horizontalement

108
Diagramme de séquences

➢ Acteurs et Objets :

• Représenté comme suit:

• Le nom de l’objet est compose de son rôle (rôle ou nom) et/ou du nom de la classe instanciée;

• Le nom est souligné pour indiquer qu’il s’agit d’une instance.

109
Diagramme de séquences

➢ Ligne de vie :

• Représentée par une ligne verticale en dessous de l’objet.

• Elle représente la période de temps durant laquelle l’objet “existe”.

• Création d’un objet : un message pointe sur le symbole de l’objet.

• Destruction d’un objet : sa ligne de vie se termine par une croix en trait épais (×).

110
Diagramme de séquences

➢ Messages :

• Les objets communiquent en échangeant des messages représentés sous forme de flèches.

• La dimension verticale représente l’écoulement du temps.

• Les messages sont étiquetés par le nom de l’opération invoquée.

111
Diagramme de séquences

➢ Messages : Activation des objets

• Une période d’activité correspond au temps d’exécution d’une action par un objet.

• Représentation : bande verticale le long de la ligne de vie de l’objet:

112
Diagramme de séquences

➢ Messages : Synchrone et Asynchrone

• Message synchrone : Émetteur bloqué en attente du retour.

• Message asynchrone : Émetteur non bloqué, continue son exécution.

113
Diagramme de séquences

➢ Messages (Message réflexif)

• L’envoi de messages récursifs se représente par un dédoublement de la bande d’activation.

• L’objet apparaît alors comme s’il était actif plusieurs fois.

114
Diagramme de séquences

➢ Structures de contrôle : Alternative

• Principe : Condition à l'envoi d'un message

• Notation : Deux diagrammes ou Bloc d'alternative alt

115
Diagramme de séquences

➢ Structures de contrôle : Boucle

• Principe : Répéter un enchaînement de messages

• Notation : Note ou Bloc de boucle loop

116
Diagramme de séquences

➢ Structures de contrôle : Référence à un autre diagramme

117
Diagramme de séquences

➢ TD (Étude des cas) :

❑ Exercice 1

Proposez un diagramme de séquences détaillant le cas d’utilisation « s’authentifier ».

118
Diagramme de séquences

➢ TD (Étude des cas) :

❑ Exercice 1

119
Diagramme de séquences

➢ TD (Étude des cas) :

❑ Exercice 2

En se basant sur les diagrammes suivants, proposez un diagramme de séquences détaillant le

cas d’utilisation « Effectuer un virement personnel ».

120
Diagramme de séquences

➢ TD (Étude des cas) :

❑ Exercice 2

121
 Mini-Projets UML

1. Choix du projet :

▪ Application de gestion des réservations pour un hôtel.

▪ Système de gestion des locations pour une agence de location des voitures.

▪ Logiciel d’organisation des rendez-vous pour un médecin.

▪ Site Web pour la gestion des inscriptions en PFE pour les étudiants de la FPN.

▪ Votre PFE.

▪ Mini-Projet du module POO.

123
 Mini-Projets UML

2. Travail à faire :

▪ Donner la liste des acteurs en détaillant le rôle de chacun.

▪ Proposer le diagramme des cas d’utilisation avec une description de chaque cas.

▪ Élaborer le diagramme des classes pour ce système avec une description de chaque classe
(ses attributs et ses opérations).

▪ Générer le code Java correspondant à chaque classe.

▪ Donner des exemples de diagramme d’objets traitant les cas particuliers.

▪ Pour les cas d’utilisation principaux, proposer des diagrammes de séquence.

▪ Organiser le diagramme de classes dans un diagramme de paquetages.

124
 Plan
Chapitre 6. Diagramme de paquetages.
➢ Diagramme de paquetages : Définition et utilité

➢ Notion de paquetage

➢ Dépendances entre paquetages

➢ TD (Étude des cas).

126
Diagramme de paquetages

➢ Diagramme de paquetages?

• Lorsque nous sommes en présence d’un système de grande taille, il peut être intéressant de le
décomposer en plusieurs parties (appelées paquetage)

• Le diagramme de paquetages est un diagramme structurel (statique) d’UML qui représente les
paquetages (ou espaces de noms) composant un système, ainsi que les relations qui lient ces
différents paquetages.

127
Diagramme de paquetages

➢ Notion de paquetage

• Un paquetage est un regroupement de différents éléments d’un système (regroupement de

classes, diagrammes, fonctions, interfaces…).

• Cela permet de clarifier le modèle en l’organisant. Il est représenté par un dossier avec son
nom à l’intérieur.

128
Diagramme de paquetages

➢ Notion de paquetage

• Il est possible de représenter les éléments du système appartenant au paquetage :

▪ à l’intérieur de celui-ci :

▪ ou à l’extérieur

129
Diagramme de paquetages

➢ Notion de paquetage

• Pour faire appel à un élément d’un paquetage, nous indiquons le nom du paquetage
(espace de nommage) suivi de deux fois deux points (::) puis du nom de l’élément.

Personne::Client

Véhicule::Voiture::Roue

130
Diagramme de paquetages

➢ Notion de paquetage

• Les paquetages peuvent s’imbriquer (décomposition hiérarchique) mais pas se chevaucher.

• Un élément du système ne peut appartenir qu’à un et un seul paquetage.

• Chaque paquetage doit posséder un nom différent.

131
Diagramme de paquetages

➢ Dépendances entre paquetages

• Chaque éléments d’un paquetage est soit :

▪ Privé, c'est-à-dire encapsulé dans le paquetage et invisible à l’extérieur de celui-ci. Un

élément privé est désigné par un signe -

▪ Public, c'est-à-dire visible et accessible de l’extérieur du paquetage. Un élément public

est désigné par un signe +

• Par défaut, les éléments d’un paquetage sont publics.

132
Diagramme de paquetages

➢ Dépendances entre paquetages

• La relation de dépendance entre deux paquetages signifie qu’au moins un élément d’un
paquetage a besoin d’utiliser au moins un élément d’un autre paquetage.

133
Diagramme de paquetages

➢ Dépendances entre paquetages : «import»

• Correspond à l’importation par un paquetage B de tous les éléments publics d’un paquetage A.
Ces éléments :

▪ auront la visibilité « public » dans le paquetage B (et seraient donc aussi transmis à un
paquetage C qui ferait une importation du paquetage B).

▪ seront accessibles au paquetage B sans avoir à utiliser explicitement le nom du paquetage A.

134
Diagramme de paquetages

➢ Dépendances entre paquetages : «import»

• Ce type de dépendance est représenté par une flèche pointillée muni du stéréotype «import».

• Le paquetage B importe Classe1 et Classe2 (pas Classe3 qui a une visibilité de type privée).

• Classe1 et Classe2 ont une visibilité de type public dans paquetage B.

• Le paquetage C importe Classe1, Classe2 et Classe4

135
Diagramme de paquetages

➢ Dépendances entre paquetages : «access»

• Correspond à l’accès par un paquetage B à tous les éléments publics d’un paquetage A.

• Ces éléments auront la visibilité privé dans le paquetage B, ils ne peuvent donc pas être transmis
à un paquetage C qui ferait une importation ou un accès au paquetage B (pas de transitivité).

• Ce type de dépendance est représenté par une flèche pointillée muni du stéréotype «access»

136
Diagramme de paquetages

➢ Dépendances entre paquetages : «access»

• Le paquetage B a accès à Classe1 et Classe2 (pas à Classe3 qui a une visibilité de type privée).

• Classe1 et Classe2 ont une visibilité de type privé dans paquetage B.

• Le paquetage C a accès à Classe4 (pas à Classe1 et Classe2 qui ont une visibilité de type privée
dans le paquetage B).

137
Diagramme de paquetages

➢ Dépendances entre paquetages : «merge»

• Correspond à la fusion de 2 paquetages en un seul.

• La dépendance de type «merge» est représentée par une flèche pointillée muni du stéréotype
«merge»

138
Diagramme de paquetages

➢ Dépendances entre paquetages : «merge»

• Le paquetage A est fusionné dans le paquetage B;

• Le paquetage A n’est pas modifié alors que le paquetage B est écrasé pour accueillir la fusion
des 2 paquetages.

139
Diagramme de paquetages

➢ TD (Étude des cas) :

❑ Exercice :

Organiser le diagramme suivant en

diagramme de paquetages.

140
Diagramme de paquetages

➢ TD (Étude des cas) :

❑ Exercice :

141
 Plan
Chapitre 7. Diagramme des composants.
➢ Introduction

➢ Notion de composant (component)

➢ Notion d’interface

➢ Les Ports

➢ Boite noire / Boite blanche

➢ TD (Étude des cas).

143
Diagramme des composants

➢ Introduction :

• Le diagramme des composants fait parti des diagrammes structuraux (statiques) d’UML;

• Il permet de représenter les différents éléments logiciels (composants) du système et leurs

dépendances (relations qui les lient).

144
Diagramme des composants

➢ Notion de composant (Component)

• En UML, un composant est un élément logiciel remplaçable et réutilisable qui fourni ou reçoit
un service bien précis. Il peut être vu comme une pièce détachée du logiciel.

• Les plugins, les drivers, les codecs, les bibliothèques sont aussi des composants.

• Il existe plusieurs possibilités pour représenter un composant;

145
Diagramme des composants

➢ Notion de composant (Component)

• Les composants fournissent des services via des interfaces.

• Un composant peut être remplacé par n’importe quel autre composant compatible c'est-à-dire
ayant les mêmes interfaces.

• Un composant peut évoluer indépendamment des applications ou des autres composants qui
l’utilise à partir du moment ou les interfaces sont respectées.

146
Diagramme des composants

➢ Notion d’interface :

• En programmation orientée objet, une interface est un ensemble de signatures de méthodes

publiques d'un objet.

• Il s'agit donc d'un ensemble de méthodes accessibles depuis l'extérieur d'une classe, par
lesquelles on peut modifier un objet, ou plus généralement communiquer avec lui.

147
Diagramme des composants

➢ Notion d’interface :
public class CompteBancaire implements Compte {
• Exemple :
private final String numero;
private int balance;
public interface Compte { public CompteBancaire(String numero) { [Link] = numero; }
@Override
void deposer(int montant); public void deposer(int montant) { [Link] += montant; }
@Override
int retirer(int montant); public int retirer(int montant) throws OperationInterrompueException {
if (balance < montant) {
int getBalance(); throw new OperationInterrompueException();
}
} return [Link] -= montant;
}
@Override
public int getBalance() { return [Link]; }

148
Diagramme des composants

➢ Notion d’interface :

• Il existe deux types d’interface dans un diagramme des composants:

▪ Les interfaces requises : Ce sont des interfaces qui fournissent un service au composant et
dont il a besoin pour fonctionner.

▪ Les interfaces fournies : Ce sont des interfaces par lesquels le composant fourni lui-même
un service.

149
Diagramme des composants

➢ Notion d’interface :

• Il existe plusieurs possibilités pour représenter les interfaces :

▪ Intégrées dans la représentation du composant;

150
Diagramme des composants

➢ Notion d’interface :

• Il existe plusieurs possibilités pour représenter les interfaces :

▪ Dans un classeur séparé du composant dans lequel sont listés les différents services;

151
Diagramme des composants

➢ Notion d’interface :

• Il existe plusieurs possibilités pour représenter les interfaces :

▪ Avec des connecteurs d’assemblage;

152
Diagramme des composants

➢ Notion d’interface :

• Exemple : Transfert de données par Internet.

153
Diagramme des composants

➢ Notion d’interface :

• Exemple : Transfert de données par Internet.

154
Diagramme des composants

➢ Les Ports :

• Le port est le point de connexion entre le composant et son environnement.

• Nous le représentons par un petit carré à la périphérie du composant.

155
Diagramme des composants

➢ Boite noire / Boite blanche :

• Un composant peut être vu de 2 manières :

▪ Comme une boite noire dont nous ne connaissons pas le contenu et auquel nous accédons
via les interfaces qui sont la seule partie visible.

156
Diagramme des composants

➢ Boite noire / Boite blanche :

• Un composant peut être vu de 2 manières :

▪ Comme une boite blanche en spécifiant les objets qui constituent le composant et en
indiquant leurs relations.

157
Diagramme des composants

➢ TD (Étude des cas) :

❑ Exercice 1 :

Le composant [Link] dépend de l'interface ImageObserver du composant [Link].

Représentez le diagramme de composants.

158
Diagramme des composants

➢ TD (Étude des cas) :

❑ Exercice 1 :

[Link] [Link]
ImageObserver

159
Diagramme des composants

➢ TD (Étude des cas) :

❑ Exercice 2 : Proposez un diagramme des composants pour cette situation.

▪ Un logiciel de messagerie repose sur 3 modules : Le module ‘gestion des emails’ est le centre de
contrôle qui interagit avec l’utilisateur et les autres modules via des interfaces et ports de service. Les
autres modules sont ‘envoi des e-mails’ et ‘réception des e-mails’, liés au premier via des interfaces.

▪ L’interface « Récupérer les e-mails », du module ‘réception des e-mails’, offre des fonctionnalités et les
données nécessaires au système pour accéder à la liste des e-mails.

▪ L’interface « Envoyer des e-mails », du module principal, offre des fonctionnalités et les données
nécessaires au module ‘envoi des e-mails’ pour son fonctionnement.

▪ L’utilisateur dispose d’une interface et d’un port de gestion pour l’administration du système.
160
Diagramme des composants

➢ TD (Étude des cas) :

❑ Exercice 2 : Administration
Utilisateur

Réception des e-mails

Gestion des e-mails

Envoi des e-mails

161
 Plan
Chapitre 8. Diagramme d’états-transitions.
➢ Introduction

➢ Notion d’ État

➢ Les événements

➢ Les actions et activités

➢ Dynamique d’un état

➢ États particuliers :
▪ État composite
▪ État orthogonal
▪ État historique
➢ TD (Étude des cas). 163
Diagramme d’états-transitions

➢ Introduction :

• Le diagramme états-transitions (State Machine Diagram) fait parti des diagrammes

comportementaux.

• Il représente les différents états (situations) dans lesquels peut se trouver l’entité,
ainsi que la façon dont elle passe d’un état à l’autre en réponse à des événements.

• Son rôle, est de décrire le fonctionnement d’une entité (objet, composant, logiciel…) ayant un
comportement séquentiel.

164
Diagramme d’états-transitions

➢ Notion d’État :

• Une situation stable qui possède une certaine durée pendant laquelle un objet exécute une
activité ou attend un événement.

• Types d’états :

▪ État initial : Initialisation du système / exécution du constructeur de l'objet.

▪ État final : Fin de vie du système / destruction de l'objet.

▪ États intermédiaires : Étapes de la vie du système / de l’objet.

État État avec événements
event1 [cond1] / action1
event2 [cond2] / action2

165
Diagramme d’états-transitions

➢ Les événements :

• Un événement est un fait instantané qui déclenche le changement d'état, qui fait donc passer
un objet d’un état à un autre état.

• Un événement se produit à un instant précis et il n’a pas de durée.

• Quand un événement est reçu, une transition peut être déclenchée et changer l’état de l'objet.

166
Diagramme d’états-transitions

➢ Les événements : 4 Types

• Signal : Réception d’un message asynchrone.

• Appel : Appel d’opération du diagramme de classes…

• Changement : à la satisfaction d’une condition évaluée continuellement jusqu’à ce qu’elle soit vraie.
when(cond)

• Temporel :

• Date absolue : when(date = date)

• Date relative : after(durée)

167
Diagramme d’états-transitions

➢ Les actions et activités :

• Réaction du système à un événement.

• Une action consiste à envoyer un signal, à faire appel à une méthode, à affecter une valeur à
un attribut...

• Une activité est une série d’actions.

168
Diagramme d’états-transitions

➢ Dynamique d’un état:

État avec événements
• Événements internes à l'état (sans changement d'état) : event
event1 [cond1] / action1
event2 [cond2] / action2

• Événements externes à l'état (changement d'état) : transition

▪ Transition vers l'état : evt-in
▪ Transition depuis l'état : evt-out
▪ Transition depuis l'état vers lui-même : evt-self

evt-self [cond. self] / act. self

evt-in [cond. in] / act. in État avec événements evt-out [cond. out] / act. out

event1 [cond1] / action1

event2 [cond2] / action2
169
Diagramme d’états-transitions

➢ États particuliers :

• État composite : État regroupant un ensemble d'états.

➢ Objectifs : structurer les comportements complexes, et factoriser les actions.

170
Diagramme d’états-transitions

➢ États particuliers :

• État composite : État regroupant un ensemble d'états.

➢ Objectifs : structurer les comportements complexes, et factoriser les actions.

171
Diagramme d’états-transitions

➢ États particuliers :

• État orthogonal : État composite dans lequel plusieurs états sont actifs simultanément.

➢ Objectifs : Structurer les comportements complexes, et factoriser les actions.

172
Diagramme d’états-transitions

➢ États particuliers :

• État historique : Pseudoétat qui mémorise le dernier sous-état actif d'un état composite.

• Permet de reprendre l’activité à l’endroit ou il s'était interrompu lors de la précédente

activation de l’état composite.

Etat historique plat : reprendre au début du sous-état du plus haut niveau dans lequel
H
nous nous étions arrêté.

H* Etat historique profond : reprendre au début du sous état dans lequel nous nous étions
arrêté, quelque soit son niveau d’imbrication.

173
Diagramme d’états-transitions

➢ États particuliers :

• État historique : Pseudoétat qui mémorise le dernier sous-état actif d'un état composite.

174
Diagramme d’états-transitions

❑ Exercice 1 :
On considère une boîte de vitesses automatique de voiture. La boîte au démarrage est au
point mort. La marche arrière ainsi que la position parking peuvent être enclenchées à partir
du point mort. La première marche avant peut également être enclenchée à partir du point
mort. En revanche, les autres marches avant, la seconde et la troisième, sont enclenchées en
séquence: 1-2-3 pour une accélération, et 3-2-1 pour une décélération. Seules la marche
arrière, la position parking et la première marche avant peuvent être ramenées directement
au point mort.

Préparez un diagramme d’états-transitions pour cette boîte.

175
Diagramme d’états-transitions

❑ Exercice 1

176
Diagramme d’états-transitions

❑ Exercice 2 :
Une montre digitale simple possède deux boutons, que l’on nommera A et B, pour la mettre à
l’heure. La montre a deux modes d’opérations, affichage de l’heure et mise à l’heure. En mode
d’affichage, les heures et les minutes sont affichées, séparées par un signe « deux points »
intermittent. Le mode de mise à l’heure a deux sous-modes, heures et minutes. Le bouton A
s’utilise pour les modes. A chaque fois que l’on appuie dessus, le mode change suivant la séquence:
affichage, configurer heures, configurer minutes, affichage, etc. Dans une sous-mode, le bouton B
s’emploie pour avancer les heures ou les minutes à chaque fois que l’on appuie dessus. Les boutons
doivent être relâchés avant de produire un autre événement.

Préparez un diagramme d’états de la montre.

177
Diagramme d’états-transitions

❑ Exercice 2

Réglage
A [!B]
Affichage Réglage Heures
do / Afficher Heures : Minutes A [!B] B [!A] / Heures++

A [!B]
Réglage Minutes
B [!A] / Minutes++

178
 Plan
Chapitre 9. Diagramme d’activités.
➢ Introduction

➢ Les actions

➢ Les activités

➢ Les transitions

➢ Les nœuds :
▪ Nœud d’action
▪ Nœud d’objet
▪ Nœud de contrôle
➢ Les partitions / couloirs d’activités :

➢ TD (Étude des cas). 180

Diagramme d’activités

➢ Introduction :

• L’un des diagrammes comportementaux, modélisant les aspects dynamiques du système.

• Permet de décrire le flux de travail d'un point de départ à un point d'arrivée en détaillant les
chemins de décision existant dans la progression des événements contenus dans l'activité.

• Représentation des opérations d’un processus et leurs conséquences sur les objets.

• Peut être utilisée pour décrire le déroulement d'un cas d'utilisation ou d'une méthode.

181
Diagramme d’activités

➢ Introduction :

• Variante du diagramme d’états-transitions.

182
Diagramme d’activités

➢ Les actions :

• Une action est le plus petit traitement qui puisse être exprimé en UML.

• Les actions sont des étapes discrètes à partir desquelles se construisent les comportements.

• La notion d'action est à rapprocher de la notion d'instruction d'un langage de programmation.

• Une action peut être, par exemple :

▪ affectation de valeur à un attribut ;
▪ création d'un objet ;
▪ calcul arithmétique simple…

183
Diagramme d’activités

➢ Les activités :

• Une activité définit un comportement décrit par un séquencement organisé d'unités dont les
éléments simples sont les actions.

• Le flot d'exécution est modélisé par des nœuds reliés par des arcs (transitions).

• Une activité est un traitement complexe et décomposable en actions. Elle peut être interrompue
par un événement.

• Une action est un traitement simple et non décomposable. Elle ne peut pas être interrompue.

184
Diagramme d’activités

➢ Les transitions :

• La transition est le passage d'une activité vers une autre.

• Elles sont déclenchées dès que l'activité source est terminée et provoquent automatiquement et
immédiatement le début de la prochaine activité à déclencher (l'activité cible).

• Les transitions spécifient l'enchaînement des traitements et définissent le flot de contrôle.

• Graphiquement les transitions sont représentées par des flèches interconnectant les activités.

Insérer carte

transition
Saisir code

185
Diagramme d’activités

➢ Les nœuds :

• Eléments graphiques du diagrammes d’activités.

• Il existe trois familles de nœuds dans un diagramme d’activités :

▪ Nœud d’exécution (d’action) ;
▪ Nœud d’objet ;
▪ Nœud de contrôle ;

186
Diagramme d’activités

➢ Les nœuds : Nœud d’action

• Un nœud d'action est un nœud d'activité exécutable qui constitue l'unité fondamentale de
fonctionnalité exécutable dans une activité.

• L'exécution d'une action représente une transformation ou un calcul quelconque dans le

système modélisé.

• Les actions sont généralement liées à des opérations qui sont directement invoquées.

Saisir code Insérer carte

187
Diagramme d’activités

➢ Les nœuds : Nœud d’objet

• Les nœuds d'objet permettent de définir un flot d'objets dans un diagramme d'activités.

• Chaque nœud représente l'existence d'objet généré/utilisé par une action.

• Graphiquement, un nœud d'objet est représenté par un rectangle dans lequel est mentionné le
type de l'objet. Ce nœud d'objet est relié à des activités sources et cibles par des arcs.

: Livre : Livre
Acheter livre Enregistrer emprunt
[disponible] [emprunté]
• Les actions sont généralement liées à des opérations qui sont directement invoquées.

• Le nom d'un état de l'objet peut être précisé entre crochets après ou sous le type de l'objet.

188
Diagramme d’activités

➢ Les nœuds : Nœuds de contrôle

• Un nœud abstrait utilisé pour coordonner les flots entre les nœuds d'une activité.

• Il existe plusieurs types de nœuds de contrôle :

▪ Nœud initial :
- Nœud à partir duquel le flot débute lorsque l’activité est invoquée.
- Une activité peut avoir plusieurs nœuds initiaux.
- Un nœud initial possède un arc sortant et pas d’arc entrant.

189
Diagramme d’activités

➢ Les nœuds : Nœuds de contrôle

• Un nœud abstrait utilisé pour coordonner les flots entre les nœuds d'une activité.

• Il existe plusieurs types de nœuds de contrôle :

▪ Nœud final :
- Nœud de fin d’activité : indique l’arrêt de toute l’activité.
- Nœud de fin de flot : indique la fin d’un flot d’exécution dans une activité. X
- Un nœud final possède un ou plusieurs arcs entrants et aucun arc sortant.

190
Diagramme d’activités

➢ Les nœuds : Nœuds de contrôle

• Un nœud abstrait utilisé pour coordonner les flots entre les nœuds d'une activité.

• Il existe plusieurs types de nœuds de contrôle :

▪ Nœud de décision :
- Permet de faire un choix entre plusieurs flots sortants.
- Possède un arc entrant et plusieurs arcs sortants.
- Ces derniers sont généralement accompagnés de conditions.

[cond1] [cond2]

191
Diagramme d’activités

➢ Les nœuds : Nœuds de contrôle

• Un nœud abstrait utilisé pour coordonner les flots entre les nœuds d'une activité.

• Il existe plusieurs types de nœuds de contrôle :

▪ Nœud de fusion :
- Rassemble plusieurs flots alternatifs entrants en un seul flot sortant.
- Possède plusieurs arcs entrants et un arc sortant.
- Utilisé pour sélectionner un flot parmi plusieurs (pas pour les synchroniser).

192
Diagramme d’activités

➢ Les nœuds : Nœuds de contrôle

• Un nœud abstrait utilisé pour coordonner les flots entre les nœuds d'une activité.

• Il existe plusieurs types de nœuds de contrôle :

▪ Nœud de débranchement :
- Sépare un flot en plusieurs flots concurrents.
- Possède un arc entrant et plusieurs arcs sortants.

193
Diagramme d’activités

➢ Les nœuds : Nœuds de contrôle

• Un nœud abstrait utilisé pour coordonner les flots entre les nœuds d'une activité.

• Il existe plusieurs types de nœuds de contrôle :

▪ Nœud d’union :
- Synchronise des flots multiples.
- Permet de représenter des traitements parallèles et leur synchronisation
- Possède plusieurs arcs entrants et un seul arc sortant.

194
Diagramme d’activités

➢ Les partitions / couloirs d’activités :

• Il est alors possible de diviser un diagramme d'activités en partitions ou couloirs d'activités.

• Chaque partition montre ainsi quelles actions sont exécutées par une classe ou une unité.

• Les nœuds d'activités appartiennent forcément à une et une seule partition.

• Les transitions peuvent, bien entendu, traverser les frontières des partitions.

195
Diagramme d’activités

➢ Les partitions / couloirs d’activités :

196
Diagramme d’activités

❑ Exercice 1:
Construire un diagramme d’activité pour modéliser le processus de commander d’un produit.

Le processus concerne les acteurs suivants:

▪ Client: qui commande un produit et qui paie la facture

▪ Caisse: qui encaisse l’argent du client

▪ Vente: qui s’occupe de traiter et de facturer la commande du client

▪ Entrepôt: qui est responsable de sortir les articles et d’expédier la commande.

197
Diagramme d’activités

❑ Exercice 1

:Caisse :Client :Vente :Entrepôt

Commander
Traiter
produit Sortir
commande
articles

Expédier
Facturer
Payer commande
client
Encaisser facture

198
 Série TD N°1

❑ EXERCICE 1:

1. Qu’est ce qu’un modèle ?

2. Pourquoi on doit modéliser un système avant son implémentation?

3. Quelle est la différence entre les diagrammes statiques et les diagrammes dynamiques?

4. Quel est l’intérêt d’un diagramme de cas d’utilisation?

5. Donnez un exemple de ce diagramme comportant des relations (include, extend, …)

200
 Série TD N°1

❑ EXERCICE 2:

▪ Transformer le code suivant en diagramme de classe

201
 Série TD N°1

❑ EXERCICE 3:

▪ En se basant sur le diagramme de classe précédent, proposer un diagramme d’objet

modélisant la situation suivante :

L’hôtel « perla », dont le gérant est Mr « alex », possède 35 chambres. L’une des chambres
est louée à Mr « bernard ».

202
 Série TD N°1

❑ EXERCICE 4:

On veut décrire le cas d’utilisation de l’authentification d’un utilisateur à un système informatique.

Cette authentification s’effectue de façon simple par la saisie d’un nom et d’un mot de passe.

▪ Représentez le cas d’utilisation de « S’authentifier » permettent à un utilisateur de se

connecter au système, sans spécifier les détails ;

▪ Introduire, dans le diagramme des cas d’utilisation, la saisie du nom et celle du mot de passe
ainsi que la vérification de ces données ;

▪ Ajouter la saisie d’un code complémentaire après celle du mot de passe. Ce code
complémentaire est optionnel pour les utilisateurs ayant besoin d’une sécurité accrue.

203
 Série TD N°1

❑ EXERCICE 5:

Considérons un réveille-matin simple :

▪ On peut mettre l’alarme « on » ou « off » ;

▪ Quand l’heure courante devient égale à l’heure d’alarme, le réveil sonne sans s’arrêter ;

▪ on peut interrompre la sonnerie.

Dessinez le diagramme d’états correspondant.

204
 Série TD N°2

❑ EXERCICE 1:

1. Qu’est-ce qu’un diagramme UML ?

2. Comment identifier les acteurs dans un diagramme de cas d’utilisation ?

3. C’est quoi la différence entre une composition et une agrégation ? Donner un exemple.

4. Expliquer la notion d’Encapsulation.

5. Quel est l’intérêt d’un diagramme de classe ?

6. Quel est le rapport entre le diagramme de séquence et les diagrammes de cas d’utilisation
et de classes ?

206
 Série TD N°2

❑ EXERCICE 2:

Le directeur d’une école a besoin d’une application pour gérer la réservation des salles de cours.
Dans cette école on peut trouver des enseignants, des étudiants, et des salles. La réservation peut
se faire uniquement par des enseignants selon la disponibilité de la salle. Le directeur de l’école
affiche un planning des salles qui peut être consulté par les enseignants et les étudiants. Le
récapitulatif horaire par enseignant, édité par le directeur, n'est consulté que par les enseignants
et le directeur.

1. Donner le diagramme de cas d’utilisation correspondant.

2. Élaborer un diagramme de classes pour ce système.

3. Proposer le diagramme de séquence pour le cas d’utilisation « Réserver une salle ».

207
 Série TD N°2

❑ EXERCICE 3:

Le processus des examens dans un établissement scolaire concerne les acteurs suivants :

▪ Professeur : propose l’énoncé de l’examen, corrige les copies des élèves, et fournit les notes à
l’administration.

▪ Administration : s’occupe de l’impression des examens et l’affichage des résultats.

▪ Elève : doit passer les examens et il peut consulter les notes.

Proposer un diagramme d’activité pour modéliser ce processus en utilisant les partitions.

208
 Étude de cas : SGB

Votre établissement vous demande de réaliser un système de gestion de bibliothèque (SGB).

1. Donner la liste des acteurs;

2. Proposer le diagramme des cas d’utilisations possibles;

3. Élaborer le diagramme des classes pour ce système;

4. Donner un exemple de diagramme d’objets;

5. Pour les cas d’utilisation principaux, proposer des diagrammes de séquence;

6. Organiser le diagramme de classes dans un diagramme de paquetages.

210