CHAPITRE 20 Un exemple complet

Introduction à la programmation orientée objets 167

 eivd Télécommunications mjn

20.1 Un projet simple

Nous allons essayer d’illustrer la conception orientée objets par un exemple simple. Il
faut tout de même voir qu’un exemple simple est certes plus aisé à comprendre, mais devient
assez vite trivial, et peut dans cetains cas poser la question de l’utilité de la modélisation. On
se souviendra que les procédés de modélisation ont été mis au point pour parvenir à maîtriser
des problèmes complexes, et que les appliquer à des problèmes plus simples implique forcé-
ment l’énoncé de certaines évidences.

Ce qui est important dans cet exemple, c’est de montrer sur un exemple quasiment évi-
dent comment s’opère la modélisation. L’étape suivante consiste à réaliser soi-même une
modélisation simple. En suite de quoi, on pourra aborder des problèmes réalistes.

168 Introduction à la programmation orientée objets

eivd Télécommunications mjn

20.2 Un exemple : un autoradio FM

Nous nous proposons ici de modéliser un autoradio FM, avec touches de contrôle et
affichage alphanumérique de la station; cet autoradio possédera des mémoires de station, et
un système de recherche automatique.

Il faut insister sur le fait que le processus de modélisation ne constitue pas une science
exacte ! Le jour où ce processus constituera une démarche parfaitement systématique, il ne
sera plus nécessaire de faire appel à des ingénieurs : de bêtes PC feront aussi bien (ou mieux)
l’affaire. Fort heureusement, il ne semble pas que ce jour figure dans les perspectives immé-
diates. Par conséquence, deux modélisations faites à partir d’une même spécification par
deux équipes différentes aboutit normalement à deux designs pouvant être très différents.
Ceci ne signifie pas forcément que l’un soit meilleur que l’autre : les deux peuvent avoir des
avantages et des inconvénients, mais ce ne seront pas les mêmes.

La première étape que nous devons accomplir est d’écrire une spécification; comme on
peut penser qu’un autoradio est assez bien spécifié, nous allons directement sauter à la modé-
lisation. Dans le cas où une spécification est nécessaire, on se rappellera que le diagramme
des cas d’utilisation permet de structurer la spécification !

Introduction à la programmation orientée objets 169

 eivd Télécommunications mjn

20.3 Les cas d’utilisation (Use Case)

Les cas d’utilisation apparaissent très tôt dans le design. Dans le cas de notre autoradio,
il se trouve que le système est trop simple pour que ceux-ci nous apportent beaucoup.

FIGURE 20.1 Diagramme des cas d’utilisation pour l’autoradio

170 Introduction à la programmation orientée objets

eivd Télécommunications mjn

20.4 Diagramme des classes

Traditionnellement, nous continuerons par le diagramme de classes : ce n’est pas une

obligation, mais il se trouve que c’est par quoi l’on commence le plus souvent. Nous effec-
tuerons ce diagramme de classe dans un paquetage spécial, que nous appelons FMRadio.

FIGURE 20.2 La paquetage

Le package est initialement vide; nous allons le remplir en identifiant trois sous-systè-
mes dans notre autoradio (nous négligeons volontairement l’alimentation) : le sous-système
d’interactions avec l’utilisateur, le sous-système audio, le sous-système de réception HF
(figure20.3, page171).

FIGURE 20.3 Première décomposition

Cette première décomposition identifie les sous-systèmes évi-

dents; le fait de les grouper par packages est le résultat d’une
recherche de classification : en fait, pour un problème aussi sim-
ple, un modèle "mis à plat" eût vraisemblablement suffi.

Introduction à la programmation orientée objets 171

 eivd Télécommunications mjn

20.5 Définition d’un package particulier

(interface utilisateur)

