Conception

INFORMATIQUE APPLIQUÉE: CSI 3204
L’analyseL’ANALYSE LA ET
et La Conception
Orientées-Objets
CONCEPTION
ORIENTEES-OBJETS
Dr. Pélagie HOUNGUE
(COUVERCLE PLACE)
L’analyse et la Conception Orientées-Objets
Avant-propos
L’Université Virtuelle Africaine (UVA) est fière de participer à accès à l’éducation dans les pays
africains en produisant du matériel d’apprentissage de qualité. Nous sommes également fiers
de contribuer à la connaissance globale, pour nos ressources éducatives sont principalement
accessibles de l’extérieur du continent africain.
Ce module a été développé dans le cadre d’un programme de diplôme et diplôme en

informatique appliquée, en collaboration avec 18 institutions partenaires dans 16 pays africains.
Un total de 156 modules ont été développés ou traduits pour assurer la disponibilité en
anglais, français et portugais. Ces modules sont également disponibles en tant que ressources
éducatives ouvertes (OER) à oer.avu.org.
Au nom de l’Université Virtuelle Africaine et notre patron, nos institutions partenaires,

la Banque africaine de développement, je vous invite à utiliser ce module dans votre
établissement, pour leur propre éducation, partager aussi largement que possible et participer
activement aux communautés AVU de pratique d’intérêt. Nous nous engageons à être à
l’avant-garde du développement et de partage ouvert de ressources pédagogiques.
L’Université Virtuelle Africaine (UVA) est une organisation intergouvernementale

panafricaine mis en place par lettre recommandée avec un mandat d’augmenter l’accès
à l’enseignement supérieur et de formation de qualité grâce à l’utilisation novatrice des
technologies de communication de l’information. Une charte instituant la UVA Organisation
intergouvernementale, signée à ce jour par dix-neuf (19) Les gouvernements africains - Kenya,
Sénégal, Mauritanie, Mali, Côte d’Ivoire, Tanzanie, Mozambique, République démocratique du
Congo, Bénin, Ghana, République de Guinée, le Burkina Faso, le Niger, le Soudan du Sud, le
Soudan, la Gambie, la Guinée-Bissau, l’Ethiopie et le Cap-Vert.
Les institutions suivantes ont participé au programme informatique appliquée: (1) Université
d’Abomey Calavi au Bénin; (2) University of Ougagadougou au Burkina Faso; (3) Université
Lumière Bujumbura Burundi; (4) Université de Douala au Cameroun; (5) Université de Nouakchott
en Mauritanie; (6) Université Gaston Berger Sénégal; (7) Université des Sciences, Techniques
et Technologies de Bamako au Mali (8) Institut de la gestion et de l’administration publique
du Ghana; (9) Université des sciences et de la technologie Kwame Nkrumah au Ghana; (10)
Université Kenyatta au Kenya; (11) Université Egerton au Kenya; (12) Université d’Addis-Abeba
en Ethiopie (13) Université du Rwanda; (14) University of Salaam en Tanzanie Dar; (15) Université
Abdou Moumouni Niamey Niger; (16) Université Cheikh Anta Diop au Sénégal; (17) Université
pédagogique au Mozambique; E (18) L’Université de la Gambie en Gambie.
Bakary Diallo
le Recteur
Université Virtuelle Africaine
2
Crédits de production
Auteur
Pair Réviseur
Oumar Maïga
UVA – Coordination Académique
Dr. Marilena Cabral
Coordinateur global Sciences Informatiques Apliquées
Prof Tim Mwololo Waema
Coordinateur du module
Jules Degila
Concepteurs pédagogiques
Elizabeth Mbasu
Benta Ochola
Diana Tuel
Equipe Média
Sidney McGregor Michal Abigael Koyier
Barry Savala Mercy Tabi Ojwang
Edwin Kiprono Josiah Mutsogu
Kelvin Muriithi Kefa Murimi
Victor Oluoch Otieno Gerisson Mulongo
3
Droits d’auteur
Ce document est publié dans les conditions de la Creative Commons
Http://fr.wikipedia.org/wiki/Creative_Commons
Attribution http://creativecommons.org/licenses/by/2.5/
Le gabarit est copyright African Virtual University sous licence Creative Commons Attribution-
ShareAlike 4.0 International License. CC-BY, SA
Supporté par
Projet Multinational II de l’UVA financé par la Banque africaine de développement.
4
Table Des Matières
Avant-propos 2
Crédits de production 3
Droits d’auteur 4
Supporté par 4
Aperçu du cours 7
Bienvenue à l’analyse et la Conception Orientées-Objets. . . . . . . . . . . . . . 7
Prérequis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Matériaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Objectifs du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Unités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Plan 9
Lectures et autres ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Unité 0. Évaluation Diagnostique 13
Introduction à l’unité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Objectifs de l’unité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Termes clés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Evaluation de l’unité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Partie II Projet de développement. . . . . . . . . . . . . . . . . . . . . . . . . 14
Réponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Unité 1. - Principes de La Programmation Orientée-Objet 18
Objectifs de l’unité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Termes clés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Activités d’apprentissage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Activité 1.1 Principes de l’orienté-objet 19
Détails de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Conclusion 21
5
Evaluation 21
Activité 1.2 – Concepts de la POO 22
Evaluation 26
Activité 1.3 - Associations et liens 26
Détails de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Conclusion 30
Evaluation 30
Lectures et autres ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Unité 2: Principes de Base en UML 33
Termes clés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Activité 2.1 –Utilisation du langage UML dans l’Analyse et la
Conception orientée objet 34
Conclusion 38
Evaluation 38
Activité 2.2- Diagrammes UML 39
Conclusion 50
Evaluation 50
Activité 2.3- Modèle UML 52
Détails de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Conclusion 54
Evaluation 54
Lectures et autres ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Unité 3: Analyse Orientée-Objet 56
6
Termes clés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Activité 3.1 - Comprendre les exigences 57
Caractéristiques des exigences 62
Evaluation 63
Activité 3.2 - Cas d’utilisation 64
Conclusion 75
Evaluation 76
Activité 3.3 - Modèle conceptuel 77
Conclusion 85
Evaluation 85
Activité 3.4 – Comportement du système: diagrammes de
séquence et des opérations système 86
Définition des terminologies : 86
Conclusion 89
Evaluation 89
Unité 4 : Conception Orientée Objet et Traduction Dans un Langage 92
Termes clés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Activité 1.1 - Les diagrammes interactifs 93
Evaluation 98
Activité 4.2 - Aperçu sur la phase de conception 99
5
Conclusion 105
Evaluation 105
Activité 4.3 - La conception du système Terminal de point de vente 106
Conclusion 110
Evaluation 110
Activité 4.4 - Conception des diagrammes de classe 110
Conclusion 112
Evaluation 112
Activité 4.5 - Mise en œuvre / traduction des dessins dans
les langages de programmation orientée objet 113
Conclusion 116
Evaluation 117
Résumé du module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Evaluation du cours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Exercice 1: (Questions de cours, 6 points) 118
Exercice 2: Diagrammes de cas d’utilisation et de classes (8 points) 118
Exercice 3: Diagramme d’activité (Recette de cuisine, 3 points) 119
Exercice 4: Diagramme d’états-transitions (Porte de garage
motorisée à enroulement, 3 points) 119
Examen final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Unité Lectures et Autres ressources. . . . . . . . . . . . . . . . . . . . . . . . 121
6
Aperçu du cours
Aperçu du cours
Bienvenue à l’analyse et la Conception Orientées-Objets
Ce module va vous enseigner, la façon dont vous devez utiliser efficacement les technologies
orientées objet et la modélisation du logiciel appliqué aux processus de développement de
logiciels tout en utilisant le langage de modélisation unifié UML ( Unified Modeling Language).
UML est le langage standard pour l’analyse et la conception orientée-objet. UML est utilisé
tout au long du cycle de vie de développement de logiciel pour prendre et communiquer
les décisions relatives à l’analyse et à la conception. En étudiant ce module, vous allez vous
rendre compte des avantages de l’utilisation d’un langage de modélisation graphique, pour
communiquer des concepts, des décisions, comprendre un problème, proposer la solution
adéquate et gérer la complexité des artefacts. Enfin, le module vous permettra de comprendre
les patrons et les règles qui contribueront à la création de composants logiciels réutilisables.
Prérequis
Programmation Orientée-Objet
Génie Logiciel
Matériaux
Les matériaux nécessaires pour compléter ce cours comprennent:
● Outils de modélisation tels que Visual Paradigm, ArgoUML, Visio, Smart Drawer
● Livres
● Support de cours
● Ordinateur et une connexion Internet
Objectifs du cours
À la fin de ce cours, l›étudiant devrait être en mesure de :
Concevoir des plans de qualité pour les systèmes de niveau entreprise qui
intègrent l’architecture et les modèles de conception en utilisant l’outil CASE
pour améliorer et faciliter la réalisation de ce processus
Développer la documentation d’appui pour les exigences, l’analyse, et les phases

de conception du projet de développement de logiciel à l’aide d’une méthode
d’analyse et de conception orientée (OOAD) utilisant le langage de modélisation
unifié (UML)
Créer les diagrammes UML selon différents contexte.
Faire correspondre la conception au code, définir une classe avec des méthodes
et des attributs simples, ajouter des attributs de référence, définir une méthode
à partir d’un diagramme de collaboration.
7
Démontrer l’importance des techniques d’analyse et de conception dans le développement de

systèmes logiciels au niveau de l’entreprise.
Unités
Unité 0: Évaluation diagnostique
Il s’agit d’une unité de pré-évaluation. Elle permettra d’évaluer les pré-requis pour ce module
et donc portera sur la programmation Orientée-Objet et le Génie Logiciel.
Unité 1 : Principes de la programmation orientée-objet
Cette unité se focalise sur les principes de la programmation orientée objet. Elle met
l’accent sur certains concepts importants comme : les classes, les objets, l’encapsulation, le
polymorphisme, l’héritage.
Unité 2: Principes de base de l’UML
Cette unité décrit le langage de modélisation unifié UML et son utilisation dans le processus
de développement de logiciel. L’accent sera mis sur les différents diagrammes UML.
Unité 3: Analyse orientée-objet
Cette unité expose les différentes étapes qui composent l’analyse orientée-objet, allant de la
collecte des besoins au diagramme des cas d’utilisation.
Unité 4: Conception orientée-objet et traduction dans un langage
Cette unité expliquera en quoi consiste la phase de conception d’un logiciel. Durant cette
phase le programmeur devra définir à quelle classe appartient chacune des méthodes définies
ainsi que les interactions entre les différents objets. Cette unité mettra également l’accent
sur les méthodes à utiliser pour passer des diagrammes au code (instructions écrites dans un
langage de programmation orienté-objet du choisi par le programmeur).
Évaluation
Les évaluations formatives (vérification de progrès) sont inclues dans chaque unité.
Les évaluations sommatives (tests et travaux finaux) sont fournies à la fin de chaque module et
traitent des connaissances et compétences du module.
Les évaluations sommatives sont gérées à la discrétion de l’établissement qui offre le cours. Le
plan d’évaluation proposé est le suivant:
1 Consultation matériaux et ressources 20 %

2 Exercices individuel ou en groupe 40 %
3 Evaluations Formatives et sommati- 40 %
ves
8
Aperçu du cours
Plan
Unité Sujets et Activités Durée estimée

Unité 0 : Eval- Connaissances de base 5 Heures
uation diag-
nostique
Unité 1 : Activité 1.1– Principes de l’orienté-ob- 25 Heures
Principes de jet
la program-
mation ori- Activité 1.2 – Concepts de la POO
entée-objet
Activité 1.3–Associations et liens
Unité 2 : Prin- Activité 2.1–Utilisation du langage 30 Heures
cipes de base UML dans l’Analyse et la Conception
en UML orientée objet
Activité 2.2– Diagrammes UML
Activité 2.3–Modèles UML

Unité 3 : Activité 3.1 – Comprendre les exi- 30 Heures
Analyse ori- gences
entée-objet
Activité 3.2 – Cas d’utilisation
Activité 3.3 – Modèle conceptuel
Activité 3.4 – Comportement du sys-

tème: diagrammes de séquence et
des opérations du système
Unité 4 : Activité 1.1 – Les diagrammes inter- 24 Heures
Conception actifs
orientée-objet
et traduction Activité 4.2 – Aperçu sur la phase de
dans un lan- conception
gage
Activité 4.3 –La conception du sys-
tème Terminal de point de vente
Activité 4.4 – Conception des dia-

grammes de classe
Activité 4.5 - Mise en œuvre / traduc-

tion des dessins dans les langages
de programmation orientée objet
Examens Examen de mi parcours et examen 5 Heures
final
9
Lectures et autres ressources

Les lectures et autres ressources dans ce cours sont indiquées ci-dessous.
Unité 0
Lectures et autres ressources obligatoires:
Brett McLaughlin, Gary Pollice, David West, Sophie Govaere, “Analyse et conception orientées
objet”, Mai 2007
Bjork R. C., (2004). ATM Simulation. ATM Online, URL: http://www.math-cs.gordon.edu/

courses/cps211/ATMExample/
Liu, Z. (2001, “Object-Oriented Software Development Using UML”, March, The United
University – International Institute for Software Technology (UNU/IIST), Report No. 229.
Nellen, T. and Mayo, L. (2000), “We Learn by Doing”, URL: http://english.ttu.edu/kairos/5.1/

coverweb/nellenmayo/doing.html.
Pascal Roques, UML 2 par la pratique: Etudes de cas et exercices corrigés, 5ème édition,
Eyrolles
Fien Van der Heyde, Laurent Debrauwer, UML 2 : Initiation, exemples et exercices corrigés, Eni.
Benoît Charroux, Aomar Osmani, Yann Thierry-Mieg, “UML 2”, collection Synthex , Pearson
Education , 3ème édition, 2010
Unité 1
Ariadne Training (2001), “UML Applied Object Oriented Analysis and Design Using the UML”,
Ariadne Training Limited
Liu Z., (2001), “Object-Oriented Software Development Using UML”, The United Nations
University, UNU-IIST International Institute for Software Technology, Tech Report 229.
Ojo A. and Estevez E., (2005), “Object-Oriented Analysis and Design with UML”, Training
Course, The United Nations University, UNU-IIST International Institute for Software Technology,
e-Macao Report 19, Version 1.0, October.
Eyrolles
Lectures et autres ressources optionnelles:
Sommerville Ian (2000), “Software Engineering (6th Edition)”. Addison-Wesley, Boston USA
10
Aperçu du cours
Unité 2
Larman C. (2004), “Applying UML and Patterns: An Introduction to Object-Oriented Analysis

and Design and Iterative Development”, (3rd Edition) 3rd Edition, Prentice Hall; 3 edition
(October 30, 2004), ISBN-13: 978-0131489066
Ojo A. and Estevez E., (2005), “Object-Oriented Analysis and Design with UML”, Training
Michael B., Rumbaugh J., “Modélisation et conception orientées objet avec UML 2 “, 2ème
édition, Pearson Education France, 2005.
Eyrolles
Booch G., Rumbaugh J. and Jacobson I. (1998), “Unified Modeling Language User Guide”,
Addison Wesley , First Edition October 20, 1998 , ISBN: 0-201-57168-4, 512 pages
Unité 3

(October 30, 2004), ISBN-13: 978-0131489066
Liu Z., (2001), “Object-Otiented Software Development Using UML”, The United Nations
Ojo A. and Estevez El., (2005), “Object-Oriented Analysis and Design with UML”, Training
11
Eyrolles
Pressman Roger S., (2001), “Software Engineering, A Practitioner’ S Approach” Fifth Edition,
McGraw-Hill Higher Education, ISBN 0073655783
Unité 4

(October 30, 2004), ISBN-13: 978-0131489066
Eyrolles
12
Unité 0. Évaluation Diagnostique

Introduction à l’unité
Lorsque l’on étudie le Génie Logiciel, il y a un certain nombre de connaissances de base
dont vous aurez besoin en tant qu’apprenant. Cette unité vous permettra de passer en revue
certaines connaissances de base à travers une évaluation.
Objectifs de l’unité
À la fin de cette unité, vous devriez être capable de :
Élaborer un ensemble d›activités dans le processus de développement logiciel.
Comparez les approches structurées et Orientées Objet de développement de logiciel.
Mettre en pratique l’approche orientée objet dans le développement du logiciel.
Termes clés
Processus logiciel : Un processus logiciel est un
ensemble d’activités et de résultats connexes. Lorsque
ces activités sont effectuées dans un ordre spécifique,
conformément aux contraintes, les résultats souhaités
sont produits.
Processus de développement logiciel : Un processus de

développement logiciel est souvent décrit comme un
ensemble d’activités nécessaires pour transformer les
besoins d’un utilisateur en un système logiciel.
Approche structurée de développement logiciel :

L’approche structurée permet d’analyser le problème,
puis de concevoir un ensemble de fonctions qui
peuvent effectuer les tâches requises. Si ces fonctions
sont trop importantes, alors elles sont décomposées
jusqu’à ce qu’elles soient assez petites à manipuler et
à comprendre.
Approche Orienté objet de développement logiciel : La

stratégie dans le développement de logiciel orienté
objet est de voir le monde comme un ensemble
d’objets. Ces objets interagissent et collaborent les
uns avec les autres pour fournir un comportement de
niveau supérieur.
13
Evaluation de l’unité
Partie I Questions sur les connaissances de base
1. Quels sont les 4 étapes fondamentales du développement de logiciel
2. Expliquer pourquoi nous avons besoin d’un processus de développement logiciel ?
3. Expliquer le processus de développement de logiciel, en particulier les exigences

qu’un bon processus de développement de logiciel doit remplir.
4. a) Quelles sont les méthodologies de développement logiciel que vous connaissez ?
5. b) Quelles sont les principales différences que vous pouvez souligner entre ces
méthodologies.
6. Pourquoi le développement Orienté Objet peut-il être mieux ?
Partie II Projet de développement

Dans cette section nous allons proposer trois projets que vous (étudiants) allez réaliser en
formant des groupes de travail de cinq étudiants. Un groupe choisit un projet parmi les trois
proposés ou peut également proposer son propre projet d’intérêt sous la supervision du
Professeur.
Les projets demandent que vous mettiez en pratique l’approche orientée objet dans le
développement du logiciel.
Projet 1:
Conception et implémentation d’un système basé sur le Web pour enregistrer

l’inscription des étudiants et fournir l’information sur les cours dans une université.
Projet 2:
Conception et implémentation d’un système qui permet l’enregistrement des

données sur le rendement des cours spécifiquement, les notes attribuées à
chaque élève dans chaque évaluation ou examen d’un cours, et le calcul de la
somme (pondérée) des notes pour obtenir les notes totaux du cours. Le nombre
d’évaluations/examens ne devraient pas être prédéfinis; ce qui permet l’ajout de
plusieurs évaluations/examens à tout moment. Le système devrait également
soutenir le classement, permettant de préciser des seuils pour les différents
grades.
Vous pouvez également l’intégrer avec le système d’inscription des étudiants du

projet 1 (peut-être mis en œuvre par une autre équipe de projet).
Projet 3:
Concevoir et implémenter un système basé sur le Web pour réserver les salles de
classe de votre université. Les réservations périodiques (jours/heures fixes chaque
14
semaine pendant tout un semestre) doivent être prises en compte. L’annulation

de cours spécifiques de la réservation périodique devrait également être prise
en compte.
Vous pouvez également l’intégrer avec le système d’inscription des étudiants du

projet 1 (peut-être mis en œuvre par une autre équipe de projet), de sorte que
les classes peuvent être réservées pour les cours et les annulations d’un cours ou
des cours extra peuvent être faites à partir d’une interface unique, et sera notifiée
dans la réservation concernant la classe et communiquée aux étudiants par e-mail.
Réponse
Partie 1
1. Il y a quatre étapes fondamentales communes à tous les processus logiciel:
i. Spécifications logicielles : La fonctionnalité du logiciel et les contraintes sur ses

opérations doivent être définies.
ii. Développement du logiciel : Un logiciel qui répond aux spécifications doit être
produit.
iii. Validation du logiciel : Le logiciel doit être validé (confirmé) pour s’assurer qu’il
fait ce que le client veut.
iv. Maintenance du logiciel: Le logiciel doit évoluer pour répondre aux besoins
changeants du client.
2. Le plus grand problème du génie logiciel est de faire en sorte que les développeurs
construisent un logiciel qui répond parfaitement aux exigences des utilisateurs.
Pour résoudre ce problème il est important d’appliquer un ensemble de méthodes
et de techniques permettant de développer et de maintenir des logiciels de qualité.
Entre autres, le suivi d’un processus de développement de logiciel va permettre
d’une part de maitriser la complexité et le coût d’un développement de logiciel et
d’autre part, d’augmenter la probabilité de réussite d’un projet de développement
de logiciel.
3. Le processus de développement logiciel est souvent décrit comme un ensemble

d’activités nécessaires pour transformer les besoins d’un utilisateur en un système
logiciel. Les exigences du client définissent le but du développement du logiciel.
Elles sont préparées par le client (parfois avec l’aide d’un ingénieur logiciel) et
définissent les services auxquels on s’attend à ce que le système fournisse, i.e. les
exigences fonctionnelles. Les exigences fonctionnelles indiquent ce que le système
doit faire plutôt que comment il est fait. Outre les exigences fonctionnelles, le
client peut également avoir des contraintes non-fonctionnelles qu’il voudrait placer
sur le système, tels que le temps de réponse nécessaire ou l’utilisation des normes
d’un langage spécifique.
15
4. a) Il existe plusieurs méthodologies de développement de logiciel qui sont utilisées.

Les deux approches les plus couramment utilisées sont : l’approche structurée
et l’approche orientée objet. Avant de discuter de ces deux approches, il est
important d’avoir une compréhension des terminologies similaires en rapport avec
la programmation informatique.
b) Quelques caractéristiques des langages procéduraux sont :
• L’accentuation est sur les tâches à faire

• Les grands programmes sont divisés en de petits programmes appelés
fonctions
• La plupart du temps, les fonctions partagent les données globales
• Les données se déplacent ouvertement autour du système d’une fonction à
une autre
• L’approche top-down est employée dans la conception du programme
Quelques caractéristiques des langages orientés objet sont :
• L’accent est mis sur les données plutôt que sur les fonctions
• Les programmes sont divisés en des objets
• Les structures de données sont conçues de telle sorte qu’elles caractérisent les
objets
• Les données sont masquées et ne peuvent être accédées par des fonctions
externes
• Les objets peuvent communiquer entre eux par les fonctions
• La programmation orientée objet suit l’approche bottom-up dans la conception
du programme
Bien que ces deux paradigmes décomposent un système :
• L’approche traditionnelle structurée se concentre sur ce qu’un système fait, i.e.

ses principales fonctions; ou sur les verbes qui décrivent le système. L’analyse
et la conception des systèmes orientés objet se concentrent sur ceux dont le
système est composé, à savoir ses principaux acteurs ou objets, ou les noms qui
décrivent le système
• En analyse structurée, l’analyste est préoccupé par les fonctions exécutées sur les
données; dans l’analyse et la conception orientées objet, l’analyste est concerné
par les objets exécutant les fonctions.
• Les deux approches sont concernées par les objets et les données, mais l’analyste
structurel les sépare en fonctions exécutées par les objets sur les données, tandis
que l’analyste OO les combine en un objet qui exécute des fonctions sur les
données.
16
Partie 2
Dans cette partie, étant donné que le résultat final est un logiciel, il faut s’assurer en plus
du langage utilisé (un langage orienté objet) que les différentes fonctionnalités soient
implémentées.

Liu, Z. (2001), “Object-Oriented Software Development Using UML”, March, The United
University – International Institute for Software Technology (UNU/IIST), Report No. 229.
Nellen, T. and Mayo, L. (2000), “We Learn by Doing”, URL: http://english.ttu.edu/kairos/5.1/

coverweb/nellenmayo/doing.html.
Bjork R. C., (2004), “ATM Simulation”, ATM Online”, URL: http://www.math-cs.gordon.edu/

