Exemple de découpage de projet

Heureusement pour eux, ils avaient pris des notes lorsque leur professeur adoré s'était lancé dans une présentation endiablée sur la technique de développement par boîtes noires et sur l'idée d'interface dans un système informatique. Ils se souviennent que:

Cette tactique semblant être une bonne alternative à celle où l'un(e) des membres de l'équipe programme et l'autre le/ la regarde, ils se sont réunis autour d'un bol de bouillon de poulet et de quelques biscuits sodas et se sont demandés comment ils pourraient découper le travail pratique auquel ils s'attaquaient.

Il est présumé, pour la suite de cette fiction, que vous avez accès à l'énoncé du travail pratique auquel s'attaquent Fritz et Wenda.

Fritz et Wenda ne sont pas nés de la dernière pluie, et ont vite réalisé qu'il y aurait plus d'une IPM dans ce travail pratique.

Premier constat: le TP0--POQédex^MD ayant été réalisé sur une base individuelle, il leur faut maintenant faire un choix entre:

Pas très chauds à l'idée de se taper beaucoup de travail supplémentaire, nos amis choisissent de conserver celui de Wenda, qui leur semble avoir une esthétique plus léchée que celui de Fritz.

De toute manière, ils savent qu'une partie du code du POQédex^MD devra être extrait de cette feuille et généralisée à l'ensemble du projet--les requêtes, la communication avec le serveur, ce genre de choses.

C'est déjà, pour eux, une décision de design importante: dans le but d'avoir un système relativement uniforme, du moins en surface, ils devront construire leur POQespace^MD de manière à ce que le POQédex^MD et lui s'agencent harmonieusement.

Second constat: ils devront demander à l'utilisateur de s'identifier par un surnom et par un choix de dresseur (re: «RQJESUIS») avant de lui permettre de jouer. Conséquence: il leur faudra obtenir au préalable la liste des dresseurs disponibles du serveur (re: «RQLISTEDRESSEURS»).

Ayant eu vent qu'il leur faudra éventuellement--lors du prochain TP--se connecter à un serveur quelque part sur Internet, ils choisissent de faire apparaître un dialogue servant à la connexion et à la saisie de ces deux informations, qui servira avant que ne soit dévoilée l'interface de jeu à proprement dit.

Fritz et Wenda sont des «vlimeux», et comptent profiter du temps où l'usager écrit son surnom et choisit son dresseur pour charger en mémoire--dans un tableau--les images qui seront affichées sur leur POQespace^MD. Ils espèrent que cela améliorera les performances de leur programme.

Troisième constat: il leur faudra une interface de jeu. Cela semble être une tâche en soi.

Ils conviennent que, puisque c'est le POQédex^MD de Wenda qui sera utilisé dans leur POQespace^MD, c'est à Fritz que reviendra la tâche de s'occuper de l'interface du POQespace^MD à proprement dit. Wenda, de son côté, se chargera de l'interface de saisie de l'identité de l'usager.

Fritz et Wenda conviennent qu'il leur faudra peut-être ajouter d'autres IPM, entre autres pour aider au déverminage de leur POQespace^MD--calibrer la fréquence avec laquelle les requêtes sont envoyées, par exemple, ou afficher les réponses reçues du serveur, le temps que tout tombe en place. Ils conviennent qu'ils reviendront là-dessus lorsqu'ils auront une meilleure idée des problèmes exacts à régler.

Certains modules semblent clairement nécessaires à Fritz et à Wenda.

Il leur semble clair qu'ils auront besoin d'un point d'entrée global au programme--la procédure «main»--qui aura entre autres pour rôle d'appeler des procédures d'initialisation pour chaque module important--le genre de truc qu'on n'appelle qu'une fois pour chaque module, au démarrage--puis d'assurer le bon démarrage du programme. Ils choisissent d'y aller d'un module nommé «modPrincipal».

Le serveur étant une DLL, il leur faudra rédiger quelques «Declare». Ils choisissent de les déposer dans un module nommé «modDéclarations».

L'idée d'un ID de requête est omniprésent dans le protocole. Ils conviennent donc d'écrire un module «modGestionId» qui ne servira qu'à cette fin. L'interface minimale de ce module sera:

Initialiser les ID--une procédure «InitID» ne prenant pas de paramètres devrait suffire. Elle devra être appelée par «main» lors du lancement du système.

Obtenir le prochain ID--une fonction «ProchainID» ne prenant pas de paramètres et retournant le prochain ID à utiliser.

Les deux conviennent que c'est là à peu près tout ce dont on a besoin d'un gestionnaire de ID.

Fritz et Wenda considèrent important de conserver en un seul lieu les informations propres à l'usager et à son dresseur (surnom de l'usager, nom et index du dresseur, direction dans laquelle le dresseur se dirige, etc.).

