Vous êtes sur la page 1sur 122

Conception Orientée

Objet
Public cible: GINF1
A.U 2023-2024

Salma KSIBI
Docteur Ingénieur en Informatique
© S. Ksibi - COO 2023-2024
Plan du cours
Chapitre 1 : Méthodologies de conception

Chapitre 2 : Introduction à la conception OO

Chapitre 3 : Diagramme de cas d’utilisation

Chapitre 4 : Diagramme de classes

Chapitre 5 : Diagramme de séquences

© S. Ksibi - COO
Chapitre 6 : Diagramme d’état-transition
2022-2023 2
Méthodologies
de conception

Chapitre 1

© S. Ksibi - COO 2022-2023 3


Introduction
• Actuellement, l'informatique est au cœur de toutes les grandes entreprises.
• Le système informatique d'une entreprise est composé de matériels et de logiciels.
• Les investissements dans ce système d'information se répartissent généralement de la manière
suivante :
• 80 % de logiciel ;
• 20 % de matériel.
• Depuis quelques années, la fabrication du matériel est assurée par quelques fabricants seulement.
• Le matériel est relativement fiable.
• Le marché est standardisé

Les problèmes
© S. Ksibiliés
- COOà l'informatique
2022-2023 sont essentiellement des problèmes de logiciel. 4
Introduction

Le logiciel :
• Un logiciel ou une application est un ensemble de programmes, qui permet à un
ordinateur ou à un système informatique d'assurer une tâche ou une fonction en
particulier (exemple : logiciel de comptabilité, logiciel de gestion des prêts).
• Les logiciels, suivant leurs tailles, peuvent être développés par une seule personne,
une petite équipe, ou un ensemble d'équipes coordonnées.
• Le développement de grands logiciels par de grandes équipes pose d'importants
problèmes de conception et de coordination.
• Or, le développement d'un logiciel est une phase absolument cruciale qui
monopolise l'essentiel du coût d'un produit et conditionne sa réussite et sa
pérennité!

© S. Ksibi - COO 2022-2023 5


Introduction
La crise du logiciel :
• En 1995, une étude du Standish Group dressait un tableau accablant de la
conduite des projets informatiques. Reposant sur un échantillon
représentatif de 365 entreprises, totalisant 8380 applications, cette étude
établissait que :
• Succès : 16% seulement des projets étaient conformes aux prévisions initiales,
• Problématique : 53% avaient subi des dépassements en coût et avaient des défaut de
fonctionnalités,
• Échec : 31,% ont été purement abandonnés durant leur développement.

© S. Ksibi - COO 2022-2023 6


Introduction

La crise du logiciel :
Selon cette étude:
 Les logiciels n'étaient pas l'augmentation des coûts ;
• fiables,
les difficultés
 Il était incroyablement• difficile de maintenance
de réaliser et d'évolution
dans les délais prévus des; logiciels
la charges.
satisfaisant leurs cahiers• des non-fiabilité ;
• le non-respect des spécifications ;
• lelanon-respect
Le taux de succès décroît avec des délais.
taille des projets et la taille des entreprises.

L'importance d'une approche méthodologique s'est imposée à la suite


de la crise de l'industrie du logiciel
© S. Ksibi - COO 2022-2023
7
Introduction
Génie logiciel (Software Engineering) :
 Le développement de 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. Ainsi, une nouvelle discipline est née : le génie logiciel.

 Le génie logiciel:
 s'intéresse à la manière dont le code source d'un logiciel est spécifié puis
produit
 vise à optimiser le coût et le délai de développement du logiciel

 Qu'attend-on d'un logiciel ?


 Comment créer des logiciels de qualité ? 8

 Quels sont les critères de qualité ?

© S. Ksibi - COO 2022-2023


Introduction
Critères de qualité d'un logiciel
• Utilité (Adéquation entre le logiciel et les besoins des utilisateurs)
• Utilisabilité
• Fiabilité
• Interopérabilité (Interactions avec d'autres logiciels)
• Performance
• Portabilité
• Réutilisabilité
• Facilité de maintenance (Un logiciel ne s'use pas pourtant, la maintenance absorbe une très
grosse partie des efforts de développement)
9
© S. Ksibi - COO 2022-2023
Introduction

Poids de la maintenance

(Zeltovitz, De Marco)
10
© S. Ksibi - COO 2022-2023
Introduction

Cycle de Vie
• La qualité du processus de fabrication est garante de la qualité du produit.
• Pour obtenir un logiciel de qualité, il faut en maîtriser le processus d'élaboration.
• La vie d'un logiciel est composée de différentes étapes.
• La succession de ces étapes forme le cycle de vie du logiciel.
• Il faut contrôler la succession de ces différentes étapes.

11
© S. Ksibi - COO 2022-2023
Introduction

Cycle de Vie
• L’étude préalable
• L'analyse du besoin,
• La conception (Déterminer la façon dont le
logiciel fournit les différentes fonctionnalités
recherchées.)
• Le codage (l’implémentation),
• Test et validation (intégration),
• La maintenance

© S. Ksibi - COO 2022-2023 12


Modélisation et Conception

◗Concevoir : c’est se prêter à un exercice intellectuel permettant


de déterminer un modèle ou un prototype avant de procéder à
sa réalisation.
◗Concevoir un SI : c’est imaginer, créer et représenter de la
manière la plus sémantique possible le SI à travers des modèles .

© S. Ksibi - COO 2022-2023 13


Modélisation et Conception
Qu'est-ce qu'un modèle ?
• Un modèle est une représentation abstraite de la réalité qui exclut Réalité
certains détails du monde réel.
• Il permet de réduire la complexité d'un phénomène en éliminant les
détails qui n'influencent pas son comportement de manière
significative.
• Il reflète ce que le concepteur croit important pour la compréhension
et la prédiction du phénomène modélisé, les limites du phénomène
modélisé dépendent des objectifs du modèle.
◗Modèle : ensemble de règles et de concepts. Modélisarion
Lesconcepts fournissent le moyen de représenter les entités du
monde réel et les relations qui existent entre elles.
Les règles sont définies sur les concepts du modèle et régularisent
leurs utilisations. 14

© S. Ksibi - COO 2022-2023


Implantation
Modélisation et Conception

Pourquoi modéliser ?
• Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du
système. C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence.
• Un modèle est un langage commun, précis, qui est connu par tous les membres de l'équipe et il
est donc un vecteur privilégié pour communiquer. Cette communication est essentielle pour
aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la
maîtrise d'ouvrage et la maîtrise d'œuvre informatique) et précise d'un problème donné.
• Dans le domaine de l'ingénierie du logiciel, le modèle permet de mieux répartir les tâches et
d'automatiser certaines d'entre elles. C'est également un facteur de réduction des coûts et des
délais.
• Le modèle est enfin indispensable pour assurer un bon niveau de qualité et une maintenance
efficace. En effet, une fois mise en production, l'application va devoir être maintenue,
probablement par une autre équipe et, qui plus est, pas nécessairement de la même société que
celle ayant créé l'application.
• Le choix du modèle a donc une influence capitale sur les solutions obtenues.
© S. Ksibi - COO 2022-2023 15
Méthodes d'analyse et de conception

