- Codage du prototype -

A partir des spécifications contenues dans le dossier de réalisation du prototype, le codage ne devrait pas poser de problèmes particuliers. Il concernera essentiellement cinq aspects : le codage de l'IHM et des états imprimés, le codage des classes, le codage des relations non persistantes, l'implémentation des données persistantes et enfin la réalisation de l'aide utilisateur.

Remarquons simplement que la méthode MACAO reste suffisamment générale pour ne pas proposer de langage, outil ou solution particulière pour le codage. Nous nous en tiendrons simplement la formulation de quelques conseils d'ordre général.

Codage de l'IHM

Il s'effectue de façon différente suivant la technologie employée : GUI ou Web.

Pour les GUI le codage s'effectue essentiellement à partir de composants graphiques qu'il faut compléter par les spécificités des boîtes de dialogue (objets de contrôles et actions déclenchées). Le cas le plus complexe est celui où l'on doit réaliser des affichages graphiques à l'intérieur de la région client d'une fenêtre primaire ou secondaire. Il faudra alors soit utiliser directement l'API graphique offerte par le système d'exploitation utilisé (GDI de Win32 ou .les packages Java awt de SUN), soit envisager l'utilisation de composants graphiques prédéfinis dont les possibilités sont compatibles avec les besoins. On peut trouver par exemple le FrameWork JHotDraw sur le site SourceForge ou le plugin Eclipse GEF (Graphic Editing Framework).

En ce qui concerne les IHM de type Web, il vaut mieux utiliser des logiciels d'assistance tels que FrontPage ou Dreamweaver qui éviteront de manipuler directement le langage HTML. Les pages produites ainsi pourront être agrémentées avec différents effets générés par des applets Java ou des composants ActiveX (par exemple, pour obtenir des menus déroulants) ou à partir de générateurs d'animations tels que Flash de Macromedia. Dans le contexte de l'Intranet professionnel où nous nous situons, il n'est d'ailleurs pas recommandé d'introduire des effets d'animations dans les fenêtres car l'objectif recherché est avant tout, l'efficacité.

Le codage de l'IHM devra suivre au plus près le SEF ou le SEP du dossier de réalisation et tenir compte des dessins ou des maquettes des boîtes de dialogue ou des pages Web. Il faudra notamment respecter au mieux les noms des objets visuels (contrôles, champs de formulaires, cadres…) indiqués dans les légendes.

Il faudra également penser à paramétrer l'IHM afin que l'on puisse facilement l'adapter à différents contextes matériels (définitions et palettes de couleurs des cartes graphiques et des écrans, types de souris, présence de carte son…) ou aux besoins particuliers des utilisateurs (raccourcis clavier modifiables, barre d'outils reconfigurable…). Il ne faut cependant pas abuser de ces paramétrages qui finiraient par compliquer considéra¬blement le codage sans apporter toujours le service attendu.

Toutes les classes d'IHM du prototype seront intégrées dans un paquetage avec le nom IHMAppliPn où "Appli" correspond au nom de l'application et Pn est le prototype numéro n. Par exemple IHMAssurAutoP1 correspond au paquetage contenant les classes d'IHM du prototype 1 de l'application Assurance-Auto.

Codage des états imprimés

On s'appuie sur les maquettes établies lors de l'analyse globale ou lors de la définition du prototype car elles représentent les besoins des utilisateurs qu'il faudra suivre au plus près. Comme pour l'IHM le codage des états imprimés peut intégrer des outils d'assistance de type Cristal Report pour Visual Basic ou utiliser des classes prédéfinies telles que java.awt.print.

Codage des classes autres que l'IHM

Lors du codage des autres classes (classes métiers et techniques) il faut veiller à utiliser les interfaces des classes du prototype précédent. On pourra utiliser des composants logiciels réutilisables ou des frameworks tels que les Java Beans côté client, ou les EJB (Entreprise Java Beans) côté serveur afin d'accélérer et de fiabiliser le codage. Dans ce but on cherchera à définir quelles sont les classes candidates à ce type de production.

Comme pour les classes d'IHM on veillera à placer toutes les autres classes dans un paquetage dont le nom sera fonction du prototype : CLASSAppliPn. Par exemple CLASSAssurAutoP2 est le nom du paquetage contenant toutes les classes autres que les classes d'IHM du prototype 2 de l'application Assurance-Auto.

Codage des relations non persistantes

Cet aspect est souvent l'un des plus délicats à traiter car il peut mettre en œuvre des techniques très variées (index, pointeurs simples ou multiples…) que nous ne détaillerons pas ici.

Implémentation des données persistantes

Il existe de multiples solutions à ce problème en fonction du choix réalisé pour le stockage des données persistantes : fichier séquentiel, fichier indexé, document XML, base Lotus-Notes, SGBD relationnel, SGBD orienté-objet, système de GED… Pour chaque catégorie d'outils, on dispose d'une API dont les fonctionnalités sont semblables d'un outil à l'autre : création d'un objet de connexion vers une base de données, méthodes d'ouverture et de balayage d'un ensemble d'enregistrements (recordset), etc.

Réalisation de l'aide utilisateur

Il s'agit ici de l'aide en ligne pouvant se matérialiser essentiellement à trois niveaux :

• l'aide générale à partir de l'option "?" située dans le menu général de l'application. Cette aide peut se décliner de différentes façons : présentation générale, index, à propos…
• l'aide associée à une boîte de dialogue ou à une page Web complexe permettant de décrire son fonctionnement à l'utilisateur,
• l'aide contextuelle utilisable à partir du bouton droit de la souris, de la touche de fonction F1 ou du passage du pointeur souris (info-bulle) permettant d'expliquer le rôle d'une icône ou d'un contrôle particulier.

Ici encore, l'emploi d'outils de réalisation qui s'appuie sur un format de fichier d'aide peut s'avérer intéressant.

Application de la règle de non-régression des prototypes

Rappelons que cette règle rappelée ici constitue l'un des points forts de la méthode MACAO car elle permet de s'assurer qu'aucune dérive n'apparaîtra dans la production du logiciel. Elle peut être considérée comme un garde-fou permettant d'empêcher les développeurs de modifier de façon anarchique les classes déjà testées et recettées. En effet toute modification intempestive de ces classes peut entraîner une réaction en chaîne dans l'apparition de bogues et, par voie de conséquence des retards importants dans le développement.

Cette règle impose que les développeurs du prototype N ne puissent pas modifier librement des sources du prototype N-1. Seuls les exécutables et les fichiers sources privés des droits de modification, sont à leur disposition afin de permettre l'accès aux classes d'interface ou la création de classes dérivées en copiant-collant certaines classes ou certaines méthodes.

Dans certains cas particuliers le développeur pourra demander une dérogation pour enfreindre cette règle sous la forme d'une DRNR (Dérogation à la Règle de Non Regression). Ce cas peut se produire si la structure des classes n'a pas été suffisamment bien étudiée afin de limiter les dépendances et contredit le principe d'ouverture/fermeture.

Une dérogation permettra alors, soit d'effectuer un refactoring d'un prototype recetté afin de diminuer les dépendances, soit de modifier directement une classe d'un prototype recetté.