Ils établissent qu'il leur faudrait pour y arriver un module «modInfosUsager» qui dévoilerait des «Set» et des «Get» pour chacune de ces informations, de même que quelques constantes publiques pour noter la direction courante du dresseur. On ne sait jamais quand ça pourrait devenir utile...

Même si nous le mentionnons pas ici, Fritz et Wenda s'entendent tout de suite sur les noms de chaque constante et de chaque sous-programme, de même que sur les paramètres des sous-programmes à rédiger. Cela est essentiel s'ils veulent être en mesure d'intégrer leurs travaux une fois ceux-ci bien avancés.

Fritz et Wenda s'attaquent ensuite à un gros morceau: la gestion des requêtes.

Ils décident de centraliser le code à cet effet dans un module nommé «modRequêtes», qui dévoilera une fonction nommée «CréerRQXYZ» pour chaque requête «XYZ» à rédiger, et qui prendra les paramètres appropriés à la requête en question. Ils en profitent pour dresseur tout de suite la liste de ces requêtes, pour être certains de ne pas en oublier, et pour s'entendre tout de suite sur l'ordre et sur le type des paramètres dans chaque cas.

Ils décident aussi d'y dévoiler une procédure «TraiterRéponse» qui prendra en paramètre une réponse et la traitera. Fritz suggère que cette procédure soit essentiellement une grande sélective, qui fasse appel (à l'interne à une procédure de traitement distincte par type de requête à traiter. Wenda réplique bien entendu à cela qu'il faudra, conséquemment, avoir de bons outils pour bien déterminer la requête correspondant à chaque réponse.

Puis, Fritz et Wenda s'attaquent à un autre gros morceau: la communication entre leur client et le serveur.

Ils choisissent d'y aller d'un couple d'instances de «Collection» pour les requêtes à envoyer et envoyées, séquentielles ou non--le prof semblait dire que c'était une bonne idée, et il se trouve qu'en y pensant bien, ils aiment l'idée eux aussi. Comme quoi les profs ne sont pas toujours si bêtes que ça.

Ils conviennent que l'interface sera ici essentiellement faite de deux procédures: «SoumettreRQ» pour soumettre une requête «batch», et «SoumettreRQSéq» pour les requêtes à traiter de façon séquentielle. À leur avis, une fois qu'un module aura soumis une requête--ce qui l'insérera dans la «Collection» appropriée parmi celles servant à envoyer, le reste devrait se faire automatiquement, et la réception d'une réponse fera alors appel au «TraiterRéponse» de «modRequêtes».

Fritz et Wenda s'adonnent aussi à la spécification de quelques autres modules et à celle de quelques autres interfaces--un module qui servira à représenter la carte avant de l'afficher, par exemple; un autre qui servira à entreposer les images servant à l'affichage des surfaces sur l'interface de jeu; un qui gardera en note les paramètres du monde sur lequel le dresseur se déplace; etc.

Mais vous ne pensiez tout de même pas que nous allions tout vous raconter?

 

Fritz et Wenda ont ensuite fait des choix quant à ce que chacun ferait. Leurs objectifs:

Dans leur petit échéancier «interne», ils se sont gardé une bonne semaine «libre» vers la fin pour arrimer leurs différents modules les uns aux autres et déverminer les petits accrocs, presque inévitables lorsqu'on attaque pour la première fois une autre manière de voir les choses.

Puisque Fritz et Wenda veulent tous deux réussir leur cours, ils ont eu la sagesse de tenir compte du fait que chacune et chacun doit comprendre l'ensemble des éléments du cours. Ainsi, ils ont convenu de se mandater l'un(e)/ l'autre de former l'autre/l'un(e) sur les trucs plus nouveaux du projet, côté technique.

Sans vouloir se donner respectivement un cours complet, ils se sont entendus pour garder un exemple simple et clair de chaque truc leur paraissant nouveau et pertinent. Expliquer à quelqu'un d'autre, après tout, ça nous oblige nous-mêmes à comprendre ce dont on doit parler, et ça favorise l'obtention de bons résultats.

Fritz et Wenda se sont aussi donné comme consigne de se rencontrer une demi-heure au début de chaque semaine pour faire le point et s'ajuster si quelque chose accroche un peu, et pour essayer de prévoir les minitests toujours susceptibles de leur exploser en plein visage--si on se sépare le boulot, il faut quand même se tenir prêt pour ces horribles créations pédagogiques que sont les minitests surprise du cours!

Finalement, Fritz et Wenda ont convenu de garder en note ce qui aura bien (et moins bien) fonctionné de ce premier jet, pour réajuster le tir la prochaine fois. Au fond, sachant qu'il est vraiment difficile d'être efficace la première fois qu'on essaie quelque chose, pourquoi ne pas apprendre de nos erreurs et profiter du cours, lieu privilégié pour faire des expériences, pour devenir vraiment efficace?