Les méthodes d'analyse et de conception fournissent une méthodologie et des notations standards qui
aident à concevoir des logiciels de qualité. Il existe différentes manières pour classer ces méthodes, dont :
• La distinction entre composition et décomposition :
• Elle met en opposition d'une part les méthodes ascendantes qui consistent à construire un logiciel par
composition à partir de modules existants et, d'autre part, les méthodes descendantes qui décomposent
récursivement le système jusqu'à arriver à des modules programmables simplement ;
• La distinction entre méthode fonctionnelle (dirigée par le traitement) et méthode orientée objet :
• Dans la stratégie fonctionnelle (également qualifiée de structurée) un système est vu comme un ensemble
hiérarchique d'unités en interaction, ayant chacune une fonction clairement définie. Les fonctions disposent
d'un état local, mais le système a un état partagé, qui est centralisé et accessible par l'ensemble des fonctions.
• Les stratégies orientées objet considèrent qu'un système est un ensemble d'objets interagissant. Chaque objet
dispose d'un ensemble d'attributs décrivant son état et l'état du système est décrit par l'état de l'ensemble.

© S. Ksibi - COO 2022-2023 16


Evolution des méthodes de conception
Méthodes de conception existantes

Années 70 : Années 80 : Années 90 :


Les approches Les approches Les approches
cartésiennes systématiques objet

© S. Ksibi - COO 2022-2023 17


Evolution des méthodes de conception des SI

◗Les méthodes fonctionnelles (70): reposer sur une décomposition des fonctions en sous
fonctions.
Ex : SADT, YOURDON.
◗Les méthodes systémiques(80): modéliser le système selon deux points de vue
complémentaires : la modélisation des données et la modélisation des traitements.
Ex : MERISE, AXIAL, Information Engineering, SSADM, REMORA.
◗Les méthodes orientées objets (90): décrire une grande partie de la dynamique du système
d’information comme un ensemble d’opérations attachées aux objets composant ce système.
Ex : OMT, OOM, HOOD.

© S. Ksibi - COO 2022-2023 18


Approches cartésiennes et systémiques

• Approches cartésiennes : basées sur l'analyse par les traitements:


résoudre un problème grâce à un cadre procédural. Ce cadre fixe les étapes
à respecter, leur enchaînement, ainsi que les entrées et les sorties
correspondant à chaque étape.
• Approches systémiques: basée sur l'analyse en structures de données :
étudier le problème à modéliser en mettant l'accent sur les relations entre
les éléments modélisés dans le logiciel. Le logiciel est avant tout
conceptualisé comme une composante du système d'organisation global de
l'entreprise. Sa conception commence par la définition du système et de ses
frontières.
19
© S. Ksibi - COO 2022-2023
Approche Objet

• La Conception Orientée Objet (COO) est la méthode qui conduit à des


architectures logicielles fondées sur les objets du système, plutôt que sur la
fonction qu'il est censé réaliser.
• En résumé, l'architecture du système est dictée par la structure du
problème.

© S. Ksibi - COO 2022-2023 20


De la programmation structurée à l'approche orientée objet
• Les méthodes fonctionnelles ou méthodes structurées trouvent leur origine dans les langages
procéduraux. Elles mettent en évidence les fonctions à assurer et proposent une approche
hiérarchique descendante et modulaire.
• L'approche fonctionnelle dissocie le problème de la représentation des données, du problème du
traitement de ces données.

• Sur la figure, les données du problème sont représentées sur la gauche. Des flèches transversales
matérialisent la manipulation de ces données par des sous-fonctions. 21

© S. Ksibi - COO 2022-2023


De la programmation structurée à l'approche orientée objet

• Limites de la programmation structurée :


• lorsque données et procédures doivent être partagées par plusieurs programmes
• lorsque les données évoluent
Programmation à objets

PROGRAMME PROGRAMME

Données Données Données


Opérations Opérations Opérations
© S. Ksibi - COO 2022-2023 22
De la programmation structurée à l'approche
orientée objet
• L'approche orientée objet
◗La modélisation objet consiste à créer une représentation informatique des éléments du
monde réel auxquels on s'intéresse, sans se préoccuper de l'implémentation. Il s'agit donc de
déterminer les objets présents et d'isoler leurs données et les fonctions qui les utilisent.
• L'approche considère le logiciel comme une collection d'objets dissociés, identifiés et
possédant des caractéristiques.
• Une caractéristique est soit un attribut (i.e. une donnée caractérisant l'état de l'objet), soit
une entité comportementale de l'objet (i.e. une fonction).
• La fonctionnalité du logiciel émerge alors de l'interaction entre les différents objets qui le
constituent. L'une des particularités de cette approche est qu'elle rapproche les données et
leurs traitements associés au sein d'un unique objet.
© S. Ksibi - COO 2022-2023 23
De la programmation structurée à l'approche
orientée objet

• L'identité : l'objet possède une identité, qui permet de le distinguer des autres objets,
indépendamment de son état. On construit généralement cette identité grâce à un
identifiant découlant naturellement du problème (par exemple un produit pourra être
repéré par un code, une voiture par un numéro de série, etc.) ;
• Les attributs: il s'agit des données caractérisant l'objet. Ce sont des variables stockant des
informations sur l'état de l'objet ;
• Les méthodes: les méthodes d'un objet caractérisent son comportement, c'est-à-dire
l'ensemble des actions (appelées opérations) que l'objet est à même de réaliser. Ces
opérations permettent de faire réagir l'objet aux sollicitations extérieures (ou d'agir sur les
autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs actions
peuvent dépendre des valeurs des attributs, ou bien les modifier.
© S. Ksibi - COO 2022-2023 24
De la programmation structurée à l'approche
orientée objet

• La difficulté de cette modélisation consiste à créer une représentation


abstraite, sous forme d'objets, d'entités ayant une existence matérielle
(chien, voiture, ampoule, personne…) ou bien virtuelle (client, temps…).
• La Conception Orientée Objet (COO) est la méthode qui conduit à des
architectures logicielles fondées sur les objets du système, plutôt que sur la
fonction qu'il est censé réaliser.

© S. Ksibi - COO 2022-2023 25


Introduction à
la conception
OO des SI

Chapitre 2

© S. Ksibi - COO 2022-2023 26


Méthodes de conception OO

◗La modélisation objet consiste à créer une représentation informatique


des éléments du monde réel auxquels on s'intéresse, sans se préoccuper de
l'implémentation. Il s'agit donc de déterminer les objets présents et d'isoler
leurs données et les fonctions qui les utilisent.
◗Plusieurs méthodes de conception orientée objets ont été proposées à
travers l’histoire. Parmi lesquelles nous citons les plus populaires :
◗La méthode OMT de Rumbaugh (Object Modeling Technique)
◗La méthode BOOCH'93 de Booch
◗La méthode OOSE de Jacobson (Object Oriented Software Engineering)
© S. Ksibi - COO 2022-2023 27
Méthodes de conception OO

