L’analyse et la Conception Orientées-Objets

(1)

L’analyse et La Conception Orientées-Objets

Dr. Pélagie HOUNGUE

(COUVERCLE PLACE)

INFORMATIQUE APPLIQUÉE: CSI 3204

L’ANALYSE ET LA CONCEPTION

ORIENTEES-OBJETS

Dr. Pélagie HOUNGUE

(2)

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

(3)

Crédits de production

Auteur

Dr. Pélagie HOUNGUE

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

(4)

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.

(5)

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

Lectures et autres ressources 17

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

Termes clés 18

Activités d’apprentissage 19

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

(6)

Evaluation 21

Activité 1.2 – Concepts de la POO 22

Détails de l’activité 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 Détails de l’activité 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

(7)

Termes clés 56

Activité 3.1 - Comprendre les exigences 57 Détails de l’activité 57

Caractéristiques des exigences 62 Evaluation 63 Activité 3.2 - Cas d’utilisation 64 Détails de l’activité 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étails de l’activité 86

Définition des terminologies : 86 Conclusion 89 Evaluation 89 Lectures et autres ressources 91

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

Termes clés 92

Activité 1.1 - Les diagrammes interactifs 93 Détails de l’activité 93

Evaluation 98

(8)

Conclusion 105

Evaluation 105

Activité 4.3 - La conception du système Terminal de point de vente 106 Détails de l’activité 106

Conclusion 110

Evaluation 110

Activité 4.4 - Conception des diagrammes de classe 110 Détails de l’activité 111

Conclusion 112

Evaluation 112

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

les langages de programmation orientée objet 113 Détails de l’activité 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

(9)

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.

(10)

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-

ves 40 %

(11)

Plan

Unité Sujets et Activités Durée estimée

Unité 0 : Eval- uation diag- nostique

Connaissances de base

^{5 Heures}

Unité 1 : Principes de la program- mation ori- entée-objet

Activité 1.1– Principes de l’orienté-ob- jet

Activité 1.2 – Concepts de la POO Activité 1.3–Associations et liens

25 Heures

Unité 2 : Prin- cipes de base en UML

Activité 2.1–Utilisation du langage UML dans l’Analyse et la Conception orientée objet

Activité 2.2– Diagrammes UML Activité 2.3–Modèles UML

30 Heures

Unité 3 : Analyse ori- entée-objet

Activité 3.1 – Comprendre les exi- gences

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

30 Heures

Unité 4 : Conception orientée-objet et traduction dans un lan- gage

Activité 1.1 – Les diagrammes inter- actifs

Activité 4.2 – Aperçu sur la phase de conception

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

24 Heures

(12)

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.

Lectures et autres ressources optionnelles:

Sommerville Ian (2000), “Software Engineering (6th Edition)”. Addison-Wesley, Boston USA

(13)

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

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

Liu Z., (2001), “Object-Otiented Software Development Using UML”, The United Nations University, UNU-IIST International Institute for Software Technology, Tech Report 229.

(14)

Pressman Roger S., (2001), “Software Engineering, A Practitioner’ S Approach” Fifth Edition, McGraw-Hill Higher Education, ISBN 0073655783

Unité 4

Ojo A. and Estevez El., (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.

Pressman Roger S., (2001), “Software Engineering, A Practitioner’ S Approach” Fifth Edition, McGraw-Hill Higher Education, ISBN 0073655783

(15)

Unité 0. Évaluation Diagnostique

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

(16)

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

(17)

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

(18)

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.

(19)

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.

Lectures et autres ressources

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/

(20)

Unité 1. - Principes de La

Programmation Orientée-Objet

Introduction à l’unité

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é.

Objectifs de l’unité

À 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.

(21)

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.

(22)

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

(23)

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.

(24)

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.

Détails de l’activité

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.

(25)

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

(26)

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.

(27)

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

(28)

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

(29)

Détails de l’activité

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

(30)

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

(31)

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) superclasse(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

(32)

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

(33)

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.

(34)

É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?

Lectures et autres ressources

• 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

(35)

Unité 2: Principes de Base en UML

Unité 2: Principes de Base en UML

Introduction à l’unité

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.

Objectifs de l’unité

À 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.

(36)

Activités d’apprentissage

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.

Détails de l’activité

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).

(37)

Unité 2: Principes de Base en UML

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

(38)

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