Cours de modélisation Objet des données par la méthode Merise

(1)

CSC4002 : Introduction à la

conception et à la programmation

orientées objet illustrées avec

UML et JAVA

Denis Conan et Jean-Luc Raffy

CSC 4002

(2)

CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA

(3)

(4)

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 21

2.1 Principes de la modélisation . . . 22

2.2 Pourquoi et comment modéliser en orienté objet . . . 23

2.3 Unified Modelling Language (UML) . . . 24

2.3.1 UML, un langage . . . 25

2.3.2 Les 10 principaux diagrammes UML . . . 26

2.4 Cinq façons de voir un système informatique : les 4+1 vues de Kruchten . . . 28

2.5 Phases de la modélisation, cycle en V . . . 29

2.6 Rôle de l’expression des besoins . . . 30

2.6.1 Exemple de cahier des charges : Studs . . . 31

2.6.2 Règles de gestion et contraintes de l’application Studs . . . 32

2.7 Rôle de l’analyse . . . 33

2.8 Rôle de la conception . . . 34

QCM . . . 35

3 Analyse, vues cas d’utilisation et processus 36 3.1 Modèle de l’analyse . . . 37

3.2 Diagrammes de cas d’utilisation . . . 38

3.2.1 Introduction . . . 39

3.2.2 Acteur . . . 40

3.2.3 Relation de généralisation spécialisation entre acteurs . . . 41

3.2.4 Cas d’utilisation, lien de communication et système . . . 42

3.2.5 Exemple de diagramme de cas d’utilisation . . . 44

3.2.6 Éléments de méthodologie . . . 45

3.3 Diagrammes d’activité * . . . 46

3.3.1 Scénarios d’un cas d’utilisation * . . . 47

3.3.2 Actions et choix * . . . 48

3.3.3 Concurrence * . . . 49

3.3.4 Autres notations du diagramme d’activité * . . . 50

QCM . . . 51

(5)

4 Analyse et conception, aspects statiques de la vue logique 52

4.1 Diagrammes communs à l’analyse et à la conception . . . 53

4.2 Diagramme de classes . . . 54

4.2.1 Modéliser la structure logique du système dans un diagramme de classes . . . 55

4.2.2 Classe . . . 56

4.2.3 Instanciation : création d’un objet d’une classe . . . 57

4.2.4 Attributs et opérations de classe . . . 58

4.2.5 Attribut dérivé . . . 59

4.2.6 Association entre classes . . . 60

4.2.7 Nom de rôle et multiplicité . . . 61

4.2.8 Généralisation spécialisation ou héritage . . . 62

4.2.9 Généralisation spécialisation : vision ensembliste . . . 64

4.2.10 Généralisation spécialisation : vision encapsulation . . . 65

4.2.11 Généralisation et redéfinition d’opérations . . . 66

4.2.12 Méthode Polymorphique et liaison dynamique . . . 67

4.2.13 Agrégation . . . 69

4.2.14 Exemple de diagramme de classes . . . 70

4.3 Diagramme d’objets . . . 73

QCM . . . 74

4.4 Concepts avancés du diagramme de classes . . . 75

4.4.1 Navigabilité . . . 76

4.4.2 Classe d’association . . . 77

4.4.3 Composition : agrégation forte . . . 78

4.4.4 Classe abstraite . . . 79

4.4.5 Interface . . . 80

4.4.6 Classe paramétrée / générique * . . . 82

4.4.7 Exemple de diagramme de classes avancé . . . 83

5 Analyse et conception, aspects dynamiques de la vue logique 84 5.1 Rappel : diagrammes communs à l’analyse et à la conception . . . 85

5.2 Modélisation des aspects dynamiques . . . 86

5.2.1 Algorithme : orientations procédurale et objet . . . 87

5.2.2 Modèle dynamique de l’analyse et de la conception . . . 88

5.3 Diagramme de séquence . . . 89

5.3.1 Modéliser l’ordre des interactions . . . 90