L’étape suivant consiste à affiner nos composants. Nous ne le ferons pas pour tous les
sous-systèmes, car ce serait fastidieux. Nous allons nous concentrer sur l’interface utilisateur.
Nous pouvons "ouvrir" l’interface utilisateur en cliquant dessus, et y insérer les composants
(sous forme de classe, cette fois) qui nous paraissent appropriés (figure20.4, page172).

FIGURE 20.4 Décomposition de l’interface utilisateur

A ce niveau, on peut commencer à définir les responsabilités de chacune des classes.

Ces responsabilités se traduiront en propriétés, en attributs, et en opérations (donc, en mem-
bres de classes). Nous n’allons, là encore pas détailler toutes les phases de l’opération, mais
en décrire une, intéressante parcequ’elle implique une modification du modèle.

La système de stockage de stations va mémoriser une station par son nom et sa fré-
quence : l’affichage des stations va également utiliser le nom et la fréquence: ces deux para-
mètres ayant selon toute apparence une relation très forte entre eux, il convient d’en faire une
classe, qui ne figure pas encore dans notre modélisation.

En l’occurence, nous avons plutôt crée un composant Station, possédant deux proprié-
tés qu’il est possible de mettre (set) ou d’examiner (get).

172 Introduction à la programmation orientée objets

eivd Télécommunications mjn

FIGURE 20.5 Ajout d’une nouvelle classe

Il nous faut encore préciser l’affichage et le clavier : il ne servirait à rien de vouloir

modéliser un clavier réel ou un affichage réel; nous admettrons donc que le "clavier" a suffi-
samment d’"intelligence" pour ne pas simplement cracher les touches pressées par l’utilisa-
teur, mais qu’il permet de donner à tout moment le mode d’utilisation dans le quel on se
trouve. Cette démarche est importante, car elle permet de fournir une abstraction du clavier
correspondant aux spécifications; le changement d’un type de clavier pour un autre ne
devrait pas trop influencer les classes utilisant le clavier.

De même, on ne détaille pas le module d’affichage, car on ne sait pas encore à quoi il
correspond (LCD à une ligne, LCD écran, CRT, etc...). La technique effective d’affichage ne
nous intéresse pas à ce niveau, mais c’est la fonction d’affichage dont nous avons besoin. La
technique gagne donc à être confinée dans la classe affichage, et d’y rester cachée.

L’élément de commande synchronise les activités de ces divers éléments: il paraît évi-
dent que ces seuls éléments ne suffisant pas à faire un autoradio, et que l’élément de com-
mande devrait vraisemblablement avoir des interfaces avec d’autres éléments. Ainsi, il paraît
assez naturel d’offrir à notre commande la possibilité de sélectionner une station; cette possi-
bilité n’est malheureusement pas implémentable telle quelle dans notre modèle, -du moins
pour l’instant-, car nous ne disposons pas des fonctionnalités des autres packages.

Remarquons néanmoins au passage que nous avons limité à 8 le nombre de stations

stockées. Ceci devrait en principe correspondre à une requête du cahier des charges et de la
spécification.

Introduction à la programmation orientée objets 173

 eivd Télécommunications mjn

FIGURE 20.6 Précision du diagramme interface utilisateur

174 Introduction à la programmation orientée objets

eivd Télécommunications mjn

20.6 Interfaces exportés par les autres packages

Pour être en mesure d’utiliser les autres packages, alors qu’ils ne sont pas encore
implémentés, il est nécessaire de définir les conventions par lesquelles on pourra collaborer
avec eux. Le package interface utilisateur n’a en principe pas besoin d’exporter d’interface,
car dans le cas de figure que nous avons choisi, il se trouve être le maître, ou coordinateur.

Les autres packages doivent définir un intertace permettant de les utiliser.

Donc, avec notre définition de l’interface utilisateur, nous avons mis la charrue avant
les boeufs : avant de définir le contenu d’un package, il faut définir les interfaces de tous les
packages composant le système ! Comme nous ne l’avions pas fait, nous sommes contraints
de revenir en arrière, sur la première phase de modélisation, en abandonnant provisoirement
ce que nous avions réalisé jusqu’ici. C’est une perte de temps, mais elle se passe à un stade
très précoce du projet : elle est donc moins critique qu’une erreur découverte au niveau du
codage.

