Conception orientée objet

des systèmes d’information

LIAG2
A.U 2020-2021

Salma Ksibi
Docteur Ingénieur en Informatique

© S. Ksibi - COO 2020-2021

 Plan du cours
◗Chapitre 1 : Systèmes d’information: Rappel et méthodologies de conception
◗Chapitre 2 : Introduction à la conception OO des SI
◗Chapitre 3 : Diagramme de cas d’utilisation
◗Chapitre 4 : Diagramme de classes
◗Chapitre 5 : Diagramme de séquence
◗Chapitre 6 : Diagramme d’état-transition
◗Chapitre 7 : Diagramme d’activités
◗Chapitre
© S. Ksibi - COO
8 2020-2021
: Diagramme de déploiement
 Chapitre 1
Systèmes d’information: Rappel et méthodologies
de conception
© S. Ksibi - COO 2020-2021
 1. Système d’information
organisation + environnement = SYSTEME ORGANISATIONNEL

entrées sorties
Organisation
transformations

4
 1. Système d’information

C’est l’ensemble de moyens humains et matériels et de

méthodes permettant de réaliser les traitements
nécessaires sur les différentes formes d’information pour la
bonne conduite de l’organisation.

5
 Système d’information
Rôle d’un SI :
• produire des informations «légales»
• déclencher des décisions programmées

SD

SI

SO

SD : système décisionnel SI : système d’information SO : système opérant 6

 2. Une organisation/ entreprise

 Une organisation regroupe des individus, aidés de machines, qui remplissent leur fonction
d’exécutant ou de décideur grâce aux informations dont ils disposent.
 Par la suite, nous parlerons en général d’entreprise par souci de simplification.
 Entreprise = Système
• « Ensemble d’éléments en interaction dynamique, organisé en fonction d’un but » Joël De
Rosnay « Le macroscope », éditions du seuil, 1975,
• L’entreprise est alors considérée comme un ensemble d’éléments (des moyens humains,
matériels, financiers et techniques) en interrelations,
• Toute organisation humaine (l’État, une famille, …) peut être perçue comme un système.
Systèmes d'information 7
 L’entreprise: Système ouvert

 Le système réagit automatiquement aux données (entrées) qui lui sont

fournies par son environnement et donne des résultats (sorties) en principe
conformes à son but.
 L'entreprise est un SYSTÈME OUVERT, c'est-à-dire en relation permanente
avec son environnement, traversé par des flux (informations, biens,
capitaux) sur lesquels il exerce une transformation pour créer d’autres
éléments.
Systèmes d'information 8
 L'informatisation
• L'informatisation est le phénomène le plus important de notre époque. Elle s'immisce
maintenant dans la plupart des objets de la vie courante et particulièrement dans le
processus de conception ou de fabrication de cet objet.
• Actuellement, l'informatique est au cœur de toutes les grandes entreprises.
• Le système d'information 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 : 20 % pour le matériel et 80 % pour le logiciel.
• Dernièrement, la fabrication du matériel est assurée par quelques fabricants seulement. Ce
matériel est relativement fiable et le marché est standardisé.
• Les problèmes liés à l'informatique sont essentiellement des problèmes de logiciel.

© S. Ksibi - COO 2020-2021

 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 leur taille, 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 2020-2021
 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 :
• 16,2% seulement des projets étaient conformes aux prévisions initiales,
• 52,7% avaient subi des dépassements en coût et délai d'un facteur 2 à 3 avec diminution du nombre des fonctions offertes,
• 31,1% ont été purement abandonnés durant leur développement.
• Pour les grandes entreprises, le taux de succès est de 9% seulement, 37% des projets sont arrêtés en cours
de réalisation, 50% aboutissent hors délai et hors budget.
• L'examen des causes de succès et d'échec est instructif : la plupart des échecs proviennent non de
l'informatique, mais de la maîtrise d'ouvrage (i.e. le client).
• Pour ces raisons, 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.

© S. Ksibi - COO 2020-2021

 Le génie logiciel