5.3.2 Participant, temps et message . . . 91

5.3.3 Exemple de diagramme de séquence « Ouvrir un scrutin » . . . 92

5.3.4 Syntaxe et types de messages . . . 93

5.3.5 Création et suppression d’objets . . . 94

5.3.6 Fragments de séquence « ref » et « opt » . . . 95

5.3.7 Fragment de séquence « loop » . . . 96

QCM . . . 97

5.4 Diagramme de communications . . . 98

5.4.1 Modéliser les liens d’interactions . . . 99

5.4.2 Participant, lien d’interaction, message . . . 100

5.4.3 Message conditionné, messages en séquence . . . 101

5.4.4 Messages emboîtés . . . 102

5.4.5 Itération de messages . . . 103

5.4.6 Collection et recherche dans une collection . . . 104

5.4.7 Messages concurrents * . . . 105

5.4.8 Choix entre séquence et communications* . . . 106

QCM . . . 107

5.5 Diagramme de machine à états . . . 108

5.5.1 Modéliser l’état des objets d’une classe . . . 109

5.5.2 Types d’états, événement et transition . . . 110

5.5.3 Événement, condition et action d’une transition . . . 111

(6)

5.5.4 Transition implicite . . . 112

5.5.5 Exemple de diagramme de machine à états de la classe Scrutin . . . 113

5.5.6 Actions liées à un état . . . 114

5.5.8 État composite * . . . 116

QCM . . . 117

6 Conception, aspects langage et technique 118 6.1 Rappel des phases du cycle de développement en V . . . 119

6.2 Conception des classes . . . 120

6.3 Rappel du diagramme de classes de l’étude de cas Studs . . . 121

6.4 Traduction des associations en attributs . . . 122

6.4.1 Règles de traduction . . . 123

6.5 Traduction des agrégations . . . 124

6.6 Traduction des compositions * . . . 125

6.7 Traduction de la classe « Façade » du système . . . 126

6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations . . . 127

6.8.1 Encapsulation avec le concept de Visibilité . . . 128

6.8.2 Notation UML . . . 129

6.8.3 Cas particulier des attributs/opérations protégés . . . 130

6.9 Traduction des attributs dérivés . . . 131

6.10 Qualification de certaines associations * . . . 132

6.11 Traduction des diagrammes d’interaction en algorithmes . . . 133

6.12 Traduction des diagrammes de machine à états . . . 134

6.12.1 Quelques opérations de la classe Scrutin . . . 135

6.13 Traduction des relations de généralisation spécialisation . . . 136

6.14 Traduction des classes d’association * . . . 137

6.15 Méthodologie : une fiche par classe . . . 138

QCM . . . 139

7 Conception, vues développement et physique 140 7.1 Diagrammes de la vue développement . . . 141

7.2 Diagramme de composants . . . 142

7.2.1 Composant, interfaces offertes et requises . . . 143

7.2.2 Composite, port, connecteurs de délégation et d’assemblage . . . 144

7.3 Diagramme de paquetages . . . 145

7.3.1 Paquetage, espace de nommage . . . 146

7.3.2 Relation entre paquetages . . . 147

7.4 Diagramme de la vue physique . . . 148

7.5 Diagramme de déploiement . . . 149

7.5.1 Nœud et liaison de communication . . . 150

7.5.2 Artefact et composant . . . 151

7.5.3 Dépendance entre artefacts . . . 152

8 Conclusion 153

9 Bibliographie 154

BE1–2 : Phase d’analyse

Gestion des prêts dans une médiathèque 155

1 Sujet 156

(7)

2 Méthodologie et objectifs 156

2.1 Première lecture : acteurs et cas d’utilisation . . . 156

2.1.1 Question 1 : diagramme de cas d’utilisation . . . 156

2.2 Analyse du texte : recherche des classes et opérations . . . 156

2.2.1 Question 2 : liste des classes . . . 157

2.3 Phase de construction du diagramme de classes . . . 157

