Vous êtes sur la page 1sur 89

La modélisation structurelle avec les

diagrammes de classes
ACDA – CPOO (M3105)

Mathieu Sassolas

IUT de Sénart Fontainebleau


Département Informatique

Année 2015-2016
Cours 3
Plan de la séance — En image

Classes

M. Sassolas
M3105
Aspects Aspects Aspects
Cours 3
fonctionnels statiques dynamiques
Programme Abstrait
Scénarios, diag.
Classes & Diag de cas de séquence
objets
Modèle des besoins
d’utilisations système
Associations

Héritage
Diag. de classes
Modèle d’analyse d’analyse, de Diag.
Dépendance paquetage d’activités
Interfaces

Analyse vs Diag. de Diag. d’états,


conception
Modèle de conception
classes métier de séquence
Paquetages

Diag. de
Modèle de déploiement
déploiement
Concret

2 / 50
Plan de la séance — En image

Classes

M. Sassolas
M3105
Aspects Aspects Aspects
Cours 3
fonctionnels statiques dynamiques
Programme Abstrait
Scénarios, diag.
Classes & Diag de cas de séquence
objets
Modèle des besoins
d’utilisations système
Associations

Héritage
Diag. de classes
Modèle d’analyse d’analyse, de Diag.
Dépendance paquetage d’activités
Interfaces

Analyse vs Diag. de Diag. d’états,


conception
Modèle de conception
classes métier de séquence
Paquetages

Diag. de
Modèle de déploiement
déploiement
Concret

2 / 50
Plan de la séance — En image

Classes

M. Sassolas
M3105
Aspects Aspects Aspects
Cours 3
fonctionnels statiques dynamiques
Programme Abstrait
Scénarios, diag.
Classes & Diag de cas de séquence
objets
Modèle des besoins
d’utilisations système
Associations

Héritage
Diag. de classes
Modèle d’analyse d’analyse, de Diag.
Dépendance paquetage d’activités
En bonus
Interfaces

Analyse vs Diag. de Diag. d’états,


conception
Modèle de conception
classes métier de séquence
Paquetages

Diag. de
Modèle de déploiement
déploiement
Concret

2 / 50
Plan de la séance

Classes

M. Sassolas 1 Programme
M3105

Cours 3
2 Classes & objets (révision IS2)
Programme

Classes & 3 Associations entre les classes


objets

Associations
4 Héritage
Héritage

Dépendance 5 Dépendance
Interfaces

Analyse vs
conception
6 Dépendance + Réalisation = Interface
Paquetages
7 Analyse vs conception

8 Paquetages
3 / 50
Plan de la séance

Classes

M. Sassolas 1 Programme
M3105

Cours 3
2 Classes & objets (révision IS2)
Programme

Classes & 3 Associations entre les classes


objets

Associations
4 Héritage
Héritage

Dépendance 5 Dépendance
Interfaces

Analyse vs
conception
6 Dépendance + Réalisation = Interface
Paquetages
7 Analyse vs conception

8 Paquetages
4 / 50
Les objets
Selon Wikipédia (fr)

Classes

M. Sassolas
M3105

Cours 3

Programme

Classes &
objets

Associations

Héritage

Dépendance

Interfaces

Analyse vs
conception
I En programmation informatique un objet est un conteneur
Paquetages
logiciel qui contient les informations et les mécanismes en
rapport avec un objet concret ou abstrait. La programmation
orientée objet est un style d’écriture de programme informatique
basé sur des métaphores d’entités dont les caractéristiques sont
5 / 50
manipulées ou simulées par informatique.
Les objets
Selon Wikipédia (fr)

Classes
I Une entité (une chose) définie dans un espace à trois
M. Sassolas dimensions, soit naturelle, soit fabriquée par l’homme (un
M3105

Cours 3
artefact ou un produit de fabrication industrielle), qui a une
fonction précise, désignable par une étiquette verbale (un nom).
Programme
[...]
Classes &
objets I Par ailleurs, certains objets sont incorporels (càd. qu’ils ne sont
Associations pas ‘objet’ des sens) : créations de l’esprit, idéalités, concepts,
Héritage fantaisies, fictions, constructions mathématiques, classes ou
Dépendance catégories, définitions universelles, but poursuivi, et cetera. Ces
Interfaces objets manquent de concrétude, mais sont, pourtant, les uns
Analyse vs réels, les autres irréels.[...]
conception
I En programmation informatique un objet est un conteneur
Paquetages
logiciel qui contient les informations et les mécanismes en
rapport avec un objet concret ou abstrait. La programmation
orientée objet est un style d’écriture de programme informatique
basé sur des métaphores d’entités dont les caractéristiques sont
5 / 50
manipulées ou simulées par informatique.
Les objets
Selon Wikipédia (fr)

Classes
I Une entité (une chose) définie dans un espace à trois
M. Sassolas dimensions, soit naturelle, soit fabriquée par l’homme (un
M3105

Cours 3
artefact ou un produit de fabrication industrielle), qui a une
fonction précise, désignable par une étiquette verbale (un nom).
Programme
[...]
Classes &
objets I Par ailleurs, certains objets sont incorporels (càd. qu’ils ne sont
Associations pas ‘objet’ des sens) : créations de l’esprit, idéalités, concepts,
Héritage fantaisies, fictions, constructions mathématiques, classes ou
Dépendance catégories, définitions universelles, but poursuivi, et cetera. Ces
Interfaces objets manquent de concrétude, mais sont, pourtant, les uns
Analyse vs réels, les autres irréels.[...]
conception
I En programmation informatique un objet est un conteneur
Paquetages
logiciel qui contient les informations et les mécanismes en
rapport avec un objet concret ou abstrait. La programmation
orientée objet est un style d’écriture de programme informatique
basé sur des métaphores d’entités dont les caractéristiques sont
5 / 50
manipulées ou simulées par informatique.
Les objets
Selon Wikipédia (fr)

