Conception Orientée Objet

Partie II: Diagrammes

Mahamadou Abdou TOURE

1
2 Plan du Cours
 Diagrammes d’objets
 Diagrammes de classes
3 I. Diagrammes d’objets
Objectif : Représenter les objets et leurs liens à un instant donné
 Utilisation : documenter des cas de test, analyser des exemples, ...
Moyen : Graphe
 Nœuds du graphe = Objets
 Possibilité de supprimer le nom, la classe
et/ou les attributs (objet anonyme, non typé
ou d’état inconnu)
 Arêtes du graphe = Liens entre objets
 Lien binaire : entre 2 objets
 Lien n-aire : entre n objets
 Possibilité de nommer les liens et les rôles
 Correspondance entre liens et attributs
4 I. Diagrammes d’objets
Exemple de diagramme d’objets
5 I. Diagrammes d’objets
Exercice:
 Tidiane, Kadiatou, Fatoumata, Aly, Tahirou et Salif sont étudiants au
département GEII;
 Mahamadou et Abdoulaye sont enseignants au département GEII.
 Mahamadou enseigne le C et le réseau ;
 Abdoulaye enseigne les machines électriques, les TCE et la
maintenance;
 Tidiane, Kadiatou et Fatoumata suivent les cours de C, de réseau et de
maintenance ;
 Tahirou, Aly et Salif suivent les cours de C, machines électriques et TCE.
6 II. Diagrammes de classes
1. Introduction
Ce sont les plus importants pour la modélisation orientée objet.
Le diagramme de classes décrit la structure interne du système
contrairement au diagramme de cas d'utilisation qui montre le
système du point de vue des acteurs.
Il permet de fournir une représentation abstraite des objets du
système qui vont interagir ensemble pour réaliser les cas d'utilisation.
7 II. Diagrammes de classes
2. Représentation UML des classes
Rectangle composé de compartiments :
 Compartiment 1 : Nom de la classe (commence par une majuscule, en
gras)
 Compartiment 2 : Attributs
 Compartiment 3 : Opérations
 Possibilité d’ajouter des compartiments (exceptions, ...)
Différents niveaux de détail possibles :
 Possibilité d’omettre attributs et/ou opérations

NomClasse1 NomClasse2 NomClasse3

Attr1: Entier attr1
Attr2: Chaîne … attr2
Op1(p1:Entier): Entier …
Op2(): Chaîne …
8 II. Diagrammes de classes
2. Représentation UML des classes
Exemple: Jouet
9 II. Diagrammes de classes
2. Représentation UML des classes
Propriétés : attributs et opérations
Les attributs et les opérations sont les propriétés
d'une classe. Par convention leurs noms
commencent par une minuscule.
Un attribut décrit une donnée de la classe
 c'est une généralisation de la notion de
variable.
Une opération est un service offert par la
classe (un traitement que les objets
correspondants peuvent effectuer - une
méthodes).
Un attribut est défini par son nom et son type.
Une opération est définie par sa signature :
nom + paramètres + type de retour
10 II. Diagrammes de classes
3. Représentation UML des attributs
 Format de description d’un attribut :
[Vis] Nom [Mult] [":" TypeAtt] ["=" Val] [Prop]
 Vis : + (public), - (privé), # (protégé), (package)
 Mult : "[" nbElt "]" ou "[" Min .. Max "]"
 TypeAtt : type primitif (Entier, Chaîne, ...) ou classe
 Val : valeur initiale à la création de l’objet
 Prop : {gelé}, {variable}, {ajoutUniquement}, ...
 Attributs de classe (statiques) soulignés
 Attributs dérivés précédés de "/"
11 II. Diagrammes de classes
3. Représentation UML des attributs
Exemples :
 # onOff : Bouton
 - x : Réel
 coord[3] : Réel
 + pi : réel = 3.14 {gelé}
 inscrits[2..8] : Personne
 /age : Entier
12 II. Diagrammes de classes
4. 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)
13 II. Diagrammes de classes
4. Représentation UML des opérations
Propriétés : attributs et opérations
Attributs et opérations de classe :
 Souligné (le terme static en C++ et Java)
 Attribut de classe partagé par toutes les