◗Le nombre important de méthodes et de modèles proposés ne permet pas


de faire avancer la technologie objet.
◗Recherche d’un langage commun (ensemble de modèles) utilisable par
toutes les méthodes de conception orientées objet.
◗Ces modèles doivent être compatibles avec les techniques et les
plateformes de réalisation.
• Avènement du Langage de Modélisation Unifié UML
© S. Ksibi - COO 2022-2023 28
Présentation d’UML

◗UML (Unified Modeling Language), que l'on peut traduire par "langage de modélisation
unifié" : est une notation permettant de modéliser un système de façon standard.
◗Ce langage est né de la fusion de plusieurs méthodes existantes auparavant, et est devenu
la référence en terme de modélisation objet.
◗UML peut être associé à toute démarche de conception de SI : à n’importe quelle étape de
la démarche et avec différents environnements de programmation.
◗Ce n’est pas une méthode de conception mais un langage de modélisation.
◗Couvre le cycle de développement du logiciel de la spécification des besoins à
l’implémentation.
◗Est un support de communication. 29
© S. Ksibi - COO 2022-2023
Evolution d’ UML

UML 2.5.1 (2017) UML 2.4 (2011) UML 2.3 (2010)

UML 2.0 (2004)

UML 1.0 (1997)

UML0.9 (1996)

Méthodes unifiées (1995) OOSE

Booch (93) OMT Autres méthodes


30

+HOOD, OOD
© S. Ksibi - COO 2022-2023
Axes de modélisation d’UML

Statique Fonctionnel
• diagramme de classes
• diagramme d’objets • diagramme de cas d’utilisation

• diagramme de composants
• diagramme de déploiement
Dynamique
• diagramme de séquence
• diagramme de collaboration
• diagramme d’états-transitions
© S. Ksibi - COO 2022-2023 31
• diagramme d’activités
Axes de modélisation

◗Le mode de représentation fonctionnel s’appuie exclusivement sur :


◗Le diagramme de cas d’utilisation : Il est utilisé dans l’activité de
spécification des besoins. Ce diagramme représente les fonctions du
système du point de vue de l’utilisateur.

© S. Ksibi - COO 2022-2023 32


Axes de modélisation

◗Le mode de représentation statique ou structurel s’appuie essentiellement sur :


◗Le diagramme de classes représente le point central dans un développement
orienté objet. En analyse, il a pour objet de décrire la structure des entités
manipulées par les utilisateurs.
◗Le diagramme de composants représente les concepts de configuration
logicielle. Il s’agit de montrer comment s’agencent des composants tels que les
fichiers source, les packages de code ou les librairies.
◗Le diagramme de déploiement correspond à la fois à la structure du réseau
informatique qui prend en charge le système logiciel, et à la façon dont les
composants y sont installés.
33

© S. Ksibi - COO 2022-2023


Axes de modélisation

◗Le mode de représentation dynamique ou comportemental


• s’appuie sur :
◗Lediagramme d’activités : représentation des règles d’enchaînement des activités
dans le système.
◗Le diagramme d’états : représentation du cycle de vie commun aux objets d’une même
classe.
◗Le diagramme de séquence : représentation temporelle des objets et leurs interactions.
◗Le diagramme de collaboration : représentation simplifiée d'un diagramme de séquence
se concentrant sur les échanges de messages entre les objets.
34

© S. Ksibi - COO 2022-2023


Concepts importants de l'approche objet
UML

• Les entités du monde réel sont représentées à l’aide d’un concept unique:
L ’OBJET.
• Tout objet est défini conforment à un TYPE ABSTRAIT.

• Un TYPE ABSTRAIT est spécifié par :


• Une structure de données (ensemble de valeurs possibles)
• Un ensemble d’opérations (méthodes) applicables à ces valeurs.

35

© S. Ksibi - COO 2022-2023


Concepts importants de l'approche objet

APPLICATIONS CLASSIQUES :
DUALITE DONNEES – TRAITEMENTS

APPROCHEOBJETS,
OBJETTYPES,
: CLASSES • ETAT : Ensemble de valeurs d ’attributs = contenu
APPLICATION = ENSEMBLE D’OBJETS informationnel.
AYANT UN COMPORTEMENT ET
ECHANGEANT DES MESSAGES • IDENTIFIANT : Identifie de manière unique un
objet et n ’est ni modifiable ni réutilisable (interne
au système).
 ABSTRAIT
 CONCRET • COMPORTEMENT: Différents messages auxquels
OBJET  ETAT l ’objet peut réagir.
 IDENTITE

 COMPORTEMEN
T 36

© S. Ksibi - COO 2022-2023


Diagramme
des cas
d’utilisation

Chapitre 3

37

© S. Ksibi - COO 2022-2023


Définition
• Un diagramme de cas d’utilisation est utile pour :
Les utilisateurs pour exprimer les besoins
Les analystes pour comprendre le système
Les programmeurs pour réaliser le nouveau système
Les testeurs pour vérifier le nouveau système

© S. Ksibi - COO 2022-2023 38


Formalisme et représentation

•Un diagramme de cas d’utilisation contient principalement trois


concepts :
Le système,
les cas d’utilisation et
les acteurs.

© S. Ksibi - COO 2022-2023 39


Formalisme et représentation

Acteur

Retirer Argent

Cas d'utilisation
Client

Consulter Compte
Associations 40

© S. Ksibi - COO 2022-2023


Système
◗Le système peut être n’importe quel système, non seulement le système
logiciel.
◗Les frontières du système doivent être définies d’une façon claire et précise.

Système de gestion de stock

Gérer Article

Reponsable Stock

© S. Ksibi - COO 2022-2023 41


Cas d’utilisation

Définitions:
◗ Les cas d’utilisation décrivent, sous la forme d’actions et de réactions, le comportement d’un
système du point de vue d’un utilisateur.
◗ Un cas d’utilisation est une manière spécifique d’utiliser un système. C’est l’image d’une
fonctionnalité du système, déclenchée en réponse à la stimulation d’un acteur.
◗ Un cas d’utilisation est une unité cohérente représentant une fonctionnalité visible de
l’extérieur. Il modélise donc un service rendu par le système avec un déclenchement, un
déroulement et une fin, pour l’acteur qui l’initie.
© S. Ksibi - COO 2022-2023 42
Cas d’utilisation

◗ Un cas d’utilisation doit :

◗ Correspondre à un objectif de haut niveau

◗ Décrire l’interaction entre l’utilisateur et le système, et non les opérations que le


système doit réaliser.

◗ Couvrir l’ensemble des fonctions à réaliser afin d’atteindre les objectifs visés.

◗ N’inclure que les interactions avec le système.

© S. Ksibi - COO 2022-2023 43


Cas d’utilisation