Classes
I Une entité (une chose) définie dans un espace à trois
M. Sassolas dimensions, soit naturelle, soit fabriquée par l’homme (un
M3105

Cours 3
artefact ou un produit de fabrication industrielle), qui a une
fonction précise, désignable par une étiquette verbale (un nom).
Programme
[...]
Classes &
objets I Par ailleurs, certains objets sont incorporels (càd. qu’ils ne sont
Associations pas ‘objet’ des sens) : créations de l’esprit, idéalités, concepts,
Héritage fantaisies, fictions, constructions mathématiques, classes ou
Dépendance catégories, définitions universelles, but poursuivi, et cetera. Ces
Interfaces objets manquent de concrétude, mais sont, pourtant, les uns
Analyse vs réels, les autres irréels.[...]
conception
I En programmation informatique un objet est un conteneur
Paquetages
logiciel qui contient les informations et les mécanismes en
rapport avec un objet concret ou abstrait. La programmation
orientée objet est un style d’écriture de programme informatique
basé sur des métaphores d’entités dont les caractéristiques sont
5 / 50
manipulées ou simulées par informatique.
Les objets
Dans la programmation objet

Classes
I Représentation logique d’un conteneur.
M. Sassolas
M3105 I Une abstraction d’un état de mémoire du programme.
Cours 3
I Une abstraction des pointeurs internes à cet état de
Programme
mémoire.
Classes &
objets I Représenté par des boı̂tes reliées entre elles :
Associations

Héritage

Dépendance

Interfaces

Analyse vs
conception

Paquetages

6 / 50
Les classes

Classes

M. Sassolas
M3105
I Un manière de générer des objets ayant tous la même
Cours 3 forme : un « moule » pour nos « boı̂tes ».
Programme

Classes &
objets

Associations I Ici « la forme suit la fonction » (“form follows function”),


Héritage donc des objets de même classe auront la même fonction :
Dépendance classe ∼ type.
Interfaces

Analyse vs
conception

Paquetages

7 / 50
Les classes

Classes

M. Sassolas
M3105
I Un manière de générer des objets ayant tous la même
Cours 3 forme : un « moule » pour nos « boı̂tes ».
Programme I Une classe est donc la donnée des attributs (avec leur
Classes & type) dont seront dotés les objets instance de cette classe.
objets

Associations I Ici « la forme suit la fonction » (“form follows function”),


Héritage donc des objets de même classe auront la même fonction :
Dépendance classe ∼ type.
Interfaces I Un type sans fonctions l’utilisant est peu utile.
Analyse vs
conception
• Il faut donner des fonctions qui utilisent les objets.
Paquetages
• Certaines fonctions agissent sur l’objet lui même : les
opérations.
• Il peut bien sûr exister des fonctions prenant de tels objets
en arguments.
7 / 50
Visibilité

Classes I Détermine ce que l’on peut voir (pour les attributs) ou


M. Sassolas utiliser (pour les opérations) depuis l’extérieur de la classe.
M3105

Cours 3
I Exemple : lorsqu’un objet est passé en argument d’une
Programme
fonction, on est à l’extérieur ; lorsqu’on est dans le code
Classes &
d’une opération de cette même classe, on est à l’intérieur.
objets

Associations

Héritage

Dépendance

Interfaces

Analyse vs
conception

Paquetages

8 / 50
Visibilité

Classes I Détermine ce que l’on peut voir (pour les attributs) ou


M. Sassolas utiliser (pour les opérations) depuis l’extérieur de la classe.
M3105

Cours 3
I Exemple : lorsqu’un objet est passé en argument d’une
Programme
fonction, on est à l’extérieur ; lorsqu’on est dans le code
Classes &
d’une opération de cette même classe, on est à l’intérieur.
objets I Les différentes visibilités :
Associations – Privé : visible uniquement depuis l’intérieur.
Héritage + Public : visible depuis l’extérieur.
Dépendance # Protégé : visible depuis l’intérieur et depuis l’intérieur
Interfaces d’objets de classe héritant.
Analyse vs ∼ Paquetage : visible seulement depuis les autres objets
conception définis dans le paquetage.
Paquetages

8 / 50
Visibilité

Classes I Détermine ce que l’on peut voir (pour les attributs) ou


M. Sassolas utiliser (pour les opérations) depuis l’extérieur de la classe.
M3105

Cours 3
I Exemple : lorsqu’un objet est passé en argument d’une
Programme
fonction, on est à l’extérieur ; lorsqu’on est dans le code
Classes &
d’une opération de cette même classe, on est à l’intérieur.
objets I Les différentes visibilités :
Associations – Privé : visible uniquement depuis l’intérieur.
Héritage + Public : visible depuis l’extérieur.
Dépendance # Protégé : visible depuis l’intérieur et depuis l’intérieur
Interfaces d’objets de classe héritant.
Analyse vs ∼ Paquetage : visible seulement depuis les autres objets
conception définis dans le paquetage.
Paquetages

En règle générale
Les attributs seront privés (à la rigueur protégés),
8 / 50 les opérations seront publiques.
Éléments de classe

Classes

M. Sassolas Propriété « statique » (static)


M3105

Cours 3
L’élément est relatif à la classe et non
Programme
aux objets instance de cette classe.
Classes &
objets I Concerne les attributs comme les opérations.
Associations I Pour les attributs, utile pour spécifier des constantes.
Héritage
I Pour les opérations, utile pour spécifier des opérations qui
Dépendance
sont logiquement dans cette classe mais qui n’agissent pas
Interfaces
sur des objets : sous-routines, comparaisons d’objets de
Analyse vs
conception cette classe. . .
Paquetages I Un élément static apparaı̂t souligné.

9 / 50
Éléments de classe

Classes

M. Sassolas Propriété « statique » (static)


M3105

Cours 3
L’élément est relatif à la classe et non
Programme
aux objets instance de cette classe.
Classes &
objets I Concerne les attributs comme les opérations.
Associations I Pour les attributs, utile pour spécifier des constantes.
Héritage
I Pour les opérations, utile pour spécifier des opérations qui
Dépendance
sont logiquement dans cette classe mais qui n’agissent pas
Interfaces
sur des objets : sous-routines, comparaisons d’objets de
Analyse vs
conception cette classe. . .
Paquetages I Un élément static apparaı̂t souligné.

Ne pas confondre avec les clefs primaires utilisées


9 / 50 pour la modélisation de bases de données.
Autres propriétés des attributs