courses/cps211/ATMExample/
17
Unité 1. - Principes de La
Programmation Orientée-Objet
Cette unité vous présente les principes de la programmation orienté objet: l’Abstraction, la
modularité, l’encapsulation et les concepts fondamentaux de l’orienté objet: objets, classes,
héritage et polymorphisme. L’unité met l’accent sur les associations et liens: l’association, la
composition, l’agrégation et la généralisation. Cette unité explique les notions de super
classes, de sous classes, et de multiplicité.
À la fin de cette unité, vous devriez être capable de:
• Expliquer les principes de l’orienté objet.

• Décrire les concepts fondamentaux de l’orienté objet.
• Démontrer l’utilisation de ces concepts sur les associations et liens.
Termes clés

Classe : Une classe n’est rien d’autre que la description
d’un ensemble d’objets ayant une structure commune
et disposant des mêmes méthodes.
Objet : Toute entité identifiable, concrète ou abstraite,

peut être considérée comme un objet. Un objet réagit
à certains messages qu’on lui envoie. Un objet est
une instance d’une classe.
L’encapsulation : c’est une technique permettant de

réunir des variables et des fonctions au sein d›une
même entité nommée classe.
L’héritage : cette technique permet de définir une

hiérarchie de classe. Chaque classe fille hérite des
méthodes et des données de ses «pères».
Le polymorphisme : Par ce principe, deux objets,

héritant une même méthode d›une classe parente,
peuvent réagir de façon différente à l›appel de cette
méthode.
18
Unité 1. - Principes de La Programmation Orientée-Objet
Activités d’apprentissage
Activité 1.1 Principes de l’orienté-objet
Présentation
Cette unité décrit les principes fondamentaux de l’orientée objet que vous devez comprendre
et qui serviront de tremplin pour le reste de l’unité.
Détails de l’activité
1.1.1 Principe 1 - Abstraction
L’abstraction est un modèle qui prend en compte les aspects les plus importants d’un système
donné, tout en ignorant les détails les moins importants. L’abstraction implique un savoir-faire
qui consiste à prendre en compte l’essentiel et à ignorer ce qui ne l’est pas. L’orienté objet
est une bonne abstraction du monde réel ; cela signifie que si le problème change (à savoir
les exigences changent, comme c’est presque toujours le cas), la solution devrait être plus
facile à modifier. Ojo and Estevez, (2005) indique que l’abstraction est le processus permettant
de se concentrer sur les aspects les plus importants, tout en ignorant les détails moins
importants. Elle permet la gestion de la complexité, en se concentrant sur les caractéristiques
essentielles qui font qu’une entité diffère des autres. La figure 1.1 montre un exemple
d’abstraction du traitement de commandes.
Figure 1.1: Exemple d’abstraction du traitement de commandes (Source: Ojo et Estevez, 2005)
1.1.2 Principe 2 – l’encapsulation
L’encapsulation, autorise uniquement l›instance qui possède un membre données à le modifier

ou à y accéder. L›objet chaise (et tous les objets en général) encapsule les données (les valeurs
d›attributs qui définissent la chaise), les opérations (les actions qui sont chargées de modifier
les attributs de la chaise), d’autres objets (des objets composites peuvent être définis), les
constantes (valeurs fixes), et d’autres renseignements connexes. L’encapsulation signifie que
l’ensemble de ces informations est empaqueté sous un nom et peut être réutilisé comme une
spécification ou un composant d’un programme. En d›autres termes, l›encapsulation cache
l’implémentation aux utilisateurs et aux clients (Ojo and Estevez, 2005). Les Clients dépendent
des interfaces comme le montre la figure 1.2 à par exemple.
Figure 1.2: Exemples d’interfaces Client (Source: Ojo et Estevez, 2005)
19
Les exigences de l’encapsulation impliquent:
• D’exposer le but d’un objet

• D’exposer les interfaces d’un objet
• De masquer l’implémentation qui définit le fonctionnement de l’objet en rendant
accessible seulement les interfaces
• De masquer les données appartenant à un objet qui définissent sa structure
et son comportement
• De masquer les données appartenant à un objet et qui permettent de suivre l’état
de l’objet.
Les avantages de l’encapsulation sont:
• Faciliter la séparation d’une interface de son implémentation, de sorte qu’une

seule interface puisse avoir plusieurs implémentations.
• Faire en sorte que les données contenues dans un objet ne puissent pas être
altérées par d’autres objets.
1.1.3 Principe 3 - Modularité
La modularité porte sur le processus de décomposition des systèmes complexes en de petits

morceaux, plus autonomes qui peuvent être gérés facilement. La modularité peut être effectuée en:
• Décomposant le problème en de plus petits sous-problèmes

• Essayant de résoudre chaque sous-problème séparément. Chaque solution est un
composant séparé qui comprend
• Une Interface: types et opérations accessibles de l’extérieur
• Une Spécification: fonctionnement et propriété bien définis de l’interface
• Une implémentation: structures de données et fonctions cachées de l’extérieur
La figure 1.3 ci-après est un exemple de modularité.
Figure 1.3: Système de traitement de commandes
20
1.1.4 Principe 4 - Hiérarchie
La hiérarchie est un arrangement des classes dans une structure arborescente. Dans cette
hiérarchie, un système complexe est composé de sous-systèmes interdépendants qui ont
à leur tour leurs propres sous-systèmes, et ainsi de suite, jusqu’à ce que le plus bas niveau
de composants élémentaires soit atteint. Figure 1.4 montre un exemple du principe de la
hiérarchie dans la programmation orienté objet.
Figure 1.4: Exemple de la Hiérarchie
Conclusion
Cette unité a mis l’accent sur les principes fondamentaux de la programmation orientée-objet.
Ces principes concernent l’abstraction, l’encapsulation, la modularité et la hiérarchie.
Evaluation
1. Quelle est la différence entre un objet et une classe ?
2. Lequel des modèles suivants A et B est plus abstrait? Justifier votre réponse.
3. Fournir un exemple d’encapsulation:
4. Identifier l’interface
5. Identifier l’implémentation
6. Décrivez la structure de votre organisation en utilisant le principe de la hiérarchie.
7. Inclure au moins trois niveaux.
8. Quels sont les quatre principes de base de la programmation orienté objet? Fournir

une brève description de chaque principe.
21
Activité 1.2 – Concepts de la POO
Présentation
Cette unité décrira les concepts de l’orientée objet. Nous aborderons les termes comme : les
objets, les classes, l’héritage et le polymorphisme. Nous mettrons l’accent sur les composantes
d’une classe, comment créer une hiérarchie de classe, comment créer des classes mères et des
classes filles et comment donner plusieurs rôles à une même méthode.
1.2.1 Concept OO 1 –Les Objets
Toute discussion portant sur l’ingénierie logicielle orientée objet doit commencer en abordant
l’expression « orienté objet ». Qu’est-ce qu’un point de vue orienté objet? Dans quels cas une
méthode est considérée comme orienté objet? Qu’est-ce qu’un objet? Tel que défini par Ojo
et Estevez(2005), l’orientation objet porte sur la visualisation et la modélisation du monde /
système comme un ensemble d’objets liés et interagissant entre eux. Les caractéristiques de
l’approche OO sont:
• L’univers est composé d’objets qui interagissent

• Décrire et concevoir des systèmes contenant des objets.
Les objets sont les entités d’exécution de base dans un système orienté objet. Ils peuvent
représenter une personne, un lieu, un compte, une base de données ou un objet que le
programme doit gérer. Ils peuvent également représenter des données définies par l’utilisateur
telles que les vecteurs, le temps et les listes. Un problème de programmation est analysé en
termes d’objets et cette analyse prend en compte la nature de la communication entre ces
objets. Les objets dans un programme doivent être choisis de telle sorte qu’ils correspondent
étroitement avec les objets du monde réel comme le montre la figure 1.5 (Ojo et Estevez,
2005).
Figure 1.5: Exemples d’objets du monde réel (Source: Ojo et Estevez, 2005)
Lorsqu’un programme est exécuté, les objets interagissent en envoyant des messages les uns
aux autres. Par exemple, si «étudiant» et «enseignant» sont deux objets dans un programme,
alors l’objet «étudiant» peut envoyer un message à l’objet « enseignant » pour demander
ses notes à un contrôle. Chaque objet contient des données et des instructions (code) pour
manipuler les données. Les objets peuvent interagir sans connaitre les détails des données ou
du code de l’autre.
22
Prenons un exemple d’un objet du monde réel. Chaise est un membre (le terme instance est
également utilisé) d’une plus grande classe d’objets que nous appelons mobilier. Un ensemble
d›attributs génériques peuvent être associés à chaque objet dans la classe mobilier (Par
exemple, tout mobilier a un coût, les dimensions, le poids, l›emplacement et la couleur,
parmi beaucoup d’attributs possibles). Ceci s’applique quand nous parlions d’une table,
d’une chaise ou d’un canapé. Etant donné que chaise est un membre/instance de mobilier,
chaise hérite tous les attributs définis pour la classe comme le montre la figure 1.8. Une fois
que la classe a été définie, les attributs peuvent être réutilisés lorsque de nouvelles instances
(objets) de la classe sont créées.
Figure 1.6: Les objets chaise et table sont des mobiliers
Dans le monde réel les objets peuvent être caractérisés par deux choses: leur état et les
traitements qu’ils peuvent subir. Chaque objet du monde réel possède des données et des
comportements. Les données pour un objet sont généralement appelés les attributs de
l›objet. Les différents comportements d›un objet sont appelées les méthodes
(ou traitements) de l›objet.
L’état d’un objet est l’ensemble des informations contenues/stockées dans l’objet. Il peut
changer au fil du temps. Il change aussi à la suite d’un traitement exécutée sur l’objet. Il ne
peut pas changer spontanément. L’état est encapsulé dans l’objet et n’est pas directement
visible. Les différentes composantes de l’état sont parfois appelés les attributs de l’objet. Un
traitement est une procédure qui à partir de l’état de l’objet et éventuellement de certains
arguments peut changer cet état et / ou retourner une ou plusieurs valeurs. Les objets
permettent certains traitements et pas d’autres.
1.2.2 Concept OO 2 - Classes
Une classe est tout simplement un modèle pour la création d’un objet. Une classe est
une description d’un ensemble d’objets connexes qui partagent les mêmes attributs,
traitements. Une classe décrit les attributs et méthodes qui existeront pour toutes les instances
de la classe. Une classe est simplement une description; elle n’existe pas vraiment en tant que
telle jusqu’à ce que vous déclarez une instance de la classe.
23
Les objets contiennent des données et du code pour manipuler ces données. L’ensemble des
données et le code d’un objet peut devenir un type de données défini par l’utilisateur lorsqu’il
est représenté sous la forme d’une classe. En fait, les objets sont des variables de type
classe. Une fois qu›une classe a été définie, nous pouvons créer un certain nombre d›objets
appartenant à cette classe. Les objets sont créés en utilisant la définition de la classe comme
modèle. Lorsqu’un objet est d’une classe donnée, il est associé aux données de cette
classe. Une classe est donc une collection d›objets du même type. Graphiquement, une classe
est assimilée à un rectangle. Voici un concept important à retenir - la classe que vous créez ne
peut rien faire jusqu›à ce que vous l›utilisiez.
Un nom de classe doit être unique dans son empaquetage. Chaque classe doit avoir un
nom qui le distingue des autres classes. Un nom de classe est une chaîne de texte. Ce nom
est appelé un nom simple; un nom de chemin est le nom de la classe préfixé par le nom
du paquet dans lequel évolue cette classe. Une classe peut être représentée ne montrant que
son nom comme le montre la figure 1.7 à titre d›exemples.
Figure 1.7: Exemples de noms de classe
Un attribut est une propriété nommée d’une classe qui décrit une plage de valeurs que les
occurrences de la propriété peuvent détenir. Une classe peut avoir un nombre quelconque
d›attributs ou pas d’attribut du tout. Un attribut représente une propriété de la chose que vous
modélisez qui est partagée par tous les objets de cette classe. Un nom d›attribut peut être du
texte. Dans la pratique, un nom d›attribut est un nom court ou un nom nominal qui représente
une propriété de sa classe englobante. En général, la première lettre de chaque mot dans un
nom d›attribut est en majuscule, sauf la première lettre, comme dans nom ou porte-Bagage
Un traitement est l’implémentation d’un service qui peut faire l’objet d’une requête provenant
de n’importe quel objet de la classe en vue de modifier le comportement de l’objet. En
d’autres termes, un traitement est une abstraction de quelque chose que vous pouvez faire à
un objet et qui est commun à tous les objets de cette classe. Une classe peut avoir un nombre
quelconque de traitements ou pas de traitements du tout. Un nom de traitements peut être du
texte. Dans la pratique, un nom de traitements est un verbe qui représente un comportement
de sa classe englobante. En général, la première lettre de chaque mot dans un nom de
traitements est en majuscule, sauf la première lettre, comme dans déplacer ou estVide. Figure
1.8 montre un exemple d›une classe et d›objets liés.
24
Figure 1.8: La classe imprimante avec sa liste d’objets (Source: Ojo et Estevez, 2005)
1.2.3 Concepts OO 3 - Héritage
L’héritage est un des concepts clés qui différencient les systèmes conventionnels (structuré)
et l’OO. Une sous-classe Y hérite de tous les attributs et les opérations associées à sa
superclasse, X. Cela signifie que toutes les structures de données et algorithmes à l’origine
conçus et mis en œuvre pour X sont immédiatement disponibles pour Y sans qu’aucune
action supplémentaire ne soit requise. Les structures de données et algorithmes peuvent être
réutilisés automatiquement. Toute modification des données ou des opérations contenues
dans une superclasse est immédiatement hérité par tous les sous-classes qui ont héritées de
la superclasse. Par conséquent, la hiérarchie des classes devient un mécanisme à partir duquel
les modifications (à des niveaux élevés) peuvent être immédiatement propagées à travers un
système.
L’héritage est le processus par lequel les objets d’une classe acquièrent les propriétés des
objets d’une autre classe. Il prend en charge le concept de classification hiérarchique. Par
exemple, le petit-fils est une partie de la class parent qui est encore une partie de la classe
grand-parent. En programmation orientée objet, le concept d’héritage entraîne l›idée de
réutilisation. Cela signifie que nous pouvons ajouter des fonctionnalités supplémentaires à une
classe existante sans la modifier. Ceci est possible en obtenant une nouvelle classe à partir de
celle qui existe.
En C ++, la classe d’origine est appelée une classe de base et la classe qui a acquis les
caractéristiques de la classe de base est appelée classe dérivée. La nouvelle classe aura les
caractéristiques combinées des deux classes. La puissance du mécanisme d›héritage est qu›il
permet au programmeur de réutiliser une classe. Ce qui signifie que l›héritage favorise le
partage et la réutilisation des informations de conception et du code du programme.
1.2.4 Concept OO 4 - Polymorphisme
Le polymorphisme est un autre concept important de la POO. C’est la capacité pour un objet

à prendre plus d’une forme. Par exemple, un traitement peut avoir un résultat différent selon
les cas. Le résultat dépend des types de données utilisés dans le traitement. Par exemple,
considérons l’opération d’addition.
Pour deux nombres, ce traitement va générer une somme
Si les opérandes sont des chaînes, le traitement produira une troisième chaîne par
concaténation
Cela signifie qu’un seul nom de la fonction peut être utilisé pour gérer un nombre différent et
25
différents types d’arguments. Ceci est quelque chose de semblable à un mot particulier ayant
plusieurs significations différentes selon le contexte.
Les classes dérivées peuvent redéfinir la mise en œuvre d’une méthode.
Exemple :
Considérez une classe “Transport”
Une méthode appelée deplacer() par example, doit être contenue dans la classe Transport
parce que tous les objet de la classe Transport doivent être en mesure de se déplacer
Si nous voulons créer un bateau et une classe de voitures, nous voudrions certainement hériter
de la classe transport, comme tous les bateaux peuvent se déplacer et toutes les voitures
peuvent se déplacer, même si c’est de différentes façons.
Evaluation
1. Répondre par Vrai ou faux? Pour celle qui sont fausses, expliquer pourquoi.
2. Stagiaire est un exemple de classe.
3. Dora Cheong est un exemple de classe.
4. createJob est un exemple d’objet.
5. deleteFile est un exemple d’opération
6. prénom est un attribut
7. Supposons que nous voulons modéliser une demande de délivrance de certificats

d’enregistrement d’affaires Identifier:
8. Définir trois classes pour le modèle.
9. Définir au moins trois attributs pour chaque classe
Activité 1.3 - Associations et liens
Présentation
Une classe n’a pas d’utilité en elle-même. Un logiciel avec de nombreuses fonctionnalités
peut avoir des milliers de classes. Les objets des différentes classes doivent être liés les uns
aux autres, interagir et de collaborer pour mener à bien les processus. Les relations entre
les objets (connus sous le nom des associations) sont représentées par des lignes reliant les
objets. L’association exprime les relations entre les classes et définit les liens entre les instances
de la classe (objets). Un lien exprime une relation entre les objets. Il existe quatre types de
relations entre les classes:
• Association Agrégation
• Composition Généralisation
26
1.3.1.1 Association
C’est la relation la plus simple entre les classes. C’est une relation d’égal à égal. C’est une
relation structurelle décrivant un ensemble de liens. Les liens sont des connexions entre les
objets. Les liens sont implémentés dans les objets en utilisant des références. Une association
est une relation entre deux ou plusieurs classes et implique une connexion entre les
instances. Les associations entre les classes A et B peuvent être:
1. A est une partie physique ou logique de B

A est semblable à B
2. A est contenue dans B
3. A est une description de B
4. A est un élément de B
5. A est une sous-unité B
6. A utilise ou gère B
7. A communique avec B
8. A suit B
9. A appartient à B
Exemple: Personne travaille pour Société
1.3.1.2 Agrégation
Une agrégation est une association qui représente une relation d’inclusion structurelle ou
comportementale d’un élément dans un ensemble. Les objets sont rassemblés pour créer un
objet plus complexe. Ce rassemblement peut être physique ou logique. L’agrégation définit un
point de contrôle unique pour les objets qui y participent. L’objet issu de l’agrégation gère les
différents objets qui composent l’agrégation. L’agrégation est représentée comme un diamant
creux, pointant à la classe qui est utilisé.
Exemple 1:
Un processeur fait partie d’un ordinateur.
CPU, périphériques, moniteur et le clavier sont assemblés pour créer un ordinateur
27
Figure 1.9: Liens d’agréation entre un ordinateur est ses composantes ou périphériques
Exemple 2 :
Un moteur fait partie d’une voiture
Figure 1.10: Liens d’agréation entre un moteur est un véhicule
1.3.1.3 Composition
La composition est une agrégation composite. La durée de vie des objets individuels dépend
de la durée de vie de l’objet global. Aucune partie de la composition ne peut exister par elle-
même. Une classe composite est construite à partir d’autres classes. La classe a besoin d’un ou
de plusieurs autres classes pour exister. La composition est représentée par un diamant solide
Exemple:
Un mot ne peut pas exister si elle ne fait pas partie d’une ligne.Si un paragraphe est supprimé,
toutes les lignes de l’alinéa sont supprimées, et tous les mots appartenant à ces lignes sont
supprimés.
Si un document est supprimé, tous les paragraphes le composant disparaissent.
Figure 1.11: Liens d’agréation de composition
1.3.1.4 Héritage ou Généralisation
La généralisation est aussi appelé relation “d’héritage”. Une généralisation est la relation entre
une classe générale et une ou des classes plus spécialisés. Dans une relation de généralisation,
les spécialisations sont appelées sous-classe et la classe généralisée est appelée la
superclasse. Une généralisation permet l›héritage des attributs et des opérations d›une
superclasse par ses sous-classes.
C’est équivalent à une relation: « genre de » or « type de ».
L’héritage ou la généralisation est décrite comme une relation parent / enfant, où une classe
enfant hérite de tous les attributs et méthodes d’une classe, et ajoute ses propres attributs et
méthodes pour créer un nouveau comportement. L’héritage est représenté comme une flèche
28
triangulaire creuse, dirigée vers la classe parente.
1.3.2 Super classe et Sous classe
Une super-classe est une classe qui contient les caractéristiques communes à deux ou plusieurs
classes. Une super classe est similaire à un sur-ensemble, par exemple, personnel-agence. Une
sous-classe est une classe qui contient au moins les attributs et méthodes de sa (ses) super-
classe(s). Une classe peut être une sous-classe et un super classe en même temps.
Figure 1.10: Exemple de lien d’héritage
Figure 1.11: Exemple de super classe et sous classe
1.3.3 Multiplicité
La multiplicité montre le nombre d’objets d’une classe pouvant être associées à un objet d’une
autre classe. Exemple: Un citoyen peut demander une ou plusieurs licences, et une licence est
requise par un citoyen.
Figure 1.12: Exemple de multiplicité entre deux classes
29
Figure 1.12: Exemple de la multiplicité
Conclusion
Comme l’a déclaré Liu, (2001), le but d’une association et d’un lien entre deux objets
est d’établir diverses sortes de relation, et donc des classes peuvent avoir toutes sortes
d’associations dans un domaine d’étude. Les objectifs que doit remplir toute association sont
les suivantes:
• Une association entre deux classes doit fournir des connexions physiques ou
conceptuelles entre les objets de ces classes.
• Seuls les objets qui sont associés entre eux peuvent collaborer les uns avec les
autres à travers les liens.
• Booch décrit le rôle d’une liaison entre les objets de la manière suivante:
• “Un lien représente l’association spécifique par lequel un objet (le client) applique
les services d’un autre objet (le fournisseur), ou par lequel un objet peut accéder
à un autre”.
Evaluation
1. Ces affirmations sont-elles vraies ou fausses ? Pour celles qui sont fausses, expliquer
pourquoi.
i. Il existe une association entre Stagiaire et Cours
ii. Il y a une composition entre Cours et Professeur
iii. Il existe une agrégation entre Cours et Lieu
2. Supposons que nous voulons modéliser une application e-service pour un organisme
gouvernemental. Est-ce que ce schéma modélise raisonnablement la relation entre
30
les entités Utilisateur, Employé, EmployéServiceClientèle, EmployéServiceAdministratif,

et Demandeur? Si non, proposez un modèle plus approprié.
3. Ajouter une généralisation pour les classes définies dans l’évaluation 1.3.6 (2)
i. Identifier la super-classe et une sous-classe.
ii. Y a-t-il une classe abstraite? Justifier.
iii. Quel facteur d’élimination est utilisé dans votre hiérarchie de généralisation?
4. Considérons la hiérarchie de généralisation prévue dans l’évaluation 3 ci-dessus.
i. Ajouter une opération à la super classe qui pourrait être implémentée de

différentes manières par ses sous-classes.
ii. Donner un exemple de polymorphisme. Expliquez.
5. Nommez les 4 relations de base en UML et décrire chacune d’elles
Résumé de l’unité
Un objet est toute abstraction qui modélise quelque chose dans l’univers ayant des
propriétés et des comportements. Une classe est une abstraction d’un ensemble d’objets
liés logiquement ayant des caractéristiques semblables. Les classes peuvent être liées
par les types de relations suivantes: association, agrégation, composition, héritage ou
généralisation. Les concepts de l’orienté objet comprennent: les objets, les classes, l’héritage
et le polymorphisme. La POO est caractérisée par quatre principes fondamentaux: l’abstraction,
encapsulation, la modularité et la hiérarchie.Cela peut être considéré comme un critère pour
déterminer si deux objets doivent être liés.
31
Évaluation de l’unité
1. Définissez les termes suivants
i. Abstraction (1 point)
ii. Polymorphisme (1 point)
iii. instanciation (1 point)
2. Expliquer l’importance de la modélisation dans le développement de systèmes

logiciels OO. Donnez des exemples concrets si nécessaire (3 points)
3. La modularité est un aspect important dans le développement de logiciels. Il

permet le partitionnement de la conception de logiciels en morceaux qui
sont regroupés ou séparés. Pourquoi est-il important d’adopter une approche
modulaire pour le développement de logiciels? (2 points)
4. Le masquage d’information exprime l’idée qu’un module cache certains aspects