◗Objectif et interaction ?
◗ Objectifs des utilisateurs : ce que les utilisateurs attendent du système
◗ Interactions avec le système : les mécanismes permettant de satisfaire ces objectifs.
◗Exemple : développement d’un outil de traitement de texte
◗ Objectif : définir un style du document
◗ Interactions : choisir les polices, choisir les tailles, choisir la mise en page, etc.
• Il s’agit donc de définir les objectifs, puis déterminer les interactions pour
atteindre les objectifs.

© S. Ksibi - COO 2022-2023 44


Cas d’utilisation

Représentation graphique :

Nom du cas
d'utilisation

Exemple :

Gérer Stock

© S. Ksibi - COO 2022-2023 45


Acteur

• Définition
◗L’acteur représente un rôle joué par une entité externe (personne ou
autre) qui interagit directement avec le système étudié et ce pour
échanger des informations ou changer l’état du système.
◗En réponse à l'action d'un acteur, le système fournit un service qui
correspond à son besoin.
◗L’acteur a un nom, qui le définit, ou qui précise son rôle dans la
transaction décrite.

© S. Ksibi - COO 2022-2023 46


Acteur
Représentation
graphique

nom acteur

Remarque: Il va falloir distinguer deux notions : acteur et utilisateur:


◗Plusieurs utilisateurs peuvent correspondre à un seul acteur.

◗Exemple: Différents caissiers jouent le même rôle dans le système.


◗Un utilisateur peut correspondre à plusieurs acteurs.
◗Exemple: Un utilisateur peut être en même temps un caissier et un gérant dans le
système.
© S. Ksibi - COO 2022-2023 47
Acteur

 Principal : utilise les fonctionnalités principales du système. Le cas d’utilisation rend ainsi un service
à cet acteur.
 Secondaire : effectue des tâches administratives ou de maintenance ou bien il est sollicité pour des
informations complémentaires.
 Matériel externe : autres que les machines où s’exécutent l’application, faisant partie du domaine
de l’application et nécessaire au fonctionnement du système.
 Autres systèmes : avec qui le système doit interagir.

Remarque:
◗Un cas d’utilisation a au plus un acteur principal, et un ensemble – éventuellement zéro – d’acteurs
secondaires.
◗Les acteurs secondaires sont généralement placés à droite des cas d’utilisation
© S. Ksibi - COO 2022-2023 48
Acteur

• Comment Identifier les acteurs du système :


◗Qui utilisera les fonctionnalités principales du système ?
◗Qui aura besoin du support du système pour réaliser ses tâches ?
◗Qui devra mettre à jour, administrer, assurer le fonctionnement du système ?
◗Avec quels autres systèmes le futur système interagit ?
◗Qui ou quoi a des intérêts sur les résultats du système ?

© S. Ksibi - COO 2022-2023 49


Acteur

Exemple d'acteurs

Accès à un
batiment

Gérer les
Personne groupes des
personnes
Administrateur

© S. Ksibi - COO 2022-2023 50


Acteur

Exemple d'acteurs

Retrait
Argent

Consulter
Guichetier compte
Système central

© S. Ksibi - COO 2022-2023 51


Relations dans les diagrammes de CU

• Association
◗L’association est une relation entre un acteur et un cas d’utilisation.
◗Un acteur déclenche un cas d’utilisation
• Représentation graphique

nom du cas d'utilisation

Nom acteur

© S. Ksibi - COO 2022-2023 52


Relations dans les diagrammes de CU

• Exemple

Retrait Agent

Guichetier

© S. Ksibi - COO 2022-2023 53


Exercice

Considérons une station-service de distribution d'essence. Les clients se servent de l'essence et le


pompiste remplit les cuves.
1. Le client se sert de l'essence de la façon suivante : il prend un pistolet accroché à une pompe et
appuie sur la gâchette pour prendre de l'essence. Qui est l'acteur du système ? Est-ce le client,
le pistolet ou la gâchette ?
2. Ahmed, dont le métier est pompiste, peut se servir de l'essence pour sa voiture. Pour modéliser
cette activité d’Ahmed, doit-on définir un nouvel acteur ? Comment modélise-t-on ça ?
3. Lorsque Ahmed vient avec son camion citerne pour remplir les réservoirs des pompes, est-il
considéré comme un nouvel acteur ? Comment modélise-t-on cela ?
4. Certains pompistes sont aussi qualifiés pour opérer des opérations de maintenance en plus des
opérations habituelles des pompistes telles que le remplissage des réservoirs. Ils sont donc
réparateurs en plus d'être pompistes. Comment modéliser cela ?
© S. Ksibi - COO 2022-2023 54
Relations dans les diagrammes de CU

• Relation d’inclusion
◗La relation d’inclusion est définie entre cas d’utilisation.
◗Elleindique qu’une instance du CU source contient aussi le comportement décrit par le CU
destination.
◗Elle a un caractère obligatoire.
◗Elle permet de :
Décomposer les comportements
Définir des comportements partageables entre plusieurs CU

© S. Ksibi - COO 2022-2023 55


Relations dans les diagrammes de CU

Représentation graphique

<<include>>
C a s d 'u t ilisa t io n 1 cas d'utilisation2

Exemple:
<<include>>

Virement Authentification

Personne

© S. Ksibi - COO 2022-2023 56


Relations dans les diagrammes de CU

• Relation d’extension
◗La relation d’extension définie entre cas d’utilisation indique qu’une instance du CU
source ajoute son comportement au CU destination.
◗Le comportement ajouté est inséré au niveau d’un point d’extension et il est défini dans
le CU destination.
◗La relation d’extension permet de modéliser des variantes de comportement d’un CU selon
les interactions des acteurs et l’environnement du système.
◗Une condition d’extension peut être spécifiée

© S. Ksibi - COO 2022-2023 57


Relations dans les diagrammes de CU

Représentation graphique

[Condition]
C a s d 'u t ilisa t io n 1 cas d'utilisation2
<<extends>>

Exemple

[ s i M on t an t > 5 0 0 ]

Retirer Montant Vérifier solde


<<extends>>

© S. Ksibi - COO 2022-2023 58


Relations dans les diagrammes de CU

Relation de généralisation (entre cas d’utilisation)


• Permet à un sous cas d’utilisation de spécialiser le comportement d’un cas d’utilisation de base
(qui peut être abstrait)
Représentation graphique Exemple

CU général Emprunter

UC UC Emprunter livre Emprunter Revue


spécialisé1 spécialisé2

© S. Ksibi - COO 2022-2023 59


Application : librairie en ligne
Développement d’un site web pour une librairie
◗L’objectif fondamental du futur site est de permettre aux internautes de rechercher des
ouvrages par thème, auteur, mots- clés, etc, de se constituer un panier virtuel, puis de pouvoir les
commander directement sur le Web.
Analyse
◗Acteurs
Internaute
◗Cas d’utilisation
Chercher des ouvrages
Gérer son panier
Effectuer une commande
Les internautes sont de deux types: un visiteur et un client ( qui passe une éventuelle commande).
© S. Ksibi - COO 2022-2023 60
Application : librairie en ligne
Diagramme cas d’utilisation:
librairie en ligne
Créer un
compte Client