• Le génie logiciel est un domaine de recherche qui a été défini afin de répondre à un problème qui
s'énonçait en deux constatations :
• Les logiciels n'étaient pas fiables,
• Il était incroyablement difficile de réaliser dans des délais prévus des logiciels satisfaisant leur cahier des charges.
• L'objectif du génie logiciel est d'optimiser le coût de développement du logiciel. L'importance d'une
approche méthodologique s'est imposée à la suite de la crise de l'industrie du logiciel à la fin des années
1970. Cette crise de l'industrie du logiciel était principalement due à :
• l'augmentation des coûts ;
• les difficultés de maintenance et d'évolution ;
• la non-fiabilité ;
• le non-respect des spécifications ;
• le non-respect des délais.

© S. Ksibi - COO 2020-2021

 Le génie logiciel
• Pour apporter une réponse à tous ces problèmes, le génie logiciel s'intéresse
particulièrement à la manière dont le code source d'un logiciel est spécifié puis
produit.
• Le génie logiciel touche au cycle de vie des logiciels :
• L’étude préalable
• L'analyse du besoin,
Etude Préalable
But du Cours

• La conception, Analyse

• L’implémentation, Cycle de vie

C onception

• Test et validation, de logiciel Implémentation

• La maintenance. Test et Validation

Maintenance
© S. Ksibi - COO 2020-2021
 Système d’information

Outils
Entreprise Informatiques

langage stricte
organisation vivante
contraintes technologiques
problèmes mal définis
14
 Système d’information
La nécessité de l’étape de conception

Différentes méthodes d’analyse et de conception

Analyse du cycle de vie du SI

Suivi de principes

Interfaces de haut niveau

standards d’environnement

15
 Modélisation, cycles de vie et méthodes

◗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 2020-2021

 Modélisation, cycles de vie et méthodes

Qu'est-ce qu'un modèle ?

◗Un modèle est une abstraction de la réalité. L'abstraction est un des piliers de l'approche objet.
◗Un modèle est une vue subjective mais pertinente de la réalité
◗Modèle : ensemble de règles et de concepts.
Les concepts 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.

© S. Ksibi - COO 2020-2021

 Modélisation, cycles de vie et méthodes
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 2020-2021
 Modélisation, cycles de vie et méthodes

◗Un modèle est une abstraction de la réalité. L'abstraction est un des piliers de l'approche objet.
◗Un modèle est une vue subjective mais pertinente de la réalité
◗Modèle : ensemble de règles et de concepts.
Les concepts 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.

© S. Ksibi - COO 2020-2021

 Modélisation, cycles de vie et méthodes
Maîtrise d'ouvrage et maîtrise d'œuvre
Maître d'ouvrage (MOA) :
• Le MOA est une personne morale (entreprise, direction, etc.), une entité de l'organisation.
Maître d'œuvre (MOE) :
• Le MOE est une personne morale (entreprise, direction, etc.) garante de la bonne réalisation technique des solutions. Il a, lors
de la conception du SI, un devoir de conseil vis-à-vis du MOA, car le SI doit tirer le meilleur parti des possibilités techniques.
• Le MOA est client du MOE à qui il passe commande d'un produit nécessaire à son activité.
• Le MOE fournit ce produit ; soit il le réalise lui-même, soit il passe commande à un ou plusieurs fournisseurs (« entreprises »)
qui élaborent le produit sous sa direction.
• La relation MOA et MOE est définie par un contrat qui précise leurs engagements mutuels.
• Lorsque le produit est compliqué, il peut être nécessaire de faire appel à plusieurs fournisseurs. Le MOE assure leur
coordination ; il veille à la cohérence des fournitures et à leur compatibilité. Il coordonne l'action des fournisseurs en
contrôlant la qualité technique, en assurant le respect des délais fixés par le MOA et en minimisant les risques.
• Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute livraison au MOA, procéder aux vérifications
nécessaires.
© S. Ksibi - COO 2020-2021
 Modélisation, cycles de vie et méthodes
Le cycle de vie d'un logiciel
• Le cycle de vie d'un logiciel désigne toutes les étapes du développement d'un logiciel, de sa conception à sa
disparition.
• L'objectif d'un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du
développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du
processus de développement, c'est-à-dire l'adéquation des méthodes mises en œuvre.
• L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé qu'elles sont détectées
tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de
maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés.
• Le cycle de vie du logiciel comprend généralement au minimum les étapes suivantes :
• Analyse des besoins et faisabilité: c'est-à-dire l'expression, le recueil et la formalisation des besoins du demandeur
(le client) et de l'ensemble des contraintes, puis l'estimation de la faisabilité de ces besoins ;
• Spécifications ou conception générale: il s'agit de l'élaboration des spécifications de l'architecture générale du
logiciel ;
© S. Ksibi - COO 2020-2021
 Modélisation, cycles de vie et méthodes
