CSC4002 : Introduction à la conception et à la programmation

Transcription

CSC4002 : Introduction à la
conception et à la programmation
orientées objet illustrées avec
UML et JAVA
Denis Conan et Jean-Luc Raffy
CSC 4002
Octobre 2015
CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA
Télécom SudParis — Denis Conan et Jean-Luc Raffy — Octobre 2015 — CSC 4002
-1
0
Table des matières
CSC4002 : Introduction à la conception et à la programmation orientées objet avec UML
et JAVA
9
1 Objectifs de CSC4002
10
2 Démarche
10
3 Découpage du module
10
4 Prérequis
11
5 Évaluation
11
6 Résultats, statistiques
12
7 Comment réussir CSC4002
12
8 Site Web et adresses courriel
13
Introduction au langage de modélisation UML
15
Sommaire
19
1 Objectifs de ce cours de modélisation orientée objet
20
2 Généralités sur la modélisation orienté objet et sur UML
2.1 Principes de la modélisation . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Pourquoi et comment modéliser en orienté objet . . . . . . . . . . . . .
2.3 Unified Modelling Language (UML) . . . . . . . . . . . . . . . . . . . .
2.3.1 UML, un langage . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Les 10 principaux diagrammes UML . . . . . . . . . . . . . . . .
2.4 Cinq façons de voir un système informatique : les 4+1 vues de Kruchten
2.5 Phases de la modélisation, cycle en V . . . . . . . . . . . . . . . . . . .
2.6 Rôle de l’expression des besoins . . . . . . . . . . . . . . . . . . . . . . .
2.6.1 Exemple de cahier des charges : Studs . . . . . . . . . . . . . . .
2.6.2 Règles de gestion et contraintes de l’application Studs . . . . . .
2.7 Rôle de l’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 Rôle de la conception . . . . . . . . . . . . . . . . . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
22
23
24
25
26
28
29
30
31
32
33
34
35
3 Analyse, vues cas d’utilisation et processus
3.1 Modèle de l’analyse . . . . . . . . . . . . . . . . . . . . . . .
3.2 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . .
3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Acteur . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Relation de généralisation spécialisation entre acteurs
3.2.4 Cas d’utilisation, lien de communication et système . .
3.2.5 Exemple de diagramme de cas d’utilisation . . . . . .
3.2.6 Éléments de méthodologie . . . . . . . . . . . . . . . .
3.3 Diagrammes d’activité * . . . . . . . . . . . . . . . . . . . . .
3.3.1 Scénarios d’un cas d’utilisation * . . . . . . . . . . . .
3.3.2 Actions et choix * . . . . . . . . . . . . . . . . . . . .
3.3.3 Concurrence * . . . . . . . . . . . . . . . . . . . . . .
3.3.4 Autres notations du diagramme d’activité * . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
37
38
39
40
41
42
44
45
46
47
48
49
50
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
4 Analyse et conception, aspects statiques de la vue logique
4.1 Diagrammes communs à l’analyse et à la conception . . . . . . . . . . .
4.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Modéliser la structure logique du système dans un diagramme de
4.2.2 Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Instanciation : création d’un objet d’une classe . . . . . . . . . .
4.2.4 Attributs et opérations de classe . . . . . . . . . . . . . . . . . .
4.2.5 Attribut dérivé . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6 Association entre classes . . . . . . . . . . . . . . . . . . . . . . .
4.2.7 Nom de rôle et multiplicité . . . . . . . . . . . . . . . . . . . . .
4.2.8 Généralisation spécialisation ou héritage . . . . . . . . . . . . . .
4.2.9 Généralisation spécialisation : vision ensembliste . . . . . . . . .
4.2.10 Généralisation spécialisation : vision encapsulation . . . . . . .
4.2.11 Généralisation et redéfinition d’opérations . . . . . . . . . . . .
4.2.12 Méthode Polymorphique et liaison dynamique . . . . . . . . . .
4.2.13 Agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.14 Exemple de diagramme de classes . . . . . . . . . . . . . . . . .
4.2.15 Éléments de méthodologie . . . . . . . . . . . . . . . . . . . . .
4.3 Diagramme d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Concepts avancés du diagramme de classes . . . . . . . . . . . . . . . .
4.4.1 Navigabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 Classe d’association . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3 Composition : agrégation forte . . . . . . . . . . . . . . . . . . .
4.4.4 Classe abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.5 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.6 Classe paramétrée / générique * . . . . . . . . . . . . . . . . . .
4.4.7 Exemple de diagramme de classes avancé . . . . . . . . . . . . .
. . . .
. . . .
classes
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
53
54
55
56
57
58
59
60
61
62
64
65
66
67
69
70
71
73
74
75
76
77
78
79
80
82
83
5 Analyse et conception, aspects dynamiques de la vue logique
5.1 Rappel : diagrammes communs à l’analyse et à la conception . .
5.2 Modélisation des aspects dynamiques . . . . . . . . . . . . . . .
5.2.1 Algorithme : orientations procédurale et objet . . . . . . .
5.2.2 Modèle dynamique de l’analyse et de la conception . . . .
5.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Modéliser l’ordre des interactions . . . . . . . . . . . . . .
5.3.2 Participant, temps et message . . . . . . . . . . . . . . . .
5.3.3 Exemple de diagramme de séquence « Ouvrir un scrutin »
5.3.4 Syntaxe et types de messages . . . . . . . . . . . . . . . .
5.3.5 Création et suppression d’objets . . . . . . . . . . . . . .
5.3.6 Fragments de séquence « ref » et « opt » . . . . . . . . .
5.3.7 Fragment de séquence « loop » . . . . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Diagramme de communications . . . . . . . . . . . . . . . . . . .
5.4.1 Modéliser les liens d’interactions . . . . . . . . . . . . . .
5.4.2 Participant, lien d’interaction, message . . . . . . . . . . .
5.4.3 Message conditionné, messages en séquence . . . . . . . .
5.4.4 Messages emboîtés . . . . . . . . . . . . . . . . . . . . . .
5.4.5 Itération de messages . . . . . . . . . . . . . . . . . . . .
5.4.6 Collection et recherche dans une collection . . . . . . . . .
5.4.7 Messages concurrents * . . . . . . . . . . . . . . . . . . .
5.4.8 Choix entre séquence et communications* . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Diagramme de machine à états . . . . . . . . . . . . . . . . . . .
5.5.1 Modéliser l’état des objets d’une classe . . . . . . . . . . .
5.5.2 Types d’états, événement et transition . . . . . . . . . . .
5.5.3 Événement, condition et action d’une transition . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
5.5.4 Transition implicite . . .
5.5.5 Exemple de diagramme de
5.5.6 Actions liées à un état . .
5.5.7 Éléments de méthodologie
5.5.8 État composite * . . . . .
QCM . . . . . . . . . . . . . . . . .
. . . . .
machine
. . . . .
. . . . .
. . . . .
. . . . .
. . . . . .
à états de
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . .
la classe
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Scrutin
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
112
113
114
115
116
117
6 Conception, aspects langage et technique
6.1 Rappel des phases du cycle de développement en V . . . . . . . . . . .
6.2 Conception des classes . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Rappel du diagramme de classes de l’étude de cas Studs . . . . . . . .
6.4 Traduction des associations en attributs . . . . . . . . . . . . . . . . .
6.4.1 Règles de traduction . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Traduction des agrégations . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Traduction des compositions * . . . . . . . . . . . . . . . . . . . . . .
6.7 Traduction de la classe « Façade » du système . . . . . . . . . . . . .
6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations
6.8.1 Encapsulation avec le concept de Visibilité . . . . . . . . . . . .
6.8.2 Notation UML . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8.3 Cas particulier des attributs/opérations protégés . . . . . . . .
6.9 Traduction des attributs dérivés . . . . . . . . . . . . . . . . . . . . .
6.10 Qualification de certaines associations * . . . . . . . . . . . . . . . .
6.11 Traduction des diagrammes d’interaction en algorithmes . . . . . . .
6.12 Traduction des diagrammes de machine à états . . . . . . . . . . . .
6.12.1 Quelques opérations de la classe Scrutin . . . . . . . . . . . .
6.13 Traduction des relations de généralisation spécialisation . . . . . . .
6.14 Traduction des classes d’association * . . . . . . . . . . . . . . . . . .
6.15 Méthodologie : une fiche par classe . . . . . . . . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
7 Conception, vues développement et physique
7.1 Diagrammes de la vue développement . . . . . . . .
7.2 Diagramme de composants . . . . . . . . . . . . . .
7.2.1 Composant, interfaces offertes et requises . .
7.2.2 Composite, port, connecteurs de délégation et
7.3 Diagramme de paquetages . . . . . . . . . . . . . . .
7.3.1 Paquetage, espace de nommage . . . . . . . .
7.3.2 Relation entre paquetages . . . . . . . . . . .
7.4 Diagramme de la vue physique . . . . . . . . . . . .
7.5 Diagramme de déploiement . . . . . . . . . . . . . .
7.5.1 Nœud et liaison de communication . . . . . .
7.5.2 Artefact et composant . . . . . . . . . . . . .
7.5.3 Dépendance entre artefacts . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
140
141
142
143
144
145
146
147
148
149
150
151
152
. . . . . . . .
. . . . . . . .
. . . . . . . .
d’assemblage
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8 Conclusion
153
9 Bibliographie
154
BE1–2 : Phase d’analyse
Gestion des prêts dans une médiathèque
1 Sujet
155
156
3
2 Méthodologie et objectifs
2.1 Première lecture : acteurs et cas d’utilisation . . . . .
2.1.1 Question 1 : diagramme de cas d’utilisation . .
2.2 Analyse du texte : recherche des classes et opérations .
2.2.1 Question 2 : liste des classes . . . . . . . . . . .
2.3 Phase de construction du diagramme de classes . . . .
2.3.1 Question 3 : diagramme de classes simple . . .
2.4 Phase de recherche des attributs et opérations . . . . .
2.4.1 Question 4 : classes avec opérations . . . . . .
2.5 Phase de vérification de l’analyse, aspects statiques . .
2.5.1 Question 5 : vérifications . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
156
156
156
156
157
157
157
157
158
158
158
3 Cahier des charges
158
3.1 Règles de prêt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Diagrammes dynamiques
161
1 Questions
162
2 Méthodologie
162
2.1 Construction des diagrammes de machine à états (DME) . . . . . . . . . . . . . . . . . . . 162
2.2 Construction des diagrammes de communications (DC) et de séquence (DS) . . . . . . . . 162
2.3 Derniers conseils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
BE5 : Conception des classes
163
1 Questions
164
2 Méthodologie
164
2.1 Démarche de conception des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
2.2 Opérations à effectuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
BE6–7 : Analyse complète d’un cas
165
1 Sujet
166
2 Questions
2.1 Analyse du texte . . . . . . . . . . . . . . . . .
2.2 Diagramme de cas d’utilisation . . . . . . . . .
2.3 Diagramme de classes . . . . . . . . . . . . . .
2.4 Diagramme de machine à états . . . . . . . . .
2.5 Conception des classes . . . . . . . . . . . . . .
2.6 Diagramme de communications ou de séquence
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Introduction au langage de programmation Java
169
Sommaire du cours
1 Introduction à Java
1.1 Vous avez dit Java ? . . . .
1.1.1 Android . . . . . . .
1.1.2 CAS . . . . . . . . .
1.1.3 Java partout ! . . . .
1.1.4 Pourquoi nous ? . .
1.2 Que recouvre le mot Java ?
1.2.1 Héros . . . . . . . .
1.2.2 Projet et Historique
1.3 Caractéristiques . . . . . .
166
166
166
166
167
167
167
173
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
174
174
174
175
175
176
176
177
177
178
4
1.3.1 Java un langage Objet . . .
1.3.2 Machine Virtuelle Java . . .
1.3.3 Robustesse . . . . . . . . .
1.4 Historique de l’API . . . . . . . . .
1.5 Environnements de développement
1.5.1 Java Standard Development
1.6 En savoir plus . . . . . . . . . . .
1.6.1 Sites Web . . . . . . . . . .
Questions sur les concepts Java . . . .
. . .
. . .
. . .
. . .
. . .
Kit
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
179
180
180
181
182
182
183
184
184
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
185
185
186
186
188
188
189
189
190
190
191
192
192
3 Classes et objets en Java
3.1 Classe . . . . . . . . . . . . . . . . . . . . .
3.1.1 Classe Personne en Java . . . . . . .
3.1.2 Instance de classe en UML . . . . .
3.1.3 Instance de classe en Java . . . . . .
3.2 Objet . . . . . . . . . . . . . . . . . . . . .
3.2.1 Constructeurs en Java . . . . . . . .
3.2.2 Exemples de constructeurs . . . . . .
3.2.3 this . . . . . . . . . . . . . . . . . .
3.2.4 Exemples d’utilisation de this . . .
3.2.5 Destruction des objets . . . . . . . .
3.2.6 Abstraction et encapsulation . . . .
3.2.7 Visibilité des méthodes . . . . . . . .
3.3 Attributs et méthodes de classe . . . . . . .
3.3.1 Attributs et méthodes de classe Java
3.3.2 Attributs et méthodes de classe . . .
3.4 Association entre classes . . . . . . . . . . .
3.4.1 Exemple d’association . . . . . . . .
3.4.2 Association entre classes en Java . .
Questions sur les classes et objet . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
194
194
194
196
196
197
197
198
198
198
199
200
200
201
201
202
203
203
204
205
4 Généralisation spécialisation en Java
4.1 Généralisation spécialisation . . . . . . . . . . . . . . . . . .
4.1.1 Héritage : comment en Java . . . . . . . . . . . . . .
4.1.2 Héritage et constructeur . . . . . . . . . . . . . . . .
4.1.3 Exemple de classe parente et classe dérivée . . . . .
4.1.4 Utilisation de classe parente et dérivée . . . . . . . .
4.2 Polymorphisme . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Exemple de Upcast et Downcast . . . . . . . . . . .
4.3 Redéfinition de méthodes dans les classes dérivées . . . . .
4.3.1 Polymorphisme et liaison dynamique avec toString
4.4 Héritage, membres et visibilité . . . . . . . . . . . . . . . .
Questions généralisation/spécialisation en Java . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
206
206
207
207
208
209
210
211
212
212
213
213
2 Concepts de bases de Java
2.1 Syntaxe de base . . . . . . . . . . . .
2.1.1 Premier en C . . . . . . . . . .
2.1.2 Premier en Java . . . . . . . .
2.2 Types Primitifs . . . . . . . . . . . . .
2.2.1 Conversions de type . . . . . .
2.2.2 Exemple de conversions . . . .
2.2.3 Tableaux . . . . . . . . . . . .
2.2.4 Exemple avec un tableau . . .
2.3 Tableaux . . . . . . . . . . . . . . . .
2.4 Méthodes . . . . . . . . . . . . . . . .
2.5 Exemple de passage d’arguments . . .
Questions sur la syntaxe de base de Java .
.
.
.
.
.
.
.
.
.
.
.
.
5
4.5 Classes abstraites . . . . . . . . . . .
4.5.1 Classes abstraites : principes
4.5.2 Classes abstraites en Java . .
4.6 Exemple de classe Abstraites . . . .
4.6.1 Exemple : classes abstraites .
4.7 Interfaces . . . . . . . . . . . . . . .
4.7.1 Interfaces en Java . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
214
214
215
215
216
218
218
5 Organisation des sources Java
5.1 Programme en C (rappel) . . . . . . . . . . . . . . . .
5.2 Exécution d’un programme (rappel) . . . . . . . . . .
5.3 Exécution d’un programme sur une machine virtuelle
5.4 Dans le cas de Java . . . . . . . . . . . . . . . . . . .
5.5 Unités de compilation . . . . . . . . . . . . . . . . . .
5.6 Paquetages . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1 Chemin de recherche . . . . . . . . . . . . . . .
5.6.2 Exemple . . . . . . . . . . . . . . . . . . . . . .
5.7 Visibilité en Java . . . . . . . . . . . . . . . . . . . . .
5.7.1 Table de visibilité . . . . . . . . . . . . . . . . .
Questions organisation des sources en Java . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
220
220
220
221
222
222
223
224
224
224
225
226
6 API Java
6.1 Premières classes de l’API . . . . . . . . . .
6.2 Classe java.lang.Object . . . . . . . . . .
6.2.1 Égalité . . . . . . . . . . . . . . . . .
6.2.2 Exemple d’égalité . . . . . . . . . . .
6.2.3 Exemple de méthode equals . . . . .
6.3 Interface de programmation . . . . . . . . .
6.3.1 Quelques paquetages Java . . . . . .
6.4 java.lang.* . . . . . . . . . . . . . . . . . . .
6.4.1 Exemple avec la classe Integer . . .
6.4.2 Classe String . . . . . . . . . . . . .
6.4.3 Exemple pour String . . . . . . . .
Questions API java.lang . . . . . . . . . . . . .
6.5 java.util.* . . . . . . . . . . . . . . . . . . .
6.5.1 Classe paramétrée . . . . . . . . . .
6.5.2 Classes Abstraites des collections . .
6.5.3 Classes instanciables des collections
6.5.4 Collections . . . . . . . . . . . . . .
6.5.5 Interface Iterable . . . . . . . . . .
6.5.6 Interface Collection<E> . . . . . .
6.5.7 Interface List<E> . . . . . . . . . .
6.5.8 Classe Vector<E> . . . . . . . . . . .
6.5.9 Boucle pour les collections . . . . . .
6.5.10 Exemple for-each sur un Vector . .
6.5.11 Exemple de classe avec Vector . .
6.5.12 Interface Iterator . . . . . . . . .
6.5.13 Exemple avec Iterator . . . . . .
6.5.14 Dictionnaires Map<K,V> . . . . . . .
6.5.15 Exemple pour Map . . . . . . . . . .
6.5.16 Dictionnaire Hashtable<K,V> . . .
6.5.17 Exemple pour Hashtable . . . . . .
6.5.18 Représentation d’une Hashtable . .
Questions collections en Java . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
227
227
227
229
229
230
231
231
232
233
233
233
234
234
235
236
237
237
238
238
239
239
240
241
241
242
243
244
244
245
246
246
247
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
7 Exceptions en Java
7.1 Motivation : retours sur un bug . . .
7.2 Principes . . . . . . . . . . . . . . .
7.2.1 Mise en œuvre . . . . . . . .
7.2.2 Exemple de traitement . . . .
7.3 Réalisation . . . . . . . . . . . . . .
7.3.1 java.lang.Exception . . . . . .
7.4 Traitement des exceptions . . . . . .
7.5 Exemple de traitement d’exceptions
Questions sur les exceptions . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
248
248
249
250
250
251
251
252
253
254
8 Concepts objets avancés en Java
8.1 Copie simple/légère . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.1 Copie pour studs . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.2 Représentation graphique d’une copie légère dans studs . . . .
8.1.3 Exemple de copie légère . . . . . . . . . . . . . . . . . . . . . .
8.1.4 Représentation graphique d’une copie plus profonde dans studs
8.1.5 Copie plus profonde dans studs . . . . . . . . . . . . . . . . . .
8.1.6 Représentation graphique d’une copie profonde . . . . . . . . .
8.1.7 Clone de Scrutin . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.8 Clone en copie profonde de Personne . . . . . . . . . . . . . .
8.1.9 Suite exemple de copie profonde . . . . . . . . . . . . . . . . .
8.2 Retour sur hashCode() . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 Exemple hashCode . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Retour sur les exceptions . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1 Test des exceptions . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2 RuntimeException . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
256
256
257
257
257
259
259
261
262
263
264
265
266
266
267
269
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Bibliographie
271
Les tests en orienté objet
274
Gestion de la persistance des objets
342
TP13-14 : TP de synthèse
Tableaux de service des navigants Air France
395
1 Questions de cours
396
2 Rappel du sujet du BE
396
3 Résultat de l’analyse UML
3.1 Liste des classes . . . . . . . . . . . . . . . . . .
3.2 Cas d’utilisation . . . . . . . . . . . . . . . . .
3.3 Diagramme de classes . . . . . . . . . . . . . .
3.4 Diagramme de machine à états . . . . . . . . .
3.5 Diagramme de communications ou de séquence
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
397
397
397
398
398
399
4 Questions de l’étude de cas
400
Glossaire global
Christian Bac et Denis Conan
402
Index global
406
Index
407
Fin
413
7
Licence
414
8
CSC4002 : Introduction à la
conception et à la programmation
orientées objet avec UML et JAVA
Denis Conan et Jean-Luc Raffy
Revision : 1496
CSC 4002
Octobre 2015
9
CSC4002 : Conception et programmation orientée objet
'
$
1 Objectifs de CSC4002
1. Présenter les concepts de base de la conception et de la programmation orientées
objet : objet, classe, composition, héritage, polymorphisme, en les illustrant avec la
notation UML
#2
2. Proposer une méthode permettant la conception de solutions orientées objet pour
résoudre des problèmes simples en utilisant les diagrammes UML
3. Illustrer la programmation en réalisant les solutions obtenues dans le langage orienté
objet JAVA
4. Appréhender les problèmes engendrés par le test d’applications orientées objet
5. Et illustrer la persistance des données en interfaçant les applications obtenues avec
une base de données relationnelle
&
%
'
$
2 Démarche
Trois cas d’étude réalistes illustrent le cours :
Cours = Application de gestion de sondages
BE et TP = Application de gestion d’une médiathèque
#3
I Depuis le cahier des charges jusqu’à la livraison
F Étude des besoins du client
F Analyse/conception
F Tests de logiciel
F Implantation (JAVA et JDBC)
BE et TP de synthèse = Application de gestion des navigants d’une compagnie
aérienne
Avertissement : Ne pas avoir peur !
La difficulté de la taille du cas d’étude principal s’estompe lors du BE et du TP
de synthèse
I qui permettent de remettre en perspective les concepts et la méthodologie
&
%
10
'
$
3 Découpage du module
Le module est divisé en deux parties :
Analyse/Conception
Octobre et novembre ; 16H30 Présentiel + 18h Hors présentiel
#4
I Analyse : élaboration d’un ensemble de diagrammes UML correspondant à une
solution du problème posé
I Conception : étude des techniques de passage des diagrammes UML à une
description complète des classes
Programmation
Décembre et janvier ; 28H30 Présentiel + 27H Hors présentiel
I
I
I
I
Découverte du langage JAVA et de ses composants les plus utiles
Réalisation en JAVA de la solution obtenue dans la partie précédente
Élaboration et programmation d’un jeu de tests
Persistance des données du système (avec JDBC)
&
%
'
$
4 Prérequis
1. Maîtrise de l’environnement UNIX (CSC3001)
#5
2. Maîtrise de la programmation procédurale en langage C (CSC3002)
3. Connaissance des principes de la gestion de projet (CSC3502)
4. Maîtrise des bases de données relationnelles (CSC4001)
&
%
11
'
$
5 Évaluation
1. CC (Contrôle continu) :
BE noté en monôme de 2h sur table portant sur la modélisation orientée objet
en UML
Avec les documents distribués en cours et en BE
2. CF1 (Contrôle final) :
#6
Contrôle individuel de 1h30 sur table portant sur la programmation orientée
objet en JAVA, avec les tests et la persistance des données
Avec les documents distribués en cours et en TP
3. CF2 :
Contrôle individuel de 1h30 sur table portant sur l’ensemble du module
Avec les documents distribués en cours, en BE et en TP
NoteCSC4002 = sup(M oy(CC, CF 1), max(CF 2, 13))
NoteUVInfo = (2 ∗ NoteCSC4001 + 4 ∗ NoteCSC4002 + 1 ∗ NoteCSC4003)/7
&
%
'
$
6 Résultats, statistiques
Année 2014/2015
198 étudiants
CC UML : moyenne 11.9, écart-type 1.99, 9 < 7, 38 < 10, 110 ≥ 12
CF 1 : moyenne 10.4, écart-type 3.37, 35 < 7, 97 < 10, 123 ≥ 65
CF 2 : 34 personnes présentes, 19 < 10, 3 < 7
#7
UV Info (CSC4001 — CSC4002 — CSC4003) : 5 étudiants ne valident pas l’UV
Année 2013/2014
185 étudiants
CC UML : moyenne 12.2, écart-type 1.8, 4 < 7, 21 < 10, 95 ≥ 12
CF 1 : moyenne 13.3, écart-type 2.35, 10 < 7, 31 < 10, 123 > 12
CF 2 : 13 personnes présentes, 10 < 10, 2 < 7
UV Info (CSC4001 — CSC4002 — CSC4003) : 5 étudiants ne valident pas l’UV
&
%
12
'
$
7 Comment réussir CSC4002
Être assidu, travailler régulièrement, ne pas lâcher (le module dure 4 mois)
Travail personnel : le temps en présentiel n’est pas suffisant pour l’assimilation ;
45 heures de travail hors présentiel sont demandées
Partie modélisation : 18h
#8
Partie programmation : 27h (variable suivant les savoir-faire à l’entrée du
module)
I Consolidation des prérequis : ±3 heures (remise à niveau en C)
Travail des cours : assimilation des concepts par la lecture
Travail des BEs : étudier les solutions proposées (assimilation par la pratique)
I S’exercer sur d’autres exemples pris des annales
I S’auto-évaluer sur les QCM
Travail des TPs : les terminer (assimilation par la pratique)
I S’exercer avec les exercices personnels
I S’auto-évaluer sur les QCM
&
%
'
$
8 Site Web et adresses courriel
Module dans Moodle : http://moodle.tem-tsp.eu
Site Web accessible Internet : http://www-inf.it-sudparis.eu/COURS/CSC4002
#9
En cas de question/suggestion, envoyez un courriel aux DEUX coordinateurs :
Denis.Conan At telecom-sudparis.eu
et
Jean-Luc.Raffy At telecom-sudparis.eu
&
%
13
14
Introduction au langage de
modélisation UML
Denis Conan, Chantal Taconet, Christian Bac
Revision : 1495
CSC 4002
Octobre 2015
15
Table des matières
Sommaire
19
20
2.1 Principes de la modélisation . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Pourquoi et comment modéliser en orienté objet . . . . . . . . . . . . .
2.3 Unified Modelling Language (UML) . . . . . . . . . . . . . . . . . . . .
2.3.1 UML, un langage . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Les 10 principaux diagrammes UML . . . . . . . . . . . . . . . .
2.4 Cinq façons de voir un système informatique : les 4+1 vues de Kruchten
2.5 Phases de la modélisation, cycle en V . . . . . . . . . . . . . . . . . . .
2.6 Rôle de l’expression des besoins . . . . . . . . . . . . . . . . . . . . . . .
2.6.1 Exemple de cahier des charges : Studs . . . . . . . . . . . . . . .
2.6.2 Règles de gestion et contraintes de l’application Studs . . . . . .
2.7 Rôle de l’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 Rôle de la conception . . . . . . . . . . . . . . . . . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
22
23
24
25
26
28
29
30
31
32
33
34
35
3.1 Modèle de l’analyse . . . . . . . . . . . . . . . . . . . . . . .
3.2 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . .
3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Acteur . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 Cas d’utilisation, lien de communication et système . .
3.2.5 Exemple de diagramme de cas d’utilisation . . . . . .
3.2.6 Éléments de méthodologie . . . . . . . . . . . . . . . .
3.3 Diagrammes d’activité * . . . . . . . . . . . . . . . . . . . . .
3.3.1 Scénarios d’un cas d’utilisation * . . . . . . . . . . . .
3.3.2 Actions et choix * . . . . . . . . . . . . . . . . . . . .
3.3.3 Concurrence * . . . . . . . . . . . . . . . . . . . . . .
3.3.4 Autres notations du diagramme d’activité * . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
37
38
39
40
41
42
44
45
46
47
48
49
50
51
. . . .
. . . .
classes
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
53
54
55
56
57
58
59
60
61
62
64
65
66
67
69
70
71
73
74
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.1 Diagrammes communs à l’analyse et à la conception . . . . . . . . . . .
4.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Modéliser la structure logique du système dans un diagramme de
4.2.2 Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Instanciation : création d’un objet d’une classe . . . . . . . . . .
4.2.4 Attributs et opérations de classe . . . . . . . . . . . . . . . . . .
4.2.5 Attribut dérivé . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6 Association entre classes . . . . . . . . . . . . . . . . . . . . . . .
4.2.7 Nom de rôle et multiplicité . . . . . . . . . . . . . . . . . . . . .
4.2.8 Généralisation spécialisation ou héritage . . . . . . . . . . . . . .
4.2.9 Généralisation spécialisation : vision ensembliste . . . . . . . . .
4.2.10 Généralisation spécialisation : vision encapsulation . . . . . . .
4.2.11 Généralisation et redéfinition d’opérations . . . . . . . . . . . .
4.2.12 Méthode Polymorphique et liaison dynamique . . . . . . . . . .
4.2.13 Agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.14 Exemple de diagramme de classes . . . . . . . . . . . . . . . . .
4.3 Diagramme d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Télécom SudParis — D. Conan, C. Taconet, C. Bac — Octobre 2015 — CSC 4002
16
4.4 Concepts avancés du diagramme de classes . . .
4.4.1 Navigabilité . . . . . . . . . . . . . . . . .
4.4.2 Classe d’association . . . . . . . . . . . .
4.4.3 Composition : agrégation forte . . . . . .
4.4.4 Classe abstraite . . . . . . . . . . . . . . .
4.4.5 Interface . . . . . . . . . . . . . . . . . . .
4.4.6 Classe paramétrée / générique * . . . . .
4.4.7 Exemple de diagramme de classes avancé
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
76
77
78
79
80
82
83
5.1 Rappel : diagrammes communs à l’analyse et à la conception . . . . .
5.2 Modélisation des aspects dynamiques . . . . . . . . . . . . . . . . . .
5.2.1 Algorithme : orientations procédurale et objet . . . . . . . . . .
5.2.2 Modèle dynamique de l’analyse et de la conception . . . . . . .
5.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Modéliser l’ordre des interactions . . . . . . . . . . . . . . . . .
5.3.2 Participant, temps et message . . . . . . . . . . . . . . . . . . .
5.3.3 Exemple de diagramme de séquence « Ouvrir un scrutin » . . .
5.3.4 Syntaxe et types de messages . . . . . . . . . . . . . . . . . . .
5.3.5 Création et suppression d’objets . . . . . . . . . . . . . . . . .
5.3.6 Fragments de séquence « ref » et « opt » . . . . . . . . . . . .
5.3.7 Fragment de séquence « loop » . . . . . . . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Diagramme de communications . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Modéliser les liens d’interactions . . . . . . . . . . . . . . . . .
5.4.2 Participant, lien d’interaction, message . . . . . . . . . . . . . .
5.4.3 Message conditionné, messages en séquence . . . . . . . . . . .
5.4.4 Messages emboîtés . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.5 Itération de messages . . . . . . . . . . . . . . . . . . . . . . .
5.4.6 Collection et recherche dans une collection . . . . . . . . . . . .
5.4.7 Messages concurrents * . . . . . . . . . . . . . . . . . . . . . .
5.4.8 Choix entre séquence et communications* . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Diagramme de machine à états . . . . . . . . . . . . . . . . . . . . . .
5.5.1 Modéliser l’état des objets d’une classe . . . . . . . . . . . . . .
5.5.2 Types d’états, événement et transition . . . . . . . . . . . . . .
5.5.3 Événement, condition et action d’une transition . . . . . . . . .
5.5.4 Transition implicite . . . . . . . . . . . . . . . . . . . . . . . .
5.5.5 Exemple de diagramme de machine à états de la classe Scrutin
5.5.6 Actions liées à un état . . . . . . . . . . . . . . . . . . . . . . .
5.5.8 État composite * . . . . . . . . . . . . . . . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
6.1 Rappel des phases du cycle de développement en V . . . . . . . . . . .
6.2 Conception des classes . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Rappel du diagramme de classes de l’étude de cas Studs . . . . . . . .
6.4 Traduction des associations en attributs . . . . . . . . . . . . . . . . .
6.4.1 Règles de traduction . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Traduction des agrégations . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Traduction des compositions * . . . . . . . . . . . . . . . . . . . . . .
6.7 Traduction de la classe « Façade » du système . . . . . . . . . . . . .
6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations
6.8.1 Encapsulation avec le concept de Visibilité . . . . . . . . . . . .
6.8.2 Notation UML . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8.3 Cas particulier des attributs/opérations protégés . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
118
119
120
121
122
123
124
125
126
127
128
129
130
17
6.9 Traduction des attributs dérivés . . . . . . . . . . . . . .
6.10 Qualification de certaines associations * . . . . . . . . .
6.11 Traduction des diagrammes d’interaction en algorithmes
6.12 Traduction des diagrammes de machine à états . . . . .
6.12.1 Quelques opérations de la classe Scrutin . . . . .
6.13 Traduction des relations de généralisation spécialisation
6.14 Traduction des classes d’association * . . . . . . . . . . .
6.15 Méthodologie : une fiche par classe . . . . . . . . . . . .
QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Diagrammes de la vue développement . . . . . . . .
7.2 Diagramme de composants . . . . . . . . . . . . . .
7.2.1 Composant, interfaces offertes et requises . .
7.3 Diagramme de paquetages . . . . . . . . . . . . . . .
7.3.1 Paquetage, espace de nommage . . . . . . . .
7.3.2 Relation entre paquetages . . . . . . . . . . .
7.4 Diagramme de la vue physique . . . . . . . . . . . .
7.5 Diagramme de déploiement . . . . . . . . . . . . . .
7.5.1 Nœud et liaison de communication . . . . . .
7.5.2 Artefact et composant . . . . . . . . . . . . .
7.5.3 Dépendance entre artefacts . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
131
132
133
134
135
136
137
138
139
. . . . . . . .
. . . . . . . .
. . . . . . . .
d’assemblage
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
140
141
142
143
144
145
146
147
148
149
150
151
152
8 Conclusion
153
9 Bibliographie
154
18
'
$
Sommaire
#2
1
2
3
4
5
6
7
8
9
Objectifs de ce cours de modélisation orientée objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Généralités sur la modélisation orienté objet et sur UML. . . . . . . . . . . . . . . . . . . . . . . . . . .4
Analyse, vues cas d’utilisation et processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Analyse et conception, aspects statiques de la vue logique . . . . . . . . . . . . . . . . . . . . . . . . 33
Analyse et conception, aspects dynamiques de la vue logique . . . . . . . . . . . . . . . . . . . . . 61
Conception, aspects langage et technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Conception, vues développement et physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
&
%
Une organisation, grande ou petite, dépend souvent, d’une part, de la qualité de son système d’information, et d’autre part, de systèmes informatiques spécifiques à son métier. Une organisation qui sait développer
ou faire développer les logiciels dont ses collaborateurs ont besoin en temps et en heure tout en restant dans
les budgets fixés assure sa pérennité et son efficience. Cet aspect est stratégique et permet de se distinguer
des concurrents. Pour développer des logiciels correspondant aux besoins des utilisateurs, un processus de
développement compris par l’ensemble des intervenants est très utile. Dès que le logiciel à développer est non
trivial et doit rendre service pendant plusieurs années, toute partie du logiciel doit être utile (pour éviter
de maintenir du code qui ne sert à rien), et doit être comprise par les différentes équipes de développement
qui produisent les différentes versions d’année en année et par les utilisateurs nouveaux qui arrivent au fil
des années. Pour toutes ces raisons, un modèle du système informatique, comprenant un modèle de la partie
logicielle, est nécessaire.
Dans ce cours de modélisation orientée objet, les deux premières sections explicitent les objectifs du
cours, puis introduisent le choix de la notation UML. Les sections qui suivent abordent tour à tour les phases
de modélisation (analyse et conception) ainsi que les aspects les plus importants de la modélisation d’un
système logiciel (aspects statiques, dynamiques, développement, et déploiement).
NB : les diapositives dont le titre se termine par le caractère « * » correspondent à un contenu non
directement étudié dans le module.
19
'
$
Introduire la modélisation orientée objet
Introduire la modélisation à base de graphiques des systèmes informatiques
Introduire la notation UML
Différents types de diagrammes avec leurs notations
#3
Rôles complémentaires des types de diagrammes
Cohérence entre diagrammes de même type ou de types différents
Présenter des éléments méthodologiques d’utilisation des différents types de
diagrammes dans un processus de développement
Présentation dans le cours d’une première étude de cas
Mise en pratique lors des bureaux d’étude avec deux autres études de cas
Évaluation de l’acquisition lors d’un examen sur table avec une quatrième étude
de cas
&
%
L’objectif de ce cours est de vous présenter les concepts de la modélisation de systèmes informatiques,
c’est-à-dire des systèmes dans lesquels la partie logicielle est prépondérante. La co-conception matérielle et
logicielle n’est pas abordée dans ce cours.
Un modèle est une abstraction de la réalité permettant de mieux comprendre le système. Nous construisons des modèles des systèmes complexes parce qu’il est difficile, voire impossible, de maîtriser la complexité
sans modélisation abstraite au delà d’une certaine taille. En outre, le choix du modèle à créer est important. Dans les modules CSC3002 et CSC3502, l’analyse structurelle de programme écrit en langage C se
focalise sur les algorithmes et les flots de données structurées. Dans le module CSC4001, ce sont les entités
structurées en table et les relations entre ces tables qui aident à organiser les informations du système, les
requêtes permettant alors d’exprimer à l’aide de l’algèbre relationnelle les manipulations sur ces données.
Dans ce module, la nouveauté est d’étudier le système logiciel selon son architecture et d’exprimer comment
des entités (appelées objets par la suite) interagissent pour remplir une fonction. Un critère important de la
qualité d’un modèle orienté objet est alors la cohérence entre les objets (réels) du système réel modélisé et
les objets (virtuels) du modèle du système réel.
La modélisation à base de graphiques est plus précise qu’une description informelle en langage naturel.
C’est un premier niveau de formalisme, suffisamment léger pour être compris par le client, suffisamment
formel pour pouvoir proposer une première analyse, support à l’approfondissement nécessaire ultérieur avec
une notation plus formelle ou à la réalisation du logiciel dans un langage donné. Le grand intérêt de UML
réside d’une part dans son orientation objet avec des notations graphiques faciles à comprendre par tout
public, et d’autre part, dans sa standardisation et très grande diffusion aussi bien dans le milieu académique
qu’industriel. Les modèles mathématiques utilisés pour modéliser les systèmes critiques ne sont pas étudiés
dans ce cours.
Ce cours introduit donc à la modélisation de systèmes informatiques orientée objet en utilisant le langage
(graphique) UML. UML divise la visualisation d’un modèle en diagrammes qui correspondent à des vues
différentes. Ce cours présente les différents types de diagrammes, leurs rôles complémentaires, et montre
comment les diagrammes d’un modèle sont construits de manière cohérente. C’est ce qui explique que nous
utilisons autant que possible la même étude de cas (le système de vote Studs) dans tout le cours. Pour ce
faire, ce cours présente un processus simplifié de développement des systèmes informatiques. L’utilisation de
la même étude de cas dans les différentes phases du processus de développement en facilite la compréhension.
Les éléments pratiques du cours sont illustrés dans les bureaux d’étude du module avec une autre étude de
cas ; c’est ce qui explique que nous utilisons la même étude de cas (la médiathèque) tout au long des bureaux
d’étude et des travaux pratiques du module. Le bureau d’étude noté a pour but de valider l’acquisition de
la notation UML et du processus de développement par l’étude d’une troisième étude de cas.
20
'
$
#4
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Principes de la modélisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Pourquoi et comment modéliser en orienté objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Unified Modelling Language (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Cinq façons de voir un système informatique : les 4+1 vues de Kruchten . . . . . . . . 10
Phases de la modélisation, cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Rôle de l’expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Rôle de l’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Rôle de la conception. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
&
%
Nous présentons dans cette section les principes de la modélisation, puis les quatre rôles du modèle d’un
système (spécifier, valider, guider et documenter), et ensuite, nous justifions l’intérêt de la modélisation
orientée objet, autour du concept d’objet permettant de relier le modèle au monde réel. Puis, nous introduisons UML, la notation la plus utilisée. Avant de passer à la première phase du processus de développement,
nous donnons un aperçu du processus de développement avec la notation UML : les vues, les phases et les
diagrammes. Ce cours UML se limite aux trois premières phases du processus de développement : l’expression
des besoins (c’est-à-dire la modélisation du cahier des charges [supposé déjà rédigé]), l’analyse (l’architecture
de la solution avec une vue métier) et la conception (la solution complétée de considérations technologiques
comme les canevas logiciels utilisés). D’autres phases sont étudiées dans le cours de programmation orientée
objet avec le langage Java qui suit ce cours de modélisation.
21
Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML
'
$
2.1 Principes de la modélisation
Objectif principal de la modélisation = maîtriser la complexité
Modéliser = abstraire la réalité pour mieux comprendre le système à réaliser / réalisé
Le modèle doit être relié au monde réel
Par exemple : l’existant avant les travaux, le réalisé, le restant à réaliser
#5
Un modèle peut être exprimé avec différents niveaux d’abstraction / raffinement
Par analogie : répartition électrique de l’immeuble, de la cage d’escalier, de
l’appartement, de la pièce
Une seule « vue » du système n’est pas suffisante
Les intervenants multiples du projet informatique possèdent des préoccupations
multiples
I Par analogie : plan de masse, vues de face et de côté, schéma électrique, plan
de plomberie, plan de calculs de construction
&
%
Le processus de modélisation vise à obtenir une solution acceptable du système informatique. La solution
finalement retenue n’est pas obtenue en une seule itération. Plusieurs étapes sont nécessaires ; ces étapes
successives permettent de raffiner le niveau de détails du système à réaliser. Les premières étapes donnent
une vision à très gros grains et permettent d’avancer dans la compréhension du problème.
Par analogie avec un architecte qui dessine plusieurs plans pour concevoir une maison, la conception
d’un système informatique est organisée dans une architecture de modélisation qui prévoit plusieurs visions
du même problème pour aider à trouver une solution acceptable. La cohérence entre les différentes vues
du système est importante, chaque vue ciblant des catégories différentes d’intervenants ayant des besoins
différents.
Lorsqu’une équipe collabore au développement d’un système informatique (de taille conséquente), trop
de détails empêchent d’avoir une vue synthétique compréhensible par tous les participants (en anglais, stakeholders)1 au projet informatique, et trop peu d’informations conduit à des interprétations différentes et
contradictoires. À partir d’une certaine taille et complexité, l’informatisation d’un système nécessite un
processus de modélisation. Quelque soit la taille du problème, une phase de modélisation est une aide au
développement du système informatique. Cependant, souvent, le nombre de personnes qui participent à la
résolution du problème (clients, équipe de développement, équipe de maintenance) est un des éléments jouant
fortement dans la décision de passer par une phase de modélisation. Plus le nombre de personnes est important, plus les échanges de documents sont importants. Le processus de modélisation est nécessaire pendant
toute la durée de vie du projet : discussion avec les clients, analyse du système à réaliser, documentation
commune entre les développeurs, etc. La pérennité de l’informatisation réalisée est un autre élément justifiant la décision de modéliser le système. En effet, le développement mais aussi la maintenance corrective
et la maintenance évolutive du système bénéficient de l’existence du modèle en tant que documentation de
référence.
Le modèle permet donc de spécifier le système à réaliser/réalisé, de valider le modèle vis-à-vis des clients,
de fournir un guide pour la construction du système pour organiser les structures de données et le comportement du système, et de documenter le système et les décisions prises.
Cf. le glossaire pour la définition des termes « modèle/model », « processus de modélisation/modelling
time », « élément de modèle/model element ».
1. Il est d’usage d’utiliser le singulier pour nommer collectivement les participants possédant le même rôle dans le projet. Il
est plus important de nommer les rôles et non de préciser si le rôle est tenu par une personne ou par une équipe. Par conséquent,
le pluriel utilisé ici à « stakeholders » indique la multiplicité des rôles.
22
'
$
2.2 Pourquoi et comment modéliser en orienté objet
Relier le modèle au monde réel par la notion d’objet
Orienté objet = abstraire et décomposer le système informatique en objets
Le monde réel est constitué d’objets physiques ou immatériels
Tracer les objets virtuels de modélisation depuis les objets du monde réel
I Relier les objets (réels) du problème et les objets (virtuels) de la solution
#6
Favoriser les abstractions naturelles du monde réel utilisables en modélisation
I Objets vus comme des « boîtes noires » : seules les propriétés visibles de
l’extérieur intéressent
I Objets possédant un nom, qualifiables, classables, polymorphes,
dé-/composables, interagissants avec d’autres objets, etc.
Objectifs supplémentaire lors de la modélisation orientée objet
Meilleure indépendance du modèle par rapport aux fonctions demandées
Meilleure capacité d’adaptation et d’évolution du modèle lorsque des
fonctionnalités sont modifiées ou ajoutées
&
%
Un modèle est une abstraction d’objets1 de la réalité. C’est donc une simplification du monde réel. La
problématique consiste alors à trouver le bon niveau d’abstraction et à exprimer les concepts du monde
réel dans un langage assez abstrait mais aussi précis qu’un langage de programmation pour que ce langage
soit interprétable par un programme informatique. Le code source d’un système logiciel est un modèle du
système. Ce code source ne fournit cependant qu’un seul niveau d’abstraction, celui de la mise en œuvre
sur une infrastructure matérielle particulière, compréhensible par une partie seulement des intervenants du
projet informatique, les développeurs. Le processus d’informatisation consiste à définir des étapes pour aller
d’un cahier des charges rédigé en langage naturel à une mise en œuvre dans un code source particulier.
Le modèle du système dans les premières phases de ce processus est nécessairement une simplification du
système réel. Le processus de modélisation vise à mieux cerner les limites du système à réaliser. Ensuite, les
modèles sont raffinés de plus en plus pour aboutir au code.
L’approche orientée objet est une façon d’aborder un problème et de le découper en petits sous-problèmes.
On commence par rechercher les objets du système puis leurs interactions. Par analogie, si je m’intéresse
au fonctionnement du corps humain, je décompose l’étude du problème en plusieurs sous chapitres plus
simples : le cœur, le système digestif, le système nerveux, le squelette, etc. Nous avons alors une étude des
différents éléments mais également une étude des interactions entre ces différents éléments. De la même façon,
si j’appréhende l’informatisation d’une banque, je recherche les différents types d’objets qui font partie du
système à réaliser : la banque, les clients, les comptes bancaires, les conseillers clients, les transferts, les
placements, les emprunts. J’étudie ensuite les interactions entre ces différents types d’objets : par exemple,
la création d’un compte bancaire nécessite des interactions entre le client et un conseiller client.
Cf. le glossaire pour la définition des termes « objet/object » et « encapsulation ».
1. Terme pris ici dans son acception générale.
23
'
$
2.3 Unified Modelling Language (UML)
#7
Systèmes d’informations des entreprises, Banques et services financiers,
Télécommunications, Transports, Défense et aérospatiale, Calculs scientifiques,
Applications réparties en réseau, services Web Internet, etc.
&
%
L’orientation objet est un concept apparu d’abord dans les communautés de recherche sur les langages de
programmation. Ainsi, le premier langage de programmation orienté objet (appelé Simula) date de la fin des
années 1960, ce qui valut à ses auteurs norvégien Ole-Johan Dahl et Kristen Nygaard l’ACM Turing Award
(considéré comme le prix Nobel d’informatique) en 2001. Le premier langage orienté objet qui fut reçu à la
fin des années 1980 par une audience plus large et qui rassemble une communauté d’utilisateurs toujours
très active est le langage Smalltalk. Depuis, sont apparus Objective C, C++, Eiffel, Java, Python, Ruby, Scala,
etc.
Les premières méthodes de modélisation, quant à elles, ont été élaborées à la fin des années 1980. Les trois
plus célèbres s’appelaient la méthode Booch (du nom de l’auteur Grady Booch), OOSE (Object-Oriented
Software Engineering) de Ivar Jacobson, et OMT (Object Modeling Technique) de James Rumbaugh. Los Tres
Amigos, comme ils sont appelés dans la communauté, se sont unis dans les années 1990 pour former UML
(Unified Modeling Language). Cette unification s’est opérée dans le cadre de la société Rational Software qui
a été absorbée depuis par IBM. Afin de toucher une plus large audience, leurs résultats ont été standardisés
ensuite par le consortium OMG (Object Management Group) en tant que la notation UML. La version
actuelle de UML est disponible sur le site de l’OMG (www.omg.org).
UML est la notation de modélisation la plus répandue dans le monde. La question de la pertinence du
choix de UML reviendrait donc plutôt à lister les domaines d’utilisation de l’informatique qui n’utilisent pas
UML, ne serait-ce que comme notation graphique pour la documentation. Cette diapositive liste certains
des domaines qui se sont constitués en « task force » au sein de l’OMG. La spécification d’un système avec
UML n’exclut pas bien sûr une modélisation du système avec des modèles formels (c’est-à-dire plus formels
que les diagrammes graphiques de UML).
24
'
$
2.3.1 UML, un langage
UML est un langage de modélisation orientée objet
UML n’est pas une méthode
UML a été adopté par toutes les méthodes orientées objet
UML est dans le domaine public ; c’est un standard
UML est un langage pour :
#8
Visualiser
I Chaque symbole graphique possède une sémantique
Spécifier
I De manière précise et complète, sans ambiguïté
Construire
I Une partie du code des classes peut être généré automatiquement
Documenter
I Les différents diagrammes, notes, contraintes, exigences sont conservés dans
un document
&
%
UML est un langage de modélisation orienté objet, c’est-à-dire que toutes les entités modélisées sont des
objets ou se rapportent à des objets : par exemple, un objet possède une structure de données (avec ce qui
s’appelle des « attributs ») et des comportements (avec ce qui s’appelle des « opérations »). UML n’est pas
une méthode. C’est pourquoi ce cours ne se résume pas à l’acquisition des notations UML mais comprend la
présentation et la mise en pratique d’une méthodologie simple. UML a été adopté par toutes les méthodes
orientées objet et est devenu le standard de l’industrie.
UML est un langage et possède les attributs d’un langage. Ainsi, étant graphique, UML permet de visualiser le système réalisé ; le modèle est divisé en vues sélectionnant les éléments pertinents puis en diagrammes
de différents types. L’aspect graphique de UML retient le premier l’attention de ses utilisateurs. Comme pour
tout langage, les éléments du langage sont définis de manière précise, complète et sans ambiguïté. Cependant,
au moment de l’écriture de ce commentaire (2015), il n’existe pas de preuve formelle de la robustesse (en
anglais, soundness) de UML comme un tout ; seuls les langages de certains diagrammes sont formellement
prouvés. En outre, UML est outillé par des éditeurs logiciels dans des ateliers de génie logiciel (AGL) qui
permettent, en plus de la modélisation, de générer le squelette du code source de certaines parties du système informatique, ce qui ajoute de l’intérêt à UML. Certains de ces ateliers permettent aussi d’effectuer
la rétro-conception d’un système déjà réalisé : à partir du code, construction du modèle UML. Enfin, UML
permet la documentation du système. Cette documentation est utilisée pour faciliter les échanges entre les
différents intervenants dans toutes les phases du processus de développement et de maintenance du système
informatique.
25
'
$
2.3.2 Les 10 principaux diagrammes UML
#9
&
%
Cette diapositive présente la liste des 10 principaux diagrammes UML étudiés dans le cours. Les principaux diagrammes qui sont présentés dans la suite du cours et utilisés en bureaux d’étude sont le diagramme
de cas d’utilisation, les diagrammes d’objets et de classes, les diagrammes de séquence et de communications
ainsi que le diagramme de machine à états. Les diapositives qui suivent indiquent dans quelles vues et dans
quelles phases / étapes du processus de développement ces diagrammes sont construits.
Voici en quelques mots une présentation du contenu de chaque type de diagramme :
• cas d’utilisation : interactions entre le système et les utilisateurs (et autres systèmes externes). Il aide
dans la visualisation des exigences / besoins ;
• activité : séquence et parallélisme dans les activités du système ; autrement dit, modélisation des
processus métier avec les échanges de données
• classes : classes, types, interfaces et relations entre eux ;
• objets : instances de classes définissant une configuration importante du système ;
• machine à états1 : états des classes à travers leur cycle de vie (de la création / instanciation des objets
à leur destruction) et les événements qui provoquent les transitions / changements d’états ;
• interaction, qui se décline en deux types de diagrammes :
– séquence : interactions entre des objets pour lesquelles l’ordre des interactions est important ;
– communications2 : interactions entre objets pour lesquels les connexions entre objets sont importantes ;
• composants : rassemblements de classes ou de composants tels que vus par l’équipe de développement
pour décomposer le système en parties de logiciel gérables (du point de vue développement en gestion
de projet) ;
• paquetages : rassemblement d’éléments de modélisation par exemple pour les distribuer entre membres
de l’équipe de développement ;
• déploiement : unités d’installation, de configuration et de déploiement du produit fini sur un parc de
machines.
1. Ce diagramme était appelé diagramme de transitions d’états en UML 1.x.
2. Ce diagramme était appelé diagramme de collaborations en UML 1.x.
26
Le langage UML possède quelques autres diagrammes que nous ne discuterons pas par manque de temps et
de place : diagrammes de temps (en anglais, timing), diagrammes de vues globales d’interactions (en anglais,
interaction overview) et diagrammes de structures composites.
Cf. le glossaire pour la définition du terme « diagramme/diagram ».
27
'
$
2.4 Cinq façons de voir un système informatique : les 4+1 vues
de Kruchten
# 10
&
%
Le modèle « 4+1 » vues, dit de Kruchten, d’un système informatique permet d’organiser la description
du système en plusieurs vues complémentaires, chacune présentant le système selon un point de vue différent.
L’utilisation de vues permet de traiter séparément les intérêts des divers groupes d’intervenants (architectes,
utilisateurs, développeurs, chefs de projets, etc.) et ainsi de mieux séparer les préoccupations fonctionnelles
(le domaine d’application ou métier ciblé par le système, par exemple la banque ou le contrôle aérien) et les
préoccupations extrafonctionnelles (les propriétés techniques telles que la sûreté de fonctionnement).
La figure schématise le modèle « 4+1 » vues. Ce modèle est composé de cinq vues. La vue « logique »
décrit les aspects statiques et dynamiques d’un système en termes de classes, d’objets, de connexions et de
communications. Elle se concentre sur l’abstraction et l’encapsulation. La vue « processus » capte les aspects
de concurrence et de synchronisation, et les décompose en flux d’exécution (processus, fil d’exécution, etc.).
Elle se rapporte aux objets actifs et aux interactions. La vue « développement » représente l’organisation
statique des modules (exécutable, codes source, paquetages, etc.) dans l’environnement de développement.
La vue « physique » décrit les différentes ressources matérielles et l’implantation logicielle tenant compte
de ces ressources. Donc, elle se rapporte aux nœuds physiques d’exécution et au placement des objets sur
les nœuds. La dernière vue, appelée « cas d’utilisation », se concentre sur la cohérence en présentant des
scénarios d’utilisation qui mettent en œuvre les éléments des quatre premières vues. Les scénarios sont une
abstraction des exigences fonctionnelles de l’application. Cette dernière vue valide en quelque sorte les autres
vues et assure la cohérence globale. C’est aussi cette dernière vue qui est construite en premier, juste après
l’établissement du cahier des charges, pour fixer les contours du système à réaliser avec ses fonctionnalités
appelées, dans la terminologie UML, des cas d’utilisation.
Cf. le glossaire pour la définition du terme « vue/view ».
28
'
$
2.5 Phases de la modélisation, cycle en V
# 11
&
%
Le schéma présente le cycle en V du développement d’un système informatique. Le cycle en V vous est
déjà familier car vous l’avez rencontré pour la programmation procédurale lors du module CSC3502. Il est
également utilisé en orienté objet. L’informatisation débute par l’établissement du cahier des charges avec
le client suivi de l’analyse qui a pour but de modéliser le problème. Puis, la conception modélise la solution
technique ; elle est suivie par la réalisation du logiciel conforme à la solution. UML est un langage graphique
aisément compréhensible par le client ; le client peut donc comprendre la modélisation du problème, même
s’il ne comprend pas toute la modélisation de la solution qui peut être plus « technique ». Ainsi se termine la
partie gauche du cycle en V. La partie droite consiste en la vérification du logiciel construit par une série de
tests et la recette par le client du produit fini. Il est important de noter que les différentes phases sont souvent
réalisées par des équipes ou des personnes différentes. Par exemple, les vérifications par les tests ne sont en
général pas effectuées par les mêmes personnes que celles ayant réalisées le logiciel à tester : cela renforce
la confiance dans le produit fini en évitant le biais de l’auto-vérification. Le plus souvent, les différents tests
sont spécifiés par les équipes qui modélisent le problème et conçoivent la solution, mais ils sont exécutés par
les équipes qui opèrent les vérifications. À titre indicatif, il existe une méthodologie appelée « développement
conduit par les tests » (en anglais, test-driven development) qui consiste, dans la phase d’implantation, à
« écrire » les tests avant d’écrire les fonctions à tester. Par ailleurs, le code écrit est évalué qualitativement
lors de ce que l’on appelle une revue de code.
Dans le cadre du module CSC4002, dans les cours (UML et Java) puis lors des bureaux d’étude UML et
des travaux pratiques Java, nous étudions toutes les phases allant de l’analyse à la validation avec les mêmes
cas d’étude : « système de vote Studs » pour le cours et « gestion d’une médiathèque » pour les bureaux
d’étude et les travaux pratiques. L’unicité du cas d’étude dans le cours puis dans les bureaux d’étude et les
travaux pratiques permet de renforcer la cohérence entre les différentes séances et de montrer sur un exemple
quelque peu réaliste, c’est-à-dire d’une taille non négligeable, la méthodologie.
Avertissement : il est important de garder en mémoire tout au long de ce module que la méthodologie proposée n’est qu’une parmi beaucoup d’autres et que des choix différents peuvent
être effectués quant à l’utilisation dans telle ou telle phase du processus de développement de
tel ou tel type de diagramme.
Cf. le glossaire pour la définition du terme « processus de développement/development process ».
29
'
$
2.6 Rôle de l’expression des besoins
Permettre une meilleure compréhension du système
Comprendre et structurer les besoins du client
# 12
Clarifier, filtrer et organiser les besoins, ne pas chercher l’exhaustivité
Une fois identifiés et structurés, ces besoins :
Définissent le contour du système à modéliser
I Précisent le but à atteindre
Permettent d’identifier les fonctionnalités principales du système
&
%
Dans ce cours, nous supposons que le client vient vous voir avec un cahier des charges du système à
réaliser. Bien sûr, il existe des méthodologies d’établissement de cahiers des charges.
Ces problématiques et les phases correspondantes qui se situent en amont de l’établissement du cahier
des charges du système, comme par exemple le positionnement du système dans un ensemble plus vaste
de systèmes de systèmes (activité appelée « urbanisation »), sont étudiées notamment dans les voies d’approfondissement DSI (« Intégration et Déploiement de Systèmes d’Information ») et ISI (« Ingénierie des
Systèmes d’Information »).
Cf. le glossaire pour la définition du terme « exigence/requirement ».
30
'
$
2.6.1 Exemple de cahier des charges : Studs
Studs : Application d’aide à la planification de réunions et à la prise de décision.
L’objectif est de permettre d’exprimer des préférences parmi plusieurs choix.
Les choix sont de deux types : (1) des plages horaires (dates avec heures de début et
de fin) et (2) des votes concernant une liste de choix.
# 13
L’organisatrice, crée un scrutin, renseigne les plages horaires possibles (type 1) et
ajoute les participants à la réunion.
Les participants peuvent exprimer dans un bulletin leurs préférences en indiquant
pour chaque plage horaire s’ils votent « pour » (ils sont disponibles et annoncent
leur intention de participer) ou « contre ».
L’organisatrice récupère les résultats du scrutin à la fin du vote et annonce la plage
horaire choisie.
La procédure est similaire pour le type 2, c.-à-d. pour les scrutins concernant des
propositions (chaînes de caractères quelconques) à choisir.
&
%
Nous nous proposons de construire une application pour aider à la planification de réunions et à la prise
de décision, appelée Studs, très simple, permettant d’exprimer des préférences parmi plusieurs choix. Les
choix sont de deux types : (1) des plages horaires (date avec heures de début et de fin) et (2) des propositions
sous forme de chaînes de caractères quelconques. Le premier type de scrutin est utilisé par une personne
qui désire organiser une réunion. Cette personne, dite l’organisatrice, crée un scrutin, renseigne les plages
horaires possibles, et ajoute les participants à la réunion. Ensuite, les participants peuvent exprimer dans un
bulletin leurs préférences en indiquant pour chaque plage horaire s’ils votent « pour » (ils sont disponibles
et annoncent leur intention de participer) ou « contre ». Enfin, l’organisatrice récupère les résultats du
scrutin à la fin du vote et annonce la plage horaire choisie (par exemple, en maximisant le nombre de
participants à la réunion). La décision n’est pas prise automatiquement par Studs, mais « manuellement »
par l’organisatrice. Le second type de scrutin est utilisé par une personne qui désire consulter avant de
prendre une décision. Cette personne, aussi appelée l’organisatrice, crée un scrutin, renseigne les différentes
réponses possibles à la question posée, et ajoute les participants à la consultation. Ensuite, les participants
peuvent exprimer dans un bulletin leurs préférences en indiquant pour chaque réponse s’ils votent « pour » ou
« contre ». Enfin, l’organisatrice récupère les résultats du scrutin et annonce la décision prise (par exemple,
en maximisant le nombre de vote « pour »). Là encore, la décision n’est pas prise automatiquement par
Studs, mais l’organisatrice prend la décision en fonction des résultats fournis par Studs.
31
'
$
2.6.2 Règles de gestion et contraintes de l’application Studs
Toutes les personnes peuvent être organisatrices.
L’organisatrice est de facto une participante au scrutin.
Seule l’organisatrice est autorisée à gérer un scrutin.
Seuls les participants enregistrés peuvent participer au scrutin et consulter les
résultats.
# 14
Pour que les participants puissent voter, il faut que le scrutin soit ouvert
(dateDuJour ≥ dateDebutScrutin).
La durée d’ouverture du scrutin est limitée.
L’organisatrice doit indiquer la date de destruction automatique du scrutin.
Toutes ces dates permettent de gérer de manière automatique le cycle de vie d’un
scrutin.
Les transitions du cycle de vie peuvent aussi être effectuées à la demande de
l’organisatrice.
&
%
Les règles de gestion et les contraintes de l’application sont les suivantes :
• toutes les personnes peuvent créer des scrutins ; elles sont dans ce cas organisatrices ;
• l’organisatrice est de facto une participante au scrutin ;
• seule l’organisatrice est autorisée à gérer un scrutin : gestion du cycle de vie du scrutin (création,
ouverture, fermeture, et destruction), ajout/retrait de participants, ajout/retrait de choix... ;
• seuls les participants enregistrés comme tels par l’organisatrice peuvent participer au scrutin et consulter les résultats ;
• pour que les participants puissent voter, il faut que le scrutin soit ouvert (dateDuJour ≥
dateDebutScrutin). Par ailleurs, la durée d’ouverture du scrutin est limitée. En outre, l’organisatrice qui crée le scrutin doit indiquer la date de destruction automatique du scrutin, ceci afin de libérer
le système des scrutins caduques. Toutes ces dates permettent de gérer de manière automatique le
cycle de vie d’un scrutin. Mais, il est aussi demandé que les transitions du cycle de vie puissent être
effectuées à la demande de l’organisatrice : en d’autres termes, l’organisatrice peut ouvrir le scrutin
prématurément (ce qui revient à avancer la date d’ouverture à la date du jour) ; elle peut fermer le
scrutin prématurément ; et elle peut demander la destruction du scrutin avant la date de destruction
indiquée lors de la création du scrutin.
32
'
$
2.7 Rôle de l’analyse
Le but de l’analyse est de traduire dans un langage qui se rapproche doucement de
celui des informaticiens les modèles exprimés dans l’expression des besoins
Cependant, pour rester compréhensible par les clients ou utilisateurs, elle ne prend
en considération que des entités du domaine (métier)
# 15
Elle sert d’interface, avec l’expression des besoins, aux dialogues avec les clients et
les utilisateurs
L’analyse doit servir de support pour la conception, l’implantation et la maintenance
Le modèle de l’analyse décrit le problème (ce que doit faire le système et comment il
le fait tel que vu d’un point de vue métier) sans spécifier la solution technique (avec
les canevas logiciels)
Analyse = LE-QUOI
&
%
Les deux premiers diagrammes permettant d’exprimer ce que le système doit faire (les fonctionnalités)
et comment il le fait d’un point de vue métier (ce que nous appellerons les règles de gestion dans le cas d’un
système d’information) sont les diagrammes de cas d’utilisation et d’activité.
Cf. le glossaire pour la définition du terme « analyse/analysis ».
33
'
$
2.8 Rôle de la conception
Le but de la conception est de fixer les choix techniques et de préparer l’implantation
Le modèle de la conception décrit la solution (comment le problème est résolu)
# 16
Conception = LE-COMMENT
La conception doit servir de support pour l’implantation et la maintenance
Le plus souvent, le modèle de la conception n’est pas destiné à être compréhensible
par les utilisateurs mais par les développeurs
&
%
Les modèles produits pendant l’analyse décrivent ce que doit faire le système indépendamment de la
façon dont il est ensuite réalisé. Ainsi, les trois préoccupations suivantes sont spécifiques à la conception :
1) organiser le développement du système informatique et adresser des questions comme les dépendances entre
modules, la configuration, la gestion des versions, 2) distribuer physiquement les différentes parties logicielles
du système et 3) définir les langages de programmation, les schémas de bases de données pour la persistance
des données, etc. Les deux premières préoccupations sont modélisées dans deux vues complémentaires à la
vue logique qui sont les vues développement et physique. Les éléments de la dernière préoccupation sont
classiquement distribués dans les deux mêmes vues.
Fixer le bon niveau d’abstraction d’un modèle ou d’un élément de modèle pour une utilisation donnée du
modèle est souvent une tâche difficile. Au début de l’analyse, soyez le plus abstrait possible et n’incluez pas
de considérations techniques dans les diagrammes de classes du modèle d’analyse. Un diagramme de classes
du modèle d’analyse ne contient que des classes métier, c’est-à-dire des concepts pertinents dans le métier
de l’application. Par exemple, un diagramme d’analyse ne se préoccupe pas de savoir si les données sont
persistantes ou temporaires et si elles seraient enregistrées en base de données, et encore moins si la base de
données serait une base de données relationnelle.
Dans le cadre du module CSC4002, le contenu de la phase de conception consiste uniquement en les deux
tâches suivantes :
1. conception détaillée des classes pour préparer leur réalisation dans le langage de programmation Java,
sujet de la seconde partie du module,
2. projection de certaines classes sur des schémas de bases de données relationnelles pour assurer la
persistance de leurs données.
La seconde tâche n’est pas abordée dans la première partie du cours, mais tient lieu d’une séance de travaux
pratiques en fin de module.
Pour répondre aux autres questions qui surviennent lors de la conception, des compétences informatiques
particulières sont requises dans des domaines très divers : par exemple, les applications multitiers, les applications Web 2.0, la conception et l’utilisation de système d’exploitation, les langages informatiques et leurs
compilateurs, les communications inter-processus, les systèmes répartis, le parallélisme dans les grappes, les
grilles de calcul et le Cloud, les intergiciels (en anglais, middleware), les ontologies, les systèmes embarqués. La plupart de ces sujets sont traités dans la voie d’approfondissement ASR (« Architecte des Services
Informatiques en Réseaux »).
Cf. le glossaire pour la définition du terme « conception/design ».
34
'
$
QCM
1. Le code source d’une application est-il un modèle de l’application ?
2. UML est-il un processus de développement ?
# 17
3. Un client demandant une informatisation est-il censé comprendre les diagrammes
UML ?
4. Un développeur / programmeur est-il censé comprendre les diagrammes UML ?
5. La phase d’expression des besoins est-elle étudiée dans ce module ?
&
%
35
'
$
# 18
3.1 Modèle de l’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Diagrammes d’activité * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
&
%
L’analyse est la première phase du processus de développement d’une application. C’est le premier modèle
construit à partir du cahier des charges. Les fonctionnalités sont rassemblées dans des diagrammes de cas
d’utilisation. Les aspects dynamiques des cas d’utilisation sont les scénarios des processus métier d’utilisation
de l’application. Les scénarios sont classiquement représentés dans des diagrammes d’activité.
36
'
$
3.1 Modèle de l’analyse
Vision de l’extérieur du système, le problème :
Vue cas d’utilisation = ce que fait le système, les fonctionnalités
Vue processus = ce que fait le système, les règles de gestion
# 19
&
%
Comme suggéré par la figure, l’élément pivot du modèle du système informatique est la vue cas d’utilisation. Cette vue est la plus proche du client et des utilisateurs finaux. C’est elle que ces derniers comprennent
le mieux. Elle est complétée par la vue processus qui décrit comment le système répond aux stimulus externes.
Cette vue processus présente les processus métier, par exemple les règles de gestion d’un système d’information. La première vue est composée des diagrammes de cas d’utilisation alors que la seconde contient les
diagrammes d’activité.
37
'
$
3.2 Diagrammes de cas d’utilisation
# 20
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Relation de généralisation spécialisation entre acteurs. . . . . . . . . . . . . . . . . . . . . . . . .23
Cas d’utilisation, lien de communication et système . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Exemple de diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Éléments de méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
&
%
Le premier diagramme dessiné est le diagramme de cas d’utilisation. Les cas d’utilisation sont développés
par du texte dans des scénarios non représentés dans le diagramme. Les scénarios seront modélisés par des
diagrammes d’activité présentés dans la section suivante.
Les éléments de modèle d’un diagramme de cas d’utilisation sont les acteurs extérieurs au système contenant les cas d’utilisation. Les interactions des acteurs avec les cas d’utilisation du système sont modélisées
par des liens de communication.
38
'
$
3.2.1 Introduction
Les fonctionnalités sont modélisées par des cas d’utilisation
Un diagramme de cas d’utilisation définit :
Le système
# 21
Les acteurs
Les cas d’utilisation (fonctionnalités)
Les liens entre acteurs et cas d’utilisation
I Quel acteur accède à quel cas d’utilisation ?
Un modèle de cas d’utilisation se définit par :
Des diagrammes de cas d’utilisation
Une description textuelle des scénarios d’utilisation
&
%
Les cas d’utilisation représentent les fonctionnalités que le système doit satisfaire. Chaque cas d’utilisation
peut être complété par un ensemble d’interactions successives d’une entité en dehors du système (l’utilisateur)
avec le système lui-même. Les cas d’utilisation permettent :
• de connaître le comportement du système sans spécifier comment ce comportement est réalisé,
• de définir les limites précises du système,
• de comprendre l’attente des utilisateurs et des experts du domaine.
Les cas d’utilisation sont aussi des instruments de validation et d’évaluation de l’avancement du système en
cours et en fin de construction.
Dans la suite de cette section, nous illustrons les scénarios par des diagrammes d’activité qui précisent
comment les différentes étapes des scénarios s’agencent. Il est aussi envisageable de décrire les scénarios par
des diagrammes de séquence et de communications. Nous préférons les diagrammes d’activité car ils sont
plus adaptés pour schématiser de manière abstraite les processus métiers. Les diagrammes de séquence et de
communications sont plus adaptés à la description de la dynamique de l’intérieur des sous-systèmes, car ils
montrent plus de détails.
Le cas d’utilisation sert aussi à guider le processus de développement en fournissant un indicateur simple
d’avancement des travaux (par exemple, 5 fonctionnalités sur les 10 incontournables sont réalisées). Il offre
un indicateur simple de succès de réalisation (la validation du produit fini consiste en la validation par
l’exécution de tests des fonctionnalités).
Cf. le glossaire pour la définition des termes « cas d’utilisation/use case [class] » et « système/system ».
39
'
$
3.2.2 Acteur
Un acteur représente une personne, un périphérique ou un autre système qui joue un
rôle (interagit) avec le système
« L’organisatrice, crée un scrutin, renseigne les plages horaires possibles et ajoute
les participants à la réunion. »
# 22
« Les participants peuvent exprimer leurs préférences en indiquant pour chaque
plage horaire s’ils votent “pour” (ils sont disponibles et annoncent leur intention
de participer) ou “contre”. »
&
%
Un acteur est une « entité » externe au système qui interagit avec le système. La notation UML de
l’acteur est soit le dessin « simplifié » d’un personnage complété en dessous par un libellé soit le dessin d’un
rectangle contenant le libellé du nom de l’acteur en dessous du libellé du stéréotype1 « « acteur » ». La
notation graphique que nous préférons est bien sûr le dessin du personnage, plus facile à repérer dans un
diagramme. Un acteur n’est pas toujours une personne, ce peut être un système externe en interaction avec
le système en cours de description2 .
Une attention particulière doit être attachée au nommage des acteurs. L’usage veut de choisir un substantif
extrait du cahier des charges, donc proposé par le client ou l’utilisateur final. En effet, rappelons que les
diagrammes de cas d’utilisation sont une modélisation directe du cahier des charges et servent au client pour
vérifier que l’analyste comprend le problème du client. Il est donc important que l’équipe de développement
s’adapte au client et montre qu’elle s’adapte au domaine applicatif, c’est-à-dire au métier du client.
Cf. le glossaire pour la définition du terme « acteur/actor [class] ».
1. Dans le langage UML, la plupart des éléments de modélisation peuvent être annotés avec ce qui est appelé un stéréotype.
Un stéréotype permet d’étendre un élément de modélisation UML. Dans cette diapositive, le rectangle modélise une classe (voir
la section qui suit pour une définition du terme « classe ») représentant un acteur.
2. C’est par exemple une application B2B (business-to-business) dans laquelle le système en cours de construction s’inscrit.
40
'
$
La généralisation spécialisation est aussi appelée héritage (EST-UN)
« L’organisatrice participe au scrutin qu’elle gère. »
I Une organisatrice est une participante
# 23
&
%
La relation de généralisation spécialisation, aussi appelée relation d’héritage, entre deux acteurs exprime
le fait que l’acteur du côté opposé à la pointe de la flèche « est une sorte de ». Il est spécialisé au sens où
il peut réaliser tout ce que l’acteur plus général peut réaliser, plus d’autres fonctionnalités. Dans l’exemple,
une organisatrice est « une sorte » de personne avec la capacité supplémentaire de créer ou supprimer un
scrutin. L’acteur du côté de la flèche est plus général, au sens où les acteurs spécialisés peuvent, au besoin,
prendre le rôle plus général de l’acteur généralisé. Dans l’exemple, une organisatrice peut prendre le rôle
(être vue comme une) d’une participante et participer à un scrutin.
Cf. le glossaire pour la définition du terme « généralisation spécialisation/generalisation ».
41
'
$
3.2.4 Cas d’utilisation, lien de communication et système
Un cas d’utilisation est un moyen de représenter les différentes possibilités d’un
système
Il correspond à une suite d’interactions entre un acteur et le système
Il définit une fonctionnalité utilisable par un acteur
# 24
&
%
Un cas d’utilisation est « quelque chose » qui fournit un résultat mesurable à un acteur du système ; le
cas d’utilisation capture une fonctionnalité que le système fournit. Un cas d’utilisation décrit les exigences du
système d’un point de vue strictement extérieur au système : il indique la valeur que le système apporte aux
utilisateurs. Ainsi, voyant les fonctionnalités décrites, le client ou l’utilisateur peut indiquer ses priorités, par
analogie aux formules classiques du cahier des charges telles que « le système doit » ou « le système devrait ».
Dans la première formulation, la fonctionnalité est incontournable et doit exister dans une solution minimale
au problème alors que dans la seconde cette fonctionnalité est optionnelle dans une version minimale du
système. Un cas d’utilisation est donc une spécification de séquence d’actions qu’un système peut réaliser en
interaction avec des acteurs extérieurs au système.
Le lien de communication entre un acteur et un cas d’utilisation indique que l’acteur utilise le système
par cette fonctionnalité : il en a besoin, ou autrement dit, il modifie l’état du système en « exécutant »
cette fonctionnalité. Le lien de communication montre l’acteur participant au cas d’utilisation. L’élément
de modélisation est appelé dans la terminologie UML une association. Quelquefois, les diagrammes de cas
d’utilisation ajoutent des flèches, appelées navigabilités, aux liens de communication pour spécifier comment
l’acteur est impliqué dans le cas d’utilisation : l’acteur reçoit des informations ou démarre le cas d’utilisation
et fournit de l’information. Cependant, ce n’est pas le rôle premier du lien de communication ; il est donc
préférable de ne pas mettre de navigabilité.
Les cas d’utilisation du système sont rassemblés dans un rectangle / une boîte pour signifier plus clairement les limites entre l’intérieur et l’extérieur du système. L’équipe n’est pas « payée » pour réaliser les
fonctionnalités hors du périmètre du système.
D’autres relations entre cas d’utilisation existent :
• «include» = réutilisation complète sans changement,
• généralisation spécialisation ou héritage = spécialisation de certaines actions du cas d’utilisation d’origine,
• «extend»1 = ajout de fonctionnalité facultative.
1. Sémantique très controversée, donc évitez d’utiliser «extend»
42
Les relations entre cas d’utilisation ont pour but de décomposer le système en fonctionnalités à granularité
plus fine, suivant ainsi l’adage « diviser pour régner ». Il existe trois types de décompositions ou relations
entre cas d’utilisation, les deux principales étant l’inclusion et l’héritage, la troisième (l’extension) étant
d’utilisation mal aisée et déconseillée2 .
La relation la plus simple à comprendre entre deux cas d’utilisation est l’inclusion notée par une dépendance stéréotypée « «include» ». L’inclusion exprime le fait qu’un cas d’utilisation comprend une séquence
d’actions consécutives qu’il est possible de factoriser avec d’autres cas d’utilisation. Dans notre étude de
cas Studs, la vérification des droits est similaire, à quelques paramètres près, et peut être factorisée pour
la création et la participation à un scrutin. Lorsque le système modélisé atteint une certaine taille, il est
important de montrer les relations d’inclusion qui définissent alors des parties du système réutilisables par
d’autres parties.
La relation de généralisation spécialisation ou héritage est utile pour montrer qu’un cas d’utilisation
est un type spécial d’un autre : le cas d’utilisation le plus spécialisé diffère quelque peu de l’original. Le
premier spécialise certaines étapes de la séquence d’actions du second en les remplaçant par des « versions »
plus spécialisées. Ainsi, toutes les étapes du cas d’utilisation original doivent être exécutées, certaines étant
remplacées par des « versions » plus spécialisées. Dans notre étude de cas, nous pouvons imaginer que le client
demande de concevoir l’authentification comme une « brique » générique spécialisable selon les protocoles
existants. Par exemple, nous spécialisons le cas d’utilisation « vérifier droits » en utilisant la méthode M1 et
créons le nouveau cas d’utilisation « authentification M1 ».
La relation d’extension entre cas d’utilisation est très controversée. Les concepteurs du langage UML
ont voulu montrer qu’un cas d’utilisation peut réutiliser un cas d’utilisation complet, de manière similaire à
l’inclusion, mais que cette réutilisation est optionnelle et dépend des conditions d’exécution. Dans l’exemple
de la figure de cette diapositive, l’authentification par la méthode M1 peut être complétée de manière
facultative par l’enregistrement de toutes les tentatives, y compris celles qui ont été infructueuses, dans le
but d’auditer a posteriori le système ou de lancer des alertes sécurité en cas d’attaques du système lorsque
des suites de tentatives infructueuses proviennent d’un même domaine d’adresse IP (attaque dite de déni de
service).
2. Nous la présentons autant pour complétude que pour la déconseiller.
43
'
$
3.2.5 Exemple de diagramme de cas d’utilisation
# 25
&
%
La figure de cette diapositive montre le diagramme de cas d’utilisation de l’étude de cas Studs. Dans
une première itération de l’analyse, sans recul suffisant, il est risqué d’utiliser toute la panoplie des relations
entre cas d’utilisation. Le premier objectif est plutôt de délimiter les contours du système en identifiant
tous les acteurs, tous les cas d’utilisation, et toutes les utilisations du système, c’est-à-dire tous les liens de
communication. Il est en revanche très intéressant de noter dès que possible les relations de généralisation
spécialisation entre acteurs.
Notez que nous ne demandons pas que vous utilisiez les relations entre cas d’utilisation dans les bureaux
d’étude, donc encore moins dans le bureau d’étude noté. Il est en effet difficile d’avoir suffisamment de recul
pour décomposer le système en fonctionnalités à granularité fine dans le temps qui vous est imparti lors du
bureau d’étude noté. Si vous les utilisez, c’est à vos risques et périls et nous en tenons compte alors dans la
notation.
44
'
$
# 26
Identifier les acteurs qui utilisent, gèrent et exécutent des fonctionnalités spécifiques
Organiser les acteurs par relation de généralisation spécialisation si c’est pertinent
Pour chaque acteur, rechercher les cas d’utilisation du système
&
%
La première étape de l’analyse consiste à bien comprendre le système à étudier. Cela consiste à lire
attentivement le cahier des charges. Cette lecture doit permettre de délimiter le système à étudier : la
méthode générale consiste à retrouver les acteurs qui interagissent avec le système. Il est très important de
fixer des frontières au problème.
Ensuite, il faut rechercher les fonctionnalités du système par la définition de ses « cas d’utilisation ».
Dans le cadre de ce cours, il s’agira de rechercher les principales fonctions attendues du système.
45
'
$
3.3 Diagrammes d’activité *
# 27
3.3.1
3.3.2
3.3.3
3.3.4
Scénarios d’un cas d’utilisation * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Actions et choix * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Concurrence * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Autres notations du diagramme d’activité * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
&
%
Un cas d’utilisation montre ce que fait ou doit faire le système. Un diagramme d’activité permet de
spécifier comment le système accomplit les fonctionnalités demandées. Un diagramme d’activité montre les
actions à un très haut niveau d’abstraction avec les interactions entre elles. Dans la pratique, les diagrammes
d’activité sont bien adaptés à cette phase de l’analyse qui consiste en l’expression des processus métier comme
un ensemble d’actions coordonnées pour atteindre un but.
Nous présentons les diagrammes d’activité dans ce cours mais n’aurons pas le temps de les pratiquer lors
des bureaux d’étude.
46
'
$
3.3.1 Scénarios d’un cas d’utilisation *
La description d’un cas d’utilisation se fait par des scénarios qui définissent la suite
logique des actions qui constituent ce cas
Il est possible de définir des scénarios simples ou des scénarios plus détaillés faisant
intervenir les variantes, les cas d’erreurs, etc.
La description du scénario précise ce que fait l’acteur et ce que fait le système
# 28
En plus de descriptions textuelles, le scénario peut être représenté en utilisant un
diagramme d’activité
Le diagramme d’activité permet de :
Présenter « l’algorithme », c’est-à-dire les étapes de la fonctionnalité
Visualiser l’aspect temporel des interactions
Connaître le sens des interactions (acteur vers système ou inverse)
Distinguer le cas nominal des variantes (p.ex. avec traitement des erreurs)
&
%
La description d’un scénario peut se faire de manière simple, par un texte compréhensible par les personnes
du domaine de l’application. Elle peut aussi être détaillée pour préciser les contraintes de l’acteur et celles du
système, les différentes étapes ou actions avec leurs enchaînements et leurs concurrences. Cette description
détaillée est dans la suite modélisée dans des diagrammes d’activité.
Les diagrammes d’activité sont avec les diagrammes de cas d’utilisation les diagrammes les plus facilement
compréhensibles des non-spécialistes du développement d’applications informatiques. En effet, l’aspect des
diagrammes d’activité ressemble beaucoup à celui des ordinogrammes ; ils sont donc accessibles à une audience
très large.
47
'
$
3.3.2 Actions et choix *
# 29
&
%
Les diagrammes d’activité visualisent les étapes des cas d’utilisation et plus particulièrement les enchaînements et les branchements. Une activité débute par un nœud initial représenté par un disque noir. Cette
action marque le début de l’activité et est suivi d’arêtes représentant le passage à l’action suivante. À l’autre
extrémité du diagramme, le nœud terminal ou final signifiant la fin de l’activité est représenté par un disque
noir entouré d’un second disque. Entre les deux extrémités, les actions importantes du scénario sont reliées
entre elles de façon à montrer le flot de l’activité : les enchaînements ou séquences et la concurrence (parallélisme). Le premier type de losange est appelée une décision et simule le début d’une instruction « si-alors ».
Les conditions sont appelées des gardes. Le second type de losange signifie la fusion des branches à la fin
du « si-alors ». Bien sûr, une attention particulière doit être apportée aux conditions pour qu’elles soient
mutuellement exclusives et complètes. Le standard UML indique que si plusieurs gardes sont valides alors
une seule branche est parcourue et le choix de la branche est aléatoire. Ce comportement ne correspond que
très rarement au souhait de l’auteur du diagramme. En outre, les conditions doivent être complètes pour
éviter que l’activité ne soit bloquée ou gelée indéfiniment parce qu’aucune des conditions n’est valide. Par
analogie avec les instructions « switch » des langages de programmation, il est ainsi judicieux de penser
à ajouter une garde « sinon » représentant le chemin par défaut à emprunter si aucune des autres gardes
n’est vraie.
Cf. le glossaire pour la définition du terme « action ».
48
'
$
3.3.3 Concurrence *
# 30
&
%
Les actions qui se déroulent en même temps sont dites concurrentes. Elles sont modélisées entre deux
traits épais comme des chemins parallèles, le premier de ces traits étant appelé « fork » et le second « join ».
Les séquences d’actions en parallèle débutent en même temps, sont toutes exécutées, mais par définition ne
finissent pas au même instant. La fin de l’action join intervient lorsque toutes les actions en parallèle se
terminent ; join est donc un point de synchronisation.
49
'
$
3.3.4 Autres notations du diagramme d’activité *
# 31
&
%
Le diagramme d’activité possède d’autres notations que nous citons pour information mais n’illustrons
pas. Le diagramme d’activité permet d’exprimer le passage du temps avec le symbole du sablier. Il est ainsi
possible de modéliser une activité qui s’exécute périodiquement en remplaçant l’action initiale par un sablier.
Il est aussi possible, à partir d’une activité, d’appeler une autre activité et d’indiquer entre deux actions
les informations transmises (montrant ainsi les flux d’informations en plus des flots d’actions).
Les interactions entre le système et les acteurs sont modélisées sous la forme de signaux émis et reçus.
Enfin, le langage UML fournit d’autres notations que nous ne montrons pas : la fin d’un chemin, le
partitionnement, les connecteurs, les expansion regions. Pour plus d’information, nous invitons les curieux à
se référer à la bibliographie ou directement au standard.
50
'
$
QCM
1. Dans un diagramme de cas d’utilisation, est-il pertinent d’ajouter des cas
d’utilisation ne faisant pas partie du système ?
2. Quelles entités peuvent être dessinées dans un diagramme de cas d’utilisation ?
# 32
(a) système
(b) action
(c) acteur
(d) généralisation spécialisation
3. Dans une généralisation spécialisation entre acteurs, l’acteur spécialisé a-t-il accès à
toutes les fonctionnalités de l’acteur généralisé ?
&
%
51
'
$
# 33
4.1
4.2
4.3
4.4
Diagrammes communs à l’analyse et à la conception . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Diagramme d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Concepts avancés du diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
&
%
Après l’élection des besoins exprimés sous la forme de fonctionnalités modélisées comme des cas d’utilisation et sous la forme de scénarios modélisés dans des diagrammes d’activité, nous pouvons modéliser la
structure logique du système, c’est-à-dire les aspects statiques du système. Cette modélisation est en grande
partie effectuée dans des diagrammes de classes, avec éventuellement des diagrammes d’objets montrant
des configurations spécifiques du système dans des conditions particulières. Le contenu principal de cette
section est donc la présentation des éléments de modélisation du diagramme de classes. Avant d’introduire
les diagrammes de classes et d’objets, et puisque ces deux diagrammes sont aussi utilisés pendant la phase
suivant l’analyse, c’est-à-dire pendant la conception, nous expliquons en quelques mots les différences entre
ces deux phases.
La présentation du diagramme de classes est effectuée en deux parties : les concepts de base et les concepts
avancés. Pendant les bureaux d’étude et pendant le bureau d’étude noté, les solutions que vous concevez
n’ont pas besoin d’utiliser les concepts avancés qui demandent plus de recul pour être mis en œuvre. Souvent,
ces concepts sont introduits dans les diagrammes de classes après la première itération. Or, vous n’avez pas
le temps de faire plus d’une itération dans tous les cas. Cependant, à la fin du premier bureau d’étude,
nous présentons une seconde version du corrigé type utilisant une bonne partie de la panoplie des concepts
avancés du diagramme de classes. C’est cette version qui ensuite sert de base aux autres bureaux d’étude et
aux travaux pratiques. Ainsi, vous aurez l’occasion de manipuler les concepts avancés dès la modélisation.
52
Introduction au langage de modélisation UML 4 Analyse et conception, aspects statiques de la vue logique
'
$
4.1 Diagrammes communs à l’analyse et à la conception
Vue logique
Aspects statiques = structure du problème et de la solution
I Diagrammes de classes et d’objets
Aspects dynamiques = comportement des éléments de la structure
I Diagrammes de séquence, de communications et de machine à états
# 34
&
%
La conception est une phase charnière entre la spécification du problème et l’implantation de la solution. Il
est donc important de garder la trace des décisions de conception : telle exigence extraite du cahier des charges
et spécifiée dans l’analyse est traduite par tels et tels éléments du modèle de conception. C’est une des raisons
qui explique que certains diagrammes sont utilisés dans le modèle de l’analyse et dans celui de la conception,
la conception consistant à compléter ou raffiner le modèle de l’analyse avec des éléments techniques, par
exemple comment rendre l’application accessible par un service Web sur l’intranet de l’entreprise.
53
'
$
4.2 Diagramme de classes
# 35
4.2.1 Modéliser la structure logique du système dans un diagramme de classes . . . . . . 36
4.2.2 Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.3 Instanciation : création d’un objet d’une classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.4 Attributs et opérations de classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
4.2.5 Attribut dérivé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.6 Association entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.7 Nom de rôle et multiplicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.8 Généralisation spécialisation ou héritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.9 Généralisation spécialisation : vision ensembliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.10 Généralisation spécialisation : vision encapsulation. . . . . . . . . . . . . . . . . . . . . . . . . . .45
4.2.11 Généralisation et redéfinition d’opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.12 Méthode Polymorphique et liaison dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.13 Agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.14 Exemple de diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.15 Éléments de méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
&
%
Les diapositives qui suivent sont très importantes pour comprendre les concepts de base de l’orientation
objet. Autant les autres types de diagrammes peuvent être spécifiques à la modélisation et ne pas trouver
de correspondance dans les langages de programmation orientés objet, autant tous les concepts présentés
dans cette section, d’une part, trouvent une correspondance dans les langages de programmation orientés
objet comme Java, et d’autre part, sont importants pour comprendre la philosophie de l’orientation objet.
Les principes de base présentés dans cette section sont complétés par la suite avec des concepts un peu plus
avancés.
Le diagramme de classes décrit les classes et les relations entre les classes. En bref, les classes possèdent
des attributs et des opérations. Les relations entre classes peuvent être de différents types : l’association
(binaire), la généralisation spécialisation ou héritage, l’agrégation, etc. Une association possède un sens de
lecture du verbe la nommant, une navigabilité indiquant dans quel sens l’association peut être parcourue.
Chaque extrémité de l’association possède un rôle spécifiant le rôle de la classe dans l’association par rapport
à l’autre extrémité, ainsi qu’une multiplicité.
Rappel : les diagrammes de classes construits lors des bureaux d’étude et du bureau d’étude noté n’ont
pas besoin d’utiliser de concepts avancés. Cependant, tous les concepts, y compris les concepts avancés, font
partie du programme du module CSC4002 et sont mis en œuvre dans les travaux pratiques.
54
'
$
4.2.1 Modéliser la structure logique du système dans un
diagramme de classes
Diagramme au cœur de l’analyse et de la conception orientées objet
Abstraction
Abstraire = ignorer / cacher des caractéristiques non significatives
Ne garder que les caractéristiques d’une classe importantes pour l’intervenant
I Analyste versus architecte ou concepteur
# 36
Encapsulation comme mécanisme d’abstraction
Cacher des détails en les rendant « privés » (non visibles)
I Par exemple, en analyse, montrer le « quoi » qui est « public » (visible)
Puis, en conception, détailler en ajoutant les éléments pour le « comment »
=⇒ Protège l’analyse des changements effectués lors de la conception dans la
partie « privée » en ne remettant pas en cause ce qui est exposé
« publiquement » au niveau métier
F Par exemple, l’analyse spécifie que tel élément est un ensemble
La conception précise que c’est une liste doublement chaînée
&
%
Les éléments de base de la structure logique du système sont les classes. La définition d’une classe
contient les détails d’un élément de cette structure qui sont importants pour l’intervenant (analyste versus
architecte ou concepteur) et le système modélisé. Retirer des détails non significatifs à une étape donnée
du développement s’appelle l’abstraction. Les diagrammes de classes de l’analyse sont plus abstraits que les
mêmes diagrammes repris et raffinés lors de la conception.
Très liée au concept d’abstraction, l’encapsulation est une particularité de l’orientation objet. L’encapsulation permet à chaque élément structurel de base, c’est-à-dire à chaque classe, de cacher des détails, soit des
données contenues dans l’élément soit des actions possibles sur l’élément. Nous verrons ainsi qu’une classe
peut n’exposer que certaines de ses caractéristiques. L’encapsulation est très importante car elle permet
de passer de manière gracieuse de l’analyse à la conception en exposant tout d’abord les caractéristiques
pertinentes pour le métier de l’application (le « quoi ») et ensuite en montrant aux développeurs des caractéristiques particulières donnant les indications sur le « comment ». Cela protège l’analyse des changements
effectués lors de la conception dans la partie « privée » en ne remettant pas en cause ce qui est exposé
« publiquement » au niveau métier.
55
'
$
4.2.2 Classe
Classe = famille d’objets ayant les mêmes caractéristiques et le même comportement
Attributs = caractéristiques (données membres, informations, propriétés)
Opérations = comportement (méthodes, fonctions, procédures, messages,
services)
# 37
&
%
Les classes décrivent les différents types d’objets1 que le système possède. Une classe est un type de
quelque chose. Vous pouvez penser à une classe comme à un modèle (au sens patron) à partir duquel les
instances ou objets2 conformes au type défini par la classe sont créés.
La description de la classe inclut deux catégories d’informations : l’état définissant les informations que les
objets de la classe contiennent et le comportement que les objets de la classe autorisent (au sens « services »
qu’ils rendent). La conjonction de l’état et du comportement caractérise l’orientation objet par rapport aux
autres approches en génie logiciel, par exemple qui séparent les données des traitements. Ainsi, en orienté
objet, le comportement d’un objet d’une classe définit les transformations sur l’état de l’objet de la classe.
Une classe peut être vue comme une structure de données appariée avec des procédures utilisant la structure.
L’état d’un objet d’une classe est défini par un ensemble d’attributs et le comportement de l’objet par un
ensemble d’opérations3 sur ses attributs. Un attribut est une information portée par un objet. Par convention,
le nom d’un attribut commence par une lettre minuscule. Une opération spécifie une transformation de l’état
de l’objet. Elle possède un nom (par convention, commençant par une lettre minuscule), une éventuelle liste
de paramètres et un éventuel type de retour. Par conséquent, une classe rassemble la spécification d’objets
possédant les mêmes attributs et les mêmes opérations.
Grâce aux mécanismes d’encapsulation, lors de l’analyse, les premiers attributs et les premières opérations
sont spécifiés. D’autres attributs et d’autres opérations peuvent être ajoutés par la suite lors de la conception
(pour prendre en compte une préoccupation technique comme la persistance), voire lors de l’implantation
(pour par exemple optimiser un comportement).
La notation UML autorise à représenter une classe uniquement avec son nom, ou avec son nom et ses
attributs, ou avec son nom et ses opérations, ou encore avec les trois caractéristiques. Lorsque des attributs
ou des opérations ne sont pas présents, cela signifie que celui qui a construit le diagramme visualisé estime
que les caractéristiques non représentées ne sont pas assez pertinentes dans la vue qu’il a choisi. (Il est bien
sûr possible de discuter et contester les choix de l’auteur du diagramme.)
Cf. le glossaire pour la définition des termes « classe/class », « attribut/attribute », et « opération/operation ».
1. Le terme « objet » est ici pris dans son acception générale.
2. Cette fois-ci, au sens orienté objet du terme.
3. Aussi appelées des méthodes dans les langages orientés objet.
56
'
$
4.2.3 Instanciation : création d’un objet d’une classe
Instanciation = création d’un objet à partir d’une classe
Objet = instance de classe
# 38
&
%
Un objet est une instance d’une classe. Le mécanisme qui crée des objets à partir (de la spécification)
d’une classe s’appelle l’instanciation. Autrement dit, un objet est une variable conforme à un type, qui est
une classe. Les opérations de l’objet utilisent les valeurs des attributs de l’objet. En outre, un objet possède
une identité qui permet de le distinguer des autres objets. On accède à un objet via une référence qui pointe
sur l’objet. Ainsi, dans l’instruction « Personne j ; », j est déclarée comme étant une référence sur un objet
de type Personne.
Cf. le glossaire pour la définition du terme « objet/object ».
57
'
$
4.2.4 Attributs et opérations de classe
Le nombre total de participations est une caractéristique des personnes (classe),
donc applicable à Julien Dupont (objet)
L’opération getNbTotalParticipations() utilise la valeur de l’attribut
nbTotalParticipations connue par la classe
Cette opération peut être appliquée directement à la classe Personne et bien sûr
aussi aux objets / instances de Personne
# 39
&
%
Par défaut, les attributs et les opérations sont dits des attributs et des opérations d’instances. Pour un
attribut, cela signifie que chaque objet possède sa propre valeur, c’est-à-dire son propre espace mémoire pour
mémoriser sa valeur. Un attribut de classe est un attribut partagé par toutes les instances de la classe, c’est-àdire l’espace mémoire d’un attribut de classe est un espace partagé par toutes les instances / objets de la classe
n’ayant pas leur propre espace mémoire de cet attribut de classe. Dans les diagrammes, les attributs et les
opérations de classe se différencient des attributs et des opérations d’instance par le fait qu’ils sont soulignés.
En outre, par déduction, les attributs de classe existent indépendamment de la présence d’instances de la
classe. En conséquence, les opérations de classe peuvent aussi être appelées indépendamment de l’existence
d’instances de la classe. Ainsi, on peut écrire les expressions suivantes, le point indiquant l’accès à un attribut
ou à une opération (similairement aux caractères « -> » du langage C) :
j.nom
j.nbTotalParticipations
Personne.nbTotalParticipations // cette forme est préférée car elle rend explicite
// l’aspect attribut de classe
j.voter()
j.getNbTotalParticipations()
Personne.getNbTotalParticipations() // cette forme est préférée car elle rend explicite
// l’aspect opération de classe
58
'
$
4.2.5 Attribut dérivé
Attribut dérivé = attribut dépendant d’autres attributs
# 40
&
%
Dans les diagrammes de classes, il est important que les informations ne soient pas redondantes. Une
forme de redondance est un attribut dérivé dont la valeur se calcule à partir des valeurs d’un ou plusieurs
autres attributs. Dans ce cas, l’attribut dérivé doit être signalé en préfixant le nom de l’attribut avec une
barre oblique « / » afin d’indiquer au lecteur que cet attribut est redondant. C’est une indication importante
pour ceux qui implantent l’application car les attributs dérivés demandent un traitement spécial : leur valeur
change à chaque fois que la valeur des attributs à partir desquels ils sont calculés change. Dans notre exemple,
le traitement est même un peu plus complexe car la valeur de l’attribut « âge » évolue aussi en fonction d’un
paramètre indépendant de l’application : la date du jour.
Cf. le glossaire pour la définition du terme « élément dérivé/derived element ».
59
'
$
4.2.6 Association entre classes
Association (binaire) = relation entre (deux) classes
Le sens de lecture est facultatif lorsqu’il n’y a pas d’ambiguïté
# 41
&
%
Une association est une relation entre classes qui exprime les relations entre leurs instances. Une association permet de naviguer entre classes. Une association possède un nom constitué classiquement d’un verbe
conjugué (la plupart du temps au présent). Le sens de lecture permet de lire l’association en prenant le nom
de la classe d’origine comme sujet, le nom de l’association comme verbe, et le nom de la classe destinatrice
comme complément d’objet direct. Dans notre exemple, cela donne « une Personne organise un Scrutin ».
Dans l’autre sens, il suffit souvent de mettre le verbe au passif. Dans notre cas, nous pouvons dire quelque
chose comme « un Scrutin est organisé par une Personne ».
Cf. le glossaire pour la définition du terme « association ».
60
'
$
4.2.7 Nom de rôle et multiplicité
Nom de rôle = indication sur la participation de la classe à l’association
Multiplicité = contrainte sur le nombre d’objets associés
# 42
&
%
Dans les diagrammes de classes, il est possible de nommer les extrémités des associations, ce sont des
noms de rôle, lorsqu’il existe un risque de confusion quant à la participation d’une classe à une association.
Les noms de rôle sont donc indiqués par exemple lorsqu’ils ne sont pas évidents ou lorsque la classe participe
à plusieurs associations, tout spécialement avec la même classe. Les noms de rôle sont donc une information
marquant visuellement une information importante : il ne faut pas en abuser.
Les associations relient des classes. Chaque extrémité d’une association possède une multiplicité ou cardinalité. La multiplicité est placée de l’autre côté de la classe utilisée comme sujet, du côté du complément
d’objet direct. Dans notre exemple, une personne organise 0 ou plusieurs scrutins, et un scrutin est organisé
par 1 personne. La diapositive donne les multiplicités possibles. La notation est la suivante : min..max, où
• max peut être omis, auquel cas la multiplicité est exactement min ;
• max peut prendre la valeur « * » qui signifie une limite non bornée (par exemple « 2..* » signifie 2 ou
plus) ;
• la notation « 0..* » peut être abrégée en « * » ;
• la multiplicité 1 est généralement omise pour des raisons de lisibilité.
Cf. le glossaire pour la définition des termes « association binaire/binary association », « rôle/role »,
« multiplicité/multiplicity », « cardinalité/cardinality », et « association n-aire/n-ary association ».
61
'
$
4.2.8 Généralisation spécialisation ou héritage
Factorisation de caractéristiques (attributs et opérations)
EST-UN, EST-UNE-SORTE-DE
# 43
&
%
Le but de la généralisation est la factorisation des caractéristiques de plusieurs classes appelées classes
enfants1 dans une classe appelée classe parente2 . Cette mise en commun des attributs (structures de données)
et des opérations (services) est le mécanisme de réutilisation le plus important de l’orientation objet. La
factorisation intervient aussi bien en définissant une partie d’état commune (attributs) qu’en extrayant
les comportements communs (opérations). La classe parente rassemble donc les attributs et les opérations
communes des classes initiales qui deviennent des classes enfants. La généralisation spécialisation s’appelle
aussi un héritage et exprime intuitivement le fait que les classes enfants « héritent » des caractéristiques
de leurs classes parentes. La généralisation exprime une relation de type « est-un » ou « est-une-sorte-de ».
En outre, le terme « généralisation » exprimant la factorisation des caractéristiques communes dans la
classe parente, le terme « spécialisation » exprime quant à lui le fait que les classes enfants possèdent les
caractéristiques de leurs classes parentes avec la possibilité de les spécialiser soit par des ajouts soit par des
redéfinitions (voir plus loin). En d’autres termes, une classe enfant possède les capacités de sa classe parente
plus quelques autres.
Généralisation spécialisation et sous-typage :
• un objet Personne peut désigner une instance des classes Personne, Avocat, Vendeur, Enseignant,
Vacataire et Permanent ;
• un objet Enseignant peut désigner une instance des classes Enseignant, Vacataire et Permanent ;
– il ne peut pas désigner une instance des classes Personne, Avocat et Vendeur.
L’exemple présenté dans cette diapositive illustre des héritages dits « simples » dans le sens où les
classes enfants ne possèdent qu’une filiation. Il est possible d’avoir de l’héritage multiple comme montré
dans l’exemple du schéma qui suit. Cette possibilité n’existe pas dans tous les langages de programmation
orientés objet. Nous déconseillons donc l’utilisation de l’héritage multiple en modélisation car l’équipe de
développement peut choisir un langage ne proposant pas cette possibilité. Dans ce cas, le diagramme de
classes doit alors être adapté, compliquant ainsi la traçabilité depuis le modèle d’analyse vers l’implantation.
Le langage de programmation choisi dans ce module, en l’occurrence Java, n’autorise pas l’héritage multiple.
Enfin, de façon plus intrinsèque, nous déconseillons l’utilisation de l’héritage multiple car il pose des
problèmes d’interprétation. Par exemple, que fait-on lorsqu’un attribut ou une opération existe « en double »
ou « triple » dans les classes parentes. Dans l’exemple qui suit, dans la classe VoitureAmphibie, comment
interprète-t-on l’opération avancer() héritée de la classe parente « racine » Véhicule et ensuite spécialisée
dans les classes parentes VéhiculeTerrestre et VéhiculeMarin ?
1. Ou sous-classes, ou encore classes dérivées.
2. Ou super-classe.
62
La figure qui suit montre une visualisation du concept de généralisation / spécialisation multiple. L’ensemble des objets de la classe VoitureAmphibie représente l’intersection des ensembles d’objets des deux
classes parentes, VéhiculeTerrestre et VéhiculeMarin.
Cf. le glossaire pour la définition des termes « généralisation spécialisation/generalisation », « héritage/inheritance », et « généralisation spécialisation multiple/multiple inheritance ».
63
'
$
4.2.9 Généralisation spécialisation : vision ensembliste
# 44
&
%
La figure de cette diapositive représente de manière intuitive les liens de parenté sous la forme de relations
entre ensembles : l’ensemble des Personne contient les ensembles des Avocat, des Vendeur, des Enseignant,
etc.
64
'
$
4.2.10 Généralisation spécialisation : vision encapsulation
# 45
&
%
La figure de cette diapositive représente de manière intuitive l’encapsultation des données et des comportements : un objet de type Vacataire possède toutes les caractéristiques (attributs et opérations) du type
Enseignant, qui contient lui-même toutes les caractéristiques (attributs et opérations) du type Personne.
Cf. le glossaire pour la définition du terme « encapsulation ».
65
'
$
4.2.11 Généralisation et redéfinition d’opérations
# 46
&
%
Rappelons que la déclaration d’une opération consiste en la spécification de son nom, des types de
ses paramètres et de son type de retour. La définition d’une opération consiste à lui adjoindre un corps
représentant un algorithme. Dans cette diapositive, une opération définie (calculerAmortissement()) dans
une classe parente est redéfinie (en anglais, overriden) dans une classe enfant, c’est-à-dire que la classe
enfant remplace la définition de l’opération spécifiée dans la classe parente par son propre algorithme. Dans
l’exemple de la diapositive, l’algorithme de calcul de l’amortissement d’un moyen de transport tel que défini
dans la classe MoyenTransport ne tient pas compte de l’infrastructure. En effet, l’amortissement d’un Camion
ou d’une Voiture ne prend pas en compte celui des routes empruntées. En revanche, les analystes décident
que ce calcul dans le cas d’un Tramway inclut les voix ferrées de la ligne. En conséquence, l’opération
calculerAmortissement() est redéfinie (même prototype, mais corps d’opération différent) dans la classe
Tramway.
NB : la notion de redéfinition (en anglais, overriding) est proche mais différente de la notion de surcharge
(en anglais, overloading). Une opération surcharge une autre opération, qu’elle soit déclarée (voire définie)
dans la même classe ou dans une classe parente, lorsque la nouvelle opération possède le même nom que
l’opération existante mais avec un prototype différent (nombre ou types des paramètres différents).
Exemple de surcharge :
constructeurMoyenTransport(String désignation, int vitesse, double prix) // age = 0
constructeurMoyenTransport(String désignation, int vitesse, double prix,
int age) // surcharge = même nom, mais paramètres différents
66
'
$
4.2.12 Méthode Polymorphique et liaison dynamique
Méthode polymorphique :
Un objet d’une classe enfant peut prendre plusieurs formes
I L’objet peut être utilisé partout où un objet de la classe parente est attendu
F Exprimant que la classe enfant est une spécialisation de la classe parente
F P.ex., void o(MoyenTransport r) accepte o(e) avec e de type Tramway
Liaison dynamique ou tardive :
# 47
Soient une classe P et o() une opération de P
Soient e un objet d’une classe E, enfant de la classe P
et o() l’opération redéfinie dans E
Soit r une référence sur un objet de type P
Le polymorphisme autorise à affecter à r la valeur e : r ← e
Si l’opération o() est appelée sur la référence r : r.o()
et s’il y a liaison dynamique (ce qui est toujours le cas en Java p.ex.)
I C’est l’opération redéfinie dans la classe enfant qui est appelée
soit l’opération o() redéfinie dans E
&
%
Le prototype d’une méthode contient des déclarations de types primitifs et de références sur des objets.
Ces types sont dits les types formels de la méthode. Lors de l’exécution, les types des objets passés en
argument de la méthode sont appelés les types effectifs. Lorsqu’une référence d’une classe est attendue, une
référence sur un objet d’une classe enfant peut être donnée. C’est le principe du polymorphisme des méthodes.
La relation entre le type formel et le type effectif est donc contrainte par la relation de généralisation
spécialisation. Cette substitution de type est possible lors de l’exécution puisque par définition l’objet de
la classe spécialisée fait tout ce que la classe parente fait, plus des choses supplémentaires. Si cette classe
spécialisée a redéfini (spécialisé) le comportement d’une opération de la classe parente, nous souhaitons que
ce soit le comportement spécialisé qui soit utilisé à la place du comportement de la classe parente. C’est ce
que permet la liaison dynamique, aussi appelée liaison tardive.
Prenons un autre exemple avec le diagramme de classes suivant.
Écrivons une opération acheterMaison() avec la définition suivante.
void acheterMaison(Personne acheteur) {
...
acheteur.changerAdresse();
...
}
Les instructions suivantes sont toutes valides (la compilation et l’exécution ne violent pas le système de
type du langage orienté objet) avec les déclarations correspondantes. En effet, tout objet d’une classe enfant
peut être utilisé là où un objet de la classe parente est attendu. En outre, l’opération effectivement appelée
/ exécutée pour l’objet jean est celle définie dans la classe Personne car jean est une instance de cette
classe. Pour l’objet pierre, c’est celle définie dans la classe enfant Avocat qui est utilisée car l’opération est
redéfinie dans la classe enfant Avocat. Enfin, pour l’objet paul, l’opération choisie à l’exécution est, selon la
règle de « la définition de la classe la plus spécialisée », celle de la classe Enseignant.
Personne jean; Avocat pierre; Vacataire paul;
67
acheterMaison(jean); // licite car jean est une Personne
acheterMaison(pierre); // licite car pierre est d’une classe enfant de Personne
acheterMaison(paul); // licite car paul est d’une classe enfant de Personne
68
'
$
4.2.13 Agrégation
Agrégation = une association exprimant un couplage fort lié à une relation de
subordination
A-UN, EST-UNE-PARTIE-DE
Elle est asymétrique du type « ensemble / élément » ou « contenant / contenu »
Règles permettant de choisir une agrégation :
# 48
Est-ce une partie de ?
Les opérations appliquées à l’ensemble sont-elles appliquées à l’élément ?
Les changements d’états sont-ils liés ?
Attention :
Un élément agrégé peut être lié à d’autres classes
La suppression de l’ensemble n’entraîne pas celle de l’élément
&
%
Dans les diagrammes de classes, nous sommes souvent appelés à utiliser des associations que nous nommerions contient ou appartient à. En fait, cet usage est tellement fréquent que UML a défini une notation spécifique pour ce type d’association, l’agrégation. Une agrégation exprime une relation « contenant /
contenu » ou « ensemble / élément », ou encore « agrégé / agrégat ». Par analogie avec la généralisation
spécialisation qui se repère par la relation « est un », l’agrégation se repère par la relation « est une partie
de » ou « a un » et le couplage fort entre l’ensemble et les éléments. Par exemple, déplacer un Polygone
revient à déplacer ses Points. Il est important de noter que l’agrégation autorise qu’un élément de l’ensemble appartienne à un autre ensemble. Nous verrons plus tard que ce n’est pas le cas de la composition,
une relation exprimant une relation de couplage encore plus fort : un élément appartient exclusivement à un
ensemble.
Cf. le glossaire pour la définition du terme « agrégation/aggregation ».
69
'
$
4.2.14 Exemple de diagramme de classes
# 49
&
%
Cette diapositive représente le diagramme de classes de l’étude de cas Studs. La diapositive suivante
donne des éléments de méthodologie pour construire ce diagramme de classes à partir du cahier des charges.
Ce diagramme de classes est le premier de l’analyse de l’étude de cas ; aucune opération n’est indiquée. Ce
diagramme est ensuite raffiné en ajoutant les opérations et en complétant la liste des attributs. Comme nous
le verrons dans la section suivante, cela est souvent effectué lors de l’analyse de la dynamique du système en
construisant les diagrammes de machine à états, de séquence et de communications.
70
'
$
Analysez le texte pour rechercher les noms qui sont des classes métier et les verbes
qui les relient qui sont des associations
Construisez un premier diagramme de classes à partir de ces noms
Enrichissez ce diagramme avec les associations à l’aide des verbes obtenus
Affinez le diagramme en éliminant les associations redondantes,
en simplifiant le schéma dès lors qu’il respecte les spécifications de l’énoncé
# 50
Ne cherchez les généralisations spécialisations que lorsque les classes sont déjà bien
établies
Ne cherhez les agrégations qu’à la fin
Terminez cette première version du diagramme en ajoutant les multiplicités
Dans une seconde itération seulement, ajoutez les attributs et les opérations
Pensez à vérifier que tous les concepts métier sont présents
Pensez à vérifier que vous pouvez réaliser les cas d’utilisation par parcours du
graphe de classes
&
%
La seconde étape de l’analyse consiste à analyser le texte du cahier des charges, afin d’y rechercher les
différentes classes métier et leurs associations. Il est préférable de sur-spécifier le modèle d’analyse avec
beaucoup de classes métier ; il sera plus facile de les regrouper plus tard que de trouver celles que nous
aurions ignorées. Recherchez les noms qui correspondent le plus souvent aux classes métier, et les verbes qui
les relient qui correspondent aux associations ; attention toutefois à certains verbes (comme le verbe être)
qui peuvent correspondre à des attributs ou à des opérations. L’opération habituelle consiste à établir des
listes exhaustives puis à les trier / sélectionner afin de ne garder que celles utiles à la résolution : suppression
des classes métier trop vagues ou non pertinentes, élimination des noms ou verbes inutiles car ce peut être
du bruit introduit lors de la rédaction du cahier des charges, chasse aux synonymes, etc.
Une autre manière de trouver ces classes métier est de partir des cas d’utilisation : dans les descriptions des
actions effectuées par les acteurs, les noms sont des classes métier et les verbes utilisés sont des associations.
Remarquez que, partant d’un énoncé, cette méthode d’analyse n’est pas une fin en soi : les limites sont
celles apportées par un texte ; cela nécessite un dialogue avec le « client ». Il est important de bien choisir le
nom des classes métier et des associations : on retrouve en général des noms pour les classes métier et des
verbes pour les associations.
Nous vous conseillons de :
• construire un premier diagramme de classes à partir des noms obtenus dans la phase précédente,
• par étapes successives, enrichir ce diagramme avec les associations à l’aide des verbes obtenus,
• affiner le diagramme en éliminant les associations redondantes en simplifiant le schéma dès lors qu’il
respecte les spécifications de l’énoncé,
• ne chercher les généralisations et spécialisations qu’à la fin, lorsque les classes sont déjà bien établies.
Concernant les associations, recherchez les relations simples, les relations d’agrégation et les relations de
généralisation spécialisation. Ensuite, trouvez la multiplicité / cardinalité de chaque association et portez-la
sur le schéma si elle diffère de la valeur par défaut (« 1 »).
Enfin, trouvez les attributs et les opérations des classes. À ce niveau, quelques retours en arrière sont
possibles à cause d’oublis ou de mauvaises compréhensions du système. Lors de l’analyse, il s’agit des attributs
ou opérations que les spécifications du problème nécessitent : ils sont liés au modèle statique. Dans la partie
conception, d’autres attributs et opérations sont trouvés, comme par exemple utilisant des classes dites
« techniques ». Si un nom est associé à une valeur (nombre, texte, etc.) dans le monde réel, alors il s’agit
certainement d’un attribut. Dans le doute, en faire une classe métier. Un critère de validité d’un attribut est
qu’il doit être simple (type/valeur) : par exemple, date, nombre, texte. Dans le cas contraire, en faire une
71
classe métier. D’autre part, les classes métier doivent être reliées entre elles par des associations et non avec
des attributs.
Pour placer une opération dans une classe, recherchez la classe responsable : c’est celle qui détient toutes
les informations nécessaires pour effectuer l’opération. En cas de création, cela devrait être la classe conteneur
(agrégation) ou celle qui détient les valeurs d’initialisation. Concernant les opérations, le niveau de détail
d’un diagramme de classes de l’analyse doit rester faible afin de ne pas empiéter sur la phase de conception.
Pour valider le diagramme de classes, reprenez l’énoncé et vérifiez que toutes les spécifications demandées
y sont présentes : cela consiste à vérifier que vous répondez à tous les cas d’utilisation. Dans le cas contraire,
reprenez le schéma et corrigez-le. Dans certains cas, cela peut remettre énormément de choses en question.
Vous devez également contrôler si des fonctionnalités nouvelles ont été ajoutées par rapport à l’énoncé. Ces
nouveautés doivent rester mineures : « vous n’êtes pas payés pour faire plus que ce que demande le client ».
72
'
$
4.3 Diagramme d’objets
Illustration des liens entre objets dans un scénario / une configuration donnée
# 51
&
%
Un diagramme d’objets est particulièrement utile quand vous voulez décrire comment les objets dans le
système « travaillent » ensemble dans un scénario donné. Un diagramme d’objets représente une configuration
donnée. La notation UML de l’objet est très simple. Un objet est un rectangle avec le nom de l’objet et le
nom de la classe séparés par le signe « : » et soulignés. Le nom de l’objet est facultatif : sans nom d’objet,
l’objet est dit « anonyme ». Lorsque deux classes sont reliées par deux associations, le nom de l’instance
d’association dessinée doit être précisée pour lever l’ambiguïté. Clairement, un diagramme d’objets doit
respecter les contraintes d’un diagramme de classes : par exemple, ne pas tracer de liens entre deux objets
dont les classes ne sont pas reliées dans le diagramme de classes.
Cf. le glossaire pour la définition du terme « objet/object ».
73
'
$
QCM
1. Quelles entités peuvent être dessinées dans un diagramme de classes ?
(a) opération
(b) acteur
(c) généralisation spécialisation
(d) association
# 52
2. Une classe est-elle une instance d’objet ?
3. Dans un diagramme de classes, tous les attributs d’une classe doivent-ils être
spécifiés ?
4. Sans multiplicité spécifiée explicitement, est-il supposé par défaut « * » ?
5. La généralisation spécialisation est-elle représentée par une relation avec un triangle
blanc à une extrémité ?
6. Soit E une classe enfant de la classe parente P, tout objet de classe E peut-il être
utilisé là où un objet de type P est attendu ?
&
%
74
'
$
4.4 Concepts avancés du diagramme de classes
# 53
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.4.6
4.4.7
Navigabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Classe d’association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Composition : agrégation forte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Classe abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Classe paramétrée / générique *. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Exemple de diagramme de classes avancé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
&
%
La séparation des concepts du diagramme de classes en deux groupes symbolise la séparation entre les
concepts de base et les concepts avancés. Il est important de bien comprendre les concepts de base avant de
s’aventurer à utiliser les concepts avancés.
La limite entre les deux ensembles (concepts de base et concepts avancés) n’est pas tracée de manière
arbitraire. Elle signifie que nous conseillons aux débutants d’utiliser les concepts avancés uniquement s’ils
les maîtrisent. Cette règle est notamment valable pour le bureau d’étude noté : une première analyse et une
première conception sans l’utilisation de ces concepts avancés est suffisante et une mauvaise utilisation de
ces mêmes concepts est pénalisante.
75
4 Analyse et conception, aspects statiques de la vue logique4.4 Concepts avancés du diagramme de classes
'
$
4.4.1 Navigabilité
Par défaut, une association est bidirectionnelle
Il est possible de réduire la portée en la rendant unidirectionnelle
En général, ce choix se fait dans la phase de conception
# 54
&
%
La navigabilité contraint le parcours du graphe de classes. Par défaut, et c’est classiquement le cas dans
le modèle d’analyse, les associations sont bidirectionnelles et peuvent être parcourues dans les deux sens.
Lorsque l’association est contrainte pour devenir unidirectionnelle, le sens de navigation qui reste possible est
spécifié par une flèche. Par conséquent, à moins d’être sûr que la contrainte est nécessaire, il est préférable de
laisser les associations bidirectionnelles. Pour être encore plus explicite, UML autorise d’alerter sur le sens
de navigation interdit en dessinant une croix, en plus de la flèche.
Cf. le glossaire pour la définition du terme « navigabilité/navigability ».
76
'
$
4.4.2 Classe d’association
# 55
&
%
Les classes d’association sont utiles dans un modèle de la phase d’analyse lorsque vous souhaitez adjoindre
des attributs à une association entre deux classes. Par exemple, avec l’exemple de la diapositive, dans
une édition collaborative (à plusieurs écrivains) d’un livre, l’application d’édition collaborative propose une
fonctionalité d’annotation des paragraphes avec suivi des modifications. Ainsi, un écrivain peut ajouter une
note à un paragraphe, cette note indiquant par exemple que le style du paragraphe est à revoir. La note
peut aussi indiquer la date et l’heure de l’annotation. Il est évident que le contenu et la date de la note
ne sont des attributs ni de la classe Écrivain ni de la classe Paragraphe ; ce sont des attributs que vous
souhaiteriez « mettre » sur l’association. Le concept UML de classe d’association signifie cela : les attributs
contenu et date de la note sont rassemblés dans une nouvelle classe dite d’association. Une instance de
cette classe est reliée à une instance d’Écrivain et à une instance de Paragraphe. Ce concept de classe
d’association est un concept avancé et il est toujours possible de s’en passer en créant deux associations, une
avec chacune des deux autres classes. Il faut alors faire attention aux multiplicités. Cette transformation de
la classe d’association en une classe « normale » et en deux associations est d’ailleurs effectuée lorsque l’on
passe d’un diagramme de classes de la phase d’analyse à un diagramme de classes de la phase de conception.
Nous étudions cela dans la section 6.
Cf. le glossaire pour la définition du terme « classe d’association/association class ».
77
'
$
4.4.3 Composition : agrégation forte
La composition est une agrégation forte qui lie les cycles de vie entre le composé
(ensemble) et les composants (éléments)
Le choix entre composition et agrégation peut être pris lors de la phase de
conception
# 56
&
%
La composition est une relation plus forte que l’agrégation. Les éléments de l’ensemble « appartiennent »
de manière exclusive à l’ensemble, contrairement à l’agrégation qui autorise qu’un élément appartienne
à plusieurs ensembles. Par ailleurs, un élément n’existe pas sans être dans un ensemble. Ces deux règles
impliquent que le cycle de vie d’un élément (de la création jusqu’à la destruction) est contraint par le
cycle de vie de l’ensemble. Ainsi, dans l’exemple de la diapositive, la destruction de la voiture provoque la
destruction des roues. Cet exemple interdit donc la revente ou récupération des roues de manière séparée
comme dans les casses de voiture : il aurait alors fallu mettre une agrégation.
En résumé, les règles obligatoires (en plus de l’association classique) pour l’agrégation sont les suivantes :
• « c’est une partie de » ;
• les opérations appliquées au composé concernent les composants. Par exemple, d’un point de vue
métier, dans l’exemple, déplacer la voiture déplace aussi la carrosserie.
Les règles supplémentaires obligatoires pour la composition sont les suivantes :
• la suppression du composé entraîne la suppression des composants ;
• les composants sont créés par le composé.
Autant il est fréquent d’utiliser l’agrégation dans les diagrammes de classes pour éviter de multiplier les
associations s’appelant « contient », autant il est dangereux de faire le choix trop tôt de la composition
avec toutes ses contraintes supplémentaires. Aussi, c’est bien lors de la conception que ce type de décision
intervient. Dans tous les cas, lors des premières itérations d’un diagramme de classes, que ce soit lors de
l’analyse ou lors de la conception, nous vous conseillons d’utiliser avec beaucoup de précaution la composition
et de plutôt attendre d’avoir plus de recul sur le système à spécifier et à réaliser pour choisir une composition.
Cf. le glossaire pour la définition du terme « composition ».
78
'
$
4.4.4 Classe abstraite
Un Média peut être transporté, dupliqué, affiché. Le transport et la duplication sont
indépendants du type de Média (copie de fichiers). Par contre, tout Média peut être
affiché et ce n’est pas la même chose pour Livre, Vidéo, Graphique ou Texte. Un
Média ne peut pas définir comment il s’affiche tant qu’il ne sait pas ce qu’il est.
Il n’existe pas d’instance de la classe Média. Un Média n’existe qu’en tant que
Livre, Texte, Graphique ou Vidéo.
# 57
&
%
UML permet de spécifier une classe de manière incomplète en ne définissant pas certaines opérations.
Ces classes dites abstraites, n’étant pas complètement spécifiées, ne peuvent pas être instanciées. Ce sont
les classes enfants qui compléteront cette spécification en définissant les opérations non encore définies. Ces
classes sont appelées des classes concrètes ; toutes les classes sont par défaut complètes, c’est-à-dire avec
des opérations définies. Les opérations non définies sont dites abstraites et sont écrites en italique dans les
diagrammes de classes. Dès qu’une opération est abstraite, sa classe devient abstraite.
Une seconde utilisation des classes abstraites est d’empêcher l’instanciation de la classe. Par exemple, dans
notre étude de cas Studs, la classe Scrutin factorise les caractéristiques et les comportements communs à tous
les scrutins mais nous désirons que tous les scrutins créés soient soit des ScrutinPlagesHoraires soit des
ScrutinPréférences. Cela est obtenu en rendant la classe Scrutin abstraite. Dans cette seconde utilisation
des classes abstraites, il est ainsi possible qu’aucune opération de la classe abstraite ne soit abstraite.
Cf. le glossaire pour la définition des termes « classe abstraite/abstract class » et « classe concrète/concrete class ».
79
'
$
4.4.5 Interface
Une interface n’est pas une classe, c’est une liste d’opérations
Une interface, comme une classe abstraite, ne peut pas servir à créer un objet
Une interface exprime un savoir-faire, un contrat à respecter par les classes qui
« réalisent » cette interface
# 58
&
%
Une interface permet de décrire le comportement d’une classe, c’est-à-dire un savoir-faire sous la forme
d’une liste de déclarations d’opérations sans leur définition. Une interface ne peut donner lieu à aucune
instance. Toutes les opérations d’une interface sont abstraites. Ainsi, une interface est équivalente à une
classe abstraite, avec la particularité supplémentaire qu’une interface ne possède pas d’attribut1 . Une classe
peut déclarer qu’elle « réalise » une interface, c’est-à-dire qu’elle définit un corps à toutes les opérations
abstraites de l’interface. Une telle classe peut ensuite être utilisée partout où un objet respectant le contrat
de l’interface est attendu. Si une classe ne réalise pas toutes les opérations abstraites de l’interface, alors cette
classe est abstraite. Une classe enfant de cette dernière classe peut compléter la concrétisation en définissant
les dernières opérations abstraites ; la classe enfant devient alors concrète.
Le lien de réalisation qui est aussi (de manière non adéquate) appelé lien d’implantation entre une classe
abstraite et une classe concrète est modélisé similairement au lien d’héritage, la différence étant le trait qui
est en pointillé. Il est possible de spécifier des hiérarchies d’interfaces, ainsi que des hiérarchies impliquant
des interfaces, des classes abstraites et des classes concrètes. Bien sûr, dans de telles hiérarchies, une interface
ne peut pas hériter d’une classe, qu’elle soit abstraite ou concrète ; c’est toujours l’inverse, c’est-à-dire une
classe abstraite ou concrète réalisant le contrat d’une interface, qui peut être dessinée.
Voici dans le diagramme qui suit une autre notation UML de l’interface. Dans la suite, nous utilisons de
préférence la première forme.
Enfin, le schéma suivant montre l’utilisation d’une interface. Une Personne et un Polygone réalisent les
opérations déclarées dans l’interface Déplaçable.
1. Cependant, dans certains langages de programmation orientés objet comme Java, les interfaces peuvent contenir des
attributs qui sont alors des constantes.
80
Cf. le glossaire pour la définition du terme « interface ».
81
'
$
4.4.6 Classe paramétrée / générique *
Classe paramétrée / générique = paramétrée par des types
Attributs génériques = typés avec le type en paramètre
Opérations génériques = arguments et / ou type de retour génériques
# 59
&
%
Les classes paramétrées / génériques (en anglais, templates) permettent de déclarer des classes qui
contiennent des comportements génériques. Vous pouvez spécifier une ou des opérations d’une classe avec des
paramètres génériques et ensuite indiquer les types des paramètres avec lesquels la classe fonctionne, comme
montré dans le schéma qui suit, soit dans un diagramme de classes soit dans un diagramme représentant des
objets.
82
'
$
4.4.7 Exemple de diagramme de classes avancé
# 60
&
%
Voici le diagramme de classes de l’étude de cas Studs avec quelques concepts avancés utilisés de façon
pertinente. Les compositions expriment le fait que les objets du système n’existe pas / plus si le système
(instance de la classe Studs) n’existe plus. La navigabilité de la classe Studs vers les classes principales du
diagramme est restreinte car il n’existe pas de raison pour que les objets de ces classes principales aient
besoin de « remonter » vers l’objet de la classe Studs auquel ils appartiennent. Au contraire, nous verrons
dans la section qui suit que toutes les opérations seront lancées et contrôlées à partir de la classe Studs.
Enfin, les classes Scrutin et Choix sont abstraites car les bulletins ne sont liés qu’à des scrutins spécialisés et
à des choix spécialisés. Nous ne désirons donc pas qu’il y ait des instances des classes Scrutin et Choix.
83
'
$
# 61
5.1
5.2
5.3
5.4
5.5
Rappel : diagrammes communs à l’analyse et à la conception . . . . . . . . . . . . . . . . . . . 62
Modélisation des aspects dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Diagramme de communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Diagramme de machine à états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
&
%
Deux objets reliés par une association peuvent échanger des messages (ou événements). Si l’association
est unidirectionnelle, ces échanges sont contraints par la navigabilité : seul l’objet du côté de la flèche peut
recevoir des messages en provenance de l’objet de l’autre côté de l’association. L’envoi d’un message se
traduit par l’appel d’une opération dans l’objet destinataire ; la classe à laquelle il appartient doit donc
offrir l’opération. Les aspects dynamiques de la vue logique représentent la collaboration entre objets pour la
réalisation (de tout ou partie) d’un cas d’utilisation. L’algorithme réalisant le cas d’utilisation peut nécessiter
la participation de plusieurs objets ; des cascades de messages peuvent être échangés entre ces objets. En
outre, les traitements effectués par les opérations des objets impliquent des changements d’états de ces mêmes
objets. Par conséquent, la modélisation des aspects dynamiques de l’analyse consiste en la connaissance
des messages échangés entre les objets, de l’ordre de ces interactions, ainsi que des changements d’états
significatifs des objets.
84
Introduction au langage de modélisation UML 5 Analyse et conception, aspects dynamiques de la vue logique
'
$
5.1 Rappel : diagrammes communs à l’analyse et à la conception
Vue logique
Aspects statiques = structure du problème et de la solution
I Diagrammes de classes et d’objets
Aspects dynamiques = comportement des éléments de la structure
I Diagrammes de séquence, de communications et de machine à états
# 62
&
%
Cette diapositive montre à nouveau les cinq vues d’un système informatique. La vue concernée par cette
section est à nouveau la vue logique. Cette fois-ci, ce sont les interactions entre les différentes parties du
système ainsi que l’évolution de leur état qui nous intéressent. Les diagrammes construits dans cette section
doivent donc être cohérents avec les diagrammes de classes et d’objets construits en étudiant les aspects
statiques du système. Lors de la phase d’analyse, il est courant de revenir plusieurs fois sur les diagrammes
de classes et d’objets parce que des éléments nouveaux ou des corrections s’avérant nécessaires apparaissent
plus clairement en étudiant les aspects dynamiques du système.
85
'
$
5.2 Modélisation des aspects dynamiques
Points de départ : Modèles de la vue cas d’utilisation + diagrammes de classes
Objectif : modéliser les algorithmes des cas d’utilisation
# 63
&
%
Après la construction des diagrammes de cas d’utilisation et d’activité, et la construction des diagrammes
de classes et d’objets, la modélisation des aspects dynamiques répond globalement à la question « comment est
spécifié le comportement du système, c’est-à-dire comment sont spécifiés les algorithmes des cas d’utilisation
en parcourant le graphe de classes et des objets ? »
Le modèle dynamique montre donc le comportement du système et l’évolution des objets dans le temps.
Il identifie les différents événements venant du monde externe et montre l’enchaînement dans le système que
provoquent ces événements. Un événement est « quelque chose » qui se produit à un moment donné dans le
temps et qui n’a pas de durée. Par exemple, l’utilisateur décroche son téléphone, le conducteur appuie sur
un bouton. Le but du modèle dynamique est de trouver les relations temporelles et événementielles entre
les objets, de montrer les interactions entre les objets, et de définir les états des objets qui déterminent la
réaction face à un événement.
86
5 Analyse et conception, aspects dynamiques de la vue logique 5.2 Modélisation des aspects dynamiques
'
$
5.2.1 Algorithme : orientations procédurale et objet
# 64
&
%
Dans l’orientation procédurale, l’écriture d’un algorithme consiste en l’écriture d’une séquence d’instructions dans un bloc (une procédure) avec des accès aux structures de données. Dans l’orientation objet,
l’écriture d’un algorithme consiste en l’écriture de plusieurs opérations réparties dans plusieurs classes, ces
opérations s’appelant les unes les autres en respectant les associations entre classes.
87
5 Analyse et conception, aspects dynamiques de la vue logique 5.2 Modélisation des aspects dynamiques
'
$
5.2.2 Modèle dynamique de l’analyse et de la conception
Les différents diagrammes du modèle dynamique de l’analyse et de la conception
sont :
# 65
Diagramme de séquence : ordre des interactions entre objets
Diagramme de communications : répartition des interactions sur les liens entre
objets
Diagramme de machine à états : comportement des objets selon leurs états
&
%
Les diagrammes UML du modèle dynamique de l’analyse et de la conception sont complémentaires. Les
diagrammes de séquence montrent visuellement l’ordre des interactions entre objets. Les diagrammes de
communications montrent visuellement la répartition des interactions sur les liens entre objets. Ces deux
premiers types de diagrammes sont duaux au sens où ils montrent presque la même vue du modèle mais
avec des formes visuelles différentes et complémentaires. Les diagrammes de machine à états spécifient le
comportement des objets selon leurs états. À ces trois types de diagrammes, UML ajoute deux autres types
de diagrammes que nous n’étudierons pas dans ce cours : 1) le diagramme de temps spécifie précisément
l’instant d’occurrence des événements dans le temps ; ce diagramme est utile car le diagramme de séquence
s’intéresse à l’ordre des interactions mais ignore la mesure précise du passage du temps ; et 2) le diagramme
de vues globales des interactions qui permet de rassembler dans le même diagramme des comportements
différents sans leurs détails pour dessiner comme son nom l’indique une vue globale des interactions.
88
'
$
5.3 Diagramme de séquence
# 66
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3.7
Modéliser l’ordre des interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Participant, temps et message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Exemple de diagramme de séquence « Ouvrir un scrutin » . . . . . . . . . . . . . . . . . . . . 69
Syntaxe et types de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Création et suppression d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Fragments de séquence « ref » et « opt » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Fragment de séquence « loop » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
&
%
Le diagramme de séquence, avec le diagramme de communications, sont les deux diagrammes UML
les plus utilisés pour spécifier les interactions entre les différentes parties du système. Dans cette section,
nous appliquons le diagramme de séquence à la modélisation des échanges (de messages) entre objets. En
effet, il est important de noter que les diagrammes de séquence et de communications mettent en œuvre
principalement1 des objets et non des classes. Cela permet par exemple de montrer les échanges dans des
configurations différentes.
Le diagramme de séquence montre l’ordre des échanges de messages et le passage du temps. C’est un
diagramme dit temporel. Les principaux concepts sont les objets participants à la séquence, le temps, les
messages, et la création et la suppression de participants. Comme ces diagrammes deviennent vite imposants
en taille, la notion de fragment permet de les construire de façon modulaire.
1. Les classes qui participent à un diagramme de séquence sont utilisées pour leurs opérations de classe : par exemple, une
classe peut proposer une opération de classe de recherche d’une instance selon des critères.
89
'
$
5.3.1 Modéliser l’ordre des interactions
# 67
Le diagramme de séquence capture l’aspect temporel des échanges entre
participantsa
Un diagramme de séquence spécifie le comportement d’un cas d’utilisation ou d’une
partie de celui-ci
a. Au sens UML du terme.
&
%
Les diagrammes de séquence capturent l’ordre des interactions entre les différentes parties du système.
En utilisant un diagramme de séquence, vous modélisez quelles interactions sont exécutées lorsque que tel
cas d’utilisation est exécuté. Les forces des diagrammes de séquence sont leur simplicité et leur efficacité
pour montrer l’aspect temporel (du haut vers le bas des schémas).
Cf. le glossaire pour la définition du terme « interaction ».
90
'
$
5.3.2 Participant, temps et message
# 68
&
%
Chaque participant possède une ligne de vie représentée par une ligne verticale en pointillée. Une flèche
reçue par un participant modélise la réception d’un message et se traduit par l’exécution d’une opération.
La durée de vie de l’opération est symbolisée par un rectangle appelé dans la notation UML une barre
d’activation. Les diagrammes de séquence étant vite assez complexes à dessiner, le plus souvent les barres
d’activations ne sont pas dessinées car elles sont facultatives.
Cf. le glossaire pour la définition des termes « message » et « ligne de vie/object lifeline ».
91
'
$
5.3.3 Exemple de diagramme de séquence « Ouvrir un scrutin »
# 69
&
%
Voici un diagramme de séquence très simple modélisant les interactions du cas d’utilisation « Ouvrir un
scrutin », c’est-à-dire avancer la date d’ouverture du scrutin (contrairement à l’ouverture « automatique »
à la date donnée lors de la création du scrutin). Remarquez que le diagramme montre des interactions entre
un acteur, une classe et deux objets. L’acteur est celui qui initie la séquence. La classe est appelée pour une
opération de classe. L’objet trouvé lors de l’appel à l’opération chercher est utilisé pour un appel d’opération
d’instance : avancerDateOuverture.
À partir de ce diagramme de séquence, nous déduisons les attributs et les opérations suivantes :
• dans la classe Studs, l’opération ouvrirScrutin,
• dans la classe Scrutin :
– l’opération de classe chercher,
– l’attribut de classe qui est une collection de références sur les scrutins,
– l’opération avancerDateOuverture.
92
'
$
5.3.4 Syntaxe et types de messages
Syntaxe complète
attribut = nomMessage(arguments) : type_retour
I attribut peut être un attribut de l’objet appelant ou une variable locale
I nom_message est une opération de l’objet appelé
Synchrone : l’expéditeur est bloqué pendant le traitement
# 70
Le retour d’appel est optionnel (implicite)
Asynchrone : l’expéditeur continue son exécution pendant le traitement du message
&
%
L’interaction la plus petite est l’événement. Un événement est une interaction pendant laquelle « quelque
chose » arrive. Les événements sont les constituants de base des messages, aussi appelés « signaux » en
automatique. Un message est constitué d’un événement d’émission chez l’appelant et d’un événement de
réception chez l’appelé, et possède une signature : « attribut = nom_message(arguments) : type_retour ».
attribut peut être un attribut de l’objet appelant ou une variable locale. L’opération nom_message est une
opération de l’objet appelé qui retourne un objet de type type_retour qui est affecté à l’attribut de l’objet
appelant ou à la variable locale. La signature du message respecte la signature de l’opération appelée. La
notation UML des diagrammes de séquence n’oblige pas à renseigner tous les éléments des prototypes des
messages. Ainsi, les premiers diagrammes de séquence de l’analyse indiquent par exemple uniquement les
noms des opérations. Ensuite, les mêmes diagrammes sont raffinés pour y ajouter les arguments et les types
de retour, puis les attributs des classes appelantes ou variables locales recevant les valeurs de retour.
Un message synchrone est une invocation d’opération bloquant l’appelant jusqu’à ce que l’appelé effectue
le traitement et retourne l’appel, que ce dernier contienne ou non une valeur de retour.
Un retour d’appel est un message que vous pouvez représenter à la fin de la barre d’activation de l’appelé
pour indiquer que le traitement est terminé et que la valeur de retour est passée à l’appelant qui peut
reprendre son traitement après la fin de l’appel synchrone. Comme la barre d’activation, la représentation
de l’appel de retour est optionnelle.
Un message asynchrone est initié par l’appelant qui continue son exécution car il n’attend pas le retour
de l’appel. L’appelant peut par exemple émettre à destination d’un même objet appelé une salve de messages
asynchrones avant un message synchrone demandant le résultat de tous les traitements précédents. Cela lui
permet d’effectuer aussi des traitements en parallèle, et dans cet exemple, cela diminue d’autant le nombre
de messages échangés (car il n’y a qu’un seul retour d’appel). Il est important de noter qu’un message
asynchrone ne possède pas de valeur de retour.
Cf. le glossaire pour la définition des termes « message synchrone/synchronous message » et « message
asynchrone/asynchronous message ».
93
'
$
5.3.5 Création et suppression d’objets
# 71
&
%
Certains objets vivent pendant tout le diagramme, d’autres sont créés et/ou meurent pendant la séquence. Pour montrer qu’un participant est créé lors de la séquence, vous pouvez soit placer l’objet en
haut du diagramme en y ajoutant le stéréotype «new» et utiliser un message synchrone appelant l’opération create(arguments), soit placer l’objet plus bas dans le diagramme au niveau du message synchrone
de création et utiliser le stéréotype «create(arguments)» pour nommer ce message synchrone. Le message
correspondant à l’opération de création d’un objet est un message particulier. L’opération est dans la suite
nommée un constructeur. Notez que l’objet en question n’existe pas avant le message, c’est-à-dire avant sa
création, et que l’opération utilisée ne possède pas de type de retour ; c’est une seconde particularité.
Par analogie avec la création d’un objet dans un diagramme de séquence, la destruction d’un objet
pendant une séquence est modélisée soit en plaçant l’objet en haut du diagramme en y ajoutant le stéréotype
«delete», la destruction étant repérée par un message synchrone appelant l’opération destroy(), soit en
plaçant l’objet plus bas dans le diagramme au niveau du message synchrone de suppression.
Enfin, un objet est dit transitoire (en anglais, transient) lorsqu’il est créé puis détruit durant la même
séquence. Le stéréotype de l’objet est alors « «transient» ».
94
'
$
5.3.6 Fragments de séquence « ref » et « opt »
ref : sous-séquence détaillée dans un autre diagramme de séquence
opt : sous-séquence optionnelle exécutée si condition de garde est vraie
# 72
poc ≡ « pour ou contre »
&
%
Avec les éléments exposés jusqu’à présent, la construction des diagrammes de séquence devient vite
laborieuse car les diagrammes se complexifient rapidement. Pour ce faire, UML propose une notion de bloc
appelé « fragment de séquence » permettant d’inclure dans un rectangle des sous-parties de diagrammes
de séquence. Un fragment de séquence indique dans le cartouche situé dans le coin haut à gauche le nom
de l’opérateur du fragment. Une autre raison de l’intérêt des fragments est la possibilité d’exprimer les
instructions de choix, les itérations... des algorithmes classiques. Nous présentons dans cette diapositive
deux premiers types de fragments de séquence.
Le fragment de séquence ref permet d’inclure une sous-séquence du diagramme de séquence, la sousséquence étant décrite dans un autre diagramme de séquence.
Le fragment de séquence opt présente une sous-séquence exécutée si une condition de garde est vraie. Les
termes de la condition sont souvent des valeurs de retour des messages précédant dans le temps le fragment
de séquence optionnel.
95
'
$
5.3.7 Fragment de séquence « loop »
loop : boucle un nombre maximum de fois tant que la condition est vraie
loop(valeur initiale, maximum, condition)
# 73
pv ≡ « peut voter », av ≡ « a voté »
&
%
Le fragment de séquence loop permet d’itérer un traitement un nombre maximum de fois jusqu’à une
condition qui peut faire sortir de la boucle avant que le nombre de fois maximum ne soit atteint.
Nous n’en présentons pas d’exemple dans ce cours, mais il existe d’autres types de fragments de séquence :
alt similaire aux « si... alors... sinon », neg pour un fragment qui ne doit pas être exécuté (utile lorsque
nous désirons exprimer un test d’intégration montrant si une interaction interdite a lieu : un message d’erreur
est affiché si l’interaction est parcourue), par pour effectuer en parallèle des traitements, assert pour vérifier
un fonctionnement et lever des exceptions.
96
'
$
QCM
1. Quelles entités peuvent être dessinées dans un diagramme de séquence ?
(a) fragment
(b) instance
(c) message
(d) condition
# 74
(e) opération
2. Un objet se distingue-t-il d’une classe parce qu’il est souligné ?
3. Pendant un message synchrone, l’expéditeur est-il bloqué en attente d’une réponse ?
4. En réponse à un message synchrone, l’appelé renvoie-t-il un seul retour d’appel ?
5. Un fragment de séquence est-il une partie optionnelle d’une séquence ?
&
%
97
'
$
5.4 Diagramme de communications
# 75
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
5.4.6
5.4.7
5.4.8
Modéliser les liens d’interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Participant, lien d’interaction, message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Message conditionné, messages en séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Messages emboîtés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Itération de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Collection et recherche dans une collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Messages concurrents * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Choix entre séquence et communications* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
&
%
Le diagramme de communications et le diagramme de séquence sont des diagrammes équivalents (on
peut construire l’un à partir de l’autre). Le diagramme de séquence possède une approche plus temporelle et
le diagramme de communication une approche plus spatiale. La dernière diapositive de cette section donne
une comparaison et des critères de choix.
98
'
$
5.4.1 Modéliser les liens d’interactions
# 76
Le diagramme de communications montre la structure spatiale des interactions entre
participants
L’attention est mise sur les liens d’interactions, qui ne sont qu’implicites dans le
diagramme de séquence
&
%
Le diagramme de communications (comme le diagramme de séquence) est un diagramme d’interactions
qui représente une vue dynamique du système. Le diagramme de communications représente les interactions
entre objets en mettant moins en évidence l’aspect temporel mais en faisant ressortir les relations entre
objets. Ce modèle montre les différents messages qui se propagent d’un objet à l’autre : il attire l’attention
de l’analyste et du concepteur sur le fait qu’un message transite sur une association, qui doit donc exister
entre la classe de l’objet appelant et la classe de l’objet appelé. Comme dans les diagrammes de séquence,
un objet doit avoir une méthode appropriée pour traiter chaque événement qu’il reçoit.
Cf. le glossaire pour la définition du terme « interaction ».
99
'
$
5.4.2 Participant, lien d’interaction, message
# 77
&
%
Dans cette diapositive et les 3 trois suivantes, nous présentons, à travers l’exemple du cas d’utilisation
« consulter les résultats d’un scrutin », la terminologie et la syntaxe du diagramme de communications. Dans
le diagramme de communications, l’aspect temporel n’est pas complètement caché car chaque message est
numéroté. Comme visualisé dans cette diapositive, les messages internes sont numérotés en commençant à
partir de 1 à partir du premier message (en réaction au message en provenance de l’acteur s’il existe).
Notez que le diagramme contient, en plus de l’objet anonyme de type Studs, la classe Personne car un
appel à la méthode de classe getParticipant() de la classe Personne est utilisé pour réaliser ce cas d’utilisation.
Par ailleurs, un diagramme de communications ne fait pas de distinction entre les différents types de
messages. Toutes les flèches sont les mêmes. En outre, vous verrez que, comme de nombreux auteurs et dans
de nombreux ateliers de génie logiciel, nous faisons souvent une entorse à la syntaxe en utilisant les liens
entre objets comme des messages, c’est-à-dire en ne doublant pas les liens entre objets par des messages,
comme dans le diagramme de communications qui suit.
100
'
$
5.4.3 Message conditionné, messages en séquence
# 78
&
%
Comme montrée dans cette diapositive, l’exécution de l’envoi d’un message peut être conditionnée, par
exemple par l’obtention d’une valeur de retour pertinente (ici, valeur de p non nulle) à un message précédent
dans la séquence (ici, le message 1). Cette façon de faire correspond à la notion de fragment optionnel du
diagramme de séquence.
101
'
$
5.4.4 Messages emboîtés
# 79
&
%
Il y a emboîtement des messages pour marquer la relation de cause à effet (un objet ayant reçu le message 2
déclenche en réaction le message 2.1). La séquence de messages du diagramme de cette diapositive est donc :
message 1 en réaction au message venant de l’acteur ; puis message 2, qui provoque le message 2.1 ; et lorsque
les traitements des messages 2.1 et 2 sont terminés, envoi du message 3 puis fin de traitement dans l’objet
anonyme de classe Studs. Par ailleurs, si l’opération getScrutin de la classe Scrutin avait besoin du service
d’autres opérations d’autres classes, les message envoyés seraient numérotés à partir de la séquence 2.1.1,
2.1.2, etc.
102
'
$
5.4.5 Itération de messages
# 80
&
%
La modélisation dans un diagramme de communications de ce qui correspond au fragment
loop du diagramme de séquence utilise les lettres et l’étoile. Dans cette exemple, le message
« 4 :*[i=1..cb.size()]afficherInfosBulletin() » exprime le parcours de la collection de bulletins cb, de l’indice 1
à l’indice correspondant à la taille (ici écrit symboliquement cb.size()), et l’appel de l’opération afficherInfosBulletin sur chaque instance de la collection. Comme indiqué dans le commentaire, à l’itération i, l’instance
manipulée s’appelle b. L’étoile au début de l’expression du message 4 indique l’itération. Par convention,
l’indice est souvent nommé par une lettre (ici i). Cette lettre est ensuite utilisée pour nommer l’itération
en cours. Ainsi, la réaction à l’appel de l’opération afficherInfosBulletin sur chaque instance de la collection
provoque les messages emboîtés 4.i.1 et 4.i.2.
103
'
$
5.4.6 Collection et recherche dans une collection
# 81
&
%
Le diagramme de communications de cette diapositive montre deux modélisations de la recherche d’un
objet dans une collection d’instances. Premièrement, la méthode de classe getParticipant suppose que la
classe Personne possède un attribut de classe correspondant à la collection des instances de la classe. Ainsi,
la méthode getParticipant est la méthode de recherche d’une instance particulière dans la collection. Le
parcours de la collection est interne à la méthode getParticipant et n’est donc pas modélisé sur le diagramme.
Deuxièmement, en utilisant une itération et une méthode d’instance, la collection de scrutins est parcourue.
Cette solution suppose que l’appelant possède une collection de références sur des objets correspondant
à l’appelé. Notez comment la collection d’instances est dessinée. Le scrutin correspondant à l’itération en
cours est « testé » par la méthode correspondre prenant en argument l’intitulé du scrutin. Dès qu’un scrutin
correspondant à l’intitulé est trouvé, l’itération est arrêtée.
Même si les deux solutions sont quelque peu différentes, dans les bureaux d’étude, nous les considérerons
comme sémantiquement équivalentes ; vous pouvez donc choisir la solution que vous préférez.
Veuillez noter que cette problématique existe aussi dans la construction des diagrammes de séquence et
que ces deux solutions sont aussi modélisables dans les diagrammes de séquence.
104
'
$
5.4.7 Messages concurrents *
# 82
&
%
Comme montré de manière synthétique dans le diagramme de cette diapositive, il est possible d’exécuter
des actions concurrentes suite à l’envoi en parallèle de plusieurs messages. Les lettres sont alors utilisées pour
la numérotation : par exemple, le message 2.a est concurrent au message 2.b. La réaction au message 2.a
provoque dans l’exemple l’envoi du message 2.a.1.
105
'
$
5.4.8 Choix entre séquence et communications*
Les plus du diagramme de séquence :
Montrer l’ordre des interactions : le premier objectif du diagramme
Montrer les messages asynchrones : différents types de messages
Montrer les parties optionnelles, les itérations : concept de fragments
Les plus du diagramme de communications :
# 83
Montrer les liens entre participants : le premier objectif du diagramme
I Lien visuel direct avec le graphe des classes du diagramme de classes
Montrer les participants : l’un des objectifs du diagramme
Un peu plus facile à construire et à adapter : numérotation plutôt que
séquencement
Les deux sont équivalents pour :
Montrer la signature des messages / opérations
Montrer le parallélisme
I Diagramme de séquence : message asynchrone et fragment par
&I Diagramme de communications : numérotation des messages
%
Cette diapositive compare les diagrammes de séquence et de communications. Ils sont très proches, mais
dans des cas particuliers et selon les interlocuteurs, le choix est important. En ce qui nous concerne, durant
le module, l’utilisation que nous en ferons lors des bureaux d’étude nous permettra d’utiliser indifféremment
l’un ou l’autre des types de diagrammes.
106
'
$
QCM
1. Quelles entités peuvent être dessinées dans un diagramme de communications ?
(a) fragment
(b) message
(c) condition
# 84
(d) ligne de vie
(e) lien d’interaction
2. Est-ce que plusieurs messages peuvent transiter sur un même lien d’interaction ?
3. Un diagramme de séquence et un diagramme de communications peuvent-ils
contenir des classes ?
&
%
107
'
$
5.5 Diagramme de machine à états
# 85
5.5.1
5.5.2
5.5.3
5.5.4
5.5.5
5.5.6
5.5.7
5.5.8
Modéliser l’état des objets d’une classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Types d’états, événement et transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Événement, condition et action d’une transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Transition implicite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Exemple de diagramme de machine à états de la classe Scrutin . . . . . . . . . . . . . . . 90
Actions liées à un état . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Éléments de méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
État composite * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
&
%
Les diagrammes de séquence et de communications modélisent des interactions, c’est-à-dire des comportements de configuration d’objets. Le diagramme de machine à états permet, lui, de modéliser le comportement
individuel d’un objet d’une classe.
Toutes les contraintes d’une étude de cas ne peuvent pas être modélisées dans des diagrammes de séquence
ou de communications. Par exemple, dans l’étude de cas Studs, comment exprimer qu’un scrutin est supprimé
après la date d’expiration ? Dans le diagramme de machine à états, nous pouvons le spécifier.
Un diagramme de machine à états est construit pour une classe donnée. Il montre les différents états
d’un objet de la classe et les événements provoquant les transitions entre ces états, et ce depuis la création
de l’objet jusqu’à sa destruction. C’est d’ailleurs le seul diagramme UML montrant explicitement le cycle de
vie complet d’un objet d’une classe.
108
'
$
5.5.1 Modéliser l’état des objets d’une classe
Certaines classes sont plus complexes et influent de manière plus importante sur le
comportement général du système
Il est important de décrire les événements provoquant les changements d’états des
objets de ces classes
# 86
Les changements d’états sont décrits dans des machines à états
Une machine à états décrit les états des objets d’une classe
Une machine à états par classe est spécifiée
Exemple de question de l’étude de cas Studs : peut-on (déjà, encore) voter ?
&
%
Les diagrammes d’activité et d’interactions (séquence ou communications) décrivent une partie seulement
du comportement du système. En effet, certaines classes un peu plus complexes que les autres demandent
que soient décrits les changements d’états des objets de ces classes. Par exemple, dans un système de gestion
de traffic d’un carrefour d’une ville par feux de signalisation, il ne paraît pas concevable de ne pas modéliser
les changements d’états de la classe correspondant aux feux tricolores. Ainsi, certaines fois, le comportement
d’un objet possède un impact important sur les autres parties du système. Il est dans ce cas important de
détailler les événements provoquant les changements d’états de ces objets. Les changements d’états sont
décrits dans des machines à états. Une machine à états par classe est spécifiée.
Cf. le glossaire pour la définition du terme « machine à états/state machine ».
109
'
$
5.5.2 Types d’états, événement et transition
L’état d’un objet est lié aux valeurs de ses attributs et des interactions avec les
autres objets
Il s’agit de ne conserver que les états significatifs
La réponse d’un objet à un événement dépend de l’état de l’objet
# 87
Un objet passe dans un état donné par l’événement qui modifie ses attributs, et
quitte cet état par un autre événement qui les modifie à nouveau
&
%
Un objet peut se retrouver dans une situation satisfaisant certaines conditions, ou réalisant certaines
actions en réaction à des événements. Cette situation est appelée un état. Un état possède un nom et se
caractérise par une certaine stabilité et une certaine durée.
Les deux extrémités d’une machine à états sont déterminées par les pseudo-états initial et final. Dans
l’état initial, l’objet n’existe pas encore, et dans l’état final, l’objet n’existe plus. Entre les deux, le diagramme
de machine à états décrit un graphe de changements d’états : les sommets sont des états et les arcs sont
des transitions. Les transitions sont franchies à la suite d’événements. La durée d’un état est l’intervalle
de temps qui s’écoule entre l’événement qui fait entrer la machine à états dans cet état et l’événement qui
en fait sortir. Plusieurs transitions peuvent faire entrer dans le même état et plusieurs peuvent en faire
sortir. Une transition est ainsi considérée sans durée effective : autrement dit, la durée de franchissement
d’une transition est très petite par rapport à la durée de présence dans un état et le franchissement d’une
transition est considérée comme immédiat. Par ailleurs, les actions spécifiées sur les transitions sont dites
« atomiques », c’est-à-dire qu’elles sont exécutées entièrement ou pas du tout : autrement dit, elles ne peuvent
pas être interrompues.
Cf. le glossaire pour la définition des termes « état/state », « transition » et « événement/event ».
110
'
$
5.5.3 Événement, condition et action d’une transition
Syntaxe complète
événement[condition]/action
La transition est déclenchée par un événement
# 88
La transition est effectivement franchie si la condition (sur l’état de l’objet) est
valide
Le franchissement déclenche l’exécution de l’action de la transition
Cette action est considérée comme immédiate et atomique
Si plusieurs transitions sont franchissables, alors la transition effectivement franchie
est choisie aléatoirement
&
%
Si un événement est indiqué sur une transition et qu’il n’y a pas de condition, alors la transition est
franchie dès que l’événement est généré par le système. Si une condition est spécifiée, alors la transition est
franchie uniquement si la condition est valide. Enfin, si aucun événement n’est spécifié, alors la transition
est franchie dès que la condition est valide.
Dans certains cas, l’analyste et le concepteur peuvent ainsi spécifier soit un événement soit une condition,
la différence entre événement et condition étant dans ces cas ténue (l’événement est la validité de la condition).
Enfin, s’il existe plusieurs transitions pouvant être franchies, la transition effectivement franchie est choisie
aléatoirement.
111
'
$
5.5.4 Transition implicite
# 89
&
%
L’exemple de cette diapositive montre le diagramme de machines à états d’une classe Pièce d’un cas
d’étude de modélisation d’une partie d’échec. Les transitions sans événement sont franchies dès que l’action
à l’intérieur de l’état est terminée ; ce type de transition est appelé « transition implicite ».
112
'
$
5.5.5 Exemple de diagramme de machine à états de la classe
Scrutin
# 90
&
%
L’exemple de cette diapositive montre le diagramme de machines à états de la classe Scrutin du cas
d’étude Studs.
Comme montré dans la diapositive, pour l’événement particulier de création de l’objet, nous introduisons
l’état EnConstruction car nous considérons que les actions liées à l’initialisation de l’objet sont complexes.
Sans cet état EnConstruction, la création est l’événement qui déclenche la transition de l’état initial vers le
premier état de la classe. De la même façon, nous avons le choix entre l’insertion d’un état EnDestruction
et l’interprétation de la destruction comme la transition du dernier état de la classe vers l’état terminal.
Dans les bureaux d’étude, nous prendrons l’habitude de mettre en avant les événements de construction
et de destruction des objets en utilisant systématiquement des états EnConstruction et EnDestruction.
113
'
$
5.5.6 Actions liées à un état
Actions exécutées à l’entrée et à la sortie d’un état
Action exécutée pendant toute la durée de présence dans l’état
Action interne déclenchée par un événement
# 91
&
%
Lors de l’entrée dans un état, l’action labellisée entry est exécutée. Par analogie, l’action labellisée exit
est exécutée lors de la sortie de l’état. Ces deux premières actions sont, comme les actions des transitions, des
actions immédiates et atomiques : elles sont de courtes durées et ne peuvent pas être interrompues. L’action
labellisée do est exécutée pendant toute la durée de l’état, entre les deux actions précédentes. Cette action
labellisée do est interruptible par un événement.
Certains événements sont dits internes (à un état). Ils provoquent l’exécution d’actions mais sans changement d’état. Dans ce cas, l’action labellisée exit n’est pas exécutée.
Comme montré aussi dans la diapositive, UML autorise les transitions dites « réflexives », faisant sortir
d’un état avant d’y retourner. Elles provoquent la séquence d’actions suivante : après l’interruption de l’action
labellisée do, exécution de l’action labellisée exit lors de la sortie de l’état, exécution de l’action spécifiée
sur la transition réflexive, exécution de l’action labellisée entry lors de l’entrée dans l’état de départ, puis
reprise de l’action labellisée do.
Enfin, pour être exhaustif, un état peut ne pas possèder d’action labellisée do ou l’algorithme de l’action
labellisée do peut se terminer sans intervention d’un événement. Dans ces cas, une transition dite « implicite »
fait sortir de l’état courant sans événement particulier.
Les curieux qui se posent des questions sur la conception de systèmes informatiques avec des actions atomiques, comme préconisé implicitement dans le paragraphe précédent, et ce notamment dans les systèmes
dits concurrents, soit multi-activité (en anglais, multi-threaded) soit répartis, peuvent étudier les fiches programmes des modules CSC4508 « Conception et programmation des systèmes centralisés » et CSC4509
« Algorithmique et communications des applications réparties » de la VAP « Architecte de Services en
Réseau ».
114
'
$
Seuls les états quelque peu stables sont pertinents
Les attributs constants (possédant toujours la même valeur une fois que l’objet est
construit) n’interviennent pas dans la recherche des états
# 92
Les attributs qui changent de valeur aident souvent à déduire les états possibles
Et particulièrement les attributs booléens
Il est souvent intéressant d’insérer de manière systématique un état de création de
l’objet (initialisation des attributs) et un état de destruction
Une attention particulière est à porter sur les événements et les actions
&
%
Il ne faut conserver que les états ayant une certaine stabilité dans le temps ou bien les états pendant
lesquels de nombreuses et/ou importantes actions sont effectuées. Les états de type EnTrainDe, EnCoursDe...
sont très intéressants. Par exemple, pour un scrutin, l’état ScrutinOuvert est intéressant car il se passe
quelque chose : le système évolue suite à la survenue d’un événement comme un vote.
Les attributs qui changent de valeur aident à déduire les états possibles, et particulièrement les attributs
booléens.
Les diagrammes de machine à états permettent de compléter la liste des opérations des classes du diagramme de classes avec les actions des transitions et des états.
115
'
$
5.5.8 État composite *
# 93
&
%
Avec UML, il est possible de spécifier des états concurrents, c’est-à-dire des objets qui dans certains états
peuvent exécuter plusieurs actions concurrentes. Cela signifie que l’objet de la classe modélisée peut faire
plusieurs choses à la fois. Il est ainsi possible de spécifier le comportement d’objets dits actifs qui effectuent
plusieurs actions de manière concurrente. L’état composite est un concept avancé du diagramme de machine
à états que nous vous conseillons de ne pas utiliser dans les bureaux d’étude de ce module.
Un état composite est un état qui contient des machines à états. Chaque région contient un diagramme de
machine à états. Chaque machine à états démarre et fonctionne en parallèle dès l’entrée dans l’état composite.
Les machines à états des régions sont interrompues dès qu’un événement fait sortir de l’état composite.
Cf. le glossaire pour la définition du terme «état composite/composite state ».
116
'
$
QCM
1. Quelles entités peuvent être dessinées dans un diagramme de machine à états ?
(a) fragment
(b) message
# 94
(c) condition
(d) objet
(e) état initial
(f) transition
2. Une transition réflexive peut-elle provoquer la séquence d’actions « exit », « action
de la transition », « entry », et « do » ?
&
%
117
'
$
# 95
6.1 Rappel des phases du cycle de développement en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.2 Conception des classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
6.3 Rappel du diagramme de classes de l’étude de cas Studs . . . . . . . . . . . . . . . . . . . . . . . 98
6.4 Traduction des associations en attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.5 Traduction des agrégations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.6 Traduction des compositions * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.7 Traduction de la classe « Façade » du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations . . . . . . . . . . 104
6.9 Traduction des attributs dérivés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.10 Qualification de certaines associations * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.11 Traduction des diagrammes d’interaction en algorithmes . . . . . . . . . . . . . . . . . . . . . 110
6.12 Traduction des diagrammes de machine à états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.13 Traduction des relations de généralisation spécialisation . . . . . . . . . . . . . . . . . . . . . . 113
6.14 Traduction des classes d’association * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.15 Méthodologie : une fiche par classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
&
%
Lors de la conception du système, le développeur raffine les modèles de l’analyse en complétant les
diagrammes. Les décisions prises lors de ce raffinement ne sont pas du même ordre que celles prises pendant
l’analyse. La phase de conception contient tous les choix technologiques permettant ensuite la mise en œuvre.
Dans ce cours, nous nous concentrons sur le raffinement du diagramme de classes et la constitution d’une fiche
par classe rassemblant tous les attributs, avec leur visibilité, leur type et leur valeur par défaut, et toutes les
opérations, avec leur prototype complet et leur algorithme. L’écriture des algorithmes, hormis l’utilisation des
références, est classique, et toutes les connaissances acquises dans les cours de programmation procédurale
s’appliquent (donc, revoir le cours CSC3002). Dans la suite de cette section, nous nous focalisons donc sur
la conception des classes.
118
'
$
6.1 Rappel des phases du cycle de développement en V
# 96
&
%
Cette diapositive rappelle les phases du cycle de développement en V d’un système informatique. Cette
section présente une des activités de la phase de conception : la conception des classes.
119
'
$
6.2 Conception des classes
# 97
&
%
La phase précédant le développement dans un langage de programmation donné (en l’occurrence Java
pour le module CSC4002) consiste à définir complètement les classes, les associations, les algorithmes et les
signatures des opérations, en partant des diagrammes de l’analyse.
Deux activités se dégagent lors de la conception des classes. Premièrement, dans la suite de cette section,
nous détaillons la traduction quelque peu automatique des diagrammes de l’analyse pour construire une fiche
par classe du diagramme de classes. Par exemple, les différentes associations sont traduites en des attributs
et le modèle dynamique est transposé dans le corps des opérations en définissant leur algorithme. En plus de
cette traduction automatique, quelques décisions doivent être prises par exemple concernant la navigabilité
des associations ou le choix entre l’agrégation et la composition. Deuxièmement, non présenté dans ce cours,
des décisions de conception peuvent intervenir pour tenir compte de contraintes matérielles et logicielles :
langages, base de données, processeurs, périphériques, etc. Par conséquent, la conception est une étape
pendant laquelle ne peuvent intervenir que des informaticiens spécialisés dans les différentes technologies
utilisées.
120
'
$
6.3 Rappel du diagramme de classes de l’étude de cas Studs
# 98
&
%
Nous remettons le diagramme de classes de l’étude de cas Studs pour rappel. Dans les diapositives qui
suivent, nous nous intéressons plus particulièrement aux éléments suivants :
• les associations de la classe Scrutin,
• les agrégations et compositions de la classe Studs,
• les attributs de la classe Scrutin,
• les attributs dérivés de la classe Choix,
• le diagramme de séquence (ou de communications) de création d’un scrutin,
• le diagramme de machine à états de la classe Scrutin,
• la généralisation spécialisation de la classe Scrutin,
• la classe « Façade » du système Studs.
121
'
$
6.4 Traduction des associations en attributs
# 99
Concept de « référence » :
À partir d’un objet Scrutin, il est possible « d’aller vers » un objet Personne et
vers une collection d’objets Bulletin
&
%
Cette diapositive présente une partie du diagramme de classes de l’étude de cas Studs. Nous nous focalisons sur la classe Scrutin et montrons les classes en association avec cette classe. L’association avec la classe
Personne possède la multiplicité « 1 » (par défaut) du côté de la classe Personne. Pour la traduction de cette
association, nous ajoutons un attribut dans la classe Scrutin ayant pour nom la forme nominale du nom
de l’association (organisateur) et pour type une référence sur la classe à l’autre extrémité (@Personne).
Quant à l’agrégation vers la classe Bulletin, la multiplicité est traduite par une collection (Collection @Bulletin). Pour l’exercice, nous souhaitons ordonner la collection. Cette décision est typiquement une décision
de conception. Elle n’est pas anodine. En effet, nous devons dans ce cas indiquer quels sont les attributs participant à l’établissement de l’ordre total de tous les objets de classe Bulletin1 : référence vers la personne
+ référence vers le scrutin.
1. Ces attributs seront utilisés dans la programmation de la méthode hashCode() en Java et dans la constitution de la clef
primaire pour la table de même nom dans la base de données.
122
'
6.4 Traduction des associations en attributs
$
6.4.1 Règles de traduction
Attribut du type référence sur un objet de la classe à l’autre extrémité de
l’association
Référence notée « @ »
Autant d’attributs que de classes auxquelles elle est reliée
Association binaire = 1 attribut
# 100
Association n-aire = n − 1 attributs
Association unidirectionnelle = pas d’attribut du côté de la flèche
Nom de l’attribut = nom du rôle ou forme nominale du nom de l’association
Traduction des multiplicités
1 =⇒ @Classe
∗ =⇒ Collection @Classe
0..N =⇒ Tableau[N] Classe
Multiplicité avec tri = Collection ordonnée @Classe
&
%
Chaque association navigable à partir d’une classe donne lieu à l’ajout d’un attribut traduisant la possibilité de traverser l’association depuis cette classe vers la/les classe/s à l’autre/aux autres extrémité/s de
l’association. Chacun de ces attributs est une référence vers un objet de la classe associée ; cette référence se
note « @ » en UML. Par exemple, la classe Facture de l’exemple ci-dessous reçoit un attribut « fournisseur:
@Fournisseur ».
Chaque classe reçoit autant d’attributs que de classes auxquelles elle est reliée. Par exemple, une classe
C ayant 2 associations binaires et une ternaire, reçoit 4 attributs : 1 pour chaque association binaire et 2
pour l’association ternaire. Le nom des attributs est par défaut le nom du rôle, sinon est construit à partir
de la forme nominale de l’association ou du nom de la classe à l’autre extrémité de l’association.
Si l’association possède une navigabilité (flèche sur le diagramme de classes indiquant que l’association
n’existe que dans un sens), seul le sens de navigation autorisée donne lieu à un attribut.
Les multiplicités sont également à prendre en compte. Dans le même exemple, l’attribut factures est une
collection (un ensemble) de références vers des objets de type Facture car la multiplicité est comprise entre
O et *. L’attribut est déclaré de la façon suivante : « factures: Collection de @Facture ». Il est possible de
préciser que cette collection est triée en ajoutant ordonnée. Si la multiplicité est valorisée à un nombre N
donné, utilisez un tableau de références qui se note comme ceci : « factures: Tableau[N] @Facture ».
123
'
$
6.5 Traduction des agrégations
Agrégation = association, avec les mêmes règles de traduction en attribut
# 101
&
%
Les agrégations sont des associations avec une sémantique particulière (ensemble, éléments), mais les
règles de traduction des associations s’appliquent à l’agrégation sans supplément particulier.
124
'
$
6.6 Traduction des compositions *
# 102
&
%
De manière supplémentaire aux agrégations qui donnent lieu uniquement à des déclarations d’attributs
(une agrégation est une association dont le nom est contient), pour une composition, les objets composants
sont possiblement créés et obligatoirement détruits par l’objet composé. Par ailleurs, dans certains langages de
programmation orientés objet, les compositions sont traduites en des attributs qui ne sont pas des références,
mais directement des objets. Pour cette raison, on appelle l’agrégation la composition par référence, et on
appelle la composition la composition par valeur.
125
'
$
6.7 Traduction de la classe « Façade » du système
Un constructeur et un destructeur (cf. traduction des agrégation et composition)
Une opération (publique) par cas d’utilisation
# 103
&
%
La classe utilisée comme façade, c’est-à-dire comme point d’entrée, du système contient toutes les opérations des cas d’utilisation. En d’autres termes, chaque cas d’utilisation est traduit en une opération de la
classe façade. Par ailleurs, certaines opérations peuvent être ajoutées lors de la conception. Plus précisément,
dans le diagramme de cas d’utilisation, certains cas d’utilisation permettent de créer et de supprimer des
instances des classes métier ; mais, il est possible que certaines classes métier aient été oubliées car ayant
été mises en exergue par la suite lors de la construction du diagramme de classes. Par exemple, en bureau
d’étude, dans le diagramme de cas d’utilisation de la Médiathèque, aucun cas d’utilisation ne s’occupe de
créer ou supprimer une Localisation.
Dans les diapositives qui suivent, nous expliquons la signification de l’adjectif « publique » et du signe
« + ».
126
'
$
6.8 Encapsulation : visibilité / accessibilité des attributs et des
opérations
Doit-on voir / accéder à tous les attributs ou à toutes les opérations d’un objet ?
Non
La classe définit ce qui est visible / accessible
# 104
I C’est le principe de l’encapsulation
Un objet complexe ne peut être utilisé qu’au travers de ce qui est accessible
Analogie :
Il n’est possible d’utiliser une voiture qu’à travers son volant, son frein, son
accélérateur, etc.
L’accès au carburateur est impossible sauf par les méthodes qui le font de
manière cohérente (méthode accélérer de l’accélérateur )
&
%
La conception des classes s’appuie sur les concepts de l’orientation objet. Dans cette section, nous nous
servons de la conception pour compléter nos connaissances sur ces concepts de l’orientation objet. Celui
que nous étudions dans cette diapositive et les suivantes est l’encapsulation : tout concepteur de classe
choisit les attributs et les opérations qu’il désire rendre visibles / accessibles de toutes les autres classes, ou
visibles / accessibles seulement des classes enfants, ou encore non visibles / non accessibles.
En guise d’autre exemple que celui de la diapositive, prenons un exemple informatique du module d’algorithmique procédurale CSC3002. Pour la conception de listes chaînées, vous utilisez une structure de données
avec des pointeurs qui permettent de connaître l’élément précédant et l’élément suivant dans liste, ainsi que
des pointeurs pour connaître le premier élément et le dernier élément de la liste. Ces derniers pointeurs
permettent de manipuler plus facilement la liste pour ajouter / supprimer un élément au début / à la fin
de la liste. Après la conception des procédures pour ces manipulations, vous souhaitez que les utilisateurs
n’utilisent ni le pointeur sur le premier ni le pointeur sur le dernier élément, mais vos procédures. En quelque
sorte, vous souhaitez que ces deux pointeurs soient non visibles / non accessibles.
La propriété d’encapsulation est très importante car en choisissant quels attributs et quelles opérations
sont visibles de tous, le concepteur définit l’API (en anglais, Application Programming Interface) du système.
Une fois qu’une API est publiée, des milliers d’utilisateurs en prennent connaissance, l’utilisent, et donc en
dépendent. Faire ensuite évoluer une API est très compliqué. Par conséquent, ce travail est critique pour
l’adoption du système par les autres concepteurs et pour la pérennité du projet.
Cf. le glossaire pour la définition du terme « visibilité/visibility ».
127
6 Conception, aspects langage et technique6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations
'
$
6.8.1 Encapsulation avec le concept de Visibilité
Les attributs sont en général inaccessibles (secrets). Ils sont alors qualifiés de :
« private » : notation UML « − »
Lecture ou modification uniquement possibles au travers des opérations
(p.ex. les accesseurs : getAdresse(), setAdresse())
# 105
Les opérations sont en général accessibles par toutes les classes. Elles sont alors
qualifiées de :
« public » : notation UML « + »
Certains attributs doivent être accessibles par les classes enfants et inaccessibles aux
autres classes. Ils sont alors qualifiés de :
« protected » : notation UML « # »
Certaines opérations peuvent cependant être privées (factorisation interne de
traitements) et certains attributs peuvent être publics (même si cela est non
souhaitable selon le principe d’encapsulation)
&
%
Pour respecter le principe d’encapsulation, les attributs sont privés (préfixés par le signe « − ») et les
opérations sont publiques (préfixées par le signe « + »). Les opérations nécessaires au fonctionnement interne
des classes sont elles-aussi privées.
Dans le cas de la généralisation spécialisation, le travail à effectuer est de vérifier la visibilité des attributs
pour les classes enfants. Si un attribut privé de la classe parente doit être « présent » dans ses classes enfants
(c’est-à-dire doit être accessible par les classes enfants), ou si un attribut n’est accédé que par ses classes
enfants, cet attribut possède la visibilité « protégée » (attribut préfixé par « # » dans la classe parente).
Dans le cours sur la programmation orientée objet, nous verrons que certains languages comme Java
introduisent d’autres types de visibilité. Par exemple, le langage Java ajoute aux trois visibilités étudiées
ici (privée, protégée, publique) la visibilité « paquetage ». Dans ce cours sur la modélisation orientée objet,
nous ignorons ces autres types de visibilité.
128
'
$
6.8.2 Notation UML
# 106
&
%
Dans l’exemple de la classe Scrutin, tous les attributs sont privés, excepté l’attribut nbTotalScrutin. Ce
dernier attribut est utilisé dans les classes enfants de la classe Scrutin, qui est une classe abstraite. Une
opération est elle-aussi protégée (afficherScrutin()). Ainsi, uniquement les classes enfants peuvent appeler
l’opération de cette classe parente, par exemple dans leur opération afficherScrutin().
129
'
$
6.8.3 Cas particulier des attributs/opérations protégés
Attribut/opération protégé/e =
Accessible par les classes enfants
Inaccessible par les autres classes
Par exemple, opération afficherScrutin() de la classe Scrutin
# 107
La classe ScrutinPlagesHoraires peut utiliser l’opération de la classe Scrutin dans
l’algorithme de son opération afficherScrutin() :
String afficherScrutin() {
...
appela de l’opération afficherScrutin() de classe parente
...
}
a. Nous étudions dans quelques diapositives comment faire cet appel.
&
%
Dans cette diapositive, nous montrons un exemple typique expliquant pourquoi il est certaines fois nécessaire de mettre une opération protégée. Soit une classe abstraite possédant des attributs privés, par exemple
la classe Scrutin. Afficher l’état d’un objet concret d’une classe enfant de la classe abstraite implique l’affichage des attributs contenus dans la classe parente et l’affichage des attributs ajoutés dans la classe enfant.
Or, si les attributs de la classe parente sont privés, comme c’est le cas avec la classe Scrutin, il est nécessaire d’avoir une opération afficherScrutin dans la classe parente (pour accéder aux attributs privés de la
classe parente). Comme la classe parente est une classe abstraite (qui ne possède pas d’instance), l’opération
afficherScrutin n’a pas besoin d’être publique. Par ailleurs, si l’opération afficherScrutin reste publique, le
concepteur qui étend la classe parente peut ne pas redéfinir l’opération afficherScrutin et seuls les attributs
de la classe parente seront affichés. Donc, l’opération afficherScrutin ne doit pas être publique, mais protégée,
et une opération afficherScrutin doit être définie dans la classe enfant. Cette méthode de la classe enfant doit
être publique et faire appel à la méthode protégée de la classe parente pour afficher les attributs de la classe
parente.
130
'
$
6.9 Traduction des attributs dérivés
Attribut dérivé =⇒ opération ou attribut selon qu’il est ou non recalculé à chaque
fois que sa valeur est lue (p.ex. dans un accesseur)
Par exemple, deux possibilités pour l’attribut nbBulletinsPour de la classe Choix
# 108
1. Définition d’un attribut dans la classe Choix
Dans l’opération voter(), incrémentation si le vote est « pour »
Lorsque demandé, fourniture de la valeur de l’attribut
Mais, attention à la suppression d’un bulletin !
2. Définition d’une opération getNbBulletinsPour()
L’opération getNbBulletinsPour parcourt tous les bulletins pour le calcul
&
%
Un attribut dérivé peut être traduit soit en un attribut et une opération qui retourne la valeur de l’attribut
à chaque appel, soit en une opération qui calcule la valeur lors de chaque appel. Cette décision est faite lors
de la conception : c’est un détail inutile lors de l’analyse et c’est une décision importante pour la mise en
œuvre.
131
'
$
6.10 Qualification de certaines associations *
numéroCompte et nom sont des attributs des classes CompteBancaire et Fichier,
respectivement
numéroCompte et nom sont les clefs de leur classe respective
Le choix de l’association qualifiée peut être laissé à la phase de conception
# 109
&
%
Les associations qualifiées sont en général utilisées dans les diagrammes de classes de la conception. C’est
en effet une information le plus souvent peu pertinente pour l’analyste mais intéressante pour les concepteurs
et ceux qui mettent en œuvre l’association : cela donne par exemple une indication pour l’élection des clefs
lors de la construction du schéma de la base de données pour la persistance.
132
'
$
6.11 Traduction des diagrammes d’interaction en algorithmes
# 110
Impact sur la classe Bulletin
Attributs
I personne : @Personne
I scrutin : @Scrutin
I choix : @Choix
I pourOuContre : boolean
&
constructeur(@Personne p, @Scrutin s,
@Choix c, boolean poc) {
personne = p
scrutin = s
choix = c
pourOuContre = poc
p.voter(b); s.voter(b); c.voter(b)
}
%
Le diagramme de séquence de cette diapositive modélise la création d’un bulletin. Nous nous intéressons
plus particulièrement à l’opération constructeur de la classe Bulletin. Nous en déduisons l’algorithme suivant :
• les arguments passés en paramètres de l’opération sont utilisés pour initialiser les attributs correspondant dans la classe Bulletin. Les attributs concernés sont des références pour des associations ;
• trois appels d’opération sont effectués. Sur l’objet p de la classe Personne, le constructeur appelle
l’opération voter. Pour rappel, il est possible que le diagramme de séquence construit lors de l’analyse
n’ait pas donné tous les détails des opérations appelées : par exemple, il est possible que les arguments
des opérations voter n’ait pas été précisés. Dans ce cas, c’est lors de la conception, donc maintenant,
que ces informations sont ajoutées.
L’argument passé en paramètre des opérations voter sert à maintenir la navigabilité de l’association de
l’objet p de la classe Personne vers l’objet b de la classe Bulletin. Ce passage de paramètre est imposé
par le diagramme de classes : une personne connaît ses bulletins. De manière similaire, l’opération
d’instance voter de la classe Scrutin et l’opération d’instance voter de la classe Choix sont appelées sur
les objets s et c, respectivement. Notez que ces opérations possèdent le même nom, mais elles sont
différentes car ce sont des opérations d’instance de trois classes différentes.
133
'
$
6.12 Traduction des diagrammes de machine à états
# 111
Attributs utilisés dans la machine à états
Valeur des attributs dans les différents états
dateDébut : date
EnConstruction : valeurs par défaut
dateLimite : date
ScrutinOuvert : ouvert = true
dateLimiteExistence : date
ScrutinFermé : ouvert = false et
(dateJour > dateLimite ou fermetureA = true)
ouvert : boolean = false
ouvertureAvancée : boolean = false
fermetureAvancée : boolean = false
EnDestruction : ouvert = false et
(dateJour > dateLE ou destructionA = true)
destructionAvancée : boolean = false
&
%
Rappelons que les attributs d’une classe, ici la classe Scrutin, d’un diagramme de classes servent à
construire un diagramme de machine à états, et vice versa (dans le sens où la construction d’un diagramme
de machine à états peut permettre de découvrir des attributs non extraits directement du cahier des charges).
Pour notre exemple de la classe Scrutin, il est fort probable que la première liste des attributs de la classe
Scrutin construite lors de la première construction du diagramme de classes n’ait pas fait apparaître les
attributs booléens qui permettent de gérer le cycle de vie par des actions de l’organisatrice, qui peut avancer
l’ouverture, la fermeture, ou la destruction d’un scrutin.
La traduction d’un diagramme de machine à états lors de la conception consiste en deux activités :
premièrement, compléter la liste des attributs afin de permettre la gestion de tous les états et de toutes
les transtions, et deuxièmement, compléter la liste des opérations afin de permettre de faire évoluer les valeurs des attributs pour respecter le diagramme de machine à états. Tout d’abord, concernant la liste des
attributs, selon le diagramme de machine à états de cette diapositive, nous pouvons nous poser la question
suivante : une ouverture avancée par l’organisatrice fait-elle changer la valeur de l’attribut dateOuverture
ou ajoute-t-on un attribut pour distinguer une ouverture automatique d’une ouverture avancée ? Comme
montré dans cette diapositive, nous avons choisi d’ajouter les attributs ouvertureAvancée, fermetureAvancée,
et destructionAvancée. Ensuite, concernant la liste des opérations, les actions du diagramme de classes deviennent des opérations de la classe, et les contraintes sur les attributs deviennent aussi des opérations (par
exemple, le passage du temps est modélisé par l’ajout d’une opération vérifierAuQuotidien). Les opérations
avec leur algorithme sont décrits dans la diapositive qui suit.
134
'
6.12 Traduction des diagrammes de machine à états
$
6.12.1 Quelques opérations de la classe Scrutin
# 112
constructeur(...) {
...
vérification
dateDébut < dateLimite <
dateLimiteExistence
}
avancerOuverture() {
ouvert = true
ouvertureAvancée = true
}
avancerFermeture() {
ouvert = false
fermetureAvancée = true
}
avancerDestruction() {
destructionAvancée = true
}
vérifierAuQuotidien() {
si ((dateJour >= dateDébut)
et (ouvertureAvancée == false))
alors ouvert = true
si ((dateJour > dateLimite)
et (fermetureAvancée == false))
alors ouvert = false
si ((dateJour > dateLimiteExistence)
et (destructionAvancée == false))
alors en destruction
}
&
%
Cette diapositive présente les algorithmes des opérations utilisées dans le diagramme de machine à états.
La dernière opération vérifierAuQuotidien est implicitement1 créée pour faire évoluer de manière automatique
l’état des objets d’un Scrutin : tous les matins, tous les scrutins sont parcourus. Par ailleurs, comme montré
dans cet exemple, dans le constructeur, il est souvent utile de vérifier que les valeurs passées en paramètres
sont cohérentes : ici, dateDebut < dateLimite < dateLimiteExistence.
1. Il n’est pas évident de trouver ce type d’opération lors de la lecture d’un diagramme de machine à états. Pour ce faire,
demandez-vous quel est l’événement non donné (implicite) qui fait changer les valeurs des attributs pour que les conditions
deviennent valides.
135
'
$
6.13 Traduction des relations de généralisation spécialisation
Dans les classes enfants, possibilité d’appel au constructeur de la classe parente (si
public ou protégé)
Par exemple, dans la classe enfant ScrutinPlageHoraire :
# 113
constructeur(...) {
super(...) // appel au constructeur de la classe parente Scrutin
nbTotal = 0
}
L’appel au constructeur de la classe parente doit être la première instruction
Dans les classes enfants, possibilité d’appel des opérations de la classe parente (si
publique ou protégée)
Par exemple, dans la classe enfant ScrutinPlageHoraire :
afficherScrutin() {
// opération redéfinie dans la classe enfant
super.afficherScrutin() // appel à l’opération de classe parente Scrutin
afficher à l’écran la valeur de l’attribut nbTotal
}
&
%
Tous les algorithmes des principales opérations, ceux qui ne sont pas triviaux, doivent être écrits pendant
la phase de conception. Le rôle de la programmation doit si possible être restreint à la traduction dans un
langage particulier (Java en ce qui nous concerne) et à l’utilisation de canevas logiciels particuliers (par
exemple, un canevas logiciel proposant des mises en œuvre de listes, de collections, d’arbre et d’autres
structures de données complexes).
Cette diapositive présente une nouveauté importante de l’orientation objet concernant l’écriture des
algorithmes : l’appel à partir d’une opération définie dans une classe enfant d’opérations définies dans une
classe parente. Lorsqu’un arbre de généralisation spécialisation est tracé dans un diagramme de classes,
certaines opérations factorisées sont définies dans une classe parente, puis redéfinies dans les classes enfants.
Par définition, toute opération protégée ou publique définie dans une classe peut être appelée dans le corps
d’une opération d’une classe enfant. Nous distinguons deux cas particuliers : 1) le constructeur de la classe,
ou 2) une opération redéfinissant l’opération de la classe parente appelée. Dans le premier cas, la notation
« super() » permet d’appeler le constructeur de la classe parente. Cet usage courant permet d’écrire le
constructeur d’une classe comme étant l’initialisation de la partie de l’état gérée par / définie dans la classe
parente, puis l’initialisation des attributs spécifiques ajoutés dans la classe enfant. Dans le second cas, il est
important de se rappeler l’effet de « la liaison dynamique ou tardive » (toujours active en Java) : si une
opération définie dans une classe est redéfinie dans une classe enfant, et si c’est une référence sur un objet de
type de la classe enfant qui est utilisée, alors c’est l’opération de la classe enfant (c’est-à-dire, l’opération de
la classe spécialisée) qui est appelée. Dans certains cas, l’opération dans la classe enfant est une « extension »
du corps de l’opération correspondante de la classe parente. Dans ces cas, la notation « super.op() » permet
d’appeler explicitement l’opération de la classe parente « op » dans le corps de l’opération de la classe enfant.
136
'
$
6.14 Traduction des classes d’association *
# 114
&
%
La conception des classes d’association peut conduire à plusieurs solutions. La plus courante est de
transformer la classe d’association en classe intermédiaire. L’association initiale est découpée en deux : une
de la première classe vers la classe intermédiaire et une autre de la classe intermédiaire vers la seconde classe.
Attention aux multiplicités : si l’association initiale est de type « 1 — * », la première association est de
type « 1 — 1 » et la seconde est de type « * — 1 ».
La figure qui suit donne les quatre possibilités de configuration des multiplictés avec les traductions
correspondantes.
137
'
$
6.15 Méthodologie : une fiche par classe
Collecter dans une fiche par classe
Tous les attributs
Toutes les opérations
Sources : cahier des charges, et diagrammes de classes, de machine à états, de
communications et de séquence
# 115
Homogénéisation des noms : même terme pour le même concept métier
La conception est une préparation de la phase de mise en œuvre
Traduction des associations
I Attribut « d’association » = référence
Traduction des attributs dérivés en attributs ou opérations
Traduction des diagrammes d’interaction et de machine à états
I Définition des algorithmes des opérations
Traduction des généralisations spécialisations
&
'
Fixation de l’accessibilité des attributs et des opérations
%
$
I Propriété d’encapsulation
# 116
&
%
Comme nous l’avons vu tout au long de cette section, la conception consiste à reprendre tous les diagrammes élaborés et à repérer les attributs et les opérations nécessaires pour la réalisation des états, des
transitions, des événements et des messages. Cette phase comprend aussi l’homogénéisation des noms et des
arguments des messages (des diagrammes de machine à états, de séquence et de communications). « Homogénéiser » signifie le respect des mêmes conventions et l’utilisation des mêmes termes pour désigner les
mêmes concepts métier.
Nous rappelons que la phase de conception inclut aussi les choix techniques tels que le choix de serveur
Web, le choix de base de données, etc. Ces choix n’ont pas été expliqués dans ce cours car ils sont hors
propos.
138
'
$
QCM
1. Pour traduire une association binaire, faut-il regarder le sens de lecture de
l’association ?
2. Une multiplicité « 0..1 » se traduit-elle par un attribut référence sur la classe à
l’autre extrémité de l’association binaire ?
# 117
3. La notation pour un attribut privé est-elle « − » ?
4. Étant donné une classe A contenant l’attribut a et une classe B contenant la
méthode b, si a est privé et b est publique, b peut-elle utiliser a ?
5. Un attribut dérivé peut-il être traduit par un attribut ?
6. Un message d’un diagramme de séquence est-il la plupart du temps traduit en une
opération privée ?
7. Le mot clef « super » permet-il d’appeler une opération de la classe parente ?
&
%
139
'
$
# 118
7.1
7.2
7.3
7.4
7.5
Diagrammes de la vue développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Diagramme de la vue physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
&
%
Lors de la conception, l’architecture logicielle du système comprend l’organisation des parties de logiciels
spécifiées avec les termes utilisés par les développeurs : paquetage, composant, connecteur, assemblage, etc.
Cette étape permet ensuite à chaque équipe de développement de connaître l’organisation du système et
de positionner sa contribution dans l’ensemble. Ce modèle intéresse aussi les personnes qui déploient et
administrent le système en production, car, implicitement, la vue développement définit les contributions de
chaque équipe de développement, et donc les responsabilités, et donne une indication pour la préparation
du déploiement (étudié dans la section qui suit celle-ci).
La seconde partie de cette section présente la vue physique, c’est-à-dire comment les composants de la
vue développement sont projetés sur une architecture matérielle. La projection s’appelle le déploiement.
Les vues développement et physique sont présentées dans ce cours pour des raisons de complétude du
cycle de vie et des diagrammes UML. Cependant, les décisions prises lors de la construction des diagrammes
de ces vues dépendent beaucoup des technologies utilisées. Ces sujets sont étudiés plus précisément dans les
voies d’approfondissement ASR (« Architecte des Services informatiques en Réseaux ») et DSI (« Intégration
et Déploiement de Systèmes d’Information »), par exemple.
140
'
$
7.1 Diagrammes de la vue développement
Composant = partie de logiciel réutilisable et remplaçable
Paquetage = espace de nommage d’éléments de modélisation
# 119
&
%
Lors du développement d’un système logiciel, il est rare de passer directement des exigences aux classes
logicielles codées. Il est nécessaire de regrouper le développement de plusieurs classes et d’organiser le développement par groupes de classes. Les composants et les paquetages sont deux concepts de regroupement.
Les composants sont des parties de logiciel réutilisables et remplaçables, selon l’approche COTS (en anglais,
Components Off The Shelf, pour composants sur étagère). Les paquetages organisent des éléments, pas uniquement des classes, dans des espaces de nommages différents et permettent de gérer la complexité d’un
logiciel de grande taille.
141
'
$
7.2 Diagramme de composants
# 120
7.2.1 Composant, interfaces offertes et requises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7.2.2 Composite, port, connecteurs de délégation et d’assemblage . . . . . . . . . . . . . . . . . 122
&
%
Le diagramme de composants définit l’architecture logicielle du système dans un environnement de développement donné. Il est issu de la conception et permet de représenter le système et les sous-systèmes du
modèle physique de l’architecture logicielle à réaliser. Un système ou un sous-système définit un espace de
visibilité et regroupe des classes.
142
'
$
7.2.1 Composant, interfaces offertes et requises
# 121
&
%
Dans le monde du bâtiment, le modèle de l’architecture (logique) permet de visualiser, spécifier et documenter sur papier les caractéristiques de la future construction : positions des murs, des fenêtres, etc.
Lors de la construction, on utilise des composants fenêtres, portes, murs. Ce sont des objets physiques qui
existent dans le monde réel. Ils rendent des services mais définissent leurs exigences : taille, espace, etc. Par
analogie, dans un système informatique, le modèle logique d’une application permet de visualiser, spécifier
et documenter la structure et le comportement des entités qui collaborent. La construction s’appuie sur des
composants logiciels. Un composant logiciel définit les services logiciels qu’il rend et aussi les services dont il
est en attente pour pouvoir fonctionner. Ainsi, un composant spécifie les interfaces qu’il fournit (qu’il réalise)
et les interfaces qu’il requiert.
Un composant joue le même rôle qu’une classe : généralisation, association avec d’autres classes et composants, réalisation d’interfaces, etc. La principale différence entre une classe et un composant est qu’un composant regroupe des classes. Un composant est dessiné comme un rectangle avec le stéréotype «component».
Si le composant est gros alors UML suggère de remplacer le stéréotype «component» par «subsystem». La
diapositive montre les deux manières de spécifier les interfaces fournies (offertes) et requises d’un composant.
La première notation graphique est plus concise et la seconde utilise uniquement des stéréotypes. Notez que
le composant est relié à ses interfaces offertes par une association de réalisation alors qu’il est relié à ses
interfaces requises par une relation de dépendance.
Cf. le glossaire pour la définition du terme « composant/component ».
143
'
$
d’assemblage
# 122
&
%
La diapositive montre que les composants peuvent être de deux types. Les composants primitifs ne
contiennent pas d’autres composants alors que les composites sont composés de composants primitifs et de
composites. Les composants à l’intérieur d’un composite sont connectés par des connecteurs dits d’assemblage. Les interfaces offertes et requises sont connectées à des ports du composite et les ports sont à leur tour
connectés aux composants de l’intérieur par des connecteurs dits de délégation. La notion de port matérialise le passage du contrôle de l’extérieur vers l’intérieur et vice versa. Non montré dans cette diapositive, les
composants primitifs sont en général constitués de classes.
Un modèle de composant hiérarchique, c’est-à-dire intégrant la notion de composants primitif et composite, permet d’étudier le système à différents niveaux de granularité : tout le système est un composite,
que l’on peut ouvrir récursivement pour en connaître plus de détails, jusqu’à trouver les classes dans les
composants primitifs.
144
'
$
7.3 Diagramme de paquetages
# 123
7.3.1 Paquetage, espace de nommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.3.2 Relation entre paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
&
%
Un système informatique peut aisément contenir des centaines de classes ou d’éléments de modélisation.
Pour gérer cette complexité, UML fournit le concept de paquetage (en anglais, package) qui organise un
espace de nommage (en anglais, name space).
145
'
$
7.3.1 Paquetage, espace de nommage
# 124
&
%
Un paquetage est représenté par un rectangle avec une cartouche rectangulaire en haut à gauche. Lorsque
le diagramme montre des éléments de modélisation (dans la diapositive, une classe) dans le paquetage, le nom
du paquetage est indiqué dans la cartouche. Le diagramme de la diapositive montre les différentes notations
pour indiquer qu’une classe est contenue dans un paquetage :
• Classe1 possède dans son nom le nom du paquetage, la hiérarchie des paquetages étant indiquée par
le symbole « :: » ;
• la notation pour Classe2 possède en dessous de son nom le nom du paquetage entre parenthèse ;
• la notation pour Classe3 utilise une notation proche de celle utilisée pour Classe2 ;
• les classes Classe4 et Classe5 sont reliées au paquetage ;
• Classe6 est directement visualisée dans le paquetage.
Cf. le glossaire pour la définition des termes « paquetage/package » et « espace de nommage/namespace ».
146
'
$
7.3.2 Relation entre paquetages
Imbrication de paquetages = imbrication d’espaces de nommage
Dépendance entre paquetages
# 125
&
%
Les paquetages peuvent contenir d’autres paquetages pour construire une imbrication d’espaces de nommage. Si un élément d’un paquetage, par exemple paquetage3 dans la diapositive, utilise un élément d’un
autre paquetage, par exemple du paquetage4, alors le premier paquetage dépend du second. La dépendance
est notée par une flèche pointillée allant du paquetage utilisateur vers le paquetage contenant l’élément
utilisé.
Cf. le glossaire pour la définition du terme « dépendance/dependency ».
147
'
$
7.4 Diagramme de la vue physique
Placement des logiciels sur les matériels
# 126
&
%
La vue physique modélise les éléments physiques (le matériel) et les logiciels montrant ainsi le placement
des logiciels sur les machines pour l’exécution du système. Il n’y a donc qu’un type de diagramme dans la
vue physique, le diagramme de déploiement.
148
'
$
7.5 Diagramme de déploiement
# 127
7.5.1 Nœud et liaison de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.5.2 Artefact et composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.5.3 Dépendance entre artefacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
&
%
Dans ce cours, nous ne nous intéressons qu’aux systèmes dans lesquels la partie logicielle est prépondérante. Le diagramme de déploiement permet de spécifier la projection des artefacts logiciels exécutables sur
le matériel, ainsi que les liens logiques et physiques via le réseau utilisé.
149
'
$
7.5.1 Nœud et liaison de communication
Ce modèle définit le diagramme de l’architecture matérielle du système
Il représente les différentes machines et les logiciels
Il montre les liens de communication entre ces différentes entités
# 128
&
%
Un « nœud » est un matériel qui peut abriter des logiciels et des fichiers : hôte, disque, etc. UML étend
la notion de nœud aux logiciels qui jouent le rôle d’environnement d’exécution tels que les systèmes d’exploitation, les serveurs Web et les serveurs d’application. Par opposition, des logiciels tels que les librairies, les
fichiers de propriétés et les fichiers exécutables ne peuvent pas être des nœuds, mais restent des « artefacts ».
Le diagramme de déploiement spécifie les liens de communication entre nœuds avec des associations
stéréotypées par les noms des protocoles de communication utilisés.
150
'
$
7.5.2 Artefact et composant
# 129
&
%
La diapositive montre trois façons de représenter un artefact : avec le stéréotype «artefact» et un icone,
avec seulement le stéréotype «artefact», et sans stéréotype et sans icone.
Le déploiement d’un artefact peut être montré de deux manières différentes : soit l’artefact est placé dans
le nœud, soit l’artefact et le nœud sont reliés par une association stéréotypée «deploy».
Enfin, le diagramme de déploiement peut modéliser par une association stéréotypée «manifest» le fait
qu’un artefact est « empaqueté » dans un composant lui-même déployé sur un nœud.
Cf. le glossaire pour la définition du terme « artefact ».
151
'
$
7.5.3 Dépendance entre artefacts
Dépendance entre artefacts
Instance de nœud
# 130
&
%
Cette diapositive montre d’une part comment les dépendances entre artefacts sont spécifiées et d’autre
part que les diagrammes de déploiement peuvent aussi contenir des instances de nœuds plutôt que des
« types » de nœuds.
Cf. le glossaire pour la définition du terme « dépendance/dependency ».
152
'
$
8 Conclusion
Modèle pour appréhender la réalisation d’un système informatique
# 131
Diagrammes UML qui permettent d’aider à la réflexion, à la discussion (clients,
architectes, développeurs, etc.)
Pas de solution unique mais un ensemble de solutions plus ou moins acceptables
suivant les contraintes du client, et les logiciels et matériels disponibles
Une solution acceptable est obtenue par itérations successives
&
%
153
'
$
9 Bibliographie
Livres
G. Booch, J. Rumbaugh, I. Jacobson, « The Unified Modeling Language User Guide »,
2nd edition, Addison-Wesley, 2005
B. Charroux, A. Osmani, Y. Thierry-Mieg, « UML 2, Pratique de la modélisation », 2è
édition, Pearson Education, 2008
J. Gabay, D. Gabay, « UML 2 : analyse et conception », Dunod, 2008
# 132
P. Roques « UML 2 par la pratique », 6è édition, Eyrolles, 2008
R. Miles et K. Hamilton, « Learning UML 2.0 : A pragmatic Introduction to UML »,
O’Reilly, 2006
Object Management Group, « OMG Unified Modeling Language, Infrastructure,
Version 2.4.1 », OMG Document Number formal/2011-08-05, August 2011
Object Management Group, « OMG Unified Modeling Language, Superstructure,
Version 2.4.1 », OMG Document Number formal/2011-08-06, August 2011
D. Pilone, « UML 2.0 Pocket Reference », O’Reilly, 2006
S.W. Ambler, « The Elements of UML 2.0 Style », Cambridge University Press, 2005
URL : OMG UML at http://www.omg.org/spec/UML/
&
%
L’ordre d’apparition des livres référencés n’a pas d’importance, hormis le fait que le document de référence
de la spécification UML de l’OMG ainsi que les deux livres qui suivent sont d’un abord plus difficile pour
les débutants.
154
Gestion des prêts dans une
médiathèque
Équipe enseignante
Revision : 1302
CSC 4002
Octobre 2015
155
Première étape : mise au point de la solution, aspect statique
L’étape d’analyse nécessite un crayon, une GROSSE gomme et BEAUCOUP de papier : pensez
à en apporter.
1
Sujet
Nous souhaitons réaliser l’analyse et la conception d’un système de gestion du fond de CD audios, de DVD
et de livres d’une médiathèque, et du prêt de ce fond à ses clients. Ce système doit être accessible par tous les
employés de la médiathèque. Les fonctions de consultation des catalogues et de consultation de ses propres
emprunts en cours doivent également être accessibles aux clients de la médiathèque.
Le fonctionnement de la médiathèque est décrit de manière approfondie dans la section 3.
2
Méthodologie et objectifs
Nous devons pour ce premier BE réaliser deux diagrammes UML, le diagramme de cas d’utilisation du
système puis le diagramme de classes.
2.1
Première lecture : acteurs et cas d’utilisation
La première étape consiste à bien comprendre le système à étudier. Dans le cadre de l’exercice, cela
consiste à lire attentivement l’énoncé. Cette lecture doit permettre de délimiter les contours du système
à réaliser : la méthode générale consiste à retrouver les « acteurs » qui interagissent avec lui. Il est très
important de fixer des frontières au problème. Ensuite, recherchez les fonctionnalités du système par la
définition de ses « cas d’utilisation ». Dans le cadre de ce module, il s’agit de rechercher les principales
fonctions attendues du système.
2.1.1
Question 1 : diagramme de cas d’utilisation
Pour réaliser le diagramme de cas d’utilisation à partir de l’analyse du texte :
• rechercher les acteurs,
• rechercher les fonctionnalités du système accessibles aux acteurs,
ce qui vous permettra de dessiner le diagramme de cas d’utilisation. Nous vous proposons de nous limiter
aux cas d’utilisation gérant les clients et les documents.
2.2
Analyse du texte : recherche des classes et opérations
La seconde étape consiste à analyser le texte du BE afin d’y rechercher :
• les classes métier1 de ce problème, ainsi que
• les premiers attributs des classes avec leur type et leur valeur par défaut,
• et de manière facultative, les premières opérations de chaque classe.
Conseil 1 Il est préférable de sur-spécifier le modèle d’analyse avec beaucoup de classes métier ; il sera plus
facile de les regrouper plus tard que de trouver celles que l’on a ignorées.
Recherchez les noms qui correspondent le plus souvent aux classes métier, et les verbes qui les relient
qui correspondent aux associations. Attention toutefois à certains verbes (comme le verbe être) qui peuvent
correspondre à des attributs ou à des opérations. La méthode habituelle consiste à établir des listes exhaustives puis à les trier/sélectionner (suppression des classes métier trop vagues ou non pertinentes). Éliminez
les noms ou les verbes inutiles (bruits introduits lors de la rédaction du texte qui ne sont pas significatifs).
Faites la chasse aux synonymes afin de ne garder que les classes utiles à la résolution du problème.
1. Certains préfèrent utiliser le terme de concept ; il faut faire attention à ne pas mélanger la notion de classe/concept métier
utilisées dans la phase d’analyse et la notion de classe utilisées dans la phase de conception.
Télécom SudParis — Équipe enseignante — Octobre 2015 — CSC 4002
156
Conseil 2 Une autre manière de trouver ces classes métier sont les « cas d’utilisation » : les classes métier
sont les noms et les verbes utilisés dans les descriptions des actions effectuées par les acteurs.
Conseil 3 Si un nom est associé à une valeur (nombre, texte, etc.) dans le monde réel, alors il s’agit
certainement d’un attribut. Dans le doute, en faire une classe métier.
Remarquez que, partant d’un énoncé, cette méthode d’analyse n’est pas une fin en soi. Les limites sont
celles apportées par un texte ; cela nécessite un dialogue avec le « client ». Enfin, il est important de bien
choisir le nom des classes métier et des associations. L’analyse permet de trouver en général des noms pour
les classes métier et des verbes pour les associations.
2.2.1
Question 2 : liste des classes
Cette deuxième lecture doit vous permettre de créer une liste de classes et de noter de manière informelle
leurs relations ainsi que les attributs qui leurs sont associés. Cette liste se présente sous forme d’énumération.
2.3
Phase de construction du diagramme de classes
Le diagramme de classes est un réseau statique de classes et d’associations (l’analogie avec le réseau routier
peut aider : il s’agit de décrire les différentes voies de circulation, pas comment on voyage). En partant des
classes et des associations trouvées précédemment, construisez un diagramme de classes. Ajoutez à ce schéma
des informations concernant les classes et les associations.
Nous vous conseillons de :
• construire un premier diagramme de classes à partir des noms obtenus dans la phase précédente,
• par étapes successives, enrichir ce diagramme par les associations à l’aide des verbes obtenus,
• affiner le diagramme en éliminant les associations redondantes2 en simplifiant le schéma dès lors qu’il
respecte les spécifications de l’énoncé,
• ne chercher les généralisations et spécialisations qu’à la fin, lorsque les classes sont déjà bien établies.
La notation UML doit impérativement être respectée. Elle conditionne la compréhension du schéma par
l’équipe de développement (ou accessoirement du correcteur).
Concernant les associations, recherchez les associations simples, les relations d’agrégation et de généralisation spécialisation. Ensuite, trouvez la multiplicité (cardinalité) de chaque relation qu’il faut porter
sur le schéma.
2.3.1
Question 3 : diagramme de classes simple
Une fois réalisées les étapes précédentes, vous devez vous appliquer à dessiner sous forme de diagramme de
classes, les classes en recherchant les associations entre les classes et les généralisations/spécialisations.
2.4
Phase de recherche des attributs et opérations
Enfin, trouvez les attributs et les opérations des classes. À ce niveau, quelques retours en arrière sont possibles
à cause d’oublis ou de mauvaises compréhensions du système. Il s’agit des attributs ou opérations qui sont liés
au modèle statique. Dans la partie conception (lors du BE5), d’autres attributs et opérations seront trouvés,
comme par exemple ceux introduits par le modèle dynamique ou encore ceux des classes dites « techniques ».
Conseil 4 Un critère de validité d’un attribut est qu’il doit être simple (type/valeur) : par exemple, date,
nombre et texte. Dans le cas contraire, en faire une classe métier. D’autre part, les classes métier doivent
être reliées avec des associations et non avec des attributs.
Vous devez réfléchir sur le choix de la classe où placer les attributs. En cas de doute, analysez de nouveau
la relation. Quelquefois, la solution consiste à ajouter une classe d’association (ce cas peut se présenter dans
cet exercice avec la classe FicheEmprunt).
Pensez à qualifier les attributs de classes (par opposition aux attributs d’instance). Il y en a un certain
nombre qui ne sont pas forcément évidents à détecter avant d’aborder la phase dynamique de l’analyse.
2. Le cas des associations ou attributs dérivés n’est pas pris en compte à ce niveau de l’analyse. Ils seraient précédés par le
caractère « / » dans le diagramme de classes.
157
Conseil 5 Pour placer une opération dans une classe, recherchez la classe responsable :
• c’est celle qui détient toutes les informations nécessaires pour effectuer l’opération ;
• en cas de création, cela devrait être la classe conteneur (agrégation/composition) ou celle qui détient les
valeurs d’initialisation.
Concernant les opérations, le niveau de détail doit rester faible afin de ne pas empiéter sur la phase de
conception.
2.4.1
Question 4 : classes avec opérations
Reprenez chaque classe du diagramme de classes et complétez-la en vérifiant l’ensemble de ses attributs et
de ses opérations.
2.5
Phase de vérification de l’analyse, aspects statiques
Après avoir dessiné le diagramme de classes (dans sa première version, il est sujet à raffinements dans les
prochaines itérations), vérifiez que le système « fonctionne ». En partant des cas d’utilisation, vérifiez que
la navigation entre les classes (associations et opérations) permet de réaliser ce qui est prévu dans le cahier
des charges.
Finalement, reprenez l’énoncé et vérifiez que toutes les spécifications demandées y sont présentes. Dans
le cas contraire, reprenez le schéma et corrigez-le. Dans certains cas, cela peut remettre énormément de
choses en question. Vous devez contrôler également si des fonctionnalités nouvelles ont été ajoutées par
rapport à l’énoncé. Demandez à un enseignant de vous aider à effectuer ce contrôle et à valider les nouvelles
spécifications. Ces nouveautés doivent rester mineures.
2.5.1
Question 5 : vérifications
Vérifiez que les cas d’utilisations peuvent être réalisés sur le système décrit par le diagramme de classes.
3
Cahier des charges
• La médiathèque contient un certain nombre de documents disponibles à la consultation ou à l’emprunt ;
les personnes désirant emprunter des ouvrages pour une durée et à un tarif donnés doivent s’inscrire
en tant que client.
• Les clients s’inscrivent auprès d’un employé de la médiathèque, et empruntent et rendent un document
par l’intermédiaire d’un employé de la médiathèque.
• L’inscription des clients consiste à remplir une fiche datée sur laquelle sont notées les informations
suivantes : nom et prénom du client ainsi que son adresse.
• Les catégories de client actuelles permettent au client de choisir de payer à chaque emprunt effectué
(catégorie « à tarif normal » ou « à tarif réduit ») ou de régler une cotisation annuelle (catégorie
« abonné »).
• Outre le tarif, la catégorie de client conditionne les critères d’emprunt suivants : le nombre de documents
empruntables et la durée de prêt (voir ci-dessous). Dans le cas « tarif réduit », un justificatif est
demandé à l’inscription, puis à chaque date anniversaire. Les justificatifs à prévoir sont les suivants :
carte étudiant/scolaire, carte vermeil et carte « à caractère social ».
• Les documents disponibles sont des CD audios, des DVD ou des livres. Chaque document est repéré par
un code unique et une localisation (salle/rayon) dans la médiathèque. Certains documents ne peuvent
pas être empruntés, mais uniquement consultés sur place. Les informations communes aux documents
sont les suivantes : le titre, l’auteur (écrivain, groupe ou metteur en scène) et l’année de sortie. Le
système devra permettre de disposer de statistiques d’utilisation, telles que le nombre d’emprunts
effectués pour les différentes catégories et genres de documents. Les autres informations des documents
sont les suivantes :
158
– les CD possèdent un genre musical (par exemple, « classique », « variétés françaises », « variétés
internationales », « compilation ») et une classification (par exemple, « opéra » pour le genre
« classique », « hardcore » pour le genre « variétés internationales » ou « rock » pour le genre
« compilation ») ;
– Les DVD possèdent un genre de vidéo (« documentaire », « comédie »...), une durée d’émission
et une mention légale de diffusion (restrictions d’usage) ; cette mention doit être disponible lors
de l’emprunt du DVD pour permettre un éventuel contrôle ;
– Les livres possèdent un genre (« roman », « policier », etc.) et un nombre de pages.
Les genres précisés sont libres ; ils sont donnés aux clients à titre indicatif pour aider au choix lors d’un
emprunt.
• Chaque sortie de document entraîne la constitution d’une fiche d’emprunt. Sur cette fiche, sont notés le
client emprunteur, la date de début du prêt, le document emprunté et la date limite de restitution. Les
durées de prêt dépendent du type de document et de la catégorie du client (voir les règles ci-dessous) ;
• La médiathèque met à la disposition des clients des ordinateurs pour qu’ils consultent le catalogue,
leurs emprunts, et puissent mettre à jour leur adresse.
Le système de gestion doit prévoir toute opération d’ajout et de suppression de clients et de documents.
Les informations les concernant ne sont pas construites par le système (par exemple, la localisation des
documents dans les locaux), mais supposées fournies lors de l’invocation de ces opérations. Le système doit
permettre de réviser les catégories et leurs conditions associées. D’autre part, les formats de la plupart
des informations sont libres (chaînes de caractères) ; le système doit toutefois veiller à la cohérence des
informations stockées (impossibilité d’avoir deux clients ou deux documents avec le même nom, emprunter
deux fois le même document, etc.).
3.1
Règles de prêt
L’emprunt d’un document par un client obéit à certaines règles :
• un client ne peut pas emprunter plus d’un certain nombre de documents fixé par sa catégorie : 2 pour
la catégorie « à tarif réduit », 5 pour la catégorie « à tarif normal » et 10 pour la catégorie « abonné ».
Dès que ce nombre maximal est atteint pour un client donné, tout nouveau prêt doit être impossible ;
• tout client qui n’a pas restitué un document avant sa date limite de restitution ne peut plus faire de
nouvel emprunt tant qu’il n’a pas régularisé sa situation, ceci même si le nombre maximal d’emprunts
n’est pas atteint. Pour ce faire, à chaque demande d’emprunt, le système vérifie s’il est à jour dans ses
restitutions ; si ce n’est pas le cas, l’emprunt n’est pas autorisé.
• l’ensemble des fiches d’emprunt est parcouru chaque jour afin de repérer s’il existe des documents pour
lesquels la date limite de restitution est dépassée. Pour chacune de ces fiches trouvées, la date de rappel
de la fiche est mise à la date du jour, le client concerné est marqué et la médiathèque envoie une lettre
de rappel que nous considérons hors système. Les fiches ayant fait l’objet d’un rappel font l’objet d’une
relance hebdomadaire.
• le tarif des emprunts dépend du document et du client. Le tarif du document est fixé par son type :
0, 5 e pour un livre, 1 e pour un CD audio et 1, 5 e pour un DVD. La règle pour les clients « à tarif
normal » est de payer le montant fixé pour chaque document emprunté (indiqué auparavant). Le tarif
appliqué aux clients « à tarif réduit » est la moitié du « tarif normal ». Les « abonnés » réglant une
cotisation annuelle empruntent les documents gratuitement ;
• la durée des emprunts dépend du document et du client. Chaque type de document est empruntable
pour une durée dite nominale : 2 semaines pour un DVD, 4 semaines pour un CD audio et 6 semaines
pour un livre. Ensuite, la durée de prêt est modifiée selon la catégorie de client : aucun changement
— la durée nominale — pour un client à tarif normal, la moitié de cette durée pour un client à tarif
réduit et le double de cette durée pour un abonné ;
• un client peut changer de statut. Par exemple, un client abonné devient un client à tarif normal si
son abonnement n’est pas renouvelé à la date anniversaire. De la même façon, un client à tarif réduit
devient un client à tarif normal si aucun justificatif n’est fourni à la date anniversaire.
159
160
Équipe enseignante
Revision : 1502
CSC 4002
Octobre 2015
161
Deuxième étape : mise au point de la solution, aspect dynamique
1
Questions
À partir de cette séance, nous ne réalisons que les fonctionnalités demandées par l’acteur Employé médiathèque.
1. Construire le diagramme de machine à états des classes FicheEmprunt, Document et Client.
2. Construire les diagrammes de communications et de séquence des opérations mettre consultable, emprunter, et restituer de la classe Médiathèque.
2
2.1
Méthodologie
Construction des diagrammes de machine à états (DME)
À partir du diagramme de classes établi dans le premier BE (dans sa version complète avec les concepts
avancés), construisez un diagramme de machine à états (DME) pour certaines des classes. Ce diagramme
permet de compléter la liste des opérations d’une classe (événements extérieurs et traitements internes). Les
états initiaux et terminaux sont montrés.
Ne conservez que les états ayant une certaine stabilité dans le temps ou bien les états pendant lesquels
de nombreuses et/ou importantes actions sont effectuées. Les états de type en train de, en cours de, etc. sont
très intéressants. Par exemple, pour une fiche d’emprunt, l’état en retard est intéressant car le comportement
du système est spécifique : certaines actions sont déclenchées et d’autres sont interdites. La construction
du DME de la classe FicheEmprunt nous permet dans la suite d’établir plus facilement les diagrammes de
séquence et de communications pour spécifier les opérations complexes comme emprunter et restituer.
Conseil 1 Les attributs booléens dans une classe aident à déduire les états possibles de cette classe.
Concernant la classe Client, dans un premier temps, ignorez le fait que les clients peuvent changer de
catégories. Dans un second temps, prenez en compte cette contrainte et adaptez votre DME.
2.2
Construction des diagrammes de communications (DC) et de séquence (DS)
Le diagramme de communications et le diagramme de séquence sont des diagrammes duaux (on peut
construire l’un à partir de l’autre). Le fait de choisir un des deux diagrammes plutôt que l’autre n’a pas de
signification particulière ici.
Conseil 2 Avant de dessiner un diagramme de communications ou de séquence, écrivez l’algorithme correspondant en langage naturel.
Pour le diagramme de communications et de séquence de l’emprunt, nous supposons que le cas d’utilisation
ne concerne qu’un document et que la procédure de vérification journalière des retards est lancée par exemple
le matin, ce qui garantit que les emprunts sont possibles toute la journée.
2.3
Derniers conseils
Bien que les questions (ainsi que la présentation) figurent dans un certain ordre, revenez sur tous les diagrammes pour les compléter ou les corriger. Il s’agit de l’élaboration d’une solution, qui passe nécessairement
par une compréhension du problème tant d’un point de vue statique (BE précédent) que d’un point de vue
dynamique (ce BE).
N’hésitez pas à compléter vos diagrammes de tout commentaire facilitant la compréhension ou permettant
d’attirer l’attention sur des points qui resteraient obscurs et à approfondir. Enfin, la documentation est une
part très importante dans toute analyse/conception.
162
Équipe enseignante
Revision : 1316
CSC 4002
Octobre 2015
163
Troisième étape : la liste des classes de manière détaillée.
Il s’agit d’établir de manière exhaustive la liste des attributs et des opérations avec leur algorithme
afin de préparer la mise en œuvre.
1
Questions
Nous étudions la conception d’un certain nombre de classes du système, en particuliers les classes :
• Médiathèque, ce qui nous permet d’étudier la traduction des agrégations et des compositions,
• FicheEmprunt, ce qui nous permet d’étudier la traduction des associations et des attributs dérivés,
• Document et Livre, ce qui nous permet d’étudier la généralisation spécialisation.
Pour chacune des classes étudiées, l’étude passe par les étapes suivantes :
1. en respectant les règles données en cours, donnez la liste exhaustive des attributs et des opérations
pour la classe ;
2. pour chacun des attributs, donnez leur visibilité, leur pseudo-déclaration, et leurs éventuelles valeurs
par défaut ;
3. pour chacune des opérations, donnez leur visibilité, leur pseudo-déclaration, ainsi que leur algorithme
général de manière littérale ou en pseudo-code (par exemple l’opération Emprunter de la classe Mediatheque et le constructeur de la classe FicheEmprunt).
2
Méthodologie
2.1
Démarche de conception des objets
L’étape finale avant le développement dans un langage de programmation orienté objet consiste à définir
complètement les classes, les attributs, les opérations, les signatures des opérations et les algorithmes.
Conseil 1 Nous vous recommandons de réserver une feuille de papier par classe et nous vous encourageons
à documenter (commenter) les attributs ou opérations que vous trouvez.
2.2
Opérations à effectuer
Les différents points à traiter sont :
1. concevoir les associations,
2. trouver tous les attributs et toutes les opérations,
3. concevoir la visibilité des attributs et des opérations,
4. concevoir les algorithmes,
5. optimiser les chemins de données (si la conception des algorithmes met en évidence des relations entre
classes trop compliquées)1 .
Les environnements orientés objet (système, langage, etc.) offrent le plus souvent des API (en anglais,
Application Programming Interface) permettant de disposer de collections toutes faites, de fonctionnalités
élaborées, etc. Le travail accompli ici nécessite peut-être alors des modifications afin de les prendre en compte.
La conception n’est alors peut-être pas complètement terminée.
1. Cette étape n’est pas parcourue lors de ce BE car nous partons de diagrammes « corrects », c’est-à-dire d’une solution
éprouvée (puisque l’équipe enseignante a réalisé l’ensemble du développement jusqu’à fournir une application qui correspond à
la modélisation et qui fonctionne). Dans la pratique, cette étape peut être une nouvelle occasion de remettre en question des
choix d’analyse ou de conception (même si cela provoque un retour en arrière qui prend du temps).
164
Équipe enseignante
Revision : 1510
CSC 4002
Octobre 2015
165
1
Sujet
L’équipage d’un avion est toujours constitué d’un pilote, d’un copilote, et de plusieurs personnels navigants
et commerciaux (PNC). Chacune de ces personnes est identifiée par son nom et sa fonction. Nous supposons
qu’un même équipage peut participer à plusieurs vols.
Chaque membre d’équipage doit être opérationnel sur deux catégories d’avions (par exemple, le PNC
Richard est opérationnel sur Airbus A320 et Boeing 747). Chaque catégorie d’avions requiert un nombre de
PNC dans son équipage oscillant entre un minimum et un maximum (par exemple, les PNC des Airbus A320
doivent être entre six et huit, et ceux d’un B747 entre 12 et 16)1 .
Voici ci-dessous un extrait du tableau de service de quelques employés de la compagnie Air France :
Avion
13562
13562
13562
13562
13562
32156
32156
32156
32156
32156
Vol
AF347
AF347
AF347
AF347
AF347
AF545
AF545
AF545
AF545
AF545
Dest.
Londres
Londres
Londres
Londres
Londres
New-York
New-York
New-York
New-York
New-York
Date
11/10/06
11/10/06
11/10/06
11/10/06
11/10/06
12/10/06
12/10/06
12/10/06
12/10/06
12/10/06
Catégorie
A320
A320
A320
A320
A320
B747
B747
B747
B747
B747
Site
Orly
Orly
Orly
Orly
Orly
Roissy
Roissy
Roissy
Roissy
Roissy
Nom
Corinne
Amy
Maureen
Richard
Ben
Nicolas
Jean-Marc
Ségolène
François
Fabien
Fonction
Pilote
Copilote
PNC
PNC
PNC
Pilote
Copilote
PNC
PNC
PNC
Figure 1 : Extrait du tableau de service des vols AF347 et AF545 sur une période
L’objectif du système à modéliser est de constituer le tableau de service. Les membres de l’équipage
peuvent visualiser les vols sur lesquels ils sont affectés. L’administrateur du système peut créer et supprimer
des entités dans le système. Le manager peut ajouter et supprimer des personnes dans un équipage pour un
vol donné (un vol est désigné par un numéro de vol et une date). Les données du vol sont archivées après le
vol pour une année2 .
En guise de simplification, nous ne permettons pas à un membre d’équipage d’assurer la fonction de pilote
pour certains vols et de copilote pour d’autres vols.
2
2.1
Questions
Analyse du texte
Après avoir réalisé une analyse du texte, ce qui vous a permis de trouver les noms et les verbes correspondant à
ce problème, choisir les classes qui vous semblent devoir faire partie de la modélisation de ce système. Décrire
textuellement ces classes et les attributs associés à chaque classe : donner le nom des classes, le nom des
attributs et des explications textuelles (uniquement quand cela vous semble nécessaire).
2.2
Diagramme de cas d’utilisation
Décrire les acteurs et les fonctionnalités significatives du système dans un diagramme de cas d’utilisation.
2.3
Diagramme de classes
Construire un diagramme de classes qui représente le système. Précisez les noms des associations, les multiplicités et les sens de navigation des associations (lorsque nécessaire pour la compréhension). Spécifiez aussi
les éventuels généralisations spécialisations et agrégations.
1. Pour simplifier, le tableau ci-dessous n’en représente que quelques-uns.
2. En raison du temps limité, nous ignorons la tenue à jour de la localisation des équipages et le décompte de leurs temps
de vols et de repos.
166
2.4
Diagramme de machine à états
Construire le diagramme de machine à états de la classe qui permet de décrire un groupe d’entrées du tableau
de service correspondant à un vol un jour donné.
2.5
Conception des classes
Dans cette question, nous nous intéressons à la classe qui permet de décrire un groupe d’entrées du tableau
de service correspondant à un vol un jour donné. Traduire par des attributs les associations de cette classe
(faites figurer le nom des attributs, leur type ainsi que leur visibilité).
2.6
Diagramme de communications ou de séquence
Donner le diagramme de communications ou de séquence qui correspond au cas d’utilisation : « affecter un
PNC à un vol ». Durant l’interaction, n’oubliez pas de vérifier que :
• l’équipage n’est pas complet,
• le PNC est en capacité d’effectuer un vol sur cette catégorie d’avion.
Dans le cas contraire, le PNC ne pourra pas être affecté à ce vol. Nous supposons que les arguments de
l’opération lancée par l’acteur sont une référence sur un PNC et une référence à un vol. Enfin, nous souhaitons
que l’opération retourne un booléen indiquant si l’affectation rend l’équipage du vol au complet.
Avant de vous lancer dans la réalisation du diagramme, nous vous conseillons de rédiger en langage
naturel les différentes étapes logiques de l’interaction, c’est-à-dire ce qu’il faut faire.
167
168
Introduction au langage de
programmation Java
Christian Bac, Denis Conan
Revision : 1527
CSC 4002
Octobre 2015
169
Table des matières
Sommaire du cours
1.1 Vous avez dit Java ? . . . . . . . .
1.1.1 Android . . . . . . . . . . .
1.1.2 CAS . . . . . . . . . . . . .
1.1.3 Java partout ! . . . . . . . .
1.1.4 Pourquoi nous ? . . . . . .
1.2 Que recouvre le mot Java ? . . . .
1.2.1 Héros . . . . . . . . . . . .
1.2.2 Projet et Historique . . . .
1.3 Caractéristiques . . . . . . . . . .
1.3.1 Java un langage Objet . . .
1.3.2 Machine Virtuelle Java . . .
1.3.3 Robustesse . . . . . . . . .
1.4 Historique de l’API . . . . . . . . .
1.5.1 Java Standard Development
1.6 En savoir plus . . . . . . . . . . .
1.6.1 Sites Web . . . . . . . . . .
Questions sur les concepts Java . . . .
173
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
174
174
174
175
175
176
176
177
177
178
179
180
180
181
182
182
183
184
184
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
185
185
186
186
188
188
189
189
190
190
191
192
192
3.1 Classe . . . . . . . . . . . . . . . . . . . . .
3.1.1 Classe Personne en Java . . . . . . .
3.1.2 Instance de classe en UML . . . . .
3.1.3 Instance de classe en Java . . . . . .
3.2 Objet . . . . . . . . . . . . . . . . . . . . .
3.2.1 Constructeurs en Java . . . . . . . .
3.2.2 Exemples de constructeurs . . . . . .
3.2.3 this . . . . . . . . . . . . . . . . . .
3.2.4 Exemples d’utilisation de this . . .
3.2.5 Destruction des objets . . . . . . . .
3.2.6 Abstraction et encapsulation . . . .
3.2.7 Visibilité des méthodes . . . . . . . .
3.3 Attributs et méthodes de classe . . . . . . .
3.3.2 Attributs et méthodes de classe . . .
3.4 Association entre classes . . . . . . . . . . .
3.4.1 Exemple d’association . . . . . . . .
3.4.2 Association entre classes en Java . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
194
194
194
196
196
197
197
198
198
198
199
200
200
201
201
202
203
203
204
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Kit
. . .
. . .
. . .
2.1 Syntaxe de base . . . . . . . . . . . .
2.1.1 Premier en C . . . . . . . . . .
2.1.2 Premier en Java . . . . . . . .
2.2 Types Primitifs . . . . . . . . . . . . .
2.2.1 Conversions de type . . . . . .
2.2.2 Exemple de conversions . . . .
2.2.3 Tableaux . . . . . . . . . . . .
2.2.4 Exemple avec un tableau . . .
2.3 Tableaux . . . . . . . . . . . . . . . .
2.4 Méthodes . . . . . . . . . . . . . . . .
2.5 Exemple de passage d’arguments . . .
Questions sur la syntaxe de base de Java .
.
.
.
.
.
.
.
.
.
.
.
.
Télécom SudParis — Christian Bac, Denis Conan — Octobre 2015 — CSC 4002
170
Questions sur les classes et objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
4.1 Généralisation spécialisation . . . . . . . . . . . . . . . . . .
4.1.1 Héritage : comment en Java . . . . . . . . . . . . . .
4.1.2 Héritage et constructeur . . . . . . . . . . . . . . . .
4.1.3 Exemple de classe parente et classe dérivée . . . . .
4.1.4 Utilisation de classe parente et dérivée . . . . . . . .
4.2 Polymorphisme . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Exemple de Upcast et Downcast . . . . . . . . . . .
4.3 Redéfinition de méthodes dans les classes dérivées . . . . .
4.4 Héritage, membres et visibilité . . . . . . . . . . . . . . . .
Questions généralisation/spécialisation en Java . . . . . . . . .
4.5 Classes abstraites . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Classes abstraites : principes . . . . . . . . . . . . .
4.5.2 Classes abstraites en Java . . . . . . . . . . . . . . .
4.6 Exemple de classe Abstraites . . . . . . . . . . . . . . . . .
4.6.1 Exemple : classes abstraites . . . . . . . . . . . . . .
4.7 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.1 Interfaces en Java . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
206
206
207
207
208
209
210
211
212
212
213
213
214
214
215
215
216
218
218
5.1 Programme en C (rappel) . . . . . . . . . . . . . . . .
5.2 Exécution d’un programme (rappel) . . . . . . . . . .
5.4 Dans le cas de Java . . . . . . . . . . . . . . . . . . .
5.5 Unités de compilation . . . . . . . . . . . . . . . . . .
5.6 Paquetages . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1 Chemin de recherche . . . . . . . . . . . . . . .
5.6.2 Exemple . . . . . . . . . . . . . . . . . . . . . .
5.7 Visibilité en Java . . . . . . . . . . . . . . . . . . . . .
5.7.1 Table de visibilité . . . . . . . . . . . . . . . . .
Questions organisation des sources en Java . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
220
220
220
221
222
222
223
224
224
224
225
226
6 API Java
6.1 Premières classes de l’API . . . . . . . . . .
6.2 Classe java.lang.Object . . . . . . . . . .
6.2.1 Égalité . . . . . . . . . . . . . . . . .
6.2.2 Exemple d’égalité . . . . . . . . . . .
6.2.3 Exemple de méthode equals . . . . .
6.3 Interface de programmation . . . . . . . . .
6.3.1 Quelques paquetages Java . . . . . .
6.4 java.lang.* . . . . . . . . . . . . . . . . . . .
6.4.1 Exemple avec la classe Integer . . .
6.4.2 Classe String . . . . . . . . . . . . .
6.4.3 Exemple pour String . . . . . . . .
Questions API java.lang . . . . . . . . . . . . .
6.5 java.util.* . . . . . . . . . . . . . . . . . . .
6.5.1 Classe paramétrée . . . . . . . . . .
6.5.2 Classes Abstraites des collections . .
6.5.4 Collections . . . . . . . . . . . . . .
6.5.5 Interface Iterable . . . . . . . . . .
6.5.6 Interface Collection<E> . . . . . .
6.5.7 Interface List<E> . . . . . . . . . .
6.5.8 Classe Vector<E> . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
227
227
227
229
229
230
231
231
232
233
233
233
234
234
235
236
237
237
238
238
239
239
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
171
6.5.9 Boucle pour les collections . . . .
6.5.10 Exemple for-each sur un Vector
6.5.11 Exemple de classe avec Vector
6.5.12 Interface Iterator . . . . . . .
6.5.13 Exemple avec Iterator . . . .
6.5.14 Dictionnaires Map<K,V> . . . . .
6.5.15 Exemple pour Map . . . . . . . .
6.5.16 Dictionnaire Hashtable<K,V> .
6.5.17 Exemple pour Hashtable . . . .
6.5.18 Représentation d’une Hashtable
Questions collections en Java . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
240
241
241
242
243
244
244
245
246
246
247
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
248
248
249
250
250
251
251
252
253
254
8.1 Copie simple/légère . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.1 Copie pour studs . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.2 Représentation graphique d’une copie légère dans studs . . . .
8.1.3 Exemple de copie légère . . . . . . . . . . . . . . . . . . . . . .
8.1.4 Représentation graphique d’une copie plus profonde dans studs
8.1.5 Copie plus profonde dans studs . . . . . . . . . . . . . . . . . .
8.1.6 Représentation graphique d’une copie profonde . . . . . . . . .
8.1.7 Clone de Scrutin . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.8 Clone en copie profonde de Personne . . . . . . . . . . . . . .
8.1.9 Suite exemple de copie profonde . . . . . . . . . . . . . . . . .
8.2 Retour sur hashCode() . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 Exemple hashCode . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Retour sur les exceptions . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1 Test des exceptions . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2 RuntimeException . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
256
256
257
257
257
259
259
261
262
263
264
265
266
266
267
269
7.1 Motivation : retours sur un bug . . .
7.2 Principes . . . . . . . . . . . . . . .
7.2.1 Mise en œuvre . . . . . . . .
7.2.2 Exemple de traitement . . . .
7.3 Réalisation . . . . . . . . . . . . . .
7.3.1 java.lang.Exception . . . . . .
7.4 Traitement des exceptions . . . . . .
Questions sur les exceptions . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Bibliographie
271
172
'
$
Sommaire du cours
#2
1
2
3
4
5
6
7
8
Introduction à Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Concepts de bases de Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Classes et objets en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Généralisation spécialisation en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Organisation des sources Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
API Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Exceptions en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Concepts objets avancés en Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
&
%
La structure du cours est la suivante :
1. généralités sur le langage et présentation de la machine virtuelle Java,
2. syntaxe de base et types primitifs,
3. classes et objets, associations entre objets,
4. généralisation et spécialisation entre classes,
5. organisation des fichiers sources et compilés,
6. classes Java indispensables de la bibliothèque,
7. types paramétriques et collections,
8. gestion des exceptions,
9. concepts avancés de Java : interface, copie d’objet.
173
'
1.1 Vous avez dit Java ?
$
#3
1.1
1.2
1.3
1.4
1.5
1.6
Vous avez dit Java ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Que recouvre le mot Java ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Historique de l’API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Environnements de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
En savoir plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
&
%
Cette section présente les concepts généraux du langage Java. Ces concepts sont souvent partagés par
les langages postérieurs aux années 1990. Cette introduction mélange la culture générale et les spécificités
techniques. Les grandes lignes de cette section sont proches de la page wikipedia sur Java.
'
$
#4
À quoi cela sert-il ?
Pourquoi nous ?
&
%
174
'
$
1.1.1 Android
#5
Android : Java est le logiciel prépondérant des + 500 000 applications.
&
%
'
$
1.1.2 CAS
#6
&
%
175
'
$
1.1.3 Java partout !
#7
&
%
'
$
1.1.4 Pourquoi nous ?
#8
&
%
176
'
$
Un projet et des évolutions sur + de 20 ans
#9
Un langage objet
Une architecture basée sur une machine virtuelle
Des interfaces de programmation objet
Des outils (Java Development Kit)
&
%
Nous détaillons chacun de ces points dans les diapositives suivantes.
$
'
1.2.1 Héros
# 10
&
%
177
'
$
1.2.2 Projet et Historique
1990 : équipe autour de James Gosling et sous l’impulsion de Bill Joy
1993 : projet de langage pour l’électronique grand public
1995 : Java Development Kit (JDK) 1.0 b1 + support dans le navigateur Netscape
1998 : mise en place du Java Community Process
# 11
1999 : Java 2 Standard Edition (J2SE) 1.2 (Java DataBase Connector amélioré,
interface graphique Swing, collections)
2005 : J2SE 1.5, alors renommé J2SE 5 (types paramétrés, annotations, collections
revues)
2006-2007 : J2SE6 et libération du code passage sous licence General Public
License, alias GNU/GPL
2009 : rachat de SUN microsystems par ORACLE
2011 : J2SE 7
&
%
L’historique de Java est décrit à la page http://www.oracle.com/technetwork/java/javase/overview/javahistory-in
C’est un projet qui débute dans la première moitié de la décennie 1990. À l’époque, SUN travaille sur
l’informatique répartie et a réalisé un système d’exploitation appelé NEXT (Unix sur un ensemble de stations
de travail). Le PC d’IBM et Microsoft est encore absent du paysage pour eux. Les objectifs de l’équipe sont
principalement de pallier les difficultés à programmer en langage C++, tout en conservant une compatibilité
avec la syntaxe de base connue des programmeurs C.
Les membres du projet ciblent le support de petites machines de type assistant personnel, ou consoles de
jeux. Les événements suivants sont importants dans cet historique :
• le navigateur Web de la société Netscape supporte Java dès 1995.
• la constitution du Java Community Process (JCP) en 1998. Cette constitution répond à la nécessité
de standardiser le langage par un processus ouvert comparable à celui des standards Internet. Ce
processus est indispensable pour le langage apparaisse indépendant de la compagnie .
• les versions J2SE se succèdent à peu près tous les deux ans, par des ajouts de classes et de fonctionnalités
décidées selon le JCP.
• Fin 2006 et courant 2007, SUN entreprend d’expurger son code de toute partie pouvant poser problème
en matière de propriété intellectuelle et place le code obtenu sous licence GNU/GPL ;
• en 2009, Oracle rachète SUN, ce qui questionne les communautés libres sur l’avenir de Java mais aussi
sur celui de MySQL dont SUN était propriétaire par le rachat de la compagnie MySQL AB en 2008.
178
'
1.3 Caractéristiques
$
Objet
# 12
Exécuté par une machine virtuelle
Permettant d’écrire des programmes robustes
Simple : C comme syntaxe de base
Sûr, multi-activité, réparti
&
%
Nous détaillons certains de ces points dans les diapositives suivantes. Nous ne traitons pas des parties
sûreté, multi-activité et répartition. Ces sujets sont, en effet, trop avancés pour ce cours. Certains sont
abordés en troisième année dans les VAP ASR (« Applications et Services informatiques Répartis ») ou SSR
(« Sécurité des Systèmes et des Réseaux »).
'
$
1.3.1 Java un langage Objet
Tout est classe sauf les types primitifs (int, float, double, etc.)
Tout objet est manipulé à travers une référence
# 13
La spécialisation est simple entre les classes
Toutes les classes dérivent de java.lang.Object
Les tableaux sont construits à partir d’une classe particulière
L’API (en anglais, Application Programming Interface) est un ensemble de classes
&
%
Java est un langage orienté objet. La notion de classe est centrale dans ce langage et tout le code est
contenu dans des classes.
Seules les variables de type primitif ne sont pas des objets. Les types primitifs correspondent aux types
du langage C. Ces types primitifs servent à créer des variables locales dans les méthodes et des attributs pour
les classes.
Les objets ne sont pas manipulés directement mais à travers des pointeurs dé-référencés de manière
automatique et appelés références. Nous présentons l’implication de cette propriété relativement aux égalités
179
et aux copies d’objets dans la section 6.2.1.
Comme tous les langages orientés objet, Java supporte la généralisation spécialisation. Pour simplifier la
réalisation, Java ne permet que la généralisation spécialisation simple, c’est-à-dire qu’une classe dérive d’une
classe et d’une seule.
Toutes les classes dérivent d’une classe racine appelée java.lang.Object. Cette classe définit des comportements stéréotypés dont nous reparlons de manière approfondie dans le section 6.2.
Les tableaux sont des objets traités de manière particulière. Ils sont construits à partir d’une classe qui
est manipulée par l’environnement de programmation.
L’ensemble des bibliothèques de fonctions est réalisé à base de classes.
$
'
1.3.2 Machine Virtuelle Java
Les compilateurs génèrent du code intermédiaire (en anglais, bytecode)
Ce code intermédiaire est interprété par les « Java Virtual Machines » (JVM)
Modèle « compile once execute everywhere »
Java Virtual Machine (JVM) :
# 14
s’exécutent sur les systèmes d’exploitation (par exemple avec la commande java)
ou sont intégrées dans les navigateurs Web
Sémantique du langage plus stricte que celle du langage C
Taille et domaine de valeur des types primitifs identiques sur toutes les plate-formes
Code source Unicode (accents et autres glyphes)
Bibliothèques standards riches
&
%
La portabilité du code Java a toujours été un objectif pour ses concepteurs. Cette portabilité n’a pas
toujours été parfaite mais elle est bien plus grande que celle des langages des générations précédentes.
Contrairement à une chaîne de compilation de langage C qui génère du code directement exécutable sur un
processeur, un compilateur Java génère du code intermédiaire appelé en anglais bytecode. Ce code est contenu
dans un fichier dont le suffixe est .class. Un fichier .class peut être chargé par une machine virtuelle Java
et interprété par celle-ci. Le code intermédiaire est totalement indépendant de la machine sur laquelle il a été
généré. Il est aussi indépendant du compilateur qui l’a produit. Ce code permet de recréer le fichier source
facilement. Le modèle de compilation est appelé en anglais « compile once, execute everywhere ».
Les tailles et les domaines de valeur des types primitifs sont identiques sur toutes les plates-formes.
Ainsi, quelle que soit l’architecture matérielle sur laquelle le programme s’exécute, un entier utilisé par
un programme Java possède une taille identique. Le principe du bytecode date des années 1980 avec son
introduction dans certains compilateurs du langage Pascal. Il se retrouve aussi aujourd’hui dans l’ensemble
de la chaîne de compilation de Microsoft associée aux langages C et C#.
Les JVM s’exécutent directement sur les systèmes d’exploitation. C’est par exemple la commande java
sous Linux. Elles peuvent être embarquées dans les navigateurs Web.
La sémantique du langage Java est plus contraignante que celle du langage C. Par exemple, il est obligatoire
d’avoir une expression booléenne dans un test.
Le code source des classes peut être écrit en caractères Unicode. La collaboration entre développeurs
préconise l’utilisation de variables dont le nom est compréhensible par le plus grand nombre.
Comme nous le verrons dans la section 6, les bibliothèques standards sont très nombreuses.
180
'
$
1.3.3 Robustesse
Conçu pour du logiciel embarqué
Gestion de la mémoire avec ramasse miettes (en anglais, garbage collector )
Pas d’accès à la mémoire physique
# 15
Gestion des erreurs par exception (voir section 7)
Contrôle des types à l’exécution
Compilateurs stricts et prévenants par exemple :
Avertissement lorsqu’une variable est affectée et non utilisée
Erreur à l’utilisation de variables non initialisées
Erreur lorsque les exceptions ne sont pas gérées
&
%
Le langage Java permet de réaliser des programmes robustes. Il a été conçu pour réaliser des logiciels
embarqués. Il tend à pallier les difficultés dues à la gestion de la mémoire en C ou C++. Pour cela, le langage est
doté d’un ramasse miettes. Les allocations d’objets sont dynamiques et la récupération de l’espace mémoire
inutilisé est réalisée par ce ramasse miettes (Garbage Collector ou GC). Les langages modernes sont dotés de
ramasse miettes. Le GC est déclenché lorsque la mémoire disponible de la JVM est faible ou périodiquement.
Le GC est un processus qui consomme du temps et il doit être contrôlable pour permettre des applications de
type temps réel. Contrairement au langage C, il n’est pas possible d’adresser directement une zone mémoire
physique à partir d’un programme Java.
Comme nous le verrons dans la section 7, la gestion des erreurs est réalisée en utilisant un mécanisme
qui permet de signaler l’erreur en un point du programme et de traiter cette erreur en un autre point. Le
flot de contrôle des erreurs est matérialisé par des instructions de contrôle particulières que nous présentons
dans la section 7.
Il n’existe pas d’équivalent à l’édition de liens pour produire un binaire exécutable. En Java, un programme
est composé d’un ensemble de fichiers de bytecode interprétables par la JVM. La JVM charge ces fichiers, que
l’on appelle aussi classes, à partir de leurs noms comme nous le décrirons dans la section 5.6. La JVM réalise
des contrôles de type au même titre que le compilateur lorsqu’elle charge une classe. Les classes peuvent
aussi être télé-chargées. Dans ce cas, elles sont vérifiées à partir d’une chaîne de certification. Les classes
télé-chargées sont exécutées dans un environnement limité. Par exemple, elles ne peuvent pas accéder au
système de fichiers.
Le compilateur Java est plus strict qu’un compilateur C. Par exemple, il n’autorise pas l’utilisation d’une
variable si elle n’a pas été explicitement initialisée. Il émet des avertissements si une variable est affectée
mais non utilisée. Il interdit aussi que les exceptions ne soient pas traitées.
181
'
$
1.4 Historique de l’API
Années de réalisation, et nombre de classes et d’interfaces des versions de Java
Java SE 7 2011 : 3 977
Java SE 6 2007 : 3 777
# 16
J2SE 5.0 2004 : 3 270
J2SE 1.4 2002 : 2 723
J2SE 1.3 2000 : 1 840
J2SE 1.2 1998 : 1 524
JDK 1.1 1997 : 477
JDK 1.0 1996 : 211
&
%
Outre les évolutions du langage, les bibliothèques de programmation associées à Java ont crû de manière
impressionnante, passant de 211 classes et interfaces dans la première version stable à presque 4000 dans la
version actuelle.
Nous verrons de ces bibliothèques quelques classes indispensables et dont les caractéristiques stéréotypées
vous permettront d’aborder d’autres bibliothèques si le besoin se présente.
'
$
# 17
Java Development Kit : compilateur, JVM, Appletviewer...
Eclipse, NetBeans, Jbuilder, Visual J++...
&
%
Les environnements de programmation permettant de programmer en Java sont nombreux. Nous utiliserons pendant les travaux pratiques le JDK et l’environnement eclipse. L’utilisation du JDK nous permet
de matérialiser l’étape de compilation du bytecode puis l’exécution dans l’environnement de la machine
virtuelle.
182
'
$
1.5.1 Java Standard Development Kit
javac : compilateur
java : JVM interpréteur de bytecode
javadoc : générateur de documentation
# 18
appletviewer : environnement pour applet
javah : générateur d’entêtes pour mélange avec code natif en C (JNI)
javap : désassembleur de code intermédiaire
jdb : dévermineur
javakey : générateur de clés pour signer le code
&
%
Le JDK permet de matérialiser les différentes parties de la chaîne de production utilisée dans le développement d’un programme Java.
Ainsi, il est nécessaire de traduire les fichiers contenant du langage Java en des fichiers contenant du
bytecode. C’est le rôle du compilateur (javac).
La commande java est la machine virtuelle dans laquelle le bytecode peut s’exécuter.
La commande javadoc permet d’extraire la documentation du code pour réaliser des pages semblables
à celles de la documentation des bibliothèques.
La commande appletviewer permet d’exécuter du code destiné à être interprété dans un navigateur
Web. Ce type de code est appelé applet.
$
'
1.6 En savoir plus
Java Series : http://docs.oracle.com/javase//
The Java Tutorial, Campione, Walrath, 5th edition, 2013,
The Java Programming Language, Arnold, Gosling, Holmes, 5th edition, 2013,
The Java Language Specification, J. Gosling, B. Joy, G. Steele, G. Bracha, A.
Bukley, 4th edition, 2013,
# 19
The Java Virtual Machine Specification, T. Lindholm, F. Yellin, G. Bracha, A.
Bukley, 3rd edition, 2013
Livres
D. Flanagan, « Java in a Nutshell : A Desktop Quick Reference, 5th Edition »,
O’Reilly, 2005
D. Flanagan, « Java Examples in a nutshell : A Tutorial Companion to Java in a
Nutshell », 3rd Edition, 2004
P. Niemeyer and J. Knudsen, « Learning Java », O’Reilly, 2005
J. Bloch, « Effective Java, 2nd Edition », Addison Wesley, 2008
&
%
Les documents du site d’Oracle sont les références écrites par les auteurs du langage ou des personnes de
leur équipe. Ils sont accessibles et nous vous recommandons de les consulter pour répondre à vos questions
183
plutôt que de naviguer dans un océan de questions-réponses plus ou moins appropriées via les moteurs de
recherche.
Nous pensons aussi que le tutoriel en ligne est bien fait et qu’il mérite que vous y passiez du temps
en complément de ce cours. À cette fin nous avons mis ce tutoriel en accès local sur l’URL suivant :
http://www-inf.int-evry.fr/cours/java/javatutorial/
Les livres sont les préférés des différents membres de l’équipe pédagogique.
'
$
1.6.1 Sites Web
http://moodle.tem-tsp.eu/moodle/view.php?id=26
http://www-inf.it-sudparis.eu/COURS/CSC4002/
# 20
http://http://www.oracle.com/technetwork/java/index.html: Oracle
Java(tm) Technology Home Page
http://www.javaworld.com: Infos
http://www.developer.com/java: Infos Liens
&
%
Voici les sites Webs qui vous permettront de gagner du temps dans votre apprentissage.
Les deux premiers représentent les liens vers les ressources pédagogiques propres à ce cours. Les autres
sont des points d’entrée vers des sites riches en informations et en exemples de programmes en Java.
'
$
Questions sur les concepts Java
En Java tout est-il objet ?
# 21
La machine virtuelle Java :
garantit-elle l’uniformité des variables de type primitif ?
met-elle en œuvre la gestion mémoire et en particulier le ramasse miettes ?
&
%
184
'
$
# 22
2.1
2.2
2.3
2.4
2.5
Syntaxe de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Types Primitifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Exemple de passage d’arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
&
%
Cette partie se concentre sur les bases du langage Java. Nous supposons que vous connaissez le langage C. Dans cette partie, nous focalisons notre attention sur les concepts nouveaux et les différences relativement à ce langage connu. Cette partie permet de traduire
les algorithmes. La partie 1 « Bien commencer en Java » du site du zéro sur Java
(http:http://fr.openclassrooms.com/informatique/cours/apprenez-a-programmer-en-java) correspond aux notions que nous présentons ici. Son parcours est recommandé à ceux qui n’ont pas programmé
depuis longtemps.
'
$
2.1 Syntaxe de base
Syntaxe de base C
Instructions de contrôle : if, switch, for, while, do while
Opérateurs : tous les opérateurs du C par exemple, + - / * %,
# 23
Blocs, instructions simples : {}, « ; »
Quelques différences
final remplace const
espaces de nommage plus nombreux : classe, fichier, groupe de classes
private remplace static
static prend un sens associé au concept de classe
&
%
La syntaxe de base du langage est inspirée de celle du langage C. L’ensemble des instructions de contrôle
du langage C est repris. Les opérateurs sont identiques. Les blocs d’instructions sont semblables. Ainsi, un
programmeur connaissant le langage C trouve la syntaxe familière et comprend rapidement les algorithmes
mis en œuvre.
185
2.1 Syntaxe de base
Une syntaxe nouvelle pour l’instruction de boucle for est utilisée pour faciliter l’écriture des parcours de
collections. Elle est détaillée dans la section 6.5.9.
Il existe de nombreuses différences sur l’utilisation de mots réservés et en particulier des mots final,
static et private. Nous étudierons ces différences dans leurs différents contextes durant ce cours.
'
$
2.1.1 Premier en C
1
2
3
#i n c l u d e < s t d l i b . h>
#i n c l u d e < s t d i o . h>
t y p e d e f enum { FAUX=0 , VRAI=1 } B o o l e e n ;
4
5
6
s t a t i c B o o l e e n e s t P r e m i e r ( i n t nombre ) {
i n t b o r n e=nombre / 2 ;
7
i f ( nombre==1) r e t u r n FAUX ;
f o r ( i n t p r e d =2; p r e d<=b o r n e ; p r e d++) {
i f ( nombre%p r e d ==0) {
r e t u r n FAUX ;
}
}
r e t u r n VRAI ;
8
9
# 24
10
11
12
13
14
15
}
16
17
18
19
20
i n t main ( ) {
int
nb ;
p r i n t f ( " S a i s i r ␣ une ␣ v a l e u r ␣>␣ 0 ␣ : ␣ " ) ;
s c a n f ( "%d " , &nb ) ;
21
i f ( nb<=0) {
22
# 25
&
%
'
$
23
p r i n t f ( " E r r e u r ␣ de ␣ s a i s i e \n " ) ;
24
return
EXIT_FAILURE ;
25
}
26
p r i n t f ( " Le ␣ nombre ␣%d␣ " , nb ) ;
27
i f ( e s t P r e m i e r ( nb ) ) {
p r i n t f ( " e s t ␣ p r e m i e r \n " ) ;
28
} else {
29
p r i n t f ( " n ’ e s t ␣ p a s ␣ p r e m i e r \n " ) ;
30
}
31
r e t u r n EXIT_SUCCESS ;
32
33
}
&
%
Dans cet exemple nous reprenons un exercice simple d’algorithmique qui consiste à saisir un nombre entier
et à déterminer si ce nombre est premier. Vous pouvez noter de grandes similitudes sur la partie algorithme des
deux programmes en C et en Java. La différence majeure entre les deux versions de la méthode estPremier
tient au fait qu’en langage C, il n’existe pas de type correspondant à une valeur booléenne.
186
'
2.1 Syntaxe de base
$
2.1.2 Premier en Java
1
2
3
4
5
6
7
8
9
# 26
10
11
12
13
14
15
16
17
18
19
20
21
22
package c o m p l e m e n t s . commeenc ;
public c l a s s Premier {
p r i v a t e s t a t i c b o o l e a n e s t P r e m i e r ( f i n a l i n t nb ) {
i f ( nb == 1 ) { r e t u r n f a l s e ; }
f o r ( i n t i =2; i <= nb / 2 ; i ++) {
i f ( nb%i == 0 ) {
return false ;
}
}
return true ;
}
p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
i n t nombre = C o n s o l e . r e a d I n t ( " E n t r e z ␣ un ␣ nombre ␣ e n t i e r " ) ;
System . o u t . p r i n t l n ( " Le ␣ nombre ␣ " + nombre + " ␣ e s t − i l ␣ p r e m i e r ␣ ? " ) ;
System . o u t . p r i n t ( " Le ␣ nombre ␣ " + nombre ) ;
i f ( e s t P r e m i e r ( nombre ) ) {
System . o u t . p r i n t l n ( " ␣ e s t ␣ p r e m i e r " ) ;
} else {
System . o u t . p r i n t l n ( " ␣n ’ e s t ␣ p a s ␣ p r e m i e r " ) ;
}
}
}
&
%
Dans l’exemple précédent, nous avons besoin de réaliser des entrées au clavier. Cette opération est relativement complexe, car elle utilise des classes de l’interface standard Java. C’est pourquoi, nous avons réalisé
la classe utilitaire Console pour masquer la complexité de ces opérations et fournir des méthodes simples
pour obtenir des nombres entiers ou des chaînes de caractères du flux d’entrée. Le code de cette classe est
donné ci-après, vous n’aurez les connaissances nécessaires pour la comprendre que vers la fin du module.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
package complements . commeenc ;
import j a v a . i o . ∗ ;
/∗∗
∗ Permet de l i r e d e s nombres e t d e s c h a i n e s de c a r a c t e r e s
∗ au c l a v i e r .
∗/
public c l a s s C o n s o l e {
/∗∗
∗ La c o n s o l e e s t un f l o t de c a r a c t e r e s b u f f e r i s e .
∗/
private s t a t i c B u f f e r e d R e a d e r c o n s o l e =
new B u f f e r e d R e a d e r (new I n p u t S t r e a m R e a d e r ( System . i n ) ) ;
/∗∗
∗ A f f i c h e un message a l ’ ecran s ans f i n de l i g n e .
∗ @param prompt Message a a f f i c h e r
∗/
public s t a t i c void p r i n t P r o m p t ( f i n a l S t r i n g prompt ) {
System . o u t . p r i n t ( prompt + " ␣ " ) ;
System . o u t . f l u s h ( ) ;
}
/∗∗
∗ L e c t u r e d ’ une c h a i n e de c a r a c t e r e s au c l a v i e r . La c h a i n e ne
∗ c o n t i e n t pas l e c a r a c t e r e ’ f i n de l i g n e ’ . En c a s de f i n de
∗ f i c h i e r ou d ’ e r r e u r , l a c h a i n e r e t o u r n e e v a u t <code>n u l l </code >.
∗ @return La c h a i n e l u e
∗/
public s t a t i c S t r i n g r e a d L i n e ( ) {
String r = " " ;
try {
r = console . readLine ( ) ;
} catch ( I O E x c e p t i o n e ) { r = n u l l ; }
return r ;
}
/∗∗
∗ L e c t u r e d ’ une c h a i n e de c a r a c t e r e s au c l a v i e r a vec a f f i c h a g e d ’ un
∗ prompt .
∗
@param prompt Message a a f f i c h e r
∗
@return La c h a i n e l u e
∗
@see #printPrompt ( S t r i n g )
∗
@see #r e a d L i n e ( )
∗/
public s t a t i c S t r i n g r e a d L i n e ( f i n a l S t r i n g prompt ) {
p r i n t P r o m p t ( prompt ) ;
return r e a d L i n e ( ) ;
}
187
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
}
2.2 Types Primitifs
/∗∗
∗ L e c t u r e d ’ un e n t i e r au c l a v i e r .
∗
∗
@return L ’ e n t i e r l u
∗
@ e x c e p t i o n NumberFormatException en c a s d ’ e r r e u r
∗/
public s t a t i c i n t r e a d I n t ( f i n a l S t r i n g prompt )
throws NumberFormatException {
return I n t e g e r . v a l u e O f ( r e a d L i n e ( ) . t r i m ( ) ) . i n t V a l u e ( ) ;
}
/∗∗
∗ L e c t u r e d ’ un d o u b l e au c l a v i e r .
∗
∗
@return Le d o u b l e l u
∗
@ e x c e p t i o n NumberFormatException en c a s d ’ e r r e u r
∗/
public s t a t i c double r e a d D o u b l e ( f i n a l S t r i n g prompt )
throws NumberFormatException {
return Double . v a l u e O f ( r e a d L i n e ( ) . t r i m ( ) ) . d o u b l e V a l u e ( ) ;
}
$
'
2.2 Types Primitifs
pas des classes
# 27
short(2 octets), int (4 octets), long (8 octets)
float (4 octets), double (8 octets)
boolean (true/false), byte (1 octet), char (2 octets)
Variables déclarées n’importe où dans un bloc
&
%
Les types primitifs ne sont pas des classes. Ils permettent de définir des variables ou des attributs. Comme
nous l’avons dit dans la section précédente, les tailles et domaines de valeurs sont définis strictement. Vous
retrouvez les types communs correspondant aux nombres entiers signés du langage C : short, int, long.
Les nombres en virgule flottantes float et double sont conformes à la norme IEEE 754.
Le type boolean est nouveau. Il ne peut prendre que les valeurs true ou false.
Le type byte correspond au type char du langage C. C’est un type entier exprimé sur 8 bits en complément
à 2 dont la valeur peut varier de -128 à +127.
Le type char quant à lui est utilisé pour contenir un caractère codé sur 16 bits en Unicode.
188
'
2.2 Types Primitifs
$
2.2.1 Conversions de type
Conversions sur les types primitifs :
# 28
Conversions sûres OK (d’un type vers un type plus complexe)
Conversions non sûres (d’un type vers un type plus pauvre) nécessitent un
transtypage (en anglais, cast) explicite
&
%
Les conversions entre types primitifs sont plus strictes qu’en langage C. Ainsi, les conversions qui vont
d’un type simple vers un type plus complexe sont acceptées. Cependant, celles qui vont d’un type complexe
vers un type plus simple doivent être associées à un transtypage explicite.
'
$
2.2.2 Exemple de conversions
1
p u b l i c c l a s s CastExampleFixed {
p u b l i c s t a t i c v o i d main ( f i n a l
2
# 29
String [ ]
args ) {
i = 2127272 ; // 0 x002075A8
3
int
4
l o n g m;
5
short s ;
6
byte b ;
7
m = i ; // p r o m o t i o n OK
8
// E x p l i c i t c a s t n e e d e d
i = ( i n t ) m;
9
10
s = ( s h o r t ) i ; // 0 x75A8
11
b = ( byte ) i ;
12
System . o u t . p r i n t l n ( "m=␣ " + m + " ; ␣ s=␣ " + s + " ; ␣b=␣ " + b ) ;
}
13
14
// 0xA8
}
Résultat de l’exécution :
m= 2127272; s= 30120; b= -88;
&
%
189
'
$
2.2.3 Tableaux
Les tableaux sont des objets
Leur taille est fixe
# 30
Leur taille est allouée dynamiquement par l’utilisation du mot réservé new
L’accès aux entrées est identique à celle en langage C une fois l’allocation faite
Erreur d’accès en cas de dépassement de taille
&
%
Nous avons dit précédemment que les tableaux étaient des objets. Ils n’ont pas la capacité à changer de
taille, mais ils doivent être alloués dynamiquement.
Ils sont traités de manière à empêcher les erreurs d’accès relativement au nombre d’entrées qu’ils
contiennent.
$
'
2.2.4 Exemple avec un tableau
1
p u b l i c c l a s s ArrayExample {
p u b l i c s t a t i c v o i d main ( S t r i n g [ ]
2
# 31
a r r a y O f I n t ; // o r
args ) {
3
int []
i n t a r r a y O f I n t [ ] ; // d e c l a r a t i o n de l a v a r i a b l e a r r a y O f I n t
4
a r r a y O f I n t = new i n t [ 4 2 ] ; // c r e a t i o n du t a b l e a u e t a s s o c i a t i o n a a r r a y O f I n t
5
a r r a y O f I n t [ 0 ] = 3 ; // a f f e c t a t i o n d ’ un e l e m e n t du t a b l e a u
6
7
System . o u t . p r i n t l n ( " A r r a y ␣ l e n g t h ␣ "+ a r r a y O f I n t . l e n g t h ) ; // o b t e n t i o n de l a
8
System . o u t . p r i n t l n ( a r r a y O f I n t [ 4 2 ] ) ;
}
9
10
t a i l l e du t a b l e a u ( 4 2 )
// i m p o s s i b l e l e v e e d ’ un e x c e p t i o n
}
Array length 42
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 42
at ArrayExample.main(ArrayExample.java:8)
&
%
190
'
$
2.3 Tableaux
Déclaration de la référence
int[] arrayOfInt; // or
int arrayOfInt[];
Création avec association de taille
# 32
arrayOfInt = new int[42];
Taille
int t = arrayOfInt.length;
Compatibilité avec C :
int[] primes = {1, 2, 3, 5, 7, 7+4};
&
%
Les tableaux sont des objets gérés de manière particulière par l’infrastructure du langage. Les variables de
type tableau sont déclarées comme des références et ne sont pas associées à l’espace mémoire correspondant.
La création d’un tableau est réalisée par l’appel du mot réservé new. C’est à ce moment que la taille du
tableau est fixée et que la référence est associée à l’objet tableau. La taille d’un tableau est connue en
accédant à l’attribut en lecture seule length. La syntaxe du langage Java pour accéder à un attribut ou une
méthode associée à un objet correspond à celle du langage C pour accéder à un membre d’une structure : le
point (« . ») permet de passer de la référence de l’objet à ses attributs ou méthodes. Nous approfondirons
ceci dans la section 3.
Pour des raisons de compatibilité ascendantes avec le langage C, les tableaux initialisés sont acceptés lors
de la définition de la référence.
'
$
2.4 Méthodes
Nom donné aux opérations
Méthodes associées aux classes (pas de méthode sans classe)
Surcharge (en anglais, overloading) des méthodes possible
# 33
Méthode d’instance
Méthode de classe avec mot réservé static
Prototype de la méthode public static void main(final String [])
Passage d’arguments
Par valeur pour les types primitifs
Par référence pour les objets et les tableaux
&
%
Ce que vous connaissez sous le concept de fonction en langage C (partie de code, associée à une liste
191
de paramètres et un type de retour) est appelé opération en UML et méthode en Java ainsi que dans de
nombreux langages objets.
En Java, les méthodes ne sont pas définies dans un seul espace de nommage comme en langage C. Chaque
méthode est définie à l’intérieur d’une classe. Dans une classe les méthodes sont identifiées par leur nom et la
liste de leurs paramètres, ce qui donne la possibilité d’avoir plusieurs méthodes dans une classe qui portent le
même nom mais qui travaillent sur des paramètres de types différents. Cette possibilité est appelée surcharge
de méthodes (overloading en anglais).
Dans le cas le plus courant, les méthodes sont associées aux objets d’une classe. Elles sont utilisées à
travers une référence d’objet. Nous approfondirons ceci dans le chapitre 3. Les méthodes de ce type sont
appelées méthodes d’instance car elles agissent sur un objet à la fois.
Les méthodes peuvent aussi être associées à la classe lorsqu’elles sont qualifiées de static, comme les
méthodes que nous avons vues jusqu’à maintenant, et en particulier la méthode main. Ce type de méthode
est dit de classe. Ces méthodes de classe peuvent être utilisées directement en associant le nom de la classe
et le nom de la méthode reliés par un point comme dans Math.sqrt(4).
La méthode de classe public static void main(String []) joue un rôle identique à la méthode int
main(int argc, char *argv[]) du langage C. Elle sert de point d’entrée pour un programme.
Les variables de type primitif sont passées par copie de la valeur. Les variables de type tableau ou objet
sont manipulées en Java à travers une référence. Lors du passage d’une référence à une méthode, cette
référence permet de manipuler l’objet d’origine. Ainsi toute modification réalisée à travers une référence
dans une méthode appelée modifie l’objet qui est référencé de manière visible par la méthode appelante.
$
'
2.5 Exemple de passage d’arguments
1
p u b l i c c l a s s EssParm {
p r i v a t e s t a t i c v o i d add ( i n t c ,
2
i n t [ ] as ) {
4
a s [ 0 ] ++;
5
System . o u t . p r i n t l n ( " add ␣ : ␣ c=" + c + " , ␣ a s [ 0 ] = " + a s [ 0 ] ) ;
6
}
7
int
8
# 34
final
c++;
3
i n t s [ ] = new i n t [ 1 0 ] ;
9
10
s [0] = 0;
11
add ( i , s ) ;
System . o u t . p r i n t l n ( " main ␣ : ␣ i=" + i + " , ␣ s [ 0 ] = " + s [ 0 ] ) ;
12
}
13
14
String argv [ ] ) {
i = 0;
}
add : c=1, as[0]=1
main : i=0, s[0]=1
&
%
Les variables de type primitif sont passées par copie. La modification de la copie c de la variable i dans
la méthode add n’a pas de répercussion sur la valeur de la variable i. La variable c est donc bien une variable
différente de la variable i. Cette variable a été initialisée avec la valeur de la variable i lors de l’appel.
Dans notre exemple les variables s et as font référence au même tableau. Ainsi, lorsque l’entrée 0 du
tableau est modifiée dans la méthode add en utilisant la variable as, l’entrée correspondante vue à travers
la variable s paraît modifiée de manière identique.
192
'
$
Questions sur la syntaxe de base de Java
En Java un fichier source peut-il contenir des méthodes ?
Dans un bloc d’instructions (partie entre accolades) :
la ligne suivante est-elle acceptable en C et en Java ?
# 35
int a = 0, b = 1, c;
la ligne suivante est-elle acceptable en C et en Java ?
if ( a = b ) {
c = a;
}
L’accès à un élément de tableau est-il réalisé de manière identique en C et en Java ?
&
%
193
'
3.1 Classe
$
# 36
3.1
3.2
3.3
3.4
Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Attributs et méthodes de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Association entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
&
%
Cette section décrit la syntaxe du langage Java relative à la création des classes et à celle des objets.
Elle s’appuie sur la connaissance de base des notations UML relatives aux classes et aux objets.
'
$
3.1 Classe
Classe Personne en UML
# 37
&
%
Ce schéma décrit plusieurs notations possibles en UML de la classe Personne du cas d’étude Studs. La
partie gauche contient la description des attributs et des opérations. C’est ce schéma que nous traduisons en
Java dans la diapositive suivante.
194
'
3.1 Classe
$
3.1.1 Classe Personne en Java
1
package s t u d s ;
2
p u b l i c c l a s s Personne {
p r i v a t e S t r i n g nom , prenom ;
3
4
private int nbParticipations = 0 , nbOrganisations = 0;
5
p u b l i c Personne ( f i n a l
# 38
String n ,
final
7
}
8
public void voter ( f i n a l
9
public void c o n s u l t e r R e s u l t a t ( f i n a l
B u l l e t i n b ){
}
Scrutin s ) {
10
public void seRetirerDUnScrutin ( f i n a l
11
@Override
12
public String toString (){
Scrutin s ) {
}
}
r e t u r n " P e r s o n n e ␣ " + nom + " , ␣ "+ prenom +" , ␣ "+ n b O r g a n i s a t i o n s + " , ␣ " + n b P a r t i c i p a t i o n s ;
13
}
14
15
String p) {
nom = n ; prenom = p ;
6
}
&
%
Une description de classe commence par une ligne contenant le mot réservé class. Lorsque la classe est
publique, le fichier qui contient celle-ci doit porter un nom identique à la classe : dans notre cas, le fichier
doit s’appeler Personne.java.
Nous décrivons plus précisément ce qu’est un paquetage qui correspond à la première ligne contenant le
mot réservé package dans la section 5.6. De même, nous présentons les possibilités associées à la visibilité
par l’utilisation des mots réservés public et private dans la section 5.7.
De manière traditionnelle, une classe commence par la description des attributs. Comme nous l’avons vu
en UML, les attributs peuvent être spécifiques à chaque objet. Ce sont des attributs d’instance. Ils peuvent
aussi être partagés entre tous les objets de la classe. Ce sont des attributs de classe. Nous détaillons ces
points à partir de la section 3.3.
Les attributs peuvent correspondre à des types primitifs ou non. Dans notre cas, la variable
nbParticipations est du type primitif int. La variable nom est une référence sur un objet de la classe
java.lang.String, que nous approfondirons dans le chapitre 6.
Les attributs d’instance sont le plus souvent initialisés par une méthode appelée constructeur et qui porte
le même nom que la classe. Nous en reparlons de manière approfondie dans la section 3.2.1.
Une classe définit les comportements de ses objets à travers des méthodes d’instance. Une méthode
d’instance réalise une opération s’appliquant sur les attributs d’un objet. C’est le cas dans notre exemple
des méthodes : voter, consulterResultat, et seRetirerDUnScrutin.
195
'
3.1 Classe
$
3.1.2 Instance de classe en UML
# 39
&
%
Cette figure représente en UML une instance de la classe Personne. Elle précise les valeurs des attributs.
Elle donne aussi la possibilité de nommer l’objet.
'
$
3.1.3 Instance de classe en Java
1
import studs . Personne ;
2
class InitPersonne {
3
# 40
String [ ]
args ) {
4
Personne j ;
// r e f e r e n c e
5
j = new P e r s o n n e ( " Dupont " , " J u l i e n " ) ;
// i n s t a n c e c r e a t i o n
6
System . o u t . p r i n t l n ( j ) ;
}
7
8
}
studs.Personne@f62373
&
%
Cet exemple montre la création d’un objet de la classe Personne. La première ligne du fichier contient
une directive import qui permet de nommer plus facilement la classe Personne. Nous approfondissons les
explications sur import dans la section 5.
Ce code est contenu dans une classe appelée InitPersonne. Cette classe est dotée d’une méthode publique, statique appelée main et recevant comme argument un tableau de chaînes de caractères. Elle peut
servir de point d’entrée à l’exécution du programme.
La ligne 4 définit une variable locale appelée j qui permet de référencer un objet de la classe Personne.
L’instance est créée à la ligne 5 par l’appel du mot réservé new suivi d’un appel au constructeur de la
classe Personne.
196
3.2 Objet
L’instance est ensuite manipulée à partir de la référence j comme dans l’appel de la méthode println,
ligne 6.
'
$
3.2 Objet
# 41
Création d’un objet
Disposer d’une référence : Personne p;
Créer l’objet : new + appel à un constructeur
I p = new Personne("Dupont", "Julien");
&
%
Pour manipuler un objet, il est nécessaire de disposer d’une référence qui correspond à la classe de l’objet.
Il faut ensuite créer un objet. Pour ceci, le mot réservé new est suivi d’un appel à l’un des constructeurs de
la classe de l’objet. C’est à cet endroit que les paramètres qui servent à initialiser les attributs sont fournis.
Une fois créé, l’objet n’est jamais manipulé directement mais toujours à travers une référence.
$
'
3.2.1 Constructeurs en Java
Méthode particulière :
Nom identique à la classe
Aucun type de retour
# 42
Appelé directement à travers new
Si aucun constructeur n’est spécifié, le compilateur en fabrique un par défaut qui
initialise les attributs à 0 (correspondant à leur type)
La surcharge des méthodes (overloading) permet à une classe d’avoir plusieurs
constructeurs qui diffèrent par le nombre et le type de leurs arguments
&
%
Les constructeurs sont des méthodes particulières. Ils portent le même nom que la classe. Ils ne peuvent
pas être appelés par un appel de méthode classique. De l’extérieur de la classe, ils sont appelés en utilisant
le mot réservé new.
Les constructeurs n’ont pas de type de retour.
197
3.2 Objet
Comme nous l’avons déjà dit dans le transparent 2.4, le langage Java permet d’avoir plusieurs méthodes
portant le même nom dans une classe à la condition que ces méthodes puissent être distinguées à l’aide de leurs
paramètres. Cette propriété s’applique aux constructeurs. Ainsi, nous pouvons avoir plusieurs constructeurs
avec des listes de paramètres différentes.
De l’intérieur de la classe, les constructeurs peuvent s’appeler directement.
'
$
3.2.2 Exemples de constructeurs
1
package s t u d s c t r s ;
2
import studs . B u l l e t i n ;
3
import studs . S c r u t i n ;
4
5
6
7
final
String p) {
final
String p ,
}
9
# 43
String n ,
8
10
11
final
String n ,
i n t nbp ,
final
i n t nbo ) {
12
n b P a r t i c i p a t i o n s = nbp ; n b O r g a n i s a t i o n s = nbo ;
13
14
}
15
16
public void c o n s u l t e r R e s u l t a t ( f i n a l
17
public void seRetirerDUnScrutin ( f i n a l
18
Bulletin b) {
}
Scrutin s ) {
Scrutin s ) {
}
}
}
&
%
Cette classe contient deux constructeurs. Le premier initialise les attributs nom et prenom et laisse les
attributs nbParticipations et nbOrganisations aux valeurs par défaut 0.
Le second constructeur initialise les attributs nom et prenom, puis initialise les attributs
nbParticipations et nbOrganisations avec les arguments correspondants.
'
$
3.2.3 this
this permet de référencer l’instance courante ;
# 44
Est associé au concept d’auto-référence de l’objet
this permet de décrire un attribut ou une méthode de l’instance courante sans
ambiguïté
this(...) en tant que méthode fait appel à un constructeur
&
%
198
'
3.2 Objet
$
3.2.4 Exemples d’utilisation de this
1
package s t u d s t h i s ;
2
3
import studs . S c r u t i n ;
4
5
6
7
8
# 45
S t r i n g nom ,
final
S t r i n g prenom ) {
t h i s . nom = nom ; t h i s . prenom = prenom ;
9
10
}
11
12
final
i n t nbp ,
String n ,
final
final
String p ,
i n t nbo ) {
13
this (n , p ) ;
14
n b P a r t i c i p a t i o n s = nbp ; n b O r g a n i s a t i o n s = nbo ;
15
}
16
void voter ( f i n a l
17
void c o n s u l t e r R e s u l t a t ( f i n a l
18
void seRetirerDUnScrutin ( f i n a l
19
B u l l e t i n b ){
}
Scrutin s ) {
Scrutin s ) {
}
}
}
&
%
L’utilisation de this à la ligne 10 de cette diapositive permet de distinguer l’attribut de l’objet courant
this.nom, du paramètre nom du constructeur. Cette pratique est courante car les programmeurs utilisent
souvent le même nom pour l’attribut et pour le paramètre qui permet de l’initialiser.
Quant à la ligne 12 this(n,p), elle correspond à l’appel du constructeur de la ligne 6. Cette pratique
est courante afin de factoriser le code.
$
'
3.2.5 Destruction des objets
Pas de technique particulière pour détruire un objet
Objet détruit lorsqu’il n’est plus référencé
Utilisation d’un ramasse miettes
# 46
Le Garbage Collector détruit les objets non référencés
La destruction est asynchrone
Il n’y a pas de garantie sur la destruction (le programme peut se terminer avant que
l’objet ne soit détruit)
Si la classe décrit une méthode appelée finalize, cette méthode est appelée avant
la libération de la mémoire de l’objet
&
%
Comme nous l’avons dit dans l’introduction, le langage Java a été pensé pour pallier les principales
difficultés du langage C++ et en particulier, les erreurs associées à la gestion des références vers les objets. Il
est en effet difficile de garantir qu’un objet est désalloué lorsqu’il n’est plus utilisé.
Les langages modernes et Java en particulier prennent à leur charge la gestion des allocations et des
libérations de la mémoire en tenant à jour la liste des références vers les blocs alloués. Pour Java, c’est
la machine virtuelle Java qui réalise ces opérations et qui met en œuvre un ramasse miettes pour vérifier
199
3.2 Objet
périodiquement que les objets alloués sont toujours référencés.
Lorsque les objets ne sont plus référencés, le ramasse miettes récupère l’espace mémoire qu’ils occupent.
Puis, il met cet espace mémoire à la disposition de la création de nouveaux objets.
Ce ramasse miettes fonctionne de manière périodique et asynchrone à l’intérieur d’un fil d’exécution séparé
de la JVM. Il n’y a pas de garantie qu’un objet soit détruit. Il est possible de déclencher le fonctionnement
du ramasse miettes par l’appel à la méthode de classeSystem.gc().
$
'
3.2.6 Abstraction et encapsulation
Une classe correspond aux concepts d’abstraction et d’encapsulation
C’est une abstraction car elle présente une interface (ensemble de méthodes) qui
permettent d’interagir avec les objets
# 47
Une classe encapsule des données (ensemble d’attributs)
Pour garantir sa robustesse et son indépendance du reste du code, une classe doit
masquer son implantation
En particulier, elle ne doit pas permettre la modification de ses attributs sans
contrôle
&
%
Une classe correspond aux concepts d’abstraction et d’encapsulation. C’est une abstraction car elle présente une interface qui permet d’utiliser les objets de cette classe. Cette interface est constituée par un
ensemble de méthodes. Une classe encapsule des données qui sont un ensemble d’attributs. Pour garantir
sa robustesse et son indépendance du reste du code, une classe doit masquer sa réalisation, appelée aussi
implantation.
Une classe doit permettre l’utilisation de son interface mais protéger ses attributs des modifications.
L’accès direct aux attributs d’une classe viole le concept d’information encapsulée dans la classe.
Pour prendre un exemple de la vie courante, lorsqu’une montre affiche une heure, nous voyons cet affichage
selon la technologie qui est apportée par l’interface (aiguilles, cristaux liquides, diodes lumineuses). Cette
interface ne nous laisse pas deviner si la montre est à pile, à quartz, à mouvement mécanique ou autre. De
plus, nous ne pouvons pas intervenir directement sur l’endroit qui stocke l’information permettant d’afficher
l’heure. Nous ne pouvons qu’accéder à des boutons qui permettent de modifier cette information.
200
'
3.3 Attributs et méthodes de classe
$
3.2.7 Visibilité des méthodes
Les méthodes publiques (public) d’une classe définissent son interface publique
# 48
Les méthodes privées (private), ne sont accessibles que depuis l’intérieur de la
classe
Les méthodes protégées (protected), sont accessibles depuis l’intérieur de la classe
et de l’intérieur de ses classes dérivées
&
%
Comme nous le reverrons dans la partie 5.7, les mots réservés public, private et protected peuvent
être utilisés sur les méthodes pour permettre leur utilisation de l’extérieur ou uniquement de l’intérieur de
la classe.
$
'
# 49
&
%
Ce schéma montre une classe qui contient des attributs et des opérations soulignés. Ces attributs et
opérations sont partagés par l’ensemble des membres d’une classe. Ils sont appelés attributs ou méthodes
de classes alors que les attributs et méthodes qui ne sont pas soulignés sont appelés attributs ou méthodes
d’instance.
201
'
$
1
2
3
4
5
6
7
8
9
# 50
10
11
12
13
14
15
16
17
18
19
20
21
22
package s t u d s s t a t ;
private int nbParticipations = 0 , nbOrganisations = 0 ;
private static int nbTotalParticipations = 0;
p u b l i c P e r s o n n e ( f i n a l S t r i n g nom , f i n a l S t r i n g prenom ) {
}
p u b l i c P e r s o n n e ( f i n a l S t r i n g nom , f i n a l S t r i n g prenom ,
f i n a l i n t nbp , f i n a l i n t nbo ) {
t h i s ( nom , prenom ) ;
n b P a r t i c i p a t i o n s = nbp ;
n b T o t a l P a r t i c i p a t i o n s += nbp ;
n b O r g a n i s a t i o n s = nbo ;
}
public static int getNbTotalParticipations () {
return nbTotalParticipations ;
}
public String toString () {
r e t u r n nom + " ␣ " + prenom + " ␣ nbp ␣ " + n b P a r t i c i p a t i o n s
+ " ␣ nbo ␣ " + n b O r g a n i s a t i o n s + " ␣ n b t ␣ "
+ nbTotalParticipations ;
&
%
'
$
}
23
24
}
1
import s t u d s s t a t . Personne ;
2
public class TestStaticPersonne {
3
args ) {
5
P e r s o n n e m = new P e r s o n n e ( " M a r t i n " , " M a r i e " , 5 , 1 ) ;
6
System . o u t . p r i n t l n ( j ) ;
System . o u t . p r i n t l n (m) ;
7
# 51
String [ ]
P e r s o n n e j = new P e r s o n n e ( " Dupont " , " J u l i e n " , 7 , 3 ) ;
4
}
8
9
}
Affichage :
Dupont Julien nbp 7 nbo 3 nbt 12
Martin Marie nbp 5 nbo 1 nbt 12
&
%
La traduction du schéma UML est donnée dans le code ci-dessus. Le mot réservé static permet de décrire
les attributs ou méthodes de classe. Ces attributs ou méthodes sont partagés par l’ensemble des instances de
la classe. Lorsque la visibilité qui leur est associée le permet, ils peuvent aussi être accédés directement en
utilisant le nom de la classe suivi d’un point et du nom de l’attribut ou de la méthode. La classe Personne
définit une méthode toString qui permet d’obtenir la représentation en chaîne de caractères d’un objet.
Nous étudierons avec plus de précision cette méthode dans la partie 6.2. Il est cependant nécessaire de
comprendre que l’appel à la méthode System.out.println associée à un objet, fait appel à la méthode
toString() de l’objet et affiche la chaîne de caractères ainsi produite.
L’affichage montre ainsi que le nombre total de participations est identique dans les deux objets.
202
'
3.4 Association entre classes
$
3.3.2 Attributs et méthodes de classe
Les attributs statiques sont partagés par toutes les instances de la classe
Les méthodes statiques ne peuvent accéder qu’aux attributs statiques
Il n’est pas nécessaire d’instancier la classe pour accéder à ses membres statiques
# 52
Les instances peuvent accéder aux attributs statiques
Les instances peuvent invoquer les méthodes statiques
Les méthodes statiques ne sont jamais associées à l’auto référence de l’objet (this)
Quelques exemples avec la classe java.lang.math :
pi = Math.PI;
// static attribute ’PI’
b = Math.sqrt(2.0);// method call of static ’sqrt’
&
%
La classe java.lang.Math est un bon exemple de l’usage qui peut être fait des attributs et des méthodes
de classe. Cette classe rassemble les constantes et les méthodes mathématiques les plus utilisées qui se
trouvent rassemblées en langage C dans le fichier d’en-têtes /usr/include/math.h et dans le fichier archive
/lib/libm.so.
Les exemples donnés correspondent à l’utilisation de la variable PI et de la fonction racine carrée.
$
'
# 53
&
%
L’extrait de diagramme de classes montre une association entre les classes Personne et Scrutin. Cette
association matérialise le fait qu’un participant peut organiser un ou plusieurs scrutins. L’association est
bidirectionnelle. Elle matérialise le fait qu’un scrutin est organisé par un participant et un seul.
L’instanciation de ce diagramme de classe donne le diagramme d’objets en dessous sur le schéma. Dans ce
diagramme d’objets, l’objet référencé par m de la classe Personne organise le scrutin référencé par listeBDE.
203
'
$
3.4.1 Exemple d’association
1
2
3
4
5
6
7
8
9
# 54
10
11
12
13
14
15
16
17
18
19
20
1
package s t u d s o r g ;
private Scrutin [ ] scrutinsOrganises ;
s c r u t i n s O r g a n i s e s = new S c r u t i n [ 1 0 ] ;
}
p u b l i c S c r u t i n o r g a n i s e r S c r u t i n ( f i n a l S t r i n g nom ) {
S c r u t i n s = new S c r u t i n ( nom ) ;
scrutinsOrganises [ nbOrganisations ] = s ;
n b O r g a n i s a t i o n s ++;
return s ;
}
r e t u r n g e t C l a s s ( ) . getName ( ) + " ␣ "+nom+" ␣ "+prenom+" ␣ nbp ␣ "
+ n b P a r t i c i p a t i o n s + " ␣ nbo ␣ " + n b O r g a n i s a t i o n s ;
}
}
package s t u d s o r g ;
&
%
'
$
2
public class Scrutin {
3
p r i v a t e S t r i n g nomScrutin ;
4
public Scrutin ( final
S t r i n g nom ) {
n o m S c r u t i n = nom ;
5
6
}
7
/∗ @see j a v a . l a n g . O b j e c t#t o S t r i n g ( )
8
@Override
9
∗/
r e t u r n " S c r u t i n ␣ [ n o m S c r u t i n=" + n o m S c r u t i n + " ] " ;
10
}
11
12
# 55
13
}
1
import s t u d s o r g . ∗ ;
2
public class
InitScrutin {
3
String [ ]
args ) {
4
Personne p ;
// r e f e r e n c e
5
p = new P e r s o n n e ( " Dupont " , " J u l i e n " ) ;
// i n s t a n c e c r e a t i o n
6
S c r u t i n bde = p . o r g a n i s e r S c r u t i n ( " E l e c t i o n ␣ bde ␣ 2010 " ) ;
7
System . o u t . p r i n t l n ( bde ) ;
}
8
9
}
&
%
Pour modéliser la relation avec les scrutins organisés, nous ajoutons à la classe Personne un tableau de
références vers des objets de la classe Scrutin. Le nombre d’entrées valides dans le tableau, est contenu dans
la variable nborganisations.
La taille du tableau est initialisée à 10 dans le constructeur à la ligne 8 de la classe Personne.
Les éléments du tableau sont affectés lorsque le participant organise un nouveau scrutin.
C’est la méthode organiserScrutin qui doit créer l’objet de type Scrutin. Pour que cet objet puisse initialiser
la relation dans le sens inverse, il doit recevoir la référence sur l’objet qui a fait appel à cette méthode. C’est
le rôle du second paramètre du constructeur.
Dans la classe Scrutin, le constructeur reçoit en argument la référence vers l’organisateur du scrutin et
la mémorise dans l’attribut organisateur à la ligne 8.
La classe InitScrutin montre un exemple d’utilisation des deux classes.
204
'
$
3.4.2 Association entre classes en Java
Mise en place à l’aide d’attributs
Dans l’une ou l’autre des classes selon la navigabilité de l’association
# 56
Mise en place au moment de la construction des instances
Multiplicité de l’association représentée à l’aide d’un tableau ou d’une collection
Difficulté lorsque l’association est bidirectionnelle, par quoi commencer ?
Utilisation d’une méthode qui permet d’affecter un attribut d’une classe en
dehors du constructeur
Passage de la référence d’un des objets dans l’appel au constructeur de l’autre
&
%
La mise en place de l’association est le plus souvent réalisée par le constructeur de la classe qui doit
recevoir en paramètre la référence de l’objet de l’autre classe. Lorsque l’association est bidirectionnelle, il est
nécessaire de passer la référence d’un objet à l’autre et réciproquement. Ce type de constructeur est expliqué
dans la section 8.1.
$
'
Questions sur les classes et objet
Les attributs d’instance d’une classe servent-ils à représenter l’état des objets de la
classe ?
# 57
Les objets sont-ils créés par l’appel à un constructeur de la classe ?
Dans la section 3.3.1, est-il légal d’écrire :
ligne 12 this.nbParticipations au lieu de nbParticipations
ligne 17 this.nbTotalParticipations au lieu de nbTotalParticipations
&
%
205
'
$
# 58
4.1
4.2
4.3
4.5
4.5
4.6
4.7
Généralisation spécialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Polymorphisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Redéfinition de méthodes dans les classes dérivées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Héritage, membres et visibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Classes abstraites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Exemple de classe Abstraites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
&
%
Dans cette section, nous abordons la généralisation spécialisation en Java. Nous étudions les relations
entre les références et les objets lorsqu’une généralisation spécialisation existe entre les classes. Puis nous
abordons les possibilités liées à la généralisation spécialisation relativement à la gestion des attributs et à
leur visibilité. Enfin, nous décrivons la possibilité de modifier un comportement d’une classe dans une classe
spécialisée.
'
$
4.1 Généralisation spécialisation
# 59
&
%
Une classe concrétise un type de donnée abstrait et un comportement. Deux cas se présentent le plus
souvent :
1. besoin d’étendre une classe : le programmeur désire réaliser une nouvelle classe qui apporte de nouvelles
fonctionnalités tout en restant proche d’une classe existante. Plutôt que de copier/coller du code d’un
fichier à un autre, la nouvelle classe est spécialisée à partir de la classe initiale par un lien d’héritage.
La nouvelle classe est appelée classe dérivée à partir d’une classe de base ;
206
2. des classes développées séparément présentent des parties identiques dans leurs attributs et dans leurs
méthodes. Dans ce cas, les parties identiques sont factorisées dans une classe qui généralise les classes
existantes. Les classes spécialisées sont modifiées pour supprimer la partie commune et sont liées à la
classe de généralisation par un lien d’héritage.
Une classe D qui hérite d’une classe B, partage tous les membres de B. Une classe D qui hérite d’une classe B
peut étendre ou modifier les structures de données et le comportement hérité de la classe B.
'
$
4.1.1 Héritage : comment en Java
Une classe ne peut hériter que d’une autre classe (héritage simple)
Une classe hérite d’une autre par l’utilisation du mot réservé extends
# 60
Une classe pour laquelle aucune spécialisation n’est explicitée spécialise
implicitement la classe java.lang.Object
L’opérateur instanceof permet de tester si une référence correspond à un objet
d’une classe donnée
Le mot réservé final utilisé devant le mot clé class interdit toute spécialisation de
la classe sur laquelle il est utilisé
&
%
En Java, la spécialisation entre classes est simple. Une classe ne peut spécialiser qu’une autre classe.
Une classe en spécialise une autre par l’utilisation du mot réservé extends suivi du nom de la classe qu’elle
spécialise. Une classe, pour laquelle aucune spécialisation n’est explicitée, spécialise implicitement la classe
java.lang.Object. Comme nous le verrons dans la section 6.2, cette propriété garantit un comportement
de base à toutes les classes.
L’opérateur instanceof permet de tester si une référence correspond à un objet d’une classe. Il s’utilise avec une référence sur un objet et un nom de classe. Il retourne true si la référence décrit un objet
correspondant à la classe, et false sinon.
Le mot réservé final utilisé devant class interdit toute spécialisation de la classe sur lequel il est utilisé.
Cette propriété peut être utilisée afin de protéger des parties sensibles ou vitales du code.
207
'
$
4.1.2 Héritage et constructeur
Création d’un objet de classe dérivée =⇒ création de la partie de l’objet
correspondant à la classe parente
# 61
Appel dans le constructeur de la classe dérivée d’un des constructeurs de la classe
parente par utilisation du mot réservé super()
En première ligne du constructeur de la classe enfant
Si aucun appel =⇒ appel au constructeur sans argument de la classe parente
&
%
Comme nous l’avons dit, un objet d’une classe dérivée est un objet de la classe parente plus une partie
qui correspond à la classe dérivée. Il est donc nécessaire d’initialiser la partie provenant de la classe parente
lorsque l’objet est créé. Le constructeur de la classe dérivée doit donc faire appel au constructeur de la classe
parente pour réaliser cette initialisation. Le plus souvent un constructeur de classe dérivée reçoit un ensemble
de paramètres pour initialiser les attributs de la classe parente. Il utilise ces paramètres pour faire appel au
constructeur de la classe parente.
'
$
4.1.3 Exemple de classe parente et classe dérivée
# 62
1
package p e r s o n n e s ;
2
3
p r i v a t e S t r i n g nom , prenom , numSecu ;
4
String n ,
6
}
7
String p ,
final
S t r i n g ns ){
r e t u r n " P e r s o n n e : ␣ " + nom + " ␣ " + prenom + " ␣ " + numSecu ;
8
}
9
10
final
nom = n ; prenom = p ; numSecu = n s ;
5
}
&
%
208
'
1
package p e r s o n n e s ;
2
p u b l i c c l a s s Enseignant extends Personne {
3
p r i v a t e i n t nbCours ; p r i v a t e S t r i n g
4
public Enseignant ( f i n a l
final
5
i n t nbc ,
6
super ( n , p , ns ) ;
7
n b C o u r s = nbc ;
final
specialite ;
final
String
String p ,
final
S t r i n g ns ,
specialite ) {
}
9
10
r e t u r n " E n s e i g n a n t : ␣ " + nbCours + " ␣ " +s p e c i a l i t e ;
11
}
12
13
String n ,
this . specialite = specialite ;
8
# 63
$
}
&
%
La classe Personne est notre classe parente. Elle contient des attributs privés nom, prenom, et numSecu.
Ces attributs sont initialisés dans le constructeur.
Les autres méthodes de la classe ne sont pas décrites. Seule la méthode toString dont nous parlerons
dans la section 4.2 sur le polymorphisme est décrite.
La classe Enseignant est une spécialisation de la classe Personne. Elle contient des attributs privés :
nbCours et specialite. Ces attributs privés sont initialisés dans le constructeur. Le constructeur de la classe
Enseignant reçoit des paramètres pour initialiser ses attributs et des paramètres qu’il utilise pour faire appel
au constructeur de la classe Personne. Comme pour la classe parente, seule la méthode toString est réalisée.
$
'
4.1.4 Utilisation de classe parente et dérivée
1
import personnes . ∗ ;
2
public class InheritExample {
3
args ) {
" 1831291... " );
5
# 64
String [ ]
P e r s o n n e p = new P e r s o n n e ( " Dupont " , " J u l i e n " ,
4
E n s e i g n a n t e = new E n s e i g n a n t ( " Durand " , " E m i l i e " ,
6
" 2 7 8 0 6 3 3 . . . " , 3 , " C l o u d ␣ Computing " ) ;
7
System . o u t . p r i n t l n ( " p␣ e s t ␣ une ␣ P e r s o n n e ␣ "
8
+ ( p i n s t a n c e o f Personne ) ) ;
9
System . o u t . p r i n t l n ( " p␣ e s t ␣ un ␣ E n s e i g n a n t ␣ "
10
+ (p instanceof Enseignant ) ) ;
11
12
System . o u t . p r i n t l n ( " e ␣ e s t ␣ une ␣ P e r s o n n e ␣ "
13
+ ( e i n s t a n c e o f Personne ) ) ;
14
System . o u t . p r i n t l n ( " e ␣ e s t ␣ un ␣ E n s e i g n a n t ␣ "
15
+ ( e instanceof Enseignant ) ) ;
16
}
17
18
}
&
%
209
'
p
p
e
e
est
est
est
est
une
une
une
une
$
Personne true
Enseignant false
Personne true
Enseignant true
# 65
&
%
Dans cet exemple, la classe Enseignant étend la classe Personne. Le constructeur de la classe Enseignant
fait appel au constructeur de la classe Personne à la ligne 6 par l’utilisation du mot réservé super. Le
résultat de l’exécution permet de vérifier qu’un objet de la classe Enseignant est bien une instance de la
classe Personne.
'
$
4.2 Polymorphisme
Affectation de références dans un arbre d’héritage
Upcast : une référence d’une classe B peut référencer toute instance de la classe B
ou de ses classes dérivées
# 66
Downcast : une référence d’une classe D dérivée d’une classe B peut recevoir une
référence de la classe B si et seulement si :
L’objet référencé est bien du type D ou d’un de ses types dérivés
Le changement de type doit être explicite (en anglais, cast) vers le nouveau type
(D)
&
%
Le polymorphisme revêt plusieurs aspects en matière de programmation. Nous prendrons la définition
de [Armstrong, 2006] : « Different classes may respond to the same message and each implement it appropriately ». L’opérateur + permet une approche simple de cette propriété. En effet, le même opérateur peut
être utilisé avec des types différents (entier ou en virgule flottante). La réalisation de 1 + 2 n’est pas la même
que celle de 1.0 + 2. Le symbole plus dénote l’addition mais ne s’adresse pas au même type de données.
La possibilité de généraliser ou spécialiser des classes donne une relation qui se traduit par un arbre
d’héritage. Le sommet de cet arbre correspond à la classe la plus générale et les feuilles représentent les
210
4.2 Polymorphisme
classes les plus spécialisées.
La possibilité de mettre la référence d’un objet d’une classe dérivée une référence de la classe parente est
un aspect objet du polymorphisme. Cette opération est appelée Upcast car l’arbre d’héritage est parcouru
du bas vers le haut.
Réciproquement, lorsqu’une référence d’un objet d’une classe dérivée a été mise dans une variable pouvant
recevoir une référence sur un objet de la classe de base, nous pouvons mettre cette référence dans une variable
qui peut contenir une référence sur un objet de la classe dérivée. Cette opération est appelée Downcast car
l’arbre d’héritage est parcouru du haut vers le bas.
'
$
4.2.1 Exemple de Upcast et Downcast
1
2
3
4
5
6
7
8
9
# 67
10
11
12
13
14
15
16
17
18
19
import personnes . Personne ;
import personnes . Enseignant ;
p u b l i c c l a s s UpDownExample {
p u b l i c s t a t i c v o i d main ( f i n a l S t r i n g [ ] a r g s ) {
Personne p ;
" 2 7 8 0 6 3 3 . . . " , 3 , " C l o u d ␣ Computing " ) ;
p = e;
// UpCast
System . o u t . p r i n t l n ( " A p r e s ␣p␣=␣ e ; ␣p␣ e s t ␣ une ␣ P e r s o n n e ␣ "
+ ( p i n s t a n c e o f Personne )
+ " ; ␣p␣ e s t ␣ un ␣ E n s e i g n a n t ␣ "
+ (p instanceof Enseignant ) ) ;
e = ( E n s e i g n a n t ) p ; // Downcast
System . o u t . p r i n t l n ( " A p r e s ␣ e ␣=␣p ; ␣ e ␣ e s t ␣ une ␣ P e r s o n n e ␣ "
+ ( e i n s t a n c e o f Personne )
+ " ; ␣ e ␣ e s t ␣ un ␣ E n s e i g n a n t ␣ "
+ ( e instanceof Enseignant ) ) ;
}
}
Apres p = e;
Apres p = e;
&
'
Apres e=p; e
Apres e=p; e
p est une Personne true
p est un Enseignant true
%
$
est une Personne true
est un Enseignant true
# 68
&
%
Dans cet exemple, la variable p de type référence de classe parente peut recevoir la référence d’un objet
de classe dérivée, contenue dans e. Inversement, une fois qu’une référence de classe parente contient une
référence vers un objet de la classe dérivée, il est possible de mettre cette valeur dans une variable pouvant
211
4.3 Redéfinition de méthodes dans les classes dérivées
contenir une référence de la classe parente. Il faut cependant informer le compilateur de cette possible perte
de sens en castant la référence.
'
$
4.3 Redéfinition de méthodes dans les classes dérivées
Redéfinition possible des méthodes publiques héritées (en anglais overriding)
Peut être annotée par @Override.
# 69
Liaison dynamique :
Redéfinition la plus proche dans l’arbre d’héritage invoquée
Même à travers une référence d’une classe parente
Accès explicite à une méthode redéfinie de la classe parente par super
&
%
Une classe peut redéfinir les méthodes publiques dont elle hérite (en anglais overriding). Dans ce cas la
méthode peut être annotée avec l’annotation @Override. Java réalise une liaison dynamique lors des appels
de méthodes, ainsi les objets des classes dérivées ont leur comportement propre même lorsqu’ils sont utilisés
à travers une référence de classe parente.
Lorsqu’il n’y a pas de définition dans la classe feuille, c’est la définition dans la classe la plus proche en
remontant dans l’arbre d’héritage qui est invoquée. Cette liaison dynamique est réalisée même lorsque l’on
utilise la méthode à travers une référence d’une classe parente. Depuis une classe dérivée, l’accès explicite
à une méthode redéfinie de la classe parente est possible en utilisant le mot réservé super. Ainsi dans nos
exemples précédents, la méthode toString() est redéfinie dans la classe dans la classe Enseignant.
$
'
1
import personnes . Personne ;
2
import personnes . Enseignant ;
3
p u b l i c c l a s s TestPolyMorph {
4
7
" 2 7 8 0 6 3 3 . . . " , 3 , " C l o u d ␣ Computing " ) ;
8
System . o u t . p r i n t l n ( p . t o S t r i n g ( ) ) ;
9
10
System . o u t . p r i n t l n ( e . t o S t r i n g ( ) ) ;
11
p = e;
12
System . o u t . p r i n t l n ( p . t o S t r i n g ( ) ) ;
// UpCast
}
13
14
args ) {
" 1831291... " );
6
# 70
String [ ]
P e r s o n n e p = new P e r s o n n e ( " Dupont " , " J u l i e n " ,
5
}
Personne: Dupont Julien
Enseignant: 3 Cloud Computing
Enseignant: 3 Cloud Computing
&
%
212
Cet exemple montre plusieurs aspects du polymorphisme et de la liaison dynamique :
1. à la ligne 11 : bien que définie dans la classe Personne, la méthode toString de la classe Enseignant
est utilisée lorsqu’on utilise une référence de la classe Enseignant. Cet aspect est appelé liaison tardive.
Java utilise la méthode qui correspond à la classe de l’objet. En fait elle utilise la méthode qui est définie
dans l’arbre d’héritage le plus près de la classe réelle de l’objet ;
2. à la ligne 12 : une référence de la classe dérivée peut être affectée à une variable correspondant à la
classe de base ;
3. à la ligne 13 : la liaison dynamique fait que l’appel de toString() fait appel à la méthode contenue
dans la classe dérivée, alors que l’appel est réalisé à travers une référence de la classe parente.
'
$
4.4 Héritage, membres et visibilité
Une classe D héritant d’une classe B hérite de tous ses membres :
# 71
Les membres private de B sont inaccessibles depuis D
Les membres protected de B sont accessibles depuis D
Les membres public sont accessibles depuis D comme depuis les autres classes
&
%
Une classe D spécialisant une classe B hérite de tous ses membres. Elle peut accéder directement aux
attributs et méthodes publics. Les langages objets ont introduit un lien privilégié entre les classes dérivées
et leur classe parente. Ce lien privilégié se traduit à travers le mot réservé protected qui permet aux classes
dérivées d’accéder à certaines parties non publiques de la classe parente. Bien que, en partie constitué des
attributs privés en provenance de la classe de base, un objet de classe dérivée ne peut accéder à ces attributs
que via les méthodes publiques ou protected de la classe parente.
213
'
4.5 Classes abstraites
$
Questions généralisation/spécialisation en Java
À quoi sert le mot réservé extends dans une déclaration de classe ?
# 72
À quoi sert le mot super ?
Peut-on interdire la redéfinition d’une méthode dans une classe dérivée ?
Peut-on interdire la généralisation/spécialisation d’une classe ?
&
%
$
'
4.5 Classes abstraites
En UML :
# 73
&
%
214
'
4.6 Exemple de classe Abstraites
$
4.5.1 Classes abstraites : principes
Classe qui ne peut pas être instanciée. Par exemple la classe Média de la diapositive
précédente
# 74
Spécialisation nécessaire jusqu’à obtenir des classes instanciables : par exemple, la
classe Livre dans la même diapositive
Impose un comportement commun à toutes les classes dérivées
Possibilité de créer des tableaux ou des collections de références de classe abstraite
&
%
Une classe abstraite décrit une classe qui ne peut pas être instanciée. En d’autre mots, il n’y a pas
d’objet de cette classe. Par exemple la classe Média de la diapositive précédente. Une classe abstraite doit
être spécialisée pour obtenir des classes instanciable. Dans l’exemple, la classe Livre est instanciable. La
classe abstraite impose un comportement commun à toutes les classes dérivées. Il est possible de créer des
tableaux ou des collections de références sur une classe abstraite. Bien entendu, cette collection contiendra
des références vers des objets des classes dérivées de la classe abstraite.
$
'
4.5.2 Classes abstraites en Java
Méthodes abstraites sans corps de méthode
# 75
Classe abstraite si méthode abstraite
Classe dérivée : définit toutes les méthodes ou reste abstraite
Classe qualifiée abstraite pour empêcher la création d’instances
&
%
Les méthodes peuvent être qualifiées abstraites et ne pas être associées à un corps de méthode. Une
classe ayant une méthode abstraite doit être qualifiée abstraite. Une classe qui étend une classe abstraite
reste abstraite tant qu’elle ne définit pas l’ensemble des méthodes abstraites imposé par sa classe parente.
Une classe peut être qualifiée abstraite même si toutes ses méthodes sont définies. Ceci empêche la création
d’objet de cette classe.
215
'
$
# 76
&
%
'
$
4.6.1 Exemple : classes abstraites
1
2
3
4
5
6
7
8
9
# 77
10
11
12
13
14
15
16
17
18
19
20
21
22
package s t u d s a b s t r a c t ;
p u b l i c a b s t r a c t c l a s s Choix {
private Bulletin [ ] lesBulletins ;
int nbBulletinsPour , nbBulletinsContre , indexBulletins ;
p u b l i c Choix ( ) {
l e s B u l l e t i n s = new B u l l e t i n [ 1 0 0 ] ;
indexBulletins = 0;
nbBulletinsPour = 0;
nbBulletinsContre = 0;
}
public int addBulletin ( Bulletin b) {
l e s B u l l e t i n s [ i n d e x B u l l e t i n s ++] = b ;
i f (b . getValue ()){
n b B u l l e t i n s P o u r++ ;
} else {
n b B u l l e t i n s C o n t r e++ ;
}
return indexBulletins ;
}
public int getNbBulletinsPour () {
return nbBulletinsPour ;
}
&
%
216
'
public int getNbBulletinsContre (){
return nbBulletinsContre ;
}
p u b l i c i n t chercherRang ( B u l l e t i n b ){
f o r ( i n t i = 0 ; i < i n d e x B u l l e t i n s ; i ++){
i f (b . equals ( l e s B u l l e t i n s [ i ] ) ) return i ;
}
r e t u r n −1;
}
public void r e t i r e r B u l l e t i n ( f i n a l B u l l e t i n r e t r a i t ) {
i n t rang = chercherRang ( r e t r a i t ) ;
i f ( r a n g > −1){
c o m p a c t e r B u l l e t i n s ( rang ) ;
}
}
p u b l i c void c o m p a c t e r B u l l e t i n s ( i n t r ){
f o r ( i n t i = r ; i < i n d e x B u l l e t i n s ; i ++){
l e s B u l l e t i n s [ i ] = l e s B u l l e t i n s [ i +1];
}
i n d e x B u l l e t i n s −−;
}
p u b l i c v o i d m o d i f i e r B u l l e t i n ( f i n a l B u l l e t i n changed ) {
i n t rang = chercherRang ( changed ) ;
i f ( r a n g >=0) {
23
24
25
26
27
28
29
30
31
32
33
# 78
$
34
35
36
37
38
39
40
41
42
43
44
45
46
&
'
$
B u l l e t i n aChanger = l e s B u l l e t i n s [ rang ] ;
i f ( a C h a n g e r . g e t V a l u e ( ) != c h a n g e d . g e t V a l u e ( ) ) {
aChanger . s e t V a l u e ( changed . g e t V a l u e ( ) ) ;
}
i f ( aChanger . ge tV al ue ( ) ) {
n b B u l l e t i n s C o n t r e −− ;
n b B u l l e t i n s P o u r ++;
} else {
n b B u l l e t i n s C o n t r e++ ;
n b B u l l e t i n s P o u r −−;
}
47
48
49
50
51
52
53
54
55
56
57
# 79
}
58
}
59
60
1
2
3
4
5
6
7
8
9
%
}
package s t u d s a b s t r a c t ;
p u b l i c c l a s s Studs {
p r i v a t e Choix [ ] l e s C h o i x ;
private Scrutin [ ] lesScrutins ;
private Bulletin [ ] lesBulletins ;
p r i v a t e Personne [ ] l e s P a r t i c i p a n t s ;
p u b l i c Studs () {
l e s C h o i x = new C h o i x [ 1 0 0 ] ;
l e s S c r u t i n s = new S c r u t i n [ 1 0 0 ] ;
&
%
217
'
# 80
4.7 Interfaces
$
10
l e s B u l l e t i n s = new B u l l e t i n [ 1 0 0 ] ;
11
l e s P a r t i c i p a n t s = new P e r s o n n e [ 1 0 0 ] ;
12
}
13
@Override
14
return " Studs ␣" + l e s C h o i x + l e s S c r u t i n s + l e s B u l l e t i n s + l e s P a r t i c i p a n t s
15
17
;
}
16
}
&
%
Dans cet exemple, nous avons la classe abstraite Choix, qui est rendue instanciable dans la classe
PlageHoraire. Les collections dans la classe Studs référencent des objets abstraits Scrutin et Choix. Les
objets référencés seront bien entendu instanciés. Ce sont des objets des classes PlageHoraire ou Preference
dans la collection des Choix.
$
'
4.7 Interfaces
UML :
# 81
&
%
Les interfaces servent à noter des comportements qui doivent être réalisés par les classes qui réalisent
cette interface. Vous pouvez considérer une interface comme une classe sans attribut et avec uniquement des
méthodes abstraites.
218
'
4.7 Interfaces
$
4.7.1 Interfaces en Java
Les membres d’une interface sont principalement des méthodes abstraites
# 82
Une interface est déclarée avec le mot réservé interface
Une interface peut hériter (extends) de plusieurs interfaces
Une classe peut implémenter (implements) une ou plusieurs interfaces
Rappel : une classe n’hérite (extends) que d’une seule classe
&
%
Une interface est une classe dont les membres sont principalement des méthodes abstraites. Une interface
est déclarée avec le mot réservé interface. Une interface peut hériter (extends) de plusieurs interfaces. Une
classe peut implémenter (implements) une ou plusieurs interfaces.
219
'
$
# 83
5.2
5.2
5.3
5.5
5.5
5.6
5.7
Programme en C (rappel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Exécution d’un programme (rappel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Exécution d’un programme sur une machine virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Dans le cas de Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Unités de compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Visibilité en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
&
%
Ce chapitre traite de l’organisation des fichiers sources et de leurs contreparties compilées en bytecode.
Cette organisation est fortement liée à l’infrastructure des compilateurs Java et des machines virtuelles Java.
'
$
5.1 Programme en C (rappel)
# 84
&
%
Nous prenons ici l’exemple d’un programme en langage C, mais cet exemple peut être généralisé à
l’ensemble des programmes issus de langages compilés et obtenus avec une phase d’édition de liens.
La figure exprime qu’un programme compilé est un ensemble de modules qui se compilent de manière
individuelle et qui sont construits pour être réunis entre eux mais aussi avec des fonctions provenant de
bibliothèques. Sur la figure, nous montrons trois fichiers sources qui donnent trois fichiers objets relogeables.
Ces trois fichiers objets sont associés entre eux et complétés par les fonctions provenant d’une bibliothèque.
Cette bibliothèque peut-être associée statiquement ou dynamiquement.
220
'
$
5.2 Exécution d’un programme (rappel)
# 85
&
%
Nous continuons notre exemple en montrant le programme en cours d’exécution appelé processus. Notre
schéma focalise sur les zones mémoires associées au programme et au système d’exploitation. Parmi ces zones,
vous pouvez voir la partie texte qui contient les instructions exécutables, la partie données, la pile qui permet
de réaliser les appels de fonctions et le tas qui permet la gestion dynamique de la mémoire. Le schéma montre
aussi la bibliothèque du langage C liée dynamiquement au programmes. La présence du processeur en dessous
du processus et du système montre que le processus exécute directement les instructions contenues dans la
zone texte de la mémoire sur le processeur. Pour mémoire, un processus saute dans le système d’exploitation
pour réaliser des opérations privilégiées et contrôlées par le système d’exploitation comme les entrées sorties.
'
$
# 86
&
%
Pour ce qui est de l’exécution d’un programme par une machine virtuelle java, le programme est constitué
d’un ensemble de modules qui se trouvent dans des fichiers. Les modules sont compilés dans un langage
intermédiaire qui est compris par la machine virtuelle. Aucun code correspondant à la machine physique
221
n’est généré. Les modules sont chargés dans la mémoire de la machine virtuelle qui les interprète et exécute
les opérations que les modules décrivent.
'
$
5.4 Dans le cas de Java
# 87
Point d’entrée public static void main(String args[]) dans une classe
Classes chargées à la demande (en anglais dynamic loading)
&
%
Les caractéristiques de la machine virtuelle Java font qu’il n’existe pas d’équivalent au programme en
binaire exécutable obtenu dans une chaîne de compilation classique et en particulier en langage C. En effet,
pour qu’un programme Java soit exécutable, il suffit d’un point d’entrée et d’un ensemble de classes. Le point
d’entrée est matérialisé par la méthode main au prototype ci-dessus. Cette méthode constitue les instructions
de départ du programme. La machine virtuelle charge dynamiquement les classes qui sont référencées à partir
de cette méthode. Le chargement des classes de l’API ne différe pas de celui des autres classes.
$
'
5.5 Unités de compilation
# 88
Un fichier source Java = une unité de compilation
Recommandation : une seule classe par fichier source
Obligation : nom du fichier source = nom de sa classe publique
&
%
Un fichier source en Java correspond à une unité de compilation. Une unité de compilation n’est compilable que si le compilateur dispose de l’ensemble des classes utilisées dans ce fichier. Ceci peut conduire un
222
compilateur à compiler plusieurs classes lors d’une demande de compilation d’une seule classe. Il est fortement recommandé d’avoir une seule classe par fichier source. Un fichier source contenant une classe publique
doit porter le même nom que cette classe.
'
$
5.6 Paquetages
Paquetages : regroupement de classes dans un espace de nommage
Noms des classes : « packagename.classname »
# 89
Espace de nommage associé à la compilation et à l’exécution
Classe Personne du paquetage studs doit être dans un fichier correspondant au
chemin « studs/Personne.java »
Ceci permet au compilateur et à la JVM de trouver les fichiers compilés
Mot réservé package : nom de paquetage des classes dans l’unité de compilation
&
%
Les paquetages permettent de regrouper un ensemble de classes dans un espace de nommage. Les noms des
classes suivent le schéma « packagename.classname ». Cet espace de nommage est associé à la compilation
et à l’exécution. La classe Personne du paquetage studs doit être dans un fichier correspondant au chemin
« studs/Personne.java ». Ceci permet au compilateur et à la JVM de trouver les fichiers compilés. Le mot
réservé package permet d’indiquer le nom de paquetage pour chaque unité de compilation.
223
'
$
5.6.1 Chemin de recherche
# 90
variable d’environnement CLASSPATH liste des répertoires de recherche pour le
compilateur et la JVM
Noms des classes complets contient le nom de paquetage
import : permet d’établir un alias
API Java est organisée en paquetages (java.lang, java.io...)
&
%
Les répertoires dans lesquels le compilateur et la JVM cherchent les paquetages sont décrits dans une
variable d’environnement appelée CLASSPATH. À l’extérieur d’un paquetage, les noms des classes sont composé
du nom de paquetage, d’un point et du nom de la classe. Un nom de paquetage peut être composé de plusieurs
parties séparées elles aussi par des points. L’instruction import permet d’utiliser le nom de la classe importée
sans le nom du paquetage en préfixe. L’API Java est organisée en paquetages (java.lang, java.io...).
$
'
5.6.2 Exemple
CLASSPATH : CLASSPATH=/src:/java
Fichier /java/studs/Personne.java contient le code suivant :
package studs;
public class Personne {
private String nom, prenom;
private int nbParticipations = 0, nbOrganisations = 0;
public Personne(String n, String p){
n = nom; prenom = p;
}
public void voter(Bulletin b){
}
public void consulterResultat(Scrutin s) {
public void seRetirerDUnScrutin(Scrutin s) {
# 91
}
}
}
Fichier InitPersonne.java dans le répertoire /src peut contenir le code suivant :
import studs.Personne;
class InitPersonne {
public static void main(String[] args) {
Personne j;
j = new Personne("Dupont", "Julien");
System.out.println(j);
}
}
// reference
// instance creation
&
%
Pour compiler le fichier InitPersonne.java, le compilateur recherche le fichier source Personne.java
du paquetage studs à partir des chemins décrits dans le CLASSPATH. Il commence, donc, par chercher le sous
répertoire studs dans le répertoire /src. Il ne trouve pas ce sous répertoire et passe au chemin suivant. Il
cherche dans /java et trouve un répertoire studs. Dans ce répertoire il trouve le fichier class Personne.class
ou il compile le fichier Personne.java pour obtenir le fichier .class. Avec ce fichier .class, il est à même
de compiler le fichier InitPersonne.java.
224
'
5.7 Visibilité en Java
$
5.7 Visibilité en Java
Un membre de la classe C peut être :
# 92
private : accessible seulement à la classe
package friendly (défaut) : accessible aux classes dans le même paquetage
protected : accessible aux classed du paquetage et à toute classe dérivée en
dehors du paquetage
public : accessible à toutes les classes
&
%
Un membre de la classe C peut être :
• private : accessible seulement à la classe ;
• package friendly : valeur par défaut, accessible aux classes dans le même paquetage ;
• protected : accessible aux classes dans le même paquetage et à toute classe dérivée en dehors du
paquetage ;
• public : accessible à toutes les classes.
'
$
5.7.1 Table de visibilité
# 93
a
b
c
d
Accessible de C2
oui
oui
oui
-
Accessible de C3
oui
oui
oui
-
Accessible de C4
oui
oui
-
-
Accessible de C5
&
oui
-
-
%
La variable a est accessible à l’ensemble des classes car elle est publique.
225
La variable b est accessible à l’ensemble des classes dérivées de C1. Ce sont les classes C2 et C4. Elle est
aussi accessible aux classes du même paquetage, soit C2 et C3.
La variable c est accessible à l’ensemble des classes de son paquetage, soit C2 et C3.
La variable d n’est accessible que dans la classe C1.
'
$
Questions organisation des sources en Java
Le nom d’un paquetage est-il lié à l’organisation des fichiers sources ?
# 94
Dans quel paquetage se trouve java.lang.Object ?
Les paquetages servent-ils seulement à la compilation des classes ?
Les paquetages impactent-ils la visibilité des membres des classes ?
&
%
226
'
6 API Java
$
6 API Java
# 95
6.2
6.2
6.3
6.4
6.5
Premières classes de l’API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Classe java.lang.Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Interface de programmation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
java.lang.* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
java.util.*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
&
%
Dans cette section, nous traitons une partie importante de l’API java, en particulier certaines classes
associées au paquetage java.lang et une partie des collections associées au paquetage java.util.
'
$
6.1 Premières classes de l’API
# 96
java.lang.Object
java.lang.String
java.lang.Integer
&
%
Nous étudions plus particulièrement les classes ci-dessus dans la suite de cette section.
227
'
6 API Java
$
6.2 Classe java.lang.Object
public String toString()
protected Object clone() throws CloneNotSupportedException
# 97
public boolean equals(Object obj)
protected void finalize() throws Throwable
public final Class getClass()
public int hashCode()
&
%
Cette classe est fondamentale. Elle impose un ensemble de comportements pour tous les objets car elle
est la racine de l’arbre d’héritage. Elle garantit par exemple que les méthodes toString et equals peuvent
être appelées sur tous les objets. Parmi les méthodes de la classe Object, nous trouvons par fréquence
d’utilisation :
• public String toString()
Retourne une représentation sous forme de chaîne de caractères de cet objet (conversion). Toute classe
devrait redéfinir cette méthode. La chaîne retournée par la méthode toString() de la classe Object est
constituée du nom de la classe suivi de @ et du code de hachage hexadécimal de l’objet. Formellement,
l’instruction exécutée pour générer cette chaîne est :
getClass().getName() + ’@’ + Integer.toHexString(hashCode())
• public boolean equals(Object obj)
Comparaison de référence entre l’objet courant et l’objet passé en argument obj (voir la section 6.2.1
plus loin)
• protected Object clone() throws CloneNotSupportedException
Retourne une copie légère de cet objet (voir dans la section 8.1
• protected void finalize() throws Throwable
Appelée par le ramasse miettes lorsque le ramasse miettes récupère l’espace correspondant à l’objet.
L’objet n’est bien entendu plus associé à une référence.
• public final native Class getClass()
Retourne la classe de l’objet sous forme d’un objet de la classe java.lang.Class
• public native int hashCode()
Retourne un code de hachage pour cet objet. Ce code sert pour les tables de hachage que nous étudierons
dans la section 6.5.3 sur les collections. La définition d’une fonction de hachage telle que donnée
dans Wikipédia est la suivante : « On nomme fonction de hachage une fonction particulière qui,
à partir d’une donnée fournie en entrée, calcule une empreinte servant à identifier rapidement, bien
qu’incomplètement, la donnée initiale. Les fonctions de hachage sont utilisées en informatique et en
cryptographie. »
• d’autres méthodes qui concernent le multithreading et que nous n’étudions pas dans ce cours :
228
6 API Java
public
public
public
public
public
final
final
final
final
final
void wait() throws InterruptedException
native void notify()
native void notifyAll()
native void wait(long) throws InterruptedException
void wait(long, int) throws InterruptedException
'
$
6.2.1 Égalité
Les objets sont manipulés par des références ⇒
o1 == o2
Teste si les références sont égales
o1.equals(o3)
# 98
Teste si le contenu de l’objet référencé par o3 est comparable au contenu de
l’objet référencé par o1
&
%
La méthode equals a été conçue pour permettre de décrire que deux objets sont identiques du point de
vue métier de la classe. Par exemple, deux objets de type chaîne de caractères, qui sont lexicographiquement
équivalents, doivent être considérés comme identiques.
La classe Object implante cependant la méthode equals en testant l’égalité entre les références. Les
classes dérivées doivent redéfinir la méthode equals en garantissant qu’elle est correcte du point de vue
métier associé à la classe.
Dans notre schéma, la comparaison par l’égalité de références ne permet pas de détecter que les chaînes
de caractères référencées par o1 et o3 sont lexicographiquement les mêmes.
La surcharge de la méthode equals dans une classe consiste à choisir la liste des champs significatifs
de l’état des objets de la classe. L’objet courant est équivalent à l’objet en référence si chacun des champs
entrant dans la comparaison est équivalent au champ correspondant dans l’objet en référence.
229
6 API Java
'
$
6.2.2 Exemple d’égalité
1
public class StringEquals {
2
# 99
String argv [ ] ) {
S t r i n g s = " Ja " , j = " J a v a " ;
3
4
S t r i n g m = s + " va " ;
5
System . o u t . p r i n t l n (m) ;
6
i f ( j == m) { System . o u t . p r i n t l n ( " j ␣==␣m␣ V r a i " ) ;
7
} e l s e { System . o u t . p r i n t l n ( " j ␣==␣m␣ Faux " ) ;
8
}
9
i f ( j . e q u a l s (m) ) {
System . o u t . p r i n t l n ( " j . e q u a l s (m) ␣ V r a i " ) ;
10
} else {
11
System . o u t . p r i n t l n ( " j . e q u a l s (m) ␣ Faux " ) ;
12
}
13
}
14
15
}
Traces d’exécution :
Java
j == m Faux
j.equals(m) Vrai
&
%
Cet exemple construit deux chaînes de caractères m et j contenant chacune le mot Java.
La ligne 6 teste si les deux références pointent vers le même objet. L’affichage confirme que les deux
chaînes de caractères sont deux instances différentes.
La ligne 9 teste utilise la méthode equals depuis l’objet référencé par j en lui passant en argument la
référence vers l’objet m. L’affichage confirme que les deux objets sont équivalents conformément à la définition
de la surcharge de equals dans la classe String : «Compares this string to the specified object. The result
is true if and only if the argument is not null and is a String object that represents the same sequence of
characters as this object.»
$
'
6.2.3 Exemple de méthode equals
1
2
3
4
5
6
7
8
9
# 100
10
11
12
13
14
15
16
17
18
19
20
21
package s t u d s e q u a l s ;
}
@Override
p u b l i c boolean e q u a l s ( Object obj ) {
i f ( t h i s == o b j ) r e t u r n t r u e ;
i f ( o b j == n u l l ) r e t u r n f a l s e ;
i f ( ! ( obj i n s t a n c e o f Personne )) return f a l s e ;
Personne other = ( Personne ) obj ;
i f ( nom == n u l l ) {
i f ( o t h e r . nom != n u l l ) r e t u r n f a l s e ;
} e l s e i f ( ! nom . e q u a l s ( o t h e r . nom ) ) r e t u r n f a l s e ;
i f ( prenom == n u l l ) {
i f ( o t h e r . prenom != n u l l )
return false ;
} e l s e i f ( ! prenom . e q u a l s ( o t h e r . prenom ) ) r e t u r n f a l s e ;
return true ;
}
}
&
%
Dans cet exemple, nous considérons que deux objets de la classe Personne représentent la même personne
si leurs attributs nom et prenom sont deux à deux comparables. Cette comparaison ne tient donc pas compte
des autres attributs que nous n’avons pas représenté dans l’exemple.
230
6 API Java
6.3 Interface de programmation
L’attribut nom des deux objets est comparé à l’aide de la méthode equals de sa classe (à savoir String).
Lorsque les noms sont identiques, nous procédons de même pour l’attribut prenom.
La méthode equals a été générée avec eclipse. Il a suffit de lui préciser que les champs à comparer
étaient le nom et le prénom.
Le code est stéréotypé. En voici quelques points clés :
• l’argument reçu par la méthode est de la classe Object. Cela vient du fait que la méthode est héritée
et doit être redéfinie. Si nous mettions à la place une référence de la classe Personne, la méthode serait
une surcharge.
• la ligne 15 vérifie si la référence de l’objet passée en argument est égale à la référence de l’objet courant.
• la ligne 16 vérifie que la référence passée n’est pas nulle.
• la ligne 17 vérifie que la référence correspond à un objet de la classe courante ou de ses classes dérivées.
• la ligne 18 fait un « downcast » de l’argument vers une référence correspondant à la classe courante.
• les lignes suivantes testent l’égalité à l’aide de equals entre les attributs discriminants.
$
'
6.3 Interface de programmation
# 101
API Java organisée en paquetages
java.lang.* importé de manière automatique
Interface de programmation disponible quelle que soit la plate-forme
&
%
L’API Java est organisée en paquetages qui regroupent des classes participant à une même thématique
de programmation, par exemple java.net pour la programmation des interfaces réseau.
Le paquetage java.lang.* est importé de manière automatique. Il n’est donc pas nécessaire de faire les
imports des classes de ce paquetage. Ceci explique le fait que nous ayons utilisé String depuis nos premiers
exemples sans importer java.lang.String.
L’API Java est réalisée ou accessible dans l’ensemble des machines virtuelles et permet ainsi d’avoir une
interface de programmation disponible quelle que soit la plate-forme.
231
'
6 API Java
$
6.3.1 Quelques paquetages Java
java.lang
# 102
java.util
java.io
java.net
&
%
'
$
6.4 java.lang.*
# 103
&
%
La majorité des classes sur la figure sont des classes finales, c’est-à-dire qu’il n’est pas possible de les
dériver. Les seules classes non finales sont Object, Throwable, Thread et ThreadGroup.
Les classes Boolean et Void ainsi que les sous-classes de la classe Number (Byte, Double, Float, Integer,
Long et Short) sont des classes conteneurs. Elles encapsulent un champ du type primitif. Cela permet de
disposer d’objets de ces types, pour pouvoir les référencer (ne pas oublier que les types prédéfinis ne sont
pas des objets). Ces classes conteneurs offrent des méthodes de conversion de et vers le type String. Il faut
noter que ces classes n’offrent pas de méthode permettant la modification de leurs champs. Depuis, java 1.5,
ces classes sont dotées d’un caractéristique appelée auto-boxing qui permet la promotion d’une variable de
type primitif en un objet de son type conteneur de manière automatique. De manière réciproque, le langage
réalise l’extraction automatique de la valeur en type primitif à partir d’un objet si nécessaire.
La classe Character est également une classe conteneur du type char ; elle offre des méthodes de test
232
6 API Java
6.4 java.lang.*
du type du caractère (isDigit(), isLetter(), etc.) et des méthodes de transformation (toLowerCase(),
toTitleCase(), etc.). Les caractères en Java sont de type Unicode (voir http://unicode.org) sur deux
octets.
La classe Math regroupe les constantes π avec Math.PI et e avec Math.E et uniquement des opérations
mathématiques de classe (avec des méthodes statiques) : abs, sqrt, acos, cos, exp, log, pow, random, etc.
Cette fonction random utilise la classe Random du paquetage java.util décrit plus loin.
'
$
6.4.1 Exemple avec la classe Integer
1
public class IntegerExample {
2
# 104
3
Integer
4
int j = i . intValue ();
String argv [ ] ) {
i = new I n t e g e r ( " 4567 " ) ;
5
i = 4567;
6
j = i ; // u n b o x i n g i . i n t V a l u e ( )
System . o u t . p r i n t l n ( " I n t e g e r ␣ i ␣ : " + i + " ␣ i n t ␣ j ␣ : " + j + " \n " ) ;
7
}
8
9
// b o x i n g i = new I n t e g e r ( 4 5 6 7 ) ;
}
&
%
'
$
6.4.2 Classe String
Gestion des chaînes de caractères
# 105
Un objet de type String n’est pas modifiable
Les constantes littérales comme “abc” sont converties en String
L’opérateur « + » permet la concaténation des String
&
%
Il s’agit de chaînes de caractères (char) non modifiables.
233
'
6 API Java
$
6.4.3 Exemple pour String
1
2
3
4
5
6
7
8
9
# 106
10
11
12
13
14
i m p o r t j a v a . u t i l . Date ;
public c l a s s StringExample {
p u b l i c s t a t i c v o i d main ( f i n a l S t r i n g a r g v [ ] ) {
S t r i n g s = " \ u 0 0 c a t r e ␣ ou ␣ ne ␣ p a s ␣ \ u 0 0 e a t r e " ;
int lg = s . length ();
System . o u t . p r i n t l n ( s + " ␣ " + l g ) ;
System . o u t . p r i n t l n ( " J a v a " . s u b s t r i n g ( 2 , 3 ) ) ;
System . o u t . p r i n t l n ( " J a v a " + " S o f t " ) ;
char [ ] data = { ’ J ’ , ’ a ’ , ’ v ’ , ’ a ’ };
S t r i n g n = new S t r i n g ( d a t a ) ; System . o u t . p r i n t l n ( n ) ;
S t r i n g p = S t r i n g . v a l u e O f ( Math . P I ) ; System . o u t . p r i n t l n ( p ) ;
S t r i n g d = S t r i n g . v a l u e O f ( new Date ( ) ) ; System . o u t . p r i n t l n ( d ) ;
}
}
Être ou ne pas être 19
v
JavaSoft
Java
3.141592653589793
Wed Sep 22 12:25:04 CEST 2010
Java
&
%
Les caractères en Java ne sont pas ASCII mais Unicode sur 16 bits. Dans l’exemple, la notation "\u00ea"
désigne un caractère Unicode correspondant à la lettre « ê ».
Les méthodes comme substring() ou toUpperCase() retournent des copies de la chaîne de caractères.
La méthode valueOf de la classe String permet de convertir les variables de type primitif en chaîne de
caractères sans créer d’objet intermédiaire.
'
$
Questions API java.lang
Pourquoi faire dériver toutes les classes de java.lang.Object ?
# 107
Pourquoi cette classe fournit-elle les méthodes suivantes :
1. toString
2. equals
La classe integer est finale, à votre avis pourquoi ? (hors cours)
&
%
234
6 API Java
'
6.5 java.util.*
$
6.5 java.util.*
# 108
&
%
Le paquetage java.util contient des classes utilitaires, en particulier celles qui servent à manipuler
les dates et les collections. Cette diapositive représente quelques classes de ce paquetage qui ne sont pas
associées à la gestion des collections. Remarquez que ces classes ne sont pas associées à d’autres classes
par généralisation spécialisation et donc qu’elles sont directement liées à la classe Object du paquetage
java.lang. De plus, ces classes respectent les interfaces Cloneable et Serializable. Cette dernière interface
provient du paquetage java.io et est associée au fait de pouvoir sauvegarder et restaurer l’état d’un objet.
Cette sauvegarde et restauration peut se faire à partir de fichiers. Les objets peuvent aussi être restaurés
après téléchargement en provenance d’un autre site.
Nous nous intéressons plus particulièrement aux collections dans les diapositives qui suivent et en particulier :
• java.util.Collection
• java.util.List
• java.util.Map
• java.util.Iterator
• java.util.Vector
• java.util.Hashtable
235
6 API Java
'
6.5 java.util.*
$
6.5.1 Classe paramétrée
# 109
Comme en UML, classe associée à la classe des objets qu’elles servent à manipuler
Classe associée spécifiée entre « <> »
Exemple : Vector<String> myStringVector = new Vector<String>();
&
%
La notion de classe paramétrée est présente dans Java depuis la version 5.0. Dans la terminologie Java, ce
type de classe est dite « generics ». Cette notion a été empruntée au langage C++ et permet, entre autre, de
spécialiser les classes qui gèrent les collections en fonction de la classe des objets que ces collections servent
à manipuler.
Ainsi, nous désirons avoir une liste de chaînes de caractères ou une liste de personnes. Nous avons besoin
des mêmes opérations sur les deux listes : ajouter, rechercher, retirer. Nous ne voulons cependant pas mélanger
les personnes et les chaînes de caractères. C’est à cela que sert la paramétrisation des classes permettant
de gérer des collections. Cette paramétrisation simplifie la vie du programmeur en lui garantissant que les
collections ne contiennent que des objets d’un type donné.
La paramétrisation est réalisée en spécifiant le type des objets manipulés entre les symboles inférieur et
supérieur. Il est nécessaire de préciser ce type lors de la déclaration de la référence et lors de la création de
l’objet.
'
$
6.5.2 Classes Abstraites des collections
# 110
&
%
236
6 API Java
6.5 java.util.*
Cette figure montre les relations entre les classes abstraites et les interfaces du paquetage ainsi que celles
associées à l’interface Iterable de java.lang.
'
$
# 111
&
%
Parmi les nombreuses collections fournies par le paquetage java.util, nous nous intéressons à un sousensemble, et plus précisément, à la classe Vector qui permet de manipuler des tableaux dynamiques, ainsi
qu’à la classe Hashtable qui permet de gérer des collections rangées par hachage. Comme nous le verrons
plus loin, nous utiliserons ces collections à travers les interfaces qu’elles réalisent. Les classes instanciables
réalisent aussi les interfaces java.lang.Cloneable et java.io.Serializable.
'
$
6.5.4 Collections
Collection : interface commune à toutes les collections ;
List : interface permettant de gérer une liste ;
# 112
Iterator : interface permettant de parcourir une collection ;
Vector : réalisation de liste dans une sorte de tableau à taille variable ;
Map : interface permettant de gérer des tables associant une clé à un objet ;
Hashtable : tableau associatif
&
%
La gestion des collections a beaucoup évolué avec la maturité du langage Java. Les premières versions du
langage permettaient de faire des collections de Object. Depuis Java 1.5, les collections sont paramétrées.
Nous concentrerons notre attention sur les deux interfaces, List et Map. La première interface permet de
237
6 API Java
6.5 java.util.*
gérer des listes comme s’il s’agissait d’un tableau de taille variable. La seconde interface permet de gérer des
ensembles de paires clé, valeur que nous appelerons dictionnaires.
Ensuite, nous utiliserons l’interface List fournie par la classe Vector pour la manipulation de cette
dernière. De même, nous utiliserons l’interface Map fournie par la classe Hashtable pour manipuler les
éléments contenus dans une HashTable.
'
$
6.5.5 Interface Iterable
# 113
provient de java.lang
Préconise : Iterator<T> iterator()
Iterator<> décrit 6.5.12
&
%
$
'
6.5.6 Interface Collection<E>
Collection la plus générale
Insertion à la fin avec boolean add(E )
Suppression de tous les éléments avec void clear()
# 114
Test de la présence d’un objet dans la collection avec boolean contains(E)
Test permettant de savoir si la collection est vide avec boolean isEmpty()
Suppression du premier élément égal selon equals(E) au paramètre avec boolean
remove(E)
Nombre d’éléments dans la collection avec int size().
&
%
L’interface collection préconise une ensemble de méthodes qui sont applicables aussi bien sur les listes
que sur les dictionnaires. Nous trouvons parmi ces méthodes :
• l’ajout en fin de collection avec boolean add(E ) ;
• la mise à vide de la collection avec void clear() ;
238
6 API Java
6.5 java.util.*
• le test de présence d’un objet dans la collection avec boolean contains(E) ;
• un test pour savoir si la collection est vide avec boolean isEmpty() ;
• la suppression du premier élément de la collection égal à un objet avec boolean remove(E) ;
• la taille de la collection avec int size().
'
$
6.5.7 Interface List<E>
Collection ordonnée supportant les objets dupliqués
# 115
Accès à un élément avec E get(int index )
Insertion à une position donnée avec add(int, E)
Suppression de l’élément à une position donnée avec E remove(int))
Recherche de l’indice d’un objet s’il est dans le vecteur avec int indexOf(E)
&
%
L’interface List préconise des méthodes supplémentaires à l’interface Collection. Ces méthodes correspondent au caractère ordonné de la liste. Elles concernent la manipulation des éléments par leur indice.
Nous trouvons parmi ces méthodes :
• l’ajout d’un élément à un indice avec boolean add(int, E ) ;
• la suppression d’un élément correspondant à l’indice avec E remove(int) ;
• le test de présence d’un objet dans la collection boolean contains(E) ;
• la recherche de l’indice d’un objet dans la collection int indexOf(E).
239
6 API Java
'
6.5 java.util.*
$
6.5.8 Classe Vector<E>
Gestion d’une collection d’éléments de la classe E dans un tableau dynamique
Pas de contrainte d’unicité sur les éléments
# 116
Dérive de la classe AbstractList
donc implémente l’interface List
donc implémente l’interface Collection
donc implémente aussi l’interface Iterable.
&
%
Les vecteurs en Java sont des tableaux d’objets dont la taille varie en fonction des éléments que l’on ajoute
ou enlève. Les objets placés dans un Vector doivent correspondre, au sens de l’instruction instanceOf, au
paramètre de type associé. L’accroissement de la taille de la collecrion est automatique, ce qui rend cette
classe facile à utiliser. La classe Vector réalise les interfaces List, Collection et Iterable. Il existe trois
constructeurs pour cette classe :
1. le premier sans argument crée un vecteur de taille initiale 10 : Vector<Integer> v1 = new
Vector<Integer>() ;
2. le second accepte un argument qui donne la taille initiale du vecteur : Vector<Integer> v1 = new
Vector<Integer>(15) ;
3. le troisième accepte deux arguments, le premier correspond à la taille initiale du vecteur et le second
à l’incrément de taille : Vector<Integer> v3 = new Vector(16,10);.
'
$
6.5.9 Boucle pour les collections
Simplification de l’écriture des parcours de collections à partir de Java 5.
Utilisation du for avec une collection, un tableau
# 117
Syntaxe : for(Type t : collection)
Itère les objets de la collection dans la référence t
Type de collection et type de t compatibles
Ressemble aux foreach de php
&
%
240
6 API Java
6.5 java.util.*
Le parcours d’une collection ressemble à une boucle for. La version 5 du langage a introduit une nouvelle
interprétation du for qui s’inspire du foreach des langages tels que php, python et perl. Cette notation
condense l’écriture en focalisant sur la collection et sur l’objet itéré.
'
$
6.5.10 Exemple for-each sur un Vector
1
import j a v a . u t i l . L i s t ;
2
import j a v a . u t i l . Vector ;
3
p u b l i c c l a s s VectorForExample {
p u b l i c s t a t i c v o i d main ( S t r i n g a r g v [ ] ) {
4
# 118
5
L i s t <S t r i n g > v = new V e c t o r <S t r i n g > ( ) ;
6
v . add ( " John " ) ;
7
System . o u t . p r i n t l n ( " T a i l l e ␣ de ␣ l a ␣ l i s t e ␣ " + v . s i z e ( ) ) ;
8
f o r ( S t r i n g s : v ){
System . o u t . p r i n t l n ( " ␣ "+s ) ;
9
}
10
}
11
12
v . add ( " G e o r g e s " ) ;
}
&
%
'
$
6.5.11 Exemple de classe avec Vector
1
2
3
4
5
6
7
8
9
# 119
10
11
12
13
14
15
16
17
18
publi c c l a s s VectorExampleBis {
L i s t <S t r i n g > v=new V e c t o r <S t r i n g > ( ) ;
v . add ( " un " ) ; v . add ( " deux " ) ; v . add ( 2 , " t r o i s " ) ;
System . o u t . p r i n t l n ( " Contenu ␣ du ␣ v e c t e u r ␣ : " ) ;
f o r ( i n t i =0; i <v . s i z e ( ) ; i ++) {
System . o u t . p r i n t l n ( " ␣ ␣ " + v . g e t ( i ) ) ;
}
i f ( v . remove ( " un " ) ) System . o u t . p r i n t l n ( " un ␣ removed " ) ;
v . remove ( 0 ) ;
System . o u t . p r i n t l n ( " Contenu ␣ du ␣ v e c t e u r ␣ : " ) ;
f o r ( i n t i =0; i <v . s i z e ( ) ; i ++) {
System . o u t . p r i n t l n ( " ␣ ␣ " + v . g e t ( i ) ) ;
}
}
}
Trace de l’exécution :
Contenu du vecteur :
&
%
241
6 API Java
'
# 120
6.5 java.util.*
$
un
deux
trois
un removed
Contenu du vecteur :
trois
&
%
Dans cet exemple :
1. nous manipulons le vecteur à travers l’interface List ;
2. le vecteur est créé à la ligne 5 ;
3. la chaîne de caractères contenant « un » est ajoutée à la ligne 6 comme premier élément ;
4. la chaîne de caractères contenant « trois » est ajoutée à la ligne 6 comme second élément ;
5. la chaîne de caractères contenant « deux » est insérée à la ligne 6 en troisième position (rang deux) ;
6. puis chaque élément du vecteur est affiché par un parcours utilisant une itération bornée par la taille
du vecteur (lignes 8 à 10) ;
7. la ligne 11 utilise la méthode remove de la classe Collection pour supprimer le premier élément de la
collection comparable à « un ». Cette méthode dépend de la méthode equals du type paramétré. En
effet, elle réalise un parcours du vecteur et compare son argument avec chacun des objets du vecteur
en utilisant la méthode equals.
8. la ligne 12 réalise la suppression de l’élément de rang 0 de la liste.
242
6 API Java
'
6.5 java.util.*
$
6.5.12 Interface Iterator
Il s’agit d’une interface qui fournit une technique pour parcourir les éléments d’une
collection
Iterator est spécialisé dans le parcours séquentiel des éléments d’une collection. Il
propose les méthodes suivantes :
# 121
hasNext() retourne vrai si l’itérateur contient encore une élément
next() retourne l’élément suivant
remove() supprime le dernier élément retourné par next() de la collection
toutes les collections possèdent la méthode iterator()
&
%
En dehors de l’utilisation du for, le parcours d’une collection en utilisant un itérateur est fortement
recommandé pour la lisibilité et la compréhension du code. Le parcours en utilisant Iterator permet la
suppression d’éléments ce que ne permet pas l’utilisation du for-each.
'
$
6.5.13 Exemple avec Iterator
1
2
3
import j a v a . u t i l . I t e r a t o r ;
4
public class VectorIterator {
5
# 122
6
L i s t <S t r i n g > v = new V e c t o r <S t r i n g > ( ) ;
7
v . add ( " John " ) ; v . add ( " G e o r g e s " ) ;
8
I t e r a t o r <S t r i n g > e = v . i t e r a t o r ( ) ;
9
while ( e . hasNext ( ) ) {
System . o u t . p r i n t l n ( " ␣ " + e . n e x t ( ) ) ;
10
11
}
12
// P a r c o u r s a v e c une b o u c l e f o r
13
f o r ( e = v . i t e r a t o r ( ) ; e . hasNext ( ) ; ) {
System . o u t . p r i n t l n ( " ␣ " + e . n e x t ( ) ) ;
14
}
15
}
16
17
}
&
%
Cet exemple montre deux parcours de la collection v avec un itérateur une fois avec une boucle while
et une fois avec une boucle for. Vous remarquerez que pour réaliser le parcours deux fois, il est nécessaire
d’initialiser l’itérateur deux fois. La première initialisation est réalisée avant la boucle while à la ligne 8. La
seconde initialisation est réalisée dans la partie initialisation de la boucle for à la ligne 13.
L’exécution de ce code donne le résultat suivant :
John
Georges
John
243
6 API Java
6.5 java.util.*
Georges
'
$
6.5.14 Dictionnaires Map<K,V>
Les tables de correspondance permettent, à partir d’une clé, de retrouver une valeur
Cette interface est associée à deux paramètres qui correspondent à la classe de la clé
et à celle de la valeur
C’est pourquoi sa définition est notée Map<K,V>
Par exemple, Map<String,String> myMap
# 123
Map supporte les méthodes supplémentaires suivantes, en plus de celles prescrites
par Collection :
boolean containsKey(K key)
boolean containsValue(V value)
Set<K> keysSet()
Collection<V> values()
V get(K key)
V put(K key, V value)
&
%
Un dictionnaire permet d’associer des clés avec des valeurs. Les clés doivent être uniques et la comparaison
des clés doit utiliser la méthode equals de la classe de la clé. Les tables de correspondance ajoutent des
méthodes relativement à l’interface des collections. Ces méthodes permettent d’ajouter et de retrouver une
valeur associée à une clé.
L’ensemble des clés peut être obtenu dans un objet de type Set. De même, l’ensemble des valeurs peut
être obtenu dans un objet de type Collection.
'
$
6.5.15 Exemple pour Map
1
2
3
4
5
6
7
8
9
# 124
10
11
12
13
14
15
16
import j a v a . u t i l . Hashtable ;
i m p o r t j a v a . u t i l . Map ;
p u b l i c c l a s s HashMapExample {
p u b l i c s t a t i c v o i d main ( f i n a l S t r i n g a r g v [ ] ) {
Map<S t r i n g , S t r i n g > h t = new H a s h t a b l e <S t r i n g , S t r i n g > ( ) ;
h t . p u t ( " Ba " , " Bah " ) ; h t . p u t ( " Aa " , " aha " ) ;
h t . p u t ( "BB" , " b e b e " ) ;
f o r ( S t r i n g k : ht . keySet ( ) ) {
System . o u t . p r i n t l n ( " C l e ␣ : ␣ "+ k
+ "␣ Valeur ␣ : ␣" + ht . get ( k ) ) ;
}
f o r ( S t r i n g v : ht . v a l u e s ( ) ) {
System . o u t . p r i n t l n ( " ␣ V a l e u r ␣ : ␣ " + v ) ;
}
}
}
Le résultat de l’exécution de l’exemple est le suivant :
Cle : Ba Valeur : Bah
Cle : BB Valeur : bebe
Cle : Aa Valeur : aha
&
%
244
6 API Java
'
Valeur : Bah
Valeur : bebe
Valeur : aha
6.5 java.util.*
$
# 125
&
%
L’exemple montre un dictionnaire réalisé dans une Hashtable. Ce dictionnaire est rempli avec trois paires
de clé, valeur : ("Ba", "Bah"), ("Aa", "aha") et ("BB", "bebe"). À la ligne 8, une boucle permet le parcours
du Set obtenu avec les clés par l’appel de la méthode keySet(). À la ligne 12, une boucle foreach permet
le parcours de la Collection obtenue avec les valeurs par l’appel à la méthode values().
'
$
6.5.16 Dictionnaire Hashtable<K,V>
# 126
Ces dictionnaires réalisent l’interface Map.
La classe associée à la clé doit supporter les méthodes hashCode() et equals()
&
%
Les dictionnaires de type tableau associatif présente les propriété suivantes :
• les objets sont rangés dans un tableau de conteneurs. Idéalement, il y a un seul objet par conteneur ;
• la valeur hachée d’une clé permet d’obtenir le rang du conteneur ;
• si plusieurs objets donnent le même valeur hachée, ils sont rangés dans le même conteneur comme dans
un vecteur ;
245
6 API Java
6.5 java.util.*
• les clés doivent être uniques,
• la durée de recherche d’une clé est idéalement en O(1) temps constant pour le calcul du rang du
conteneur puis accès.
• le temps peut être en O(M) lorsqu’il y a des collisions de hachage.
Vous pouvez trouver plus de détails sur les fonctions de hachage dans la section 6.4, pages 506 à 549 du livre
de D. E. Knuth, « The Art of Computer Programming, Vol 3. : sorting and searching ».
La classe de la clé doit garantir que ses méthodes equals et hashCode sont correctes, ce sont elles qui
sont utilisées.
'
$
6.5.17 Exemple pour Hashtable
1
import j a v a . u t i l . Hashtable ;
2
i m p o r t j a v a . u t i l . Map ;
3
p u b l i c c l a s s HashtableExample {
4
Map<S t r i n g , S t r i n g > h t = new H a s h t a b l e <S t r i n g , S t r i n g > ( ) ;
6
h t . p u t ( " Ba " , " Bah " ) ; h t . p u t ( " Aa " , " aha " ) ;
7
h t . p u t ( "BB" , " b e b e " ) ;
8
f o r ( S t r i n g k : ht . keySet ( ) ) {
System . o u t . p r i n t l n ( " C l e ␣ : ␣ "+ k + " ␣ Hash ␣ : ␣ "+ k . hashCode ( )
9
# 127
String argv [ ] ) {
5
+ "␣ Valeur ␣ : ␣" + ht . get ( k ) ) ;
10
}
11
}
12
13
}
Le résultat de l’exécution de l’exemple est le suivant :
Cle : Ba Hash : 2143 Valeur : Bah
Cle : BB Hash : 2112 Valeur : bebe
Cle : Aa Hash : 2112 Valeur : aha
&
%
L’exemple montre qu’il est possible que deux clés d’une même hastable donnent la même valeur pour
la fonction de hachage.
'
$
6.5.18 Représentation d’une Hashtable
# 128
&
%
246
6 API Java
Cette figure représente une table de hachage dans laquelle les conteneurs possèdent 5 entrées. Cette table
correspond au programme précédent. Le premier conteneur correspond à la valeur de hachage 2112 et le
second à la valeur 2143. Le premier conteneur contient deux éléments, le premier correspond avec la chaîne
de caractères « Bebe » et le second avec la chaîne de caractères « Aha ». Le second conteneur contient
l’élément correspondant à la chaîne de caractères « Bah ».
'
$
Questions collections en Java
# 129
Quelles sont les opérations préconisées par l’interface Collection ?
À quel usage est destiné un Iterator ?
Quelle est l’utilité du concept de Map ?
&
%
247
'
$
# 130
7.1
7.2
7.3
7.4
7.5
Motivation : retours sur un bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Réalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Traitement des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Exemple de traitement d’exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
&
%
Cette partie s’intéresse au traitement des erreurs et à leur gestion à travers les classes d’exceptions.
'
# 131
$
7.1 Motivation : retours sur un bug
&
%
Après avoir visionné l’accident du vol, voici quelques explications extraites du rapport d’experts réalisés
en 1996. Les parties expliquant la cause informatique de cet accident ont été mise en gras.
« In general terms, the Flight Control System of the Ariane 5 is of a standard design. The attitude of
the launcher and its movements in space are measured by an Inertial Reference System (SRI). It has its own
internal computer, in which angles and velocities are calculated on the basis of information from a “strapdown” inertial platform, with laser gyros and accelerometers. The data from the SRI are transmitted through
the databus to the On-Board Computer (OBC), which executes the flight program and controls the nozzles of
the solid boosters and the Vulcain cryogenic engine, via servovalves and hydraulic actuators.
In order to improve reliability there is considerable redundancy at equipment level. There are two SRIs
operating in parallel, with identical hardware and software. One SRI is active and one is in stand-by, and if
248
the OBC detects that the active SRI has failed it immediately switches to the other one, provided that this
unit is functioning properly. Likewise there are two OBCs, and a number of other units in the Flight Control
System are also duplicated.
The design of the Ariane 5 SRI is practically the same as that of an SRI which is presently used on
Ariane 4, particularly as regards the software.
Based on the extensive documentation and data on the Ariane 501 failure made available to the Board, the
following chain of events, their inter-relations and causes have been established, starting with the destruction
of the launcher and tracing back in time towards the primary cause.
• The launcher started to disintegrate at about H0 + 39 seconds because of high aerodynamic loads due
to an angle of attack of more than 20 degrees that led to separation of the boosters from the main stage,
in turn triggering the self-destruct system of the launcher.
• This angle of attack was caused by full nozzle deflections of the solid boosters and the Vulcain main
engine.
• These nozzle deflections were commanded by the On-Board Computer (OBC) software on the
basis of data transmitted by the active Inertial Reference System (SRI 2). Part of these
data at that time did not contain proper flight data, but showed a diagnostic bit pattern
of the computer of the SRI 2, which was interpreted as flight data.
• The reason why the active SRI 2 did not send correct attitude data was that the unit had declared a
failure due to a software exception.
• The OBC could not switch to the back-up SRI 1 because that unit had already ceased to function during
the previous data cycle (72 milliseconds period) for the same reason as SRI 2.
• The internal SRI software exception was caused during execution of a data conversion from 64-bit
floating point to 16-bit signed integer value. The floating point number which was converted had a
value greaterthan what could be represented by a 16-bit signed integer. This resulted in an Operand
Error. The data conversion instructions (in Ada code) were not protected from causing
an Operand Error, although other conversions of comparable variables in the same place
in the code were protected.
»
$
'
7.2 Principes
Séparation entre flot de gestion des erreurs et flot d’exécution normale
Contrôle de flot spécifique pour les exceptions
Parties de code balisées relativement au traitement d’erreurs (régions gardées)
# 132
Parties de code spécifiques pour le traitement d’erreurs
Méthode constatant l’erreur et ne possédant pas suffisamment d’informations dans
son contexte pour la traiter
Nécessité de remonter le chemin d’appel jusqu’à trouver une méthode possédant
suffisamment d’informations pour traiter cette erreur
&
%
La gestion des erreurs dans les programmes orientés objet tente de distinguer les instructions associées
au contrôle de flot normal du programme et celles qui sont associées à la gestion des erreurs. Pour ce faire,
249
7.2 Principes
Java introduit la notion d’exception. Une exception est un événement qui ressemble à une interruption
logicielle, comme lorsque votre programme fait une division par 0. La gestion des exceptions permet au
programme de prévenir et d’essayer de traiter ce type d’erreurs avec beaucoup de flexibilité pour permettre
au programme de continuer à fonctionner. Généralement, la méthode dans laquelle l’erreur est détectée ne
possède pas suffisamment d’informations dans son contexte pour traiter cette erreur. L’erreur vient en effet
le plus souvent de mauvais paramètres qui ont été reçus par cette méthode. L’exception doit remonter le
long du chemin d’appel des méthodes jusqu’à une méthode qui possède suffisamment d’informations pour
traiter cette erreur.
$
'
7.2.1 Mise en œuvre
Les méthodes peuvent :
Lever une exception :
En prévenant les autres méthodes par l’ajout d’une clause throws dans leur
prototype
En créant un objet du type exception : classe qui dérive de
java.lang.Exception
# 133
Et en utilisant le mot réservé « throw » pour provoquer la remontée du chemin
d’appel
Relayer des exceptions en ajoutant au prototype le mot clef « throws » et la liste
des exceptions
Traiter des exceptions par des blocs try, catch, et finally
&
%
'
$
7.2.2 Exemple de traitement
1
2
3
4
5
6
7
8
9
# 134
10
11
12
13
14
15
16
17
18
19
20
21
public class ArrayControled {
s t a t i c f i n a l i n t max = 4 2 ;
p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
int i , j = 0;
i n t [ ] a r r a y O f I n t = new i n t [ max ] ;
f o r ( i =0; i <a r r a y O f I n t . l e n g t h ; i ++){
arrayOfInt [ i ] = i ;
}
f o r ( i =0; i <a r g s . l e n g t h ; i ++){
try {
j = Integer . parseInt ( args [ i ] ) ;
System . o u t . p r i n t l n ( a r r a y O f I n t [ j ] ) ;
} catch ( NumberFormatException n f e ){
System . o u t . p r i n t l n ( " P a r a m e t e r ␣ " + a r g s [ i ] + " ␣ s h o u l d ␣ be ␣ an ␣ i n t e g e r " ) ;
} c a t c h ( A r r a y I n d e x O u t O f B o u n d s E x c e p t i o n oobe ) {
System . o u t . p r i n t l n ( " P a r a m e t e r ␣ " + a r g s [ i ]
+ " ␣ s h o u l d ␣ be ␣>=0␣ and ␣<" + max ) ;
}
}
}
}
&
%
Ce code initialise un tableau de 42 entiers dans la partie entre le lignes 6 et 8 avec leur indice. Puis, à
partir des arguments du main, il essaye d’afficher le contenu de l’entrée correspondante du tableau.
250
7.3 Réalisation
Dans ce code, la région gardée correspond aux lignes 10 à 13, c’est à dire le bloc d’instructions du try.
Deux cas d’erreur sont traités : l’argument n’est pas un entier et la valeur de l’entier obtenu n’est pas
entre 0 et 41.
L’exécution de ce programme avec les arguments 2 43 zurg 22, donne le résultat suivant :
2
Parameter 43 should be >=0 and <42
Parameter zurg should be an integer
22
'
$
7.3 Réalisation
Classes dérivées de java.lang.Exception
Lever une exception consiste à :
Créer une instance d’une classe dérivée de java.lang.Exception
# 135
Déclencher le déroulement arrière des appels de méthodes qui ont menés à la
méthode courante
Arrêter le déroulement arrière à la rencontre d’un bloc try catch pour ce type
d’exception
S’il n’y a aucun bloc try catch l’exception remonte jusqu’à la machine virtuelle
Java qui interrompt l’exécution
Lorsqu’un bloc try catch correspondant à l’exception est trouvé :
I Les instructions suivantes du bloc try sont sautées
I Les instructions du bloc catch qui correspond le mieux sont exécutées
&
%
Les exceptions sont des classes dérivées de la classe java.lang.Exception. Lever une exception consiste
à créer une instance d’une classe dérivée de java.lang.Exception, puis à déclencher le déroulement arrière
des appels de méthodes qui ont menées à la création de l’exception.
Ce déroulement arrière s’interrompt lorsqu’il rencontre un bloc try catch correspondant à ce type d’exception.
Si aucun bloc try catch n’est trouvé, alors l’exception remonte jusqu’à la machine virtuelle Java qui
interrompt l’exécution du programme.
Lorsqu’un bloc try catch est trouvé, les instructions dans le bloc try qui suivent l’instruction qui a
provoqué l’exception ne sont pas exécutées et le flux de contrôle passe à la première instruction de la partie
catch dont la classe correspond le mieux à l’exception qui est reçue.
251
'
$
7.3.1 java.lang.Exception
# 136
&
%
Les exceptions sont des classes. Il est possible d’en définir de nouvelles. Elles doivent dériver de la classe
Exception ou d’une de ses classes dérivées. La classe Exception hérite, quant à elle, de la classe Throwable
qui fournit l’ensemble des opérations.
Les classes issues de Throwable se rangent en deux catégories :
• hors contrôle : elles servent à gérer les erreurs internes à Java ou les fautes de programmation (division
par zéro, dépassement des limites d’un tableau, etc.). Pour ces exceptions hors contrôle :
– la directive throws ne doit pas être utilisée ;
– les erreurs internes à Java sont gérées par la classe Error qui hérite de Throwable. Ces erreurs
ne peuvent pas être déclenchées par le programmeur ;
– les fautes de programmation sont gérées par la classe RuntimeException et toutes ses sous-classes
(par exemple, ArithmeticException) ;
• sous contrôle : il s’agit des autres exceptions que peuvent déclencher vos méthodes et que vous devez
signaler à leurs utilisateurs par la directive throws.
252
'
$
7.4 Traitement des exceptions
Pour les exceptions sous contrôle :
Une méthode qui fait appel à une méthode qui peut lever une exception doit définir
son comportement relativement à cette exception
# 137
Traiter l’exception par un bloc try catch
Relayer l’exception par le mot réservé throws
Réorganisation du code de manière cohérente dans les blocs try.
&
%
Une méthode qui fait appel à une méthode qui peut lever une exception doit définir son propre comportement relativement à cette exception.
Pour cela elle peut soit prendre en charge le traitement de l’exception en entourant l’appel correspondant
dans un bloc try catch, soit déclarer qu’elle est transparente à l’exception en utilisant le mot réservé throws
pour ce type d’exception.
L’introduction de bloc try catch s’accompagne de la réorganisation du code en intégrant les parties qui
dépendent de la bonne exécution de la méthode risquant de lever l’exception, à l’intérieur du bloc.
'
$
1
2
3
4
5
6
1
2
# 138
3
4
5
6
7
8
9
10
11
12
13
14
15
p u b l i c c l a s s NumException e x t e n d s E x c e p t i o n {
p r i v a t e s t a t i c f i n a l l o n g s e r i a l V e r s i o n U I D = 1L ;
p u b l i c NumException ( f i n a l d o u b l e v a l e u r , f i n a l S t r i n g s ) {
super ( s + "␣ v a l e u r ␣ : ␣" + v a l e u r ) ;
}
}
public c l a s s TestSimpleExcept {
/∗ ∗
∗ P o s i t i f t e s t e s i l a v a l e u r du p a r a m e t r e v a l e s t p o s i t i v e .
∗ @param v a l v a l e u r a t e s t e r
∗ @t hro ws NumException s i v a l e s t < 0
∗/
p r i v a t e s t a t i c v o i d p o s i t i f ( f i n a l d o u b l e v a l ) t h r o w s NumException {
i f ( v a l < 0 . 0 ) throw new NumException ( v a l , " V a l e u r ␣ p o s i t i v e ␣ a t t e n d u e . " ) ;
return ;
}
/∗ ∗
∗ t e s t P o s i t i f u t i l i s e p o s i t i f e t r e l a y e l ’ e x c e p t i o n NumException .
∗ @param v a l v a l e u r a t e s t e r .
∗ @t hro ws NumException l o r s q u e p o s i t i f emet NumException
∗/
&
%
253
'
p r i v a t e s t a t i c v o i d t e s t P o s i t i f ( d o u b l e v a l ) t h r o w s NumException {
p o s i t i f ( val );
System . o u t . p r i n t l n ( " Pas ␣d ’ e x c e p t i o n ␣ l e ␣ c o d e ␣ c o n t i n u e ␣ en ␣ s e q u e n c e " ) ;
return ;
}
/∗ ∗
∗ T r a i t e m e n t d e s a r g u m e n t s de main p a r t e s t d e s
∗ valeurs entieres positives .
∗ @param a r g v a r g u m e n t s de l a l i g n e de commande .
∗/
p u b l i c s t a t i c v o i d main ( f i n a l S t r i n g [ ] a r g v ) {
int i , j = 0;
f o r ( i =0; i <a r g v . l e n g t h ; i ++) {
try {
j = I n t e g e r . p a r s e I n t ( argv [ i ] ) ;
testPositif ( j );
System . o u t . p r i n t l n ( " P a r a m e t e r ␣ " + a r g v [ i ] + " ␣ s h o u l d ␣ be ␣ an ␣ i n t e g e r " ) ;
} c a t c h ( NumException n ) {
System . o u t . p r i n t l n ( " Catch ␣ d a n s ␣ l e ␣ main ␣ " + n ) ;
}
}
}
16
17
18
19
20
21
22
23
24
25
26
# 139
27
28
29
30
31
32
33
34
35
36
37
38
39
$
}
&
%
'
$
Trace d’exécution avec arguments 2, -3 et 3 :
# 140
Pas d’exception le code continue en sequence
Catch dans le main NumException: Valeur positive attendue. valeur : -3.0
&
%
Dans cet exemple la classe NumException permet de caractériser des exceptions qui sont relatives à une
valeur numérique reçue en paramètre.
Cette exception est utilisée dans la méthode positif de la classe TestSimpleExcept pour interrompre
le cours normal de l’exécution du programme lorsque cette méthode est appelée avec un argument inférieur
à 0.
La méthode positif est appelée à travers testPositif qui ne lève pas d’exception elle-même mais
relaie l’exception, du fait qu’elle contient la clause throws. L’exécution de cette méthode est interrompue
lorsqu’une exception est levée.
La méthode main contrôle les appels à testPositif par un bloc try catch.
254
'
$
Questions sur les exceptions
À quoi servent :
# 141
1. Le bloc try catch ?
2. Le mot réservé new après la directive throw ?
Pourquoi créer une classe d’exception ?
&
%
255
'
8.1 Copie simple/légère
$
# 142
8.1 Copie simple/légère . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
8.2 Retour sur hashCode() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
8.3 Retour sur les exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
&
%
Cette partie est consacrée aux concepts objets avancés et à leur réalisation en Java. Parmi ces concepts,
nous abordons les classes abstraites, et les interfaces. Cette partie revient sur des concepts déjà vus comme
la copie profonde et les exceptions, pour évoquer leur utilisation dans des cas peu simples.
'
$
Les objets sont manipulés par des références ⇒
o2 = o1 : copie la référence o1 dans o2
# 143
o2 = o1.clone() : o2 référence un nouvel objet (copie de o1)
&
%
La classe Object propose une copie légère par un clonage basé sur la copie champ par champ réalisée
par affectation : elle n’appelle pas récursivement la méthode clone() (pour cette raison, la copie est appelée
légère). Cette opération de clonage par défaut n’est possible que si la classe réalise (implements) l’interface
java.lang.Cloneable. Si ce n’est pas le cas, l’exception CloneNotSupportedException est levée. Cette
copie champ par champ est suffisante pour avoir deux objets indépendants lorsque les objets copiés ne
contiennent pas de référence.
Lorsque les objets contiennent des références, il faut définir la méthode clone() pour cette classe, mais
aussi pour toutes les classes référencées par celle-ci, afin de réaliser une copie récursive dite « copie profonde ».
256
La méthode clone est protected dans la classe Object afin de restreindre l’utilisation de cette méthode
aux classes et à leurs classes filles. Si le clonage est garanti (par la redéfinition de la méthode clone), celle-ci
doit devenir publique.
'
$
8.1.1 Copie pour studs
# 144
&
%
Nous voulons réaliser une méthode clone qui fonctionne pour la paire Scrutin et Personne.
La difficulté de ce clonage tient au fait que la relation est bidirectionnelle. Il faut donc être capable de
dupliquer les deux objets et de ne pas avoir d’incohérence d’association entre ces objets.
'
$
8.1.2 Représentation graphique d’une copie légère dans studs
# 145
&
%
257
'
$
8.1.3 Exemple de copie légère
1
2
3
4
5
6
7
8
9
# 146
10
11
12
13
14
15
16
17
18
19
20
21
22
&
%
'
$
1
2
3
4
5
6
7
8
9
10
11
# 147
package s t u d s c l o n e l i g h t ;
import j a v a . u t i l . A r r a y L i s t ;
p u b l i c c l a s s Personne implements C l o n e a b l e {
p r i v a t e i n t n b P a r t i c i p a t i o n s = 0 , nbOrg = 0 ;
p r i v a t e A r r a y L i s t <S c r u t i n > s c r u t i n s ;
p u b l i c P e r s o n n e ( S t r i n g nom , S t r i n g prenom ) {
t h i s . nom = nom ; t h i s . prenom = prenom ; s c r u t i n s = new A r r a y L i s t <S c r u t i n > ( ) ; }
p u b l i c S c r u t i n o r g a n i s e r S c r u t i n ( S t r i n g nom ) {
s c r u t i n s . add ( new S c r u t i n ( nom , t h i s ) ) ; r e t u r n s c r u t i n s . g e t ( nbOrg ++); }
@Override
p u b l i c Personne c l o n e ( ) throws CloneNotSupportedException {
return ( Personne ) super . clone ( ) ;
}
p u b l i c S t r i n g getNom ( ) { r e t u r n nom ; }
p u b l i c S t r i n g getPrenom ( ) { r e t u r n prenom ; }
p u b l i c A r r a y L i s t <S c r u t i n > g e t S c r u t i n s ( ) { r e t u r n s c r u t i n s ; }
p u b l i c void v o t e r ( B u l l e t i n b ){ }
public void c o n s u l t e r R e s u l t a t ( Scrutin s ) { }
public void seRetirerDUnScrutin ( Scrutin s ) { }
}
12
13
14
15
16
17
18
19
20
21
22
23
24
import s t u d s c l o n e l i g h t . S c r u t i n ;
import s t u d s c l o n e l i g h t . Personne ;
public class TestCloneLight {
p u b l i c s t a t i c v o i d main ( f i n a l S t r i n g [ ] a r g s )
throws CloneNotSupportedException {
P e r s o n n e p = new P e r s o n n e ( " Dupont " , " J u l i e n " ) ;
p . o r g a n i s e r S c r u t i n ( " E l e c t i o n ␣ bde " ) ;
P e r s o n n e p1 = p . c l o n e ( ) ;
i f ( p1 == p ) {
System . o u t . p r i n t l n ( " p␣==␣ p1 " ) ;
}
i f ( p . getNom ( ) == p1 . getNom ( ) ) {
System . o u t . p r i n t l n ( " p␣ e t ␣ p1 ␣noms␣==" ) ;
}
i f ( p . getPrenom ( ) == p1 . getPrenom ( ) ) {
System . o u t . p r i n t l n ( " p␣ e t ␣ p1 ␣ prenoms ␣==" ) ;
}
A r r a y L i s t <S c r u t i n > a1 , a2 ;
a1 = p . g e t S c r u t i n s ( ) ;
a2 = p1 . g e t S c r u t i n s ( ) ;
i f ( a1 == a2 ) {
System . o u t . p r i n t l n ( " p␣ e t ␣ p1 ␣ s c r u t i n s ␣==" ) ;
} else {
&
%
258
'
for ( int
25
System . o u t . p r i n t l n ( " S c r u t i n ␣ de ␣ r a n g ␣ " + i +" ␣==" ) ;
27
}
28
}
29
}
30
}
31
32
i ++){
i f ( a1 . g e t ( i ) == a2 . g e t ( i ) ) {
26
# 148
i = 0 ; i < a1 . s i z e ( ) ;
$
}
p et p1 noms ==
p et p1 prenoms ==
p et p1 scrutins ==
&
%
Dans cet exemple, la classe Personne implémente l’interface Clonable en réalisant le clonage par l’utilisation de la méthode clone héritée de la classe Object. L’objet obtenu est bien distinct de l’objet initial.
Par contre, les objets référencés par les deux objets, à savoir le nom, le prénom et le tableau de Scrutin
n’ont pas été dupliqués et donc ils sont partagés par les deux objets de type Personne.
'
$
8.1.4 Représentation graphique d’une copie plus profonde dans
studs
# 149
&
%
259
'
$
8.1.5 Copie plus profonde dans studs
1
2
package s t u d s c l o n e d e e p ;
3
4
5
6
7
8
9
# 150
10
11
12
13
14
15
16
17
18
19
20
21
22
p u b l i c Personne ( f i n a l S t r i n g n , f i n a l S t r i n g p ) {
t h i s . nom = n ;
t h i s . prenom = p ;
s c r u t i n s = new A r r a y L i s t <S c r u t i n > ( ) ;
}
S c r u t i n s = new S c r u t i n ( nom , t h i s ) ;
s c r u t i n s . add ( s ) ;
nbOrg ++;
return s ;
}
/∗ ∗ l e c l o n a g e e s t p r o f o n d , i l d u p l i q u e l e s o b j e t s r e f e r e n c e s ∗/
@SuppressWarnings ( " unchecked " )
@Override
&
%
'
$
P e r s o n n e c l o n e = new P e r s o n n e ( nom , prenom ) ;
clone . nbParticipations = nbParticipations ;
c l o n e . nbOrg = nbOrg ;
c l o n e . s c r u t i n s = ( A r r a y L i s t <S c r u t i n >) s c r u t i n s . c l o n e ( ) ;
return clone ;
}
p u b l i c void v o t e r ( f i n a l B u l l e t i n b ){ }
23
24
25
26
27
28
29
30
31
32
33
# 151
34
35
36
1
}
2
3
4
5
6
7
8
9
import s t u d s c l o n e d e e p . S c r u t i n ;
import s t u d s c l o n e d e e p . Personne ;
p u b l i c c l a s s TestCloneDeep {
p . o r g a n i s e r S c r u t i n ( " E l e c t i o n ␣ bde " ) ;
&
%
260
'
10
11
12
13
14
15
16
17
18
19
20
# 152
21
22
23
24
25
26
27
28
29
30
31
32
33
&
i f ( p1 == p ) {
}
}
}
a1 = p . g e t S c r u t i n s ( ) ;
a2 = p1 . g e t S c r u t i n s ( ) ;
i f ( a1 == a2 ) {
} else {
f o r ( i n t i = 0 ; i < a1 . s i z e ( ) ; i ++) {
i f ( a1 . g e t ( i ) == a2 . g e t ( i ) ) {
System . o u t . p r i n t l n ( " S c r u t i n s ␣ de ␣ r a n g ␣ " + i +" ␣==" ) ;
} else {
i f ( a1 . g e t ( i ) . g e t O r g a n i s a t e u r ( ) == a2 . g e t ( i ) . g e t O r g a n i s a t e u r ( ) ) {
System . o u t . p r i n t l n ( " O r a g a n i s a t e u r ␣ d e s ␣ s c r u t i n s ␣ de ␣ r a n g " + i +"==" ) ;
}
}
%
'
$
}
34
# 153
}
35
}
36
37
$
}
&
%
Scrutins de rang 0 ==
261
'
$
8.1.6 Représentation graphique d’une copie profonde
# 154
&
%
'
$
8.1.7 Clone de Scrutin
1
2
3
4
5
6
7
8
9
# 155
10
11
12
13
14
15
16
17
18
19
20
21
22
package s t u d s c l o n e ;
p u b l i c c l a s s S c r u t i n implements C l o n e a b l e {
p r i v a t e Personne o r g a n i s a t e u r ;
p r i v a t e S t r i n g nomScrutin ;
p u b l i c S c r u t i n ( f i n a l S t r i n g nom , f i n a l P e r s o n n e o r g a n i s a t e u r ) {
n o m S c r u t i n = nom ;
this . organisateur = organisateur ;
}
/∗ ∗ l e c l o n a g e d u p l i q u e l e nom m a i s ne p e u t p a s m o d i f i e r l ’ o r g a n i s a t e u r .
∗ En e f f e t l e c l o n a g e de l ’ o r g a n i s a t i o n c l o n e l e s s c r u t i n s qu ’ i l a
∗ o r g a n i s Ã ľ e t n o u s e n t r e r i o n s d a n s une c a s c a d e d ’ a p p e l s i n f i n i e
∗ ∗/
@Override
p u b l i c S c r u t i n c l o n e ( ) throws CloneNotSupportedException {
r e t u r n new S c r u t i n ( new S t r i n g ( n o m S c r u t i n ) , o r g a n i s a t e u r ) ;
}
/∗ ∗ Methode p o u r m o d i f i e r l ’ o r g a n i s a t e u r en c a s de c l o n a g e . ∗/
void s e t O r g a n i s a t e u r ( f i n a l Personne norg ) {
o r g a n i s a t e u r = norg ;
}
p u b l i c Personne g e t O r g a n i s a t e u r () {
return organisateur ;
&
%
262
'
# 156
}
23
24
$
}
&
%
Scrutin contient deux attributs, une chaîne de caractères qui est clonable, et une référence sur l’organisateur du Scrutin. La méthode clone est définie entre les lignes 11 et 13. Elle fait appel à la méthode clone
de la classe Object qui duplique les attributs de l’objet dans le clone.
Nous voulons aussi que le clone du Scrutin puisse être associé avec la Personne lorsque celui-ci aura été
clonée. Pour cela, nous introduisons la méthode setOrganisateur().
'
$
8.1.8 Clone en copie profonde de Personne
1
2
3
4
5
6
7
8
9
# 157
10
11
12
13
14
15
16
17
18
19
20
21
22
package s t u d s c l o n e ;
import s t u d s a b s t r a c t . B u l l e t i n ;
p u b l i c Personne ( f i n a l S t r i n g n , f i n a l S t r i n g p ) {
t h i s . nom = n ;
t h i s . prenom = p ;
s c r u t i n s = new A r r a y L i s t <S c r u t i n > ( ) ;
}
S c r u t i n s = new S c r u t i n ( nom , t h i s ) ;
s c r u t i n s . add ( s ) ;
nbOrg ++;
return s ;
}
/∗ ∗ l e c l o n a g e e s t p r o f o n d , i l d u p l i q u e l e s o b j e t s r e f e r e n c e s .
∗ Ce n ’ e s t p a s n Ã ľ c e s s a i r e p o u r l e s o b j e t s du t y p e S t r i n g
∗ du f a i t qu ’ un S t r i n g e s t non m o d i f i a b l e .
∗/
&
%
263
'
23
@Override
24
25
P e r s o n n e c l = new P e r s o n n e ( nom , prenom ) ;
26
cl . nbParticipations = nbParticipations ;
27
c l . nbOrg = nbOrg ;
28
for ( Scrutin scr : scrutins ) {
29
Scrutin sclone = scr . clone ( ) ;
30
sclone . setOrganisateur ( cl );
c l . s c r u t i n s . add ( s c l o n e ) ;
31
# 158
$
}
32
return cl ;
33
34
}
35
36
37
38
39
40
41
B u l l e t i n b ){ }
}
&
%
Pour ce qui est de la personne, nous voulons la cloner et elle contient une liste des scrutins qu’elle a
organisés. Il faut donc que nous dupliquions cette liste, ce qui est possible puisqu’elle implémente l’interface
Cloneable. Il faut, cependant que la duplication soit profonde c’est-à-dire que nous dupliquions les entrées
de la liste.
Cette duplication profonde, commence par cloner l’objet courant. Pour cela elle crée un objet copie par
appel d’un constructeur à la ligne 23, auquel elle passe les paramètres nom et prenom. Elle modifie ensuite
les attributs nbOrg et nbParticipations en y mettant les valeurs des attributs correspondant dans l’objet
courant. Ensuite, à la ligne 25, la méthode parcourt les scrutins un à un. Pour chaque scrutin, un clone du
scrutin est construit à la ligne 26. L’organisateur de ce scrutin cloné est associé avec la personne en cours de
clonage par la méthode setOrganisateur.
$
'
8.1.9 Suite exemple de copie profonde
1
2
3
4
5
6
7
8
9
# 159
10
11
12
13
14
15
16
17
18
19
20
21
22
import s t u d s c l o n e . ∗ ;
publi c c l a s s TestClone {
p . o r g a n i s e r S c r u t i n ( " E l e c t i o n ␣ bde ␣ 2010 " ) ;
i f ( p1 == p ) {
}
}
}
a1 = p . g e t S c r u t i n s ( ) ;
a2 = p1 . g e t S c r u t i n s ( ) ;
i f ( a1 == a2 ) {
&
%
264
'
23
} else {
24
for ( int
25
i = 0 ; i < a1 . s i z e ( ) ;
System . o u t . p r i n t l n ( " S c r u t i n s ␣ de ␣ r a n g ␣ " + i +" ␣==" ) ;
27
} else {
28
i f ( a1 . g e t ( i ) . g e t O r g a n i s a t e u r ( ) == a2 . g e t ( i ) . g e t O r g a n i s a t e u r ( ) ) {
29
System . o u t . p r i n t l n ( " O r a g a n i s a t e u r ␣ d e s ␣ s c r u t i n s ␣ de ␣ r a n g " + i +"==" ) ;
30
}
31
}
32
}
33
}
34
}
35
36
i ++) {
i f ( a1 . g e t ( i ) == a2 . g e t ( i ) ) {
26
# 160
$
}
&
%
La trace d’exécution, montre maintenant que tout est cloné correctement.
$
'
8.2 Retour sur hashCode()
Méthode facilitant l’utilisation de Hashtable
Contrat de base :
# 161
Doit retourner la même valeur lorsqu’elle est appelée plusieurs fois sur le même
objet
Doit retourner la même valeur pour deux objets equals
Peut retourner la même valeur pour deux objets différents (limites du hachage)
Algorithme de J. Bloch dans Effective Java
&
%
Cette méthode est destinée à faciliter l’usage des tables hachage. Le contrat de base de cette méthode
est le suivant :
• si elle est invoquée deux fois sur le même objet, elle doit retourner la même valeur, cela bien sûr
uniquement si aucun des attributs utilisés pour la méthode equals() n’a été changé entre les deux
appels ;
• elle doit retourner la même valeur pour deux objets égaux selon la méthode equals ;
• il n’est pas obligatoire que deux objets différents selon la méthode equals retournent des valeurs de
hashCode différentes ;
265
• nous utiliserons l’algorithme le plus populaire. Cet algorithme a été proposé par J. Bloch dans Effective
Java (Addison-Wesley 2001). En voici la transcription :
– partir d’une valeur prédéfinie (si possible un nombre premier), par exemple 17, stockée dans une
variable de type int appelée result ;
– pour chaque attribut significatif de la classe que nous appelons f (un attribut est significatif s’il
est pris en compte par equals()) :
∗ calculer une valeur entière appelée c de hashCode() selon le type de f.
∗ combiner la valeur entière de result avec la valeur obtenue selon l’expression suivante :
result = 31 * result + c .
– retourner la valeur lorsque tous les attributs significatifs ont été traités.
La génération automatique des méthodes equals et hashCode sera réalisée pendant les séances de travaux
pratiques.
'
$
8.2.1 Exemple hashCode
1
2
3
4
5
6
7
8
9
# 162
10
11
12
13
14
15
16
17
18
19
20
21
package s t u d s e q u a l s ;
}
@Override
p u b l i c boolean e q u a l s ( Object obj ) {
i f ( t h i s == o b j ) r e t u r n t r u e ;
i f ( o b j == n u l l ) r e t u r n f a l s e ;
i f ( ! ( obj i n s t a n c e o f Personne )) return f a l s e ;
Personne other = ( Personne ) obj ;
i f ( nom == n u l l ) {
i f ( o t h e r . nom != n u l l ) r e t u r n f a l s e ;
} e l s e i f ( ! nom . e q u a l s ( o t h e r . nom ) ) r e t u r n f a l s e ;
i f ( prenom == n u l l ) {
i f ( o t h e r . prenom != n u l l )
return false ;
} e l s e i f ( ! prenom . e q u a l s ( o t h e r . prenom ) ) r e t u r n f a l s e ;
return true ;
}
}
&
%
266
'
8.3 Retour sur les exceptions
$
1
p u b l i c c l a s s NumException e x t e n d s E x c e p t i o n {
private static
3
p u b l i c NumException ( f i n a l d o u b l e v a l e u r ,
final
}
5
6
}
1
p u b l i c c l a s s N u l l E x c e p t i o n e x t e n d s NumException {
f i n a l l o n g s e r i a l V e r s i o n U I D = 1L ;
2
private static
3
public NullException () {
s u p e r ( 0 , " V a l e u r ␣ n u l l e ␣ non ␣ a t t e n d u e " ) ;
4
}
5
6
String s ) {
super ( s + "␣ v a l e u r ␣ : ␣" + v a l e u r ) ;
4
# 163
f i n a l l o n g s e r i a l V e r s i o n U I D = 1L ;
2
}
&
%
Nous reprenons la classe NumException et nous définissons aussi une version dérivée de celle-ci appelée
NullException. Cette exception est destinée à être levée lorsqu’un argument est null alors qu’il ne devrait
pas l’être.
$
'
8.3.1 Test des exceptions
1
2
3
4
5
6
7
8
9
# 164
10
11
12
13
14
15
16
17
18
19
20
21
22
public class TestExceptInHerit {
/∗ ∗
∗ Methode v e r i f i a n t qu ’ une v a l e u r e s t p o s i t i v e .
∗ @return valeur d ’ entree
∗ @t hro ws NumException s i v a l e u r n e g a t i v e
∗ @t hro ws N u l l E x c e p t i o n s i v a l e u r e g a l e a z e r o .
∗/
p r i v a t e s t a t i c double p o s i t i f O u N u l l ( f i n a l double v a l )
t h r o w s NumException , N u l l E x c e p t i o n {
i f ( val < 0.0) {
throw new NumException ( v a l , " P o s i t i f O u N u l l ␣ v a l e u r ␣ p o s i t i v e ␣ a t t e n d u e . " ) ;
}
i f ( v a l == 0 . 0 ) {
throw new N u l l E x c e p t i o n ( ) ;
}
return val ;
}
/∗ ∗
∗ traitement p a r t i e l d ’ exception les exceptions
∗ N u l l E x c e p t i o n s o n t t r a i t e e s , l e s e x c e p t i o n s NumException
∗ sont t r a i t e e s p a r t i e l l e m e n t et r e l a y e e s .
&
%
267
'
∗ @t hro ws NumException
∗/
p r i v a t e s t a t i c void t e s t P o s i t i f O u N u l l ( f i n a l double v a l )
t h r o w s NumException {
d o u b l e d =0;
System . o u t . p r i n t l n ( " Dans ␣ t e s t P o s i t i f O u N u l l ␣ v a l ␣=␣ "+v a l ) ;
try {
d = positifOuNull ( val );
System . o u t . p r i n t l n ( " Pas ␣d ’ e x c e p t i o n ␣ l e ␣ c o d e ␣ c o n t i n u e ␣ en ␣ s e q u e n c e " ) ;
} c a t c h ( N u l l E x c e p t i o n m) {
System . o u t . p r i n t l n ( " Catch ␣ N u l l E x c e p t i o n ␣ d a n s ␣ t e s t P o s i t i f O u N u l l ␣ " + m) ;
throw m;
} c a t c h ( NumException m) {
System . o u t . p r i n t l n ( " Catch ␣ NumException ␣ d a n s ␣ t e s t P o s i t i f O u N u l l ␣ "
+ " t r a i t e m e n t ␣ p a r t i e l ␣ e t ␣ r e l a i s " + m) ;
throw m;
}
finally {
System . o u t . p r i n t l n ( " Dans ␣ l e ␣ f i n a l l y ␣ de ␣ t e s t P o s i t i f O u N u l l ␣ " + d ) ;
}
}
p u b l i c s t a t i c v o i d main ( f i n a l S t r i n g [ ] a r g s ) {
int j = 0;
23
24
25
26
27
28
29
30
31
32
33
# 165
34
35
36
37
38
39
40
41
42
43
44
45
46
&
%
'
$
f o r ( S t r i n g oneArg : a r g s ) {
47
try {
48
j = I n t e g e r . p a r s e I n t ( oneArg ) ;
49
testPositifOuNull ( j );
50
51
System . o u t . p r i n t l n ( " P a r a m e t e r ␣ " + oneArg
52
# 166
$
+ " ␣ s h o u l d ␣ be ␣ an ␣ i n t e g e r " ) ;
53
} c a t c h ( NumException n ) {
54
System . o u t . p r i n t l n ( " Catch ␣ d a n s ␣ l e ␣ main ␣ " + n ) ;
55
}
56
}
57
}
58
59
}
&
%
268
'
$
L’exécution de ce programme avec les arguments du main 2 0 -2 donne l’affichage
suivant :
# 167
Dans testPositifOuNull val = 2.0
Dans le finally de testPositifOuNull 2.0
Dans testPositifOuNull val = 0.0
Catch NullException dans testPositifOuNull NullException:
Valeur nulle non attendue valeur reçue : 0.0
Catch dans le main NullException: Valeur nulle non attendue valeur reçue : 0.0
Dans testPositifOuNull val = -2.0
Catch NumException dans testPositifOuNull traitement partiel et relaisNumException:
PositifOuNull valeur positive attendue. valeur reçue : -2.0
Catch dans le main NumException: PositifOuNull valeur positive attendue. valeur reçue : -2.0
&
%
La méthode Positif lève deux exceptions suivant la valeur de l’argument qui lui est passé. Elle lève
l’exception de type NumException lorsqu’elle reçoit un argument dont la valeur est inférieure à zéro. Elle
lève l’exception de type NullException lorsqu’elle reçoit un argument égal à 0.
Le méthode testPositif réalise un appel à la méthode Positif et réagit lorsque cette dernière lève une
exception. Lorsque l’exception est de type NullException la méthode testPositif traite cette exception
et se termine. Il est aussi possible de récupérer une exception, dans notre cas NumException, de réaliser un
traitement puis de la retransmettre en utilisant l’instruction throw.
Vous noterez que le bloc finally est exécuté dans tous les cas, c’est-à-dire, qu’il y ait exception ou pas,
et que l’exception soit traitée ou pas.
'
$
8.3.2 RuntimeException
# 168
&
%
Les exceptions qui sont dérivées de l’exception RunTimeException sont exemptes de la vérification à la
compilation. Ceci permet au programmeur de ne pas encadrer les sections qui risquent de lever ces exceptions
269
dans des try...catch.
270
'
$
Bibliographie
[Armstrong, 2006] Armstrong, D. J. (2006). The quarks of object-oriented
development. Communication of the ACM, 49(2) :123–128.
# 169
[Knuth, 1973] Knuth, D. E. (1973). The Art of Computer Programming, volume 3. :
sorting and searching. Addison-Wesley Publishing Company, Inc.
[Maurer and Lewis, 1975] Maurer, W. D. and Lewis, T. G. (1975). Hash table methods.
ACM Computing Survey, 7(1) :5–19.
&
%
271
272
273
J.-Paul Gibson
Revision : 1527
CSC 4002
Octobre 2015
274
Télécom SudParis — J.-Paul Gibson — Octobre 2015 — CSC 4002
275
J. Paul Gibson
[email protected]
http://www-public.telecom-sudparis.eu/~gibson/
Bureau A 207, Le département LOgiciels-Réseaux
Thanks to: Christian Bac, Denis Conan & Jean-Luc Raffy
2014/2015
Dr J Paul Gibson, TSP
CSC4002-Tests.1
276
I.Rappels sur les tests
Le cycle en V
préparation
Spécification
Validation
Codage et
exécution
préparation
Conception préliminaire
Tests d’intégration
Codage et
exécution
préparation
Conception détaillée
Tests unitaires
Codage et exécution
Codage (système et tests)
2014/2015
CSC4002-Tests.2
277
II. Comment utiliser les modèles OO en UML?
III. Étude de cas – médiathèque
A) Préparation
Tests de validation
Tests unitaires
B) Codage et Exécution
Tests unitaires avec Junit
Tests de validation
2014/2015
CSC4002-Tests.3
278
Testing Consistency (not uniquely OO)
We need consistency between documentation/models:
•
•
•
•
Natural Language Text (English/French)
(UML) models
(Java) Code
Comments in (Java) Code
Develop tests in parallel with code to avoid inconsistency
NOTE: testing after all the code is developed is usually a bad
idea, but it is better than no testing at all!
2014/2015
CSC4002-Tests.4
279
Niveaux de test - pour chaque (sous)système
•
Tests de validation
•
•
Tests unitaires
Système
P
r
é
p
a
r
a
t
i
o
n
e
x
é
c
u
t
i
o
n
Sous-système
2014/2015
CSC4002-Tests.5
280
UML – les diagrammes
Spécification
Diagramme des cas d’utilisation
–
Tests de validation
Niveau Sous-Système (Analyse et conception)
•
test des associations, des agrégations (diagramme de classes)
•
test de séquences (diagramme de séquence et de communications)
•
test des exceptions contrȏlées
–
–
Diagramme des classes (ébauche)
–
Diagrammes de séquence/communications
–
Classes détaillées
–
Diagrammes de machine à états
2014/2015
Tests unitaires
CSC4002-Tests.6
281
II. (OO) modeles en UML
How to Use UML
Tests should be derived from the requirements
specification (in UML).
The UML diagrams should help us because:
•
•
2014/2015
provided the UML is validated we have a good
chance of testing the system against what is
required
the structure of the UML should correspond to the
structure of the developed code, so we can re-use
this design structure to structure our tests.
CSC4002-Tests.7
282
II. (OO) modeles en
UML
Validation
Use Case Diagrams – for each use case examine possible scenarios, and choose
a subset of alternative paths for testing. For example:
Use case1
Use case2
Use case3
Use case4
2014/2015
CSC4002-Tests.8
283
Integration : composition tree
II. (OO) modeles en
UML
The test sequence can be decided by looking at the tree-like structure of
composition hierarchies. For example:
Système
Composition tree
Big Bang Testing : all at once at the system interface
Top-Down Testing : does not require all lower level components to be complete
Bottom-Up Testing : does not require all higher level components to be complete
2014/2015
CSC4002-Tests.9
284
II. (OO) modeles en
UML
Les tests unitaires
•
•
•
Il faut tester les invariants de chaque classe
Il faut tester la fonctionnalité de chaque méthode de
chaque classe
Des classes avec des contraintes séquencielles sur
l’activation des méthodes et leurs clients peuvent avoir des
erreurs de séquencement.
=> Le comportement requis doit être testé en utilisant un
modèle de machine à états
2014/2015
CSC4002-Tests.10
285
III. Etude de cas
Comment Tester la Médiathèque?
A) Préparation
1. Tests de validation, e.g.: Emprunter
2. Tests d’intégration, e.g.: Emprunter
3. Tests unitaires, e.g.: Document
Présentation
Séquence
1st
3rd
5th
4. Tests unitaires avec JUnit
5. Tests d’intégration
6. Tests de validation
6th
4th
2nd
2014/2015
CSC4002-Tests.11
286
III. Etude de cas
Comment Tester la Médiathèque?
Préparation
1.
2.
3.
Tests de validation, eg:
Emprunter
Tests d’intégration, eg:
Emprunter
Tests unitaire, eg:
Document
4.
Tests unitaire avec JUnit
5.
6.
Tests de validation
2014/2015
CSC4002-Tests.12
287
III. Etude de cas – Préparation Tests de Validation
Emprunter
A validation test is a black box test
- usually done by the client - that
validates the (partial) behaviour of
the whole system.
The UML use case diagrams help
us to identify good candidates for
validation tests.
We will test the emprunter
functionality
2014/2015
CSC4002-Tests.13
288
Emprunter
Données d’entrée
client: peut être inscrit ou non;
emprunts: déja effectués par le client
• existe-t-il un emprunt en retard ?
• le nombre de documents empruntés correspond-il au nombre
maximum de ce client ?
document:
●
existe?
• empruntable ou consultable?
• déjà emprunté ou disponible?
2014/2015
CSC4002-Tests.14
289
Emprunter
Données de sortie
Emprunt accepté ou refusé.
Remarque: la définition des jeux de tests de validation pour le cas
d’utilisation emprunter document permet de soulever au moins les
questions suivantes (à poser au client):
• un abonné qui n’est pas à jour de sa cotisation peut-il tout de même
emprunter un document?
• doit-il être considéré comme un client au tarif normal tant qu’il n’a pas
renouvelé son abonnement?
• ou doit-il se réabonner avant de pouvoir emprunter un document?
D’une manière générale, la préparation des jeux de tests de validation
permet de lever les ambiguïtés et les vides de la spécification.
NOTE : Plus les tests sont préparés tôt et moins les corrections
coûtent chères
2014/2015
CSC4002-Tests.15
290
Emprunter
Table de décisions
2014/2015
CSC4002-Tests.16
291
Emprunter
To illustrate the testing process, we will treat the first 2 test cases
Test 1 - Client n'est pas inscrit
Test Code Steps:
1.
2.
3.
4.
2014/2015
Intialise dummy Mediatheque
Check state of current Mediatheque (including statistics)
Attempt to « emprunter » a document for a client who does not exist
CSC4002-Tests.17
292
Emprunter
Test 2 - Client possède un emprunt qui est en retard
Test Code Steps:
1.
2.
3.
4.
5.
6.
Intialise dummy Mediatheque
Authorise « emprunter » of a document for a client
Advance the date so that the previous « emprunt » is now past its deadline
Attempt to « emprunter » by the same client before they return the
document that is past its deadline
2014/2015
CSC4002-Tests.18
293
III. Etude de cas
Comment Tester la Médiathèque ?
A)
Préparation
1)Tests de validation, e.g.: Emprunter
2)Tests d’intégration, e.g.: Emprunter
3)Tests unitaires, e.g.: Document
4)Tests unitaires avec JUnit
5)Tests d’intégration
6)Tests de validation
2014/2015
CSC4002-Tests.19
294
III. Etude de cas –Tests de Validation - Codage et Execution
Validation Tests
Even if our system is not yet completely developed, we can
write the code for the validation tests.
For this example, we will code the validation test as a JUnit
test on the mediatheque class.
NOTE: A validation of the overall system is often
known as an acceptance test; and can be thought
of as a system unit test.
2014/2015
CSC4002-Tests.20
295
Test 1 - Client n'est pas inscrit
/**
* Document TEST 1<br>
* Client n'est pas inscrit
*/
@Test (expected= OperationImpossible.class) // we expect an exception
public void clientPasInscrit( ) throws OperationImpossible,
InvariantBroken{
m1.emprunter("nom", "prenom", "Test_code1");
}
To see why we expect an exception we must look at the setup code
2014/2015
CSC4002-Tests.21
296
@Before
public void setUp() throws Exception {
// un test de validation est un test unitaire sur la classe Mediatheque
m1 = new Mediatheque("mediatheque test");
Genre g = new Genre("Test_nom1");
Localisation l = new Localisation("Test_salle1","Test_rayon1");
Document d1 = new Video("Test_code1",l, "Test_titre1", "Test_auteur1",
"Test_annee1" ,g, "Test_duree1", "Test_mentionLegale1");
Document d2 = new Video("Test_code2",l, "Test_titre2", "Test_auteur2",
"Test_annee2" ,g, "Test_duree2", "Test_mentionLegale2");
m1.ajouterDocument(d1); m1.metEmpruntable("Test_code1");
m1.ajouterDocument(d2); m1.metEmpruntable("Test_code2");
CategorieClient cat = new CategorieClient("Test_Cat1", 10, 1.5, 2.5, 3.5, true);
Client c1 = new Client("Test_Client_Nom1", "Test_Client_Prenom1",
"Test_Client_Address1",cat);
m1.inscrire(c1);
Client c2 = new Client("Test_Client_Nom2", "Test_Client_Prenom2",
"Test_Client_Address2",cat);
}
@After
public void tearDown() throws Exception {m1 = null;}
2014/2015
CSC4002-Tests.22
297
Test 2 - Client n'est pas sans retard
/**
* Document TEST 2<br>
* Client n'est pas sans retard
*/
@Test (expected= OperationImpossible.class) // we expect an exception
public void clientAvecRetard( ) throws OperationImpossible,
InvariantBroken{
m1.emprunter("nom1", "prenom1", "Test_code1");
Datutil.addAuJour(7);
Datutil.addAuJour(7);
m1.emprunter("nom1", "prenom1", "Test_code2");
}
2014/2015
CSC4002-Tests.23
298
III. Etude de cas
A)
Préparation
1.
2.
3.
Tests de validation, e.g.:
Emprunter
Tests d’intégration, eg:
Emprunter
Tests unitaires, e.g.:
Document
4.
Tests unitaires avec JUnit
5.
6.
Tests de validation
2014/2015
CSC4002-Tests.24
299
III. Etude de cas – Préparation Tests d’intégration
Emprunter
The operation « emprunter » requires co-ordination between the
•
•
•
•
client,
mediatheque,
document, and
ficheEmprunt
objects
We wish to verify that the traces (of communication) between the objects involved
in the collaboration, as specified in UML, are executed by the implementation (in
Java), following the specified temporal ordering.
These tests can be derived from the communications and/or sequence diagrams
…
2014/2015
CSC4002-Tests.25
300
Emprunter
In the communications diagram, the temporal order is specified by the
numbering
2014/2015
CSC4002-Tests.26
301
The co-ordination
between the
Client and the
Document:
Emprunter
1
2
3
4
5
6
6.1
6.2
6.2.1
6.3
6.3.1
6.4
6.4.1
6.5
6.6
6.6.1
2014/2015
Integration Test 1
An « emprunt » is not
authorised because the
document is not
« empruntable »
Integration Test 2
An « emprunt » is not
authorised because the
document is
« emprunté »
Integration Test 3
Emprunt is authorised
CSC4002-Tests.27
302
III. Etude de cas –Tests d’Integration - Codage et Execution
Emprunter
Integration Test1 - An « emprunt » is not authorised because the document is not
empruntable
•
Construct a document,and make it not Empruntable
•
Construct a client
•
Construct a FicheEmprunt for the client and document
•
Check that:
1.
the system handles the exceptional case in a meaningful way
2.
the client and document states/statistics have not been changed
2014/2015
CSC4002-Tests.28
303
Emprunter
Integration Test 2 Design: An « emprunt » is not authorised because the
document is « emprunté »
•
Construct a document, which is empruntable and emprunté
•
Construct a client
•
•
Check that:
1.
the system handles the exceptional case in a meaningful way
2.
the client and document states/statistics have not been changed
2014/2015
CSC4002-Tests.29
304
Emprunter
Integration Test 3: Emprunt is authorised
•
Construct a document, which is empruntable and not
emprunté
•
Construct a client
•
•
•
Check that the system handles the exceptional case in a meaningful
way
Check that:
1.
the tarif and duree des emprunts are as required
2.
the client and document states/statistics have been updated
as required
2014/2015
CSC4002-Tests.30
305
III. Etude de cas
A)
Préparation
1.
2.
3.
Emprunter
Tests d’intégration, e.g.:
Emprunter
Document
2014/2015
4.
5.
6.
Tests de validation
CSC4002-Tests.31
306
Emprunter
Integration Test1 Code: Verify correct co-ordination by FicheEmprunt
•
Construct a document, and make it Empruntable
•
Construct a client
•
•
•
using a dummy mediatheque
Check that the tarif and “duree des emprunts” values for
the FicheEmprunt are as required
Check that the client and document states have been
updated correctly
We should do the same for integration tests 2 and 3
2014/2015
CSC4002-Tests.32
307
Emprunter
Integration Tests: Typical/Example Development Status
For example:
Completed
Partial
Not yet
implemented
This requires further analysis
2014/2015
CSC4002-Tests.33
308
Emprunter
Integration Test 1
Analysis: it is too
soon, in this example,
to code the integration
tests
2014/2015
CSC4002-Tests.34
309
III. Etude de cas
A)
Préparation
1.
2.
3.
Emprunter
Tests d’intégration, e.g.:
Emprunter
Document
4.
Tests unitaires avec JUnit
5.
6.
Tests de validation
2014/2015
CSC4002-Tests.35
310
III. Etude de cas – Préparation Tests Unitaires
The Document class
We will use the following UML diagrams to « derive » our unit tests for the
Document class:
•
•
Class Diagrams
State machine diagrams
We may also need to use the original natural language text.
We should not have to examine the Java code Document.java, but can
just call the code using the Document.class file – this is blackbox
testing.
We may need access to the documentation for the code in order to
understand code properties that are not specified in the UML models.
NOTE: If documentation is poor then we will have to examine the code in
order to be able to guarantee that our tests compile and execute correctly.
2014/2015
CSC4002-Tests.36
311
The Document class
The high-level class diagram
can be partitioned so that we
abstract away from the classes
that are not directly
« connected » to the
Document
2014/2015
CSC4002-Tests.37
312
The Document class
We test only the public attributes
and operations/methods –
following the blackbox approach
We should first examine the
safety invariant … if it is not in
the UML model then we need to
add it.
2014/2015
CSC4002-Tests.38
313
The Document class
The invariant property is defined on
the attributes of the class in order to
say when a Document instance/object
is in a SAFE state, i.e. a state which is
meaningful/allowable.
Here, the invariant should « include »:
Emprunté => (empruntable
AND nbEmprunts >=0)
We should link this (invariant) requirement to the
original text, where possible:
« La médiathèque contient un certain nombre
de documents disponibles à la consultation ou à l’emprunt »
2014/2015
A formal
interpretation
that needs
validation with
the client
CSC4002-Tests.39
314
The Document class
BUT, these are not public
So we have a test design choice –
1) extend the Document class by adding a public invariant method:
•
(a) creating a new subclass (and make attributes protected), or
•
(b) editing/updating the Document class
OR
2) use public methods – directly in the testing code - that are equivalent to
testing the invariant and are guaranteed not to change the state of the object
(Document) being tested (e.g. estEmpruntable and estEmprunte.)
2014/2015
CSC4002-Tests.40
315
The Document class
All design decisions involve compromise.
QUESTION: Can you see the advantages/disadvantages of each option
for specifying the invariant property?
In this example, we choose to pursue option 1 (b) - Edit the
Document class, because •
•
2014/2015
It is good practice in OO development to have invariants
specified for all classes, and
It is the « simplest » coding option for « Java beginners »
CSC4002-Tests.41
316
Document
Now, let’s consider the dynamic behaviour specified by the state
machine. The first thing is that the initial state must be SAFE. Then we
check that all subsequent states are SAFE.
2014/2015
CSC4002-Tests.42
317
Document
Test1: check that the construction of a Document respects the invariant
1.
2.
3.
Create a DocumentTest class with a single main method for testing a
concrete instance of a Document subclass –
•
Video, or
•
Audio, or
•
Livre
Create a test method that gets called in the main method.
Ensure that the test can be checked –
•
output results to screen, or
•
print results to file, or
•
include test oracle code that knows what the results should be
and asserts these when the test executes, automating the test
process
2014/2015
CSC4002-Tests.43
318
Document
Test 2: Check all reachable states to be SAFE, i.e. respect the invariant
Code Design:
Complete state coverage can be
achieved by a single execution
trace after creation –
metEmpruntable()
emprunter()
NOTE: Testing all states respect the invariant does not check the correct
temporal behaviour of the Document class …We will see this problem later
with Test4
2014/2015
CSC4002-Tests.44
319
Document
We need to write at least one test for each public operation/method of the
Document class.
For conciseness, we illustrate this by looking at the single Emprunter
operation
« emprunter : … Pour tous les documents, les statistiques sont mises à
jour à savoir : le nombre d’emprunts de ce document, le nombre
d’emprunts de ce type de document et le nombre d’emprunts total »
Test3 - check statistics are updated correctly
Code design steps: « emprunt » a document 5 times and, each time,
check that the individual document « statistiques » are incremented. At the
end of the loop, check that the total « statistiques » have increased by 5.
2014/2015
CSC4002-Tests.45
320
Document
Test4: correct temporal sequencing
1.
2.
Check that we can only « restituer » a document after
it has been « emprunté »
Check that we can only « mettre en consultation » if
the document is « empruntable »
Code Design: such sequences of events should produce
exceptions
2014/2015
CSC4002-Tests.46
321
Document
Final Test
After testing all other important temporal properties of the Document
class, we should conclude the Document unit tests by testing how the
constructor method(s) behaves when one tries to construct a Document
using « invalid » component parameters. For example:
•
•
Null Genre or Localisation or …
UNSAFE Genre or Localisation or …
Final Test Java (code) design steps:
1.
2.
Attempt to construct a Document with a null Genre
Check that the exception is generated and handled as required
Note: some testers chose to do this test first
2014/2015
CSC4002-Tests.47
322
III. Etude de cas
A)
Préparation
1.
Tests de validation, e.g.: Emprunter
2.
Tests d’intégration, e.g.: Emprunter
3.
Tests unitaires, e.g.: Document
4.
5.
6.
2014/2015
Tests de validation
CSC4002-Tests.48
323
III. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Document
Coding step - Write code for invariant in Document
public boolean invariant (){
return !(emprunte && !empruntable)
2014/2015
&& nbEmprunts >=0;
CSC4002-Tests.49
324
Document
Coding step : Update all Document operations/methods that may change state
of a Document to check invariant and throw exception when it is broken.
Mediatheque –
metEmpruntable,
metConsultable
Audio – emprunter
Livre – emprunter
Video - emprunter
For example, metEmpruntable:
public void metEmpruntable() throws InvariantBroken{
empruntable = true;
if (!invariant())
throw new InvariantBroken("Document -"+this);
}
2014/2015
CSC4002-Tests.50
325
Document
Coding step - Update toString method to display if Document is SAFE or
UNSAFE (depending on whether invariant is respected)
public String toString() {
String s = "\"" + code + "\" " + titre + " " + auteur + " " + annee
+ " " + genre + " " + localisation + " " + nbEmprunts;
if (empruntable) {
s += " (emp ";
if (emprunte) s += "O";
else s += "N";
s += ")"; }
if (invariant()) s += " SAFE "; else s +=" UNSAFE ";
return s;
}
2014/2015
CSC4002-Tests.51
326
Using JUnit tool – assertions and failures
(see http://junit.org/javadoc/4.10/)
assertTrue(boolean)
assertFalse(boolean)
assertArrayEquals( _ , _ )
assertEquals( _ , _ )
assertNull(_)
assertSame( _ , _ )
fail()
fail(java.lang.String )
...
2014/2015
CSC4002-Tests.52
327
III. Etude de cas –Tests Unitaires- Codage et Execution Avec JUnit
Document
package mediatheque.document;
import
import
import
import
static org.junit.Assert.*;
org.junit.After;
org.junit.Before;
org.junit.Test;
import
import
import
import
mediatheque.Genre;
mediatheque.Localisation;
mediatheque.OperationImpossible;
util.InvariantBroken;
public class JUnit_Document {
protected Localisation l;
protected Genre g;
protected Document d1;
// setUP
method
// tearDown method
// test
methods
Annotation @Before
Annotation @After
Annotation @Test
}
2014/2015
CSC4002-Tests.53
328
Call Sequences : Simplest Case
The call sequence for a class with two test methods – test1 and test2 is:
Call @Before setUp
Call @Test method test1
Call @After tearDown
Call @Before setUp
Call @After tearDown
2014/2015
CSC4002-Tests.54
329
Call Sequences : More Complex Case
When setting up and tearing down is “expensive” then we can use
@BeforeClass and @AfterClass annotations/methods to ensure that these
are executed only once for each class.
For example, the call sequence for a class with two test methods – test1 and
test2 is:
Call @BeforeClass setUpClass
Call @AfterClass tearDownClass
(See the JUnit documentation for more details on call sequences when
we mix simple and complex cases)
Note: we use the simplest case in the following examples
2014/2015
CSC4002-Tests.55
330
Document
@Before
public void setUp() throws Exception{
g = new Genre("Test_nom1");
l = new Localisation("Test_salle1","Test_rayon1");
d1 = new Video ("Test_code1", l, "Test_titre1",
"Test-auteur1", "Test-annee1", g,
"Test_duree1", "Test-mentionLegale1");
}
@After
public void tearDown() throws Exception {
l=null; g=null; d1=null;
}
2014/2015
CSC4002-Tests.56
331
Document
Test1: check the construction of a Document respects the invariant
@Test
public void constructorInvariant( ) throws
OperationImpossible, InvariantBroken{
Assert.assertTrue(d1.invariant());
}
Test2: Check all reachable states to be SAFE, i.e. respect the invariant
@Test
public void reachableStates () throws OperationImpossible,
InvariantBroken {
d1.metEmpruntable();assertTrue(d1.invariant());
d1.emprunter();assertTrue(d1.invariant());
}
2014/2015
CSC4002-Tests.57
332
Document
Test4.1 : Check that we can only « restituer » a document after it has been
« emprunté »
@Test(expected=OperationImpossible.class)
public void restituerBeforeEmprunter () throws
OperationImpossible, InvariantBroken {
Assert.assertTrue(!d1.estEmprunte());
d1.restituer();
}
2014/2015
CSC4002-Tests.58
333
Document
Test4.1 : Check that we can only « restituer » a document after it has been
« emprunté »
JUnit shows us if an expected exception was not thrown
2014/2015
CSC4002-Tests.59
334
Document
Test4.1 : Check that we can only
« restituer » a document after it has
been « emprunté »
Q: restituer in states
consultable and empruntable?
Q: How to Fix This
OPTION 1: Update UML diagram with new transition(s)
OPTION 2: Update Document code
OPTION 3 … : Can You Think Of Any Other Options?
2014/2015
CSC4002-Tests.60
335
Document
Test4.1 : Check that we can only « restituer » a document after it
has been « emprunté »
restituer
restituer
OPTION 1: Update UML diagram
with new transition(s)
No longer require an exception to be thrown in consultable and
empruntable states when restituer is called
2014/2015
CSC4002-Tests.61
336
Document
Test4.1 : Check that we can only « restituer » a document after it
has been « emprunté »
OPTION 2: Update Document code
public void restituer() throws InvariantBroken, OperationImpossible{
if (!emprunte) throw new OperationImpossible("Document -"+this);
emprunte = false;
System.out.println("Document: ranger \"" + titre + "\" en " +
localisation);
if (!invariant())
throw new InvariantBroken("Document -"+this);
}
2014/2015
CSC4002-Tests.62
337
III. Etude de cas
Le cycle en V (terminé)
préparation
Spécification
Validation
Codage et
exécution
préparation
Conception préliminaire
Codage et
exécution
préparation
Tests unitaires
Codage et exécution
Codage (système et tests)
2014/2015
CSC4002-Tests.63
338
SOME MORE ADVANCED ISSUES
INHERITANCE
Inheritance complicates the testing process:
•
Should we also have a test inheritance hierarchy?
•
How do we test the subclassing relationship?
EXCEPTIONS
Exceptions complicate the testing process:
•
Exception handling testing requires generating the
exceptions and where/how this should be done is not
always obvious
GUIs are difficult to test as you often need to simulate user actions
2014/2015
CSC4002-Tests.64
339
To Come (In the TP)
Unit Tests – Document
Integration Tests – FicheEmprunt
Complete the validation tests : use case emprunter document
Unit tests on Document subclasses (using inheritance)
QUESTIONS?????
2014/2015
CSC4002-Tests.65
340
341
Claire Lecocq
Revision : 1527
CSC 4002
Octobre 2015
342
Télécom SudParis — Claire Lecocq — Octobre 2015 — CSC 4002
343
Gestion de la
persistance des objets
CSC4002
Claire Lecocq
Institut Mines-Télécom
Janvier 2014
344
Plan du document
1. Motivations
1. Application exemple : la médiathèque
2. Problématique en image
2. Quel schéma de Base de Données Relationnelle ?
3. Gérer la persistance dans Java : JDBC
4. Conclusion
2
Janvier 2014
345
Application exemple : la médiathèque
■ Développement orienté objet : standard de fait
■ Où sont stockées les données ?
● Durée de vie ?
● Partage ?
● Volume de données ?
■ Une idée ?
3
Janvier 2014
346
Problématique en image
Application
UML
Développement
Objet
Mapping
chargement

Stockage des données
déchargement
Modèle E/A
Relationnel
SGBD
4
Janvier 2014
347
Plan du document
1. Motivations
● Processus de conception d’une BD (rappel)
● Existe t-il un modèle relationnel pour un diagramme de
classes ?
● Diagramme de classes de la médiathèque
● Traduction du diagramme en dehors de l’arbre
d’héritage
● Héritage
− Revenons sur la sémantique de l’héritage1
− Traduction de l’héritage en modèle relationnel
4. Conclusion
1
5
la généralisation/spécialisation est appelée dans ce cours héritage
Janvier 2014
348
Processus de conception d’une BD
(rappel)
Besoin de la BD
Prise en compte
des
particularités du
SGBD
Contrat
Conception logique
Schéma conceptuel (haut niveau)
E/A UML
Indépendant du SGBD
Monde
réel
Recueil des besoins et analyse
Transformation du modèle
Relationnel
Réseau
Hiérarchique
Conception physique
Schéma physique (spécifique SGBD)
6
Placement
Disque
Optimisation
Spécifique à
un SGBD
Schéma conceptuel (spécifique SGBD)
Janvier 2014
349
Existe t-il un modèle relationnel pour un
diagramme de classes ?
■ Si
●
●
Hypothèse 1 : existe correspondance E/A  diagramme
de classes
Hypothèse 2 : existe traduction E/A  relationnel
−
−
Voir cours CSC4001 : Introduction aux BD relationnelles
Diapositives 13 et 14 pour la médiathèque
■ Alors
●
7
Transformer un diagramme de classes UML (partie
statique) en un schéma relationnel « équivalent » peut
se ramener à la transformation d’un schéma E/A vers un
schéma relationnel
Janvier 2014
350
Hypothèse 1 :
Correspondance E/A  diagramme de classes
SI-BD
Entité/Association
Génie logiciel - langages
Entité

Classe
Entité faible

Composition
Association sans attribut

Association
Association avec attribut(s)

Classe d’association
Pas de correspondance
Héritage – Généralisation,
spécialisation
Clé


Identité d’objet
Attribut calculé


8
Attribut dérivé
Opération
Cardinalités

Multiplicités
Attribut d’une entité de
paramètres

Attributs de classe
Janvier 2014
351
Hypothèse 1 :
Correspondance E/A  diagramme de classes
SI-BD
Entité/Association
Génie logiciel - langages
Entité

Classe
Entité faible

Composition
Association sans attribut

Association
Association avec attribut(s)

Classe d’association
Pas de correspondance
Héritage – Généralisation,
spécialisation
Clé


Identité d’objet

Attribut calculé

Problème
héritage
Attribut dérivé
Opération
Cardinalités

Multiplicités
Attribut d’une entité de
paramètres

Attributs de classe
9
Janvier 2014
352
Diagramme de classes de la médiathèque
10
Janvier 2014
353
Traduction du diagramme en dehors de
l’arbre d’héritage
■ Classe façade
11
Janvier 2014
354
■ Classes persistantes
12
Janvier 2014
355
Règles de traduction
■ Classe  entité
● Attribut d’instance  attribut d’entité
● Adapter au mieux les correspondances de types
● Définir la clé de l’entité
■ Association, agrégation  association
■ Composition  entité faible
■ Multiplicités  cardinalités
13
Janvier 2014
356
■ Modèle entité/association
Localisation
salle : varchar(20)
rayon : varchar(5)
Genre
nom : varchar(20)
nbEmprunts : integer
FicheEmprunt
dateEmprunt : date
dateLimite : date
depasse : integer
1,1
correspondre
0,n
Client
nom : varchar(20)
prenom : varchar(20)
adresse : varchar(20)
nbEmpruntsEffectues : integer
nbEmpruntsDepasses : integer 1,1
nbEmpruntsEnCours : integer
dateInscription : date
codeReduction : integer
dateRenouvellement : date
14
Categorie
nom : varchar(20)
nbEmpruntsMax : integer
tarifInscription : float
coefDuree : float
coefTarif : float
codeReducUsed : integer
0,n
appartenir
Janvier 2014
357
Hypothèse 2 : Traduction du diagramme
en dehors de l’arbre d’héritage
■ Modèle relationnel
Localisation
salle : varchar(20)
rayon : varchar(5)
Genre
nom : varchar(20)
FicheEmprunt
dateEmprunt
dateLimite
depasse
nom
prenom
Client
nom
prenom
adresse
nbEmpruntsEffectues
nbEmpruntsDepasses
nbEmpruntsEnCours
dateInscription
codeReduction
dateRenouvellement
catclient
15
Categorie
nom
nbEmpruntsMax
tarifInscription
coefDuree
coefTarif
codeReducUsed
Janvier 2014
358
Il reste la partie la plus intéressante :
l’arbre d’héritage !
Localisation
salle : varchar(20)
rayon : varchar(5)
Genre
nom : varchar(20)
FicheEmprunt
dateEmprunt
dateLimite
depasse
nom
prenom
Client
nom
prenom
adresse
nbEmpruntsEffectues
nbEmpruntsDepasses
nbEmpruntsEnCours
dateInscription
codeReduction
dateRenouvellement
catclient
16
Categorie
nom
nbEmpruntsMax
tarifInscription
coefDuree
coefTarif
codeReducUsed
Janvier 2014
359
Revenons sur la sémantique de l’héritage
(1)
■ Spécialisation peut
être :
Personne
nom
prénom
adresse
● Partielle* : une instance
peut ne pas être
spécialisée
Personne 
Etudiant  Salarie
Partielle
X
● Totale** : toute instance
est spécialisée dans au
moins une classe enfant
Etudiant
noEtud
cycle
Salarie
salaire
Totale
Prive
prime
Public
indice
Salarie = Prive  Public
Dans les cours UML et Java, les termes utilisés sont classes concrètes* et classes abstraites*
17
Janvier 2014
360
Revenons sur la sémantique de l’héritage
(2)
■ Spécialisation peut
être :
Personne
nom
prénom
adresse
● Recouvrement : une
instance peut être
spécialisée dans
plusieurs classes
enfants*
● Partition : une instance
est spécialisée dans au
plus une classe enfant
Etudiant  Salarié  
Recouvrement
Etudiant
noEtud
cycle
Salarie
salaire
Partition
Doctorant
vacataire
Prive
prime
Public
indice
Prive  Public = 
•Dans les cours UML et Java, l’héritage multiple a été ignoré pour raison de simplicité et
aussi parce que Java ne l’autorise pas (contrairement à C++)
18
Janvier 2014
361
Traduction de l’héritage en modèle
relationnel
■ 3 correspondances possibles :
1. Correspondance directe
2. Correspondance ascendante
3. Correspondance par aplatissement
3.1. Pour partition
3.2. Pour recouvrement
19
Janvier 2014
362
Correspondance directe (n° 1)
■ Une classe  une relation BD
■ Liaison entre les relations se fait via la clé
■ Correspondance de l’arbre de Document
Document
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
Création
d’une clé
Relation
clé
Audio
code
classification
Clé +
clé étrangère
20
Video
code
dureeFilm
mentionLegale
Contrainte
d’intégrité
référentielle
Livre
code
nbPages
Janvier 2014
363
Correspondance directe (n° 1) - suite
VueDocument
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
Typedoc
Classification
nombrePages
Durrefilm
Mentionlegale
Audio
code
classification
21
create view vueDocument(code, titre, auteur, annee,
empruntable, emprunte, salle,rayon,nomGenre,nbEmprunts,
typedoc, classification, nombrePages, dureeFilm, mentionLegale)
as
select document.code, titre, auteur, annee, empruntable,
emprunte, salle,rayon,nomGenre,nbEmprunts,'Audio',
classification, null, null, null
from audio, document
where audio.code = document.code
union
emprunte, salle,rayon,nomGenre,nbEmprunts,'Video', null, null,
dureeFilm, mentionLegale
from video, document
where video.code = document.code
union
emprunte, salle,rayon,nomGenre,nbEmprunts,'Livre', null,
nombrePages, null, null
from livre, document
where livre.code = document.code ;
Document
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
Video
code
dureeFilm
mentionLegale
Livre
code
nbPages
Relation
clé
Contrainte
d’intégrité
référentielle
Vue
Construction
de la vue
par requête
Janvier 2014
364
Correspondance directe pour la
médiathèque
VueDocument
code
titre
…
Audio
code
classification
Video
code
dureeFilm
mentionLegale
Livre
code
nbPages
Genre
nom
nbEmprunts
22
Document
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
nomGenre
salle
rayon
Localisation
salle
rayon
FicheEmprunt
nom
prenom
code
dateEmprunt
dateLimite
depasse
Client
nom
prenom
adresse
nbEmpruntsEffectues
nbEmpruntsDepasses
nbEmpruntsEnCours
catclient
dateInscription
codeReduction
dateRenouvellement
Categorie
nom
nbEmpruntsMax
tarifInscription
coefDuree
coefTarif
codeReducUsed
Solution retenue pour le TP
Janvier 2014
365
Correspondance directe et typologie des
arbres d’héritage
Spécialisation
23
Spécialisation
Totale
Partielle
Partition
Recouvrement
OK
Vérification : 1
tuple de la
« relation
parent » est
toujours
référencé par 1
tuple de la
« relation
enfant »
OK
OK
Vérification :
nonduplication de
clé entre
« relations
enfants »
OK
Remarques
 Reconstitution de
l'objet par jointure
 Sémantique très
proche du modèle
objet
 Fonctionne pour
tout arbre d’héritage
Janvier 2014
366
Correspondance ascendante (n° 2)
■ Chaque classe spécialisée  une relation BD
■ Classe parent  une vue
■ Correspondance de l’arbre de Document
Document
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
Audio
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
classification
24
Video
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
dureeFilm
mentionLegale
CREATE VIEW Document AS
SELECT code, titre, auteur, annee,
empruntable, emprunte, nbEmprunts
FROM Audio
UNION SELECT code, titre, auteur,
annee, empruntable, emprunte,
nbEmprunts FROM Video
UNION SELECT code, titre, auteur,
annee, empruntable, emprunte,
nbEmprunts FROM Livre
Livre
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
nbPages
Vue
Construction
de la vue
par requête
Janvier 2014
367
Correspondance ascendante pour la
médiathèque
■
Une vue n’est pas une relation BD !
● Pas de clé  non référençable par une clé étrangère
Document
code
25
Audio
code
FicheEmpruntAudio
code
nom
prenom
Video
code
FicheEmpruntVideo
code
nom
prenom
Livre
code
FicheEmpruntLivre
code
nom
prenom
Client
nom
prenom
FicheEmprunt
Janvier 2014
368
Correspondance ascendante et typologie
des arbres d’héritage
Spécialisation
Spécialisation
Totale
Partielle
Partition
Recouvrement
OK
KO
OK
KO
Redondance
de données
Remarques
 Multiplie les relations
 Évite les jointures pour reconstruire les
objets
 Spécialisation totale. Classe abstraite =
vue (relation virtuelle)
 Difficile d’assurer l’unicité des
identificateurs
26
Janvier 2014
369
Correspondance par aplatissement (n°
3.1)
■ Ensemble des classes de la hiérarchie  une seule
■
■
relation BD
Éventuellement chaque classe « enfant »  une vue
Correspondance de l’arbre de Document
Document
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
typeDocument
classification
dureeFilm
mentionLegale
nbPages
Audio
code
…
classification
27
Video
code
…
dureeFilm
mentionLegale
CREATE VIEW Audio AS
empruntable, emprunte, nbEmprunts,
classification
FROM Document
WHERE typeDocument=‘Audio’
Livre
code
…
nbPages
Janvier 2014
370
Correspondance par aplatissement 3.1
pour la médiathèque
Genre
nom
nbEmprunts
Localisation
salle
rayon
Document
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
nomGenre
salle
rayon
typeDocument
classification
dureeFilm
mentionLegale
nbPages
Client
nom
prenom
adresse
nbEmpruntsEffectues
nbEmpruntsDepasses
nbEmpruntsEnCours
typeClient
dateInscription
dateRenouvellement
codeReduction
FicheEmprunt
nom
prenom
code
dateEmprunt
dateLimite
depasse
dateCotisation
Categorie
nom
nbEmpruntsMax
tarifInscription
coefDuree
coefTarif
codeReducUsed
Solution retenue pour le TP
28
Janvier 2014
371
Correspondance par aplatissement 3.1 et
typologie des arbres d’héritage
Spécialisation
Spécialisation
Totale
Partielle
Partition
Recouvrement
OK
OK
Si attribut
donnant le
nom de la
classe
autorisé à
null
OK
KO
Remarques
 Évite les jointures pour reconstruire les
objets
 Du vide dans la relation (valeurs nulles)
 Spécialisation totale : classes abstraites
 relations (concrètes), classes concrètes
 vues (virtuelles)
 Souvent la solution la plus simple à
mettre en place; la plus choisie
29
Janvier 2014
372
Correspondance par aplatissement 3.2
pour la médiathèque
■ Variante de la correspondance 3.1 avec utilisation
■
d’un attribut booléen supplémentaire par classe
enfant
Si un document pouvait être à la fois un Audio et
une Vidéo
Document
code
titre
auteur
annee
empruntable
emprunte
nbEmprunts
AudioB
VideoB
LivreB
Classification
dureeFilm
mentionLegale
nbPages
30
CREATE VIEW Audio AS
empruntable, emprunte, nbEmprunts,
classification
FROM Document
WHERE AudioB = 1
Janvier 2014
373
Correspondance par aplatissement 3.2 et
typologie des arbres d’héritage
Spécialisation
31
Spécialisation
Remarques
Totale
Partielle
Partition
Recouvrement
OK
OK
Si tous les
attributs
booléens
correspondant
aux classes
enfants sont
autorisés à
FAUX/NULL
Non pertinent
3.1
OK
idem 3.1
Janvier 2014
374
QCM – Vrai ou faux
■ Y a t-il toujours un modèle relationnel
■
■
■
32
« correspondant » à un diagramme de classes ?
Le nombre de relations dans le modèle relationnel
est-il égal au nombre de classes dans le
diagramme de classes ?
Une classe abstraite est-elle toujours traduite par
une vue ?
S’il existe plusieurs modèles relationnels
« correspondant » à un diagramme de classes, je
choisis au hasard : il n’y a pas de critère de choix
?
Janvier 2014
375
Plan du document
1. Motivations
1. Qu’est ce que JDBC ?
2. Que faire pour pouvoir utiliser JDBC ?
3. Principaux objets mis en œuvre
1. Tuyaux de communication : Connection et Statement
2. Exécution d’une requête : ResultSet
3. Correspondance de type
1.
2.
Exemple sur les chaînes de caractères
Correspondance de type SQL/Java
4. Étapes d’interaction avec le SGBD
5. Politique de gestion de la persistance
4. Conclusion
33
Janvier 2014
376
Qu’est ce que JDBC ?
■
■
■
■
Java DataBase Connectivity
API Java pour accéder à des SGBDR via SQL
Indépendance / SGBD cible (via des pilotes)
Fourni par le paquetage java.sql
● Interfaces
● Implémentées dans les pilotes (en anglais, driver)
Application java
Pilote
− Dépendants des SGBDs cibles
− « Tout » SGBD a un pilote JDBC
Protocole
du SGBD
SGBD
34
Janvier 2014
377
Que faire pour pouvoir utiliser JDBC ?
■ Avoir un pilote
■ Le référencer dans le CLASSPATH
■ Dans chaque classe qui utilise des ordres JDBC
● Importer le paquetage java.sql
import java.sql.*;
● Charger en mémoire la classe du (des) pilote(s) avant
d’utiliser JDBC :
Class.forName("oracle.jdbc.OracleDriver");
Class.forName("com.mysql.jdbc.Driver" );
Class.forName("org.postgresql.Driver" );
35
Janvier 2014
378
Tuyaux de communication :
Classe Connection et Statement
Media : Mediatheque
Nom : string
….
Connection : @Connection
Constructeur()
rechercheBD()
miseAJourBD()
Destructeur()
36
Pilote PostgreSQL
Application java
Statement statement1
« SELECT * FROM Document »
SGBD
PostgresSQL
Janvier 2014
379
Exécution d’une requête :
Classe ResultSet
Application java
Nom : string
….
lesLocalisations: collection
de @Localisation
37
Pilote MySQL
media : Mediatheque
Statement stmt1
ResultSet rset =
stmt1.executeQuery
("select * from
localisation");
SGBD
PostgresSQL
Localisation
Janvier 2014
380
Correspondance de types :
Exemple sur les chaînes de caractères
Application java
Statement stmt1
rset contient
"select * from localisation";
while (rset.next()) {
…
String salle =
rset.getString("salle");
…
}
String salle
38
SGBD
PostgresSQL
Localisation
salle :
varchar(20)
Janvier 2014
381
Correspondance de type SQL/Java (1)
Type SQL
numeric
integer
float
char, varchar
date
39
Méthode recommandée
Java.Math.BigDecimal getBigDecimal()
int getInt()
double getDouble()
String getString()
java.sql.Date getDate()  java.util.Date
Janvier 2014
382
Correspondance de type SQL/Java (2)
■ Pas de booléen en bases de données !
■ Document :
■ empruntable et emprunte : boolean dans le
■
diagramme de classe
empruntable et emprunte : integer dans la base
de données
ResultSet rset = stmt.executeQuery("select * from
document");
while (rset.next()) {
…
boolean empruntable =
rset.getInt("empruntable") > 0;
boolean emprunte = rset.getInt("emprunte") >
0;
…
}
40
Janvier 2014
383
Étapes d’interaction avec le SGBD
1. Ouvrir une connexion
●
Instance de Connection
2. Créer des « fils » pour supporter l’envoi d’instructions SQL
au sein de la connexion
● Requête non paramétrée dans une instance de
Statement
● Requête paramétrée dans une instance de
PreparedStatement
INSERT INTO localisation (salle, rayon) values (?,
?)
3. Demander l’exécution de ces instructions par le SGBD :
●
Requête d’interrogation (SELECT) : méthode
executeQuery() sur le *Statement
● Requête de mise à jour (INSERT, UPDATE, DELETE) :
méthode executeUpdate() sur le *Statement
4. Fermer la connexion : méthode close() sur la connexion
41
Janvier 2014
384
1. Établir une connexion
String driver = "org.postgresql.Driver";
String urlBd = "jdbc:postgresql://mysql-inf/TPCONCEPTION";
try {
Class.forName(driver).newInstance();
}catch(Exception cnfe) {
throw new OperationImpossible("Echec acces Pilote BD- " +
driver + " " + cnfe);
}
Statement stmt = null;
try {
laConnexion =
DriverManager.getConnection(urlBd,compte,passe);
} catch(SQLException qe) {
throw new OperationImpossible("Echec connexion BD- " + qe
+ " " + urlBD);
}
2012
385
2 et 3. Exécuter une requête de mise à
jour (1)
private void insererBD(Document doc) throws
OperationImpossible {
try {
PreparedStatement stmt;
if (doc instanceof Audio ){
Audio au = (Audio) doc;
stmt = laConnexion.prepareStatement("INSERT INTO
document (code, titre, auteur, annee, empruntable,
emprunte, salle, rayon, nomgenre, nbemprunts,
typedoc, classification) values (?, ?, ?, ?, ?, ?,
?, ?, ?, ?, 'Audio', ?)");
stmt.setString(11, au.getClassification());
} else {
// Video puis Livre
}
43
Janvier 2014
386
2 et 3. Exécuter une requête de mise à
jour (2)
stmt.setString(1, doc.getCode());
stmt.setString(2, doc.getTitre());
stmt.setString(3, doc.getAuteur());
stmt.setString(4, doc.getAnnee());
stmt.setInt(5,doc.estEmpruntable()?1:0);
stmt.setInt(6, doc.estEmprunte()?1:0);
stmt.setString(7, doc.getLocalisation().getSalle());
stmt.setString(8, doc.getLocalisation().getRayon());
stmt.setString(9, doc.getGenre().getNom());
stmt.setInt(10, doc.getNbEmprunts())
} catch (SQLException e) {
throw new OperationImpossible("Echec insertion
" + e);
}
}
44
BD-
Janvier 2014
387
QCM - Vrai/faux
■ Puis-je me passer de « driver » pour interagir avec le
■
■
■
■
■
45
SGBD ?
Dois-je créer une connexion (objet Connection) à
chaque fois que je dois interagir avec le SGBD et la
refermer après chaque interaction ?
Faut –il, en fonction du type de requête SQL à exécuter,
choisir judicieusement la méthode execute* à utiliser
Un ResultSet peut-il contenir de nombreux « tuples »
?
Les types Java et les types de bases de données
correspondent-ils parfaitement ?
La méthode prepareStatement est-elle utilisée pour
les requêtes paramétrées ?
Janvier 2014
388
Politique de gestion de la persistance
■ Comment intégrer le code JDBC qui assure le
chargement et le déchargement des objets Java
depuis la BD ?
● En structurant au mieux le code (limiter le nombre
d’opérations à modifier)
● Quel(s) objet(s) charger et quand ?
● Quel(s) objet(s) décharger et quand ?
46
Janvier 2014
389
Chargement / déchargement (1)
■ Chargement
● Constructeur d’objet intégrant tous les attributs
● Statique : constructeur de « collections »
− Similaire au TP médiathèque sérialisée
− Volume de données contrôlé
● Dynamique : constructeur d’objet (nécessité d’une clé
pour sélectionner l’objet)
− Charger les objets connexes
■ Déchargement
● Statique : à la fin du programme (attention aux pertes
d’information)
● Dynamique : dans les opérations de mise à jour
47
Janvier 2014
390
Chargement / déchargement (2)
■ Statique
● Adapté aux petits volumes de données
● Faible taux de mises à jour
● Simple à mettre en œuvre
■ Dynamique
●
●
●
●
48
Adapté aux volumes de données importants
Fort taux de mises à jour
Meilleure résistance aux fautes
Plus compliqué à programmer
Janvier 2014
391
Plan du document
1. Motivations
2.
3.
4.
49
1. Application exemple : la médiathèque
2. Problématique en image
Quel schéma de Base de Données Relationnelle ?
Gérer la persistance dans Java : JDBC
Conclusion
Janvier 2014
392
Conclusion
■ Pour un diagramme de classes
● Plusieurs modèles relationnels pour la persistance
● Savoir choisir
■ Schéma relationnel
● Relation + attributs avec des domaines + clé +
contraintes d’intégrité
■ JDBC : une solution technique
● « bas » niveau
■ Canevas logiciels industriels
● Hibernate, TopLink
● Proposition de modèles de persistance
● Méthodes « haut » niveau pour interagir avec le SGBD
50
Janvier 2014
393
394
Tableaux de service des navigants
Air France
Enseignants CSC4002
Revision : 1567
CSC 4002
Octobre 2015
395
1
Questions de cours
En partant de la classe CNAMERecord dont le code source est donné ci-après, répondez aux questions suivantes.
Les questions 1 à 6 doivent être répondues au plus en trois lignes.
1
2
3
4
// C o p y r i g h t ( c ) 1999 Brian W e l l i n g t o n ( b w e l l i n g @ x b i l l . o r g )
package o r g . x b i l l . DNS ;
import j a v a . i o . ∗ ;
import o r g . x b i l l . DNS . u t i l s . ∗ ;
5
6
public c l a s s CNAMERecord extends NS_CNAME_PTRRecord {
7
8
9
10
private CNAMERecord(Name name , i n t d c l a s s , i n t
super ( name , Type .CNAME, d c l a s s , t t l ) ;
}
ttl ) {
11
12
13
14
15
16
17
18
/∗∗
∗ C r e a t e s a new CNAMERecord w i t h t h e g i v e n d a t a
∗ @param t a r g e t The name t o which t h e CNAME a l i a s p o i n t s
∗/
public CNAMERecord(Name name , i n t d c l a s s , i n t t t l , Name t a r g e t ) {
super ( name , Type .CNAME, d c l a s s , t t l , t a r g e t ) ;
}
19
20
21
22
23
protected Record rrFromWire (Name name , i n t type , i n t d c l a s s , i n t t t l , i n t l e n g t h ,
DataByteInputStream i n ) throws I O E x c e p t i o n {
return rrFromWire (new CNAMERecord( name , d c l a s s , t t l ) , i n ) ;
}
24
25
26
27
28
protected Record r d a t a F r o m S t r i n g (Name name , i n t d c l a s s , i n t t t l , T o k e n i z e r s t , Name o r i g i n )
throws I O E x c e p t i o n {
return r d a t a F r o m S t r i n g (new CNAMERecord( name , d c l a s s , t t l ) , s t , o r i g i n ) ;
}
29
30
}
Question 1 (1pt) : Quel doit être le nom du fichier source qui contient cette classe ?
Question 2 (1pt) : Sachant que la variable d’environnement CLASSPATH contient la chaîne de caractères
suivante : « /usr/local/java:. » dans quel(s) répertoire(s) peut se trouver ce fichier ?
Question 3 (1pt) : À quelle classe fait référence le mot réservé super de la ligne 9 ou 17 ?
Question 4 (1pt) : Combien doit-on passer de paramètres pour créer un objet de la classe CNAMERecord
lorsque l’on est hors de la classe ?
Question 5 (1pt) : Quelles classes peuvent utiliser la méthode rrFromWire ?
Question 6 (1pt) : On désire ajouter une méthode public String toString() à la classe CNAMERecord.
Cette méthode doit décrire l’objet par une chaîne de caractères, et en particulier le nom de sa classe.
Écrire le corps de la méthode toString().
2
Rappel du sujet du BE
Nous avons réalisé l’analyse d’un cas d’étude lors du bureau d’étude de synthèse dont nous rappelons ci-après
le sujet ainsi que la correction que nous en avons faite.
L’équipage d’un avion est toujours constitué d’un pilote, d’un copilote et de plusieurs personnels naviguants et commerciaux (PNC). Chacune de ces personnes est identifiée par son nom et sa fonction. L’équipage
d’un avion est reconstitué pour chacun de ses vols.
Chaque membre d’équipage doit être opérationnel sur deux catégories d’avions (par exemple, le PNC
Richard est opérationnel sur Airbus A320 et Boeing 747). Chaque catégorie d’avions requiert un nombre de
PNC dans son équipage oscillant entre un minimum et un maximum (par exemple, les PNC des Airbus A320
doivent être entre six et huit, et ceux d’un B747 entre 12 et 16)1 .
Voici ci-dessous un extrait du tableau de service de quelques employés de la compagnie AIR FRANCE.
1. Pour simplifier, le tableau ci-dessous n’en représente que quelques-uns.
TELECOM SudParis — Enseignants CSC4002 — Octobre 2015 — CSC 4002
396
Avion
13562
13562
13562
13562
13562
32156
32156
32156
32156
32156
Vol
AF347
AF347
AF347
AF347
AF347
AF545
AF545
AF545
AF545
AF545
Dest
Londres
Londres
Londres
Londres
Londres
New-York
New-York
New-York
New-York
New-York
Date
11/10/06
11/10/06
11/10/06
11/10/06
11/10/06
12/10/06
12/10/06
12/10/06
12/10/06
12/10/06
Catégorie
A320
A320
A320
A320
A320
B747
B747
B747
B747
B747
Site
Orly
Orly
Orly
Orly
Orly
Roissy
Roissy
Roissy
Roissy
Roissy
Nom
Corinne
Amy
Maureen
Richard
Ben
Nicolas
Jean-Marc
Ségolène
François
Fabien
Fonction
Pilote
Copilote
PNC
PNC
PNC
Pilote
Copilote
PNC
PNC
PNC
L’objectif du système à modéliser est de constituer le tableau de service. Les membres de l’équipage
peuvent visualiser les vols sur lesquels ils sont affectés. L’administrateur du système peut créer et supprimer
des entités dans le système. Le manager peut ajouter et supprimer des personnes dans un équipage pour un
vol donné (un vol est désigné par un numéro de vol et une date). Les données du vol sont archivées après le
vol pour une année2 .
3
Résultat de l’analyse UML
3.1
Liste des classes
Les classes et — attributs — obtenus après analyse du texte sont les suivants :
• Équipage — auMin, auMax — la classe équipage regroupe l’ensemble des membres d’équipage (pilote,
copilote et PNC) qui participent à un vol (à une date donnée) ;
• Avion — — un avion appartient à une catégorie donnée, il participe à plusieurs vols ;
• Pilote — — un membre d’équipage qui a pour métier pilote ;
• Copilote — — un membre d’équipage qui a pour métier copilote ;
• PNC — — un membre d’équipage qui a pour métier PNC ;
• MembreÉquipage — nom, prénom —
• CatégorieAvion — nom, nbPNCmin, nbPNCmax — un membre d’équipage ne peut voler que sur deux
catégories d’avion. Plusieurs avions peuvent appartenir à la même catégorie, d’où la nécessité de créer
une classe CatégorieAvion ;
• Vol — numéro, site, destination, date — un vol est une classe d’association entre un avion et un
ensemble de membres d’équipage. Un vol se déroule à une date donnée.
Nous décidons aussi d’appeler le système global TableauNavigants.
3.2
Cas d’utilisation
La figure suivante présente les acteurs et les cas d’utilisation du système.
2. En raison du temps limité, nous ignorons la tenue à jour de la localisation des équipages et le décompte de leurs temps
de vol et de repos.
397
3.3
La figure suivante présente le diagramme de classes proposé.
3.4
Diagramme de machine à états
La figure suivante présente le diagramme de machine à états de la classe « Vol ».
398
3.5
Diagramme de communications ou de séquence
La figure suivante présente le diagramme de communications associé au cas d’utilisation « affecter un PNC
à un vol ».
399
4
Questions de l’étude de cas
Question 1 Donnez en Java tous les attributs de la classe Vol. Proposez un constructeur.
Question 2 Donnez en Java tous les attributs de la classe MembreÉquipage. Vous devez réaliser l’association
avec la classe CatégorieAvion avec une collection. Proposez un constructeur et une méthode equals.
Question 3 Proposez un constructeur pour la classe Pilote
Question 4 En considérant que la classe TableauNavigants utilise un vecteur appelé personnel pour
stocker la collection des membres d’équipage. Réalisez le corps de la méthode de prototype suivant :
MembreÉquipage chercherMembre(MembreÉquipage membre).
Pour cette méthode, nous supposons qu’il est possible que des objets de type MembreÉquipage existent
sans être référencés dans la collection personnel de la classe TableauNavigants, et cela, même si le
diagramme de classes l’interdit par la présence de la composition entre la classe TableauNavigants
et la classe MembreÉquipage. C’est de la programmation défensive : même si la composition est mal
programmée (des objets MembreÉquipage existent en dehors de la collection personnel), les objets
trouvés sont effectivement dans la collection.
Par conséquent, l’objectif de la méthode chercherMembre est de tester si un objet égal à celui fourni
en argument de la méthode est membre de la collection et, si c’est le cas, de donner l’objet qui est dans
la collection. Sinon, elle retourne null.
Question 5 Écrivez le corps de la méthode affecterPNCVol appelée dans le diagramme de communications correspondant au cas d’utilisation affecterPNCVol. La méthode affecterPNCVol de la classe
TableauNavigants lève une exception appelée TableauNavigantsException pour décrire les cas
d’erreur. Elle fait aussi appel à des méthodes de la classe Equipage qui lèvent des exceptions de
type EquipageException. La méthode affecterPNCVol relaiera ces exceptions. En outre, la valeur
booléenne retournée permet de savoir si l’équipage est au complet suite à l’ajout du membre. Le
prototype de la méthode affecterPNCVol est le suivant :
public boolean affecterPNCVol(Vol v, PNC pnc) throws TableauNavigantsException,
EquipageException
Question 6 Nous désirons intégrer un invariant à la classe MembreÉquipage. Nous avons choisi l’invariant
suivant : le nombre de qualifications de la personne est entre 0 et 2. Écrivez l’invariant.
Dans cette question, nous supposons que la collection utilisée dans la classe MembreÉquipage ne contient
pas deux éléments égaux.
Question 7 Nous ajoutons maintenant des tests d’invariant sur les méthodes de la classe MembreÉquipage
qui modifient le nombre de qualifications. Ces méthodes lèveront donc l’exception InvariantBroken.
Voici les nouveaux prototypes des méthodes à votre disposition :
• MembreÉquipage(String nom, String prenom) throws InvariantBroken
• public boolean addQualification(CatégorieAvion type) throws InvariantBroken,
EquipageException
• public boolean delQualification(CatégorieAvion type, boolean fromType) throws
EquipageException, InvariantBroken
Proposez un ensemble de tests unitaires pour vérifier que cet invariant n’est pas violé, puis implantez-les
en utilisant le canevas logiciel JUnit. Voici les quatre tests :
• la construction d’un objet correct (c.-à-d., l’invariant est vérifié) ;
• l’ajout d’une qualification sans dépasser le maximum est permis ;
• l’ajout d’une qualification déjà présente est interdit ;
• l’ajout d’une qualification au delà du maximum n’est pas permis.
400
401
Glossaire global
Revision : 1567
CSC 4002
Octobre 2015
Les définitions de ce glossaire sont en grande partie extraites de la source suivante :
http://www.iai.uni-bonn.de/III/lehre/vorlesungen/SWT/SS96/Material/UML1.0/glossary.html. Il
ne nous a pas semblé nécessaire de les traduire en français.
acteur/actor [class] A predefined stereotype of type denoting an entity outside the system that interacts
with use cases. 40, Cf. stéréotype/stereotype
action A computational or algorithmic procedure. 48, 111, 114
agrégation/aggregation A special form of association that specifies a whole-part relationship between the
aggregate (whole) and a component part. association class. 69
analyse/analysis The part of the software development process whose primary purpose is to formulate a
model of the problem domain. Analysis focuses what to do, design focuses on how to do it. 33
artefact A piece of information that is used or produced by a software development process. An artefact
can be a model, a description or software. 151
association A relationship that describes a set of links. 60
association binaire/binary association An association between two classes. 61
association n-aire/n-ary association An association among three or more classes. Each instance of the
association is an n-tuple of values from the respective classes. 61
attribut/attribute A named property of a type. 56
cardinalité/cardinality The number of elements in a set. 61
cas d’utilisation/use case [class] A class that defines a set of use case instances. 39
classe/class A description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class is an implementation of type. attribute. 56
classe abstraite/abstract class A class that cannot be directly instantiated. 79
classe concrète/concrete class A class that can be directly instantiated. 79
classe d’association/association class A modeling element that has both association and class properties. An association class can be seen as an association that also has class properties, or as a class that
also has association properties. 77
composant/component An executable software module with identity and a well-defined interface. 143
composition A form of aggregation with strong ownership and coincident lifetime as part of the whole.
Parts with non-fixed multiplicity may be created after the composite itself, but once created they live
and die with it (i.e., they share lifetimes). Such parts can also be explicitly removed before the death
of the composite. abstract class. 78
conception/design The part of the software development process whose primary purpose is to decide how
the system will be implemented. During design strategic and tactical decisions are made to meet the
required functional and quality requirements of a system. 34
dépendance/dependency A relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).
147, 152
diagramme/diagram A graphical presentation of a collection of model elements, most often rendered as
a connected graph of arcs (relationships) and vertices (other model elements). 27
élément de modèle/model element An element that is an abstraction drawn from the system being
modeled. 22
403
élément dérivé/derived element A model element that can be computed from another element, but that
is shown for clarity or that is included for design purposes even though it adds no semantic information.
59
encapsulation A means to bind together code and the data it uses. 23, 65
espace de nommage/namespace A part of the model in which the names may be defined and used.
Within a namespace, each name has a unique meaning. 146
état/state A condition or situation during the life of an object during which it satisfies some condition,
performs some activity, or waits for some event. 110
état composite/composite state A state that consists of substates. 116
événement/event A significant occurrence. An event has a location in time and space and may have parameters. In the context of state diagrams, an event is an occurrence that can trigger a state transition.
110
exigence/requirement A desired feature, property, or behavior of a system. 30
généralisation spécialisation/generalisation A taxonomic relationship between a more general element
and a more specific element. The more specific element is fully consistent with the more general element
and contains additional information. An instance of the more specific element may be used where the
more general element is allowed. 41, 63
généralisation spécialisation multiple/multiple inheritance A semantic variation of generalization in
which a type may have more than one supertype. 63
héritage/inheritance The mechanism by which more specific elements incorporate structure and behavior
of more general elements related by behavior. 63
interaction A behavioral specification that comprises a set of message exchanges among a set of objects
within a particular context to accomplish a specific purpose. An interaction may be illustrated by one
or more scenarios. 90, 99
interface The use of a type to describe the externally visible behavior of a class, object, or other entity. In
the case of a class or object, the interface includes the signatures of the operations. 81
ligne de vie/object lifeline A line in a sequence diagram that represents the existence of an object over
a period of time. 91
machine à états/state machine A behavior that specifies the sequences of states that an object or an
interaction goes through during its life in response to events, together with its responses and actions.
109
message A communication between objects that conveys information with the expectation that activity
will ensue. The receipt of a message is normally considered an event. 91
message asynchrone/asynchronous message A message where the sending object does not pause to
wait for results. state machine. 93
message synchrone/synchronous message A message where the sending object pauses to wait for results. 93
méta-modèle/metamodel A model that defines the language for expressing a model. 403
méthode/method The implementation of an operation. The algorithm or procedure that effects the results
of an operation. 403
modèle/model A semantically closed abstraction of a system. 22
404
multiplicité/multiplicity A specification of the range of allowable cardinalities that a set may assume.
Multiplicity specifications may be given for roles within associations, parts within composites, repetitions, and other purposes. Essentially a multiplicity is a (possibly infinite) subset of the non-negative
integers. 61
navigabilité/navigability The ability for objects of a class at one end of an association to retrieve objects
from the other end. 76
objet/object An entity with a well-defined boundary and identity that encapsulates state and behavior.
State is represented by attributes and relationships, behavior is represented by operations and methods.
An object is an instance of a class. 23, 57, 73
opération/operation A service that can be requested from an object to effect behavior. An operation has
a signature, which may restrict the actual parameters that are possible. 56, Cf. méthode/method
paquetage/package A general purpose mechanism for organizing elements into groups. Packages may
be nested within other packages. A system may be thought of as a single high-level package, with
everything else in the system contained in it. 146
processus de développement/development process A set of partially ordered steps performed for a
given purpose during software development, such as constructing models or implementing models. 29
processus de modélisation/modelling time Refers to something that occurs during a modeling phase
of the software development process. It includes analysis time and design time. Usage note: When
discussing object systems it is often important to distinguish between modeling-time and run-time
concerns. 22
rôle/role The named specific behavior of an entity participating in a particular context. A role may be
static (e.g., an association role) or dynamic (e.g., a collaboration role). 61
stéréotype/stereotype A new type of modeling element that extends the semantics of the metamodel.
Stereotypes must be based on certain existing types or classes in the metamodel. Stereotypes may
extend the semantics, but not the structure of pre-existing types and classes. Certain stereotypes are
predefined in the UML, others may be user defined. 403, Cf. méta-modèle/metamodel
système/system A collection of connected units that are organized to accomplish a specific purpose. A
system can be described by one or more models, possibly from different viewpoints. 39
transition A relationship between two states indicating that an object in the first state will perform certain
specified actions and enter the second state when a specified event occurs and specified conditions are
satisfied. On such a change of state the transition is said to fire. 110
visibilité/visibility An enumeration whose value (public, protected, private, or implementation) denotes
how the model element to which it refers may be seen outside its enclosing name space. 127
vue/view A projection of a model, which is seen from a given perspective or vantage point and omits
entities that are not relevant to this perspective. object. 28
405
Index global
Revision : 1567
CSC 4002
Octobre 2015
406
attribut, 56, 195
de classe, 58
dérivé, 59
d’instance, 58
base, 208
classe
dérivée, 208
enfant, voir généralisation spécialisation
instanciation, 57
nom, 56
opération, 56
de classe, 58
d’instance, 58
parente, voir généralisation spécialisation
classe abstraite, 79, 214
classe d’association, 77
classe instance, 196
classe méthode, 195
classe métier, 34, 71
classe paramétrée, 236
classe publique, 195
classes
générique, 82
paramétrée, 82
CLASSPATH, 224
clone(), 228, 256, 257, 264
collection, 237
Hashtable, voir java.util.Hashtable
List, voir java.util.List
Map, voir java.util.Map
table de hachage, 237
Vector, voir java.util.Vector
communications, voir diagrammes, communications
comportement, voir modèle, aspects dynamiques
composant, voir diagrammes, composants, 143
composite, 144
connecteur
d’assemblage, 144
de délégation, 144
dépendance, 143
interface
fournie, 143
B
requise, 143
bytcode, 180
port, 144
primitif, 144
C
relation de dépendance, 143
cas d’utilisation, voir diagrammes, cas d’utilisation,
composition, 78
90
concepteur, 55
relations, 42
conception, 20–154
extend, 42
classes, voir diagrammes, classes
héritage, 42
communications, voir diagrammes, communicainclude, 42
tions
scénario, 47
composants,
voir diagrammes, composants
classe, 56, 58
déploiement, voir diagrammes, déploiement
abstraite, 79
des classes, voir conception des classes
association, voir association, 203–205
A
abstract, 215, 218
abstract, voir classe abstraite
acteur, 39, 40
généralisation, 41
action, 114
activité, 114
do, 114
entrée, 114
entry, 114
exit, 114
sortie, 114
activité, voir diagrammes, activité
agrégration
forte, voir composition
allocation mémoire, 199
analyse, 36–116
activité, voir diagrammes, activité
cas d’utilisation, voir diagrammes, cas d’utilisation
classes, voir diagrammes, classes
communications, voir diagrammes, communications
machine à états, voir diagrammes, machine à
états
objets, voir diagrammes, objets
séquence, voir diagrammes, séquence
analyste, 55
architecte, 55
architecture matérielle, 150
association, 60
multiplicités, 61
nom, 60
qualifiée, 132
rôle, 61
sens de lecture, 60
association qualifiée, 132
attribut, voir classe, 195
attribut de classe, 201–203
attribut dérivé, 131
auto référence, 198, 199
407
machine à états, voir diagrammes, machine à
états
paquetages, voir diagrammes, paquetages
conception des classes, 118–136
encapsulation, 127, 129
accessibilité des attributs, 127
accessibilité des opérations, 127
visibilité, voir visibilité
opérations, 134
attribut dérivé, 131
contrainte sur attribut, 134
message, 134
super, 136
traduction de la classe façade du système, 126
traduction des associations, 122–137
agrégation, 124
association binaire, 123
association n-aire, 123
association unidirectionnelle, 123
classes d’association, 137
compositions, 125
multiplicités, 123
référence, 123
constructeur, 196–198
conversion type, 189
copie profonde, 256, 257, 264
D
déploiement, voir diagrammes, déploiement
diagrammes
activité, 46
action, 48
appel d’activité, 50
arête, 48
attente, 50
choix, 48
décision, 48
démarrage, 50
fork, 49
fusion, 48
garde, 48
information transmise, 50
join, 49
nœud initial, 48
nœud terminal, 48
cas d’utilisation, 38–45
acteur, voir acteur
cas d’utilisation, voir cas d’utilisation
exemple, 44
lien acteur — cas d’utilisation, 39
lien de communication, 42
méthodologie, 45
scénario, 39
système, 39, 42
classes, 54–71, 75–82
408
agrégation, 69
association, voir association
association qualifiée, 132
classe, voir classe
classe abstraite, 79
classe d’association, 77
composition, 78
exemple, 70, 83
généralisation spécialisation, voir généralisation spécialisation, voir généralisation spécialisation
héritage, voir héritage
interface, 80
méthodologie, 71
navigabilité, 76
communications, 88, 98–106
collection, 104
exemple, 100–104
lien d’interaction, 100
message, 100, voir message
participant, 100
structure spatiale, 99
composants, 142–144
composant, voir composant
déploiement, 149–152
architecture matérielle, 150
artefact, 151
component, 151
dépendance entre artefacts, 152
deploy, 151
device, 150
execution environment, 151
instance de nœud, 152
liaison de communication, 150
manifest, 151
nœud, 150
machine à états, 88, 108–116
action, 114, voir action
état, 109, voir état
exemple, 112, 113
méthodologie, 115
transition, 110, voir transition
objets, 73
paquetages, 145–147
paquetage, voir paquetage
séquence, 88–106
événement, voir message
fragment, 95
gfragment, voir fragment de séquence
ligne de temps, 91
message, 91, voir message
participant, 91
downcast, 210
E
encapsulation, voir conception des classes
equals(), 228–230
Error, 252
état, 110
composite, 116
région, 116
sous-état, 116
evenement, voir événement
événement, 110
final, 110
intial, 110
type, 110
étude de cas, 31
Studs, 31
cas d’utilisation, 44
conception des classes, 122, 129
contraintes, 32
diagramme d’activité, 48, 49
diagramme de classes, 70, 83
diagramme de communications, 100–103
diagramme de déploiement, 151, 152
diagramme de machine à états, 113
diagramme de séquence, 92, 95, 96
diagramme d’objets, 73
expression des besoins, 31
règles de gestion, 32
événement, voir message
exception, 181, 267
principe, 249
relais, 267
traitement, 267
Exception, 252
extends, 207
F
final, 207
finalize, 199
for
for-each, 241
fragment de séquence
condition d’entrée, 95
contour, 95
loop, 96
opt, 95
ref, 95
type, 95
G
garbage collector, 199
généralisation, 206
généralisation spécialisation, 62, voir héritage, 64, 65
classe enfant, 62
classe parente, 62
méthode polymorphisme, 67
redéfinition d’opération, 66
H
hashCode(), 228, 265, 266
Hashtable, voir collection
hasNext(), 243
héritage, 62, voir généralisation spécialisation, 64, 65,
206
héritage simple, 207
I
instance, voir objet, 196
instance method, 195
instanceof, 207
référence, 197
instanciation, voir classe
instruction, 185
instruction de contrôle, 185
interface, 80, 218, 219
J
JAVA
API, 182
classe, 179, 194
historique, 178
JDK, 183
objet, 194
java.io, 232
java.io.Serializable, 235
java.lang, 227, 232
java.lang.Boolean, 232
java.lang.Byte, 232
java.lang.Character, 232
java.lang.Cloneable, 235
java.lang.Collection, 114
java.lang.Double, 232
java.lang.Exception, 251
java.lang.Float, 232
java.lang.Integer, 232, 233
java.lang.Iterable, 238
java.lang.Long, 232
java.lang.Number, 232
java.lang.Object, 207, 227, 228
java.lang.PI, 232
java.lang.Short, 232
java.lang.String, 227, 233, 234
java.lang.Void, 232
java.Math, 232
java.Math.sqrt(), 232
java.net, 232
java.util, 227, 232, 235
java.util.Collection, 237
java.util.Hashtable, 237, 245, 246
java.util.Integer, 227
java.util.Iterator, 237, 243
java.util.List, 237, 239
java.util.Map, 237, 244
java.util.Vector, 237, 240
L
liaison dynamique, 67, 210
lien
409
acteur — cas d’utilisation, 39
de communication, 42
d’interaction, 100
List, voir collection
M
machine à états, voir diagrammes, machine à états
machine virtuelle, 180
Map, voir collection
message, 91, 100–105
asynchrone, 93
conditionné, 101
creation, 94
create, 94
new, 94
emboîté, 102
en séquence, 101
itération de, 103
retour d’appel, 93
suppression, 94
destroy, 94
synchrone, 93
syntaxe, 93
arguments, 93
attribut, 93
nom, 93
type retour, 93
méthode, voir opération, 195
méthode de classe, 201–203
méthode polymorphique, 67
liaison dynamique, 67
type effectif, 67
type formel, 67
method overloading
surcharge, 195
modèle, 22
4+1 vues de Kruchten, 28
analyse, 37
aspects
dynamiques, 85, 88
statiques, 53
boîte noire, 23
orienté objet, 23
modélisation, 22, 29
cycle en V, 29
phases, 29
analyse, 33, voir analyse, voir analyse
conception, 34, voir conception
expression des besoins, 30–32
multiplicités, voir association
N
navigabilité, 76
new, 197, 198
next(), 243
O
objet, 73
410
objet destruction, 199
référence, 197
operateur, 185
opération, voir classe
abstraite, 79
orientation objet, voir modele, orienté objet
P
package, 223
paquetage, voir diagrammes, paquetages, 146, 223
dépendance, 147
espace de nommage, 146
imbrication, 147
passage argument, 192
polymorphisme, 210
R
ramasse miettes, 181, 199
référence, 122, 123, 179
remove(), 243
RuntimeException, 252, 269
S
scénario, 47, 90
aspect temporel, 90
spécialisation, 206
static, 202, 203
super
constucteur, 208
super(), 208
surcharge de méthode, 195
syntaxe de base, 185
système, voir diagrammes, cas d’utilisation
limite, 42
système informatique, 28
T
tableau, 179, 190, 191
accès, 191
création, 191
référence, 191
taille, 191
table de hachage, voir collection
this, 198, 199
this(), 198, 199
throw, 250
Throwable, 252
throws, 250, 253
toString, 209, 213
toString() , 228
toString exemple, 202
transition, 110
déclenchée, 111
franchie, 111
implicite, 112, 114
réflexive, 114
syntaxe, 111
action, 111
condition, 111
événement, 111
transtypage, 189, 210
try catch, 250, 251, 253
seemethode polymorphisme, 67
seemethode polymorphisme, 67
type primitif, 179, 180, 188
boolean, 188
char, 188
double, 188
float, 188
int, 188
long, 188
short, 188
private, 225, 226
protected, 225, 226
public, 225, 226
vue, 22
cas d’utilisation, 22, 37
développement, 22, 141
logique, 22, 53
aspect dynamique, 85
aspect statique, 53
physique, 22
processus, 22, 37
U
UML, 20–154
diagrammes
activité, 26, voir diagrammes, activité
cas d’utilisation, 26, voir diagrammes, cas
d’utilisation
classes, 26, voir diagrammes, classes
communication, voir diagrammes, communications
communications, 26
composants, 26, voir diagrammes, composants
composites, 26
interaction, 26
machine à états, 26, voir diagrammes, machine
à états
objets, 26, voir diagrammes, objets
paquetages, 26, voir diagrammes, paquetages
séquence, 26, voir diagrammes, séquence
temps, 26
vue globale d’interactions, 26
général, 24–26
langage, 25
unicode, 180
unité de compilation, 222
upcast, 210
V
Vector, voir collection
visibilité, 128
notation UML
−, 129
#, 129
+, 129
private, 128
protected, 128
public, 128
visibilité, voir accessibilité
visibilité, 225, 226
package, 225, 226
411
412
$
'
Fin
#2
Nous espérons que ce cours a contribué à vous rendre autonome dans la lecture et
l’écriture de modèles UML et de programmes JAVA.
Bon voyage (;-)).
&
%
Nous espérons que vous continuerez de naviguer avec plaisir dans ce cours en ligne lorsque vous en aurez
besoin.
413
$
'
Licence
Ce document est une documentation libre, placée sous la Licence de Documentation Libre GNU (GNU
Free Documentation License).
#3
Copyright (c) 2000-2014 C. Bac, D. Conan, C. Taconet, C. Lecocq, J.-P. Gibson
Permission est accordée de copier, distribuer et/ou modifier ce document selon les
termes de la Licence de Documentation Libre GNU (GNU Free Documentation License),
version 1.2 ou toute version ultérieure publiée par la Free Software Foundation; avec
les Sections Invariables qui sont ‘Licence’ ; avec les Textes de Première de Couverture
qui sont ‘CSC4002: Introduction à la conception objet illustrée avec UML et JAVA’
et avec les Textes de Quatrième de Couverture qui sont ‘Fin’.
Une copie de la présente Licence peut être trouvée à l’adresse suivante :
http://www.gnu.org/copyleft/fdl.html.
Remarque : La licence comporte notamment les sections suivantes : 2. COPIES VERBATIM, 3. COPIES
EN QUANTITÉ, 4. MODIFICATIONS, 5. MÉLANGE DE DOCUMENTS, 6. RECUEILS DE
DOCUMENTS, 7. AGRÉGATION AVEC DES TRAVAUX INDÉPENDANTS et 8. TRADUCTION.
&
%
Ce document est préparé avec des logiciels libres :
• LATEX : les textes sources sont écrits en LATEX (http://www.latex-project.org/, le site du Groupe
francophone des Utilisateurs de TEX/LATEX est http://www.gutenberg.eu.org). Une nouvelle classe
et une nouvelle feuille de style basées sur la classe seminar ont été tout spécialement dévéloppées: newslide (projet picoforge newslide, http://picoforge.int-evry.fr/projects/slideint)
et slideint (projet picoforge slideint, http://picoforge.int-evry.fr/projects/slideint);
• emacs: tous les textes sont édités avec l’éditeur GNU emacs (http://www.gnu.org/software/emacs);
• dvips: les versions PostScript (PostScript est une marque déposée de la société Adobe Systems Incorporated) des transparents et des polycopiés à destination des élèves ou des enseignants sont obtenues
à partir des fichiers DVI (« DeVice Independent ») générés à partir de LaTeX par l’utilitaire dvips
(http://www.ctan.org/tex-archive/dviware/dvips);
• ps2pdf et dvipdfm: les versions PDF (PDF est une marque déposée de la société Adobe Systems Incorporated) sont obtenues à partir des fichiers Postscript par l’utilitaire ps2pdf (ps2pdf
étant un shell-script lançant Ghostscript, voyez le site de GNU Ghostscript http://www.gnu.org/software/ghostscript/) ou à partir des fichiers DVI par l’utilitaire dvipfm;
• makeindex: les index et glossaire sont générés à l’aide de l’utilitaire Unix makeindex
(http://www.ctan.org/tex-archive/indexing/makeindex);
• TeX4ht: les pages HTML sont générées à partir de LaTeX par TeX4ht (http://www.cis.ohio-state.edu/~gurari/TeX4ht/mn.html);
• Xfig: les figures sont dessinées dans l’utilitaire X11 de Fig xfig (http://www.xfig.org);
• fig2dev: les figures sont exportées dans les formats EPS (« Encapsulated PostScript ») et PNG
(« Portable Network Graphics ») grâce à l’utilitaire fig2dev (http://www.xfig.org/userman/installation.html);
• convert: certaines figures sont converties d’un format vers un autre par l’utilitaire convert
(http://www.imagemagick.org/www/utilities.html) de ImageMagick Studio;
• HTML TIDY: les sources HTML générés par TeX4ht sont « beautifiés » à l’aide de HTML TIDY
(http://tidy.sourceforge.net) ; vous pouvez donc les lire dans le source;
Nous espérons que vous regardez cette page avec un navigateur libre: Mozilla ou Firefox par exemple. Comme
l’indique le choix de la licence GNU/FDL, tous les éléments permettant d’obtenir ces supports sont libres.
414

CSC4002 : Introduction à la conception et à la programmation

Transcription

Documents pareils

Diplomatic-Cover - Top Interactive Agencies

Procédure d`installation et d`activation de licence : Télécharger la

un cursus ingénieur bi-diplômant entre tunis et paris : la filière tunis

Informatique mobile, ubiquitaire et diffuse

Mardi 17 Janvier 19h00 Exia / Cesi de Mont Saint Aignan Des

Descriptif mission en alternance : Caterpillar Grenoble Equipe

Voir mon CV - Master 2 IMT

CV - Julien Vaudour

CP filière Tunis - Telecom SudParis

Le langage Java