Chercher des
Visiteur
ouvrages

Gérer son
panier
Client

Effectuer une
commande

 Les deux acteurs Client et Visiteur partagent deux cas d’utilisation :


Chercher des ouvrages
61
Gérer son panier.
Comment optimiser la présentation dans ce cas ?
© S. Ksibi - COO 2022-2023
Application : librairie en ligne
Le diagramme devient alors :

librairie en ligne

Créer un
Visiteur compte Client

Chercher des
ouvrages

Internaute Gérer son


panier

Effectuer une
commande
Client

62

© S. Ksibi - COO 2022-2023


Application : librairie en ligne
On pourrait relier les cas d’utilisation des internautes par des relations
d’extension :
La recherche d’ouvrages peut donner lieu à leur mise dans le panier (et
réciproquement !).
La gestion du panier peut donner lieu au passage d’une commande(et
réciproquement !).
◗De même, les différentes possibilités de recherche d’ouvrages seront
modélisées plus finement par une relation de généralisation/spécialisation.
◗Enfin, l’authentification du client est nécessaire au début du passage d’une
commande, du suivi des commandes, ou de la modification des informations
du compte.

© S. Ksibi - COO 2022-2023 63


Application : librairie en ligne
Le diagramme en version finale:
librairie en ligne

Effectuer une
recherche rapide
Créer un
Visiteur compte Client

Chercher des Effectuer une


ouvrages recherche détaillée

Internaute Gérer son


panier <<Extends>>
<<Extends>>
Effectuer une <<Include>>
S’authentifier
© S.commande
Ksibi - COO 2022-2023 64
Client
Application: Agence de voyage
1. Une agence de voyages organise des voyages où l’hébergement se fait en hôtel. Le client doit
disposer d’un taxi quand il arrive à la gare pour se rendre à l’hôtel.

2. Certains clients demandent à l’agent de voyages d’établir une facture détaillée. Cela donne lieu à un
nouveau cas d’utilisation appelé « Etablir une facture détaillée ». Comment mettre ce cas en relation
avec les cas existants ?
3. Le voyage se fait soit par avion, soit par train. Comment modéliser cela ?
© S. Ksibi - COO 2022-2023 65
Description textuelle d’un CU

◗À chaque cas d’utilisation doit être associée une description textuelle des
interactions entre les acteurs et le système et les actions que le système doit réaliser en
vue de produire les résultats attendus par les acteurs.
◗Un scénario représente une succession particulière d’enchaînements, s’exécutant du
début à la fin du cas d’utilisation. Un enchaînement étant l’unité de description de
séquences d’actions.
◗Un cas d’utilisation contient en général un scénario nominal et plusieurs scénarios
alternatifs (qui se terminent de façon normale) ou d’erreur (qui se terminent en échec).

© S. Ksibi - COO 2022-2023 66


Description textuelle d’un CU

• La description d’un scénario se compose de deux parties :


Première partie : permet d’identifier le cas d’utilisation, elle doit contenir les
informations suivantes : Nom, objectif, Acteurs principales, acteurs secondaires, pré-
conditions, post-condition.
Deuxième partie : contient la description du fonctionnement du cas (scénario
nominal et plusieurs scénarios alternatifs ou d’erreur).

Représentation textuelle d’un CU


Nom CU :
Objectif :
Acteurs principales :
Acteurs secondaires :
Pré-condition :
Post-condition :
© S. Ksibi - COO 2022-2023 Scénario : 67

Nominal :
Alternatifs : D’erreur :
Description textuelle d’un CU

◗Objectif : Décrire succinctement le contexte et les résultats attendus du cas


d’utilisation.
◗Acteurs concernés : Le ou les acteurs concernés par le cas doivent être identifiés
en précisant globalement leurs rôles.
◗Pré-conditions : Si certaines conditions particulières sont requises avant
l’exécution du cas, elles sont à exprimer à ce niveau.
◗Post-conditions : Par symétrie, si certaines conditions particulières doivent être
réunies après l’exécution du cas, elles sont à exprimer à ce niveau.
◗Scénario nominal : c’est le scénario principal qui doit se dérouler sans echec.

© S. Ksibi - COO 2022-2023 68


Description textuelle d’un CU

◗Scénarios alternatifs : Les autres scénarios, secondaires ou correspondant à la


résolution d’anomalies, sont à décrire à ce niveau. Le lien avec le scénario principal se
fait à l’aide d’une numérotation hiérarchisée (1.1, 1.2, …) rappelant le numéro de
l’action concernée.
Remarque :

◗Le rôle des scénarios dans les diagrammes de CU est de détailler davantage les
interactions Utilisateur/Système et de préparer les diagrammes suivants (collaboration
/ séquence) et ce afin de passer progressivement vers l’implémentation

© S. Ksibi - COO 2022-2023 69


Description textuelle d’un CU

<<extends>>
emprunter une casette rechercher une cassette

Nom : Emprunter une cassette


Acteur principal : client
Objectifs : décrire les étapes permettant au client du magasin d’emprunter une cassette
vidéo via le distributeur automatique.
Pré-conditions : Le client possède une carte qu’il a achetée auprès du magasin. Le
distributeur est alimenté en cassettes.
Post-conditions : le système enregistre les informations relatives à l’opération d’emprunt
(date, heure, identifiant du client, identifiant du film emprunté)
© S. Ksibi - COO 2022-2023 70
Description textuelle d’un CU

Scénario nominal :
1.le système vérifie la validité de la carte.
2.Le système vérifie que le crédit de la carte est supérieur ou égal à 1 dinar.
3.Appel du cas « rechercher une cassette»
4.Le client choisit une cassette vidéo
5.Le système, indique d’après la valeur de la carte, pendant combien de temps le client peut
garder la cassette.
6.Le système délivre la cassette
7.Le client prend la cassette
8.Le système rend la carte au client
9.Le client prend sa carte
© S. Ksibi - COO 2022-2023 71
Description textuelle d’un CU
Scénario alternatif :
A1. Le crédit de la carte est inférieur à 1 dinar
l’enchainement démarre après le point 2 de la séquence nominale:
2.1. Le système indique que le crédit de la carte ne permet pas au client
d’emprunter une vidéo.
2.2. Le système invite le client à aller recharger sa carte au magasin
La sequence nominale reprend au point 8

Scénarios d ’exceptions :
E1. La carte introduite n’est pas valide
L’enchaînement démarre après le point 1 de la séquence nominale:
1.1.Le système indique que la carte n’est pas reconnue
1.2 Le distributeur éjecte la carte
© S. Ksibi - COO 2022-2023 72
Description textuelle d’un CU
Scénarios d ’exceptions (suite):
E2. La cassette n’est pas reprise par le client
L’enchainement démarre après le point 6 de la séquence nominale:
6.1.Au bout de 15 secondes, le système avale la cassette
6.2Le système annule la transaction
6.3Le distributeur éjecte la carte
E3. La carte n’est pas prise par le client
L’enchainement démarre après le point 8 de la séquence nominale:
8.1.Au bout de 15 secondes, le système avale la carte
8.2. Le système consigne cette erreur
E4. Le client a annulé la recherche (il n’a pas choisi de vidéo)
L’enchainement démarre après le point 4 de la séquence nominale:
4.1. Le distributeur éjecte la carte 73
© S. Ksibi - COO 2022-2023
Diagramme
des classes