• Conception détaillée: cette étape consiste à définir précisément chaque sous-ensemble du logiciel ;
• Codage (Implémentation ou programmation): c'est la traduction dans un langage de programmation des
fonctionnalités définies lors de phases de conception ;
• Tests unitaires: ils permettent de vérifier individuellement que chaque sous-ensemble du logiciel est
implémenté conformément aux spécifications ;
• Intégration: l'objectif est de s'assurer de l'interfaçage des différents éléments (modules) du logiciel. Elle
fait l'objet de tests d'intégration consignés dans un document ;
• Qualification : c'est-à-dire la vérification de la conformité du logiciel aux spécifications initiales ;
• Documentation: elle vise à produire les informations nécessaires pour l'utilisation du logiciel et pour des
développements ultérieurs ;
• Mise en production: c'est le déploiement sur site du logiciel ;
• Maintenance: elle comprend toutes les actions correctives (maintenance corrective) et évolutives
(maintenance évolutive) sur le logiciel.

© S. Ksibi - COO 2020-2021

 Modèles de cycles de vie d'un logiciel
Étapes du cycle de développement

MODELE EN CASCADE

définition
des besoins

conception

implémentation

tests

utilisation
maintenance 23
 Modèles de cycles de vie d'un logiciel
Étapes du cycle de développement

MODELE EN V
définition
validation
des besoins

conception test
du système du système

conception test
des composants des composants

codage
24
Modèles de cycles de vie d'un logiciel
Étapes du cycle de développement

MODELE EN SPIRALE

25
 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 fonctionnelle (dirigée par le traitement) et 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 2020-2021

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

Années 70 • Les approches cartésiennes

Années 80 • Les approches systémiques

Années 90 • les approches objet

27
 Evolution des méthodes de conception
de SI
◗Lesmé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.
◗Lesmé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.
 Approches cartésiennes et systémiques

• Approche 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.
• Approche 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.
 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 2020-2021

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.

© S. Ksibi - COO 2020-2021

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 2020-2021
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 2020-2021

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.
• 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 2020-2021

 Chapitre 2
Introduction à la conception OO des SI

© S. Ksibi - COO 2020-2021

 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 2020-2021
 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 2020-2021
 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.
© S. Ksibi - COO 2020-2021
 Evolution d’ UML

UML 2.4 (2011) UML 2.3 (2010)

UML 2.0 (2004)

UML 1.0 (97)

UML0.9 (96)

Méthodes unifiées (95) OOSE

Booch (93) OMT Autres méthodes

+HOOD, OOD
© S. Ksibi - COO 2020-2021
 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
© S. Ksibi - COO 2020-2021 collaboration diagramme d’états-transitions
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 2020-2021

 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.
© S. Ksibi - COO 2020-2021
 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
© S. se
Ksibi concentrant
- COO 2020-2021 sur les échanges de messages entre les objets.
Concepts importants de l'approche objet
UML
• Les entités du monde réel sont représentée à 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.

© S. Ksibi - COO 2020-2021

 Concepts importants de l'approche objet
APPLICATIONS CLASSIQUES :
DUALITE DONNEES – TRAITEMENTS

APPROCHEOBJETS,
OBJETTYPES,
: CLASSES • ETAT : ENSEMBLE DE VALEURS D ’ATTRIBUTS =
APPLICATION = ENSEMBLE D’OBJETS CONTENU INFORMATIONNEL
AYANT UN COMPORTEMENT ET
ECHANGEANT DES MESSAGES • IDENTIFIANT : IDENTIFIE DE MANIERE UNIQUE
UN OBJET ET N ’EST NI MODIFIABLE NI
REUTILISABLE (INTERNE AU SYSTEME).
 ABSTRAIT
 CONCRET • COMPORTEMENT: DIFFERENTS MESSAGES