instances de la classe (garde une valeur
unique et partagée par toutes les instances
de classe)
 Opération de classe sur des attributs de
classe uniquement
Attributs dérivés :
 peuvent être calculés à partir d'autres
attributs et de formules de calcul
 Exemple : π vs Volume
 peu utilisés
14 II. Diagrammes de classes
4. Représentation UML des opérations
 Opérations abstraites/virtuelles (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»
15 II. Diagrammes de classes
5. Relations entre classes
 Une relation d'héritage est une relation de généralisation/spécialisation
permettant l'abstraction de concepts.
 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 association représente une relation sémantique entre les objets
d'une classe.
 Une relation d'agrégation décrit une relation de contenance ou de
composition.
16 II. Diagrammes de classes
6. Associations entre classes
 Abstraction des relations définies par les liens entre objets
Liens entre objets :
17 II. Diagrammes de classes
7. Relations entre classes - Association
connexion sémantique entre des classes représentée par un trait
 le plus souvent entre deux classes (binaire)
 parfois on peut indiquer le sens de la lecture (par un verbe)

 l'association peut être nommée par ses rôles.

18 II. Diagrammes de classes
7. Relations entre classes – Association – Rôle d’une
association
 le rôle décrit comment une classe voit une autre classe à travers
l'association
 Le rôle devient le nom d'un champ en C++ et Java
 il y a deux rôles (ne vous trompez pas de côté ! ! !)
 multiplicité ou cardinalité
19 II. Diagrammes de classes
7. Relations entre classes – Association – Multiplicité des
associations
La notion de multiplicité (ou cardinalité) permet de contraindre le nombre
d'objets intervenant dans les instanciations des associations.

Exemple : une location est payée par un et un seul client, alors que le client
peut réserver plusieurs locations.
La syntaxe de m
 1 : toujours un et un seul (dès la création de l'objet)
 0..1 : zéro ou un

}
 m..n : de m à n (entiers > 0)
 * ou 0..* : de zéro à plusieurs vecteur/liste en C++/Java
 1..* : au moins un
20 II. Diagrammes de classes
7. Relations entre classes – Association – rôle et
Multiplicité des associations
Règle générale :

Exemple:
21 II. Diagrammes de classes
7. Relations entre classes – Association – rôle et
Multiplicité des associations
Exercice:
 Chaque étudiant du département IF suit un ensemble d’unités
d’enseignement (UE).
 Chaque UE a un coefficient et est constituée de cours, de travaux
dirigés (TD) et de travaux pratiques (TP).
 Chaque cours, TD ou TP a une date. Les cours sont faits en amphi, les TD
en salle de classe et les TP en salle machine.
 Pour les TP et TD, les étudiants sont répartis dans des groupes. Pour
chaque TP, chaque étudiant est en binôme avec un autre étudiant.
 Les cours et les TD sont assurés par un enseignant. Les TP sont assurés par
deux enseignants.
 Pour chaque UE, l’étudiant a une note de devoir surveillé ; pour chaque
TP, le binôme a une note de TP.
22 II. Diagrammes de classes
8. Navigabilité
Qu’est-ce que la navigabilité d’une association entre C1 et C2 ?
 La navigabilité permet de spécifier dans quel(s) sens il est possible de
traverser l'association a l'exécution.
 On restreint la navigabilité d'une association à un seul sens a l'aide
d'une flèche.

Exemple : Connaissant un article on connaît les commentaires, mais pas

l'inverse. En C++ ou Java, listeDesAvis pourrait être un tableau de
références vers des objets de type Commentaire.
23 II. Diagrammes de classes
8. Navigabilité
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 C2
 C1 a un attribut de type C2 et C2 a un attribut de type C1
Spécification de la navigabilité : C1 x C2
Orientation de l’association
 C1 a un attribut du type de C2, mais pas l’inverse
Attention :
Dans un diagramme de classes conceptuelles, toute classe doit être
accessible à partir de la classe principale
24 II. Diagrammes de classes
8. Navigabilité
Qu’est-ce que la navigabilité d’une association entre C1 et C2 ?
 Association unidirectionnelle de 1 vers 1

 Association bidirectionnelle de 1 vers 1

 Association unidirectionnelle de 1 vers *

25 II. Diagrammes de classes
9. Propriétés et contraintes sur les associations
Propriétés sur extrémités d’associations
 {variable} : instance modifiable (par défaut)
 {frozen} : instance non modifiable
 {addOnly} : instances ajoutables mais non retirables (si mult. > 1)
Contraintes prédéfinies
 Sur une extrémité : {ordered}, {unique}, ...
 Entre 2 associations : {subset}, {xor}, ...
26 II. Diagrammes de classes
10. Classes Associations
Association attribuée :

Une classe association peut participer à d’autres associations :

27 II. Diagrammes de classes
10. Classes Associations
Classes – Associations réflexives
 L'association la plus utilisée est l'association binaire (reliant deux classes).
 Parfois, les deux extrémités de l'association pointent vers la même
classe. Dans ce cas, l'association est dite réflexive .
28 II. Diagrammes de classes
10. Classes Associations
Associations n – aires Classe – association
 C'est une association qui possède des propriétés
 Elle est plus riche qu'une association simple
 L'identifiant de la classe-association est déterminé par les deux classes
reliées par l'association
29 II. Diagrammes de classes
10. Classes Associations
Associations n – aires
Associations entre n classes (avec n > 2)

Classes-Associations n-aire
30 II. Diagrammes de classes
11. Associations particulières : composition et agrégation
Composition :
 L'association la plus "forte". On utilise un losange plein

 Décrit une contenance structurelle entre instances

 Cardinalité maximum de 1 obligatoire
 Relation transitive et antisymétrique
 Un composant appartient à au plus un composite (container ou
ensemble)
 La création (copie, destruction) du composite (container ou ensemble)
implique la création (copie, destruction) de ses composants (partie)
31 II. Diagrammes de classes
11. Associations particulières : composition et
agrégation
Agrégation :
 Une agrégation est une forme d'association plus forte que
l'association simple
 Représente la relation d'inclusion faible d'un élément dans
un ensemble
 On représente l'agrégation par l'ajout d'un losange vide du
côté de l'agrégat

 On utilise souvent le terme composition faible

 Simple regroupement de parties dans un tout
32 II. Diagrammes de classes
11. Associations particulières : composition et agrégation
Exemple:
33 II. Diagrammes de classes
11. Associations particulières : composition et agrégation
 Dès que il y a la notion de contenance on utilise une agrégation ou une
composition
 La composition est aussi dite agrégation forte

NB: Si les composants ont une autonomie vis-à-vis du composite alors

préférez l'agrégation. Mais tout dépend de l'application que vous
développez.
34 II. Diagrammes de classes
12. Dépendance
 Relation unidirectionnelle exprimant une dépendance sémantique
entre deux classes/interfaces
 Représenté par un trait discontinu orienté

 Généralement A dépend de B si :
 A utilise B comme argument dans la signature d'une méthode
 A utilise B comme variable locale d'une méthode
35 II. Diagrammes de classes
12. Dépendance
Exemple : la modification du code de la route a un impact sur
 l'attitude du conducteur
 des caractéristiques des voitures

Relation très générale : toutes les relations possibles entre les classes sont
des dépendances
36 II. Diagrammes de classes
13. Généralisation et Héritage
Niveau conceptuel : Généralisation
 indique qu'une classe est un cas plus générale d'une autre
 se traduit par la notion d'héritage en Programmation Objet
 Relation non-réflexive
 transitive : les classes spécialisées héritent de la structure et du
comportement des classes plus générales (attributs, opérations,
associations et nouveaux héritages)
 Relation non symétrique
 La sous-classe “est-une-sorte-de” la super classe
 Toute instance de la sous-classe est instance de la super classe
37 II. Diagrammes de classes
13. Généralisation et Héritage
Niveau implémentation : Héritage
 Mécanisme proposé par les langages de programmation Objet
 "B hérite de A" signifie que B possède :
 Toutes les propriétés de A (attributs, op., assoc., contraintes)
 Possibilité de redéfinir les opérations de la sous-classe
 Polymorphisme
 Ainsi que des nouvelles propriétés qui lui sont propres
 Permet de factoriser les propriétés communes à plusieurs classes
 Une opération définie pour A est accessible aux sous-classes de A
38 II. Diagrammes de classes
13. Généralisation et Héritage
Exemple
39 II. Diagrammes de classes
14. Héritage vs Composition
Problème :
Modéliser le fait qu’il y a des voitures bleues, des voitures rouges et des voitures
vertes.
Solution 1 : Héritage
 Créer une classe abstraite Voiture
 Créer 3 classes VoitureBleue, VoitureRouge et VoitureVerte qui héritent de
Voiture
Solution 2 : Composition
 Créer une classe Voiture et une classe Couleur (énumération)
 Créer une association entre Voiture et Couleur
Comment représenter ces 2 solutions en UML?
Quelle solution choisissez-vous ?
Et si on veut modéliser le fait qu’il y a des personnes hommes et des personnes
femmes ?
40 II. Diagrammes de classes
16. Classes abstraites
Qu’est-ce qu’une classe abstraite ?
 Classe qui ne peut être instanciée: Sert uniquement de super classe à
d'autres classes
 Contient des opérations non définies (pour garantir que toutes les classes filles aient
ces méthodes) :
 abstract (Java) ou virtual (C++)
 Doit être spécialisée en une ou plusieurs classes non abstraites
 Notation : mot clé {abstract} ou nom en italique
Pourquoi des classes abstraites ?
 Spécifier un comportement commun à plusieurs classes
 Manipuler des instances de classes différentes de façon uniforme
 Polymorphisme
Bonne pratique :
Dans une hiérarchie d’héritage, les classes qui ne sont pas des feuilles sont
généralement abstraites
41 II. Diagrammes de classes
16. Classes abstraites
Exemple
42 II. Diagrammes de classes
17. Interface
Qu’est-ce qu’une interface ?
 Classe sans attribut dont toutes les opérations sont abstraites
 Ne peut être instanciée
 Doit être réalisée (implémentée) par des classes non abstraites
 Peut hériter d’une autre interface
Pourquoi des interfaces ?
 Utilisation similaire aux classes abstraites
 En Java : une classe ne peut hériter de plus d’une classe, mais elle peut
réaliser plusieurs interfaces
43 II. Diagrammes de classes
17. Interface
Exemple

 Les méthodes egal() et superieur() sont abstraites.

 Les méthodes abstraites doivent être implémentées dans chaque
réalisation de Comparable.
44 II. Diagrammes de classes
17. Interface
Classe cliente d’une interface
 Quand une classe dépend d'une interface pour réaliser ses opérations,
elle est dite classe cliente de l'interface
 On utilise une relation de dépendance entre la classe cliente et
l'interface requise

 Toute classe implémentant l'interface pourra être utilisée - principe de

substitution
45 II. Diagrammes de classes
18. Synthèse des différentes relations
 Association
 Navigable dans les 2 sens : ——————
 Navigable dans un sens : ——————>
ou –X—————>
 Composition : ——————
 Agrégation : ——————
 Généralisation : ——————
 Réalisation d’une interface : ——————O ou - - - - - - - - - - - -
 Utilisation d’une interface : ——————C ou - - - - «use» - - - - >
 Intanciation d’une classe générique : - - - - «bind» (Type) - - - - >
 Dépendance : - - - - - - - - - - - - >
46 II. Diagrammes de classes
18. Synthèse des différentes relations

Association Association Agrégation Composition

bidirectionnelle unidirectionnelle (Composition faible) (Composition forte)
47 II. Diagrammes de classes
18. Synthèse des différentes relations

Héritage Relation
Dépendance
d’Interface
48 II. Diagrammes de classes
19. Applications
Cherchez l’erreur (1/3)

Navigabilité : Tout objet doit être accessible via une association

49 II. Diagrammes de classes
19. Applications
Cherchez l’erreur (2/3)

 Eviter les associations redondantes :

 Le vol d’un bagage est obtenu à partir du passager
 Les bagages d’un vol sont obtenus à partir des passagers
 Possibilité de spécifier que l’association Bagage-Vol est dérivée...
50 II. Diagrammes de classes
19. Applications
Cherchez l’erreur (3/3)

Navigabilité : En l’absence de réservations, on ne peut accéder ni aux

chambres ni aux clients