Chapitre 4

74

© S. Ksibi - COO 2022-2023


Définition
◗Le diagramme de classes exprime de manière générale la structure statique d’un
système, en termes de classes et de relations entre ces classes.
◗Alors que le diagramme de cas d'utilisation montre un système du point de vue des
acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une
représentation abstraite des objets du système qui vont interagir pour réaliser les cas
d'utilisation.
• Il s'agit d'une vue statique, car on ne tient pas compte du facteur temporel dans le
comportement du système.
• Le diagramme de classes permet de modéliser les classes du système et leurs relations
indépendamment d'un langage de programmation particulier.
• Les principaux éléments de cette vue statique sont les classes et leurs relations :
association, généralisation et plusieurs types de dépendances.
© S. Ksibi - COO 2022-2023 75
Classe
• Une classe est un concept abstrait représentant des éléments variés comme :
• des éléments concrets (ex. : des avions),
• des éléments abstraits (ex. : des commandes de marchandises ou services),
• des composants d'une application (ex. : les boutons des boîtes de dialogue),
• des structures informatiques (ex. : des tables de hachage),
• des éléments comportementaux (ex. : des tâches), etc.

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


• Une classe est la description formelle d'un ensemble d'objets ayant une sémantique et
des caractéristiques communes.
Représentation et Exemple:
NOM_CLASSE client
+NumClt
+ATTRIBUTS +NomClt
+AdrClt
+OPERATIONS()

+MAJClt()
76

Représentation d'une classe Exemple de classe


Caractéristiques d’une classe

◗Les caractéristiques d'un objet permettent de spécifier son état et son comportement.

◗Les caractéristiques sont soit des attributs, soit des opérations

◗Une propriété d’une classe constitue un élément de l’état de l’objet: c’est un attribut qui décrit
l'état d'un objet.
◗Une opération (ou méthode) représente un service spécifique offert par un objet: C’est une
fonction qui peut prendre des valeurs en entrée et modifier les attributs ou produire des
résultats
• Exemple
◗Une commande est définie par un numéro et une date.
◗Un client est caractérisé par un numéro, un nom, un prénom et un type.
◗Pour chaque produit on doit connaître son code, sa désignation et son prix

© S. Ksibi - COO 2022-2023 77


Représentation graphique d’une classe

• Une classe est un classeur. Elle est représentée par un rectangle divisé
généralement en trois compartiments.
• Le premier indique le nom de la classe, le deuxième ses attributs et le
troisième ses opérations.

78
© S. Ksibi - COO 2022-2023
Exemples de Classes

◗Liste des attributs ◗Liste des classes


◗Numéro d’une commande ◗Commande
◗Client
◗Date d’une commande
◗Produit
◗Numéro d’un client
◗Nom d’un client
◗Prénom d’un client • Représentation graphique des classes
◗Type d’un client Commande Client Produit

◗Code d’un produit +numClient +codeProduit


+numCommande +nomClient +desProduit
◗Désignation d’un produit +dateCommande +prenomClient +typeProduit
+typeClient
◗Prix d’un produit
© S. Ksibi - COO 2022-2023 79
Attribut de classe
•Les attributs définissent des informations qu'une classe ou un objet doivent connaître.
•Ils représentent les données encapsulées dans les objets de cette classe. Chacune de ces
informations est définie par un nom, un type de données, une visibilité et peut être initialisée.
•Le nom de l'attribut doit être unique dans la classe. La syntaxe de la déclaration d'un attribut
est la suivante :
•[Visibilité] NomAttribut [Multiplicité] : Type [=Valeur Initiale] [{Propriété}]]
•Dans une classe, le marqueur de visibilité se situe au niveau de chacune de ses caractéristiques. Il
permet d'indiquer si une autre classe peut y accéder.
◗Visibilité (type d’accessibilité ) : La visibilité détermine si d’autres classes peuvent l’utiliser:
◗ + : public: visible et modifiable par tout objet,
◗ - : private: seulement visible et modifiable par les opérations de l’objet auquel il appartient,
◗# : protected: seulement accessible et modifiable par les opérations des classes descendantes.
© S. Ksibi - COO 2022-2023 80
Attribut de classe

◗Multiplicité : exprime le nombre d’instances de l’attribut et elle est présentée sous forme
d’intervalle ou d’un nombre.
◗Le type des attributs peut être :
◗un type primitif : entier, chaîne,…
◗une classe : un type utilisateur

◗Attribut dérivé : Un attribut peut être dérivé (/attribut) : Rectangle

◗déduit par application d’une formule sur d’autres attributs +longueur


+largeur surface = longueur*largeur
+/surface
◗qui conduit en implémentation à une opération
Niveau Conception
Rectangle

+longueur
© S. Ksibi - COO 2022-2023 +largeur 81
+ /surface
+surface()
Opération de classe

◗Une opération est un service qu’une instance de classe peut réaliser.


◗Une méthode est l’implémentation d’une opération.
◗Syntaxe de description d’une opération :
• [Visibilité] NomOpération [[Arguments] : TypeRetourné [{Propriété}]]
• Dans une classe, une opération doit être unique.
• Quand le nom d'une opération apparaît plusieurs fois avec des
paramètres différents, on dit que l'opération est surchargée.

© S. Ksibi - COO 2022-2023 82


Opération de classe

◗Visibilité : +, -, #
◗Arguments : direction nom_argument : type argument [=valeur par défaut]
◗Direction :
◗IN:argument est un paramètre en entrée seule; non modifiable par l’exécution de cette
opération
◗OUT : argument est un paramètre en sortie seule; l’appelant peut récupérer les informations
◗INOUT : argument est en un paramètre en entée-sortie; passe à l’opération et modifiable
Produit
Client
◗Exemple: +numClient
+codeProduit
+desProduit
+nomClient
+typeProduit
+prenomClient
+typeClient +MAJ_Produit()
+MAJ_Client()

Commande
© S. Ksibi - COO 2022-2023 +numCommande 83
+dateCommande
+calculTotal()
Opération de classe

◗Propriété :
◗Requête : l’opération ne modifie pas les attributs ;
◗Abstrait : l’opération n’est pas implémentée dans la classe ;
◗Est-feuille : l’opération ne peut pas être redéfinie ;
◗Est-racine : l’opération est définie pour la première fois dans la hiérarchie ;
◗Récursive : l’opération est récursive ;

© S. Ksibi - COO 2022-2023 84


Relations entre classes

