08 - Diagramme de Classes [PDF]

Zitiervorschau

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´ emarche de

conception OO

Diagramme conceptionde OOclasses

impl´ementation, 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´ ethode de M´ ethode de gras) Conception Conception Orient´ ee Objet ramme de classes Diagramme de classes Orient´ ee Objet Compartiment 2 : Attributs Diagramme de classes A. Lewandowski Classe Attributs et erations A. Lewandowski A. Op´ Lewandowski Compartiment 3 : Opérations Classe M´ ethode de Conception Orient´ ee Objet

d’ajouter des compartiments (exceptions, ...) tions etPossibilité méthodes Résumé Repr´esentation 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´ e sentation Introduction Introduction pération peut s!appliquer à de nombreuses d’une Conceptsclasse de base initiale { visibilit´e nom : type e] = 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 `a 3 Introduction compartiments eule) . Attribut 1 ` a 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 ` a UML Introduction ` a 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é Diagramme d’objets enDiagramme fonction des besoins • op´erations 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´ e tails en fonction des besoins s´ equence [4] tableau de 4 élémentsDiagramme de sensDeFlux nomArgument : type = valeurParDéfaut Diagramme de Diagramme d’activit´ e Une classe communication communication [2..*] tableau dynamique sensDeFlux Diagramme d’´ etats facultatif = in, out ou inout Diagramme de Diagramme de Autres diagrammes d'au moins 2 éléments s´ equence s´ equence mais impératif Diagramme d’activit´ e Diagramme d’activit´ e D´ emarche de Une classe pour l'implémentation Diagramme d’´ etats Diagramme d’´ etats 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´ emarche de conception OO

I. BOUSSAID (USTHB)

D´ emarche de conception OO

GL - COO

18 novembre 2013

35 / 101

Diagramme de classes

Classes et instances

Représentation UML des attributs

Repr´esentation des attributs :

Représentation d’un attribut :

visibilit´e nom : type [multiplicit´e] = 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´esentation 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ˆ oles : forme nominale, d´ecrit une extr´emit´e de

l’association

I. BOUSSAID (USTHB)

GL - COO

18 novembre 2013

39 / 101

Diagramme de classes

Relations entre classes

Les Repr´eassociations 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 • Rˆ oles : formesi nominale, d´einverse) crit une extr´emit´e 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´ e :est 1,rôle2 0..1,d’un 0..*, 1..*,etn..m Un Classe2 Classe1 mult2 (x..y) Classe2 peuvent jouer ce rôle pour un Classe1

D c

• Mots cl´ es : set, ordered set, list Exemple :

I. BOUSSAID (USTHB)

GL - COO

18 novembre 2013

40 / 101

Diagramme de classes

Relations entre classes

Les associations

Repr´esentation 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ˆ oles : forme d´e0..1}, crit une extr´emit´ de sinon → Type = C2nominale, si mult2 ∈ {1, ou collection dee 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´ e : 1, 0..1, 0..*, 1..*, n..m

Exemple :

D c

• Mots cl´ es : 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´ e des associations Navigabilité d’une association • bidirectionnelles par d´efaut • la navigation peut ˆ etre restreinte `a une seule Par défaut, les associations sont navigables dans les deux directions. direction la navigation peut être restreinte à une seule direction : les instances (association `a navigabilit´ e restreinte) 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

entre classes ecialisation G´en´eRelations ralisation/Sp´

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´ ecialisation Héritage

• Extension coh´ erente de classes

Relation transitive, non réflexive, et non symétrique ! elation non-r´eflexive, non-sym´etrique ! 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´en´eralisation/Sp´ecialisation

Comment multiple Commentéviter ´eviter l’héritage l’h´eritage multiple ?? Première solution déléguer: d´ • Premi` ere :solution el´ eguer 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´en´eralisation/Sp´ecialisation

Comment ´eviterl’héritage l’h´eritage multiple ?? Comment éviter multiple • Deuxi` eme: solution eriterladeplus la importante classe la plus Deuxième solution hériter de :lah´ classe et déléguer les autres importante et d´ el´eguer les autres

L

ses

Classe A

Classe A

Classe B

Classe B

s

t´ e

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

´ e

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´ erations de

` a UML e cas

l’interface Les interfaces

e classes e

’objets e n e

’activit´ e ’´ etats 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´en´eralisation/Sp´ecialisation

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