FIGURE 20.7 Interface du package "PartieAudio"

On remarque les interfaces entréeSignal et sortieSignal. On les a représentés ici comme

void, mais en réalité, un signal est aussi un objet, comme tous les autres: dans notre récepteur
de radio FM, on peut dire qu’il y a trois types de signaux : le signal HF (haute fréquence)
venant du préamplificateur de l’antenne, le signal FI (fréquence intermédiaire) sortant du
convertisseur de fréquence, et le signal BF (basse fréquence) qui pourra être fourni à l’étage
audio. On pourrait tout à fait modéliser ces signaux : on obtiendrait vraisemblablement quel-
que chose d’assez proche de la situation suivante (figure20.8, page176).

Introduction à la programmation orientée objets 175

 eivd Télécommunications mjn

FIGURE 20.8 Définition d’un signal

uMin, uMax correspondant à des niveaux de tension

fMin, fMax correspondant à des fréquences (bande passante)

pMin, PMax correspondant à des puissances.

Il se trouve que ces signaux ne nous intéressent pas directement, du moins du point de
vue de la modélisation que nous cherchons à réaliser. Cela ne veut pas dire qu’il n’est pas
nécessaire de documenter ! Au contraire : à ce niveau, il faut essayer de documenter tout ce
qui peut l’être, quitte à ajouter dans un commentaire que cette information est indicative. Ces
classes peuvent être définies au niveau du package principal. Nous obtenons de ce fait
l’interface suivant (figure20.9, page176) pour le package HF :

FIGURE 20.9 Interfaçage de la partie HF

176 Introduction à la programmation orientée objets

eivd Télécommunications mjn

Il faut bien comprendre que les méthodes "entréeSignal" et "sor-

tieSignal" ne sont mentionnées ici qu’à titre documentaire; elles
pourraient aussi bien être omises, puisque ce ne sont pas des
membres sur lesquels nous puissions avoir une influence. Il en
va de même pour les méthodes correspondantes de la partie
Audio: on peut les omettre sans nuire au modèle informatique.
Mais pour des raisons de documenation, et aussi por montrer
que UML peut être utilisé aussi pour modéliser des systèmes
matériels, nous conservons ces méthodes, même si elles ne sont
pas susceptibles de générer du code.

Nous avons défini des interfaces pour nos packages: nous pou-
vons dés lors compléter le package "InterfaceUtilisateur".

Introduction à la programmation orientée objets 177

 eivd Télécommunications mjn

FIGURE 1. Interface utilisateur complété

Le modèle indique que la commande va s’exécuter comme un

thread indépendent (implémentation de l’interface Runnable,
lui-même défini dans le JDK, implémentation correspondante de
la méthode run()). En conséquence, run() devient la seule
méthode publique : ceci provient du fait que l’élément de com-
mande est le "maître" de l’autoradio; en conséquence, il n’a pas
à fournir des méthodes aux autres éléments du système.

178 Introduction à la programmation orientée objets

eivd Télécommunications mjn

FIGURE 2. La partie basse fréquence

La partie HF correspondante est à peu près immédiate (figure3,

page179).

FIGURE 3. Partie haute fréquence

Ceci termine notre modélisation de classes, du moins dans la

mesure où nous n’avons pas commis d’erreurs que nous ne cons-
taterions que plus tard. Il s’agit donc de valider ce modèle, et
c’est à cet effet que sont destinés les modèles suivants.

Il faut ici noter qu’un tel diagramme de classes ne devrait en

aucun cas être établi par une personne seule; en effet, c’est de la
contestation que naissent les détections d’erreurs ou d’absences.

Introduction à la programmation orientée objets 179

 eivd Télécommunications mjn

180 Introduction à la programmation orientée objets