Association
◗Une association est une relation entre deux classes (association binaire) ou plus
(association n-aire), qui décrit les connexions structurelles entre leurs instances.
◗Une association indique donc qu'il peut y avoir des liens entre des instances des
classes associées.
◗Les relations possibles entre classes sont :
◗Association

◗Agrégation

◗Composition

◗Héritage

© S. Ksibi - COO 2022-2023 85


Relations entre classes

Association
◗Une association lie une ou plusieurs classes : arité 1 ou plus.
◗Une association peut être :
◗binaire

◗n-aires

◗reflexive Classe 1 Association Classe 2

© S. Ksibi - COO 2022-2023 86


Relations entre classes
Association: Relation binaire

• Une association binaire est matérialisée par un trait plein entre les classes
associées. Elle peut être ornée d'un nom, avec éventuellement une précision
du sens de lecture ( ou ).

Livre Emprunter Lecteur

© S. Ksibi - COO 2022-2023 87


Relations entre classes

Association:Relation n-aires
• Une association n-aire lie plus de deux classes.
• On représente une association n-aire par un grand losange avec un chemin
partant vers chaque classe.
• Le nom de l'association, le cas échéant, apparaît à proximité du losange.

Enseignant Etudiant

Salle Groupe Matière * * Enseignant

Enseigner

© S. Ksibi - COO 2022-2023


88
Relations entre classes

◗Une association peut être nommée.


◗Le nom de l’association peut être en forme verbale active ou passive.
◗Le sens de lecture d’une association peut être précisé avec les deux
signes suivants : > ou <

• Association en forme verbale active Association avec sens de lecture


Hotel Herberge Personne
Hotel Herberge > Personne

• Association en forme verbale passive Personne Est employé par > Société
Personne Est employé par Société

89

© S. Ksibi - COO 2022-2023


Relations entre classes

• Association à navigabilité restreinte


◗Par défaut une association est navigable dans les deux sens
◗On peut limiter la navigabilité à un seul sens dans un modèle (et non lors de
l’implémentation).

Electeur Vote Candidat

© S. Ksibi - COO 2022-2023 90


Relations entre classes

• Notion de rôle
•L’extrémité d’une association peut avoir un nom, appelé rôle, qui décrit comment une classe
source voit une classe destination au travers de l’association.

Classe 1 Nom Association Classe 2


+[Rôle 1] +[Rôle 2]

Exemples:

Personne Est employé par Société Hotel +Client Personne


+Employé +Employeur
+Directeur