Classes
Dérivé Qui
peut être calculé.
M. Sassolas
M3105 IConcerne uniquement les attributs.
Cours 3
IIndiqué par un symbole /
Programme IUtile si l’attribut est important, utilisé
Classes &
objets
souvent, calculable mais à grand coût. . .
Associations
I Exemple : -/ ^ age est calculable depuis
Héritage - dateNaissance.
Dépendance Cardinalité Les attributs peuvent avoir une multiplicité.
Interfaces
I Exemple : - autresPrenoms[0..3].
Analyse vs
conception I Plus d’infos sur les cardinalités lorsqu’on
Paquetages parlera des associations.
Valeur par défaut Indiquée par = valeur.
Type énumération Type (anonyme) qui a un nombre fini de
10 / 50 valeur possibles : - jour: {‘Lundi’,... }.
Représentation graphique des classes

Classes

M. Sassolas
M3105

Cours 3

Classe
Programme

Classes & – attribut1 : Type1 = valeur


objets
# attribut2[0..1] : Type2
Associations
–/ attribut3 : Type3
Héritage
– attribut4 : Type4
Dépendance
∼ attribut5 : {val1,val2}
Interfaces

Analyse vs + opération(arg : TypeArg)


conception
+ routine(arg : Classe) : Type
Paquetages

11 / 50
Plan de la séance

Classes

M. Sassolas 1 Programme
M3105

Cours 3
2 Classes & objets (révision IS2)
Programme

Classes & 3 Associations entre les classes


objets

Associations
4 Héritage
Héritage

Dépendance 5 Dépendance
Interfaces

Analyse vs
conception
6 Dépendance + Réalisation = Interface
Paquetages
7 Analyse vs conception

8 Paquetages
12 / 50
Association simple

Classes

M. Sassolas ClasseA
M3105
I Lorsqu’un attribut a pour
Cours 3
– attributA : TypeA
type une classe présente sur le
Programme – monB : ClasseB
Classes &
diagramme, on explicite cette
objets relation par une association.
Associations

Héritage

Dépendance

Interfaces

Analyse vs ClasseB
conception

Paquetages – attributB : TypeB


– monA : ClasseA

13 / 50
Association simple

Classes

M. Sassolas
M3105 ClasseA
Cours 3
I Lorsqu’un attribut a pour
– attributA : TypeA type une classe présente sur le
Programme

Classes &
diagramme, on explicite cette
objets relation par une association.
Associations
–monA
Héritage

Dépendance

Interfaces
–monB
Analyse vs
conception ClasseB
Paquetages
– attributB : TypeB

13 / 50
Association simple

Classes

M. Sassolas
M3105 ClasseA
Cours 3
I Lorsqu’un attribut a pour
– attributA : TypeA type une classe présente sur le
Programme

Classes &
diagramme, on explicite cette
objets relation par une association.
Associations
–monA
I On peut nommer l’association
Héritage
associe pour expliciter la nature de la
Dépendance

Interfaces
–monB relation.
Analyse vs
conception ClasseB
Paquetages
– attributB : TypeB

13 / 50
Association simple

Classes

M. Sassolas
M3105 ClasseA
Cours 3
I Lorsqu’un attribut a pour
– attributA : TypeA type une classe présente sur le
Programme

Classes &
diagramme, on explicite cette
objets relation par une association.
Associations
–monA
I On peut nommer l’association
Héritage
associe pour expliciter la nature de la
Dépendance

Interfaces
–monB relation.
Analyse vs I Une association fournit donc
conception ClasseB
ces attributs implicites dont le
Paquetages
– attributB : TypeB nom est fourni par les rôles.

13 / 50
Association simple

Classes

M. Sassolas
M3105 ClasseA
Cours 3
I Lorsqu’un attribut a pour
– attributA : TypeA type une classe présente sur le
Programme

Classes &
diagramme, on explicite cette
objets relation par une association.
Associations
–monA
I On peut nommer l’association
Héritage
associe pour expliciter la nature de la
Dépendance

Interfaces
–monB relation.
Analyse vs I Une association fournit donc
conception ClasseB
ces attributs implicites dont le
Paquetages
– attributB : TypeB nom est fourni par les rôles.
Les rôles ont une visibilité.

13 / 50
Cardinalités

Classes

M. Sassolas
M3105 ClasseA I Indique le nombre d’objets qui
Cours 3

– attributA : TypeA peuvent être ainsi associés.


Programme
I Syntaxe : intervalle x..y ,
Classes &
objets point x, arbitrairement ∗.
1..* –monA
Associations I Les plus utilisés :
Héritage
1 Unique (par défaut).
Dépendance
0..1 Optionnel.
0..1 –monB
Interfaces 1..* Au moins un.
Analyse vs
conception ClasseB * Autant que l’on veut
(potentiellement 0).
Paquetages
– attributB : TypeB
I Les rôles s’entendent comme
l’ensemble des objets associés.

14 / 50
Navigabililité

Classes

M. Sassolas
M3105 ClasseA
Cours 3

– attributA : TypeA
Programme

Classes &
objets
I Indique que l’accès ne se fait
Associations pas dans les deux sens.
Héritage I On remarque qu’il n’y a donc
Dépendance plus de rôle monA.
Interfaces
–monB
Analyse vs
conception ClasseB
Paquetages
– attributB : TypeB

15 / 50
Navigabililité

Classes

M. Sassolas ClasseA
M3105

Cours 3
– attributA : TypeA
Programme –monB : ClasseB
Classes &
objets
I Indique que l’accès ne se fait
Associations pas dans les deux sens.
Héritage I On remarque qu’il n’y a donc
Dépendance plus de rôle monA.
Interfaces

Analyse vs
conception ClasseB
Paquetages
– attributB : TypeB

15 / 50
Navigabililité

Classes

M. Sassolas
M3105 ClasseA
Cours 3

– attributA : TypeA
Programme

Classes &
objets
I Indique que l’accès ne se fait
Associations pas dans les deux sens.
Héritage I On remarque qu’il n’y a donc
Dépendance plus de rôle monA.
Interfaces
–monB
I Par défaut : la navigabilité est
Analyse vs
conception ClasseB bidirectionnelle.
Paquetages
– attributB : TypeB

15 / 50
Agrégation

Classes

