Université Mohammed El Bachir El Ibrahimi- Bordj Bou Arreridj Faculté des Mathématiques et Informatique Master I IID Modélisation Objet avec UML Djamila MOHDEB [email protected] [email protected] Année universitaire: 2020/2021 2 Chapitre II: Diagrammes structurels 3 Diagramme de classes 4 Diagramme de classes Objectif : le diagramme de classe permet de donner la représentation statique du système à développer. Cette représentation est centrée sur les concepts de classe et d’association. La description du diagramme de classe est fondée sur : • Le concept d’objet, • Le concept de classe comprenant les attributs et les opérations (méthodes), • Les différents types d’association entre classes. 5 Classe Une classe se représente à l’aide d’un rectangle comportant plusieurs compartiments. Les trois compartiments de base sont : • La désignation de la classe, • La description des attributs, • La description des opérations. Deux autres compartiments peuvent être aussi indiqués : • La description des responsabilités de la classe, • La description des exceptions traitées par la classe. 6 Classe Attribut Un attribut est une propriété élémentaire d’une classe. Pour chaque objet d’une classe, l’attribut prend une valeur (sauf cas d’attributs multivalués). La syntaxe générale d’un attribut est : [Visibilité] Nom_attribut [multiplicité] [:type_attribut] [=valeur initiale {propriété}] • Visibilité : se reporter aux explications données plus loin sur ce point. • Nom d’attribut : nom unique dans sa classe. • Multiplicité : un attribut peut avoir des valeurs multiples. Dans ce cas, cette caractéristique est indiquée après le nom de l’attribut (ex. : prénom [3] pour une personne qui peut avoir trois prénoms). • Type : type primitif (entier, chaîne de caractères…) dépendant des types disponibles dans le langage d’implémentation ou type classe matérialisant un lien avec une autre classe. • Valeur initiale : valeur facultative donnée à l’initialisation d’un objet de la classe. • {propriétés} : valeurs marquées facultatives (ex. : « id » (identifiant), « modifiable » (variable) ou « figé » (frozen). Par défaut l’attribut est modifiable). Facture -num_facture : Chaine de caractères {id} -date_facture : Date = 01/01/2019 -montant_facture : Réel /montant_TVA : Réel 9 Remarques • Un attribut dont la valeur peut être calculée à partir d’autres attributs de la classe est un attribut dérivé qui se note: « /nom de l’attribut dérivé ». • On donne à chaque classe un identifiant de référence {id}. UML ne l’impose pas ; mais dans le cadre d’une implémentation sur SGBD relationnel, il est indispensable que les objets aient des identifiants. Opération Une opération est une fonction applicable aux objets d’une classe. Une opération permet de décrire le comportement d’un objet. Une méthode est l’implémentation d’une opération. La syntaxe générale d’une opération est : [Visibilité] Nom_opération (paramètres) [:type_résultat {propriété}] • Visibilité : se reporter aux explications données plus loin sur ce point. • Nom d’opération : utiliser un verbe représentant l’action à réaliser. • Paramètres : liste de paramètres (chaque paramètre peut être décrit, en plus de son nom, par son type et sa valeur par défaut). L’absence de paramètre est indiquée par ( ). 11 • Type résultat : type de (s) valeur(s) retourné(s) dépendant des types disponibles dans le langage d’implémentation. Par défaut, une opération ne retourne pas de valeur, ceci est indiqué par exemple par le mot réservé « void » dans le langage C++ ou Java. • {propriétés} : valeurs facultatives applicables (ex. : {query} pour un comportement sans influence sur l’état du système). Visibilité des attributs et opérations Chaque attribut ou opération d’une classe peut être de type public, protégé, privé ou paquetage. Les symboles + (public), # (protégé), (privé) et ~ (paquetage) sont indiqués devant chaque attribut ou opération pour signifier le type de visibilité autorisé pour les autres classes. Les droits associés à chaque niveau de confidentialité sont : • Public (+) attribut ou opération visible par tous. • Protégé (#) attribut ou opération visible seulement à l’intérieur de la classe et pour toutes les sous-classes de la classe. • Privé (-) attribut ou opération seulement visible à l’intérieur de la classe. • Paquetage (~) attribut ou opération ou classe seulement visible à l’intérieur du paquetage où se trouve la classe. 13 Attribut ou opération de niveau classe • Un attribut ou une opération peut être défini non pas au niveau des instances d’une classe, mais au niveau de la classe. • Il s’agit soit d’un attribut qui est une constante pour toutes les instances d’une classe soit d’une opération d’une classe abstraite ou soit par exemple d’une opération « créer » qui peut être définie au niveau de la classe et applicable à la classe elle-même. • C’est le soulignement de l’attribut ou de l’opération qui caractérise cette propriété. • L’attribut nb_livres_empruntables est un attribut de niveau classe. Cet attribut a la même valeur pour tous les objets de la classe. • Ce n'est pas une caractéristique d'un objet instance de la classe Personne. C'est une caractéristique valable pour l'ensemble des personnes (la classe). En C++, un attribut est traduit par un attribut dans la classe de type « static ». • Une opération de niveau classe peut uniquement accéder aux attributs de niveau classe. • L’opération getNb_livres_empruntables () est appelée pour afficher la valeur nb_livres_empruntables qui est un attribut de niveau classe. En C++, une opération de classe est traduite par une méthode « static » de la classe. 16 Relations entre classes • Une association représente une relation sémantique entre les objets d'une classe. • Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre les éléments du modèle (flèche ouverte pointillée). • Une relation d'héritage est une relation généralisation/spécialisation permettant l'abstraction. de • Une relation d'agrégation décrit une relation de contenance ou de composition. 17 Association Une association décrit un groupe de liens ayant une même structure et une même sémantique. Un lien est une instance d’une association. • Une association peut être identifiée par son nom. • Le symbole ► (facultatif) indique le sens de lecture de l’association. • Le rôle tenu par une classe vis-à-vis d’une association peut être précisé sur l’association. 18 • La multiplicité ou la cardinalité indique un domaine de valeurs pour préciser le nombre d’instance d’une classe vis-à-vis d’une autre classe pour une association donnée : • 1..1 : cardinalité minimale et maximale sont égale à 1. Aussi noté 1. • x..x : minimale et maximale sont égale à x. Aussi noté x. x doit être un entier positif et non nulle. • 0..1 : cardinalité minimale est égale à 0 ; la cardinalité maximale est égale à 1. • 0..* : cardinalité minimale est égale à 0 ; la cardinalité maximale est égale à n. Aussi noté *. • 1..* : cardinalité minimale est égale à 1 ; la cardinalité maximale est égale à n. • n..m : cardinalité minimale est égale à n ; la cardinalité maximale est égale à m. • 1,n,m : cardinalité est égale à 1, n ou m. 20 Navigabilité de l’association • La navigabilité indique si l’association fonctionne de manière unidirectionnelle ou bidirectionnelle, elle est matérialisée par une ou deux extrémités fléchées. • Par défaut une association est bidirectionnelle. Il est possible de réduire la portée en la rendant unidirectionnelle. En général, ce choix se fait dans la phase de conception. 21 Association réflexive Une association est dite réflexive si elle met en relation une classe avec elle-même. 22 Classe d’association • Une association porteuse d’attributs est appelée classe association. • Les attributs d’une classe association dépendent fonctionnellement des identifiants appartenant aux classes associées. 23 Association ternaire • Il est exceptionnel d’avoir besoin d’associations n-aires avec n supérieur à 3. Mais il peut être commode d’utiliser des relations ternaires (n supérieur à 2) pour éviter de définir une classe supplémentaire 24 Qualificateurs : restriction de la cardinalité • La qualification d’une relation entre deux classes permet de préciser la sémantique de l’association et de qualifier de manière restrictive les liens entre les instances. • Seules les instances possédant l’attribut indiqué dans la qualification sont concernées par l’association. Cet attribut ne fait pas partie de l’association. Contraintes d’association Dans le langage UML, une contrainte est une règle de gestion attachée à un élément du modèle et exprimée entre accolades {…} dans un langage naturel ou formel (langage OCL pour UML). Prenant en exemple les contraintes prédéfinies pour les associations : • Sur une extrémité : {ordered}, {unique}, … • Entre deux associations : {subset}, {xor}, ... Contraintes d’association • Entre deux associations : {subset}, {xor}, ... Propriétés de mise à jour de liens Il est possible d’indiquer des contraintes particulières relatives aux conditions de mise à jour des liens. • {variable} : instance modifiable (par défaut). • {frozen} : instance non modifiable fixée lors de la création de l’objet. • {addOnly} : instances ajoutables mais non retirables (impossible de supprimer un élément). 28 Dépendance entre classes • La dépendance entre deux classes permet de représenter l’existence d’un lien sémantique. • Une classe B est en dépendance de la classe A si des éléments de la classe A sont nécessaires pour construire la classe B. 29 Composition et agrégation • Une agrégation est un cas particulier d’association non symétrique exprimant une relation de contenance. • Les agrégations n’ont pas besoin d’être nommées : implicitement elles signifient « contient », « est composé de ». 30 Règles permettant de choisir une agrégation • Est-ce une partie de ? • Les opérations appliquées à l'ensemble sont-elles appliquées à l’élément ? • Les changements d'états sont-ils liés ? 31 Composition et agrégation 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 entraîne la destruction de tous ses éléments (le composite est responsable du cycle de vie des parties). 32 Règles obligatoires pour la composition • La suppression du composé entraîne-t-elle la suppression des composants ? • Les attributs du composé sont-ils utilisés dans les composants ? • Les composants sont des instances du composé ? • Un composant ne peut pas être en relation avec d'autres classes externes au composé. Remarque : le choix entre l’agrégation et la composition peut être laissé à la phase de conception. 33 Généralisation/Spécialisation • Une superclasse est une classe plus générale reliée à une ou plusieurs autres classes plus spécialisées (sous-classes) par une relation de généralisation. • Les sous-classes « héritent » des propriétés de leur superclasse et peuvent comporter des propriétés spécifiques supplémentaires. 34 Généralisation/Spécialisation Remarque • Les sous-classes peuvent masquer des attributs correspondants à la superclasse. Ils peuvent également avoir des attributs supplémentaires. • L’ajout de propriétés dans une sous-classe correspond à une extension de classe. Le masquage de propriétés dans une sous-classe correspond à une restriction de classe. 35 Héritage multiple L’héritage multiple met en évidence des classes spécialisées correspondant à plusieurs classes génériques. 36 Contraintes de spécialisation Par défaut, les sous-classes ont des instances disjointes les unes par rapport aux autres. Dans certains cas, il existe un recouvrement d’instances entre les sousclasses. D’une manière générale, quatre situations peuvent se rencontrer et se représentent sous forme de contraintes : • {overlapping} (chevauchement): deux sous-classes peuvent avoir, parmi leurs instances, des instances identiques ; • {disjoint} : les instances d’une sous-classe ne peuvent être incluses dans une autre sous-classe de la même classe ; • {complete} : la généralisation ne peut pas être étendue ; • {incomplete} : la généralisation peut être étendue. 38 Classe abstraite • Une classe abstraite est simplement une classe qui ne s’instancie pas directement mais dont les classes descendantes ont des instances. Elle se note en italique. • Dans une relation d’héritage, la superclasse est par définition une classe abstraite. 39 Classe abstraite « Abstract » Media • Exemple Enregistrer() Afficher() Texte ligne Afficher() Image long larg Afficher() Vidéo Graphique durée points Afficher() Afficher() 40 Classe Interface • Une classe d’interface permet de décrire la vue externe d’une classe. La classe d’interface, identifiée par un nom, comporte la liste des opérations accessibles par les autres classes. Le compartiment des attributs ne fait pas partie de la description d’une interface. • La classe d’interface est une spécification et non une classe réelle. Une classe d’interface peut s’assimiler à une classe abstraite. • Une interface ne peut donner lieu à aucune implémentation. 41 Classe Interface « Interface » Déplaçable Avancer() Reculer() Descendre() • Exemple « réalise » « réalise » « réalise » Personne Animal Voiture nom nom vitesse Avancer() Reculer() Descendre() Avancer() Reculer() Descendre() Avancer() Reculer() Descendre() 42 Classe Interface Représentation • L’interface peut être aussi matérialisée plus globalement par un petit cercle associé à la classe source. • La classe utilisatrice de l’interface est reliée au symbole de l’interface par une flèche en pointillé. Exemple (N.B: Cette figure est empruntée du livre « UML, analyse et conception ») 44 Diagramme d’objets 45 Diagramme d’objets • Le diagramme d’objets permet de mettre en évidence des liens entre les objets. • Les objets instances des classes, sont reliés par des liens, instances des associations. • Le diagramme d’objets utilise les mêmes concepts que le diagramme de classes, à l’exception de la multiplicité qui est explicitement indiquée. • Il est essentiellement utilisé pour comprendre ou pour illustrer des parties complexes d’un diagramme de classes. 46 Diagramme d’objets Formalisme et représentation • Le nom d’un objet est toujours souligné. Il peut prendre trois formes : ✓ nom_objet ✓ nom_objet :nom_classe ✓ :nom_classe (pour désigner un objet quelconque de la classe). • Le nom d’un lien est toujours souligné. Exemple: 47 Diagramme d’objets Livre 0..* aPourAuteur ► titre Roman01 :Livre titre=Nedjma Auteur 1..* nom Auteur01:Auteur aPourAuteur ► nom=Kateb Yacine 48 Diagramme de paquetages 49 Diagramme de paquetages Objectif • La modélisation en paquetages vise à décomposer un projet logiciel en sous-systèmes cohérents. • En pratique, il s’agit de regrouper entre elles des classes liées les unes aux autres de manière à faciliter la maintenance ou l’évolution du projet et de rendre aussi indépendantes que possible les différentes parties d’un logiciel. • Les paquets offrent un mécanisme général pour structurer les éléments de modélisation dans un diagramme. 50 Diagramme de paquetages • Un paquetage peut contenir d’autres paquetages, sans limite du niveau d’emboitement. • Un niveau donné peut contenir un mélange de paquetages et d’autres éléments de modélisation (classes, des interfaces, …etc.), de la même manière qu’un répertoire peut contenir des répertoires et des fichiers. 51 Diagramme de paquetages Formalisme • Les packages se représentent à l’aide d’un rectangle possédant un onglet dans lequel est inscrit le nom du package. Les éléments contenus se représentent dans le rectangle. La taille du rectangle s’adapte à la taille de son contenu. Nom du paquet 52 Diagramme de paquetages Dépendance entre paquetages • Une relation de dépendance entre deux paquetages A et B signifie qu’au moins une classe du paquetage A utilise les services offerts par au moins une classe du paquetage B. • Toutes les classes contenues par un paquetage ne sont pas nécessairement visibles de l’extérieur du paquetage. A B 53 Diagramme de paquetages Principes de découpage en paquetages • Pour identifier les bonnes catégories (paquetages), il faut se fonder sur deux principes fondamentaux : cohérence et indépendance. Avantages de découpage en paquetages • Un bon découpage permet d’être plus efficace pour organiser les équipes, maîtriser la complexité, assurer l’évolutivité et favoriser la réutilisation. • En d’autres termes, le découpage conditionne l’application du style d’architecture orienté composant.