de son fonctionnement interne à d’autres modules. (2 points)
5. Quel autre terme (unique) désigne le masquage d’information
6. Pourquoi le masquage d’information est-il important?
• Ariadne Training (2001), “UML Applied Object Oriented Analysis and Design
Using the UML”, Ariadne Training Limited
• Liu Z., (2001), “Object-Oriented Software Development Using UML”, The United
Nations University, UNU-IIST International Institute for Software Technology, Tech
Report 229.
• Ojo A. and Estevez E., (2005), “Object-Oriented Analysis and Design with UML”,
Training Course, The United Nations University, UNU-IIST International Institute for
Software Technology, e-Macao Report 19, Version 1.0, October.
• Pascal Roques, UML 2 par la pratique: Etudes de cas et exercices corrigés, 5ème
édition, Eyrolles
• Fien Van der Heyde, Laurent Debrauwer, UML 2 : Initiation, exemples et exercices
corrigés, Eni.
• Benoît Charroux, Aomar Osmani, Yann Thierry-Mieg, “UML 2”, collection Synthex
, Pearson Education , 3ème édition, 2010
• Sommerville Ian (2000), “Software Engineering (6th Edition)”. Addison-Wesley,
Boston USA
32
Unité 2: Principes de Base en UML

Le langage UML (Unified Modeling Language) est universellement accepté et utilisée dans la
conception de logiciels. Ce langage tient lieu de norme en matière de modélisation. UML est
le langage visuel utilisé pour transmettre des idées de conception, il met l’accent sur la façon
dont les développeurs appliquent les outils UML dans le processus de développement de
logiciels.
À la fin de ce module, vous devriez être capable de:
• Définir UML
• Décrire le but d’UML
• Énumérer et décrire les diagrammes UML statiques et dynamiques
• Identifier les phases du processus de développement auquel appartient chaque
diagramme UML
Termes clés
UML
Langage de modélisation unifié (UML) est un langage

de modélisation graphique qui fournit une syntaxe
pour décrire les principaux éléments (appelés
artefacts en UML) de systèmes logiciels.
La modélisation
La modélisation est la conception d’applications

logicielles qui se fait avant mise en œuvre dans un
langage de programmation particulier. Un modèle est
une représentation ou une simplification de la réalité.
Diagramme
Un diagramme est la représentation graphique d’un

ensemble d’éléments. Les diagrammes servent à
visualiser un système à partir de différents points de
vue, par conséquent un diagramme est un aperçu
d’un système.
33
Activité 2.1 –Utilisation du langage UML dans l’Analyse et la Conception

orientée objet
Présentation
Le modèle permet donc de spécifier le système à réaliser/réalisé, de valider le modèle vis-à-vis

des clients, de fournir un guide pour la construction du système pour organiser les structures de
données et le comportement du système, et de documenter le système et les décisions prises.
Nous introduisons dans cette activité, la notation UML, qui est actuellement la plus utilisée.
Avant de passer à la première phase du processus de développement, il est important de
comprendre le fonctionnement du processus de développement avec la notation UML.
2.1.1 Normes en matière de modélisation
Pendant de nombreuses années, le terme objet orienté (OO) a été utilisé pour désigner
une approche de développement de logiciel qui utilise un certain nombre de langages de
programmation orientés objet (par exemple, Java, C ++). Aujourd’hui, le paradigme OO
englobe une vue complète de l’ingénierie logicielle.
La norme pour ce qui est d’analyser et de concevoir des systèmes voudrait que l’on modélise
d’abord le système avant de l’implémenter. La modélisation est une technique d’ingénierie
éprouvée et bien acceptée. La modélisation peut être fait mathématiquement ou par toute
autre notation acceptée et comprise par les ingénieurs du même domaine à travers le monde
L’ingénierie logicielle ne disposait pas d’une telle notation. Entre 1989 et 1994, plus de 50
langages de modélisation de logiciels étaient utilisés - chacun d’entre eux comportant leurs
propres notations. Chaque langage avait une syntaxe qui lui était propre, tandis que dans le
même temps, chaque langage partageait des similitudes avec les autres langages, et pour ne
rien arranger aucun de ces langages n’était complet.
2.1.2 Historique du langage UML
Dans le milieu des années 1990, trois méthodes ont émergé du lot. Ces trois méthodes ont
commencé à converger, à fusionner. Chaque méthode a ses propres atouts:
• Booch était excellent pour la conception et la mise en œuvre. Grady Booch avait

été un acteur majeur dans le développement des techniques orientées objet.
• Object Modeling Technique (OMT) était le mieux adapté pour l’analyse des
systèmes d’information à données intensives.
• Object Oriented Software Engineering (OOSE) a présenté un modèle connu
sous le nom de cas d’utilisation. Les Cas d’utilisation sont un puissant outil
pour comprendre le comportement de tout un système (un aspect où l’OO est
traditionnellement défaillant).
34
Ainsi, le Unified Modelling Language (UML) est en grande partie le produit de trois ingénieurs
logiciels bien connus, - GradyBooch, Ivar Jacobson et James Rumbaugh. En 1994, James
Rumbaugh, le créateur de OMT rejoint Grady Booch à Rational Corp. L’objectif du partenariat
est de fusionner leurs idées en une seule méthode unifiée. En 1995, le créateur de OOSE,
Ivar Jacobson, avait également rejoint Rational, et ses idées (en particulier la notion de «cas
d’utilisation») ont été introduits dans la nouvelle méthode unifiée - maintenant appelé Unified
Modeling Language.
Le langage de modélisation unifié ou UML est un langage de modélisation graphique visant

à fournir la syntaxe pour décrire les principaux éléments des systèmes de logiciels (appelés
artefacts dans le UML 0). L’UML représente une collection des meilleures pratiques d’ingénierie
qui ont fait leurs preuves dans la modélisation des systèmes complexes. Dans ce cours, nous
avons besoin d’explorer les principaux aspects de l’UML, et de décrire la façon dont l’UML
peut être appliqué à processus de développement de logiciels.
3.1.3 Qu’est-ce que UML?
Le langage de modélisation unifié (UML) est un moyen standard pour spécifier, construire, et
documenter un système développé en utilisant l’approche orientée objet. UML est un langage
graphique pour capturer les artefacts du développement de logiciels. UML est le standard de
facto pour la modélisation orientée objet. Ainsi :
L’UML est un langage de visualisation:
Pour de nombreux programmeurs, il suffit de penser à une implémentation pour la traduire

aussitôt en code. En fait, certaines idées sont plus claires quand on en écrit le code.
L’UML est un langage de spécification:
Spécifier signifie construire des modèles qui sont précis, sans ambiguïté, et complèts. En
particulier, l’UML aborde la spécification de toutes les décisions importantes d’analyse,
de conception et de mise en œuvre qui doivent être faits dans le développement et le
déploiement d’un système logiciel.
L’UML est un langage de construction:
L’UML n’est pas un langage de programmation visuel, mais ses modèles peuvent être reliés
directement à une variété de langages de programmation. Cela signifie qu’il est possible de
faire correspondre un modèle UML à des éléments d’un langage de programmation tel que
Java, C ++, Visual Basic ou PHP, ou même à tables dans une base de données relationnelle ou
à une base de données orientée objet.
Les éléments qui s’expriment le mieux graphiquement sont font graphiquement dans
l’UML, alors que les ceux qui sont mieux exprimés textuellement le sont dans le langage de
programmation. Cette correspondance améliore la conception: la génération de code à partir
d’un modèle UML dans un langage de programmation.
35
L’UML est un langage de documentation:
Les livrables d’un développement logiciel digne du nom sont de toutes sortes. En dehors du
code exécutable brut, on a (mais la liste n’est pas exhaustive): Exigences, architecture, code
source, des plans de projet, tests, prototypes, les versions.
En fonction de la culture de développement, certains de ces livrables sont traités plus

formellement que d’autres. Ces livrables sont également essentielles pour contrôler, jauger et
communiquer sur un système au cours de son développement et après son déploiement.
L’UML se charge de la documentation de l’architecture d’un système dans les moindres

détails. L’UML fournit également un langage pour l’expression des besoins et pour les
tests. Enfin, l’UML fournit un langage de modélisation des activités de planification de projet et
la gestion des versions.
L’UML peut aussi être vu comme un langage de communication. Ainsi il permet de transmettre

des idées ou de communiquer avec des utilisateurs. La modélisation graphique peut aider
les utilisateurs (techniciens ou non) à comprendre un logiciel. Dans le développement de
logiciels, les aspects qui nécessitent une communication sont entre autres la collecte des
besoins, la conception, la mise en œuvre et le déploiement. UML est un langage conçu pour
communiquer sur ces choses.
Comme pour tout langage, l’UML a sa propre notation et sa syntaxe. UML ne dit pas comment
développer des logiciels. Il peut être appliqué dans tous les processus de développement
de logiciels. Sa notation comprend un ensemble de formes conçues pour la construction
de différents types de diagrammes. Chaque forme a une signification particulière. UML est un,
langage générique très vaste permettant représenter les aspects clés d’un développement de
logiciels.
D’après Ojo and Estevez, (2005) les objectifs de UML sont les suivants:
• Fournir un langage de modélisation visuel pour concevoir, développer et

échanger des modèles ayant un sens
• Fournir des mécanismes d’extensibilité et de spécialisation pour étendre les
concepts de base
• Promouvoir les spécifications qui ne sont pas propres à un langage de
programmation ou à des processus de développement en particulier
• Etre une référence pour comprendre les langages de spécification
• Encourager la croissance du marché des outils de l’orienté objet
• Prise en charge d’un niveau de développement comprenant des concepts tels
que les « frameworks » ou les « patterns »
2.1.4 Modéliser avec UML
La modélisation est la conception d’applications logicielles. Elle se fait avant le

codage (mise en œuvre dans un langage de programmation particulier). Un modèle est
une représentation ou une simplification de la réalité. Il fournit un schéma d’un système. Un
36
modèle ne dicte pas ou ne montre pas comment l’implémentation sera faite. Il indique juste
le qui, le quoi, le où, le quand etc. La conception basée sur les modèles mets l’accent sur la
schématisation des modèles d’un système afin de documenter et de valider l’existant et / ou le
nouveau système proposé. En fin de compte, le modèle devient le patron pour la conception
et la construction d’un système amélioré.
La modélisation est au centre de toutes les activités conduisant à la mise en place d’un bon
déploiement de logiciel.
Nous construisons des modèles pour les raisons suivantes:
• Montrer le résultat escompté : la structure et le fonctionnement du nouveau

système.
• Visualiser et contrôler l’architecture du système.
• Mieux comprendre le système que nous construisons, tout en explorant les
possibilités de simplification et de réutilisation.
• Gérer les risques.
• Gérer la complexité.
• Prévoir la Réutilisation.
La Modélisation :
• Les fonctionnalités du système sont complètes et marchent comme il faut.

• Besoins des utilisateurs finaux sont adressés, et
• La conception du programme répond aux exigences en termes d’évolutivité,
de robustesse, de sécurité, d’extensibilité. Tout cela doit être vérifié avant
l’implémentation avec du code
Il y a beaucoup d’éléments qui contribuent à un déploiement logiciel réussi; un dénominateur

commun est l’utilisation de la modélisation. La modélisation est une technique d’ingénierie
éprouvée et bien acceptée. On note trois éléments de base: Les éléments qui sont les
principaux acteurs du modèle, les relations qui lient les éléments ensemble et les schémas. Ces
éléments sont utilisés pour représenter des structures complexes.
2.1.5 Principes de modélisation
L’utilisation de la modélisation a une histoire riche dans toutes les disciplines de

l’ingénierie. Cette expérience suggère quatre principes de base de la modélisation.
Le choix du modèle à créer a une profonde influence sur la façon dont un problème est abordé
et comment la solution est façonné.
En d’autres termes, il est essentiel de bien choisir vos modèles. Lorsque les modèles sont bien
choisis, les problèmes de développement les plus complexes sont mieux cernés; par contre
mal choisir ses modèles pourrait vous induire en erreur, vous amenant à vous concentrer sur
des questions non pertinentes.
37
Chaque modèle peut avoir différents niveaux de précision.
Les meilleurs types de modèles sont ceux qui vous permettent de choisir le niveau de détail
que vous désirez, selon la personne qui analyse le modèle et ce que cette personne a
besoin de voir. Un analyste ou un utilisateur final voudront se concentrer sur la solution; un
développeur va vouloir se concentrer sur comment la solution est obtenue. Ces deux
intervenants voudront visualiser un système à différents niveaux de détail à des moments
différents.
Les meilleurs modèles tiennent compte de la réalité.
Dans les techniques d’analyse structurée le fait qu’il y a un décalage fondamental entre le
modèle d’analyse et le modèle de conception d’un système. A défaut de combler ce gouffre,
le système conçu et le système construit en viendront à diverger au fil du temps. Dans les
systèmes orientés objet, il est possible de se connecter toutes les vues presque indépendants
d’un système en un seul ensemble sémantique.
Aucun modèle n’est autosuffisant. Chaque système est mieux représenté par un petit
ensemble de modèles quasi indépendants.
Pour comprendre l’architecture du système logiciel orienté objet, vous avez besoin d’avoir des
aperçus complémentaires et inter liés: un cas d’utilisation (exposant les exigences du système),
un aperçu de la conception (capturant le problème et la solution), un aperçu des processus
(modélisation de la distribution des processus et des threads du système), un aperçu de
l’implémentation (concernant la réalisation physique du système), et un aperçu du déploiement
(qui met l’accent sur les questions d’ingénierie système). Chacune de ces vues peuvent
représenter des aspects structurels ou fonctionnels. Ensemble, ces vues représentent le plan
du logiciel.
Conclusion
Cette activité s’est évertuée à vous faire comprendre les réels motifs de la modélisation et ses
différents principes sans oublier de donner avant tout l’historique du langage UMSL et sa définition.
Evaluation
1. Pourquoi et comment modéliser en orienté objet ?
2. Pourquoi dit-on qu’un modèle est une abstraction d’objets de la réalité ?
3. Citez deux principes de base de la modélisation.
4. Expliquer l’expression suivante : UML est un langage pour :
i. Visualiser
ii. Spécifier
iii. Construire
iv. Documenter
38
Activité 2.2- Diagrammes UML
Présentation
Un diagramme est la représentation graphique d’un ensemble d’éléments qui représentent

des choses ainsi que les relations qui lient ces éléments. On dessine des diagrammes pour
visualiser un système à partir de différents points de vue, de sorte qu’un diagramme est un
aperçu d’un système. UML dispose de beaucoup de différents diagrammes (modèles). Ces
différents diagrammes servent à envisager un système à partir de plusieurs perspectives. UML
est un langage graphique qui comprend des schémas (modèles) dont les neufs principaux que
nous étudierons dans ce module de cours sont:
1. Diagramme de classe
2. Diagramme d’objets
3. Diagramme de cas d’utilisation
4. Diagramme de Séquence
5. Diagramme de collaboration
6. Diagramme d’état transition
7. Diagramme d’activités
8. Diagramme de composants
9. Diagramme de Déploiement
Ces neuf diagrammes peuvent être divisés en deux catégories
Quatre de ces diagrammes représentent la structure de statique de l’application:
• Diagramme de classes
• Diagramme d’objets
• Diagramme de composants
• Diagramme de Déploiement
Cinq de ces diagrammes représentent les aspects dynamiques de l’application:
• Diagramme de cas d’utilisation

• Diagramme de séquence
• Diagramme d’activités
• Diagramme de collaboration
• Diagramme d’état transition
• Détails de l’activité
39
2.2.1 Le diagramme de classes
En conception orienté objet, une classe a un nom, un ensemble de méthodes (également

connu sous le nom d’opérations) et des données liées (également connu sous le nom des
attributs). La classe en elle-même n’est pas très utile. Un système logiciel peut avoir des
milliers de classes, la modélisation des relations entre ces classes est ce qui définit réellement
le comportement du système.
Figure 2.1: Représentation graphique d’une classe
Les interactions entre les classes se répartissent en quatre grandes catégories (décrits
précédemment).
• Association
• Héritage encore appelé généralisation
• Composition
• Agrégation
Les diagrammes de classes montrent un ensemble de classes, des interfaces, des

collaborations et les relations entre elles. Les diagrammes de classes sont les diagrammes les
plus courants dans la modélisation des systèmes orientés objet. Il est un aspect essentiel de
toute méthode de conception orientée objet.
Les diagrammes de classes donnent un aperçu de la conception statique d’un système. Ils sont
utilisés à l’étape de l’analyse ainsi qu’à la conception. Les diagrammes de classes sont utilisés
pour créer le modèle conceptuel lequel est compréhensible par quiconque. Associé aux cas
d›utilisation, un schéma conceptuel est une technique puissante dans l›analyse des besoins. La
figure 2.2 montre un exemple d’un diagramme de classe.
40
Figure 2.2: Exemple d’un diagramme de classes
2.2.2 Diagramme d’objets
Les diagrammes d’objets montrent un ensemble d’objets et leurs relations. Ce sont des
captures instantanées d’éléments trouvés dans les diagrammes de classes. La figure 2.3 montre
un exemple d’un diagramme d’objets.
Figure 2.3: Exemple d’un diagramme UML de l’objet
41
2.2.3 Diagramme de cas d’utilisation
Les cas d’utilisation sont des techniques polyvalentes et utiles pour décrire les besoins des
utilisateurs. Un cas d’utilisation est une description de haut niveau d’une exigence majeure
de l’utilisateur. Elle représente la fonctionnalité du système. Il est décrit le comportement du
système du point de vue de l’utilisateur et constitue une interaction avec le système initié par
un utilisateur ou un autre système.
Les diagrammes de cas d’utilisation donnent un aperçu statique du système. Les personnes

et / ou les dispositifs (appelés acteurs) qui interagissent avec le système sont identifiés avec
les fonctions qu’ils exercent ou qu’ils initient. Un diagramme de cas d’utilisation montre un
ensemble de cas et d’acteurs (un cas particulier de classe) et leurs relations. Ces diagrammes
sont particulièrement importants dans l’organisation et la modélisation des comportements
d’un système. Ils sont une aide précieuse lors de l’analyse, puisque le développement des
cas d’utilisation permet de mieux comprendre les exigences. Cas d’utilisation et modèle
conceptuel sont des outils puissants dans l’analyse des besoins. Voici quelques termes utilisés
lors de la représentation des diagrammes de cas d’utilisation :
i. Cas d’utilisation
Figure 2.4: Exemple de cas d’utilisation
L’acteur représente un utilisateur du système, ou tout autre système externe qui interagit avec
le système.
Le cas d’utilisation représente une fonctionnalité qui est importante pour l’utilisateur. La plupart
du temps, nous voyons l’acteur comme un utilisateur humain, mais il peut aussi représenter un
système ou un autre artefact non humain
ii. La Relation « Uses »
Cette fonction encourage la réutilisation. Si un cas d’utilisation a besoin de la fonctionnalité

d’un autre cas d’utilisation dans le but d’accomplir sa tâche, il “utilise” le 2ème cas
d’utilisation. La relation est dessinée comme une ligne avec une flèche pointant vers le cas de
l’utilisation qui est “utilisé”.
42
Figure 2.5: Exemple de cas d’utilisation avec la relation <<include>>
iii. La relation « Extends »
La notation « Extends » étend les fonctionnalités d’un cas d’utilisation pour gérer des erreurs
ou des exceptions. La relation « Extends » est utilisée quand il y a un cas d’utilisation qui est
similaire à un autre, mais en fait un peu plus. La relation est dessinée comme une ligne avec
une flèche pointant vers le principal cas d’utilisation.
Une relation « Extends » se doit de:
• Capturer le cas simple et normalen premier

• Pour chaque étape de ce cas d’utilisation, demander «Qu’est-ce qui pourrait aller
mal ici» et «Comment cela pourrait-il fonctionner différemment?”
• Considérer toutes les variations comme des extensions du cas d’utilisation donné.
Figure 2.6: Exemple de cas d’utilisation avec la relation <<extends>>
La relation « include »
Une relation « include » peut être utilisée pour faire un cas d’utilisation complexe à partir de
cas plus simples.
43
Figure 2.7: Autres exemple de cas d’utilisation avec la relation <<include>>
Les Diagrammes de cas d’utilisation sont utilisés à plusieurs fins. Ils fournissent:
• Une vue d’ensemble graphique des fonctionnalités du système.

• Un pont entre les développeurs et les clients / utilisateurs. La notation est
suffisamment simple pour permettre à un non-utilisateur de comprendre et de
commenter.
• Un point de départ pour l’élaboration des exigences détaillées.
• Une base solide pour la conception.
• Une intégration des tests.
2.2.3.1 Les scénarios de cas d’utilisation
Un scénario est une description d’un cas d’utilisation. C’est le récit de l’interaction d’un
utilisateur avec le système. Il peut être décrit en termes:
• D’acteurs impliqués
• De mesures à prendre afin de parvenir à la fonctionnalité décrite dans le titre du
cas d’utilisation. (Les cas d’utilisation portent sur les fonctionnalités, alors assurez-
vous que le titre reflète certaines fonctionnalités.)
• Les étapes prennent généralement la forme de l’écoulement normal des
événements, suivi par les flux alternatifs et / ou des flux d’exception.
Exemple:
Dans un système bancaire ATM, un cas d’utilisation serait “Valider l’utilisateur”. Les étapes
impliquées dans l’authentification d’un utilisateur sont décrits dans les scénarios. Il y aura un
certain nombre de scénarios pour “Valider l’utilisateur”, décrivant différentes situations qui
peuvent survenir.
44
Le flux principal d’événements pour le cas d’utilisation “valider l’utilisateur” pourrait être:
Scénario principal
• Système demande à l’utilisateur le numéro de code PIN

• L’utilisateur entre le code PIN via le clavier.
• L’utilisateur valide le code PIN en appuyant sur la touche Entrée.
• Système vérifie ensuite le code PIN pour voir si il est valide.
• Si le code PIN est valide, le système valide la connexion.
• Fin du cas d’utilisation
Scénario alternatif
• Système demande à l’utilisateur le numéro de code

• L’utilisateur entre le code PIN via le clavier.
• l’utilisateur appuie le bouton ANNULER pour annuler la transaction
• Fin de cas d’utilisation. Aucun changement sur le compte de l’utilisateur.
• En utilisant des scénarios, vous êtes en mesure de découvrir les objets qui
doivent collaborer pour produire les résultats escomptés.
2.2.4 Diagrammes de séquence et de collaboration
Lors du développement de logiciel en utilisant l’approche orienté objet, toute fonctionnalité

du logiciel devra être réalisé par des objets qui collaborent. Nous pouvons élaborer un
diagramme de collaboration pour décrire la façon dont nous voulons que les objets que nous
avons construit collaborent. Les diagrammes de séquence et les diagrammes de collaboration
sont des diagrammes d’interaction.
• Ils décrivent tous les deux le flux de messages entre des objets.
• Ils sont très utiles pour décrire le flux de procédure à travers les objets.
• Ils décrivent les interactions entre les objets et leurs relations, y compris les
messages qui peuvent être envoyés entre eux
• Les Diagrammes d’interaction abordent l’aspect dynamique d’un système
• Ce sont des modèles qui décrivent comment un groupe d’objets collaborent
2.2.4.1 Diagrammes de séquence
Un diagramme de séquence est un diagramme d’interaction qui met l’accent sur la
chronologie des messages. Les Diagrammes de Séquence se concentrent sur l’ordre dans
lequel les messages sont envoyés. Ils fournissent un plan séquentiel de passage de messages
entre les objets au fil du temps. Les diagrammes de séquence sont induits par les cas
45
d’utilisation qui sont les exigences du système. Ici, les objets sont représentés par des lignes
verticales et les messages comme des lignes horizontales entre eux. La séquence de messages
se lit de gauche à droite et du haut vers le bas. Les diagrammes de séquence décrivent
«comment» le système accomplira “ce que” nous avons décrit dans les cas d’utilisation.
Pour construire les diagrammes de séquence, on peut suivre l’approche suivante:
• Transformer la description de cas d’utilisation et de le transformer en algorithme