M. Sassolas
M3105 Agrégat
Cours 3

– attributA : TypeA I Un raccourci pour la notion


Programme

Classes & d’ensemble.


objets

Associations
1..* –monA
Héritage

Dépendance

Interfaces * –monB
Analyse vs
conception Agrégé
Paquetages
– attributB : TypeB

16 / 50
Agrégation

Classes

M. Sassolas
M3105 Agrégat
Cours 3

– attributA : TypeA I Un raccourci pour la notion


Programme

Classes & d’ensemble.


objets

Associations
1..* –monA I L’agrégat est formée des
Héritage objets agrégés.
Dépendance I Un objet peut appartenir à
* –monB
Interfaces
plusieurs agrégats.
Analyse vs
conception Agrégé I Détruire un agrégat ne détruit
Paquetages
– attributB : TypeB pas les agrégés.

16 / 50
Agrégation — Exemple
Le diagramme de classes

Classes

M. Sassolas
M3105 Club Équipe nationale
Cours 3

– nom : String – pays : Pays


Programme

Classes &
objets
–club
Associations 0..1
Héritage

Dépendance
* –joueurs
Interfaces

Analyse vs Joueur
conception
–joueurs
Paquetages – nom : String
–prénom : String 30

17 / 50
Agrégation — Exemple
Le diagramme objets

Classes

M. Sassolas stadeToulousain: Club dusautoir: Joueur


M3105

Cours 3
nom = « Stade Toulousain » nom = « Dusautoir »
Programme
joueurs = {dusautoir, tolofua, . . . } prénom = « Thierry »
Classes &
club = stadeToulousain
objets

Associations

Héritage

Dépendance
xvFrance: Équipe nationale
Interfaces pays = france
Analyse vs
conception
joueurs = {dusautoir, kayser, . . . }
Paquetages

18 / 50
Agrégation — Exemple
Le diagramme objets

Classes

M. Sassolas stadeToulousain: Club dusautoir: Joueur


M3105

Cours 3
nom = « Stade Toulousain » nom = « Dusautoir »
Programme
joueurs = {dusautoir, tolofua, . . . } prénom = « Thierry »
Classes &
club = stadeToulousain
objets

Associations

Héritage

Dépendance
xvFrance: Équipe nationale
Interfaces pays = france
Analyse vs
conception
joueurs = {dusautoir, kayser, . . . }
Paquetages

I Détruire une équipe ne détruit pas un joueur.


I Un joueur peut appartenir à plusieurs équipes.
18 / 50
Composition

Classes

M. Sassolas
M3105 Composite
Cours 3 I Un raccourci pour la notion
– attributA : TypeA de partie.
Programme

Classes &
objets

Associations
1 –monA
Héritage

Dépendance

Interfaces * –monB
Analyse vs
conception Composant
Paquetages
– attributB : TypeB

19 / 50
Composition

Classes

M. Sassolas
M3105 Composite
Cours 3 I Un raccourci pour la notion
– attributA : TypeA de partie.
Programme

Classes &
objets
I Le composite est formée des
Associations
1 –monA objets composants.
Héritage I Un objet ne peut appartenir
Dépendance qu’à un seul composite :
* –monB
Interfaces
cardinalité 1 ou 0..1
Analyse vs
conception Composant seulement.
Paquetages
– attributB : TypeB I Détruire un composite signifie
détruire ses composants

19 / 50
Composition — Exemple
Le diagramme de classes

Classes

M. Sassolas Forêt Feuille


M3105

Cours 3 – nom : String – couleur : CouleurRVB


Programme

Classes & –feuilles *


objets 0..1 –forêt
Associations

Héritage

Dépendance * –arbres
Interfaces
–parent
Analyse vs
Branche 1
conception

Paquetages
– diamètre : int

–parent –sousbranches
0..1 *
20 / 50
Composition — Exemple
Le diagramme objets

Classes
fontainebleau: Forêt
M. Sassolas
M3105 nom = « Forêt Domaniale de Fontainebleau »
Cours 3

Programme

Classes & tronc: Branche br1: Branche


objets

Associations
diamètre = 450 diamètre = 112
Héritage

Dépendance
br2: Branche feuille: Feuille
Interfaces

Analyse vs
diamètre = 214 couleur = orange
conception

Paquetages

21 / 50
Composition — Exemple
Le diagramme objets

Classes
fontainebleau: Forêt
M. Sassolas
M3105 nom = « Forêt Domaniale de Fontainebleau »
Cours 3

Programme

Classes & tronc: Branche br1: Branche


objets

Associations
diamètre = 450 diamètre = 112
Héritage

Dépendance
br2: Branche feuille: Feuille
Interfaces

Analyse vs
diamètre = 214 couleur = orange
conception

Paquetages

I Chaque branche a un seul parent.


I Si l’on abat le tronc, toutes les sous-branches meurent.
21 / 50
Si l’on abat une forêt, tous les arbres sont coupés.
Mais si on code ?
Cardinalités, agrégations et compositions dans le code

Classes

M. Sassolas
M3105 I Des cardinalités * impliquent souvent que l’attribut est un
Cours 3 ensemble : collection, liste, tableau. . .
Programme ,→ Il faut souvent avoir les accesseurs ad-hoc pour modifier
Classes & ces ensembles :
objets

Associations
• il est utile de nommer le get adéquatement : getListe. . .
• insérer, supprimer au lieu du set habituel.
Héritage

Dépendance C’est souvent le cas avec des agrégations ou compositions.


Interfaces

Analyse vs
conception

Paquetages

22 / 50
Mais si on code ?
Cardinalités, agrégations et compositions dans le code

Classes

M. Sassolas
M3105 I Des cardinalités * impliquent souvent que l’attribut est un
Cours 3 ensemble : collection, liste, tableau. . .
Programme ,→ Il faut souvent avoir les accesseurs ad-hoc pour modifier
Classes & ces ensembles :
objets

Associations
• il est utile de nommer le get adéquatement : getListe. . .
• insérer, supprimer au lieu du set habituel.
Héritage

Dépendance C’est souvent le cas avec des agrégations ou compositions.