2.3.1 Question 3 : diagramme de classes simple . . . 157

2.4 Phase de recherche des attributs et opérations . . . 157

2.4.1 Question 4 : classes avec opérations . . . 158

2.5 Phase de vérification de l’analyse, aspects statiques . . . 158

2.5.1 Question 5 : vérifications . . . 158

3 Cahier des charges 158 3.1 Règles de prêt . . . 159

BE3–4 : Phase d’analyse 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 166 2.1 Analyse du texte . . . 166

2.2 Diagramme de cas d’utilisation . . . 166

2.6 Diagramme de communications ou de séquence . . . 167

Introduction au langage de programmation Java 169 Sommaire du cours 173 1 Introduction à Java 174 1.1 Vous avez dit Java ? . . . 174

1.1.1 Android . . . 174

1.1.2 CAS . . . 175

1.1.3 Java partout ! . . . 175

1.1.4 Pourquoi nous ? . . . 176

1.2 Que recouvre le mot Java ? . . . 176

1.2.1 Héros . . . 177

1.2.2 Projet et Historique . . . 177

1.3 Caractéristiques . . . 178

(8)

1.3.1 Java un langage Objet . . . 179

1.3.2 Machine Virtuelle Java . . . 180

1.3.3 Robustesse . . . 180

1.4 Historique de l’API . . . 181

1.5 Environnements de développement . . . 182

1.5.1 Java Standard Development Kit . . . 182

1.6 En savoir plus . . . 183

1.6.1 Sites Web . . . 184

Questions sur les concepts Java . . . 184

2 Concepts de bases de Java 185 2.1 Syntaxe de base . . . 185 2.1.1 Premier en C . . . 186 2.1.2 Premier en Java . . . 186 2.2 Types Primitifs . . . 188 2.2.1 Conversions de type . . . 188 2.2.2 Exemple de conversions . . . 189 2.2.3 Tableaux . . . 189

2.2.4 Exemple avec un tableau . . . 190

2.3 Tableaux . . . 190

2.4 Méthodes . . . 191

2.5 Exemple de passage d’arguments . . . 192

Questions sur la syntaxe de base de Java . . . 192

3 Classes et objets en Java 194 3.1 Classe . . . 194

3.1.1 Classe Personne en Java . . . 194

3.1.2 Instance de classe en UML . . . 196

3.1.3 Instance de classe en Java . . . 196

3.2 Objet . . . 197

3.2.1 Constructeurs en Java . . . 197

3.2.2 Exemples de constructeurs . . . 198

3.2.3 this . . . 198

3.2.4 Exemples d’utilisation de this . . . 198

3.2.5 Destruction des objets . . . 199

3.2.6 Abstraction et encapsulation . . . 200

3.2.7 Visibilité des méthodes . . . 200

3.3 Attributs et méthodes de classe . . . 201

3.3.1 Attributs et méthodes de classe Java . . . 201

3.3.2 Attributs et méthodes de classe . . . 202

3.4 Association entre classes . . . 203

3.4.1 Exemple d’association . . . 203

3.4.2 Association entre classes en Java . . . 204

Questions sur les classes et objet . . . 205

4 Généralisation spécialisation en Java 206 4.1 Généralisation spécialisation . . . 206

4.1.1 Héritage : comment en Java . . . 207

4.1.2 Héritage et constructeur . . . 207

4.1.3 Exemple de classe parente et classe dérivée . . . 208

4.1.4 Utilisation de classe parente et dérivée . . . 209

4.2 Polymorphisme . . . 210

4.2.1 Exemple de Upcast et Downcast . . . 211

4.3 Redéfinition de méthodes dans les classes dérivées . . . 212

4.3.1 Polymorphisme et liaison dynamique avec toString . . . 212

4.4 Héritage, membres et visibilité . . . 213

Questions généralisation/spécialisation en Java . . . 213

(9)

4.5 Classes abstraites . . . 214