simples s’exécutant à côté du diagramme d’Etat.
• Devinez quelles classes seraient impliquées en vous basant sur la description de
cas d’utilisation.
• Pour chacune des étapes de votre algorithme décidez de quelle classe aura la
responsabilité de faire telle tâche.
• Pour chacune de ces tâches vous pouvez revenir en arrière et décider de les
décomposer en un certain nombre de tâches plus simples.
• Ajouter des informations supplémentaires qui correspondent aux relations “uses
(includes)” et “extends” dans le diagramme de cas d’utilisation.
• Envisager des erreurs importantes que vous pourriez avoir à manipuler que peut-
être ne sont pas couverts dans le modèle de cas d’utilisation.
• Demandez-vous si le diagramme cas d’utilisation a besoin d’être modifié compte
tenu des écarts relevés au point précédent.
Une analyse des diagrammes de séquence montre ce qui suit:
Une classe
• Participe à une séquence en émettant et/ou en recevant des messages

• Est placé dans la partie supérieure du diagramme et est représentée au moyen
d’un rectangle portant un nom descriptif.
Une ligne de vie
• Indique la durée de vie d’un objet au cours d’une séquence

• Est une ligne verticale en pointillés en dessous de chaque classe.
Un centre de contrôle
• C’est un long rectangle étroit placé au sommet d’une ligne de vie

• Indique quand un objet envoie ou reçoit des messages.
Un message
• Transmet des informations d’un objet à un autre objet

• Est représenté en utilisant une flèche horizontale avec en étiquette la description
du message et les paramètres applicables.
Exemple d’un diagramme de séquence “Faites une tasse de thé” générée à partir de son cas
d’utilisation, comme le montre la figure 2.8.
46
Figure 2.8: Un diagramme de séquence pour le Cas d’utilisation “faire une tasse de thé”
2.2.4.2 Diagramme de collaboration
Un diagramme de collaboration est un diagramme d’interaction qui met l’accent sur

l’organisation structurelle des objets qui envoient et reçoivent des messages. Les diagrammes
de collaboration expriment à la fois le contexte d’un groupe d’objets et l’interaction entre ces
objets. Il met l’accent sur les relations entre les objets. Ils sont très utiles pour visualiser la façon
dont plusieurs objets collaborent pour faire un travail et pour comparer un modèle dynamique
avec un modèle statique
Lors de la création des diagrammes de collaboration, des motifs sont utilisés pour justifier les
relations. La figure 2.9 montre un exemple d’un diagramme de collaboration.
Figure 2.9: Exemple d’un diagramme de collaboration
47
Remarque pour les diagrammes de séquence et de collaboration
• Les diagrammes de séquence et les diagrammes de collaboration sont

isomorphes, ce qui signifie que vous pouvez prendre l’un et le transformer
en l’autre.Les diagrammes de séquence et les diagrammes de collaboration
décrivent la même information, et l’un peut être transformé en l’autre sans
difficulté.
• Le choix entre les deux dépend de ce que le concepteur veut faire apparaître.
2.2.5 Les diagrammes d’état-transition
Le diagramme d’état-transition est un diagramme qui montre tous les états possibles qu’un
objet peut occuper. Certains objets peuvent à un moment donné être dans un certain état. Un
diagramme d’état-transition ou simplement un diagramme d’état comprend des Etats, des
transitions, des événements et des activités. Les diagrammes états-transitions traitent de la
vision dynamique d’un système. Les diagrammes états-transitions en UML ne sont nécessaires
que si un objet a une réaction différente suivant son état. Figure 2.10 montre un exemple d’un
diagramme d’états.
Figure 2.10: diagrammes d’états
2.2.6 Diagrammes d’activités
Un diagramme d’activités est un diagramme d’états spécial qui montre le déroulement des
activités à l’intérieur d’un système. Ils sont utilisés pour montrer comment les différents flux ou
processus dans un système sont construits, par quoi ils commencent, les nombreux sentiers de
décision qui peuvent être empruntés du début à la fin et les niveaux où il pourrait y avoir de
traitement parallèle lors de l’exécution.
Les diagrammes d’activités abordent la vision dynamique d’un système. Ils sont

particulièrement importants dans la modélisation de la fonction d’un système et mettent
l’accent sur le flux de contrôle entre les objets. Un diagramme d’activité comme le montre la
figure 2.11 en général ne modélise pas le comportement interne exact d’un système logiciel
(comme un diagramme de séquence le fait) mais il montre les processus de manière générale à
un haut niveau.
48
Figure 2.11: Exemple d’un diagramme d’activité
2.2.7 Un diagramme de composants
Un diagramme de composants est semblable au diagramme de paquet. Il fonctionne de la

même manière que le diagramme de paquage, montrant les organisations et les dépendances
entre un ensemble de composants. Les diagrammes de composants traitent de la vision
statique d’un système. Les diagrammes de composants mettent l’accent sur les entités
physiques du logiciel par exemple, les fichiers en-têtes, les exécutables, les librairies etc.,
plutôt que sur le partitionnement logique du diagramme de paquage. Il est basé en grande
partie sur le diagramme de paquet, mais comporte des “.dll” pour gérer les E / S.
Figure 2.12: Exemple d’un diagramme de composants
2.2.8 Diagrammes de déploiement
Le diagramme de déploiement montre la configuration des nœuds de traitement en cours

d’exécution et les composants qui en dépendent. Les diagrammes de déploiement abordent
49
la vue statique d’une architecture. Ils sont liés aux diagrammes de composants dans le sens où
un nœud renferme généralement un ou plusieurs composants.
Figure 2.13: Exemple d’un diagramme de déploiement
Conclusion
Dans cette activité nous avons vu comment donner l’aperçu d’un système informatique à
travers différents diagrammes UML. Les principaux diagrammes UML permettent de répondre
certaines questions importantes à savoir :
• Cas d’utilisation - Comment notre système va-t-il interagir avec le monde

extérieur?
• Diagramme de classes – De quels objets avons-nous besoin? Comment seront-ils
liés?
• Diagramme de collaboration - Comment les objets interagissent-t-ils?
• Diagramme de séquence - Comment les objets interagissent-t-ils?
• Diagramme d’état transition – Dans quels états nos objets seront-ils?
• Diagramme de composants - Comment nos composants logiciels seront-ils liés?
• Diagramme de déploiement - Comment le logiciel sera-t-il déployé ?
Evaluation
1. Considérons un processus logiciel comprenant les activités suivantes: collecte

des besoins, analyse orientée objet, conception des objets, implémentation et le
déploiement.
i. Dressez la liste des diagrammes qui sont essentiels pour chacune de ces
activités.
ii. Fournir des justifications pour votre choix de diagrammes.
50
2. Choisissez la meilleure réponse:
a. Le diagramme de classes:
i. est le premier modèle créé dans le projet
ii. est créé après les autres modèles
iii. est utilisé pour spécifier les objets et générer du code
iv. est utilisé pour créer les diagrammes de séquence et de collaboration.
b. Le diagramme de séquence modélise:
i. la séquence des activités à mettre en œuvre
ii. la manière dont les objets communiquent
iii. les relations entre les objets
iv. l’ordre dans lequel le diagramme de classes est construit
c. Le diagramme de collaboration:
i. est une vue unique sur le comportement de l’objet
ii. modélise les connexions entre les différents points de vue
iii. modélise les relations entre les composants logiciels et matériels
iv. modèles de la façon dont les objets communiquent
3. Quel est le rôle des diagrammes suivants dans la conception orientée objet?
i. Diagramme de classe
ii. Diagramme d’objets
iii. Diagramme de cas d’utilisation
iv. Diagramme de collaboration
4. Quel est le rôle du diagramme d’Etat transition et du diagramme d’interaction

dans le développement du système?
51
Activité 2.3- Modèle UML
Présentation
UML est un langage et possède les attributs d’un langage. Ainsi, étant graphique, UML permet
de visualiser le système réalisé ; le modèle est divisé en vues sélectionnant les éléments
pertinents puis en diagrammes de différents types. L’aspect graphique de UML retient
l’attention de ses utilisateurs. Comme pour tout langage, les éléments du langage sont définis
de manière précise, complète et sans ambiguïté.
Le modèle « 4+1 » vues, dit de Kruchten, d’un système informatique permet d’organiser la
description du système en plusieurs vues complémentaires, chacune présentant le système
selon un point de vue différent. L’utilisation de vues permet de traiter séparément les intérêts
des divers groupes d’intervenants (architectes, utilisateurs, développeurs, chefs de projets,
etc.) et ainsi de mieux séparer les préoccupations fonctionnelles (le domaine d’application ou
métier ciblé par le système, par exemple la banque ou le contrôle aérien) et les préoccupations
extrafonctionnelles (les propriétés techniques telles que la sûreté de fonctionnement).
2.3.1 La Modélisation
La figure 2.14 schématise le modèle « 4+1 » vues. Ce modèle est composé de

cinq vues.
1. La vue « logique » décrit les aspects statiques et dynamiques d’un système en

termes de classes, d’objets, de connexions et de communications. Elle se concentre
sur l’abstraction et l’encapsulation.
2. La vue « processus » capte les aspects de concurrence et de synchronisation, et les

décompose en flux d’exécution (processus, fil d’exécution, etc.). Elle se rapporte
aux objets actifs et aux interactions.
3. La vue « développement » représente l’organisation statique des modules

(exécutable, codes source, paquetages, etc.) dans l’environnement de
développement.
4. La vue « physique » décrit les différentes ressources matérielles et l’implantation

logicielle tenant compte de ces ressources. Donc, elle se rapporte aux nœuds
physiques d’exécution et au placement des objets sur les nœuds.
5. La dernière vue, appelée « cas d’utilisation », se concentre sur la cohérence en

présentant des scénarios d’utilisation qui mettent en œuvre les éléments des quatre
premières vues. Les scénarios sont une abstraction des exigences fonctionnelles
de l’application. Cette dernière vue valide en quelque sorte les autres vues et
assure la cohérence globale. C’est aussi cette dernière vue qui est construite en
premier, juste après l’établissement du cahier des charges, pour fixer les contours
du système à réaliser avec ses fonctionnalités appelées, dans la terminologie UML,
des cas d’utilisation.
52
Figure 2.14: Modèle sous forme de vue
2.3.2 Vue d’ensemble
Les diagrammes de cas d’utilisation montrent les fonctionnalités d’un système.
1. La description d’un cas d’utilisation (scénario) permet de découvrir les objets qui
doivent interagir (par l’envoi de messages et les fonctions effectuées) pour produire
la fonctionnalité requise
2. En modélisant les classes et leurs relations nous établissons un modèle structurel

du système (diagramme de classes)
3. Enfin, nous examinons chaque classe à tour de rôle afin d’identifier les aspects
comportementaux du système en utilisant les diagrammes d’états ou les
diagrammes de séquence / de collaboration
4. Les informations issues de ces modèles sont incorporées de nouveau dans le

diagramme de classes qui est la base de la conception du système
5. Pendant une bonne partie de réévaluation et de réglage fin, ces modèles nous
permettent de créer un modèle de conception du système
2.3.3 Le processus de conception
Le processus de conception UML implique la création de divers documents graphiques ou

textuels. En UML, ces documents sont appelés artifacts et ils décrivent le résultat issu d’une
étape dans le processus.
Le processus de conception en UML comporte deux parties principales qui sont:
• L’Analyse - Quel est le problème?

• La Conception - Comment le problème sera-t-il résolu?
53
Les phases d’analyse et de conception servent à décomposer le projet en plus petits

composants ayant les caractéristiques suivantes:
• Les détails d’implémentation du système sont masqués.

• Le système est modulaire
• Les composants sont reliés et interagissent
• La complexité de la couche
• Les composants peuvent être réutilisés dans d’autres programmes.
• Variations sur un thème.
La classification des documents UML en se basant sur le SDLC est indiquée dans le tableau 2.1
Tableau 2.1: Catégories de documents UML
Phase de
Statique Comportementale
développement
Cas d’utilisation
Besoins
Cas d’utilisation de haut niveau
Diagramme de classes
conceptuel ou de domaine
Analyse Diagrammes de séquence
Contrats d’exploitation
Les diagrammes de collabora-

tions
Conception
Conception des diagram-
mes de classe
Conclusion
Cette activité expose les différentes vues distingués lors de la modélisation. Une classification
des différents diagrammes UML selon ces différentes vue a été proposée.
Evaluation
Citez les différentes vues du modèle Kruchten et expliquez brièvement ce qui s’y passe.
54
L’UML est un langage graphique pour capter les artefacts de développements logiciels. Ce
langage nous fournit un ensemble de symboles afin de produire des modèles. UML est
en train d’être adopté comme un langage de modélisation universel dans l’industrie de
développement. L’UML a été conçu à l’origine à Rational Corp. par les trois associés
précédemment cités dans l’introduction. Le langage est très riche, et comporte de nombreux
aspects des bonnes pratiques du génie logiciel.
1. Expliquer pourquoi le langage UML (Unified Modeling Language) est

utilisé pour l’analyse et la conception des systèmes orienté objet.
2. Citer les objets et / ou diagrammes UML dans l’ordre de leur apparition

dans les processus de recueillement des besoins, d’analyse des besoins et
de conception du système.
3. Expliquer clairement pourquoi il est nécessaire d’avoir une variété de

diagrammes pour modéliser un système?
• Ariadne Training (2001), “UML Applied Object Oriented Analysis and Design
Using the UML”, Ariadne Training Limited
• Larman C. (2004), “Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design and Iterative Development”, (3rd Edition) 3rd
Edition, Prentice Hall; 3 edition (October 30, 2004), ISBN-13: 978-0131489066
• Liu Z., (2001), “Object-Oriented Software Development Using UML”, The United
Nations University, UNU-IIST International Institute for Software Technology, Tech
Report 229.
• Ojo A. and Estevez E., (2005), “Object-Oriented Analysis and Design with UML”,
Training Course, The United Nations University, UNU-IIST International Institute for
Software Technology, e-Macao Report 19, Version 1.0, October.
• Michael B., Rumbaugh J., “Modélisation et conception orientées objet avec UML
2 “, 2ème édition, Pearson Education France, 2005.
• Pascal Roques, UML 2 par la pratique: Etudes de cas et exercices corrigés, 5ème
édition, Eyrolles
• Fien Van der Heyde, Laurent Debrauwer, UML 2 : Initiation, exemples et exercices
corrigés, Eni.
• Benoît Charroux, Aomar Osmani, Yann Thierry-Mieg, “UML 2”, collection Synthex
, Pearson Education , 3ème édition, 2010
55
Unité 3: Analyse Orientée-Objet

Cette unité explique comment obtenir un cahier des charges en associant les cas d’utilisation,
les classes identifiées et en tenant compte du fonctionnement du système et des contrats
d’exploitation qui sont obtenus à partir du modèle de séquence du système.
À la fin de cette unité, vous devriez être capable de:
• Produire un cahier de charge, les spécifications fonctionnelles et non

fonctionnelles du système.
• Modéliser les Cas d’utilisation du modèle et les diagrammes de cas d’utilisation
pour décrire les besoins fonctionnels
• Expliquer les diagrammes de cas d’utilisation et leur utilité pour décrire un
modèle de cas d’utilisation.
Termes clés
L’analyse Plutôt que d’apporter une solution, l’analyse met
l’accent sur une enquête par rapport à un problème et sur
des besoins. Par exemple, si l’on souhaite informatiser le
système d’information d’une bibliothèque, comment s’y
prendrait-on ?
Le mot «Analyse» est un terme général, de manière plus

précise on pourrait parler, d’analyse des besoins (une
enquête sur les besoins) ou de l’analyse des objets (une
enquête sur les objets du domaine).
Conception La conception apporte une solution théorique

aux exigences, mais n’engage pas la mise en œuvre. Par
exemple, la conception peut produire une description d’un
schéma de base de données et des objets logiciels. Au
bout du compte, c’est probable que les résultats de la
conception soient mises en œuvre.
Cas d’utilisation Un cas d’utilisation spécifie une séquence

d’actions que le système peut effectuer et qui donnent un
résultat ayant de la valeur pour un acteur particulier.
56
Activité 3.1 - Comprendre les exigences
Présentation
Les besoins/exigences sont une description d’une fonctionnalité, d’un besoin ou d’une
condition qu’un utilisateur souhaite voir implémenter dans un système. Un besoin est:
Une fonction que le système doit effectuer
Une caractéristique du système ou une description de quelque chose que le système est
capable de faire pour atteindre le but pour lequel il a été conçu.
Une affirmation sur laquelle toutes les parties prenantes s’accordent à dire qu’elle doit être
vérifiée pour que le problème du client soit résolu de façon adéquate.
La spécification des exigences doit être correcte et approfondie pour qu’un projet soit mené à
bien.
Nous prendrons le cas d’un point de vente pour illustrer les questions ci-après :
Quel devrait être le résultat issu d’une bonne collecte et d’une
bonne analyse des besoins/exigences?
Comment identifier les éléments constitutifs de ce résultat ?
Comment ces résultats sont-ils exprimés?
3.1.1 Spécification des exigences
La documentation des exigences est une activité très importante, qui se fait après que les
besoins soient collectés et analysés. Il s’agit de présenter les exigences dans un format
cohérent. C’est le cahier des charges. Ce document est une spécification pour un produit
logiciel particulier, un programme ou un ensemble de programmes qui remplissent certaines
fonctions dans un environnement spécifique.
Le cahier des charges est une description des besoins ou un désir exprimé pour un produit. Il
est la déclaration officielle de ce qui est requis du développeur du système. Les exigences
doivent être sans ambigüité et exprimées d’une manière que le client et les membres de
l’équipe de développement comprennent clairement.
Ce n’est pas un document de conception et il doit indiquer ce qui doit être fait plutôt

que comment il est fait. Il doit être sous une forme qui peut être considéré comme le point
de départ pour le développement de logiciels. Un langage de spécification est souvent
utilisé. Des notations graphiques sont souvent également utilisées pour décrire la spécification
des besoins.
57
Il est recommandé que le cahier des charges incluse au minimum les éléments suivants:
Une vue d’ensemble du projet
Les objectifs / buts
Le glossaire - définition de tous les termes pertinents
Les fonctions du système
Exigences fonctionnelles du système
Attributs du système (exigences non fonctionnelles)
Les cas d’utilisation - descriptions narratives des processus de domaine
Le modèle conceptuel - un modèle de concepts importants et leurs relations dans

le domaine de l’application
Les documents suivants sont généralement produits par la collecte des informations :
documents variés tels que les déclarations du client au sujet de ses besoins ;

rapport d’enquête préliminaire et documents électroniques,
résultats des entrevues,
réunions de définition des exigences etc.
3.1.2 Vue d’ensemble du projet
Cette rubrique doit donner le but du projet. Cela devrait décrire la nécessité de construire le
système. Par exemple, le but de ce projet est de créer un système autonome pour la vente des
objets d’art de la boutique.
3.1.3 Objectifs
Le but de ce projet est de créer un terminal de point de vente pour gérer les ventes au
détail. Les objectifs décrivent comment le système s’inscrit dans la gestion ou dans les objectifs
stratégiques globaux de l’organisation qui acquiert le logiciel.
Les objectifs du terminal de point de vente peuvent être énoncés comme suit:
En général, le but est d’automatiser la gestion des commandes, de garantir, des

services et des flux de meilleure qualité et à moindre coût. Plus précisément,
ceux-ci comprennent:
Paiement rapide pour le client,
Analyse des ventes rapides et précises,
Contrôle automatique des stocks.
Note: La vue d’ensemble et les objectifs peuvent être combinées en une section
d’introduction dans le document.
58
3.1.4 Glossaire
Le glossaire est la définition de tous les termes pertinents. Il est la clarification des termes
ambigus et des concepts, des explications de jargons, la description des événements métiers
ou la description des actions logicielles.
Remarque:
Il n’y a pas de format spécifique pour le glossaire.
3.1.5 Fonctions système
Les fonctions du système regroupent les choses qu’un système est censé faire. Il y a 2 grandes
catégories de besoins:
Besoins fonctionnels
Ce sont ceux qui se rapportent directement au fonctionnement du système.
Ce sont les aspects du système que le client est le plus susceptible de reconnaître.
Besoins non fonctionnels:
Ce sont les contraintes / restrictions imposées sur le système.
Besoins fonctionnels
Les exigences fonctionnelles décrivent l’interaction entre un système et son environnement. Ils
décrivent comment un système doit réagir dans certaines conditions. Pour vérifier que X est en
effet une fonction du système, il faut donner un sens à la phrase suivante:
«Le système devrait faire <X> »
Par exemple, “facilité d’utilisation” ne figure pas parmi les phrases de vérification. Ainsi, les
besoins de ce type ne devraient pas faire partie du cahier des charges fonctionnel.
Les fonctions du système doivent être classées dans l’ordre des priorités pour éviter de les
manquer. Les catégories comprennent:
Fonctions évidentes doivent être remplies, et l’utilisateur doit être conscient que

c’est fait.
fonctions cachées doivent être remplies, mais peuvent ne pas être visibles

pour les utilisateurs. Cela est vrai pour de nombreux services techniques sous-
jacentes, comme enregistrer des informations dans un mécanisme de stockage
persistant. Les fonctions cachées sont souvent omises par erreur pendant les
processus de collecte des exigences.
Dans la présentation des fonctions, comme le montre le modèle donné dans le

tableau 3.1 :
Elles devraient être divisées en groupes organisés de façons interdépendantes,
59
Chaque fonction doit avoir un numéro de référence qui peut être utilisé dans
d’autres documents au cours du développement,
La catégorie à laquelle une fonction appartient doit être indiquée.
Tableau 3.1: Modèle pour la présentation des exigences fonctionnelles
Ref # Fonction Catégorie
Les tableaux 3.2 et 3.3 montrent les exigences fonctionnelles pour le système Terminal de
point de vente
Tableau 3.2: Les fonctions de base du système Terminal de point de

vente
R1.1 Enregistrer la vente (en cours) - évident
les articles achetés
R1.2 Calculer le montant total de la évident
vente en cours
R1.3 Récupérer des informations évident
d’achat de l’article à partir d’un
code à barres à l’aide d’un lecteur
de code-barres ou à partir de la
saisie manuelle d’un code de pro-
duit, tel qu’un code universel des
produits (CUP)
R1.4 Réduire les quantités en stock caché
quand une vente est validée
R1.5 Archiver les ventes terminées caché
R1.6 La caissière doit se connecter évident
avec un identifiant et un mot de
passe pour utiliser le système
R1.7 Fournir un mécanisme de stock- caché
age persistant
R1.8 Fournir des mécanismes de caché
communication inter-système et
interprocessus
R1.9 Afficher la description et le prix évident
de l’élément enregistré
60
Tableau 3.3: fonctions de paiement du système Terminal de point de vente

R2.1 Gérer les paiements en espèces, enregistrer évident
le montant payé et calculer le solde dû.
R2.2 Gérer les paiements par carte de crédit, la évident
capture des informations de crédit à partir
d’un lecteur de carte ou par saisie manuelle,
et autoriser le paiement avec le service d’au-
torisation des cartes de crédit du magasin
(externe) via une connexion par modem.
R2.3 Gérer les paiements par chèque, l’enregis- évident
trement du permis de conduire par saisie
manuelle, et autoriser le paiement par le ser-
vice d’autorisation des chèques du magasin
(externe) via une connexion par modem.
R2.4 Enregistrer les paiements à créditer sur les caché
comptes clients.
Exigences non fonctionnels
Les exigences non fonctionnelles du système, également connus sous le nom d’attributs du
système. Ce sont les contraintes imposées sur le système et les restrictions qui pèsent sur le
concepteur.
Les attributs du système doivent :
définir la façon dont un système est censé se comporter et sont souvent appelées
caractéristiques du système,
être par exemple les temps de réponse, les besoins en mémoire, la performance,

la facilité d’utilisation, la sécurité, la facilité d’utilisation, les plates-formes de
système d’exploitation, la compatibilité, coût de la vente au détail, la tolérance
aux pannes, etc.
Le programmeur ne peut pas écrire une ligne de code spécifique, à mettre en