Interfaces I Il n’y a pas vraiment moyen de contrôler la différence entre
Analyse vs
conception
agrégation et composition dans le code : le code effectué à
Paquetages la destruction du composite doit se charger de détruire le
composant (si on veut être propre, autrement il y a les
garbage-collectors. . .).
22 / 50
Associations n-aires

Classes I Dans le cas de diagrammes de classe d’analyse, on peut


M. Sassolas envisager des relations n-aires.
M3105

Cours 3
I Au sens mathématique : n-uplet d’objets instances des
Programme
classes liées : (x1 , . . . , xn ) ∈ X1 × · · · × Xn .
Classes &
objets

Associations

Héritage

Dépendance

Interfaces

Analyse vs
conception

Paquetages

23 / 50
Associations n-aires

Classes I Dans le cas de diagrammes de classe d’analyse, on peut


M. Sassolas envisager des relations n-aires.
M3105

Cours 3
I Au sens mathématique : n-uplet d’objets instances des
Programme
classes liées : (x1 , . . . , xn ) ∈ X1 × · · · × Xn .
Classes &
objets
Équipe nationale
Associations

Héritage

Dépendance
domicile visiteur
Interfaces
arbitre lieu
Analyse vs Arbitres Stade
conception

Paquetages
Match

23 / 50
Associations n-aires

Classes I Dans le cas de diagrammes de classe d’analyse, on peut


M. Sassolas envisager des relations n-aires.
M3105

Cours 3
I Au sens mathématique : n-uplet d’objets instances des
Programme
classes liées : (x1 , . . . , xn ) ∈ X1 × · · · × Xn .
Classes &
objets
Équipe nationale
Associations

Héritage
domicile visiteur
Dépendance

Interfaces
arbitre lieu
Analyse vs Arbitres Match Stade
conception

Paquetages

Les associations n-aires ne sont pas obligatoires, et


23 / 50 peuvent souvent être remplacées par une classe.
Classes d’association

Classes I Lorsque l’association entre deux classes dispose elle même


M. Sassolas d’attributs (voire d’opérations).
M3105

Cours 3
I Les instances de cette classe n’existent que lorsque
Programme
l’association existe.
Classes &
I Modélisent les informations relatives à l’interaction.
objets

Associations

Héritage
Billet
Dépendance
prix : int Vol
Interfaces Passager
Analyse vs imprimer() numero : String
conception nom : String de : Aéroport
Paquetages prénom : String vers : Aéroport
compte fidelité : int départ : Date
créditer(pts : int) arrivée : Date
24 / 50
Mais si on code ?
Associations n-aires et classes d’associations dans le code

Classes I Les classes d’association ou les associations n-aires n’ont


M. Sassolas pas de pendant dans les langages objets.
M3105

Cours 3
I On replace l’association n-aire par une classe sans autre
Programme
attribut que ses associations.
Classes &
objets

Associations

Héritage Billet
Dépendance

Interfaces
prix : int Vol
Passager
Analyse vs
conception
imprimer() numero : String
nom : String de : Aéroport
Paquetages
prénom : String vers : Aéroport
compte fidelité : int départ : Date
créditer(pts : int) arrivée : Date
25 / 50
Mais si on code ?
Associations n-aires et classes d’associations dans le code

Classes I Les classes d’association ou les associations n-aires n’ont


M. Sassolas pas de pendant dans les langages objets.
M3105

Cours 3
I On replace l’association n-aire par une classe sans autre
Programme
attribut que ses associations.
Classes &
I On remplace l’association disposant d’une classe par deux
objets associations vers la classe d’association :
Associations

Héritage Billet
Dépendance

Interfaces
prix : int Vol
Passager
Analyse vs
conception
imprimer() numero : String
nom : String de : Aéroport
Paquetages
prénom : String vers : Aéroport
compte fidelité : int départ : Date
créditer(pts : int) arrivée : Date
25 / 50
Plan de la séance

Classes

M. Sassolas 1 Programme
M3105

Cours 3
2 Classes & objets (révision IS2)
Programme

Classes & 3 Associations entre les classes


objets

Associations
4 Héritage
Héritage

Dépendance 5 Dépendance
Interfaces

Analyse vs
conception
6 Dépendance + Réalisation = Interface
Paquetages
7 Analyse vs conception

8 Paquetages
26 / 50
Héritage

Classes

M. Sassolas Pourquoi ?
M3105

Cours 3 Factoriser pour en écrire le moins possible.


Programme

Classes &
objets

Associations Ancêtre Descendant


Héritage

Dépendance
#attr : Type –newAttr : TypeBis
Interfaces +op() : Type
Analyse vs
conception

Paquetages

27 / 50
Héritage

Classes

M. Sassolas Pourquoi ?
M3105

Cours 3 Factoriser pour en écrire le moins possible.


Programme

Classes &
objets

Associations Ancêtre Descendant


Héritage

Dépendance
#attr : Type –newAttr : TypeBis
Interfaces +op() : Type
Analyse vs
conception

Paquetages
obj: Descendant
attr = valeur
newAttr = newValeur
27 / 50
Remarques sur l’héritage

Classes I On hérite de tous les attributs même implicites


M. Sassolas associations.
M3105

Cours 3
I On hérite des opérations mais elle peuvent être redéfinies
Programme
(override) polymorphisme : l’opération de l’ancêtre
Classes &
prend plusieurs forme dans les objets hérités.
objets
I On peut hériter d’une classe héritant. . .
Associations
I On peut hériter de plusieurs classes à la fois :
Héritage

Dépendance
Avion Bateau Voiture
Interfaces

Analyse vs
conception

Paquetages
Hydravion Hydroglisseur

28 / 50 Soyez prudents, cela ne fonctionne pas toujours dans le code.


Classes et opérations abstraites

Classes

M. Sassolas Une classe abstraite n’est jamais instanciée.


M3105

Cours 3

Programme
I Le but est uniquement d’en hériter.
Classes & I Le nom de la classe apparaı̂t en italique.
objets ClasseAbs
Associations

Héritage

Dépendance

Interfaces

Analyse vs
conception

Paquetages

29 / 50
Classes et opérations abstraites

Classes

M. Sassolas Une classe abstraite n’est jamais instanciée.


M3105

Cours 3