4.5.1 Classes abstraites : principes . . . 214

4.5.2 Classes abstraites en Java . . . 215

4.6 Exemple de classe Abstraites . . . 215

4.6.1 Exemple : classes abstraites . . . 216

4.7 Interfaces . . . 218

4.7.1 Interfaces en Java . . . 218

5 Organisation des sources Java 220 5.1 Programme en C (rappel) . . . 220

5.2 Exécution d’un programme (rappel) . . . 220

5.3 Exécution d’un programme sur une machine virtuelle . . . 221

5.4 Dans le cas de Java . . . 222

5.5 Unités de compilation . . . 222 5.6 Paquetages . . . 223 5.6.1 Chemin de recherche . . . 224 5.6.2 Exemple . . . 224 5.7 Visibilité en Java . . . 224 5.7.1 Table de visibilité . . . 225

Questions organisation des sources en Java . . . 226

6 API Java 227 6.1 Premières classes de l’API . . . 227

6.2 Classe java.lang.Object . . . 227

6.2.1 Égalité . . . 229

6.2.2 Exemple d’égalité . . . 229

6.2.3 Exemple de méthode equals . . . 230

6.3 Interface de programmation . . . 231

6.3.1 Quelques paquetages Java . . . 231

6.4 java.lang.* . . . 232

6.4.1 Exemple avec la classe Integer . . . 233

6.4.2 Classe String . . . 233

6.4.3 Exemple pour String . . . 233

Questions API java.lang . . . 234

6.5 java.util.* . . . 234

6.5.1 Classe paramétrée . . . 235

6.5.2 Classes Abstraites des collections . . . 236

6.5.3 Classes instanciables des collections . . . 237

6.5.4 Collections . . . 237

6.5.5 Interface Iterable . . . 238

6.5.6 Interface Collection<E> . . . 238

6.5.7 Interface List<E> . . . 239

6.5.8 Classe Vector<E> . . . 239

6.5.9 Boucle pour les collections . . . 240

6.5.10 Exemple for-each sur un Vector . . . 241

6.5.11 Exemple de classe avec Vector . . . 241

6.5.12 Interface Iterator . . . 242

6.5.13 Exemple avec Iterator . . . 243

6.5.14 Dictionnaires Map<K,V> . . . 244

6.5.15 Exemple pour Map . . . 244

6.5.16 Dictionnaire Hashtable<K,V> . . . 245

6.5.17 Exemple pour Hashtable . . . 246

6.5.18 Représentation d’une Hashtable . . . 246

Questions collections en Java . . . 247

(10)

7 Exceptions en Java 248

7.1 Motivation : retours sur un bug . . . 248

7.2 Principes . . . 249

7.2.1 Mise en œuvre . . . 250

7.2.2 Exemple de traitement . . . 250

7.3 Réalisation . . . 251

7.3.1 java.lang.Exception . . . 251

7.4 Traitement des exceptions . . . 252

7.5 Exemple de traitement d’exceptions . . . 253

Questions sur les exceptions . . . 254

8 Concepts objets avancés en Java 256 8.1 Copie simple/légère . . . 256

8.1.1 Copie pour studs . . . 257

8.1.2 Représentation graphique d’une copie légère dans studs . . . 257

8.1.3 Exemple de copie légère . . . 257

8.1.4 Représentation graphique d’une copie plus profonde dans studs . . . 259

8.1.5 Copie plus profonde dans studs . . . 259

8.1.6 Représentation graphique d’une copie profonde . . . 261

8.1.7 Clone de Scrutin . . . 262

8.1.8 Clone en copie profonde de Personne . . . 263

8.1.9 Suite exemple de copie profonde . . . 264

8.2 Retour sur hashCode() . . . 265

8.2.1 Exemple hashCode . . . 266

8.3 Retour sur les exceptions . . . 266

8.3.1 Test des exceptions . . . 267

8.3.2 RuntimeException . . . 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 397 3.1 Liste des classes . . . 397