œuvre pour les exigences non fonctionnelles. Elles sont plutôt des propriétés
«émergentes» qui découlent de l’ensemble de la solution.
Les besoins non fonctionnel peuvent être classés en:
Exigences par rapport au produit
Ce sont les exigences qui précisent que le produit livré doit se comporter d’une
manière particulière, par exemple la vitesse d’exécution, la fiabilité, etc.
61
Le tableau 3.4 présente des exemples d’exigences non-fonctionnelles.
Tableau 3.4: Attributs pour le système Terminal de point de vente
Attribut Contraintes
Temps de Lors de l’enregistrement d’un article vendu, la
réponse description et le prix apparaissent dans les 5
secondes
métaphore d’in- Formulaires-métaphore windows et boîtes de
terface dialogue
Tolérance à la Enregistrer les paiements à crédit sur les
panne comptes des clients débiteurs dans les 24 heu-
res, même si l’alimentation en énergie ou un
dispositif tombe en panne
plate-forme de Microsoft Windows 2007 et 2008
système d’ex-
ploitation
Exigences Organisationnels
Ce sont les exigences qui sont une conséquence des politiques et procédures

organisationnelles par exemple les normes du procédé utilisé, les exigences de mise en
œuvre, etc.
Exigences Externes
Exigences qui découlent de facteurs qui sont externes au système et à ses processus de
développement par exemple, les exigences d’interopérabilité, les exigences législatives, etc.
Caractéristiques des exigences

Les exigences sont censées avoir les caractéristiques suivantes:
Vérifiable:
Un cahier des charges devient souvent partie du contrat entre un client et un

développeur système. Il décrit ce que le développeur va livrer et ce pour quoi il
va être payé. Il est important qu’on puisse vérifier si le produit final répond aux
exigences. Les exigences devraient donc être vérifiables; il devrait être possible
de décider si le logiciel est conforme aux exigences.
Complète :
Les exigences doivent être complètes, et ne rien omettre. Cela peut être très difficile
à réaliser, surtout dans les grands systèmes. Les tendances actuelles veulent que l’on
divise le développement en modules plus petits et implémenter chacun d’eux.
62
Non ambigüe
Une exigence est ambiguë si elle a plus d’un sens. L’ambiguïté peut résulter d’un mauvais
choix de mots et / ou des définitions différentes pour un mot ou une phrase.
Cohérente
Toutes les parties du cahier de charges doivent être cohérentes. Elles ne doivent pas se
contredire les unes les autres.
Exemple de contradiction :
“Si vous supprimez une tâche toutes ses sous-tâches devrait être
supprimé automatiquement” ;
“Vous devez toujours confirmer la suppression d’une tâche et de chacune de

ses sous-tâches.
Modifiable
Les exigences devraient être structurées de telle sorte qu’il soit possible de les modifier à
moindre coût. Ceci nécessite qu’elles soient structurées avec soin, par exemple, en séparant
les exigences fonctionnelles des exigences non fonctionnelles, en fournissant un glossaire (une
table de définitions),….
Traçable
Les exigences doivent être structurées de sorte qu’il soit possible de les identifier de manière unique.
Chacune doit avoir un numéro unique.
Cela permet d’y faire référence dans les tests finaux du logiciel fourni, et dans les discussions
avec le client.
Evaluation
1. En considérant le cas des projets étudiants, proposés dans l’unité 0, effectuer les
tâches suivantes:
2. Donner un aperçu et les objectifs du système que vous souhaitez développer
3. Énumérer les principaux besoins fonctionnels du système que vous souhaitez

développer.
4. Pour chaque exigence, fournir l’identificateur de l’exigence, la description et les

références croisées.
Lister cinq exigences non fonctionnelles du système en utilisant le format spécifié.
63
Activité 3.2 - Cas d’utilisation
Présentation
L’un des principaux objectifs de l’OO est de décomposer les exigences en concepts et en objets
dans le domaine d’application et de produire un modèle conceptuel. Une technique importante
pour aider à cette décomposition est de considérer les cas d’utilisation (description narrative des
processus de domaine en termes d›interactions entre le système et ses utilisateurs).
3.2.1 Concepts de cas d’utilisation
Un cas d’utilisation décrit la séquence des événements de certains types d›utilisateurs,

appelés acteurs, en utilisant une partie de la fonctionnalité du système pour terminer un
processus. Il est tout simplement une description d’un ensemble d’interactions entre un
utilisateur et le système. En mettant en place un ensemble de cas d’utilisation, on peut décrire
l’ensemble du système que nous prévoyons créer, d’une manière très claire et concise.
Par exemple, pour mener à bien le processus d’achat dans un magasin quand un Terminal de
point de vente est utilisé :
• deux acteurs doivent être impliqués: le client et le caissier,

• la séquence d’événements suivante peut être réalisée:
• Le client arrive à une caisse avec les produits achetés,
• Le caissier enregistre la commande et le paiement,
• Enfin, le client quitte le magasin avec ses produits.
Par conséquent, pour un utilisateur, un cas d’utilisation est une façon d’utiliser le système. Un
cas d’utilisation est décrit comme une séquence d’interactions entre des acteurs et le système
par lequel le système fournit un service aux acteurs. Chaque cas d’utilisation décrit une
partie des exigences fonctionnelles de certains utilisateurs. Tous les cas d’utilisation décrivent
ensemble les exigences fonctionnelles globales du système.
La première étape du recueillement des besoins est d’assimiler les besoins aux cas
d’utilisation. Tous les cas d’utilisation permettent aux développeurs de logiciels et au client de
se mettre d’accord sur les besoins, c’est-à-dire sur les conditions auxquelles le système doit se
conformer. UML fournit une notation simple pour représenter un cas d’utilisation.
Acteurs
Un cas d’utilisation ne peut pas initier des actions de lui-même. Un acteur est une entité
qui peut initier un cas d’utilisation. Un acteur représente un ensemble cohérent de rôles qui
sont des entités externes au système pouvant utiliser le système, plutôt qu’une personne en
particulier. Un acteur représente un type d’utilisateurs du système ou un système externe avec
lequel le système interagit.
64
Il est important de noter que :
• Un acteur stimule généralement le système avec des événements en entrée, et

reçoit quelque chose en retour du système.
• Les acteurs communiquent avec le système en envoyant des messages
et reçoivent des messages à partir du système tel que décrit dans les cas
d›utilisation.
• Les acteurs représentent tout ce qui a besoin d’interagir avec le système pour un
échange d’information: utilisateurs humains, systèmes informatiques, électriques
ou dispositifs mécaniques tels que des minuteries.
• Un utilisateur physique peut représenter un ou plusieurs acteurs dans leur
interaction avec le système et plusieurs utilisateurs individuels peuvent agir en
tant que différentes occurrences d’un même acteur.
• S’il y a plus d’un acteur dans un cas d’utilisation, celui qui génère l’action de
départ est appelé l’acteur initiateur et les autres sont des acteurs participants.
• Les acteurs qui interagissent directement avec le système sont des
acteurs primaires / directs, les autres sont appelés acteurs secondaires.
Exemple:
Un système ATM (un système de guichet bancaire automatique) interagit avec des utilisateurs
qui utiliseront le système pour retirer de l›argent à partir des comptes, déposer de l›argent
sur des comptes, et de transférer de l›argent entre les comptes. Ce type d’utilisateurs
est alors représenté par l’acteur Client de la Banque. Par conséquent, un modèle de
cas d’utilisation peut être utilisé pour représenter les trois cas d›utilisation retirer de
l’argent, déposer de l’argent, et transférer de l’argent qui sont associés à l›acteur Client de la
Banque comme le montre la figure 3.1.
Figure 3.1: Diagramme de cas d’utilisation d’un système ATM
Ainsi, les acteurs représentent des entités en dehors du système qui collaborent avec le
système. Une fois que nous avons énuméré tous les acteurs d’un système, nous avons ainsi
identifié l’environnement externe du système.
Pour la plupart des systèmes, un seul acteur peut interagir avec de nombreux cas d’utilisation,
et un seul cas d’utilisation peut être initié par de nombreux acteurs différents. Prenant
l’exemple du cas Terminal de point de vente, la figure 3.2 montre un système complet décrit à
l’aide des acteurs et des cas d’utilisation.
65
Figure 3.2: Cas d’utilisation système Terminal de point de vente
Granularité des Cas d’utilisation
Ariane (2001) indique clairement qu’il peut être difficile de se prononcer sur la granularité
des cas d’utilisation dans un scénario particulier. Est-ce que chaque interaction utilisateur-
système est un cas d’utilisation ? ou est-ce qu’un cas d’utilisation englobe toutes les
interactions? Prenons l’exemple du système ATM dans la figure 3.3 qui permet à un utilisateur
de retirer de l’argent, nous pouvons avoir les interactions suivantes:
• Entrez carte
• Entrez le Code PIN
• Sélectionnez un montant
• Confirmer montant
• Retirer carte
• Prendre le reçu
…
66
Est-ce que chacune de ces étapes, par exemple “entrer le numéro PIN” est un cas d’utilisation?
Ceci est une erreur classique dans la construction de cas d’utilisation. Ici, nous avons généré
un grand nombre de petits cas d’utilisation presque sans importance. Dans tout système non
trivial, nous nous retrouverions avec un grand nombre de cas d’utilisation, et la complexité du
système deviendrait écrasante.
Figure 3.3: Proposition de diagramme de cas d’utilisation pour le système d’ATM
Ce diagramme (Figure 3.3) de cas d’utilisation est-il utile?
Pour gérer la complexité d’un système aussi large soit-il, nous devons garder les cas
d’utilisation à un assez “haut niveau”. La meilleure façon est de garder la règle qui suit à
l’esprit.
“Un cas d’utilisation doit satisfaire un objectif pour l’acteur”
Si nous appliquons cette règle simple à notre exemple ci-dessus, nous pouvons
poser la question suivante :
Est-ce que “prendre un reçu», par exemple, est un objectif pour notre client? Eh
bien pas vraiment. Ce ne sera pas la fin du monde si le reçu n’a pas été délivré.
Appliquez maintenant la règle aux autres cas d’utilisation, et vous verrez que
vraiment, aucun d’entre eux ne décrit l’objectif de l’utilisateur. Le but de l’utilisateur
dans ce cas est de « retirer de l’argent”, et cela devrait être le cas d’utilisation!
67
Figure 3.4: Un diagramme de cas d’utilisation plus ciblée pour le système d’ATM
3.2.2 Identification des cas d’utilisation
Il est nécessaire de mener une réflexion poussée et d’examiner le cahier des charges afin
d’identifier les cas d’utilisation :
Une méthode pour identifier les cas d’utilisation est basée sur l’acteur:
• Identifier les acteurs liés à un système ou d’une organisation, à savoir trouver

et préciser tous les acteurs en recherchant quels utilisateurs vont utiliser le
système ainsi qu’en déterminant les autres systèmes qui doivent interagir avec lui.
• Pour chaque acteur, identifier les processus qu’ils initient ou auquel ils participent
en regardant comment l’acteur communique / interagit avec le système pour faire
son travail.
• Une deuxième méthode pour identifier les cas d’utilisation est basée sur
les événements.
• Identifier les événements externes auxquels le système doit répondre.
• Faire correspondre les événements aux acteurs et aux cas d’utilisation.
Pour identifier les cas d’utilisation, il faut poser et répondre à un certain nombre de questions,
telles que :
• Quelles sont les principales tâches de l’acteur?

• Est-ce que l’acteur devra lire / écrire / modifier les informations système?
• Est-ce que l’acteur devra informer le système sur les changements externes?
• Est-ce que l’acteur souhaite être informé des modifications?
• Pour l’application Terminal de point de vente, les acteurs potentiels suivants et
les cas d’utilisation suivants peuvent être identifiés:
Acteur Processus
La Connexion, Décon-
caissière nexion
Client Acheter des arti-
cles, Retourner des
articles
68
3.2.3 Rédaction des cas d’utilisation
Cas d’utilisation de haut niveau
Lorsque nous utilisons les méthodes indiquées dans le paragraphe ci-dessus pour identifier
un cas d’utilisation, nous créons d’abord un cas d’utilisation de haut niveau pour obtenir
une certaine compréhension de l’ensemble du processus, puis nous le développons en y
ajoutant plus de détails. Un cas d’utilisation de haut niveau décrit un procédé très brièvement,
généralement en deux ou trois phrases. Ils ne sont souvent concernés que par les événements
auxquels les acteurs participent. Il est décrit sous la forme suivante dans le tableau 3 .5:
Tableau 3.5: un cas d’utilisation de haut niveau Template

Cas d’utilisation: Nom du cas d’utilisation (utiliser une phrase
commençant par un verbe).
Acteurs: Liste des acteurs (agents externes),

indiquant qui initie le cas d’utilisation.
Objectif: Intention du cas d’utilisation.
Aperçu: Une brève description du processus.
Références Cas d’utilisation liés à celui-ci et les

croisées: fonctions du système.
Par exemple, la description de haut niveau du processus achat d’articles en payant en

espèce dans le système Terminal de point de vente est donnée dans le tableau 3.6.
Tableau 3.6: Description de haut niveau pour le Cas d’utilisation “Achat d’ar-
ticles en payant en espèce “
Cas d’utilisation:
achat des articles en payant en espèce
Acteurs: Client (initiateur), caissier.
Objectif: Enregistrer une vente et le paiement en espèces.
Aperçu: Un client arrive à une caisse avec de nouveaux articles

à acheter. Le caissier enregistre l’achat et perçoit un
paiement en espèces. A la fin, le client quitte avec les
articles.
Références Fonctions: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1.

croisées:
Les références aux fonctions du système indiquent que :
le cas d’utilisation est créé par une meilleure compréhension de ces fonctions,
ces fonctions nécessaires sont allouées à ce cas d’utilisation,
69
Les points suivants sont très utiles :
il est possible de vérifier que toutes les fonctions du système ont été allouées à
des cas d’utilisation,
il offre un lien entre les résultats produits à différents stades du développement,
Toutes les fonctions du système et les cas d’utilisation peuvent être repérées au
cours de l’implémentation et des tests.
Cas d’utilisation étendu
Un cas d’utilisation étendu montre plus de détails que celui de haut niveau, et on le

fait souvent dans un style conversationnel entre les acteurs et le système. Typiquement,
un cas d›utilisation étendu élargit un cas d’utilisation de haut niveau en ajoutant
deux sections : parcours typique d’événements et scénario alternatif (ou exceptions), comme
indiqué dans le tableau 3.7.
Tableau 3.7: Parcours typique des événements dans un cas d’utilisation

élargi
Action de l’acteur: Réponse du système:
Numéroter les actions des Numéroter les réponses du système
acteurs.
Parcours alternatifs:
● Alternatives qui peuvent survenir
au numéro ….
● Description de l’exception.
Par exemple dans le tableau 3.8, le cas d’utilisation haut niveau « Achat d’articles en payant
en espèce » dans le système Terminal de point de vente peut être développé avec les deux
sections de la manière suivante.
Tableau 3.8: parcours typique des événements du cas d’utilisation “ Achat

d’articles en payant en espèce “
Acteur Action:
Réponse du système:
Ce cas d’utilisation commence quand un

client arrive à une caisse (Terminal de point
de vente) avec des articles à acheter.
Le caissier enregistre l’identifiant de chaque Détermine le prix de l’article et ajoute les

élément. informations de l’article à la transaction de
vente en cours.
S’il y a plusieurs exemplaires d’un même
article, le caissier peut entrer la quantité La description et le prix de l’article en
aussi. cours sont affichés.
70
A l’issue de l’entrée d’un article, le Calcule et affiche le total de la vente.

caissier indique au terminal que la
saisie des articles est terminée.
Le caissier annonce le total au Client.
Le client donne le paiement en espèces,

supérieur ou égal au total de la vente.
Le caissier enregistre le montant reçu. Montre le solde dû au client et génère un

reçu.
Le caissier dépose l’argent reçu et extrait la Archive la vente terminée.

monnaie de la caisse.
L’argent dû au client est remis ainsi

que le reçu émis.
le client s’en va avec les articles

achetés.
Parcours alternatifs:
Ligne 2: un identificateur non valide est entré. Indiquer erreur.
Ligne 7:Le client n’a pas assez de liquidités. Annuler la transaction de vente.
3.2.4 Descriptions de cas d’utilisation
Chaque cas d’utilisation contient un ensemble complet de détails textuels sur les interactions
et les scénarios qu’il contient. Le tableau 3.9 montre le modèle pour une description de cas
d’utilisation:
Tableau 3.9: Un modèle pour une description de cas d’utilisation

Cas d’utilisation: Nom du Cas d’utilisation
Acteurs: Intitulés des rôles des personnes ou entités externes

initiateurs et participants du cas d’utilisation
Brève description: Une brève description du cas d’utilisation
Préconditions: Une description des conditions qui doivent être

remplies avant que le cas d’utilisation ne soit invoqué
Post-conditions: Une description de ce qui est arrivé à la fin du cas

d’utilisation
Flux principal: Une liste des interactions du système qui ont lieu dans
le cadre du scénario le plus courant. Par exemple, pour
«retirer de l’argent”, ce serait “entrer carte, entrer le
code PIN, etc.”
71
Flux alternatif (s): Une description des alternatives possibles
Flux d’exception: Une description des scénarios possibles où les

événements inattendus ou imprévus ont eu lieu
Types de relation dans un diagramme de cas d’utilisation
Tous les acteurs et les cas d’utilisation d’un système constituent un modèle de cas
d’utilisation qui décrit comment les cas d’utilisation sont liés les uns aux autres et aux acteurs,
et spécifie les exigences fonctionnelles du système. Un diagramme de cas d’utilisation décrit le
cadre du modèle de cas d’utilisation et illustre un ensemble de cas d’utilisation d’un système,
les acteurs, et la relation entre les acteurs et les cas d’utilisation.
La notation UML pour un diagramme de cas d’utilisation est composé de:
une forme ovale représente un cas d’utilisation,
un bonhomme en traits pleins représente un acteur,
une ligne entre un acteur et un cas d’utilisation signifie que l’acteur initie et / ou participe au
processus.
Les diagrammes de cas d’utilisation s’accompagnent des spécifications de comportement, qui

définissent les interactions au sein d’un cas d’utilisation particulier. En général, on utilise les
relations entre les cas d’utilisation tels que include, uses et extend pour réduire la complexité
du modèle en identifiant les points communs dans les différents cas d›utilisation dans la
description des diagrammes de cas.
Une relation include peut être utilisée pour former un grand cas d’utilisation à partir de
cas plus simples.
Une relation extend est utilisée dans des cas où un cas d’utilisation peut être élargi en option
par une fonctionnalité dans un autre cas d’utilisation.
La notation “extend” étend les fonctionnalités d’un cas d’utilisation pour prendre en compte
des erreurs ou des exceptions. La relation est dessinée comme une ligne avec une flèche
pointant vers le principal cas d’utilisation comme le montre la figure 3.5. Vous utilisez la
relation “extend” lorsque vous avez un cas d’utilisation qui est semblable à un autre, mais en
fait un peu plus.
72
Figure 3.5: Relation “extend”
Toutefois, si le point de décision présente des alternatives qui sont tous relativement
égale et normale dans leur probabilité, alors nous devons les considérer comme des cas
d’utilisation individuels et ils peuvent être utilisés par un cas d’utilisation principal, en utilisant
des relations uses comme dans la figure 3.6.
Figue. 3.6: cas d’utilisation avec une relation « uses »
Attention ! Les cas d’utilisation encouragent la réutilisation. Si un cas d’utilisation a besoin de

la fonctionnalité d’un autre cas d’utilisation dans le but d’accomplir sa tâche, il “uses” le 2ème
cas d’utilisation. La relation est dessinée comme une ligne avec une flèche pointant vers le cas
de l’utilisation qui est “utilisé”.
73
3.2.5 Les cas d’utilisation dans un processus de développement
Les activités et artéfacts de l’analyse de cas d’utilisation peuvent être résumés comme suit:
• Après que les fonctions du système aient été répertoriés, identifier les acteurs et
les cas d’utilisation.
• Ecrire tous les cas d’utilisation dans le format de haut niveau. Vous pouvez, les
classer comme primaire, secondaire ou facultatif.
• Dessiner un diagramme de cas d’utilisation pour le système.
• Etablir des relations entre les cas d’utilisation et les illustrer dans le diagramme de
cas d’utilisation.
• Ecrire les cas les plus critiques, influents et risqués dans le format élargi pour
mieux comprendre la nature et de la taille du problème. Différer la rédaction
de la forme élargie des cas d’utilisation les moins critiques jusqu’à ce que la
conception ou la mise en œuvre commence.
• Idéalement, les cas d’utilisation réels devraient être reportés jusqu›à la phase de
conception d›un cycle de développement, puisque leur création implique des
décisions de conception. Cependant, il est parfois nécessaire de créer certains
cas réels au cours de la phase d’exigence en cas où :
• Les descriptions concrètes aident considérablement la compréhension.
• Les clients demandent que l’on décrive leurs processus de cette façon.
• Vous pouvez, classer les cas d’utilisation afin de planifier quel cas devrait être
dans la phase de conception ou la phase de mise en œuvre.
3.2.6 Acteurs et cas d’utilisation du système Terminal de point de vente
En utilisant les techniques de la présente section, une liste (non exhaustive) des acteurs
concernés et des cas d’utilisation est répertoriée ans le tableau 3.10 :
Tableau 3.10: Acteurs et cas d’utilisation pour le système Terminal de point

de vente
Acteur Cas d’utilisation
La caissière S’identifier
Donner la monnaie
Client Acheter Articles
retourner Articles
Gérant Démarrer
Eteindre
Administrateur du sys- Ajouter de nouveaux utilisateurs
tème
74
3.2.7 Utilité des cas d’utilisation
Les raisons pour lesquelles les cas d’utilisation sont utiles pour une la collecte des besoins sont:
Ils ne répondent pas seulement à la question de ce que le système doit faire, mais y répondent
en termes de ce que le système doit faire pour chaque utilisateur/acteur. Ils identifient donc les
fonctions que le système fournit pour ajouter de la valeur à ses utilisateurs, et aident à éliminer
les fonctions qui n’ajoutent pas de la valeur aux utilisateurs.
Un cas d’utilisation définit la portée du système. Ils permettent de visualiser la taille et l’étendu

du développement à faire.
Ils permettent la communication entre le client et les développeurs (puisque le schéma est très
simple, tout le monde peut le comprendre)
Ils identifient les fonctions du système et la relation entre les fonctions du système.
Ils identifient également les concepts et les objets impliqués dans le domaine
d’application. Ces concepts et objets sont très importants dans la modélisation de
l’architecture du système, et sont par la suite réalisés dans la conception sous la forme de
classes et d’objets logiciels.
Les cas d’utilisation sont très semblables aux exigences/besoins, mais les exigences/besoins
ont tendance à être vagues, confus, ambigus et mal écrits, alors que les cas d’utilisation sont
beaucoup plus ciblés.
La «somme» des cas d’utilisation est l’ensemble du système. Tout ce qui n’est pas couverts par
un cas d’utilisation est en dehors de la limite du système à développer. Donc le diagramme de
cas d›utilisation ne comporte pas d’omission.
Les cas d’utilisation guident les équipes de développement à travers le processus de

développement. Ils sont une épine dorsale du développement et nous nous référons à eux
dans tout ce que nous faisons.
Les cas d’utilisation fournissent une méthode pour planifier le travail de développement, et

permettent d’estimer combien de temps le développement prendra.
Les cas d’utilisation constituent la base de la création des systèmes de test.
Les cas d’utilisation aident à la création de guides d’utilisation.
Conclusion
Les cas d’utilisation sont un puissant moyen pour modéliser ce dont le système a besoin. Un
cas d’utilisation est une description de bout en bout de l’utilisation du système pour exécuter
une tâche, et non une combinaison quelconque d’un certain nombre d’étapes de calcul. Nous
devons garder à l’esprit, la granularité des cas d’utilisation pour contenir la complexité.
75
Evaluation
1. Quand utilise-t-on les relations de cas d’utilisation suivantes et pourquoi?
i. << Extend>>
ii. << Uses>>
2. La tâche de la saisie et l’analyse des exigences est difficile et complexe pour une
variété de raisons.
i. Les exigences sont les exigences de clients qui sont en fait les besoins des

