Analyse, Conception Objet Diagrammes de Classes
Transcription
Analyse, Conception Objet Diagrammes de Classes
Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes Analyse, Conception Objet SIMMO/ENSM.SE Sommaire • Définition Diagrammes de Classes • Paquetages • Classe • Association • Aggrégation Une partie du matériau de ce cours est issue du cours de S.Galland ([email protected]) • Composition Septembre 2003 • Généralisation • Relation de dépendance • Classe abstraite • Interface • Classe utilitaire Sept.2003 1 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 Diagrammes de classes SIMMO/ENSM.SE Utilisation Définition • Lors de l’analyse et de la conception: • Point central de la modélisation du système pour exprimer sa structure statique. – Définitions formelles des objets qui composent le système à partir des cas d’utilisation et des diagrammes d’interaction (séquences et collaboration). • Représentation d’un ensemble de classes, d’interfaces et de paquetages ainsi que leurs relations. – Bases conceptuelles pour les diagrammes d’état-transition, de déploiement, ... • Une classe décrit un ensemble d’objets (instances de la classe). • Lors de l’implantation : • Une association décrit un ensemble de liens (instances de l’association). Sept.2003 Sommaire– 2 – Génération automatique des structures statiques du système (classes, relations, ...). Définition– 3 Sept.2003 Utilisation– 4 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes Paquetages Classe • Définition : description d’un ensemble d’objets partageant les mêmes attributs, opérations, méthodes, relations et sémantiques. • Définition : Mécanisme de partitionnement des modèles et de regroupement des éléments de modélisation. • Chaque paquetage peut contenir un ensemble de diagrammes et/ou de paquetages. • Généralement, en fonction de l’objectif du diagramme, elle est décrite par : un nom (obligatoire), des attributs, des opérations, des exceptions, ... • Chaque élément d’un paquetage possède un nom unique dans ce paquetage. • Possibilité de définir des relations entre paquetages (dépendances, cf. plus loin). • Un nom de classe est unique au sein du paquetage Nom de paquetage::nom de la classe Pack1 Classe1 1..2 SIMMO/ENSM.SE Pack1::Classe2 • Rque : les objets sont représentés comme les classes avec leur nom souligné. Pack2 * <<importe>> Classe1 InnerPack Sept.2003 Paquetages– 5 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 Classe– 6 Diagrammes de classes Classe (suite) Stéréotype • Un stéréotype permet d’étendre les classes déjà existantes en leur donnant une signification sémantique différente. • Représentation UML : Nom de classe Nom de classe SIMMO/ENSM.SE Nom de classe • Si la classe A est un stéréotype de la classe B, alors A se comporte comme B tout en ayant une signification sémantique différente. Attributs attribut1 attribut2 • Mécanisme proche de la généralisation/spécialisation sauf qu’il permet le changement de sémantique. Opérations op1() op2() • Représentation UML : <<stéréotype>> Nom de classe Sept.2003 Classe (suite)– 7 Sept.2003 Classe (suite)– 8 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes SIMMO/ENSM.SE Attribut Stéréotype (suite) • Définition : propriété définie par un nom, un type et éventuellement une valeur initiale. • Quelques stéréotypes prédéfinis : énumération: classe définissant un ensemble d’identificateurs formant le domaine de valeur d’un type. • Syntaxe UML : [ visibilité ] nom attribut [ multiplicité ] : type attribut [ = valeur initiale ] utilitaire: classe réduite au concept de module et qui ne peut être instanciée. – visibilité : cf. plus loin. acteur: classe modélisant un ensemble de rôles joués par un acteur. – nom attribut : identificateur de l’attribut, unique au sein de la classe. interface: classe contenant uniquement une description des opérations visibles. – multiplicité : l’attribut représente un ensemble de valeurs; exemple de tableau: Parents[ 1..2 ] : Personne. exception: classe modélisant un cas particulier de signal : les exceptions. Sept.2003 – valeur initiale : valeur prise par l’attribut lors de l’instanciation de la classe (valeur en concordance avec le type de l’attribut). Classe (suite)– 9 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 Diagrammes de classes Attribut : Type SIMMO/ENSM.SE Attribut : Type (suite) • Mutabilité : contrainte quant aux possibilités de modificiation d’un attribut. La mutabilité peut être : • type attribut : ensemble des valeurs pouvant être prises par l’attribut. Il peut être : – {gelé} : attribut non modifiable (ou constante), – une classe : Rectangle, Cercle, Personne, ... – {variable} : modifiable à tout moment (mutabilité par défaut), – un type primitif : Entier, Chaı̂ne de caractères, Booléen, ... – {ajoutUniquement} : seul l’ajout est possible (si multiplicité > 1) Télévision – une expression complexe dont la syntaxe n’est pas précisée par UML : ensemble de n points, ... Sept.2003 Classe (suite)– 10 on/off : Bouton couleur : enum{ gris, noir } marque : Chaîne télétexte : Booléen = Vrai chaînes [ 5.. * ] : Canal type : TypeTV { gelé } Classe (suite)– 11 Sept.2003 Canal Bouton <<énumération>> TypeTV 16/9 4/3 Classe (suite)– 12 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes Attribut : attribut dérivé Opération • Définition : spécification du comportement des instances de la classe. • Parfois des propriétés redondantes sont spécifiées lors de l’analyse. • Cinq catégories d’opérations : – les constructeurs qui créent les objets, • Les propriétés entièrement dépendantes d’autres propriétés peuvent être exprimées à l’aide d’attributs dérivés. – les destructeurs qui détruisent les objets, • Un attribut dérivé peut être traduit par une opération. – les sélecteurs (opérations de consultation) qui renvoient tout ou partie de l’état d’un objet, Rectangle Rectangle Longueur : Entier Largeur : Entier /Surface : Entier Longueur : Entier Largeur : Entier { surface = Longueur * Largeur } Surface() : Entier – les modificateurs qui changent tout ou partie de l’état d’un objet, – les itérateurs qui visitent l’état d’un objet ou le contenu d’une structure de données contenant des objets. renvoie Longueur * Largeur Sept.2003 Classe (suite)– 13 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 Classe (suite)– 14 Diagrammes de classes Opération (suite) SIMMO/ENSM.SE Opération : arguments • arguments : description des valeurs nécessaire à l’opération. • Syntaxe UML : [ visibilité ] nom opération ( [ arguments ] ) : type retourné propriétés • Syntaxe UML : [ direction ] nom argument : type argument [ = valeur par défaut ] [ , autres arguments ] – visibilité : cf. plus loin. Sept.2003 SIMMO/ENSM.SE – nom opération : identificateur de l’opération, unique au sein de la classe. – valeur par défaut : valeur prise par l’argument si aucune valeur n’est donnée lors de l’utilisation de cette opération. – type retourné : type de la valeur retournée par l’opération; si omis l’opération ne retourne aucune valeur. – direction : UML définit trois directions pour les arguments ∗ in (par défaut) : paramètre en entrée seule et non modifié par l’exécution de l’opération, ∗ out : paramètre en sortie seule; l’appelant peut ainsi récupérer des informations, ∗ inout : paramètre en entrée-sortie; l’argument est passé à l’opération et modifiable. Classe (suite)– 15 Sept.2003 Classe (suite)– 16 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes SIMMO/ENSM.SE Opération : propriétés Opération : implémentation • UML définit cinq propriétés pour les opérations: • Spécification d’une pré-condition : condition qui doit être toujours vraie avant l’exécution de l’opération. – requête [ = vrai | faux ] : si vrai (par défaut), l’opération n’altère pas l’état de l’instance. • Spécifciation d’une post-condition : condition qui est toujours vraie après l’exécution de l’opération. – abstrait [ = vrai | faux ] : si vrai (par défaut), indique une opération non implémentée c-à-d, une opération dont l’implémentation devra être obligatoirement réalisée par les classes filles. • Implémentation avec des diagrammes état-transition, des diagrammes de collaboration, du pseudo-code, ... – estFeuille [ = vrai | faux ] : si vrai (par défaut), indique une opération qui ne peut pas être réimplémentée par une classe fille. − nombre_éléments : Entier = 0 + retirerSommet() : Booléen + nbrElements() : Entier – concurrence = séquentiel | gardé | concurrent : précise le mécanisme d’exécution concurrente de l’opération. Sept.2003 Classe (suite)– 17 Diagrammes de classes { <<pré−condition>> nombre_éléments > 0 } Pile d’assiettes – estRacine [ = vrai | faux ] : si vrai (par défaut), indique qu’une opération est définie pour la première fois dans une hiérarchie de classes. SIMMO/ENSM.SE renvoie nombre_éléments Sept.2003 Classe (suite)– 18 Diagrammes de classes Visibilité des membres SIMMO/ENSM.SE Visibilité des membres (suite) • UML définit trois niveaux de visibilité : – public : l’élément est visible pour tous les clients/utilisateurs de la classe, noté par +. <<visible>> A B + attr_public : Entier # attr_protégé : Booléen − attr_privé : Chaîne – protégé : l’élément est visible pour les sous-classes de la classe, noté par #. + op_publique() # op_protégée() − op_privée() – privé : l’élément est visible pour la classe seule, noté par -. C Sept.2003 <<visible>> Classe (suite)– 19 Sept.2003 <<visible>> <<visible>> Classe (suite)– 20 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes SIMMO/ENSM.SE Association Portée des membres • UML définit deux niveaux de portée : • Définition : relation entre au moins deux classes qui entraı̂nent des connexions entre leurs instances. – portée d’instance (par défaut) : les éléments sont valides pour d’une seule instance de la classe; les éléments n’ont aucune existance en dehors de l’instance. • Représentation UML : trait reliant les deux classes en relation. – portée de la classe : les éléments sont toujours valides; ils ne sont pas attachés à une instance particulière mais à une classe. • Syntaxe UML : un élément ayant une portée de classe est souligné + Parents [ 1..2 ] : Personne Classe A Classe B A + ID : Entier + nombre_instances : Entier Sept.2003 Classe (suite)– 21 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 Association– 22 Diagrammes de classes SIMMO/ENSM.SE Association : arité Association : arité (suite) • Les association ont le plus souvent une arité binaire : deux classes en relation. Salle 1 Etudiant • Représentation UML des associations d’arité supérieure (n-aire) : losange. 2..* 1 Enseignant Cours début fin • Traduire une association d’arité n-aire en un ensemble d’associations binaires. Salle • Note : la difficulté de trouver un nom différent pour chaque extrémité d’une association n-aire est souvent le signe d’une association d’arité inférieure. Sept.2003 1 Etudiant Association– 23 Sept.2003 2..* 1 1 <<association ternaire>> Cours début fin 1 1 Enseignant Association– 24 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes SIMMO/ENSM.SE Association : nommage Association : rôles des extrémités • Les associations peuvent être nommées c.-à-d. identifiées par un texte unique décrivant la sémantique de l’association. • Les extrémités des associations peuvent être qualifiées par des rôles. Travaille pour Personne • Un rôle indique comment une classe Source voit une classe Destination. Source A Société • Note : utiliser une forme verbale active (“travaille pour”) ou passive (“employé par”). Société Société Association– 25 Diagrammes de classes SIMMO/ENSM.SE Association– 26 Diagrammes de classes SIMMO/ENSM.SE Association : multiplicité (suite) • Définition : la multiplicité précise le nombre d’instances pouvant être liées par une extrémité d’association à une instance pour chaque autre extrémité d’association. • Multiplicités définies par UML : • Sous sa forme générale, elle s’exprime par une suite d’intervalles disjoints sur l’ensemble des entiers naturels. • Sous-estimer la multiplicité des associations réduit la flexibilité du modèle, la sur-estimer conduit à des développements inefficaces. Sept.2003 1..10 B Société Personne Sept.2003 Association : multiplicité A employé • Note : ne pas utiliser à la fois le nommage d’une association et les rôles des extrémités de la même association. Personne Sept.2003 employeur Destination B • Le rôle est un pseudo-attribut de la classe source (utilisé comme un attribut). • Si ambiguı̈té, indiquer le sens de lecture avec les signes ou (par défaut lecture de gauche à droite). Travaille pour rôle de B employeur 0..1 0..* employé Personne Association– 27 Sept.2003 1 un et un seul (multipicité par défaut) 0..1 zéro ou un N exactement N M..N de M à N * zéro ou plus, c.-à-d. de 0 à +∞ 0..* zéro ou plus, c.-à-d. de 0 à +∞ 1..* un ou plus, c.-à-d. de 1 à +∞ Association– 28 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes SIMMO/ENSM.SE Association : qualification Association : contraintes • Clé d’accés sur l’ensemble des instances que représente l’association. • Expression de contraints sur les extrémités, entre associations, . . . (cf. cours OCL). Plateau 1 Plateau Personne Abscisse Ordonnée 1 0..* {ordonné} Compte Secteur 1 PC portable 1..n {ou−exclusif} Batterie 1 Case Case Parents d’élèves * Classe {sous−ensemble} d’école Personne * Délégués Sept.2003 Association– 29 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 Association– 30 Diagrammes de classes Association : classe-association SIMMO/ENSM.SE Association : classe-association (suite) • Si une association possède des propriétés ou des opérations, il est possible de la qualifier à l’aide d’une classe-association. • Lors de la conception, une classe-association peut être remplacée par une classe intermédiaire. • Une classe-association possède les mêmes caractéristiques que les associations et les classes. Etudiant réalise 1..* 0..* Travail m A B n note : 0..20 attribut • Une classe-association qui ne participe pas à d’autres relations avec d’autres classes peut ne pas porter de nom. A Sept.2003 Association– 31 Sept.2003 m C attribut n B Association– 32 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes SIMMO/ENSM.SE Composition Aggrégation • Définition : forme spéciale d’association exprimant une relation de composition entre aggrégats (part-whole). • Cas particulier d’aggrégation. La classe ayant le rôle prédominant est la classe composite ou classe conteneur. • Association irréflexive, antisymétrique dans laquelle une des extrémitiés joue un rôle prédominant, pouvant être récursive. • La composition implique : – la durée de vie des composants est la même que celle du composite. • Permet de modéliser les contraintes d’intégrité et de désigner les aggrégats comme garant de ces contraintes. – la multiplicité du côté du composite prend ses valeurs dans 0 ou 1. • La composition et les attributs sont sémantiquement équivalents. • A travers une aggrégation, il est possible de représenter : Composite – la propagation des valeurs d’attributs d’une classe vers l’autre; – une action sur une classe qui implique une action sur une autre classe (ex: copie profonde); Voiture 0..1 * Voiture m : Moteur Composant m 1 Moteur – une subordination des objets d’une classe à ceux d’une autre. propriétaire Personne 1..* 0..* Immeuble Sept.2003 Aggrégation– 33 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 Composition– 34 Diagrammes de classes SIMMO/ENSM.SE Généralisation : simple Généralisation • La généralisation simple est une relation binaire. • Définition : relation (irréflexive, antisymmétrique, transitive) entre une classe plus générale et une classe plus spécifique (signifie “est un” ou “est une sorte de”). Ce n’est pas une association. • Représentation UML : flèche triangulaire blanche orientée vers la classe la plus générale. • Exemple : un animal est un concept plus général qu’un chat ou un chien. Inversement un chien est un concept plus spécialisé qu’un animal. La classe Animal est une généralisation de la classe Chat ou la classe Chien. La classe Chien est une spécialisation de la classe Animal. Animal Chien Chat Cheval Animal • L’élément plus spécifique peut contenir des informations qui lui sont propres, à condition que ces informations et la description des éléments plus généraux soient totalement cohérentes. Chien Chat Cheval • Deux types de généralisation : simple ou multiple. Sept.2003 Généralisation– 35 Sept.2003 Généralisation– 36 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes Généralisation : simple (suite) SIMMO/ENSM.SE Généralisation : simple (suite) • La classe la plus générale peut être nommée : “classe mère”, “classe parent”, “superclasse”, “classe de base”. • Les sous-classes héritent des attributs, des opérations, des relations et des contraintes définies dans la classe mère. • La classe la plus spécialisée peut être nommée : “classe fille”, “classe enfant”, “sous-classe”, “classe dérivée”. • Héritage: mécanisme permettant à une classe d’utiliser les membres de sa classe mère sans avoir à les redéfinir. • La classe la plus élévée dans la hiérarchie (pas de généralisation) est souvent nommée “classe racine”. Animal # âge : Entier = 0 + mange() Chat + anniversaire() Sept.2003 Généralisation– 37 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 • Définition : mécanisme permettant à une classe d’avoir plusieurs classes mères. Animal + mange() : Type_Alimentation SIMMO/ENSM.SE Généralisation : multiple • Définition : mécanisme permettant à une classe fille la spécialisation d’opérations. Omnivore Carnivore Herbivore Généralisation– 38 Diagrammes de classes Polymorphisme <<énumération>> Type_Alimentation { âge := âge + 1; } • Les superclasses n’ont pas forcément d’ancêtres communs. renvoie Omnivore Véhicule Lion Vache + mange() : Type_Alimentation + mange() : Type_Alimentation Humain Tapis Aérien Tapis volant renvoie Carnivore renvoie Herbivore • Tapis volant hérite des propriétés de Tapis et de Aérien. • L’exécution de l’opération mange() déprendra du type réel de l’objet : Lion::mange() pour un Lion et Animal::mange() pour un Humain. Sept.2003 Généralisation– 39 Sept.2003 Généralisation– 40 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes Relation de dépendance Relation de dépendance (suite) • Définition : relation unidirectionnelle indiquant qu’un changement dans la cible (fournisseur) provoque un changement dans la source (client). • Stéréotypes prédéfinis dans UML pour les relations de dépendance : – Liaison : lie • Relation non structurelle existant entre plusieurs éléments. – Utilisation : utilise, appelle (une opération source appelle une autre opération cible), crée (une instance de la classe source crée une instance de la classe cible), instancie (une opération de l’élément source crée une instance de l’élément cible), instance de (l’élémént source est une instance de l’élément cible). • Représentation UML : une flèche pointillé éventuellement stéréotypée. • Quatre types de relations de dépendances : Abstraction: relation entre éléments qui représentent un même concept à différents niveaux d’abstraction ou selon des points de vue distincts; – Permission : ami (permet à l’élément source d’ignorer la propriété de visibilité de l’élément cible), Liaison: dépendance entre une classe paramètrable (cible) et une classe paramètrée (source); – Abstraction : dérive (un élément source est défini ou calculé à partir d’un élément cible), raffine relation de dépendance entre deux éléments à des niveaux sémantiques différents, réalise : l’élément source implémente la spécification désignée par l’élément cible. Permission: l’élément source a le droit d’accéder à l’espace de nommage de l’élément cible; Utilisation: l’élément source requiert la présence d’un élément cible. Sept.2003 Relation de dépendance– 41 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 • On définit une classe abstraite lorsque : – il est impossible de connaı̂tre l’implantation d’une méthode (abstractisation d’une opération). Exemple : l’opération manger() de la classe Animal n’a pas de sens sémantique propre; il s’agit d’une propriété existant chez tous les animaux; il est impossible de préciser le comportement de ce service au niveau de la classe Animal. • Représentation UML : définition de la classe avec la propriété {abstrait} ou si une de ses opérations (héritée ou non) possède la propriété {abstrait = vrai}. Classe A { abstrait } + mange() : Type_Alimentation {abstrait} Omnivore Carnivore Herbivore SIMMO/ENSM.SE Classe abstraite (suite) • Définition : classe non instanciable définissant au moins un mécanisme général instanciable par des classes filles. Animal Relation de dépendance (suite)– 42 Diagrammes de classes Classe abstraite <<énumération>> Type_Alimentation SIMMO/ENSM.SE – l’instanciation d’une classe n’a aucun sens sémantique ou pratique. Lion Vache Humain + mange() : Type_Alimentation + mange() : Type_Alimentation + mange() : Type_Alimentation renvoie Herbivore renvoie Omnivore renvoie Carnivore Sept.2003 Classe abstraite– 43 Sept.2003 Classe abstraite (suite)– 44 Diagrammes de classes SIMMO/ENSM.SE Diagrammes de classes SIMMO/ENSM.SE Interface Interface (suite) • Définition : description d’un ensemble d’opérations utilisées pour spécifier un service offert par une classe. • Ne contient ni attribut, ni association, ni implémentation des opérations (les opérations sont abstraites). <<interface>> Crédit Entreprise • Une classe réalisant une interface doit : <<utilise>> <<réalise>> – soit implémenter les opérations de l’interface, <<utilise>> – soit définir les opérations de l’interface comme des opérations abstraites (implémentables par les classes filles). Client • Représentation UML : <<utilise>> – classe ayant le stéréotype interface, ou par un cercle pour faire référence à l’interface utilisée dans la classe, Banque Crédit <<interface>> Assurance <<réalise>> mensualité() : Réel – flèche d’héritage en pointillés pour la réalisation d’une interface par une classe, – flèche de dépendance en pointillés pour l’utilisation. Sept.2003 Interface– 45 Diagrammes de classes SIMMO/ENSM.SE Sept.2003 Interface (suite)– 46 Diagrammes de classes Classe utilitaire SIMMO/ENSM.SE Pour en savoir plus ... • Définition : définition d’une classe dont tous les membres ont une portée de classe les attributs et les opérations deviennent des variables et des procédures globales. “Modélisation objet avec UML”. Muller, Gaertner. 2000. Éditions Eyrolles (http://www.editionseyrolles.com/). “Le guide de l’utilisateur UML”. Booch. 2000. Éditions Eyrolles. • Une classe utilitaire ne peut pas être instanciée. • En Java, une classe utilitaire correspond à une classe qui ne contient que des membres statiques. “UML en action – De l’analyse des besoins à la conception en Java”. Roques. 2000. Éditions Eyrolles. • Représentation UML : classe ayant le stéréotype utilitaire. “Intégrer UML dans vos projets”. Lopez. 1997. Éditions Eyrolles. <<utilitaire>> Math + sin(Degré) : Réel + cos(Degré) : Réel Sept.2003 Classe utilitaire– 47 Sept.2003 Pour en savoir plus ...– 48