OBJET  ETAT AUXQUELS L ’OBJET PEUT REAGIR.
 IDENTITE

 COMPORTEMENT

© S. Ksibi - COO 2020-2021

 Chapitre 3
Diagramme de cas d’utilisation

© S. Ksibi - COO 2020-2021

 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 2020-2021

 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 2020-2021

 Formalisme et représentation

Acteur

Retirer Argent

Cas d'utilisation
Client

Consulter Compte
Associations
© S. Ksibi - COO 2020-2021
 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

Gérer Article

Reponsable Stock

© S. Ksibi - COO 2020-2021

 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.

◗ Uncas 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 2020-2021

 Cas d’utilisation
◗ un cas d’utilisation doit :
◗ Correspondre à un objectif de haut niveau

◗ Décrirel’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 2020-2021

 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 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 2020-2021

 Cas d’utilisation
Représentation graphique :

Nom du cas
d'utilisation

Exemple :

Gérer Stock

© S. Ksibi - COO 2020-2021

 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 2020-2021
 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 2020-2021

 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ème : avec qui le système doit interagir.
Remarque:
◗Un cas d’utilisation a au plus un acteur principal, et un ensemble – éventuellement vide – d’acteurs
secondaires.
◗Les acteurs secondaires sont généralement placés à droite des cas d’utilisation

© S. Ksibi - COO 2020-2021

 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 2020-2021

 Acteur
Exemple d'acteurs

Accès à un
batiment

Gérer les
groupes des
Personne personnes
Administrateur

© S. Ksibi - COO 2020-2021

 Acteur
Exemple d'acteurs

Retrait
Argent

Consulter
Guichetier compte
Système central

© S. Ksibi - COO 2020-2021

 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 2020-2021
 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 2020-2021

 Relations dans les diagrammes de CU

• EXemple

Retrait Aegent

Guichetier

© S. Ksibi - COO 2020-2021

 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 2020-2021

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 2020-2021

 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 2020-2021

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 ]

Montant Vérifiez solde

<<extends>>

© S. Ksibi - COO 2020-2021

 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 2020-2021

 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 2020-2021

 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 2020-2021
Scénario :
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

© S. Ksibi - COO 2020-2021

 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 2020-2021

 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 2020-2021
 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 choisi 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 2020-2021
 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 séquence 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
S. Ksibi - COO 2020-2021
éjecte la carte
 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- COO
© S. Ksibi distributeur
2020-2021 éjecte la carte
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
 Application : librairie en ligne
Diagramme en deuxième version

Créer un
compte Client

Chercher des
Visiteur ouvrages

Effectuer une
commande
Client

Gérer son
panier
Application : librairie en ligne
Nous remarquons maintenant que les deux acteurs Client et
Visiteur partagent deux cas d’utilisation :
Chercher des ouvrages et
Gérer son panier.
Application : librairie en ligne
Le diagramme devient alors :

Créer un
Visiteur compte Client

Chercher des
ouvrages

Internaute Gérer son

panier

Effectuer une
commande
Client
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.
Application : librairie en ligne
Le diagramme en version finale

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
commande
Client
 Exercice
• Soient les cas d'utilisation suivants :
• Passer une commande
• Passer une commande urgente
• Suivre une commande
• Valider l'utilisateur
• Passer une commande
• Expédier commande totale ou partielle
• Le suivi de la commande désigne le processus complet, du passage à l'expédition. Il peut
toutefois arriver qu'une commande passée ne soit pas envoyée. Passer une commande
urgente est un cas particulier de passer une commande. Pour passer une commande, il faut
nécessairement valider l'utilisateur.
• Donner le diagramme de cas d'utilisation sans représenter les acteurs

© S. Ksibi - COO 2020-2021

 Chapitre 4
Diagramme de classes

© S. Ksibi - COO 2020-2021

 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.

◗Son intérêt est de modéliser les entités du système d’information.

© S. Ksibi - COO 2020-2021

 Formalisme

© S. Ksibi - COO 2020-2021

 Classe

◗Une classe regroupe sous un même terme générique et une même représentation, un
ensemble d’objets ou instances ayant :
◗des propriétés (états)
et
◗des comportements (opérations /méthodes)
communs.

© S. Ksibi - COO 2020-2021

 Classe
Représentation et Exemple:

client
NOM_CLASSE
+NumClt
+ATTRIBUTS +NomClt
+AdrClt
+OPERATIONS()
+MAJClt()

Représentation d'une classe Exemple de classe

© S. Ksibi - COO 2020-2021

 Classe

◗Une propriété d’une classe constitue un élément de l’état de l’objet

◗Une opération (ou méthode) représente un service spécifique offert par un objet
• 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 2020-2021

 Classe
◗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
◗Type d’un client
◗Code d’un produit
◗Désignation d’un produit
◗Prix d’un produit
© S. Ksibi - COO 2020-2021
 Classe

• Représentation graphique des classes

Commande Client Produit

+numClient +codeProduit
+numCommande +nomClient +desProduit
+dateCommande +prenomClient +typeProduit
+typeClient

© S. Ksibi - COO 2020-2021

 Attribut de classe

•[Visibilité] NomAttribut [Multiplicité] : Type [=ValeurInitiale] [{Propriété}]]

◗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 2020-2021

 Attribut de classe
◗Multiplicité : exprime le nombre d’instances de l’attribut et elle est présentée sous forme d’intervalle ou de
nombre.
◗Le type des attributs peut être :
◗un type primitif : entier, chaîne,…
◗une classe : un type utilisateur
◗Propriété : mutabilité (gelé, variable, ajout Uniquement, …).
◗La mutabilité exprime les possibilités de modification d’un attribut et peut être :
◗Gelé (Frozen): attribut non modifiable (constante),
◗variable : attribut
modifiable
◗ajout uniquement :seul l’ajout est possible  multiplicité >1

© S. Ksibi - COO 2020-2021

 Attribut de classe
◗Attribut dérivé : Un attribut peut être dérivé (/attribut) :
◗déduit par application d’une formule sur d’autres attributs
◗qui conduit en implémentation à une opération

Rectangle
Rectangle
+longueur
+longueur +largeur
+largeur surface = longueur*largeur
+/surface +surface()

Niveau Analyse
Niveau Conception

© S. Ksibi - COO 2020-2021

 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é}]]
© S. Ksibi - COO 2020-2021
 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

© S. Ksibi - COO 2020-2021

 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 2020-2021

 Opération de classe
◗Exemple:

Produit
Client
+codeProduit
+numClient
+desProduit
+nomClient
+typeProduit
+prenomClient
+typeClient +MAJ_Produit()
+MAJ_Client()

Commande
+numCommande
+dateCommande
+calculTotal()

© S. Ksibi - COO 2020-2021

 Relations entre classes
Association
◗L’association exprime une connexion sémantique bidirectionnelle entre classes.
◗Une association est instanciable dans un diagramme d’objets ou de collaboration sous forme de
liens entre objets issus de classes associées.
◗Les relations possibles entre classes sont :
◗Association

◗Agrégation

◗Composition

◗Héritage

© S. Ksibi - COO 2020-2021

 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 2020-2021

 Relations entre classes
Association
◗Exemple 1 : Relation binaire
Livre Emprunter Lecteur

◗Exemple 2 : Relation n-aires Enseignant

Salle Groupe

© S. Ksibi - COO 2020-2021

 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 <

© S. Ksibi - COO 2020-2021

 Relations entre classes
• Association en forme verbale active
Hotel Herberge Personne

• Association en forme verbale passive

Personne Est employé par Société

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Association avec sens de lecture

Hotel Herberge > Personne

Personne Est employé par > Société

© S. Ksibi - COO 2020-2021

 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 2020-2021

 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]

© S. Ksibi - COO 2020-2021

 Relations entre classes

Personne Est employé par Société

+Employé +Employeur

Hotel +Client Personne

+Directeur

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Relation réflexive
• Une relation réflexive est une relation qui relie une classe à elle-même.
• Représentation & Exemple :
+Rôle2 +Est enfant
CLASSE
+Rôle1 Personne
+Est parent

© S. Ksibi - COO 2020-2021

 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 2020-2021

 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).
◗1..* : une occurrence de la classe participe au moins une fois (1) et peut participer sans
limitation (n)
◗M .. N : une occurrence de la classe participe au moins M et au max N

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Exemples:
Entreprise Servcie
1 1..*

Enseignant
1..*