Programme
I Le but est uniquement d’en hériter.
Classes & I Le nom de la classe apparaı̂t en italique. «abstract»
objets
I À la main on indique le stéréotype ClasseAbs
Associations

Héritage <<abstract>>.
Dépendance

Interfaces

Analyse vs
conception

Paquetages

29 / 50
Classes et opérations abstraites

Classes

M. Sassolas Une classe abstraite n’est jamais instanciée.


M3105

Cours 3

Programme
I Le but est uniquement d’en hériter.
Classes & I Le nom de la classe apparaı̂t en italique. «abstract»
objets
I À la main on indique le stéréotype ClasseAbs
Associations

Héritage <<abstract>>.
Dépendance

Interfaces Une opération abstraite doit être


Analyse vs
conception
redéfinie dans les classes héritant.
Paquetages
I Le nom de l’opération apparaı̂t
Classe
en italique.

29 / 50 +opAbs()
Classes et opérations abstraites

Classes

M. Sassolas Une classe abstraite n’est jamais instanciée.


M3105

Cours 3

Programme
I Le but est uniquement d’en hériter.
Classes & I Le nom de la classe apparaı̂t en italique. «abstract»
objets
I À la main on indique le stéréotype ClasseAbs
Associations

Héritage <<abstract>>.
Dépendance

Interfaces Une opération abstraite doit être


Analyse vs
conception
redéfinie dans les classes héritant.
Paquetages
I Le nom de l’opération apparaı̂t
Classe
en italique.
I À la main on indique le
29 / 50 « abstract » +opAbs()
stéréotype <<abstract>>.
Attention au vocabulaire

Classes

M. Sassolas Pour l’implémentation (et l’APL. . .)


M3105

Cours 3 Chaque langage de programmation


Programme utilise un vocabulaire différent.
Classes &
objets

Associations
I En Java :
Héritage
• Une opération abstraite reste une opération abstraite.
Dépendance
• Une classe dont une opération est abstraite est abstract.
• Une classe abstract de Java pourrait être instanciée.
Interfaces
• On peut simuler une classe abstraite sans attributs par une
Analyse vs
conception interface plus de détails sur l’interface plus tard.
Paquetages I En C++ :
• Une opération abstraite est appelée virtuelle pure.
• Une classe dont une opération est virtuelle pure est
abstraite.
30 / 50 • Une classe abstraite est appelée une interface.
Exemple d’héritage

Classes

M. Sassolas Personne
M3105

Cours 3 –nom : String Patient


Programme
–prénom : String –numsecu : int
Classes &
#dateNaissance : Date
objets

Associations
+getNomComplet() : String
Héritage

Dépendance
Médecin
Interfaces

Analyse vs
conception Soignant
Infirmier
Paquetages
–matricule : int
+calculerSalaire() : int
Aide-soignant
31 / 50
Retour sur la visibilité « protégé »

Classes

M. Sassolas
M3105

Cours 3

Programme I Les attributs (et opérations) protégés sont visibles par


Classes & suite d’héritage : dateNaissance est visible dans la classe
objets
Médecin.
Associations

Héritage
I Lorsqu’une classe a vocation à être héritée, il faut se poser
Dépendance
la question du privé vs protégé.
Interfaces • Si un accesseur a vocation à être redéfini, choisir protégé.
Analyse vs
• Sinon, choisir privé, la classe héritant utilisera si besoin les
conception accesseurs définis dans la classe mère.
Paquetages

32 / 50
Plan de la séance

Classes

M. Sassolas 1 Programme
M3105

Cours 3
2 Classes & objets (révision IS2)
Programme

Classes & 3 Associations entre les classes


objets

Associations
4 Héritage
Héritage

Dépendance 5 Dépendance
Interfaces

Analyse vs
conception
6 Dépendance + Réalisation = Interface
Paquetages
7 Analyse vs conception

8 Paquetages
33 / 50
Dépendances

Classes
I Pour modéliser des liens logiques entre les classes.
M. Sassolas
M3105
I Une classe A dépend d’une classe B si le bon
Cours 3 fonctionnement de A nécessite l’existence (et le bon
Programme fonctionnement) de B.
Classes & I Crée des dépendances dans le code :
objets
• il faut coder la classe B avant ;
Associations • une modification de B peut affecter A (maintenance).
Héritage

Dépendance

Interfaces

Analyse vs
conception

Paquetages

A B
34 / 50
Dépendances

Classes
I Pour modéliser des liens logiques entre les classes.
M. Sassolas
M3105
I Une classe A dépend d’une classe B si le bon
Cours 3 fonctionnement de A nécessite l’existence (et le bon
Programme fonctionnement) de B.
Classes & I Crée des dépendances dans le code :
objets
• il faut coder la classe B avant ;
Associations • une modification de B peut affecter A (maintenance).
Héritage
I Plusieurs cas de dépendance sont possibles :
Dépendance
use utilisation : un objet de classe B est utilisé en
Interfaces
argument d’une opération de A ;
Analyse vs
conception create création/instanciation : la classe A va créer
Paquetages des objets de B ;
call appel : la classe A appelle une opération de B.
<<use>>
A B
34 / 50
Exemple de dépendances

Classes
Block Game
M. Sassolas
M3105 Piece
Cours 3
xpos <<create>>
ypos +next piece() xpos
Programme
+test line() ypos
Classes &
objets
shape : Shape
Associations
<<use>>
+rotate()
Héritage
GameCtrl +lower()
Dépendance

Interfaces

Analyse vs +refresh(g :Game)


conception

Paquetages

35 / 50
Exemple de dépendances

Classes
Block Game
M. Sassolas
M3105 Piece
Cours 3
xpos <<create>>
ypos +next piece() xpos
Programme
+test line() ypos
Classes &
objets
shape : Shape
Associations
<<use>>
+rotate()
Héritage
GameCtrl +lower()
Dépendance

Interfaces

Analyse vs +refresh(g :Game)


conception

Paquetages

Dépendances implicites
L’association, l’héritage. . . ont des dépendance implicites :
35 / 50 pas besoin de les indiquer !
Plan de la séance

Classes

M. Sassolas 1 Programme
M3105

Cours 3
2 Classes & objets (révision IS2)
Programme

Classes & 3 Associations entre les classes


objets

Associations
4 Héritage
Héritage

