Fichiers - COBOL Énoncé COUREUR SEMAINE FAIT A FAIRE C1

Université de NANTES
Faculté des Sciences et des Techniques
IUP - MIAGE
Deuxième année
Fichiers - COBOL
(Resp. A. VAILLY)
TP n° 2 : Gestion d'une équipe de coureurs cyclistes
Le dossier est à rendre pour le 10 mai 2008 au plus tard. Il sera déposé SUR LA PLATEFORME MADOC uniquement, en format pdf exclusivement.
Les tests en salle machine auront lieu dans la semaine du 13 au 16 mars 2008. La présence
des équipes au complet est requise.
Énoncé
Objectif : mise en place d'un mini-logiciel de gestion d'une équipe de coureurs cyclistes, constitué d'un
programme principal et de sous-programmes.
1- Description de la structure de données :
On se situe dans le cadre du développement d'une application de gestion de programmes
d'entraînement de coureurs cyclistes. Chaque coureur dispose d'un programme adapté à sa morphologie, sa
forme du moment et ses objectifs, exprimé en termes de kilométrage à réaliser. Chaque coureur dispose
d'un entraîneur. Chaque entraîneur a au moins un coureur. Il peut en avoir plusieurs.
Le système d'information de cette application peut être décrit par le modèle entités associations
propriétés suivant :
ENTRAINEUR
Numéro entraîneur
Nom
Prénom
Diplôme
1, n
SEMAINE
S'OCCUPE DE
A FAIRE
0, n Numéro semaine
GrandTour
Km-à-faire
0, n
COUREUR
Numéro coureur
1, 1 Nom
Prénom
0, n
Adresse
Total-Km-faits
COBOL-Travaux pratiques
décembre 27, 2007
C1
©
0, n
FAIT
Km-faits
sujet tapé par Alain VAILLY
1
Université de NANTES
Faculté des Sciences et des Techniques
IUP - MIAGE
Deuxième année
Les coureurs enregistrés n'ont pas forcément de programme d'entraînement mémorisé. Il est
également possible d'avoir dans la base des coureurs qui n'ont encore parcouru aucun kilomètre. Par contre,
tous ceux qui en ont parcouru avaient un programme (la contrainte d'inclusion garantit que chaque coureur
ne s'entraîne que les semaines durant lesquelles il doit le faire).
La contrainte C1 permet de vérifier que les coureurs ne dépassent pas leur programme. Elle
exprime le fait que le nombre de kilomètres parcourus par un coureur pour chaque semaine est inférieur ou
égal au nombre de kilomètres à faire.
La propriété Total-Km-faits correspond à la somme des kilomètres faits par le coureur. Elle ne
devrait en théorie pas figurer dans ce schéma, car elle est calculable. Nous la maintenons par souci de
simplification de ce sujet.
Cette structure de données peut être matérialisée par cinq fichiers :
- fichier des coureurs (fcour), séquentiel indexé, de clé primaire le numéro de coureur (CODCOUR), de
clé secondaire le numéro d'entraîneur (ENTRAINEUR), ayant la structure suivante :
CODCOUR
NOM
PRENOM
ADRESSE
TOTAL-KM-FAITS
entier 3
chiffres
9 (3)
20 alpha.
num.
X (20)
20 alpha. num.
25 alpha.
num.
X (25)
entier 5 chiffres
X (20)
9 (5)
ENTRAINEU
R
entier 3
chiffres
9 (3)
- fichier des entraîneurs (fentr), séquentiel indexé, de clé primaire le numéro d'entraîneur (CODENTR),
ayant la structure suivante :
CODENTR
NOM
PRENOM
DIPLOME
entier 3
chiffres
9 (3)
20 alpha.
num.
X (20)
20 alpha. num.
25 alpha.
num.
X (25)
X (20)
- fichier des semaines d'entraînement (fsem), séquentiel indexé, de clé primaire le numéro de semaine
(CODSEM), de structure :
CODSEM
GRANDTOUR
entier 2 chiffres
99
10 alpha.
X (10)
la variable GRANDTOUR pouvant prendre les valeurs suivantes : FRANCE, GIRO, VUELTA, NULL,
selon que la semaine est une semaine de grand tour ou non.
- fichier des programmes à réaliser (fprog), séquentiel indexé, de clé primaire le couple (numéro
coureur, numéro semaine), avec deux clés secondaires, CODCOUR et CODSEM, de structure :
CODCOUR
CODSEM
KM-A-FAIRE
entier 3 chiffres
9 (3)
entier 2 chiffres
99
entier 4 chiffres
9 (4)
- fichier des programmes réalisés (freal), séquentiel indexé, ayant pour clé primaire le couple (numéro
coureur, numéro semaine), avec deux clés secondaires, CODCOUR et CODSEM. La structure de ce fichier
est la suivante :
COBOL-Travaux pratiques
décembre 27, 2007
CODCOUR
CODSEM
KM-FAITS
entier 3 chiffres
9 (3)
entier 2 chiffres
99
entier 4 chiffres
9 (4)
sujet tapé par Alain VAILLY
2
Université de NANTES
Faculté des Sciences et des Techniques
IUP - MIAGE
Deuxième année
2) Interface du logiciel :
Tous les écrans seront standardisés. Ils seront tous composés de trois parties, selon le modèle cijoint :
80 colonnes
4 à 6 lignes
<date jour>
<NOM APPLICATIF>
<nom fonction>
13 à 15 lignes
4 lignes
23 lignes
<message erreur ou autre>
<liste des invites des différents choix>
Choix : <saisie du choix>
Les différentes parties jouent des rôles différents :
- entête (partie supérieure) : 4 à 6 lignes
désignation de l'application, fonction en cours, date du jour et ligne de séparation
- corps (partie médiane) : 13 à 15 lignes
affichage de résultats, saisies autres que les invites...
- bas de page (partie inférieure) : 4 lignes
ligne 19 : ligne de séparation
ligne 20 : ligne pour les messages provenant d'erreurs de saisie, de manipulation...
ligne 21 : ligne d'invite indiquant les différents choix de poursuite
ligne 22 : ligne pour saisir le caractère représentant le choix.
L'écran de présentation du menu sera structuré différemment des autres : présentation des
différents choix et saisie du choix dans la partie médiane, partie inférieure ne contenant que le message
d'erreur de saisie.
3) Structuration du logiciel :
L'application comprend les fonctionnalités suivantes :
F0 : affichage des coureurs n'ayant pas de programme d'entraînement pendant les grands tours
F1 : mise à jour du fichier des coureurs (ajout, suppression, modification)
F2 : enregistrement des programmes en début de saison (association A FAIRE)
F3 : enregistrement des entraînements effectués (association FAIT)
F4 : mise à jour des entraîneurs (ajout, suppression, modification)
F5 : édition de l'état d'avancement des entraînements (par coureur, par semaine)
F6 : classement des coureurs
F7 : mise à zéro des programmes associés à une semaine donnée
COBOL-Travaux pratiques
décembre 27, 2007
sujet tapé par Alain VAILLY
3
Université de NANTES
Faculté des Sciences et des Techniques
IUP - MIAGE
Deuxième année
L'architecture fonctionnelle du logiciel à développer est une arborescence :
Affichage oisifs
0
MENU
M)enu Q)uitter
Affichage oisifs
Mise à jour coureurs
Programmes à faire
Programmes faits
Mise à jour entraîneurs
État avancement entraînements
Classement coureurs
RAZ programmes
Quitter
Mise à jour coureurs
1
M)enu Q)uitter
Programmes à faire
2
M)enu Q)uitter
Programmes faits
3
M)enu Q)uitter
Mise à jour entraîneurs
4
M)enu Q)uitter
État avancement
entraînements
M)enu
Q)uitter
5
0
1
2
3
4
5
6
7
Q
Classement coureurs
6
M)enu Q)uitter
RAZ programmes
7
M)enu Q)uitter
Chaque fin d'exécution d'une feuille de cet arbre doit permettre à l'utilisateur de choisir soit de
revenir au menu, soit de quitter l'application.
4) Saisies :
Les données saisies sont supposées pleines d'erreurs. Toutes les données saisies devront donc
être vérifiées. Les données erronées donneront lieu à affichage de messages d'erreurs appropriés (dans la
partie inférieure de l'écran), effacement des données erronées (afin de permettre une re-saisie) et, après la
nouvelle saisie, effacement du message d'erreur précédent. Le nombre d'essais sera limité à trois pour
chaque saisie.
Le choix de la partie du logiciel à exécuter (menu) fourni par l'utilisateur sera vérifié AVANT de
lancer l'exécution.
5) Travail à faire :
5.1) organisation : le travail est exécuté par des équipes de quatre (exceptionnellement cinq). Chaque équipe
désignera, dès le début, un chef de projet.
5.2) travail de l'équipe : tous les membres de l'équipe devront analyser et programmer le logiciel. Une
organisation avec un programme principal (pour l'affichage du menu) et des sous-programmes externes, un
par module, sera mise en place. Le programme principal devra être programmé en premier. Il fera
"normalement" appel aux divers sous-programmes externes, un par fonction, selon le principe développé
en TD (cf. TD n° 4, programme P4). Même si une fonction n'est pas encore prête, le sous-programme
externe correspondant devra donc être présent dès le début. Il comportera AU DEBUT un écran "par défaut"
qui affichera, en partie médiane, un message indiquant que la fonction n'est pas encore disponible. Le
"vrai" sous-programme une fois testé, ce sous-programme par défaut disparaîtra au profit du "vrai".
Chaque équipe devra analyser et programmer les fonctions ci-après :
F0 : affichage des coureurs n'ayant pas de programme à faire pendant les grands tours. L'utilisateur aura le
choix entre faire un affichage ciblé sur UN grand tour précis (saisi à l'écran) ou TOUS les grands tours. Si
COBOL-Travaux pratiques
décembre 27, 2007
sujet tapé par Alain VAILLY
4
Université de NANTES
Faculté des Sciences et des Techniques
IUP - MIAGE
Deuxième année
cette dernière option est choisie, un coureur sera considéré comme oisif s'il n'a aucun programme à faire
pendant toutes les semaines de tous les tours. Si l'option UN est choisie, le coureur devra, pour être
affiché, n'avoir aucun programme durant toutes les semaines du tour en question.
F1 : mise à jour des coureurs, comprenant l'enregistrement d'un coureur, la prise en compte des
modifications et la suppression d'un coureur.
Les modifications à enregistrer concernent toutes les propriétés SAUF le numéro de coureur (un
coureur change de numéro en perdant l'ancien —il s'agit donc d'une suppression de coureur— et gagnant le
nouveau —il s'agit donc ensuite d'enregistrer un nouveau coureur—) et le numéro d'entraîneur. Ces
modifications seront acceptées uniquement si le coureur existe. Les programmes à faire ou faits ne sont
pas concernés par cette opération.
L'enregistrement d'un coureur se fait en fournissant tous les attributs nécessaires, ainsi que le
numéro de son entraîneur. Si cet entraîneur n'existe pas, il sera créé (par appel au sous-programme de
création contenu dans la fonction F4). Le nouveau coureur n'a pas de programme d'entraînement à faire, ni
a fortiori de programme fait.
La suppression d'un coureur ne peut se faire que si ses programmes sont déjà supprimés. Si son
entraîneur ne s'occupait que de lui, il sera également supprimé.
F2 : enregistrement des programmes à faire. Cet enregistrement ne peut être accepté que si le coureur
existe.
F3 : enregistrement des programmes faits. Cet enregistrement ne peut être accepté que si le coureur existe
et si les contraintes (celle qui est nommée C1 sur le schéma et la contrainte d'inclusion) sont vérifiées. Le
nombre total de kilomètres parcourus par le coureur est mis à jour.
F4 : mise à jour des entraîneurs, comprenant l'enregistrement d'un entraîneur, la prise en compte des
modifications et la suppression d'un entraîneur.
L'enregistrement d'un entraîneur ne peut se faire que s'il s'occupe d'un coureur. Seront donc
saisies les informations suivantes : numéro d'entraîneur, nom, prénom, diplôme. Le (ou les) numéro(s) de
coureurs dont il s'occupe sera (seront) ensuite fourni(s). Si ces coureurs n'existent pas, ils seront créés (par
appel du sous-programme de création contenu dans F1).
Tous les attributs de l'entraîneur sont modifiables, à l'exception du numéro.
La suppression d'un entraîneur s'accompagnera de celle de ses coureurs. Elle ne pourra toutefois
se faire que si les programmes de ces derniers (qu'il s'agisse de ceux à faire ou de ceux faits) n'existent
plus.
F5 : édition de l'état d'avancement des programmes d'entraînements. Deux versions de cet état sont
demandées. Dans les deux cas, il s'agit de produire une liste décrivant tous les entraînements. La première
version les présente semaine par semaine, la seconde coureur par coureur.
Les fichiers sont supposés sans erreur.
Version 1 :
Semaine n°
Coureurs
Nom
Prénom
COBOL-Travaux pratiques
décembre 27, 2007
Entraînements
Adresse
prévus
réalisés
sujet tapé par Alain VAILLY
5
Université de NANTES
Faculté des Sciences et des Techniques
IUP - MIAGE
Deuxième année
TOUS les coureurs figureront dans cet état, pour chaque semaine. Si, une semaine donnée, un
coureur n'a pas d'entraînement à faire, la valeur 0 sera inscrite dans les cases prévus et réalisés.
Version 2 :
Nom
Prénom
Adresse
Coureur
Entraînements
Semaine
prévus
réalisés
TOUTES les semaines figureront sur le document. Si, pour une semaine donnée, le coureur n'a
pas d'entraînement prévu, la valeur 0 sera inscrite dans les cases prévus et réalisés.
F6 : classement des coureurs, selon le kilométrage réalisé. Les coureurs seront classés en ordre décroissant
des valeurs prises par l'attribut TOTAL-KM-FAITS.
F7 : remise à zéro des programmes d'une semaine donnée. L'utilisateur fournira le numéro de la semaine
concernée. Tous les programmes à faire cette semaine-là seront supprimés, tous les programmes
réellement faits également. L'utilisateur aura ensuite le choix de revenir au menu général ou bien de
fournir une autre semaine.
5.3) rôle du chef de projet : le chef de projet est chargé, plus spécifiquement, de l'intégration des sousprogrammes "dans" le logiciel. C'est lui qui crée le programme principal, teste son fonctionnement,
remplace les sous-programmes "par défaut" par les "vrais", dès que possible. Le chef de projet doit aussi
piloter l'équipe, en surveillant l'avancement du travail, en aidant, éventuellement, un co-équipier.
C'est, enfin, le chef de projet qui crée un répertoire GROSTP (avec les droits nécessaires pour
que chaque membre de l'équipe puisse y accéder), y place les jeux d'essais, y remet éventuellement ces jeux
d'essais s'ils sont altérés -en allant les chercher sur l'Intranet). L'intégration des sous-programmes dans ce
répertoire sera effectuée sous la responsabilité du chef de projet. Les tests de non-régression (ie. globaux)
seront réalisés par lui.
5.4) répartition des tâches au sein de l'équipe : soit une équipe quelconque, composée de cinq étudiants,
appelés A, B, C, D et E. A est le chef d'équipe. La répartition des tâches peut être la suivante :
A : (chef de projet) création du programme principal, intégration, tests de non-régression, analyse et
programmation F0
B : analyse et programmation F1, tests unitaires, import dans GROSTP
C : analyse et programmation F2, F3 et F7, tests unitaires, import dans GROSTP
D : analyse et programmation F4 et F6, tests unitaires, import dans GROSTP
E : analyse et programmation F5, tests unitaires, import dans GROSTP
D'autres organisations sont possibles. Elles sont toutefois déconseillées. Le "KIFEKOUA" sera
défini dès le début du TP et fourni aux enseignants.
NB : la fonction F1 est la plus "difficile" des huit. Il serait prudent de la confier à un bon. (B stands for
"bon").
COBOL-Travaux pratiques
décembre 27, 2007
sujet tapé par Alain VAILLY
6
Université de NANTES
Faculté des Sciences et des Techniques
IUP - MIAGE
Deuxième année
6) "documents" à rendre :
Chaque équipe rendra un seul dossier, en format pdf. Il devra comporter une partie analyse
algorithmique (une douzaine de pages au maximum) et une partie jeux d'essais (avec une description des
essais prévus par l'équipe, avec les résultats escomptés, rédigée sur un maximum de quatre pages).
Le listing de chaque programme (programme principal, sous-programmes externes), le "chemin"
Linux indiquant où sont situées les sources, ainsi que la ligne de compilation seront fournis en annexe du
dossier.
Ce dossier sera déposé sur la plate-forme MADOC, dans le répertoire créé à cet effet. La
personne qui déposera ce dossier sera le chef de projet, le dépôt se faisant sous son SEUL nom.
COBOL-Travaux pratiques
décembre 27, 2007
sujet tapé par Alain VAILLY
7