0..* 1..*
Salle Groupe

© S. Ksibi - COO 2020-2021

 Relations entre classes

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

Passer
Etudiant 1..* 0..* Examen

Note

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Classe d’associations
•Permet de représenter une association par une classe pour définir des attributs et/ou des
opérations dans l’association.
Embauche
Entreprise Expert

0..* 1..*

Contrat

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Exemple
◗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 2020-2021

 Relations entre classes

Client passer Produit

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

Qté_Cdée
© S. Ksibi - COO 2020-2021
 Relations entre classes

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

◗Des compagnies aériennes proposent différents vols.
Compagnie Propose Vol

1..*

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Un vol est réalisé par plusieurs compagnies

Compagnie +Assurer Propose Vol

1..* 1..*

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Un vol a un jour et une heure de départ et un jour et une heure

d’arrivée.
Vol
+Etat (Fermé,Ouvert)
Compagnie +Assure Propose
+DateDepart
+HeureDepart
1..* 1..*
+DateArrivée
+HeureArrivée

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Un vol a un aéroport de départ et un aéroport d’arrivée.

Solution 1:

Vol
+Etat (Fermé,Ouvert)
+DateDepart 2 Aéroport
1..* {Ordered}
+HeureDepart
+DateArrivée
+HeureArrivée

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Un vol a un aéroport de départ et un aéroport d’arrivée.

Solution 2:

Vol
+Etat (Fermé,Ouvert) Aéroport
+Départ
+DateDepart 0..*
1
+HeureDepart 1
+DateArrivée 0..* +Arrivée
+HeureArrivée

© S. Ksibi - COO 2020-2021

 Relations entre classes
◗Un vol peut comporter des escales dans des aéroports.
◗Une escale a une heure d’arrivée et une heure de départ..

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

Escale
+HeureDepart
+HeureArrivée

© S. Ksibi - COO 2020-2021

 Relations entre classes

• Chaque aéroport dessert une ou plusieurs villes,

Aéroport
Dessert Ville
0..*

© S. Ksibi - COO 2020-2021

 Relations entre classes

◗Une réservation concerne un seul vol, et un seul passager.

◗Une réservation peut être annulée ou confirmée

Vol
Réservation +Etat (Fermé,Ouvert)
Passager 1 1 +DateDepart
+HeureDepart
Relative +Annuler() +DateArrivée
Concerne
+Confirmer() +HeureArrivée

© S. Ksibi - COO 2020-2021

 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 2020-2021
 Relations entre classes

• Formalisme:

• Exemple:
© S. Ksibi - COO 2020-2021
 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 2020-2021

 Relations entre classes
• Formalisme: Classe 1 +composants Classe 2

+composés

Section

Document Chapitre
• Exemple: Figure

© S. Ksibi - COO 2020-2021

 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 chacun des propriétés propres à un
sous-ensemble d’occurrences de la classe générique.
© S. Ksibi - COO 2020-2021
 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 2020-2021

 Relations entre classes
• Exemple
Matériel

Imprimante Clavier Ordinateur

© S. Ksibi - COO 2020-2021

 Relations entre classes
• Exemple : Héritage multiple
Véhicule

A voile Terrestre Marin

A moteur

Bateau

© S. Ksibi - COO 2020-2021

 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.
 Il
est 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 2020-2021

 Relations entre classes
Document

• Corrigé:
Feuillet

Text Objet géométrique

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

© S. Ksibi - COO 2020-2021

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 2020-2021

 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 2020-2021

 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
10..1

© S. Ksibi - COO 2020-2021

 Les contraintes

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

Portable
Ou-exclusif

Secteur

© S. Ksibi - COO 2020-2021

 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 2020-2021

 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 2020-2021

 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 2020-2021

 Les contraintes
• Incomplète : Indique que la généralisation est extensible: elle peut
avoir d’autres spécialisations.
Enseignant

{incomplet}

Vacataire Permanant

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

© S. Ksibi - COO 2020-2021

 Les contraintes
• Complète : Indique que la généralisation est terminée : Il n’est pas
possible d’ajouter d’autres sous-classes

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

Instance(Permanent) = Instance(Enseignant)

© S. Ksibi - COO 2020-2021

 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 2020-2021

 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 2020-2021