utilisateurs du système et non ceux des développeurs.
ii. Tout système a de nombreux utilisateurs (ou types d’utilisateurs), alors que
chaque utilisateur peut savoir ce qu’il ou elle fait.
iii. Très souvent, les utilisateurs ne savent pas quelles sont les exigences ou
comment les spécifier de manière précise.
iv. Différents types d’utilisateurs ont, des exigences différentes, parfois

contradictoires. Comment pouvez-vous, en tant qu’analyste des exigences d’un
système, aider à surmonter l’un de ces problèmes, et créer un modèle de cas
d’utilisation?
3. Quelles sont les différences et les relations entre les fonctions du système et les
cas d’utilisation? Comment peuvent-ils être identifiés?
4. Prenons un exemple d’un système de bibliothèque. Supposons qu’un membre de

la bibliothèque est autorisé à emprunter jusqu’à six articles (par exemple, une copie
d’un livre, un journal, etc). Le système effectue les tâches d’emprunt d’un exemplaire
d’un livre, d’extension d’un prêt, et de vérification de la réservation. Ecrire les
cas d’utilisation qui représentent ces tâches, et utiliser un diagramme de cas
d’utilisation pour représenter les relations entre ces cas d’utilisation.
5. Seul ou en groupe, essayez de construire les cas d’utilisation de la façon suivante:
i. Identifier les cas d’utilisation de votre système
ii. Identifier les acteurs liés à chacun des cas d’utilisation identifiés dans (a)
iii. Fournir les spécifications de cas d’utilisation pour les cas d’utilisation figurant
dans la tâche (b). Sélectionnez seulement quatre cas d’utilisation clés qui reflètent les
principales tâches de votre projet.
iv. Fournir un modèle de cas d’utilisation pour montrer les relations entre les
acteurs et tous les cas d’utilisation de votre système
Remarque: Quatre principaux cas d’utilisation sélectionnés seront utilisés dans les étapes
suivantes du processus de développement de logiciels.
76
Activité 3.3 - Modèle conceptuel
3.3.1 Concepts et Classes
Une activité importante et typique dans l’analyse des besoins orientée objet est d›identifier
les concepts liés aux exigences et de créer un modèle conceptuel du domaine. Le
terme domaine couvre la zone de l’application, dans lequel nous travaillons ; par exemple, le
magasin dans notre étude de cas du système Terminal de point de vente.
La modélisation conceptuelle (parfois appelé modélisation des domaines) est l’activité qui
consiste à découvrir quels concepts sont importants pour le système. Ce processus nous aide
à mieux comprendre le problème, et à développer une meilleure connaissance de l’activité de
notre client.
Un modèle conceptuel illustre les concepts abstraits et significatifs dans le domaine du

problème. La création de concepts est l’étape la plus essentielle de l›analyse et de l›enquête
du domaine dans la modélisation orientée objet en vue de la construction de logiciels
véritablement extensible et réutilisables. L’objectif de cette étape est la décomposition du
problème dans des concepts ou des objets individuels.
De manière informelle, un concept est une idée, une chose ou objet. Plus formellement, un

concept peut être considéré en termes de son symbole, intension et extension:
• Symbole - des mots ou des images représentant un concept. On peut y faire

référence quand on parle de ce concept.
• Intension - la définition d’un concept.
• Extension - l’ensemble des exemples ou des instances à laquelle le concept
s’applique.
Chaque exemple particulier qui applique le concept est appelé une instance de ce
concept. Par exemple, le symbole Module tel qu›il est appliqué dans certaines universités est
un concept :
• Qui a le sens de “ représenter un cours offert dans le cadre d’un diplôme dans
cette université “ ayant un code, un titre, et un nombre de crédits, etc…
• L’extension de tous les modules offerts à l’université.
En UML, les termes de classe et de type sont utilisés, mais pas le terme concept. Nous
pouvons échanger ces termes dans la mesure où nous savons bien que nous sommes
à l’étape de l’analyse des besoins et nous comprenons et nous étudions le domaine du
problème. Chaque instance d’une classe est appelée un objet de la classe. Par exemple,
pour une classe appelée «étudiant», JahnSmith et JaneBrown sont des instances de la classe
«étudiant». Par conséquent, une classe définit un ensemble d’objets.
Les notions de classe et d’objet sont liées entre elles étant donné que l’un ne peut pas exister
sans l’autre, et que tout objet appartient à une classe.
77
Les différences entre les deux notions sont les suivantes:
• Un objet est une entité concrète - qui existe dans l’espace et le temps (propriété
persistante des objets);
• Une classe est une abstraction d’un ensemble d’objets.
La définition UML d’une classe est “une description d’un ensemble d’objets qui partagent
les mêmes attributs, opérations, méthodes, relations et sémantique”. Cela couvre les classes
utilisées à toutes les étapes dans un processus de développement OO.
3.3.2 Identification des concepts
Une distinction importante entre l’analyse OO et l’analyse structurée est la décomposition

par concepts (objets) plutôt que la décomposition par fonctions. Le point clé de cette
décomposition est de trouver ce qui peut avoir un comportement, et de décider plus tard dans
la conception et la mise en œuvre comment ils se comportent afin de réaliser la fonctionnalité
du système. Deux activités qui sont essentielles à l’application de l’orientée objet sont:
• L’identification des objets candidats de la situation du problème, et

• La sélection de ces objets candidats qui sont susceptibles d’être utiles à un
système d’information et qui sont ensuite développés et précisés dans un modèle
d’objet (modèle conceptuel)
• Il y a généralement deux stratégies pour identifier les concepts.
La première consiste à trouver des concepts à partir des descriptions textuelles du domaine
du problème selon la liste des catégories de concept. Les concepts et objets (choses) peuvent
être divisés en différentes catégories en fonction de la nature de leurs instances. La liste des
catégories de conception dans le tableau 3.11 a été trouvé utile dans l’identification des
concepts.
Tableau 3.11: Guide pour identifier les concepts

Catégorie de Concepts Exemples
objets physiques ou tangibles (ou des Terminal de point de vente, Maison,

choses) Voiture, Mouton, personne, Avion
endroits Magasin, bureau, aéroport, bureau de

police, …
documents, spécifications, dessins, Spécification de l’Article, Description du

ou descriptions de choses Module, Description du Vol
transactions Vente, paiement, réservation
rôle des personnes Caissier, étudiant, docteur, pilote
78
conteneurs d’autres choses Magasin, bibliothèque, Avion
choses dans un conteneur Produit, livre, Passager
autres ordinateurs ou de systèmes Système de contrôle de carte de crédit,

électro-mécaniques externes à notre Système de contrôle du trafic aérien
système
concepts abstraits faim, Acrophobie
organisations Département de Ventes, Club, …
Evénements et incidents historiques Vente, vol qualifié, Réunion, vol, crash,

atterrissage
Processus (souvent pas représentés Vendre un produit, Réserver un Siège

en tant que concept, mais parfois oui)
règles et politiques Politique de Retour d’un produit, Politique

d’Annulation
catalogues Catalogue de Produits, Catalogue de

Pièces
dossiers de financement, le travail, les Reçu, Contrat de Travail, trace de

contrats, les questions juridiques Maintenance
instruments et services financiers Stock
manuels, livres Manuel d’utilisation, Manuel de

Réparation
Cette stratégie consiste à créer une liste de concepts candidats par rapport aux exigences
de la description du client, des rapports d›enquête initiale, les définitions des fonctions du
système, et les cas d›utilisation. Une autre technique simple et utile pour l’identification des
concepts est d’identifier le nom et syntagmes nominaux dans les descriptions textuelles d’un
domaine de problème, et les considérer comme des concepts ou des attributs candidats.
Attention:
Des précautions doivent être prises si ces méthodes sont utilisées; la correspondance
mécanique nom pour nom des concepts n’est pas possible, les mots dans les langues
naturelles sont ambigus, et les catégories conceptuelles peuvent comprendre des concepts
qui sont soit attributs, des événements ou des opérations qui ne devraient pas être modélisés
comme des classes. Nous devrions nous concentrer sur les objets / classes impliquées dans
la réalisation des cas d›utilisation.
Considérer notre cas du système Terminal de vente, des cas d’utilisation Acheter des articles
en payant en espèces. Nous pouvons identifier quelques phrases nominales comme le montre
la figure 3.7. Certains des syntagmes nominaux dans le cas d’utilisation sont des concepts
candidats; certains peuvent être des attributs de concepts.
79
Figue. 3.7: Modèle conceptuel initial pour le domaine de point de vente
Les lignes directrices suivantes sont utiles pour identifier les concepts:
• Il est préférable d’indiquer sur un modèle conceptuel beaucoup trop de concepts,

que d’en spécifier trop peu.
• Ne pas exclure un concept tout simplement parce que les exigences ne montrent
pas un besoin évident de retenir des informations à ce sujet.
• Il est fréquent d’omettre des concepts pendant la phase initiale d’identification,
et de les découvrir plus tard, lors de l’examen des attributs ou associations,
ou pendant la phase de conception. Dans ce cas ils sont ajoutés au
modèle conceptuel.
• Notez un concept en tant que candidat dans le modèle conceptuel quand vous
n’êtes pas sûr qu’il ne doit pas être inclus.
• En règle générale, un modèle conceptuel n’est pas tout à fait correct ou tout à
fait faux, mais plus ou moins utiles; il est un outil de communication.
3.3.3 Les associations dans un modèle conceptuel
Un modèle conceptuel avec des concepts totalement indépendants seulement est

évidemment inutile, comme des objets de différentes classes doivent être liés les uns
aux autres afin qu’ils puissent interagir et collaborer entre eux pour mener à bien les
processus. Dans UML, une association est une relation entre deux classes qui spécifient
comment des instances des classes peuvent être reliées entre eux et travailler ensemble. Dans
le même sens que les instances d›une classe sont des objets, les instances de l›association
sont les liens entre les objets des deux classes - ce que signifie que les objets de la même
classe «partagent les mêmes relations».
Multiplicité
En ce qui concerne une association entre les classes, une information importante est de savoir
comment le nombre d’objets d’une classe (dite “A”) peut être associée à un objet d’une autre
classe (dite “B”), à un moment donné. Nous utilisons la multiplicité pour représenter cette
information. Un exemple montre les expressions de multiplicité et leur signification.
80
Figue. 3.8: Exemple d’expression de multiplicité
La détermination de la multiplicité expose souvent à l’occultation des contraintes intégrées

dans le modèle. Par exemple, que l’association qui relie personne et compagnie dans la figure
précédente soit un à plusieurs ou plusieurs à plusieurs, cela dépendra de l›application.
Les objets peuvent avoir plusieurs sortes de relation, et les classes (ou concepts) peuvent
avoir toutes sortes d’associations dans un domaine de problème donné. Une association doit
remplir les objectifs suivants.
Une association entre deux classes doit fournir des connexions physiques ou conceptuelles

entre les objets des classes.
Seuls les objets qui sont associés entre eux peuvent collaborer les uns avec les autres à travers
les liens.
Le rôle d’une liaison entre les objets peut être décrit comme suit:
“Un lien représente l’association spécifique par lequel un objet (le client) applique
les services d’un autre objet (le fournisseur), ou par lequel un objet peut accéder
à un autre objet”.
Comme l’identification des concepts, une liste de catégorie d’association peut

être utile. La liste présentée dans le tableau 3.12 contient des catégories
communes qui sont généralement considérés.
Tableau 3.12: Liste de catégorie « Association »

Catégorie d’Association Exemples
A est une partie physique de B Tiroir-Terminal
A est une partie logique de B LignedeVente-Vente
A est une espèce / sous-classe paiementCash-paiement, volNonstop-Vol

/ sous-type de B
A est physiquement contenue Terminal-Magasin

dans B
A est logiquement contenue DescriptionProduit-Catalogue,

dans B
A est une description de B DescriptionProduit -Produit, DescriptionVol-Vol
A est une ligne d’une LignedeVente-Vente

transaction ou d’un rapport B
81
A est connu / connecté / Vente-Terminal

enregistré / rapporté / capturé
dans B
A est un élément de B Caissier-Magasin, pilote-avion
A est une sous-unité Département-magasin, entretien-Avion

organisationnelle de B
A utilise ou gère B Caissier-Terminal, pilote-Avion
A communique avec B Client-caissier, ReservationAgent-passagers
A est liée à une transaction Client-paiement, Passager-ticket

avec B
A est une opération liée à une Paiement-Vente, réservation-annulation

autre transaction B
A est à côté de B Terminal-Terminal, Ville-Ville
A est possédée par B Terminal-Magasin, Avion-Vol
Source: Liu, (2001)
Voici quelques associations hautement prioritaires qu’il est important d’inclure dans un modèle
conceptuel:
• A est une partie physique ou logique de B.

• A est physiquement ou logiquement contenue dans B.
• A est enregistré dans B.
Associations du domaine « point de vente »
Nous pouvons maintenant ajouter des associations au modèle conceptuel du système Terminal
de point de vente créé dans la section précédente comme indiqué dans la figure 3.9.
82
Figue. 3.9: Modèle conceptuel pour le Terminal de point de vente (concepts et associations)
3.3.4 Attributs dans un modèle conceptuel
Chaque instance d’un concept peut avoir des propriétés utiles. Par exemple, une vente
a une date et une heure; un module a un code, un titre, et un certain nombre de crédits,
un étudiant a un nom et un âge, etc. Un attribut de classe est l›abstraction d›une seule
caractéristique ou une propriété d›entités ayant été extraites comme objets de la classe. À
tout moment, l›attribut d›un objet donné dans la classe est une valeur logique de données
représentant la propriété correspondante de l›objet, et est appelé la valeur de l’attribut
de l’objet à ce moment. Ainsi, un objet a exactement une valeur pour chaque attribut à un
moment donné. Par conséquent, la valeur d’un attribut d’un objet peut changer au fil du
temps. Par exemple,
le temps et la date sont des attributs de la classe vente, et une instance
de vente peuvent être une vente a lieu à 13h30 le 1/01/2016.
Le code, le titre, et le crédit sont trois attributs de la classe Module, et une

instance de module peuvent avoir un code MP206, le titre: génie logiciel et
développement du système, et le crédit: 20.
83
Le prénom et l’âge sont des attributs de l’élève, et un élève peut avoir pour nom

de Jean Loïc, et être âgé de 19 ans.
Un attribut a un nom, et peut spécifier le type de des données décrites par

l›attribut, et une valeur par défaut de l›attribut.
Quelques règles pour les attributs:
Garder l’attribut simple
Les attributs dans un modèle conceptuel doivent de préférence être simples ou des types de
données pures :
Intuitivement, les types des attributs les plus simples sont ce qu’on considère
comme types primitifs de données: booléen, date, numérique, String (texte),
Temps.
D’autres types simples comprennent : Adresse, Couleur, Géométrique (Points,

Rectangle,.. .), numéros de téléphone, numéro de sécurité sociale, le code
universel des produits(UPC), Code Postal, types énumérés.
Aucun attribut comme clé étrangère
Les attributs ne doivent pas être utilisés pour relier les concepts dans le modèle conceptuel,
mais pour stocker des informations sur les objets eux-mêmes. La violation la plus courante
de ce principe consiste à ajouter une sorte d’attribut de clé étrangère, comme on le fait
habituellement en faisant la conception des bases de données relationnelles, afin d›associer
deux types. Par exemple, l›attribut NumeroTerminalActuel dans la classe Caissier illustré par la
figure 3.10 est indésirable parce que son but est de relier la classe Caissier à la classe Terminal.
La meilleure façon d›exprimer qu›un caissier utilise un Terminal est une association, et non avec
un attribut clé étrangère.
Figure 3.10: Les attributs clés étrangères ne sont pas appropriés
3.3.5 Étapes pour créer un modèle conceptuel
• Appliquer les étapes suivantes pour créer un modèle conceptuel:

• Lister les concepts candidats à l’aide de la liste des Catégories de concept et les
phrases d’identification de nom en rapport avec les exigences actuelles à l’étude.
• Dessinez-les dans un modèle conceptuel.
84
• Ajouter les associations nécessaires pour enregistrer les relations

• Ajouter les attributs nécessaires pour satisfaire les exigences d’information.
Le modèle conceptuel doit être créé en enquêtant sur le fonctionnement du système, les cas
d’utilisation et d’autres rapports initiaux sur le domaine. Les modèles conceptuels ne sont pas
des modèles de conception de logiciel, tels que les classes Java ou C++. Par conséquent, un
modèle conceptuel peut montrer les éléments suivants :
• concepts
• associations entre concepts
• les attributs des concepts.
Les éléments suivants ne sont pas adaptés à un modèle conceptuel:
• Un artefact de logiciels, telle qu’une fenêtre ou une base de données, à moins

que le domaine à modéliser soit concepts logiciels, tels que le modèle d’une
interface utilisateur graphique.
• Opérations (responsabilités) ou méthodes.
Conclusion
Cette activité vous a permis de comprendre comment mettre en place un modèle conceptuel.
Vous avez pour faire la différence entre un certain nombre de concepts importants comme
classes, objets, attributs, association, etc. L’accent a été mis sur les stratégies à utiliser pour
identifier, les concepts, les attributs. Des règles ont été énoncées pour la mise en place des
associations entre deux classes.
Evaluation
Identifier des classes dans le problème suivant. Pour chaque classe, identifier leurs attributs
(membres de données)
Une station météorologique est un ensemble de logiciels contrôlé qui recueille des données,
effectue des traitements sur ces données et transmet ces données pour un traitement
ultérieur. Les instruments comprennent des thermomètres aériens et terrestres, un anémomètre,
une girouette, un baromètre et un pluviomètre. Les données sont recueillies toutes les cinq
minutes. Les stations météorologiques transmettent leurs données à un ordinateur d’une zone
donnée en réponse à une demande provenant de ce dernier. L’ordinateur de la zone rassemble
les données recueillies et l’intègre avec des rapports provenant d’autres sources telles que les
satellites et les navires. Il génère ensuite un ensemble de cartes météorologiques locales.
85
Considérons l’énoncé du problème suivant:
“Le client d’une banque doit être en mesure de déposer un montant dans son compte et d’en
retirer en utilisant un écran tactile (ATM). Chaque transaction doit être enregistrée, le client doit
être en mesure d’examiner toutes les transactions effectuées dans le compte. L’enregistrement
des transactions doit tenir compte de la date, du type, de la quantité et du solde du compte
après la transaction. Un client peut avoir deux types de compte - un compte courant et un
compte d’épargne. L’accès à l’interface ATM est fourni par un code PIN de 4 chiffres entiers de
0 à 9.Dessinez un schéma conceptuel et fournir trois attributs clés pour chaque classe définie.
Activité 3.4 – Comportement du système: diagrammes de séquence et

des opérations système
Présentation
Cette activité a l’intention d’introduire la façon de :
Identifier les événements du système et les opérations du système
Créer un diagramme de séquence du système pour des cas d’utilisation
Vous avez besoin d’identifier les opérations que le système doit effectuer et dans
quel ordre le système a besoin d’effectuer ces opérations pour mener à bien un
cas d›utilisation, et l›effet d›une telle opération sur le système, c’est-à-dire sur les
objets du système.
Un cas d’utilisation définit une classe de conversations entre les acteurs et le

système, et une conversation individuelle de cette classe est une réalisation du cas
d›utilisation. Évidemment, il peut y avoir de nombreuses réalisations pour un cas
d›utilisation. Un scénario d›un cas d›utilisation est un cas particulier ou le chemin
réalisé à travers le cas de l›utilisation, c’est-à-dire une réalisation particulière du
cas d›utilisation.
3.4.2 Evénements d’entrée du système et opérations du Système
Au cours des interactions dans toute réalisation, les acteurs génèrent des événements système,
et demandent au système d’effectuer certaines opérations en réponse. Les événements
générés par les acteurs sont très étroitement liés à des opérations que le système peut
effectuer. Cela implique que vous aviez identifié les opérations de système en identifiant les
événements que les acteurs génèrent.
Définition des terminologies :

Un événement d›entrée du système est une entrée externe générée par un acteur pour un
système. Un événement d’entrée du système déclenche une opération en réponse.
Une opération système est une opération que le système exécute en réponse à un événement
d’entrée du système. Certaines opérations du système génèrent également des événements
86
de sortie aux acteurs pour aller vers le prochain événement système qu’un acteur peut
effectuer.
Un événement système est soit un événement d’entrée ou un événement de sortie.
Par conséquent, un événement d’entrée du système déclenche une opération système, et

l’opération système répond à un événement d’entrée du système.
Maintenant, nous pouvons formellement définir un scénario de cas d›utilisation, comme

une séquence d›événements système qui se produisent au cours d›une réalisation du cas
d›utilisation. Par exemple, prenons le cas d›utilisation Faire des appels téléphoniques pour
un système téléphonique, qui implique deux acteurs, l’Appelant (initiateur) et l’Appelé. Les
séquences d’événements suivantes montrent un scénario de ce cas d’utilisation:
Événements d’entrée Événements de sortie
L’Appelant soulève le récepteur Le son de la composition du numéro

commence
L’appelant compose (5551234) Le téléphone sonne chez l’Appelé
Le son de la sonnerie s’entend chez

l’Appelant
L’Appelé répond au téléphone La sonnerie du téléphone s’arrête
L’Appelé raccroche La connexion se coupe
L’Appelant raccroche
On peut représenter l’ensemble des séquences d’événements comme un scénario en utilisant

un diagramme de traceur d’événements.
87
Figure 3.11: Diagramme de la trace des évènements systèmes du Téléphone pour le cas
d’utilisation “ Faire des appels téléphoniques “ (Source: Liu, (2001))
3.4.3 Diagramme de séquence du système
À la phase d’analyse des besoins, il est nécessaire de définir le système en le traitant comme
une boîte noire de sorte que le comportement est une description de ce qu›un système fait,
sans expliquer comment il le fait. Par conséquent, nous sommes principalement intéressés par
l’identification et l’illustration des opérations système qu›un acteur demande au système. Cela
signifie que nous sommes intéressés à trouver les événements d›entrée du système en
inspectant les cas d›utilisation et leurs scénarios.
Par exemple, le parcours typique des événements dans le cas d’utilisation Faire des
appels téléphoniques indique que l’appelant et l’appelé génèrent les événements
d’entrée du système qui peuvent être désignés par décrocher, composerNumTelephone,
repondreTelephone, raccrocher. D’une manière générale, un événement prend des paramètres.
Pour identifier les opérations système, nous pouvons également utiliser un diagramme de
trace pour montrer, pour un parcours particulier d’événements au sein d’un cas d’utilisation, les
acteurs externes qui interagissent directement avec le système, le système (comme une boîte
noire), et les événements d’entrée du système que les acteurs génèrent. Et nous appelons un
tel diagramme de trace simplifiée un diagramme de séquence du système. Un diagramme de
séquence du système pour le cas d’utilisation Faire des appels téléphoniques peut être illustré
comme dans la Figure 3.12.
88
Figure 3.12: Diagramme de séquence du système téléphonique pour le cas d’utilisation “Faire
des appels téléphoniques”
Un diagramme de séquence du système doit être fait pour le parcours typique des
événements du cas d’utilisation, et peut-être pour les parcours alternatifs les plus intéressants.
Les étapes de réalisation d’un diagramme de séquence sont :
Tracez une ligne représentant le système comme une boîte noire.
Identifier chaque acteur qui interagit directement avec le système.
Tracez une ligne pour chaque acteur.
A partir du parcours typique des évènements du cas d’utilisation, identifier les

événements d’entrée (externes) du système que chaque acteur génère et les
illustrer sur le diagramme.
Conclusion
Dans cette activité, vous avez appris comment représenter le comportement du système par le
biais d’un diagramme de séquence des opérations du système, à partir d’un cas d’utilisation.
Evaluation
1. Décrire clairement l’importance du diagramme de séquence.
2. A partir des études de cas individuels ou en groupe, identifiez les événements

d’entrée du système pour quatre cas d’utilisation clés sélectionnés qui reflètent
les principales tâches de votre projet, avec l’aide du diagramme de séquence du
système. Ceux-ci sont associés aux opérations du système.
Remarque: Les opérations système sélectionnées seront utilisées dans la phase de conception

