1- Document de conception

Guide des travaux pratiques automne 1997 page 1
Aide à la rédaction d’un travail pratique
idée originale :
Gilles-Philippe Grégoire
Stéphane Lévesque
Anne Raby
Adaptation:
Pierre Bélisle

Guide des travaux pratiques automne 1997 page 2
Table des matières
1. DOCUMENT DE CONCEPTION ..................................................................................................................................................... 3
DÉFINITION DU PROBLÈME ...................................................................................................................................................................... 3
PRÉCISIONS CONCERNANT LES SPÉCIFICATIONS ...................................................................................................................................... 3
LE DIAGRAMME HIÉRARCHIQUE .............................................................................................................................................................. 3
L’ALGORITHME GLOBAL DE HAUT NIVEAU .............................................................................................................................................. 4
L’ALGORITHME SPÉCIFIQUE .................................................................................................................................................................... 4
LA STRATÉGIE DE VÉRIFICATION(LES RÉSULTATS ATTENDUS) ................................................................................................................. 4
2. CODE SOURCE .................................................................................................................................................................................. 6
3. JEUX D'ESSAI ..................................................................................................................................................................................... 7
JEUX D'ESSAI (LES RÉSULTATS OBTENUS) ............................................................................................................................................... 7
LES LIMITES DU PROGRAMME ................................................................................................................................................................. 7
4. GUIDE DE L’UTILISATEUR ............................................................................................................................................................ 7
5. DISQUETTE ........................................................................................................................................................................................ 8
6. QUALITÉ DE LA PRÉSENTATION ................................................................................................................................................ 8
ANNEXE A ............................................................................................................................................................................................... 9
LA DISQUETTE : ....................................................................................................................................................................................... 9
L’ENVELOPPE .......................................................................................................................................................................................... 9
LA PAGE COUVERTURE DU DOCUMENT .................................................................................................................................................. 10

Guide des travaux pratiques automne 1997 page 3
1. Document de conception
Définition du problème
À FAIRE
 Vous devez montrer, dans vos propres mots, que vous comprenez ce qu’il faut faire. Vous expliquez le problème, le défi
à résoudre ou à surmonter.
 Le document doit être composé de manière à ce que n’importe quel collègue, qui n’a pas lu l’énoncé préalablement,
puisse bien comprendre ce qu’il y a à faire
À NE PAS FAIRE
 Cette partie n’est pas une copie de l’énoncé
 Ne doit pas faire état de la méthode de solution
 N’est pas une description du programme
Précisions concernant les spécifications
Ce sont les détails importants ; Les contraintes de l'usager ou du contexte.
On retrouve les exigences relatives au problème telles :
 Formule de calcul
 Règles d’affaires, règles de traitement
 Conditions de validation
****On doit en combinant ces deux parties(définition du problème et précisions concernant les spécifications, retrouver toutes les
parties essentielles à la résolution du problème. Tous les détails doivent y être.
Le diagramme hiérarchique
À FAIRE
 identifier chacune des étapes logiques du programme
 Chaque boîte représente une étape qui devrait par la suite correspondre à une procédure
 utiliser des verbes, énoncer une action
 arrêter de décomposer quand les étapes peuvent naturellement être transposées en code
 Il n’est pas nécessaire de le faire par ordinateur, vous pouvez le faire à la main (ÉCRITURE LISIBLE) mais
faites-le complètement, c’est-à-dire les boîtes, et les lignes reliant les boîtes(seulement pour le premier travail)
À NE PAS FAIRE
 Un arbre décisionnel, mais une structure de programme
 Un ordinogramme, un organigramme ou un structurogramme détaillé(condition, boucle)
 Un diagramme de flux, ne pas utiliser de flèches

Guide des travaux pratiques automne 1997 page 4
L’algorithme global de haut niveau
À FAIRE
 S’inspirer du diagramme hiérarchique.
 Donner le fonctionnement de ce qui se passe à l’intérieur du premier niveau du diagramme
 refléter ce que sera le programme, abstraction faite du langage de programmation,
 utiliser des descriptions, pas des étiquettes,
À NE PAS FAIRE
 mentionner des appels de procédure ou des noms de procédure
 utiliser du code ou des symboles spécifiques au code
L’algorithme Spécifique
À FAIRE
 Prendre les parties de l'algorithme global qui nécessitent d'être plus spécifiées
 Si dans un algorithme spécifique, des parties méritent spécifications, on le fait ici.
Cet algorithme spécifique en question, devient donc comme un algorithme global.
 Écrire autant d'algorithmes que nécessaires pour la bonne compréhension de la solution.
 Détailler les algorithmes même s'ils sont connus (ex. algorithme de tri )
À NE PAS FAIRE
 mentionner des appels de procédure ou des noms de procédures ou fonctions
 utiliser du code ou des symboles spécifiques au code
 oublier les algorithmes de calcul
La stratégie de vérification(les résultats attendus)
À FAIRE
 une explication de la démarche de vérification du programme
 on explique le cheminement des tests, pourquoi on fait tel ou tel test,
 c’est ce à quoi on s’attend
 on doit retrouver les raisons qui justifient chacun des tests
 on explique les cas normaux, limites, hors bornes et erronés, en mentionnant des valeurs pour chacun des tests
 tests, à la main, de ce que le programme devrait donner
 calculer les résultats que l’on devrait avoir, pour ensuite les comparer avec l’exécution, s’il y a concordance, le
programme devrait être bon
 On doit retrouver les résultats attendus des essais fournis par le professeur ET les essais personnels, qui
proviennent de la stratégie de vérification
 Peut-être sous forme de tableau (idéalement)
 Numéroter les tests et faire correspondre ces tests avec les tests sur l’exécution
À NE PAS FAIRE
 l’exécution du programme
 seulement l’énoncé des tests, faut aussi retrouver les explications

Guide des travaux pratiques automne 1997 page 5
Les structures de données
À FAIRE
 expliquer les structures de données utilisées dans le programme (s’il y a lieu)
 on explique comment est formée la structure, ce qu’il y a dedans, comment elle est utilisée,
 doit être clair et donner un aperçu de ce que l’on retrouve dans le programme, pour ne pas avoir à le deviner
 s’il n’y en a pas, dans le programme, ne rien écrire
 il faut inclure, entre autres :
- les types construits
- les enregistrements
- les tableaux
- les fichiers
- les matrices
- etc.
- ...
À NE PAS FAIRE
 du code ADA ou autre
 une liste exhaustive des variables retrouvées dans le programme
 l’explication des différentes procédures du programme
Description des entrées/sorties
pour chaque future procédure ou fonction
À FAIRE
 Décrire tout ce qui entre(provient du clavier, de fichiers etc.) et qui sort du programme principal(Écran, fichiers etc.)
 Décrire tout ce qui entre et qui sort des sous-programmes
 On y retrouve une description, un nom, un pseudo-type
 ENTRÉE : ce sont les futurs paramètres formels en IN ou IN OUT
 SORTIE : ce sont les futurs paramètres formels en OUT ou IN OUT
À NE PAS FAIRE
 Un écran de sortie provenant de l’exécution du programme
 La transcription de la partie déclarative
 Ne pas utiliser les noms de variables spécifiques au programme