Vous êtes sur la page 1sur 14

CHAPITRE 20

Un exemple complet

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.

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 !

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

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

que nous appelons FMRadio. FIGURE 20.2 La paquetage Le package est initialement vide; nous allons le

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

(figure20.3, page171). FIGURE 20.3 Première décomposition Cette première décomposition identifie les sous-systèmes

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.

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

FIGURE 20.4 Décomposition de l’interface utilisateur A ce niveau, on peut commencer à définir les

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

eivd

Télécommunications

mjn

FIGURE 20.5 Ajout d’une nouvelle classe

mjn FIGURE 20.5 Ajout d’une nouvelle classe Il nous faut encore préciser l’affichage et le clavier

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

nous intéresse pas à ce niveau, mais c’est la fonction d’affichage dont nous avons besoin. La

La technique effective d’affichage ne

).

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.

eivd

Télécommunications

mjn

FIGURE 20.6 Précision du diagramme interface utilisateur

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"

FIGURE 20.7 Interface du package "PartieAudio" On remarque les interfaces entréeSignal et sortieSignal. On

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

eivd

Télécommunications

mjn

FIGURE 20.8 Définition d’un signal

mjn FIGURE 20.8 Définition d’un signal uMin, uMax correspondant à des niveaux de tension fMin,

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

pour le package HF : FIGURE 20.9 Interfaçage de la partie HF 176 Introduction à la

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

eivd

Télécommunications

mjn

FIGURE 1.

Interface utilisateur complété

mjn FIGURE 1. Interface utilisateur complété Le modèle indique que la commande va s’exécuter comme un

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.

eivd Télécommunications mjn FIGURE 2. La partie basse fréquence La partie HF correspondante est à
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
(figure3, page179). FIGURE 3. Partie haute fréquence Ceci termine notre modélisation de classes, du moins dans

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.

eivd

Télécommunications

mjn