orientée objet.
89
La phase d’analyse du développement logiciel met l’accent sur la compréhension des
exigences, des concepts et des opérations liées au système. Les enquêtes et l’analyse sont
souvent caractérisées comme se concentrant sur les questions de : Quels sont les processus,
les concepts, les associations, les attributs, les opérations.
Dans cette unité, vous avez exploré quelques artéfacts utiles qui peuvent être utilisés pour
capturer les résultats d’une enquête et d’analyse et qui se résument comme suit :
Artéfact d’analyse Questions résolues
Cas d’utilisation Quels sont les processus de domaine?
Modèle conceptuel Quels sont les concepts, les associations et les attributs?
Diagrammes de séquence du Quels sont les événements d’entrée et les opérations du

système de système?
1. Exprimez en UML qu’un étudiant peut suivre jusqu’à six modules, et que
au plus 25 élèves peuvent être inscrits pour chaque module.
2. Exprimez en UML qu’un module fait partie d’une formation ; qu’une roue
fait partie d’un véhicule, qu’un employé est un membre d’une équipe.
3. Discutez de l’utilisation de l’agrégation et de la composition.
4. Exprimez en UML la relation entre une personne et ses chemises. Qu’en

est-il des chaussures d’une personne? Pensez-vous que vous avez exposé
une faiblesse dans UML? Pourquoi ou pourquoi pas?
5. Qu’est-ce que la multiplicité de l’association entre les classes dans chacune

des paires suivantes?
6. Les classes Dessert et recette dans un tutoriel de cuisson
7. Les classes légumes et nutriments dans un système de gestion de

l’exploitation de la culture hydroponique
8. Les classe chambre et fenêtre dans un système de conception architecturale.
Considérez le scénario suivant :
La compagnie Total (T) Ltd souhaite informatiser son système de pompes à essence. Le
programme qui sera conçu doit commencer dans un état d’attente. En appuyant sur une
touche, il y aura une demande pour mettre le bout de la pompe dans le réservoir d’essence. Il
90
existe quatre types de carburant disponible: le GPL à un coût de 800 shillings tanzaniens par
litre. Le « Sans plomb » à un coût de 700 shillings tanzaniens par litre. Le Diesel à un coût
de 850 shillings tanzaniens par litre et le « super sans plomb » a un coût de 900 shillings
tanzaniens par litre. Votre programme doit permettre à l’utilisateur de sélectionner le type de
carburant nécessaire. L’utilisateur doit être en mesure d’annuler la transaction avant et pendant
la saisie du montant et doit pouvoir entrer la quantité de carburant nécessaire. Pour des
raisons de sécurité seulement un maximum de 50 litres peut être livré en une fois.
Après la distribution, il doit y avoir un message de remerciement et une indication de la

monnaie à rendre. Il doit y avoir une requête pour redéposer le bout de la pompe sur son
support. Le système doit revenir à son état d’attente.
Identifier les classes dans le domaine du problème posé, et proposer un “ schéma

conceptuel “ . Ajouter les associations s’il y en a.
Un cas d’utilisation possible de ce système peut être “ SelectionnerTypeCarburant “ afin

d’obtenir la quantité nécessaire de carburant. Dessinez le diagramme de séquence du cas
d’utilisation “ SelectionnerTypeCarburant “.
Dessinez un objet pour montrer le fonctionnement du système pour le cas d’utilisation

“ SelectionnerTypeCarburant “.
Fournir un diagramme de traceur pour le cas d’utilisation “ SelectionnerTypeCarburant “.


(October 30, 2004), ISBN-13: 978-0131489066
Liu Z., (2001), “Object-Otiented Software Development Using UML”, The United Nations
Eyrolles
91
Unité 4 : Conception Orientée

Objet et Traduction Dans un
Langage
Après l’identification des besoins et la création d’un modèle de domaine, des méthodes sont
ajoutées aux classes du logiciel, en des messages entre les objets pour remplir les exigences. Il
est extrêmement important de définir quelle méthode appartient à quelle classe et comment
les objets doivent interagir. Ceci est le cœur de ce que signifie le développement d’un système
orienté objet, outre la schématisation des diagrammes du modèle de domaine.
À la fin de cette unité, vous devriez être capable de :
• Expliquer la notion de diagrammes de collaboration

• Appliquer la notation UML au diagramme de collaboration
• Décrire la nature de la phase de conception
• Utiliser des modèles pour l’attribution de responsabilités à des objets
• Utiliser des modèles pour créer des diagrammes de collaboration
• Générer du code à partir des diagrammes issus des étapes précédentes
Termes clés
Modèle GRASP Les modèles du GRASP sont une aide
d’apprentissage pour aider quelqu’un à comprendre l’essentiel
de la conception objet, et d’appliquer le raisonnement de la
conception à la méthodologie rationnelle, ainsi explicable. Ils
décrivent les meilleures pratiques, les meilleures conceptions,
et enregistrent l’expérience de manière à ce qu’il soit possible
à d’autres de réutiliser cette expérience. Cette approche basée
sur la compréhension et l’utilisation des principes de conception
utilise les modèles d’attribution de responsabilités.
Conception logicielle La conception logicielle est une activité

dans laquelle les composants logiciels et leurs relations sont
identifiés, en fonction des besoins du client. La conception
est la façon de résoudre un problème, donc il y a toujours un
processus de conception.
92
Unité 4 : Conception Orientée Objet et Traduction Dans un Langage
Processus de conception de logiciel Le processus

de conception orienté objet comprend des activités de
conception de l’architecture du système, d’identification
des objets du système, de description de la conception
en utilisant des modèles d’objets différents, et de
documentation des interfaces de composants.
Activité 1.1 - Les diagrammes interactifs
Présentation
Un contrat pour les opérations du système décrit ce que l’opération du système fait, mais
ne montre pas la solution à comment les objets du logiciel vont travailler ensemble pour
remplir le contrat de l’opération. Ceci est plutôt spécifié dans l’élaboration des diagrammes
d’interaction en UML. Une tâche majeure de la phase de conception est de créer les
diagrammes d’interaction pour toutes les opérations du système.
4.1.1 Types de diagrammes interactifs
L’UML définit deux types de diagrammes d’interaction, chacun pouvant être utilisés pour
exprimer des messages d’interactions similaires ou identiques :
Les diagrammes de collaboration
Les diagrammes de séquence des objets
Chaque type a ses forces et ses faiblesses, comme illustré ci-dessous :
Lors du dessin des diagrammes devant être publiés sur des pages de faible largeur,
les diagrammes de collaboration ont l’avantage de permettre l’expansion verticale
pour de nouveaux objets . ’ajout d’objets additionnels dans un diagramme de
séquence doit se faire par la droite, ce qui est un facteur limitant. D’autre part,
dans les diagrammes de collaboration il est difficile de voir facilement la séquence
des messages.
93
Le tableau 4.1 décrit la différence entre les diagrammes de séquence et de collaboration.
Tableau 4.1 : Différence entre diagramme de séquence et diagramme de collaboration

Type Points forts Faiblesses
Diagramme Montre clairement la séquence ou l’ordre Contraint d’étendre vers
de séquence temporel des messages la droite lors de l’ajout
de nouveaux objets;
Notation simple
consomme l’espace
horizontal
Diagramme Économie d’espace - possibilité d’ajouter de Difficile de voir la
de nouveaux objets dans deux dimensions séquence des messages
collaboration
Offre une meilleure illustration des Plus de notation
ramifications complexes, des itérations et des complexes
comportements concurrents
Le tableau 4.2 décrit la différence entre le diagramme de séquence système et le diagramme

de séquence objet
Tableau 4.2 : la différence entre le Diagramme de Séquence Système et le Diagramme

de Séquence Objet
Diagrammes de Séquence Système Diagrammes de Séquence Objet
Illustre l’interaction entre l’ensemble du Montre les interactions entre les

système et les acteurs externes objets du système
Affiche uniquement les événements externes Identifie les opérations des objets
du système et identifie ainsi des opérations
système
Sont créés au cours de la phase d’analyse Les modèles sont créés et utilisés
dans la phase de conception
4.1.2 Les diagrammes de collaboration
Un diagramme de collaboration est un graphique montrant un certain nombre d’objets et les

liens entre eux, et qui, en outre, affiche les messages qui sont transmis à partir d’un objet à
un autre. Les diagrammes de collaboration et les diagrammes de séquence objet peuvent
exprimer des constructions similaires et différentes personnes peuvent préférer l’un à l’autre.
Nous allons principalement discuter et utiliser les diagrammes de collaboration.
À titre d’exemple, le diagramme de collaboration pour l’opération “effectuerPaiement(montant

payé)” du système de vente via un terminal est illustré par la figure 4.
94
Figure 4.1 : Un diagramme de collaboration pour l’opération effectuerPaiement
(montant payé)
Par exemple, le diagramme de séquence objet pour l’opération “ effectuerPaiement (montant

payé)” pour le système de vente est illustré par la figure 4.2.
Figure 4.2 : Diagramme de séquence objet pour l’opération effectuerPaiement (montant payé)
Les deux diagrammes représentent le pseudo programme suivant :
: Terminal accepte l’appel de sa méthode effectuerPaiement()
(à partir d’un objet d’interface);
: Terminal appel de la méthode effectuerPaiement() de :Vente;
:Vente appel du constructeur de la classe Paiement pour créer un nouveau paiement new:
paiement
95
4.1.3 La notation UML pour les diagrammes de collaboration
Représenter une valeur de retour
Certains messages envoyés à un objet nécessitent une valeur qui doit être retournée à l’objet
émetteur. Une valeur retournée peut être montrée en faisant précéder le message du nom
d’une variable suivi d’un opérateur d’affectation (‘:=’) comme illustré dans la Figure 4.3. Le type
de la valeur retournée peut être affiché sur le plan opérationnel. La syntaxe standard pour le
message est :
return := message(paramètre : Type paramètre) : returnType
Figure 4.3 : Valeurs retournées sur un diagramme de collaboration
Représentation de l’itération
Un objet peut envoyer plusieurs fois un message à un autre objet un certain nombre de fois.
Ceci est indiqué en préfixant le message avec un astérisque (‘*’) comme dans la figure 4.4.
Figure 4.4 : Représentation de l’itération sur un diagramme de collaboration
Représentation de la création des instances
Le message de création en UML est create, qui est indépendant des langages de

programmation, illustre une instance en cours de création. Optionnellement, la nouvelle
instance créée peut inclure le symbole <<new>> comme illustré à la Figure 4.5. Le message
create peut éventuellement prendre des paramètres lorsque certains attributs de l’objet à créer
doivent être définis avec une valeur initiale.
96
Figure 4.5 : Création d’une instance sur un diagramme de collaboration
Représentation du numéro de séquence du message
L’ordre des messages est illustré avec des numéros de séquence, comme illustré dans la Figure
4.6. Le plan de numérotation est :
Le premier message n’est pas numéroté. Ainsi, msg1() n’a pas de numéro.
L’ordre et l’imbrication des messages subséquents sont illustrés avec un schéma de

numérotation légal dans lequel les messages imbriqués leur ajoutent un numéro. L’imbrication
est faite par ajout du numéro du message entrant, au numéro de message sortant.
Figure 4.6 : Séquencement des numéros de message sur un diagramme de collaboration
Représentation des messages conditionnels
Parfois, un message peut être surveillé et peut être envoyé d’un objet à un autre uniquement
lorsqu’une condition est vérifiée. Ainsi, lors de l’exécution d’un objet, un choix de plusieurs
messages, surveillés par différentes conditions, sera envoyé. Dans un système séquentiel, un
objet peut envoyer un seul message à la fois et donc ces conditions doivent être mutuellement
exclusives. Lorsque nous avons des messages conditionnels mutuellement exclusifs, il
est nécessaire de modifier les expressions de séquence en ajoutant une lettre au chemin
conditionnel.
Figure 4.7 : Message conditionnel sur un diagramme de collaboration
Notez que :
97
L’une ou l’autre des actions 1a ou 1b pourrait s’exécuter après le msg1() selon les conditions.
Le numéro de séquence pour les deux est de 1, et a et b représentent les deux chemins.
Cela peut être généralisé à un nombre quelconque de messages conditionnels mutuellement

exclusifs.
Représentation des multi-objets
Nous appelons multiobjet un ensemble logique d’instances/objets. Un multiobjet est une

instance d’une classe du conteneur et chaque instance est un ensemble d’instances d’une
classe ou d’un type donné. Par exemple, LignedeVente est une classe et chaque instance
est un ensemble de ventes. Chaque multiobjet est habituellement mis en œuvre comme
un groupe d’instances stocké dans un conteneur ou un objet de type collection. Dans un
diagramme de collaboration, un multiobjet représente un ensemble d’objets sur l’extrémité
“plusieurs” d’une association. En UML, un multiobjet est représenté par une icône de pile
comme illustré dans la figure 4.8.
Figure 4.8 : Multiobjet et Message pour Multiobject
Evaluation
1. Décrire clairement la notation UML de base utilisée dans les diagrammes de

collaboration.
2. Quelle est la différence entre *msg(), *[true] msg(), et [true] msg() dans un
diagramme de collaboration?
3. Élaborer un diagramme de collaboration dans lequel :
4. Un objet O reçoit le message meg d’un acteur;
5. O crée un nouvel objet P;
6. P envoie un message à Q;
98
7. Puis O détruit P
8. Faire la distinction entre les termes suivants
9. Diagramme de séquence et diagramme de collaboration
10. Diagramme de séquence système et diagramme de séquence objet
Activité 4.2 - Aperçu sur la phase de conception
Introduction
Les opérations complexes doivent être décomposées en de plus simples opérations internes
qui sont affectés à (ou réalisées par) d’autres objets. La principale tâche de la conception
consiste à créer les diagrammes de collaboration pour les opérations système identifiées
dans la phase de l’analyse préalable des besoins. Le plus important et le plus difficile dans la
génération de diagrammes de collaboration est l’affectation des responsabilités aux objets. Par
conséquent, le reste de cette activité portera essentiellement sur les principes généraux pour
l’affectation de responsabilité, qui sont structurées dans un format appelé modèles.
Les artefacts nécessaires pour créer les diagrammes de collaboration sont:
• Modèle conceptuel :
• Le concepteur peut choisir de définir les classes du logiciel correspondant aux
concepts. Les objets de ces classes participent aux interactions illustrées dans les
diagrammes d’interaction.
• Les contrats pour les opérations du système :
• Le concepteur définit les responsabilités et les conditions postérieures que les
diagrammes d’interaction doivent remplir.
• Les cas d’utilisation essentiels (ou réels):
• Le concepteur peut collecter des informations sur les tâches dont les diagrammes
d’interaction s’acquittent, en plus de ce qui est dans les contrats (N’oubliez pas
que les contrats ne disent pas beaucoup sur les sorties de l’interface utilisateur).
4.2.1 GRASP : Modèles pour l’attribution des responsabilités
Décider de quelles méthodes interviennent où et comment les objets devraient interagir est
extrêmement important. L’attribution de responsabilité est une étape cruciale/critique dans
l’élaboration des systèmes orientés objet.
Par définition, une responsabilité est un contrat ou l’obligation d’un objet. Les responsabilités
sont liées aux obligations des objets en fonction de leur comportement. Le but est d’aider à
appliquer méthodiquement les principes fondamentaux pour l’attribution des responsabilités
aux objets. Au sein des artéfacts UML, un contexte commun où ces responsabilités
(implémentées comme des méthodes) sont considérés est lors de la création de diagrammes
d’interaction. Les responsabilités peuvent être regroupées en deux types principaux :
99
Donner des responsabilités:
Ce sont des actions qu’un objet peut effectuer, notamment : faire quelque chose lui-même
comme la création d’un objet ou effectuer un calcul, amorcer une action ou opération dans
d’autres objets, contrôler et coordonner des activités dans d’autres objets.
Connaître les responsabilités :
C’est relatif à la connaissance qu’un objet détient : connaître les données privées encapsulées,
connaître les objets en relation, connaître les choses qui peuvent être dérivées ou calculées.
4.2.2 Créer les diagrammes de collaboration
Lors de la création des diagrammes de collaboration :
Commencer avec les responsabilités qui sont identifiées à partir des cas d’utilisation, du
modèle conceptuel et des contrats des opérations du système.
Attribuer ces responsabilités à des objets, puis :
Décider de ce que les objets doivent faire pour s’acquitter de ces responsabilités afin
d’identifier de nouvelles responsabilités qui sont de nouveau affectés à des objets.
Répétez ces étapes jusqu’à ce que les responsabilités identifiées soient acquittées et que le
diagramme de collaboration soit terminé.
Les responsabilités sont attribuées aux classes d’objets durant l’étape de la conception
orientée objet. Notez que la responsabilité n’est pas la même chose qu’une méthode, mais
les méthodes sont implémentées pour s’acquitter des responsabilités. Les responsabilités
d’un objet sont implémentées en utilisant les méthodes de l’objet qui agisse seul ou en
collaboration avec d’autres méthodes et objets. Par exemple, si on se réfère au système de
vente :
La classe Vente pourrait définir une méthode qui effectue l’impression d’une instance de vente;
nommons la méthode print, pour s’acquitter de cette responsabilité,
L’instance Vente peut avoir à collaborer avec d’autres objets, tels que l’envoi d’un message aux
objets LignedeVente en leur demandant d’imprimer eux-mêmes.
En UML, les responsabilités sont assignées aux objets lors de la création du diagramme de
collaboration et ce dernier représente à la fois l’attribution des responsabilités aux objets et
la collaboration entre ces objets pour la réalisation des responsabilités. Par exemple, tel que
présenté dans la Figure 4.9 :
Les objets Vente ont reçu une responsabilité pour imprimer eux-mêmes, qui est invoqué avec
un message print.
La réalisation de cette responsabilité exige une collaboration avec les objets LignedeVente en

leur demandant d’imprimer.
100
Figure 4.9 : Réaliser l’opération print sur chaque objet d’un Multiobjet
4.2.3 Principes généraux dans l’attribution des responsabilités
Les modèles sont les meilleurs principes pour l’attribution des responsabilités à des objets.
Les modèles sont des guides à la création de méthodes du logiciel. Ils sont des solutions aux
problèmes communs qui surviennent souvent. Dans ce module, le modèle GRASP (General
Responsability, Assignment Software Patterns) va être utilisé. Le modèle GRASP a le format
suivant :
Nom du modèle : Le nom donné au modèle

Solution : La description de la solution du problème
Problème : Description du problème que le modèle résout
Plus simplement, un motif est une paire problème/solution ayant un nom et qui peut être
appliqué à de nouveau contexte, avec des conseils sur la façon de l’appliquer dans des
situations nouvelles. Les modèles GRASP incluent les cinq modèles de base suivants :
Expert,
Créateur,
Haute Cohésion,
Faible Couplage et
Contrôleur.
GRASP 1 : Expert
C’est un modèle très simple qui est utilisé plus que tout autre modèle dans l’attribution des
responsabilités. La classe Expert est la classe qui possède les informations nécessaires pour
s’acquitter de la responsabilité. Les experts font des choses en fonction des informations qu’ils
connaissent. Attribuer la responsabilité à l’expert en information i.e. la classe qui dispose des
renseignements nécessaires pour s’acquitter de la responsabilité.
101
Exemple :
Figure 4.10 : Diagramme de collaboration pour obtenir le prix d’un produit
Ceci peut être résumé comme suit :
Classe Responsabilité
Vente Connaît la vente totale
LignedeVente Connaît le Sous-total de chaque ligne d’article
SpecificationProduit Connaît le prix des produits
GRASP 2: Créateur
La création des objets est l’une des activités les plus courantes dans un système orienté
objet. Il pose la question “qui devrait être responsable de la création d’instances d’une classe
particulière ?” Attribuer par exemple à la classe B la responsabilité de créer une instance de la
classe A, si l’une des conditions est vraie :
B contient A
B enregistre A
B regroupe (agrège) A
B utilise étroitement A
B dispose des données d’initialisation de A
Par exemple, dans le système Terminal de point de vente à travers un terminal, qui devrait
être responsable de la création d’une instance LignedeVente, partant du modèle Créateur,
nous devrions rechercher une classe qui agrège, contient des instances LignedeVent. Comme
Vente contient plusieurs objets LignedeVente, le motif Créateur suggère que Vente est le bon
candidat pour avoir la responsabilité de la création des instances LignedeVente comme le
montre la Figure 4.11. Cela signifie que la méthode “creerLigneProduit” sera définie dans la
classe Vente.
102
Figure 4.11 : Diagramme de collaboration pour créer un LignedeVente
GRASP 3 : Haute Cohésion
La cohésion ou la cohérence est la force des dépendances au sein d’un sous-système. La

cohésion est une mesure de la façon dont les responsabilités d’une classe sont fortement
liées et orientées. Il est le “ciment” interne avec laquelle un sous-système est construit. Un
composant est cohésif si tous ses éléments sont orientés vers une tâche et les éléments sont
essentiels pour effectuer la même tâche. Si un sous-système contient des objets non liés entre
eux, la cohérence est faible. Une haute cohésion est souhaitable.
Une classe avec une haute cohésion a des responsabilités fonctionnelles fortement liées, et
ne pas faire énormément de travail. Ces classes ont un petit nombre de méthodes avec
de simples mais très connexes fonctionnalités. Dans une bonne conception orientée objet,
chaque classe ne devrait pas faire trop de travail. Il faut juste attribuer quelques méthodes à
une classe et déléguer une partie des travaux pour s’acquitter de la responsabilité à d’autres
classes.
Les abstractions clés séparées à partir d’un contrôleur sont :
Alarme
Ascenseur
Portes
Registres
Figure 4.12 : Quatre classes séparées cohérentes pour gérer un ascenseur
103
GRASP 4 : Faible Couplage
Le couplage est une mesure de la manière dont une classe est fortement reliée à; a
connaissance de, ou s’appuie sur d’autres classes. Une classe avec un bas (ou faible)
couplage n’est pas dépendante de nombreuses autres classes. Lorsque nous attribuons une
responsabilité à une classe, nous aimerions affecter les responsabilités de manière à ce que le
couplage entre les classes demeure faible.
Dans l’exemple ci-dessous pour le cas d’utilisation “effectuerPaiement” et avec la

considération du couplage faible, la deuxième conception est préférable parce qu’elle
n’a pas besoin d’un lien supplémentaire entre Terminal et Paiement. Cette attribution de
la responsabilité est également justifiable parce qu’il est raisonnable de penser qu’une
classe Vente utilise étroitement la classe Paiement.
Première conception :
Seconde conception
Figure 4.13 : Vente crée le paiement avec couplage faible
GRASP 5 : Contrôleur
Qui gère un événement système? Attribuer la responsabilité pour la manipulation d’un

message d’événement système à une classe qui représente l’une de ces options :
Représente l’ensemble du système, l’appareil ou d’un sous-système (contrôleur de façade).
Représente un scénario de cas d’utilisation à l’intérieur duquel le l’événement système se

produit (Cas d’utilisation ou contrôleur de session)
104
Un contrôleur est une interface objet non-utilisateur qui est responsable de la gestion des
événements d’entrée du système, et le contrôleur définit la méthode pour l’opération
du système correspondant à l’événement d’entrée du système. Une solution possible est
d’ajouter/introduire une nouvelle classe, et le faire siéger entre l’acteur et les classes métiers.
Le nom de ce contrôleur est généralement appelé <nom>Handler. Le gestionnaire (Handler)
lit les commandes de l’utilisateur puis décide vers quelles classes les messages doivent être
dirigés. Le gestionnaire est la seule classe qui serait autorisée à lire et afficher. Le système
reçoit les événements externes d’entrée, impliquant habituellement une interface utilisateur
graphique exploitée par une personne.
Le modèle Contrôleur prend la forme suivante :
Tableau 4.3 : Modèle Contrôleur

Nom du Modèle Contrôleur
Solution Attribuer la responsabilité de la gestion de l’évènement
(entrée) système à une classe qui représente l’un des choix
suivants :
Représente le “système général” (contrôleur de façade).
Représente l’ensemble de l’entreprise ou organisation