Dépendance 5 Dépendance
Interfaces

Analyse vs
conception
6 Dépendance + Réalisation = Interface
Paquetages
7 Analyse vs conception

8 Paquetages
36 / 50
Interfaces

Classes

M. Sassolas I Un cas particulier de classes


M3105

Cours 3
abstraites : ClasseTrèsAbstraite
Programme I sans aucun attribut ;
Classes &
I dont toutes les opérations +op1 (. . .)
objets
+op2 (. . .)
Associations sont abstraites.
...
Héritage

Dépendance

Interfaces

Analyse vs
conception

Paquetages

37 / 50
Interfaces

Classes

M. Sassolas I Un cas particulier de classes


M3105 «interface»
Cours 3
abstraites : ClasseTrèsAbstraite
Programme I sans aucun attribut ;
Classes &
objets
I dont toutes les opérations +op1 (. . .)
Associations sont abstraites. +op2 (. . .)
Héritage I On utilise le stéréotype ...
Dépendance <<interface>>.
Interfaces

Analyse vs
conception

Paquetages

37 / 50
Interfaces

Classes

M. Sassolas I Un cas particulier de classes


M3105 «interface»
Cours 3
abstraites : ClasseTrèsAbstraite
Programme I sans aucun attribut ;
Classes &
objets
I dont toutes les opérations +op1 (. . .)
Associations sont abstraites. +op2 (. . .)
Héritage I On utilise le stéréotype ...
Dépendance <<interface>>.
Interfaces

Analyse vs
conception Philosophie
Paquetages
Les classes qui en héritent doivent
implémenter un comportement.

37 / 50
Réalisation

Classes

M. Sassolas Héritage d’interfaces


M3105

Cours 3 I Ce cas particulier est nommé réalisation.


Programme

Classes &
objets

Associations

Héritage
«interface» «interface»
Dépendance Interf1 Interf2
Interfaces

Analyse vs
conception +op1 () +op2 ()
Paquetages

Classe
38 / 50
Réalisation

Classes

M. Sassolas Héritage d’interfaces


M3105

Cours 3 I Ce cas particulier est nommé réalisation.


Programme I Notation : flèche d’héritage pointillée.
Classes &
objets I Il évite l’héritage multiple.
Associations

Héritage
«interface» «interface»
Dépendance Interf1 Interf2
Interfaces

Analyse vs
conception +op1 () +op2 ()
Paquetages

Classe
38 / 50
Réalisation — Exemple

Classes

M. Sassolas
M3105 «interface»
Cours 3 Triable
Programme

Classes &
objets +quicksort()
Associations
+bubblesort()
Héritage ArbreBin Liste
Dépendance
racine : Node tete : Elem
Interfaces

Analyse vs
conception «interface»
Paquetages Printable

+afficher ()
+afficherLaTeX ()
39 / 50
Utilisation d’interfaces

Classes

M. Sassolas ClasseReq
M3105

Cours 3
ClasseImplem
Programme
action(obj : Interface)
Classes & <<use>>
objets

Associations

Héritage «interface»
Dépendance Interface
Interfaces

Analyse vs
conception +opération()
Paquetages

La classe ClasseImplem fournit la capacité de réaliser


l’opération dont ClasseReq a besoin.
40 / 50
Utilisation d’interfaces

Classes

M. Sassolas ClasseReq Interface


M3105

Cours 3
ClasseImplem
Programme
action(obj : Interface)
Classes &
objets

Associations

Héritage
Notation « lollypop »
Dépendance

Interfaces

Analyse vs
conception

Paquetages

La classe ClasseImplem fournit la capacité de réaliser


l’opération dont ClasseReq a besoin.
40 / 50
Exemple d’interfaces

Classes

M. Sassolas
M3105
GestionnaireIU
Cours 3

Fenêtre
Programme

Classes &
+newpopup(cl : Cliquable)
objets

Associations <<use>>
Héritage

Dépendance

Interfaces
«interface»
Analyse vs
Cliquable
conception

Paquetages
+onClick()
+onDoubleClick()

41 / 50
Exemple d’interfaces

Classes

M. Sassolas
M3105
GestionnaireIU Cliquable
Cours 3

Fenêtre
Programme

Classes &
+newpopup(cl : Cliquable)
objets

Associations

Héritage

Dépendance

Interfaces

Analyse vs
conception

Paquetages

41 / 50
Quand utiliser les interfaces ?

Classes

M. Sassolas
M3105

Cours 3

Programme I Les interfaces découpent l’application selon des besoins et


Classes & les fonctionnalités.
objets

Associations I Permet une forme de programmation par contrats.


Héritage I Quand l’héritage concerne les comportements et non les
Dépendance données.
Interfaces
I Permet de factoriser des classes qui n’ont pas forcément
Analyse vs
conception de lien entre elles.
Paquetages

42 / 50
Plan de la séance

Classes

M. Sassolas 1 Programme
M3105

Cours 3
2 Classes & objets (révision IS2)
Programme

Classes & 3 Associations entre les classes


objets

Associations
4 Héritage
Héritage

Dépendance 5 Dépendance
Interfaces

Analyse vs
conception
6 Dépendance + Réalisation = Interface
Paquetages
7 Analyse vs conception

8 Paquetages
43 / 50
Que modélise-t-on ?

Classes

M. Sassolas
M3105

Cours 3

Programme I Le diagramme de classes permet de modéliser la structure


Classes & à différents niveaux de détail, à différentes étapes de la
objets

Associations
modélisation.
Héritage I Les diagrammes d’analyse et de conception sont très
Dépendance différents.
Interfaces
I Un diagramme de classes (sans opérations) peut aussi
Analyse vs
conception modéliser une base de données (cf ACSI IS1).
Paquetages

44 / 50
Diagramme de classes d’analyse

Classes
I Identifier les classes.
M. Sassolas • Un acteur du diagramme de cas d’utilisation n’a pas
M3105
nécessairement de classe le représentant.
Cours 3
• De même, le Système du DCU n’a jamais de classe le
Programme
représentant.
Classes &
objets

Associations

Héritage

Dépendance

Interfaces

Analyse vs
conception

Paquetages

45 / 50
Diagramme de classes d’analyse