3.2 Cas d’utilisation . . . 397

3.5 Diagramme de communications ou de séquence . . . 399

4 Questions de l’étude de cas 400

Glossaire global

Christian Bac et Denis Conan 402

Index global

Christian Bac et Denis Conan 406

Index 407

Fin 413

(11)

Licence 414

(12)

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

(13)

CSC4002 : Conception et programmation orientée objet # 2 ' & $ %

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. 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

# 3 ' & $ %

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 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

(14)

3 Découpage du module

Le module est divisé en deux parties :  Analyse/Conception

Octobre et novembre ; 16H30 Présentiel+ 18h Hors présentiel

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 Découverte du langage JAVA et de ses composants les plus utiles I Réalisation en JAVA de la solution obtenue dans la partie précédente I Élaboration et programmation d’un jeu de tests

I Persistance des données du système (avec JDBC)

# 5 ' & $ %

4 Prérequis

1. Maîtrise de l’environnement UNIX (CSC3001)

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)

(15)

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) :

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(Moy(CC, CF 1), max(CF 2, 13))

NoteUVInfo = (2 ∗ NoteCSC4001 + 4 ∗ NoteCSC4002 + 1 ∗ NoteCSC4003)/7

# 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

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

(16)

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

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

# 9

'

&

$

%

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

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

(17)

CSC4002 : Conception et programmation orientée objet

(18)

Introduction au langage de

modélisation UML

Denis Conan, Chantal Taconet, Christian Bac

Revision : 1495

CSC 4002

Octobre 2015

(19)

Introduction au langage de modélisation UML

Table des matières

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 21

2.1 Principes de la modélisation . . . 22

2.2 Pourquoi et comment modéliser en orienté objet . . . 23

2.3 Unified Modelling Language (UML) . . . 24

2.3.1 UML, un langage . . . 25

2.3.2 Les 10 principaux diagrammes UML . . . 26

2.4 Cinq façons de voir un système informatique : les 4+1 vues de Kruchten . . . 28

2.5 Phases de la modélisation, cycle en V . . . 29

2.6 Rôle de l’expression des besoins . . . 30

2.6.1 Exemple de cahier des charges : Studs . . . 31

2.6.2 Règles de gestion et contraintes de l’application Studs . . . 32

2.7 Rôle de l’analyse . . . 33

2.8 Rôle de la conception . . . 34

QCM . . . 35

3 Analyse, vues cas d’utilisation et processus 36 3.1 Modèle de l’analyse . . . 37

3.2 Diagrammes de cas d’utilisation . . . 38

3.2.1 Introduction . . . 39

3.2.2 Acteur . . . 40

3.2.3 Relation de généralisation spécialisation entre acteurs . . . 41

3.2.4 Cas d’utilisation, lien de communication et système . . . 42

3.2.5 Exemple de diagramme de cas d’utilisation . . . 44

3.3 Diagrammes d’activité * . . . 46

3.3.1 Scénarios d’un cas d’utilisation * . . . 47

3.3.2 Actions et choix * . . . 48

3.3.3 Concurrence * . . . 49

3.3.4 Autres notations du diagramme d’activité * . . . 50

QCM . . . 51

4 Analyse et conception, aspects statiques de la vue logique 52 4.1 Diagrammes communs à l’analyse et à la conception . . . 53

4.2.1 Modéliser la structure logique du système dans un diagramme de classes . . . 55

4.2.2 Classe . . . 56

4.2.3 Instanciation : création d’un objet d’une classe . . . 57

4.2.4 Attributs et opérations de classe . . . 58

4.2.5 Attribut dérivé . . . 59

4.2.6 Association entre classes . . . 60

4.2.7 Nom de rôle et multiplicité . . . 61

4.2.8 Généralisation spécialisation ou héritage . . . 62

4.2.9 Généralisation spécialisation : vision ensembliste . . . 64

4.2.10 Généralisation spécialisation : vision encapsulation . . . 65

