Modélisation et conception orientées objet avec UML Ilhem Boussaïd [email protected] Université des Sciences et de la Technologie Houari Boumediene Licence 3 Académique http://sites.google.com/site/ilhemboussaid 18 novembre 2013 I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 1 / 101 Introduction Plan 1 Introduction Qualité d’une conception Démarche fonctionnelle Démarche orientée objet 2 Diagramme de classes Classes et instances Relations entre classes Compléments sur la modélisation des classes 3 Diagramme de packages 4 Références I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 2 / 101 Introduction De la spécification à la conception Spécifier → c’est définir le quoi. Concevoir → c’est définir le comment. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 3 / 101 Introduction Principes de conception La décomposition en sous-problèmes Il s’agit de : Décorréler les problèmes pour n’en traiter qu’un seul à la fois. Simplifier les problèmes (temporairement) pour aborder leur complexité progressivement. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 4 / 101 Introduction Principes de conception La modularité C’est une instance cruciale du principe de décomposition des problèmes. Il s’agit de partitionner le logiciel en modules qui : ont une cohérence interne (des invariants) ; possèdent une interface ne divulguant sur le contenu du module que ce qui est strictement nécessaire aux modules clients. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 5 / 101 Introduction Critères d’évaluation pour la conception On mesure la cohésion ("cohesion") d’un module aux nombres de ses sous-modules qui effectuent des tâches similaires et ont des interactions continues. On mesure l’interdépendance ("coupling") entre deux modules A et B à la quantité de modifications à faire sur B lorsque A est modifié (et réciproquement). Haute cohésion, basse interdépendance ("High cohesion, low coupling") I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 6 / 101 Introduction Qualité d’une conception Qualité d’une conception La composante la plus importante de la qualité d’une conception est la maintenabilité. maximiser la cohésion à l’intérieur des composants minimiser le couplage entre ces composants Les dégradations de la conception sont liées aux modifications des spécifications, Ces modifications sont à faire vite et par d’autres que les concepteurs originaux ça marche mais sans respect de la conception initiale corruption de la conception (avec effet amplifié au fur et à mesure) I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 7 / 101 Introduction Qualité d’une conception Couplage/Cohésion A RETENIR ABSOLUMENT Pour qu’un logiciel soit extensible et réutilisable, il faut qu’il soit découpé en modules faiblement couplés et à forte cohésion. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 8 / 101 Introduction Qualité d’une conception Couplage Couplage Une entité (fonction, module, classe, package, composant) est couplée à une autre si elle dépend d’elle. Couplage faible Désigne une relation faible entre plusieurs entités (classes, composants), permettant une grande souplesse de programmation, de mise à jour. Ainsi, chaque entité peut être modifiée en limitant l’impact du changement au reste de l’application. Couplage fort au contraire, tisse un lien puissant qui rend l’application plus rigide à toute modification de code. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 9 / 101 Introduction Qualité d’une conception Couplage fort Couplage Fort Mesurez l’impact d’une modification de ces modules Module 1 Module 2 Module 4 I. BOUSSAID (USTHB) Module 3 Module 6 Module 5 GL - COO 18 novembre 2013 10 / 101 Introduction Qualité d’une conception Couplage faible Couplage Faible Module 1 Module 2 Module 4 I. BOUSSAID (USTHB) Mesurez l’impact de modification d’un des modules Module 3 Module 6 Module 5 GL - COO 18 novembre 2013 11 / 101 Introduction Qualité d’une conception Forte cohésion Cohésion entre modules dans un composant, entre services dans un module :"qui se ressemble s’assemble " L’idée est de vérifier que nous rassemblons bien dans une classe des méthodes cohérentes, qui visent à réaliser des objectifs similaires. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 12 / 101 Introduction Qualité d’une conception Conception : Approche Fonctionnelle vs. Objet Comment décomposer ? Deux approches : Fonctionnelle → Descendante. Objet → Ascendante I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 13 / 101 Introduction Démarche fonctionnelle Modélisation par décomposition fonctionnelle descendante La forme la plus immédiate pour décrire un travail à effectuer est de lister les actions à réaliser. On découpe une tâche complexe à effectuer en une hiérarchie d’actions à réaliser de plus en plus simples, petites et précises (Pour décrire, on utilise le verbe) : I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 14 / 101 Introduction Démarche fonctionnelle Modélisation par décomposition fonctionnelle descendante Exemple : 1 Rouler En Voiture : 1 Mettre moteur en marche : 1 2 2 Démarrer Voiture : 1 2 3 3 Mettre Contact Démarrer Moteur Mettre Point Mort Passer La Première Embrayer En Accélérant Rouler : 1 2 3 Accélérer Freiner Passer Vitesse I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 15 / 101 Introduction Démarche fonctionnelle Modélisation par décomposition fonctionnelle Découpe fonctionnelle descendante 2/9 descendante Rouler en voiture Mettre moteur en marche Mettre contact Démarrer moteur Introduire Clé de contact Tourner clé de contact en position « Démarreur » et la laisser revenir Tourner le clé en position contact Démarrer Point mort Passer la 1ere Rouler Embrayer en accélérant Levier de vitesse sur position 1 Accélérer Suivant pression pédale de droite Augmenter le débit d’essence dans le carburateur I. BOUSSAID (USTHB) ESISAR GENIE LOGICIEL ORIENTE OBJET GL -– COO Freiner Passer vitesse Suivant pression pédale du milieu Augmenter la pression sur les freins 18 novembre 2013 16 /7 101 Introduction Démarche fonctionnelle Découpe fonctionnelle desce Modélisation par décomposition fonctionnelle descendante L’implémentation en code source d’une sol en programmation procédurale): L’implémentation en code source d’une solution décrite en terme d’actions terme d’actions est un code organisé est un code organisé en fonctions (programmation procédurale) : roulerEnVoiture() mettreMoteurEnMarche() mettreContact() demarrerMoteur() demarrer() mettrePointMort() passerLaPremiere() embrayerEnAccelerant() rouler() accelerer() freiner() passerVitesse() I. BOUSSAID (USTHB) ESISAR GL - COO GENIE LOGICIEL – ORIENTE OBJET 18 novembre 2013 17 / 101 Introduction Démarche fonctionnelle Modélisation par décomposition fonctionnelle descendante Dans ce cadre de travail : L’analyse est une découpe fonctionnelle descendante des fonctionnalités à pourvoir. La conception est une découpe du logiciel en une hiérarchie descendante d’actions permettant de satisfaire les fonctionnalités à pourvoir. L’implémentation est une programmation procédurale. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 18 / 101 Introduction Démarche fonctionnelle Modélisation par décomposition fonctionnelle descendante Découpe fonctionnelle descendante 5/9 Dans une programmation procédurale issue d’unedécoupe découpe fonctionnelle Dans une programmation procédurale issue d’une fonctionnelle descendante, les données et les fonctions descendante, les données les fonctions travaillant données travaillant sur ceset données sont dispersées danssur desces modules sont dispersées dans des modules différents. différents. type typeVitesse est {pointMort, premiere, seconde, troisieme, quatrieme cinquieme, marcheArriere}; vitesseCourante : typeVitesse := pointMort; procedure passerVitesse( vitesseCourante : in out typeVitesse; vitesseAPasser : in typeVitesse); procedure mettreAuPointMort( vitesseCourante : in out typeVitesse); ESISAR I. BOUSSAID (USTHB) GENIE LOGICIEL – ORIENTE OBJET E.CHENU GL - COO 10 18 novembre 2013 19 / 101 Introduction Démarche fonctionnelle Modélisation par décomposition fonctionnelle descendante Dispersion données/fonctions : Lorsque le logiciel évolue, il faut faire évoluer les structures de données et les fonctions en parallèle (probablement dans des modules différents). Maintenir cette cohérence est laborieuse parce que données et fonctions sont dispersées. La dispersion données/fonctions nuit à l’extensibilité ! I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 20 / 101 Introduction Démarche fonctionnelle Modélisation par décomposition fonctionnelle descendante Rappelez vous ! Pour qu’un logiciel soit extensible et réutilisable, il faut qu’il soit découpé en modules faiblement couplés, ainsi chaque entité peut être modifiée en limitant l’impact du changement au reste de l’application. et à forte cohésion. Il faut réunir ce qui est impacté par une même modification (« qui se ressemble s’assemble ») I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 21 / 101 Introduction Démarche fonctionnelle Modélisation par décomposition fonctionnelle descendante Comment évaluer la découpe fonctionnelle descendante et la programmation procédurale en termes de couplage et cohésion ? Séparer données et fonctions sur ces données entraine : Un fort couplage par les données, Perte de cohésion (par dispersion). Le code est donc peu extensible et peu réutilisable ! I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 22 / 101 Introduction Démarche fonctionnelle Fonctionnel versus Objet 2.2 QU’APPORTE LA MODELISATION OBJET – – Plus grande indépendance du modèle par rapport aux fonctionnalités demandées. ÆDes fonctionnalités peuvent être rajoutées ou modifiées, le modèle objet ne change pas. Plus proche du monde réel. LA DEMARCHE FONCTIONNELLE Accent mis sur ce que fait le système (ses fonctions) LA DEMARCHE OBJET Accent mis sur ce qu'est le système (ses composants) : les objets 5 I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 23 / 101 Introduction Démarche orientée objet Démarche orientée objet On ne raisonne plus en termes d’actions mais plutôt en concepts du monde physique. Puisqu’ils appartiennent au monde physique, ces concepts peuvent être stables et réutilisables. U M G L 1 NIVERSITE ENTOURI ENIE OGICIEL FACULTE DES SCIENCES DE L’INGENIEUR DEPARTEMENT D’INFORMATIQUE ANNEE UNIVERSITAIRE 2007-2008 ILHEM BOUSSAID On ne raisonne uniquement en verbes, mais davantage en noms. 2.2 ENCAPSULATION I. BOUSSAID On (USTHB) COO et les comportements (qui 18 novembre dit que les informations (qui sont GL des -données) sont les 2013 24 / 101 Introduction Démarche orientée objet Pourquoi une structuration orientée objet ? Unicité et universalité du paradigme Réduire le décalage entre monde réel et logiciel Objets réels → Objets conceptuels → Objets logiciels Réutilisabilité et évolutivité facilitées par différents mécanismes Encapsulation, Modularité, Abstraction, Polymorphisme, Héritage Faible couplage inter-objets / Forte cohésion intra-objet Paradigme qui arrive à maturité Bibliothèques de classes, Design patterns, UML, Méthodologies de développement (USDP, Agile, XP, ...), ... Environnements de développement intégrés (IDE) I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 25 / 101 Diagramme de classes Plan 1 Introduction Qualité d’une conception Démarche fonctionnelle Démarche orientée objet 2 Diagramme de classes Classes et instances Relations entre classes Compléments sur la modélisation des classes 3 Diagramme de packages 4 Références I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 26 / 101 Diagramme de classes Objectif Les diagrammes de cas d’utilisation modélisent à QUOI sert le système. Le système est composé d’objets qui interagissent entre eux et avec les acteurs pour réaliser ces cas d’utilisation. Les diagrammes de classes permettent de spécifier la structure statique d’un système, en termes de classes et de relations entre ces classes. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 27 / 101 Diagramme de classes Classes et instances Objets Objet Identité + Etat + Comportement Une identité deux objets différents ont des identités différentes on peut désigner l’objet (y faire référence) Un état (attributs) ensemble de propriétés/caractéristiques définies par des valeurs permet de le personnaliser/distinguer des autres objets peut évoluer dans le temps Un comportement (méthodes) ensemble des traitements que peut accomplir un objet (ou que l’on peut lui faire accomplir) I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 28 / 101 Diagramme de classes Classes et instances Objets Objet : Entité concrète ou abstraite du domaine d’application. Décrit par état (attributs) + comportement (opérations) I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 29 / 101 Diagramme de classes Classes et instances Objets - Exemple Objet (2) y Quelques exemples: 9 Objet États Comportements Chien Nom, race, âge, couleur Aboyer, chercher le baton, mordre, faire le beau Compte N°, type, solde, ligne de crédit Retrait, virement, dépôt, consultation du solde Téléphone N°, marque, sonnerie, répertoire, opérateur Appeler, Prendre un appel, Envoyer SMS, Charger Voiture Tourner, accélérer, s’arrêter, ffaire i lle plein, l i kl klaxonner Plaque, marque, couleur, vitesse USTHB - Master IL 2009-2010 I. BOUSSAID (USTHB) - GL Ilhem BOUSSAID - COO 18 novembre 2013 30 / 101 Diagramme de classes Classes et instances Classes et instances I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 31 / 101 Diagramme de classes Classes et instances Classes et instances Les objets possédant la même structure de données (attributs) et le même comportement (opérations) sont les représentants d’une même classe. Une classe est une abstraction qui décrit les propriétés pertinentes pour une application. Données et opérations traitant les données ne sont pas séparées, mais réunies au sein d’un même module. Cohésion ! Chaque objet est une instance d’une classe. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 32 / 101 Diagramme de classes Classes et instances Classes et instances Classe : Regroupement d’objets de même nature (mêmes attributs + mêmes opérations) I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 33 / 101 Diagramme de classes Classes et instances Classes et instances Classes et instances (2) Layclasse « chien » définit : Quelques exemples LesLaattributs d’un» définit: chien (nom, race, couleur, âge, . . . ) y classe « chien Lesy comportements d’un chien chercher le bâton, mordre. . . ) Les attributs d’un chien (nom, race,(Aboyer, couleur, âge…) Les comportements d’un chien (Aboyer, chercher bâton, mordre…) de chien Il peut yexister dans le monde plusieurs objetsle(ou instances) y Il peut exister dans le monde plusieurs objets (ou instances) de chien Classe Instances (Objets) Chien Mon chien: Bill, Teckel, Brun, 1 an Le chien de mon voisin: Hector, Labrador, Noir, 3 ans Compte Mon compte à vue: N° 210-1234567-89, Courant, 1.734 DZ, 12.500DZ Mon compte épargne: N° 083-9876543-21, Epargne, 27.000 DZ, 0DZ Voiture Ma voiture: ABC-123, VW Polo, grise, 0 km/h La voiture que je viens de croiser: ZYX-987, Porsche, noire, 170 km/h 11 USTHB - Master IL 2009-2010 - Ilhem BOUSSAID I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 34 / 101 Démarche de conception OO Diagramme conceptionde OOclasses implémentation, etc.) Classes et instances conception OO Figure 7.10 - Features diagram of the Kernel package Représentation d’une classe 75 76 76 rectangle composé de compartiments Compartiment 1 : Nom de la classe (commence par une majuscule, en Méthode de Méthode de gras) Conception Conception Orientée Objet ramme de classes Diagramme de classes Orientée Objet Compartiment 2 : Attributs Diagramme de classes A. Lewandowski Classe Attributs et A. Lewandowski A. Opérations Lewandowski Compartiment 3 : Opérations Classe Méthode de Conception Orientée Objet d’ajouter des compartiments (exceptions, ...) tions etPossibilité méthodes Résumé Représentation des attributs : on est une fonction ou une procédure UML Superstructure Specification, v2.1.1 qui peut uée aux objets ou par les d!une classe. Introduction Uneobjets classe 30 UML Superstructure Specification, v2.1.1 Représentation Introduction Introduction pération peut s!appliquer à de nombreuses d’une Conceptsclasse de base initiale { visibilité nom : type = valeur nts Une[multiplicité] classe Attribut 1 érentes. Dans ce cas, on dit qu!elle est Diagrammes UML Concepts de base Concepts de base Attribut 2 • rectangle à 3 Introduction compartiments eule) . Attribut 1 à UML UML Opération Diagrammes UML deDiagrammes est l!implémentation d!une 1opération pour(singulier, Diagramme de cas Attribut 2 • nom d’utilisation majuscule) donnée. Opération 2 Introduction à UML Introduction à UML Diagramme de classes Opération 1 Diagramme de cas Diagramme de cas • attributs Diagramme de facultatif public + d’utilisation d’utilisation packages Opération 2 facultatif de classes Diagramme de classes privé • opérations Diagramme d’objets enDiagramme fonction des besoins par défaut: 1 Diagramme de Diagramme de Diagramme de protégé # communication packages packages [0..1] élément pouvant être nul Argument : Diagramme de Diagramme d’objets Diagramme d’objets • plus ou moins de détails en fonction des besoins séquence [4] tableau de 4 élémentsDiagramme de sensDeFlux nomArgument : type = valeurParDéfaut Diagramme de Diagramme d’activité Une classe communication communication [2..*] tableau dynamique sensDeFlux Diagramme d’états facultatif = in, out ou inout Diagramme de Diagramme de Autres diagrammes d'au moins 2 éléments séquence séquence mais impératif Diagramme d’activité Diagramme d’activité Démarche de Une classe pour l'implémentation Diagramme d’états Diagramme d’états conception OO plus ou moins de détails en fonction des besoins : Possibilité d’omettre attributs et/ou opérations Autres diagrammes Une classe Autres diagrammes Démarche de conception OO I. BOUSSAID (USTHB) Démarche de conception OO GL - COO 18 novembre 2013 35 / 101 Diagramme de classes Classes et instances Représentation UML des attributs Représentation des attributs : Représentation d’un attribut : visibilité nom : type [multiplicité] = valeur initiale {p public + privé protégé # facultatif mais impératif pour l'implémentation I. BOUSSAID (USTHB) facultatif facultatif par défaut: 1 [0..1] élément pouvant être nul [4] tableau de 4 éléments [2..*] tableau dynamique d'au moins 2 éléments GL - COO 18 novembre 2013 36 / 101 Diagramme de classes Classes et instances Une opération une fonction ou une procédure qui Attributs etest Opérations être appliquée aux objets ou par les objets d!une clas LaReprésentation même opération peut d’une opération : s!appliquer à de nombreuse classes différentes. Dans ce cas, on dit qu!elle est Une opération représente un élément de comportement (un service) polymorphe . une classe. contenu dans ajouterons surtout les opérations en conception car cela po Une Nous méthode est l!implémentation d!uneobjet, opération fait partie donnée. des choix d’attribution des responsabilités aux objets. une classe I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 37 / 101 Diagramme de classes Classes et instances Représentation UML des opérations Format de description d’une opération : [Visibilité] Nom ["(" Arg ")"] [" :" Type] Visibilité : + (public), - (privé), # (protégé) Arg : liste des arguments selon le format [Dir] NomArgument : TypeArgument où Dir = in (par défaut), out, ou inout Type : type de la valeur retournée (type primitif ou classe) Opérations abstraites (non implémentées) en italique Opérations de classe (statiques) soulignées Possibilité d’annoter avec des contraintes stéréotypées «precondition» et «postcondition» ; Programmation par contrats Possibilité de surcharger une opération : même nom, mais paramètres différents Stéréotypes d’opérations : «create» et «destroy» I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 38 / 101 Diagramme de classes Relations entre classes Les associations Diagramme de classes Connexion sémantique bidirectionnelle entre classes Relations entre classes Représentation des associations : Nom : forme verbale, avec un sens de lecture Rôles : forme nominale, décrit une extrémité de l’association Multiplicité 1, 0..1, 0..∗, 1..∗, n..m Représentation des: associations I Classe 1 x..y nom association ▶ rôle 1 x..y rôle 2 {mots-clés} C Classe 2 D • Nom : forme verbale, avec un sens de lecture • Rôles : forme nominale, décrit une extrémité de l’association I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 39 / 101 Diagramme de classes Relations entre classes Les associations Représentation des associations I Classe 1 x..y nom association ▶ rôle 1 x..y rôle 2 {mots-clés} C Classe 2 D Interprétation en français : • Nom : forme verbale, avec un sens de lecture Un Classe1 nom association un Classe2 (ou un Classe2 nom association un Classe1 sens de lecture inverse) • Rôles : formesi nominale, décrit une extrémité de Un Classe1 est rôle1 d’un Classe2 et mult1 (x..y) Classe1 peuvent jouer l’association ce rôle pour un Classe2 • Multiplicité 1,rôle2 0..1,d’un 0..*, 1..*,etn..m Un Classe2 :est Classe1 mult2 (x..y) Classe2 peuvent jouer ce rôle pour un Classe1 D c • Mots clés : set, ordered set, list Exemple : I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 40 / 101 Diagramme de classes Relations entre classes Les associations Représentation des associations I Classe 1 x..y nom association ▶ rôle 1 x..y rôle 2 {mots-clés} C Classe 2 D en langage de programmation orienté objet • Interprétation Nom : forme verbale, avec un sens de lecture La classe Classe1 a un attribut de nom rôle2 • Rôles : forme décrit extrémité de sinon → Type = C2nominale, si mult2 ∈ {1, 0..1},une ou collection de Classe2 La classe Classe2 a un attribut de nom rôle1 l’association → Type = C1 si mult1 ∈ {1, 0..1}, ou collection de Classe1 sinon • Multiplicité : 1, 0..1, 0..*, 1..*, n..m Exemple : D c • Mots clés : set, ordered set, list I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 41 / 101 Diagramme de classes Relations entre classes Multiplicité des associations :07 14 La multiplicité spécifie le nombre d’instances d’une classe pouvant être liées à une seule instance d’une classe associée. Elle contraint le nombre d’objets liés. Exemple : une personne peut posséder plusieurs voitures (entre zéro et un nombre quelconque) ; une voiture est possédée par une seule personne. ation OSITION I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 42 / 101 Diagramme de classes Relations entre classes d’une association peut porter une indication de multiplicité qui Multiplicité des associations objets de la classe considérée peuvent être liés à un objet de multiplicité est une information portée par l’extrémité la forme d’une expression entière. 1 Un et un seul 0..1 Zéro ou un N N (entier naturel) M .. N De M à N (entiers naturels) * De zéro à plusieurs 0 .. * De zéro à plusieurs 1 .. * D'un à plusieurs rend compte du fait que plusieurs personnes travaillent pour I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 43 / 101 Diagramme de classes Relations entre classes Multiplicité des associations I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 44 / 101 Multiplicité Diagramme de classes Relations entre classes Multiplicité des associations ! La multiplicité spécifie le nombre d!instances d!une classe pouvant être liées à une seule instance d!une Exemple : classe associée. Elle contraint le nombre d!objets liés I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 45 / 101 Diagramme de classes Relations entre classes Multiplicité des associations Exemple : I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 46 / 101 Diagramme de classes Relations entre classes Association Reflexive Exemple de diagramme d’objets : I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 47 / 101 Diagramme de classes Relations entre classes Association multiple I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 48 / 101 Diagramme de classes Relations entre classes Relations entre classes Exemple récapitulatif Exemple Entreprise 0..* ◀ travaille pour employeur 1..* employé emploie ▶ Personne patron 0..1 * dirige ▼ employés Association réflexive I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 49 / 101 s Diagramme de classes Relations entre classes • Directionnalité des associations Navigabilité d’une association • bidirectionnelles par défaut • la navigation peut être restreinte à une seule Par défaut, les associations sont navigables dans les deux directions. direction la navigation peut être restreinte à une restreinte) seule direction : les instances (association à navigabilité d’une classe ne "connaissent" pas les instances d’une autre. Exemple On restreint la navigabilité d’une association à un seul sens à l’aide d’une flèche. Citoyen * vote pour ▶ 0..1 Candidat ces trois notations ont la même sémantique I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 50 / 101 Diagramme de classes Relations entre classes Navigabilité d’une association Qu’est-ce que la navigabilité d’une association entre C1 et C2 ? Capacité d’une instance de C1 (resp. C2) à accéder aux instances de C2 (resp. C1) Par défaut : Navigabilité dans les deux sens : C1 a un attribut de type C2 et C2 a un attribut de type C1 Spécification de la navigabilité : Orientation de l’association : C1 a un attribut du type de C2, mais pas l’inverse I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 51 / 101 Diagramme de classes Relations entre classes Classe d’Association Classe Attribuée Une classe association peut participer à d’autres associations : I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 52 / 101 Classe-association Diagramme de classes Relations entre classes Classe d’Association ! Une classe-association est une Une classe-association est une association qui une est aussi classe. une classe. association qui est aussi I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 53 / 101 Diagramme de classes Relations entre classes Classe d’Association Ne placez pas les attributs d’une association dans une classe. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 54 / 101 Diagramme de classes Relations entre classes Classe d’Association Exemple de diagramme d’objets : I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 55 / 101 Diagramme de classes Relations entre classes Classe d’Association Équivalences Parfois, l’information véhiculée par une classe-association peut être véhiculée sans perte d’une autre manière I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 56 / 101 Diagramme de classes Relations entre classes Association n-aire En général, les associations sont binaires N-aires : au moins trois instances impliquées Associations n-aires A n’utiliser que lorsqu’aucune autre solution n’est possible ! I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 57 / 101 Diagramme de classes Relations entre classes Association n-aire I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 58 / 101 Diagramme de classes Relations entre classes Association n-aire Un cours ne peut exister que s’il existe un lien entre un objet Enseignant et un objet Groupe. Quand le lien est rompu (effacé), le cours l’est également. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 59 / 101 Diagramme de classes Relations entre classes Si un cours doit pouvoir exister indépendamment d’un lien entre un enseignant et un groupe, il faut utiliser une association ternaire. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 60 / 101 Diagramme de classes Relations entre classes Dépendance Une classe A dépend d’une classe B (noté A - - - - - - - - > B) si : Il existe une association navigable de A vers B (ou A possède un attribut de type B) Une méthode de A a un paramètre ou une var. locale de type B I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 61 / 101 Diagramme de classes Relations entre classes Agrégation osite entraîne la destruction de tous ses éléments Une agrégation est un cas particulier d’association non symétrique cycleexprimant de vieunedes parties). relation de contenance d’un élément dans un ensemble. Les agrégations n’ont pas besoin d’être nommées : implicitement elles signifient « contient », « est composé de ». On représente l’agrégation par l’ajout d’un losange vide du côté de l’agrégat (l’ensemble). Agregat Element 1..* Composite I. BOUSSAID (USTHB) 0..* GL - COO Element 18 novembre 2013 62 / 101 Diagramme de classes Relations entre classes Agrégation - Exemples Une pièce est composée de murs. Un mur peut être commun à plusieurs pièces Agrégation ! L!agrégation est une forme d!association forte dans laquelle un objet agrégat est constitué de constituants agrégés. Elle est transitive et antisymétrique. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 63 / 101 u cycle de vie des parties). Diagramme de classes Relations entre classes composition Relation transitive et antisymétrique Une composition est une agrégation plus forte impliquant que : un élément ne peut appartenir qu’à un seul agrégat composite (agrégation non partagée) ; la destruction de l’agrégat composite (l’ensemble) entraîne la Agregat Element destruction de tous ses éléments (les parties) le composite est responsable du cycle de vie 0..* des parties. 1..* Composite Element 1 I. BOUSSAID (USTHB) 0..* GL - COO 18 novembre 2013 64 / 101 Diagramme de classes Relations entre classes Composition - Exemples Une partie constituante ne peut appartenir à plus d’un assemblage ; Composition une fois une partie constituante affectée à un assemblage, sa durée de vie coïncide avec ce dernier. ! Forme d!agrégation qui implique : ! ! qu!une partie constituante ne peut appartenir à plus d!un assemblage ; une fois une partie constituante affectée à un assemblage, sa durée de vie coïncide avec ce dernier. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 65 / 101 Diagramme de classes Relations entre classes Composition - Exemples Un mur est composé de briques. Une brique n’appartient qu’à un mur I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 66 / 101 Diagramme de classes Relations entre classes Agrégation vs. composition Quand mettre une composition plutôt qu’une agrégation ? Pour décider de mettre une composition plutôt qu’une agrégation, on doit se poser les questions suivantes : Est-ce que la destruction de l’objet composite (du tout) implique nécessairement la destruction des objets composants (les parties) ? C’est le cas si les composants n’ont pas d’autonomie vis-à-vis des composites. Lorsque l’on copie le composite, doit-on aussi copier les composants, ou est-ce qu’on peut les «réutiliser», auquel cas un composant peut faire partie de plusieurs composites ? Si on répond par l’affirmative à ces deux questions, on doit utiliser une composition. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 67 / 101 Diagramme de classes Relations entre classes Propagation (ou déclenchement) Application automatique d’une opération à un réseau d’objets à partir d’un objet initial quelconque. Propagation l’agrégation permet un mécanisme de délégation d’opérations : (ou déclenchement) l’opération Document.copier() peut être déléguée à l’opération Paragraphe.copier() en l’appliquant à toutes les instances de ! Application automatique d!une opération à unà son réseau paragraphe qui composent le document. Celle-ci peut tour être d!objets à partir d!un objet initial quelconque. déléguée dans les mêmes conditions à Caractère.copier(). I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 68 / 101 Diagramme de classes Relations entre classes Qualification Association Qualifiée : Un qualicatid d’association est une liste d’attributs dans une association binaire où les valeurs des attributs sélectionnent un ou plusieurs objets liés. Un qualificatif agit toujours sur une association dont la multiplicité est plusieurs I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 69 / 101 Diagramme de classes Relations entre classes Contraintes UML permet d’associer une contrainte à un élément de modèle de plusieurs façons. Sur les deux diagrammes suivants, la contrainte porte sur un attribut qui doit être positif. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 70 / 101 Diagramme de classes Relations entre classes Contraintes La contrainte frozen signifie que l’association, la classe ou l’attribut, une fois créé ne changera jamais (ici frozen précise que le nombre de roues d’un véhicule ne peut pas varier). La contrainte subset précise que le président est également un membre du comité. La contrainte xor (ou exclusif) précise que les employés de l’hôtel n’ont pas le droit de prendre une chambre dans ce même hôtel. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 71 / 101 Diagramme de classes Relations entre classes Contraintes I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 72 / 101 Diagramme de classes Relations entre classes Contraintes Le NAS d’un employé, une fois créé, ne peut changer Read only signifie que la valeur peut changer à l’intérieur de la classe mais ne peut être changée de l’extérieur de la classe (Le salaire, ne peut être modifié à l’extérieur de la classe Employe) I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 73 / 101 Relations entre classes Généralisation/Spécialisation Diagramme de classes Héritage (Généralisation/Spécialisation) L’héritage une relation de spécialisation/généralisation. tationLes: éléments spécialisés héritent de la structure et du comportement des éléments plus généraux (attributs et opérations) Classe B Super-classe: plus générale Sous-classe: plus spécialisée Classe A I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 74 / 101 Diagramme de classes Relations entre classes Héritage I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 75 / 101 Diagramme de classes Relations entre classes Héritage Pour que ça fonctionne : Principe de substitution : toutes les propriétés de la classe parent doivent être valables pour les classes enfant principe du « A est un B » ou « A est une sorte de B » : toutes les instances de la sous-classe sont aussi instances de la super-classe. Par exemple, toute opération acceptant un objet d’une classe Animal doit accepter tout objet de la classe Chat (l’inverse n’est pas toujours vrai). I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 76 / 101 Diagramme de classes Relations entre classes senter ? Héritage I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 77 / 101 Diagramme de classes Relations entre classes pécialisation Héritage • Extension cohérente de classes Relation transitive, non réflexive, et non symétrique ! elation non-réflexive, non-symétrique ! Classe A Classe A Impossible ! I. BOUSSAID (USTHB) Classe B GL - COO 18 novembre 2013 78 / 101 Diagramme de classes Relations entre classes Héritage - Exemple I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 79 / 101 Diagramme de classes Relations entre classes Héritage Multiple Une classe peut avoir plusieurs classes parents. On parle alors d’héritage multiple. Exemple : Le langage C++ est un des langages objet permettant son implantation effective. Java ne le permet pas. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 80 / 101 Diagramme de classes Diagramme de classes Héritage Multiple Relations entre classes Généralisation/Spécialisation Comment multiple Commentéviter éviter l’héritage l’héritage multiple ?? Première solution :solution déléguer: déléguer • Première Classe A Classe A Classe B Classe C I. BOUSSAID (USTHB) Classe B Classe C GL - COO 18 novembre 2013 81 / 101 i e L Diagramme de classes Relations entre classes Diagramme de classes Héritage Multiple Généralisation/Spécialisation Comment éviterl’héritage l’héritage multiple ?? Comment éviter multiple • Deuxième la importante classe la plus Deuxième solution : solution hériter de :lahériter classe lade plus et déléguer les autres importante et déléguer les autres L ses Classe A Classe A Classe B Classe B s té Classe C I. BOUSSAID (USTHB) Classe C GL - COO 18 novembre 2013 82 / 101 Diagramme de classes Relations entre classes Énumerations Enumération I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 83 / 101 Diagramme de classes objet élémentaire avec UML Classes Modélisation abstraites Classes abstraites Compléments sur la modélisation des classes Diagrammes de classes Une méthode est dite abstraite lorsqu’on connaît son entête Une méthode lorsqu'on sonréalisée. entête mais (signature) maisest pasdite la abstraite manière dont elle connaît peut être la manière dont elle peut être réalisée. pas Il appartient aux classes enfant de définir les methodes abstraites. Il appartient aux classes enfant de dénir les methodes abstraites. Une classe est dite abstraite lorsqu’elle définit au moins une méthode abstraite lorsqu’une classe parent contient uneméthode méthode Une classe est diteouabstraite lorsqu'elle dénit au moins une abstraitenon ou encore lorsqu'une classe parent contient une méthode abstraite abstraite réalisée. non encore réalisée. Pierre Gérard (P13 IUT Villetaneuse) I. BOUSSAID (USTHB) Introduction à UML 2 GL - COO DUT Informatique S2D 66 / 342 18 novembre 2013 84 / 101 Diagramme de classes Compléments sur la modélisation des classes Classes Abstraites Classes abstraites - Exemple Exemple : classe abstraite FormeGéométrique - couleur: string opération abstraite + calculeSurface() + type() + colorier(string) s é Rectangle - longueur - largeur + calculeSurface() + type() Cercle - rayon + calculeSurface() + type() return PI x rayon² return longueur x largeur I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 85 / 101 Diagramme de classes Compléments sur la modélisation des classes Les interfaces Le rôle d’une interface est de regrouper un ensemble d’opérations assurant un service cohérent offert par une classe. Une interface est définie comme une classe, avec les mêmes compartiments. Les principales différences sont : la non-utilisation du mot-clé "abstract", car l’interface et toutes ses méthodes sont, par définition, abstraites ; l’ajout du stéréotype "interface" avant le nom de l’interface. Toutes les classes implémentant une interface doivent implémenter toutes les opérations décrites dans l’interface I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 86 / 101 Diagramme de classes UML Compléments sur la modélisation des classes • elles doivent mettre en œuvre les opérations de à UML e cas l’interface Les interfaces e classes e ’objets e n e ’activité ’états mmes e OO «interface» Interface 1 Représentation synthétique Interface 1 + opération1() + opération2() . . . Représentation détaillée Exemple : de ion Objet Diagramme de classes owski Généralisation/Spécialisation I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 87 / 101 Diagramme de classes Compléments sur la modélisation des classes Classe Cliente de l’interface Quand une classe dépend d’une interface (interface requise) pour réaliser ses opérations, elle est dite "classe cliente de l’interface". Graphiquement, cela est représenté par une relation de dépendance entre la classe et l’interface. Une notation lollipop équivalente est aussi possible. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 88 / 101 Diagramme de classes Compléments sur la modélisation des classes Les interfaces : implémentation et utilisation I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 89 / 101 Diagramme de classes Compléments sur la modélisation des classes Attributs dérivés Les attributs dérivés peuvent être calculés à partir d’autres attributs et des formules de calcul. Les attributs dérivés sont symbolisés par l’ajout d’un "/" devant leur nom. Lors de la conception, un attribut dérivé peut être utilisé comme marqueur jusqu’à ce que vous puissiez déterminer les règles à lui appliquer. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 90 / 101 Diagramme de classes Compléments sur la modélisation des classes Attributs de classe Par défaut, les valeurs des attributs définis dans une classe di fèrent d’un objet à un autre. Parfois, il est nécessaire de dé finir un attribut de classe qui garde une valeur unique et partagée par toutes les instances. Graphiquement, un attribut de classe est souligné I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 91 / 101 Diagramme de classes Compléments sur la modélisation des classes Opérations de classe Semblable aux attributs de classe Une opération de classe est une propriété de la classe, et non de ses instances. Elle n’a pas accès aux attributs des objets de la classe. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 92 / 101 Diagramme de classes Compléments sur la modélisation des classes Diagrammes de classes à différents niveaux On peut utiliser les diagrammes de classes pour représenter un système à différents niveaux d’abstraction : Le point de vue spécification met l’accent sur les interfaces des classes plutôt que sur leurs contenus. Le point de vue conceptuel capture les concepts du domaine et les liens qui les lient. Il s’intéresse peu ou prou à la manière éventuelle d’implémenter ces concepts et relations et aux langages d’implémentation. Le point de vue implémentation, le plus courant, détaille le contenu et l’implémentation de chaque classe. Les diagrammes de classes s’étoffent à mesure qu’on va de hauts niveaux à de bas niveaux d’abstraction (de la spécification vers l’implémentation) I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 93 / 101 Diagramme de classes Compléments sur la modélisation des classes Élaboration d’un diagramme de classes Démarche Trouver les classes du domaine étudié. généralement des concepts ou des substantifs du domaine. Trouver les associations entre classes. Souvent des verbes, ou des constructions verbales, mettant en relation plusieurs classes. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 94 / 101 Diagramme de classes Compléments sur la modélisation des classes Élaboration d’un diagramme de classes Démarche Trouver les attributs des classes. Souvent des substantifs, correspondant à un niveau de granularité plus fin que les classes. Les adjectifs et les valeurs correspondent souvent à des valeurs d’attributs. Organiser et simplifier le modèle en éliminant les classes redondantes et en utilisant l’héritage. Tester les chemins d’accès aux classées Itérer et raffiner le modèle. Un modèle est rarement correct dès sa première construction. La modélisation objet est un processus non pas linéaire mais itératif. I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 95 / 101 Diagramme de packages Plan 1 Introduction Qualité d’une conception Démarche fonctionnelle Démarche orientée objet 2 Diagramme de classes Classes et instances Relations entre classes Compléments sur la modélisation des classes 3 Diagramme de packages 4 Références I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 96 / 101 Diagramme de packages Packages Qu’est-ce qu’un paquetage (package) ? Élément de modélisation qui : Permet de grouper d’autres éléments de modélisation (classes, autres paquetages, ...) Sert d’espace de désignation Peut inclure d’autres package Peut importer d’autres package L’héritage entre package est possible I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 97 / 101 Diagramme de packages Diagramme de Packages Notation I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 98 / 101 Diagramme de packages Diagramme de Packages Exemple I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 99 / 101 Diagramme de packages Packages I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 100 / 101 Références Plan 1 Introduction Qualité d’une conception Démarche fonctionnelle Démarche orientée objet 2 Diagramme de classes Classes et instances Relations entre classes Compléments sur la modélisation des classes 3 Diagramme de packages 4 Références I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 101 / 101 Références Michael Blaha et James Rumbaugh Modélisation et conception orientées objet avec UML2, Christine Solnon Modélisation UML, Pierre Gérard Génie Logiciel - Principes et Techniques, A. Lewandowski Méthode de Conception Orientée Objet Des figures et des transparents empruntés à Delphine Longuet et Laurent AUDIBERT I. BOUSSAID (USTHB) GL - COO 18 novembre 2013 101 / 101