Classes
I Identifier les classes.
M. Sassolas • Un acteur du diagramme de cas d’utilisation n’a pas
M3105
nécessairement de classe le représentant.
Cours 3
• De même, le Système du DCU n’a jamais de classe le
Programme
représentant.
Classes &
objets I Ces attributs mérite-t-il d’être rassemblés dans une classe ?
Associations • S’ils représentent un ensemble cohérent ( pas de
Héritage difficulté à trouver un nom à cette classe).
Dépendance • S’ils sont utilisés ailleurs, en particulier par des associations
Interfaces
qui leur sont propres.
Analyse vs
• Si certaines opérations ne concernent que ceux-ci.
conception

Paquetages

45 / 50
Diagramme de classes d’analyse

Classes
I Identifier les classes.
M. Sassolas • Un acteur du diagramme de cas d’utilisation n’a pas
M3105
nécessairement de classe le représentant.
Cours 3
• De même, le Système du DCU n’a jamais de classe le
Programme
représentant.
Classes &
objets I Ces attributs mérite-t-il d’être rassemblés dans une classe ?
Associations • S’ils représentent un ensemble cohérent ( pas de
Héritage difficulté à trouver un nom à cette classe).
Dépendance • S’ils sont utilisés ailleurs, en particulier par des associations
Interfaces
qui leur sont propres.
Analyse vs
• Si certaines opérations ne concernent que ceux-ci.
conception
I Pas besoin de préciser les types.
Paquetages
I On peut utiliser des associations n-aires, des classes
d’associations.
I On limite l’héritage aux classes logiquement liées (quelques
45 / 50 attributs en commun ne font pas toujours un héritage).
Diagramme de classes de conception

Classes

M. Sassolas
M3105

Cours 3 I Partir du diagramme de classe d’analyse : il donne


Programme (presque) les classes du modèle et la structure d’une
Classes &
objets
éventuelle base de données.
Associations I Préciser les types.
Héritage I Ajouter les classes qui ne sont pas métier : vues,
Dépendance
contrôleurs. . .
Interfaces

Analyse vs
I Ne pas hésiter à diviser le diagramme en fonction des
conception différentes parties du système.
Paquetages

46 / 50
Diagramme de classes de conception

Classes

M. Sassolas
M3105

Cours 3 I Partir du diagramme de classe d’analyse : il donne


Programme (presque) les classes du modèle et la structure d’une
Classes &
objets
éventuelle base de données.
Associations I Préciser les types.
Héritage I Ajouter les classes qui ne sont pas métier : vues,
Dépendance
contrôleurs. . .
Interfaces

Analyse vs
I Ne pas hésiter à diviser le diagramme en fonction des
conception différentes parties du système.
Paquetages
I Ensuite factoriser par héritage et interfaces.

46 / 50
Plan de la séance

Classes

M. Sassolas 1 Programme
M3105

Cours 3
2 Classes & objets (révision IS2)
Programme

Classes & 3 Associations entre les classes


objets

Associations
4 Héritage
Héritage

Dépendance 5 Dépendance
Interfaces

Analyse vs
conception
6 Dépendance + Réalisation = Interface
Paquetages
7 Analyse vs conception

8 Paquetages
47 / 50
Diviser le système

Classes
I Séparer le système en parties logiques (presque)
M. Sassolas
M3105
indépendantes.
Cours 3 I Exemple : une partie gère la base de donnée, une partie
Programme gère l’interface graphique, une partie gère le cœur de
Classes & métier. . .
objets
I Permet d’avoir une vue plus haut niveau des diagramme
Associations

Héritage
de classes.
Dépendance I Pratique pour lister les interfaces fournies par un
Interfaces paquetage.
Analyse vs
conception
Paquetage
Paquetages

«interface»
+ ClassePub – ClassePriv
+Interface
48 / 50
Diviser le système

Classes
I Séparer le système en parties logiques (presque)
M. Sassolas
M3105
indépendantes.
Cours 3 I Exemple : une partie gère la base de donnée, une partie
Programme gère l’interface graphique, une partie gère le cœur de
Classes & métier. . .
objets
I Permet d’avoir une vue plus haut niveau des diagramme
Associations

Héritage
de classes.
Dépendance I Pratique pour lister les interfaces fournies par un
Interfaces paquetage.
Analyse vs
conception

Paquetages

48 / 50
Visibilités

Classes
Paquetage
M. Sassolas
M3105

Cours 3
+ ClassePub – ClassePriv
Programme

Classes &
objets I Les classes au sein d’un paquetage peuvent être. . .
Associations + publiques : visibles depuis l’extérieur du paquetage
Héritage (défaut).
Dépendance – privées : invisibles depuis l’extérieur du paquetage.
Interfaces ,→ « Invisible » signifie que l’on ne peut pas l’instancier.
Analyse vs
conception

Paquetages

49 / 50
Visibilités

Classes
Paquetage
M. Sassolas
M3105

Cours 3
+ ClassePub – ClassePriv
Programme

Classes &
objets I Les classes au sein d’un paquetage peuvent être. . .
Associations + publiques : visibles depuis l’extérieur du paquetage
Héritage (défaut).
Dépendance – privées : invisibles depuis l’extérieur du paquetage.
Interfaces ,→ « Invisible » signifie que l’on ne peut pas l’instancier.
Analyse vs I Rappel : les attributs/opérations peuvent avoir la visibilité
conception paquetage (∼) :
Paquetages • L’attribut est publique depuis les autres classes du
paquetage.
• L’attribut est privé depuis l’extérieur du paquetage
Cette visibilité n’a de sens que si la classe elle-même est
49 / 50
publique.
Hiérarchie, lien entre paquetages

Classes Parent
M. Sassolas
M3105 PaquetageA
Cours 3

Programme – ClassePrivA + ClassePubA


Classes &
objets
PaquetageB
Associations

Héritage – ClassePrivB + ClassePubB


Dépendance

Interfaces

Analyse vs
conception I On n’interdit pas les associations entre classes de
Paquetages différents paquetages.
I On peut mettre des paquetages dans d’autres pour
hiérarchiser le découpage.
50 / 50 I (On peut relier les paquetages d’autres manières ; nous n’en parlerons pas.)

Vous aimerez peut-être aussi