4.2.11 Généralisation et redéfinition d’opérations . . . 66

4.2.12 Méthode Polymorphique et liaison dynamique . . . 67

4.2.13 Agrégation . . . 69

4.2.14 Exemple de diagramme de classes . . . 70

4.3 Diagramme d’objets . . . 73

QCM . . . 74

(20)

4.4 Concepts avancés du diagramme de classes . . . 75

4.4.1 Navigabilité . . . 76

4.4.2 Classe d’association . . . 77

4.4.3 Composition : agrégation forte . . . 78

4.4.4 Classe abstraite . . . 79

4.4.5 Interface . . . 80

4.4.6 Classe paramétrée / générique * . . . 82

4.4.7 Exemple de diagramme de classes avancé . . . 83

5 Analyse et conception, aspects dynamiques de la vue logique 84 5.1 Rappel : diagrammes communs à l’analyse et à la conception . . . 85

5.2 Modélisation des aspects dynamiques . . . 86

5.2.1 Algorithme : orientations procédurale et objet . . . 87

5.2.2 Modèle dynamique de l’analyse et de la conception . . . 88

5.3 Diagramme de séquence . . . 89

5.3.1 Modéliser l’ordre des interactions . . . 90

5.3.2 Participant, temps et message . . . 91

5.3.3 Exemple de diagramme de séquence « Ouvrir un scrutin » . . . 92

5.3.4 Syntaxe et types de messages . . . 93

5.3.5 Création et suppression d’objets . . . 94

5.3.6 Fragments de séquence « ref » et « opt » . . . 95

5.3.7 Fragment de séquence « loop » . . . 96

QCM . . . 97

5.4 Diagramme de communications . . . 98

5.4.1 Modéliser les liens d’interactions . . . 99

5.4.2 Participant, lien d’interaction, message . . . 100

5.4.3 Message conditionné, messages en séquence . . . 101

5.4.4 Messages emboîtés . . . 102

5.4.5 Itération de messages . . . 103

5.4.6 Collection et recherche dans une collection . . . 104

5.4.7 Messages concurrents * . . . 105

5.4.8 Choix entre séquence et communications* . . . 106

QCM . . . 107

5.5.1 Modéliser l’état des objets d’une classe . . . 109

5.5.2 Types d’états, événement et transition . . . 110

5.5.3 Événement, condition et action d’une transition . . . 111

5.5.4 Transition implicite . . . 112

5.5.5 Exemple de diagramme de machine à états de la classe Scrutin . . . 113

5.5.6 Actions liées à un état . . . 114

5.5.8 État composite * . . . 116

QCM . . . 117

6 Conception, aspects langage et technique 118 6.1 Rappel des phases du cycle de développement en V . . . 119

6.3 Rappel du diagramme de classes de l’étude de cas Studs . . . 121

6.4 Traduction des associations en attributs . . . 122

6.4.1 Règles de traduction . . . 123

6.5 Traduction des agrégations . . . 124

6.6 Traduction des compositions * . . . 125

6.7 Traduction de la classe « Façade » du système . . . 126

6.8 Encapsulation : visibilité / accessibilité des attributs et des opérations . . . 127

6.8.1 Encapsulation avec le concept de Visibilité . . . 128

6.8.2 Notation UML . . . 129

6.8.3 Cas particulier des attributs/opérations protégés . . . 130

(21)

6.9 Traduction des attributs dérivés . . . 131

6.10 Qualification de certaines associations * . . . 132

6.11 Traduction des diagrammes d’interaction en algorithmes . . . 133

6.12 Traduction des diagrammes de machine à états . . . 134

6.12.1 Quelques opérations de la classe Scrutin . . . 135

6.13 Traduction des relations de généralisation spécialisation . . . 136

6.14 Traduction des classes d’association * . . . 137

6.15 Méthodologie : une fiche par classe . . . 138

QCM . . . 139

7 Conception, vues développement et physique 140 7.1 Diagrammes de la vue développement . . . 141