91
Relations entre classes
• Relation réflexive
•Une relation réflexive est une relation qui relie une classe à elle-même (les
deux extrémités de l'association pointent vers la même classe)

• Représentation & Exemple :

Est parent
+Rôle2
+enfant
CLASSE
+Rôle1 Personne +parent

© S. Ksibi - COO 2022-2023 92


Relations entre classes
• Cardinalités
◗Pour une association binaire : précisent le nombre (min et max) d’
objets de la classe cible qui peuvent être liés à un objet de la classe
source.

◗Pour une association n_aires : elles correspondent au nombre minimum


et maximum de fois qu’une instance de classe peut intervenir dans la
relation.

© S. Ksibi - COO 2022-2023 93


Relations entre classes

• Cardinalités
◗1 : une occurrence de la classe participe au moins et au plus une fois .
◗0..1 : une occurrence de la classe peut exister sans pour autant participer à la
relation (0) et ne participe jamais plus d’une fois (1).
◗* ou N: une occurrence de la classe peut participer plusieurs fois
◗0..* : une occurrence de la classe peut exister sans pour autant participer à la
relation(0) et peut participer sans limitation (n ou *).
◗1..* : une occurrence de la classe participe au moins une fois (1) et peut participer
sans limitation (*)
◗M .. N : une occurrence de la classe participe au moins M et au max N

© S. Ksibi - COO 2022-2023 94


Relations entre classes

• Exemples:
Entreprise fournir Servcie
* 1..*

Enseignant
1..*

0..* 1..*
Salle Groupe

© S. Ksibi - COO 2022-2023 95


Relations entre classes

• Attributs de lien
• Représentent les associations porteuses de données

Examen
Etudiant
1..* Passer 0..*

Note

© S. Ksibi - COO 2022-2023 96


Relations entre classes
• Classe d’associations
• Une classe d'association est une classe qui fait partie d'une relation d'association entre deux autres
classes.
• Elle est rattachée à une relation d'association pour fournir des informations supplémentaires sur la
relation.
• Une classe d'association est identique à d'autres classes et peut contenir des opérations, des
attributs, ainsi que d'autres associations.

Entreprise Embaucher Expert

0..* 1..*

Contrat

© S. Ksibi - COO 2022-2023 97


Relations entre classes

• Exemple:
• Proposer le diagramme de classes modélisant les spécifications suivantes:
◗Une commande est passée par un seul client et concerne un ou plusieurs produits.
◗Un client passe une ou plusieurs commandes.
◗Un produit peut être commandé par plusieurs commandes.
◗Pour chaque produit commandé on doit connaître la quantité commandée.

© S. Ksibi - COO 2022-2023 98


Relations entre classes

Client concerner Produit


passer
Commande 1..* 1..*
+NumClt 1 1..* +NumCde +CodPdt
+NomClt +DateCde +DesgPdt
+TypClt +CalculTot() +QteStock
+MAJClt()
+MAJPdt()

Qté_Cdée

© S. Ksibi - COO 2022-2023 99


Relations entre classes

• Application : Réservation de vols dans une agence de voyage


◗Des compagnies aériennes proposent différents vols.
◗Un passager peut passer une ou plusieurs des réservations de vols
◗Une resrevation concerne un ou plusieurs vols
◗Un vol est réalisé par plusieurs compagnies
◗Un vol a un jour et une heure de départ et un jour et une heure d’arrivée.
◗Un vol a un aéroport de départ et un aéroport d’arrivée.
◗Un vol peut comporter des escales dans des aéroports.
◗Une escale a une heure d’arrivée et une heure de départ..
◗Chaque aéroport dessert une ou plusieurs villes,

© S. Ksibi - COO 2022-2023 100


Relations entre classes
Réservation
Passager 1

Relative +Annuler()
+Confirmer()
◗Solution:
concerne

Vol
+Départ Aéroport
+Etat 1
Compagnie +Assure Propose 0..*
Dessert Ville
(Fermé,Ouvert) 0..* 1
+Arrivée
1..* 1..* +DateDepart 0..* 1..*
Escale 0..*
+HeureDepart
+DateArrivée
+HeureArrivée
Escale
+HeureDepart
+HeureArrivée

© S. Ksibi - COO 2022-2023


Relations entre classes

• L’agrégation
◗L’agrégationest une forme particulière d’association qui exprime un
couplage plus fort entre classes.
◗Association destinée à construire des objets complexes (composés) à
partir d’objets simples (composants).
◗Agrégation faible : dont la destruction du composé n’entraîne pas la
destruction des composants : les classes sont autonomes.

© S. Ksibi - COO 2022-2023 102


Relations entre classes

• Formalisme:

• Exemple:
© S. Ksibi - COO 2022-2023 103
Relations entre classes

• La composition
◗La composition est une relation d’agrégation dans laquelle il existe une
contrainte de durée de vie entre la classe « composé » et la classe «
composant ». Autrement dit la suppression de la classe « composé »
entraine la suppression de la ou des classes «composant ».
◗C’est une agrégation forte.

◗Une instance de composant ne peut être liée qu’à un seul agrégat.

© S. Ksibi - COO 2022-2023 104


Relations entre classes

• Formalisme: Classe 1 +composants Classe 2

+composés

Section

Document Chapitre
• Exemple: Figure

© S. Ksibi - COO 2022-2023 105


Relations entre classes

• La généralisation
◗La généralisation est la relation entre une classe (superclasse ou
classe-mère) et d’autres classes (sous-classes ou classes-filles) partageant
un sous-ensemble commun d’attributs et/ou d’opérations.
◗La généralisation est un processus de modélisation permettant de
rassembler dans une même classe toutes les propriétés et les méthodes
communes, vis à vis d’autres classes spécialisées regroupant chacune des
propriétés propres à un sous-ensemble d’occurrences de la classe
générique.
© S. Ksibi - COO 2022-2023 106
Relations entre classes

◗Une sous-classe hérite des attributs, méthodes et associations de sa


classe-mère et contient des éléments spécifiques.
◗Formalisme

Super_classe

Sous_classe1 Sous_classe2

© S. Ksibi - COO 2022-2023 107


Relations entre classes

• Exemple

Matériel

Imprimante Clavier Ordinateur

© S. Ksibi - COO 2022-2023 108


Relations entre classes

• Exemple : Héritage multiple


Véhicule

A voile Terrestre Marin


A moteur

Bateau

© S. Ksibi - COO 2022-2023 109


Relations entre classes

Application
Il est demandé de représenter le diagramme de classes d’une gestion technique de
documents.
Chaque document est composé d’un ou plusieurs feuillets. Un feuillet comporte du
texte et des objets géométriques supportant des opérations de type : sélectionner,
copier, couper, coller et déplacer.
Nous considérons les quatre objets géométriques suivants : cercle, ellipse, carré,
rectangle.
Ilest demandé d’utiliser les propriétés de la généralisation et la spécialisation afin de
représenter au mieux ces objets géométriques.

© S. Ksibi - COO 2022-2023 110


Relations entre classes

• Corrigé: Document

1..*
Feuillet

0..* 0..*
Text Objet géométrique

copier()
sélectionner()
couper()
coller()
déplacer()

© S. Ksibi - COO 2022-2023 111


Rectangle Carré
Cercle
Eclipse
Les contraintes

◗Une contrainte est une relation sémantique entre des éléments du


modèle qui spécifie les conditions et les propositions qui doivent être
respectées.
◗Certains types de contraintes sont prédéfinis dans UML, les autres
doivent être définis par les utilisateurs.
◗Une contrainte est représentée par un texte entre accolades { }.

© S. Ksibi - COO 2022-2023 112


Les contraintes

• Ordre de tri
•Pour une association de multiplicité supérieure à 1, les liens peuvent être :
◗non ordonnés (valeur par défaut),
◗ordonnés ou triés lorsque l’on est au niveau de l’implémentation (tri sur une valeur interne).
◗Exemple :

Personne 0..* Compte


1
{Ordonné}

© S. Ksibi - COO 2022-2023 113


Les contraintes

• Sous-ensemble
•Cette contrainte permet d’exprimer que l’ensemble des occurrences d’une relation est
inclus dans l’ensemble des occurrences d’une autre, vis à vis des objets communs.
• Exemple

Toutes les instances de diriger sont incluses dans affecter


Affecter
1 1..*
Service Employe
{Sous ensemble}
Diriger 1
0..10

© S. Ksibi - COO 2022-2023 114


Les contraintes

• Ou-exclusif
•Indique pour un objet donné qu’une seule association est valide.
• Exemple:

Batterie

Portable
Ou-exclusif

Secteur

© S. Ksibi - COO 2022-2023 115


Les contraintes

• Contraintes et propriétés de la généralisation


• Par défaut, les sous-classes ont des instances disjointes
les unes par
rapport aux autres. Dans certains cas, il existe un recouvrement
d’instances entre les sous-classes. D’une manière générale, quatre
situations peuvent se rencontrer et se représentent sous forme de
contraintes :
◗Chevauchement,
◗Disjoint,
◗Complète,
◗Incomplète.

© S. Ksibi - COO 2022-2023 116


Les contraintes

• Chevauchement : Une instance de l’une des spécialisations peut être


simultanément une instance d’une autre.

Véhicule

{chevauchement}
A voile Terrestre Marin
A moteur

Bateau

© S. Ksibi - COO 2022-2023 117


Les contraintes

◗Disjoint: Les instances d’une sous-classe ne peuvent être incluses dans


une autre sous-classe de la même classe ;

Enseignant

{Disjoint}

Vacataire Permanant

© S. Ksibi - COO 2022-2023 118


Les contraintes

• Incomplète : Indique que la généralisation est extensible: elle peut


avoir d’autres spécialisations.
Enseignant
Professeur d’enseignement supérieur

{incomplet}

Vacataire Permanant

• On peut trouver d’autres instances de la classe Enseignant qui ne sont ni Vacataire ni Permanent
ni Professeur d’enseignement supérieur :
• Instance(Vacataire) U Instance(Permanent) inclus Instance(Enseignant) 119

© S. Ksibi - COO 2022-2023


Les contraintes

• Complète : Indique que la généralisation est terminée : Il n’est pas


possible d’ajouter d’autres sous-classes
Enseignant_universitaire

{complet}

Vacataire Permanant

• Un Enseignant ne peut être qu’un Vacataire, ou Permanent: Instance(Vacataire) U


Instance(Permanent) = Instance(Enseignant)

© S. Ksibi - COO 2022-2023 120


Les contraintes

La qualification :
◗Elle permet de sélectionner un sous-ensemble d'objets, parmi ceux
participant à une association.
◗Elle est définie par un qualificatif, qui est utilisé avec un objet de la
classe source et permet de sélectionner les objets de la classe cible.

© S. Ksibi - COO 2022-2023 121


Les contraintes

Exemple:
0..2 *
CLIENT
compte BANQUE

◗Un compte dans une banque appartient à au plus deux personnes. Autrement dit, une instance
du couple {Banque , compte} est en association avec zéro à deux instances de la classe Personne.
◗Mais une personne peut posséder plusieurs comptes dans plusieurs banques. C’est-à-dire qu’une
instance de la classe Client peut être associée à plusieurs (zéro compris) instances du couple
{Banque , compte}.
◗Bienentendu, et dans tous les cas, un instance du couple {Client , compte} est en association
avec une instance unique de la classe Banque.

© S. Ksibi - COO 2022-2023 122

Vous aimerez peut-être aussi