(contrôleur de façade).
Représente quelque chose dans le monde réel qui est actif

(par exemple, le rôle d’une personne) qui pourrait être
impliquée dans la tâche (contrôleur de rôle).
Représente un gestionnaire artificiel de tous les

événements (entrée) du système d’un cas d’utilisation,
généralement appelé “<UseCaseName>Handler”
(contrôleur de cas d’utilisation).
Problème Qui devrait être responsable de la gestion des événements
d’entrée d’un système ?
Conclusion
Dans cette activité, vous avez appris comment utiliser le modèle GRASP pour attribuer des
responsabilités à une classe en vous basant sur les principes généraux qu’il met à notre
disposition. Les cinq principaux modèles de base GRASP ont été étudiés.
Evaluation
1. Expliquer clairement les aspects suivants du modèle objet :
2. Modèle Contrôleur
3. Modèle Cohésion
4. Un bon logiciel devrait avoir une cohésion élevée et un faible couplage. Expliquez.
105
Activité 4.3 - La conception du système Terminal de point de vente
Introduction
Cette section applique les modèles GRASP pour attribuer des responsabilités à des classes, et
pour créer les diagrammes de collaboration pour le système Terminal.
Nous considérons dans cette conception, les cas d’utilisation Acheter des articles
en espèce et Démarrer. Les Directives pour la réalisation des diagrammes de
collaboration (partiellement illustrée à la figure 4.14) comprennent:
Créer un diagramme distinct pour chaque opération du système qui a été identifiée et dont les
contrats sont définis. Si le diagramme est complexe, le diviser en des diagrammes plus petits.
À l’aide du contrat de responsabilités et des post-conditions, et de la description des cas

d’utilisation comme point de départ, concevoir un système d’interactions entre les objets pour
accomplir les tâches.
Appliquer les modèles GRASP pour faire une bonne conception.
Figure 4.14 : Lignes directrices pour la conception
Avec les cas d’utilisation, Acheter des articles en espèce et Démarrer, nous avons
identifié quatre opérations système à savoir : entrerProduit, finirVente, effectuerPaiement,
et commencer. Selon nos directives, nous devrions construire au moins quatre diagrammes
de collaboration. Selon le modèle Contrôleur, la classe Terminal pourrait être choisie comme
contrôleur pour la gestion de ces opérations.
Figure 4.15 : Liste de responsabilités de la classe Terminal
106
Nous devons examiner le contrat de entrerProduit pour savoir ce que la classe Terminal a

besoin de faire pour s’acquitter de cette responsabilité (voir tableau 4.4).
Tableau 4.4 : Post-Condition de l’opération “entrerProduit”

Post-conditions: Si une nouvelle vente, une instance Vente a été créé
(création d’instance).
S’il y a une nouvelle vente, l’instance Vente serait associée

avec l’instance Terminal (association formée).
Une instance LignedeVente a été créé (création d’instance).
L’attribut LignedeVente.quantite a été défini avec quantite().
L’instance LignedeVente a été associée à une instance

de SpecificationProduit en se basant sur le code universel du
produit (UPC)(association formée).
La création d’une nouvelle vente:
Les post-conditions de entrerProduit indiquent une responsabilité à l’égard de la création d’un

objet Vente.
Le modèle Créateur suggère la classe Terminal comme un candidat raisonnable créateur de

la vente, comme la classe Terminal enregistre les ventes (objet Vente).
Après que la classe Terminal ait créé l’objet Vente, une instance de Terminal peut lui être
facilement associée tout le temps.
La création d’une nouvelle ligne LignedeVente:
Lorsque l’objet Vente est créé, il doit créer une collection vide pour enregistrer toutes les
lignes futures LignedeVente qui seront ajoutées.
Cette collection sera maintenue par l’objet Vente, ce qui implique avec le modèle Créateur
que l’objet Vente est un bon candidat pour la création de la ligne (LignedeVente).
Figure 4.16 : Diagramme de collaboration pour la création d’une nouvelle ligne LignedeVente
107
Trouver la spécification du produit avec SpecificationProduit
La nouvelle ligne LignedeVente créée doit être associée à SpecificationProduit pour

avoir ses spécifications qui sont conformes au code universel du produit (UPC)
Ceci a besoin des paramètres du message de creerLigneVente envoyé à l’objet

Vente et qui contient l’instance SpecificationProduit spécifié par spec, et qui
correspond à l’UPC
Nous devons récupérer le les spécifications grâce à l’instance SpecificationProduit

avant que le message CreerProduit(spec,qty)soit envoyé à l’objet Vente
Partant du modèle Expert, CatalogueProduit contient toutes les spécifications

de specificationProduit, donc il est un bon candidat pour chercher dans
SpecificationProduit
La visibilité vers CatalogueProduit
Du contrat de la méthode commencer(), il est montré que la classe Terminal a été associée à

CatalogueProduit
La classe Terminal est responsable dans l’envoi du message nommé spec à CatalogueProduit
Par conséquent le diagramme de collaboration pour l’opération entrerProduit sera comme

illustré dans la Figure 4.17 :
Figure 4.17 : Diagramme de collaboration pour l’opération entrerProduit
Le diagramme de collaboration pour l’opération finirVente sera comme illustré dans la Figure

4.18.
108
Figure 4.18 : Diagramme de collaboration pour l’opération finirVente
Le diagramme de collaboration pour l’opération effectuerPaiement sera comme le montre la

Figure 4.19.
Figure 4.19 : Diagramme de collaboration pour l’opération effectuerPaiement
Le diagramme de collaboration pour la journalisation d’une vente terminée sera comme illustré

dans la Figure 4.20.
Figure 4.20 : Diagramme de collaboration de la journalisation d’une vente complète
109
Le diagramme de collaboration de l’opération commencer sera comme illustré dans la Figure

4.21.
Figure 4.21 : Diagramme de collaboration pour l’opération commencer
Conclusion
Cette activité a mis l’accent sur comment appliquer le modèle GRASP à une classe pour
identifier ces différentes responsabilités. Ensuite, des exemples concrets ont été donnés pour
montrer comment réaliser le diagramme de collaboration inhérent à une opération donnée.
Evaluation
Expliquer les expressions suivantes du modèle GRASP :
• Responsabilités
• Opérations
• Post-conditions
Appliquer le modèle GRASP pour identifier les responsabilités d’une classe dénommée
« compte » d’un système de gestion de compte bancaire
Activité 4.4 - Conception des diagrammes de classe
Présentation
Lors de la création d’un diagramme de collaboration, nous enregistrons les méthodes

correspondant aux responsabilités assignées à une classe comme décrit dans la troisième
activité de cette unité. Ces classes avec les méthodes sont des classes du logiciel représentant
les classes conceptuelles des modèles conceptuels. Puis, en se fondant sur ces classes du
logiciel identifiées, les diagrammes de collaboration et le modèle conceptuel initial, nous
pouvons créer un diagramme de classes de conception qui illustre les informations suivantes
:Les classes, associations et attributs
• Les méthodes L’information sur le type des attributs

• La navigabilité
• Les dépendances
110
4.4.1 Les étapes de la réalisation d’un diagramme de classes de conception
Utilisez la stratégie suivante pour créer un diagramme de classes de conception :
i. Identifier toutes les classes qui participeront à l’interaction de l’objet en

analysant les collaborations
ii. Présenter les dans un diagramme de classes
iii. Copier les attributs à partir des concepts connexes dans le modèle conceptuel
iv. Ajouter des noms de méthodes en analysant les diagrammes d’interaction
v. Ajouter des informations de type aux attributs et aux méthodes
vi. Ajouter l’association nécessaire pour appuyer la visibilité de l’attribut requis
vii. Ajouter la flèche de navigabilité nécessaire aux associations pour indiquer le

sens de visibilité de l’attribut
viii. Ajouter les lignes de relation de dépendance pour indiquer la non-visibilité de

l’attribut
De plus :
Améliorer les attributs par l’ajout des types de données
Déterminer la visibilité, par exemple public (+), privé (-) qui sont important pour l’encapsulation
4.4.2 Ajouter des associations et la navigabilité
Chaque extrémité d’une association est appelée un rôle. Dans un diagramme de classes de
conception, le rôle peut être décoré avec une flèche de navigabilité. La navigabilité est une
propriété du rôle qui indique qu’il est possible de naviguer de façon unidirectionnelle à travers
l’association des objets de la classe source vers la classe cible.
Figure 4.22 : Une partie du diagramme de classes de conception illustrant la navigabilité
La navigabilité est généralement interprétée comme la visibilité des attributs à partir de la

classe source vers la classe cible. Au cours de la mise en œuvre dans un langage POO, il
est habituellement traduit comme la classe source ayant un attribut qui fait référence à une
instance de la classe cible. Par exemple, la classe Terminal définira un attribut qui fait référence
à une instance de Vente.
111
4.4.3 Le diagramme de classes de conception avec les associations et la navigabilité
Le diagramme de classes de conception sera comme illustré à la Figure 4.23
Figure 4.23 : Schéma de conception avec association et navigabilité
Conclusion
Cette activité a mis l’accent sur l’étape ultime de la phase de la conception d’un système, celui
de la réalisation d’un diagramme de classes de conception. Vous avez étudié les différentes
actions à mener pour mettre en place ce diagramme. Vous avez également compris l’utilité des
associations et de la navigabilité entre deux classes.
Evaluation
1. Discuter de la relation entre le modèle conceptuel et le modèle de classes de

conception en termes de leurs classes et associations. Quelles sont les possibilités
d’associer deux classes dans un diagramme de classes de conception ?
2. À partir des études de cas individuellement ou en groupe, procédez de la manière suivante :
3. Créer des diagrammes de séquence objet pour les quatre opérations sélectionnées
au cours de l’analyse orientée objet
4. Créer le diagramme de collaboration pour les quatre opérations utilisées en

question (a) ci-dessus. Avec l’aide du modèle GRASP d’assignation de responsabilité,
identifier les méthodes de chaque classe. (comparer avec les diagrammes de
séquence objet connexe. Remarquez qu’à ce stade aucun des deux ne peut être
utilisé pour motif de commodité)
En utilisant certains des renseignements contenus dans les diagrammes de classes conceptuels,
décrire les attributs et les opérations des classes du logiciel. Indiquer les types des attributs et
opérations de la classe ainsi que leur visibilité
112
Présenter vos classes du logiciel dans un diagramme de classes de conception et indiquer la

navigabilité sur les associations de classe.
Activité 4.5 - Mise en œuvre / traduction des dessins dans les langages

de programmation orientée objet
Présentation
Les artefacts UML créés pendant la phase de conception qui sont les diagrammes

d’interaction et de séquence seront utilisés comme entrée pour le processus de génération
de code. La mise en œuvre consiste écrire le code source, définir éventuellement une base de
données JSP/XML, etc.
Les attributs
Les attributs deviennent des variables en Java et en C#. Leur type est soit un type primitif (int ,
etc.), soit une classe fournie par la plate-forme (String, Date, etc.).
La visibilité des attributs est montrée en les faisant précéder par (+) pour public, (#) pour
protégé (protected), (-) pour privé (private). Les attributs de classe en UML deviennent des
membres statiques en Java ou en C#.
Figure 4.17 : Exemple de traduction d’attribut
Les opérations
Les opérations deviennent des méthodes en Java et en C#. Leur visibilité est définie avec
les mêmes conventions que les attributs. Les opérations de classe deviennent des méthodes
statiques
113
Figure 4.18 : Exemple de traduction d’opération
Les relations
Les relations aussi doivent être traduites convenablement.
Généralisation
Figure 4.19 : Exemple de traduction d’une relation de généralisation
114
Association bidirectionnelle
Figure 4.20 : Exemple de traduction d’une relation bidirectionnelle
Association réflexive
Figure 4.20: Exemple de traduction d’une association réflexive
Agrégation et Composition
Figure 4.21 : Exemple de traduction d’une association d’agrégation ou de composition
115
Classe-association
Figure 4.19 : Exemple de traduction d’une classe-association
Les cardinalités
Figure 4.19 : Exemple de traduction des cardinalités
Conclusion
Cette dernière activité vous a fait voir quelques exemples de critères (type de relations,
attributs, cardinalité, etc…) dont il faut tenir compte lors de la traduction d’un diagramme en
programme. Vous êtes appelé à lire le lien ci-après pour plus d’information sur le sujet abordé
dans cette activité. https://fr.scribd.com/doc/301165196/modelisationobjetavecuml-pdf (Pages
395 à 404)
116
Evaluation
1. Considérez le diagramme de classe relatif à notre exemple d’étude de cas de

terminal de point de vente.
2. Définir une classe Java pour la classe CatalogueProduit
3. Définir une classe Java pour la classe Magasin.
4. Définir une classe Java pour la classe Vente
Résumé
Dans cette unité, le modèle GRASP a été exploré menant à une conception orientée objet
plus compréhensible, modifiable et robuste. L’analyse et la conception orientée objet est
une approche basée sur un modèle dans le processus de développement logiciel. En ayant
le diagramme de classes de conception en place, le langage d’implémentation peut être
appliqué pour implémenter le diagramme de classes de conception en code. Toutefois, le
module opte pour montrer comment le diagramme de classes de conception peut être mappé
avec un langage de programmation orienté-objet typique. Les langages Java et C# sont
utilisés, mais tout langage de programmation orienté objet peut être utilisé, comme C++.
Évaluation L’unité
1. Expliquer la différence entre le couplage et la cohésion dans la conception

d’applications, y compris l’explication de la raison pour laquelle chacun
est important. Donner un exemple de la façon dont chacune de ces
notions auraient une incidence sur la conception du programme.
2. En vous référant à l’approche orientée objet dans l’analyse et la conception

du système, décrire les éléments suivants :
• Deux types généraux de responsabilités quand on utiliser des modèles

• Le terme “ responsabilité “
• Le modèle “Contrôleur”
3. Faire la distinction entre un diagramme de séquence du système et un
diagramme de séquence objet
4. Expliquer clairement pourquoi les modèles sont nécessaires lors de

l’utilisation de l’approche d’analyse et de conception orientées objet dans
le développement logiciel ?
117
Résumé du module
Dans ce cours d’Analyse et Conception orientée objet, l’accent a été mis sur les principes de
l’Orienté-objet et leur utilité. Ensuite, nous avons introduit la notation UML qui est le langage
de modélisation le plus utilisé de nos jours à travers le monde et motivé son choix. Sa syntaxe
et ses principaux diagrammes ont été étudiés de long en large. Par la suite, les différentes
étapes des deux principales phases de la modélisation, à savoir l’analyse et la conception ont
été décrites à travers les différents diagrammes importants à mettre en place durant chacune
de ces phases. De nombreux exemples ont été donnés, chaque fois que cela est nécessaire
pour soutenir les concepts abordés. Enfin, des exemples montrant le passage des diagrammes
au code ont été exposés.
Evaluation du cours
Consigne
Soyez succinct, clair et précis. La durée de cet examen est 2h30mn
Examen de mi-parcours
Exercice 1: (Questions de cours, 6 points)

Citez 4 facteurs de qualité d’un logiciel et définissez-les.
Citez les principales activités de développement d’un logiciel.
A quoi sert le cahier des charges ? Qui le définit ?
Quel est le paradoxe de la gestion de projet ? Comment le gérer ?
Quelle est la différence entre navigabilité et sens de lecture d’une association ?
Quelle est la différence entre une association de composition et une agrégation faible ?
Donnez deux exemples pour illustrer chaque concept.
Exercice 2: Diagrammes de cas d’utilisation et de classes (8 points)

Modélisez à l’aide d’un diagramme de cas d’utilisation une médiathèque dont le
fonctionnement est décrit ci-après.
Une petite médiathèque n’a qu’une seule employée qui assume toutes les tâches :
la gestion des œuvres de la médiathèque ;
la gestion des adhérents.
Le prêt d’un exemplaire d’une œuvre donnée est limité à trois semaines. Si l’exemplaire n’est
pas rapporté dans ce délai, cela génère un contentieux. Si l’exemplaire n’est toujours pas
rendu au bout d’un an, une procédure judiciaire est déclenchée.
118
Pour gérer un prêt, l’employé doit rechercher l’adhérent dans le système et rechercher
également l’œuvre. S’il reste des exemplaires de l’œuvre, l’un de ces exemplaires est extrait
puis attribué à l’adhérent. L’accès au système informatique est protégé par un mot de passe.
Proposer le diagramme de classes permettant de modéliser la structure interne de la

médiathèque. Ajouter les opérations (traitements) qu’il faut, aux différentes classes afin que le
prêt d’une œuvre à un adhérent soit effectif.
Un hôtel est composé d’au moins deux chambres. Chaque chambre dispose d’une salle
d’eau qui peut être une douche ou une salle de bain. L’hôtel héberge des personnes. Il
peut employer du personnel et est dirigé par un des employés. L’hôtel a les caractéristiques
suivantes : une adresse, le nombre de pièces, la catégorie. Une chambre est caractérisée par le
nombre et le type de lits, le prix et le numéro. On peut calculer le chiffre d’affaires, le loyer en
fonction des occupants.
Donnez le diagramme de classes.
Utilisez les contraintes pour affiner les relations.
Exercice 3: Diagramme d’activité (Recette de cuisine, 3 points)

On désire modéliser une recette de cuisine simple à l’aide d’un diagramme d’activité
La recette est la suivante :
• Commencer par casser le chocolat en morceaux, puis le faire fondre.

• En parallèle, casser les œufs en séparant les blancs des jaunes.
• Quand le chocolat est fondu, ajouter les jaunes d’œuf.
• Battre les blancs en neige jusqu’à ce qu’ils soient bien fermes.
• Les incorporer délicatement à la préparation chocolat sans les briser.
• Verser dans des ramequins individuels.
• Mettre au frais au moins 3 heures au réfrigérateur avant de servir.
• Construire le diagramme d’activité correspondant à ce système.
Exercice 4: Diagramme d’états-transitions (Porte de garage motorisée à

enroulement, 3 points)
Considérons une porte de garage motorisée à enroulement. L’utilisateur dispose d’une
Télécommande comportant un bouton unique permettant d’actionner cette porte. Une
pression sur le bouton a pour effet :
– d’ouvrir la porte si celle-ci est fermée ;
– de la fermer si elle est ouverte ;
– de demander son ouverture si elle est en cours de fermeture ;
– de demander sa fermeture si elle est en cours d’ouverture.
119
La porte dispose en outre d’un capteur de butée qui indique que la porte a atteint sa butée
haute (porte ouverte) ou basse (porte fermée). On suppose que la porte est initialement
fermée.
Décrire le comportement de la porte de garage à l’aide d’un diagramme d’états-transitions.
Examen final
Consigne
Soyez succinct, clair et précis. La durée de cet examen est 2h30mn
Exercice
Une grande école universitaire veut mettre en place un système d’inscription simplifié qui
permettra de:
S’authentifier
Faire une demande d’admission
Choisir une filière
Obtenir les horaires d’un cours
Consulter la liste des étudiants
Consulter le dossier des étudiants
Gérer les étudiants
Enregistrer les notes des étudiants
Donner les résultats des étudiants à la fin du semestre
Question 1: (10 points)
Identifier les acteurs de ce système et décrire de façon détaillée leurs rôles
Identifier les CU
Construire le diagramme de CU
Faire une description détaillée de 4 CU au choix.
Question 2: Réaliser les diagrammes suivants (10 points)
Diagramme de classes
Identifier les entités
Ajouter les associations
Ajouter les attributs
Diagrammes de séquences
120
Choisissez 4 CU parmi les CU et dessinez les diagrammes de séquences correspondants
Diagrammes d’états-transitions
Dessiner un diagramme d’état qui présente les différents états d’un dossier étudiant
Diagramme d’activité
Proposer un diagramme d’activité pour l’introduction des notes d’étudiant par le professeur
Unité Lectures et Autres ressources

Liu Z., (2001), “Object-Otiented Software DevelopmentUsing UML”, The United Nations
Ojo A. and Estevez El., (2005), “Object-OrientedAnalysis and Design with UML”, Training
Larman C. (2004), “Applying UML and Patterns: An Introduction to Object-OrientedAnalysis

and Design and IterativeDevelopment”, (3rd Edition) 3rd Edition, Prentice Hall; 3 edition
(October 30, 2004), ISBN-13: 978-0131489066
121
122
Siège de l’Université Virtuelle Africaine
The African Virtual University

Headquarters
Cape Office Park
Ring Road Kilimani
PO Box 25405-00603
Nairobi, Kenya
Tel: +254 20 25283333
contact@avu.org
oer@avu.org
Bureau Régional de l’Université

Virtuelle Africaine à Dakar
Université Virtuelle Africaine
Bureau Régional de l’Afrique de l’Ouest
Sicap Liberté VI Extension
Villa No.8 VDN
B.P. 50609 Dakar, Sénégal
Tel: +221 338670324
bureauregional@avu.org
2017 UVA

Conception

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception

Transféré par

Droits d'auteur :

Formats disponibles

INFORMATIQUE APPLIQUÉE: CSI 3204

Ce module a été développé dans le cadre d’un programme de diplôme et diplôme en

Au nom de l’Université Virtuelle Africaine et notre patron, nos institutions partenaires,

L’Université Virtuelle Africaine (UVA) est une organisation intergouvernementale

Université Virtuelle Africaine

UVA – Coordination Académique

Dr. Marilena Cabral

Coordinateur global Sciences Informatiques Apliquées

Prof Tim Mwololo Waema

Barry Savala Mercy Tabi Ojwang

Edwin Kiprono Josiah Mutsogu

Kelvin Muriithi Kefa Murimi

Victor Oluoch Otieno Gerisson Mulongo

Projet Multinational II de l’UVA financé par la Banque africaine de développement.

Bienvenue à l’analyse et la Conception Orientées-Objets. . . . . . . . . . . . . . 7

Lectures et autres ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Unité 0. Évaluation Diagnostique 13

Partie II Projet de développement. . . . . . . . . . . . . . . . . . . . . . . . . 14

Lectures et autres ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Unité 1. - Principes de La Programmation Orientée-Objet 18

Activité 1.1 Principes de l’orienté-objet 19

Activité 1.2 – Concepts de la POO 22

Activité 1.3 - Associations et liens 26

Détails de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Lectures et autres ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Unité 2: Principes de Base en UML 33

Activité 2.1 –Utilisation du langage UML dans l’Analyse et la

Conception orientée objet 34

Activité 2.2- Diagrammes UML 39

Activité 2.3- Modèle UML 52

Lectures et autres ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Unité 3: Analyse Orientée-Objet 56

Activité 3.1 - Comprendre les exigences 57

Caractéristiques des exigences 62

Activité 3.2 - Cas d’utilisation 64

Activité 3.3 - Modèle conceptuel 77

Activité 3.4 – Comportement du système: diagrammes de

séquence et des opérations système 86

Définition des terminologies : 86

Lectures et autres ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Unité 4 : Conception Orientée Objet et Traduction Dans un Langage 92

Activité 1.1 - Les diagrammes interactifs 93

Activité 4.2 - Aperçu sur la phase de conception 99

Activité 4.3 - La conception du système Terminal de point de vente 106

Détails de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Activité 4.4 - Conception des diagrammes de classe 110

Détails de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Activité 4.5 - Mise en œuvre / traduction des dessins dans

les langages de programmation orientée objet 113

Détails de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Résumé du module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Evaluation du cours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Exercice 1: (Questions de cours, 6 points) 118

Exercice 2: Diagrammes de cas d’utilisation et de classes (8 points) 118

Exercice 3: Diagramme d’activité (Recette de cuisine, 3 points) 119

Exercice 4: Diagramme d’états-transitions (Porte de garage

motorisée à enroulement, 3 points) 119

Examen final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Unité Lectures et Autres ressources. . . . . . . . . . . . . . . . . . . . . . . . 121

● Ordinateur et une connexion Internet

Développer la documentation d’appui pour les exigences, l’analyse, et les phases

Créer les diagrammes UML selon différents contexte.

Démontrer l’importance des techniques d’analyse et de conception dans le développement de

Unité 0: Évaluation diagnostique