7.2 Diagramme de composants . . . 142

7.2.1 Composant, interfaces offertes et requises . . . 143

7.2.2 Composite, port, connecteurs de délégation et d’assemblage . . . 144

7.3 Diagramme de paquetages . . . 145

7.3.1 Paquetage, espace de nommage . . . 146

7.3.2 Relation entre paquetages . . . 147

7.4 Diagramme de la vue physique . . . 148

7.5 Diagramme de déploiement . . . 149

7.5.1 Nœud et liaison de communication . . . 150

7.5.2 Artefact et composant . . . 151

7.5.3 Dépendance entre artefacts . . . 152

8 Conclusion 153

9 Bibliographie 154

(22)

Introduction au langage de modélisation UML # 2 ' & $ %

Sommaire

1 Objectifs de ce cours de modélisation orientée objet . . . 3 2 Généralités sur la modélisation orienté objet et sur UML. . . .4 3 Analyse, vues cas d’utilisation et processus . . . 18 4 Analyse et conception, aspects statiques de la vue logique . . . 33 5 Analyse et conception, aspects dynamiques de la vue logique . . . 61 6 Conception, aspects langage et technique . . . 95 7 Conception, vues développement et physique . . . 118 8 Conclusion . . . 131 9 Bibliographie . . . 132

Une organisation, grande ou petite, dépend souvent, d’une part, de la qualité de son système d’informa-tion, 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.

(23)

1 Objectifs de ce cours de modélisation orientée objet

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 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 construi-sons 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 impor-tant. 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.

(24)

2 Généralités sur la modélisation orienté objet et sur UML

2.1 Principes de la modélisation. . . .5 2.2 Pourquoi et comment modéliser en orienté objet . . . 6 2.3 Unified Modelling Language (UML) . . . 7 2.4 Cinq façons de voir un système informatique : les 4+1 vues de Kruchten . . . 10 2.5 Phases de la modélisation, cycle en V . . . 11 2.6 Rôle de l’expression des besoins . . . 12 2.7 Rôle de l’analyse . . . 15 2.8 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 introdui-sons 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.

(25)

Introduction au langage de modélisation UML 2 Généralités sur la modélisation orienté objet et sur UML # 5 ' & $ %

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 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, sta-keholders)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 impor-tant, 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 justi-fiant 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 compor-tement 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.

(26)

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 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.

(27)

2.3 Unified Modelling Language (UML)

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).

(28)

2 Généralités sur la modélisation orienté objet et sur UML 2.3 Unified Modelling Language (UML) # 8 ' & $ %

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 :

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 visua-liser 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 sys-tè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.

(29)

2 Généralités sur la modélisation orienté objet et sur UML 2.3 Unified Modelling Language (UML) # 9 ' & $ %

2.3.2 Les 10 principaux diagrammes UML

Cette diapositive présente la liste des 10 principaux diagrammes UML étudiés dans le cours. Les princi-paux 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

impor-tantes ;

• 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.

(30)

2 Généralités sur la modélisation orienté objet et sur UML 2.3 Unified Modelling Language (UML) 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 ».

(31)

2.4 Cinq façons de voir un système informatique : les 4+1 vues

de Kruchten

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 ».

(32)

2.5 Phases de la modélisation, cycle en V

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 ».

(33)

2.6 Rôle de l’expression des besoins

Permettre une meilleure compréhension du système Comprendre et structurer les besoins du client

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’ap-profondissement 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 ».

(34)

2 Généralités sur la modélisation orienté objet et sur UML 2.6 Rôle de l’expression des besoins # 13 ' & $ %

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.

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.

(35)

2 Généralités sur la modélisation orienté objet et sur UML 2.6 Rôle de l’expression des besoins # 14 ' & $ %

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.

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 consul-ter 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’organisa-trice 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.

(36)

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)

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 ».

(37)

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)

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 et3)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 appli-cations 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 embar-qué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 ».