Développement. Clients : Jacques Lamothe & Matthieu Lauras. Nathalie Coisne Pinelli Florian Journeau Stéphane Ruot Option GSI 2008 Février 2008

Transcription

1 Projet BEER WITCH Développement Clients : Jacques Lamothe & Matthieu Lauras Nathalie Coisne Pinelli Florian Journeau Stéphane Ruot Option GSI 2008 Février

2 SOMMAIRE Sommaire...2 Introduction...5 Gestion de projet Organisation interne du groupe : attribution des fonctions...6 a. Chef de projet : M. Florian JOURNEAU...6 b. Responsable organisationnel et avancement du projet : M. Stéphane RUOT...6 c. Responsable des rapports : Mlle Nathalie COISNE PINELLI Répartition des tâches...6 a. Florian...7 b. Stéphane...7 c. Nathalie Planification du projet...7 a. La réalisation du diagramme de Gantt...7 b. Le suivi de projet : actualisation des Gantt...10 c. Le consommé des heures...12 Description de la base de données La table «partie»...14 a. Son rôle...14 b. Ses attributs...15 c. Ses relations La table «chainelog»...15 a. Son rôle...15 b. Ses attributs...16 c. Ses relations La table «maillon»...17 a. Son rôle...17 b. Ses attributs...17 c. Ses relations La table «resultats»...18 a. Son rôle...18 b. Ses attributs...18 c. Ses relations La table «parametres»...19 a. Son rôle...19 b. Ses attributs...19 c. Ses relations...20 Créer une partie Approche de la démarche suivie Présentation des RunModes et Templates...22 a. Le RunMode Creer1 :...22 b. Le RunMode Creer2 :...23 c. Le RunMode Creer3 :...23 d. Le RunMode Creer4 :...25 Jouer une partie Description de ce que fait le programme...26 a. Ecran d accueil...26 b. RunMode : jouer_choix_partie...26 c. Rumode : verif_mdp_joueur

3 d. RunMode : enregistrer_joueur...27 e. RunMode : accueil Description de l élaboration du code...35 a. Des débuts difficiles...35 b. Quelques solutions techniques utilisées...35 Administrer une partie Accueil...36 a. Administrer partie Choix de la partie et authentification...36 a. Retourner...37 b. Vérifier du mot de passe Confirmation du choix de la partie...38 a. Retourner à la liste des parties...38 b. Valider le choix de la partie Administration de la partie choisie...39 a. Actualiser les données...40 b. Consulter les résultats d un ancien tour...40 c. Passer en calcul automatique ou manuel...40 d. Exporter les résultats...41 e. Finir la partie Visualisation d un tour antérieur au tour en cours...41 a. Retourner à l écran d administration Confirmation de la fin de la partie...42 a. Retourner à l écran d administration...42 b. Valider Information de la suppression de la partie Confirmation de l exportation des résultats...43 a. Retourner à l écran d administration...43 b. Confirmer Accès au fichier exporté...45 a. Retourner à l écran d administration :...45 Quelques choix de conception globaux Solution technique concernant les délais Solution technique concernant les valeurs initiales Solution technique concernant l id client et l id fournisseur Solution technique du marché...46 Que reste t-il à faire? Problèmes non reste à gérer...47 a. La sécurité...47 b. Les déconnexions...47 c. La partie Créer...48 d. La partie Jouer : Le manque d information pour le joueur...48 e. La partie Administrer Fonctions du CdC non réalisées mais qui devaient l être...49 a. La partie Créer...49 b. La partie Jouer...49 c. La partie Administrer Fonctions du CdC non réalisées...51 a. La partie Créer...51 b. Jouer...52 c. La partie Administrer

4 Bilan global sur le projet GSI Le cahier des charges Les spécifications Le développement...55 Annexes...56 Mode d emploi de l application BW Création de partie :...58 a. Saisie des informations concernant la partie...58 b. Paramètre du marché...59 c. Créer un maillon...59 d. Spécification des délais...60 e. Gestion de la chaîne logistique Administration d une parie :...61 a. Choix de la partie :...62 b. Administration de la partie : Jouer une partie...65 a. Identification et connexion au jeu...65 b. Le déroulement d un tour...66 Installation de l application sur un serveur WEB Installation du module Perl et des packages adéquates Installation de la base de donnée Installation des fichiers de l application Configuration de l application

5 INTRODUCTION Notre projet de l option GSI 2008 était de réaliser une application qui permettrait de simuler une chaîne logistique et ainsi d en faire ressortir l effet BullWhip. Cette application devait permettre à des professeurs de créer des parties en ligne, aux élèves de jouer en ligne et aux chargés de TD d administrer les parties en ligne. Grâce au cahier des charges et aux spécifications qui ont été rédigées au préalable, nous avons pu réaliser ce projet. Nous avons donc développé cette application de manière à ce qu elle satisfasse au mieux les volontés de nos clients M. Jacques Lamothe et M. Matthieu Lauras. Nous reprenons dans ce rapport l ensemble des travaux que nous avons menés pour la réalisation de l application «Beer Witch». Dans un premier temps, nous vous exposerons notre gestion de projet pour que vous puissiez vous rendre compte de l avancée du développement par rapport à ce que nous avions prévu. Ensuite, nous commencerons à parler technique en exposant d abord la base de données que nous avons créée, puis la description du code de chacune des trois parties du programme (créer, jouer, administrer). Nous continuerons avec le listing de toutes les fonctions que nous avons pas pu faire avec des propositions de solution et toutes les fonctions que nous avons faites mais qui faudrait améliorer. Enfin, nous ferons un petit bilan de la réalisation de l ensemble des trois phases du projet Option GSI. Bonne lecture - 5 -

6 GESTION DE PROJET 1. Organisation interne du groupe : attribution des fonctions Notre équipe projet est composée de trois membres : M. Florian JOURNEAU, Mlle Nathalie COISNE PINELLI, et Stéphane RUOT. Au sein du groupe, chaque membre a une fonction bien déterminée. La répartition des responsabilités est la suivante : a. Chef de projet : M. Florian JOURNEAU Le chef de projet est responsable de la coordination entre les différents membres du groupe et de la répartition du travail. Il organise les réunions et se tient au courant de l avancement du projet. Il assure l harmonie et la communication au sein du groupe. De plus, il essaye d avoir une vison globale sur l ensemble du projet au niveau du travail de chacun. En cas de besoin, il peux se rendre disponible pour aider un autre membre du groupe. b. Responsable organisationnel et avancement du projet : M. Stéphane RUOT Le responsable de la gestion du projet gère la planification et l avancement du projet. Il réactualise le diagramme de Gantt au fur et à mesure de l avancement du projet et vérifie ainsi que l avancement réel du projet correspond au planning prévisionnel. En cas retard, il informe le chef de projet et essaye de déterminer les causes. c. Responsable des rapports : Mlle Nathalie COISNE PINELLI En tant que responsable des rapports, elle organise le plan de rédaction des rapports et répartit la rédaction aux différents membres du groupe. Elle se charge de la mise en commun des différentes parties et effectue la mise en forme. Elle doit s assurer que les dates de rendu des rapports sont respectées. 2. Répartition des tâches Les membres du groupe ne se sont pas limités uniquement aux taches liées à leur fonction sinon le projet n aurait pas avancé. Nous allons donc détailler un peu plus la répartition des tâches centrales du projet et travaux spécifiques de chacun

7 Nous avons distingué trois parties dans la programmation. Chaque membre ayant en charge le bon déroulement de sa partie. Le travail sur chaque partie n étant pas tout à fait équivalent, si un membre avait fini plus tôt que les autres il devait aider celui qui était en retard. La répartition s est faite en fonction des compétences et des envies de chacun. Ainsi, après avoir posé les bases pour que chacun ait le même point de départ, la répartition des taches a été la suivante : a. Florian Il a commencé par définir le modèle conceptuel des données (MCD) avec Nathalie afin de définir la base de données. Puis, il s est occupé de réaliser les fichiers permettant la création de la base de données. La plus grande partie de son travail a été la programmation de la création de partie ainsi que des templates qui s y rapportaient. Il s est aussi chargé des CSS, et de la mise en commun des différentes parties du programme. b. Stéphane En plus de la gestion de projet, il était responsable de la programmation de la partie jouer. Il a merveilleusement bien réalisé sa partie «Jouer» car il faut le dire, c était très difficile. Il s est assuré auprès de M. Lamothe que les calculs qu il faisait dans la partie Jouer correspondaient bien au jeu de la bière. Il s est également charger de nous rappeler notre avancement et nous re-situer par rapport au Gantt initial. c. Nathalie Avec Florian, elle a commencé par définir le modèle conceptuel des données (MCD). Elle s est ensuite occupé de l administration de la partie et a réalisé le programme et les templates. De part sa fonction, elle s est aussi assurée du bon déroulement de la rédaction des rapports et de la mise en commun des différentes parties écrites. De plus, elle a été un élément moteur du groupe. 3. Planification du projet Après avoir listé des tâches, nous avons réalisé un diagramme de Gantt afin de suivre de façon régulière l évolution du projet. Cela nous permettait : soit de vérifier que nous étions dans les temps, soit d estimer le retard que nous avions pris et dans ce cas de prévoir comment le rattraper. a. La réalisation du diagramme de Gantt La définition des objectifs du projet nous a permis de faire notre première planification. Nous avons fait l hypothèse que ces objectifs seraient atteints à la fin du projet

8 Puis nous avons construit le diagramme de GANTT sous MS Project à partir de cette hypothèse et de la liste des tâches que nous avions définie. La réalisation du diagramme de GANTT s est faite par étape afin que la planification du projet soit la plus réaliste et la plus cohérente possible. On peut distinguer le GANTT des tâches et le GANTT des ressources : Le GANTT des tâches regroupait toutes les informations sur les tâches : nom, durée, dates de début et de fin, liens de précédence avec d autres tâches. Le GANTT des ressources a permis la gestion des ressources. Il nous a renseigné sur l utilisation des ressources. C était surtout une indication car nous nous sommes plus intéressés aux heures de travail globales plutôt qu à la charge au jour le jour pour chaque ressource. Pour réaliser le diagramme de Gantt initial, nous avons commencé par modifier le calendrier standard, pour l adapter aux heures de projet qui nous étaient allouées. Nous avons donc réparti les 80 heures disponibles sur le mois de janvier. Ce premier diagramme était une estimation du projet. Nous ne savions pas si le projet allait se dérouler de cette façon car il était difficile d évaluer les durées des tâches. Dans tous les cas, en fonction des réunions d avancement du projet nous mettions à jour cette planification

9 La planification initiale - 9 -

10 b. Le suivi de projet : actualisation des Gantt Le projet n a duré qu un mois et la planification initiale était assez cohérente après la première semaine. Nous avons donc décide de ne faire qu une actualisation du Gantt en milieu de projet ainsi qu un bilan en fin de projet. Les mises à jours de l avancement du projet ont donc été effectuées le 19/01/08 et le 30/01/08. i. Actualisation du 19/01 A cette date, nous avions fait la moitié du projet en temps et presque 60% des heures consacrées à celui-ci. Apres un début difficile, car nous n étions pas familiarisés avec le langage Perl, nous avions tout de même réussi à ne pas accumuler trop de retard par rapport à la planification initiale. En effet, nous étions à presque 55% d avancement dans le projet. Pour simplifier le Gantt, nous avions mis les templates en précédente de la programmation. Cependant, bien que nous commencions par le template, il était modifié au fur et à mesure de la programmation. Ce qui explique que les templates ne soient pas finis alors que la phase de programmation soit commencée. La partie la plus en retard dans la programmation était celle consacrée au jeu en lui même. C est celle qui dès le départ semblait être la plus difficile et la plus longue à réaliser. Finalement c était bien le cas. En ce qui concerne la création de partie, les fonctions principales marchaient. Nous avons estimé que cette partie était terminée à 60%. Il restait donc à la peaufiner un peu pour ne pas oublier de fonctions. Enfin, pour la partie administration, de nombreuses fonctions étaient réalisées sur celles prévues mais certaines manquaient encore. Dans l ensemble, le projet avait suivi en grande partie la planification initiale malgré un petit retard pour la partie jouer

11 La planification au 19/

12 ii. Actualisation du 30/01 Le 30/01, le projet touchait à sa fin comme nous pouvons le voir sur le Gantt de suivi ci-dessus. Nous avons quasiment arrêté la programmation pour nous consacrer au rapport. La mise en commun des programmes avait été effectuée et l application tournait presque complètement. Certains bugs ont été détectés grâce à cette réunion des CGI. Nous avons donc dans la mesure du possible essayé de les corriger. La partie la plus conséquente qu il restait à faire était les rapports, pour lesquels nous n avions peut être pas prévu assez de temps. De plus, il nous a fallu préparer l oral qui n avait pas été pris en compte dans le diagramme de Gantt. c. Le consommé des heures Dans cette partie, nous allons comparer les heures prévues pour le projet et les heures réellement passées dessus. Il est évident que sur l ensemble du projet, nous avons tous dépassé les heures imparties au projet. Mais ceci est difficile à quantifier. En effet, nous n avons pas toujours travaillé pendant les heures de projet mais il se trouve que nous les rattrapions chez nous. Nous avions envie de réaliser une application qui marche. C est cette envie qui nous à poussé à travailler en plus chez nous. Cependant ce n était pas une contrainte. La cause principale du dépassement des heures de projet est dû au rapport. Nous n avions pas prévu assez de temps pour les faire car nous n avions pas prévu qu il fallait autant de choses dedans

13 La planification au 30/

14 DESCRIPTION DE LA BASE DE DONNEES Après analyse du diagramme de classes fournit dans le cahier des charges, nous avons élaboré la base de données. Nous en avons ressortit quatre tables principales : la table «partie», la table «chainelog», la table «maillon» et la table «resultats». Nous avons aussi créé une table annexe appelée «parametres». Voici la description de l ensemble de ces tables : 1. La table «partie» a. Son rôle La table partie est la table qui permettra de stocker les différentes parties créées par un utilisateur à partir de l application web et qui n ont pas été supprimées. On peut donc y retrouver l ensemble des informations nécessaire à une partie indépendamment de ses chaînes logistiques et de leurs maillons

15 b. Ses attributs Voici la liste des attributs contenus dans la table «partie» : Clé Nom attribut Description Type primaire part_id Identifiant de la partie Entier/Autoincrément part_nompartie Nom de la partie Caractères (50) Part_MdpAdmin Mot de passe de l administrateur Caractères (30) part_mdpjoueur Mot de passe du joueur Caractères (30) part_typeproduit Type de produit (bières, bois ) Caractères (30) part_datecreation Date de création de la partie Date part_datejeu Date à laquelle la partie commence à être jouée Date L «identifiant de la partie» est différent pour toutes les parties. Il permet de retrouver une certaine partie rapidement. C est un attribut qui s auto-incrémente de un par rapport à l identifiant de la dernière partie créée, à chaque création d une nouvelle partie. Le «mot de passe administrateur» est celui que l utilisateur devra donner pour accéder à l administration d une partie choisie. Le «mot de passe joueur» est celui que l utilisateur devra donner pour pouvoir jouer une partie choisie. Le «type produit» a pour but de répondre à la fonction technique «FT Donner le type de produit» et la fonction secondaire «FS Le programme s adapte au secteur d activité des élèves» qui sont des fonctions données dans le cahier des charges. Il permet d adapter les chaînes logistiques au domaine d activité des élèves qui joueront. Par exemple, si les joueurs sont des élèves d une école d aéronautique, le type de produit sera «avion». La «date de création» permet l effacement automatique d une partie lorsqu elle n a pas été jouée 48h00 après sa création. Dans notre application, nous n avons pas répondu à cette fonction mais nous avons tout de même créé l attribut dans la base pour que ceux qui reprendront notre projet n aient pas à le créer. La «date de jeu» permet de savoir si une partie a déjà commencé à être jouée. Nous nous ne servons pas de cet attribut dans notre application mais il servira pour la suite du développement. c. Ses relations Cette table est la table mère de toute la base. Elle ne dépend donc d aucune autre table même si les autres tables dépendent de celle-ci. 2. La table «chainelog» a. Son rôle La table «chainelog» permet de stocker toutes les chaînes logistiques créées et qui n ont pas été supprimées. On y retrouve donc l ensemble des chaînes logistiques de toutes les parties qui existent avec toutes informations nécessaires pour une chaîne logistique

16 b. Ses attributs Voici la liste des attributs contenus dans la table «chainelog» : Clé Nom attribut Description Type primaire chl_id Identifiant de la chaîne logistique Entier/Autoincrément étrangère chl_part_id Identifiant de la partie associée à la chainelog Entier chl _Numero Rang de la chaîne logistique dans la partie Petit Entier (6) chl _TourEnCours Numéro du tour en cours d être joué Petit Entier (6) chl _NbMaillon Nombre maillon total de la chaîne logistique Petit Entier (6) chl _MarcheInitial Valeur de la demande du marché avant échelon Entier chl _MarcheFinal Valeur de la demande du marché après échelon Entier chl_tourechelon Tour auquel on fait l échelon sur le marché Entier chl_calculauto Calcul automatique ou pas Binaire L «identifiant de la partie» est la clé étrangère qui permet de relier la table «chainelog» avec la table «partie». Cette relation est explicitée dans le paragraphe suivant «Ses relations». Le «numéro» sert à donner un repère à la chaîne logistique par rapport aux autres chaînes logistiques de la même partie. Le «tour en cours» permet de connaître à tout moment le numéro du tour qui est en train d être joué par les joueurs. Sous-entendu, cet attribut permet de savoir le nombre de tour qui a déjà été joué pour cette chaîne logistique. Le «marché initial» est le nombre de commande que le premier maillon de la chaîne logistique recevra à chaque tour. Le «tour échelon» est le numéro du tour auquel a lieu l augmentation de la commande reçue par le premier maillon. Le «marché final» est le nombre de commande que le premier maillon de la chaîne logistique reçoit à chaque tour lorsque le numéro du tour de l échelon est passé. Ces trois derniers attributs correspondent à la définition d un profil de commande linéaire. Pour plus de précisions, vous pouvez vous reporter au cahier des charges. c. Ses relations Une chaîne logistique appartient à une seule partie. On doit pouvoir repérer pour chaque chaîne logistique l identifiant de la partie à laquelle elle appartient.. La table «chainelog» doit donc être reliée à la table «partie». Elle est la première table fille de la table «partie». Pour ce faire, la table «chaînelog» possède une clé étrangère : «chl_part_id». Cette clé correspond à l identifiant de la table «partie». Les deux tables sont donc reliées par l identifiant de la partie : part_id chl_part_id De plus, pour gérer les clés étrangères, toutes les tables de la base doivent être définit comme un «InnoDB»

17 3. La table «maillon» a. Son rôle La table «maillon» permet de stocker tous les maillons appartenant à une chaîne logistique créées qui n a pas été supprimée. On y retrouve donc l ensemble des maillons de toutes les chaînes logistiques de toutes les parties qui existent. Chaque ligne de cette table donne toutes les informations nécessaires pour la définition d un maillon. b. Ses attributs Voici la liste des attributs contenus dans la table «maillon» : Clé Nom attribut Description Type primaire mail_id Identifiant du maillon Entier/Autoincrément étrangère mail_chl_id Identifiant de la chaîne log associée au maillon Entier mail_nommaillon Nom du maillon Caractères (50) mail_nummaillon Numéro du maillon Petit Entier (6) mail_nomjoueur Nom du joueur qui joue le maillon Caractères (50) mail_idfournisseur L identifiant du maillon fournisseur Petit Entier (6) mail_idclient L identifiant du maillon Client Petit Entier (6) mail_delaicommande Le délai de la commande Petit Entier (6) mail_delailivraison Le délai de livraison Petit Entier (6) mail_delaidispostock Le délai de mise à disposition dans le stock Petit Entier (6) mail_delaitraitcmd Le délai du traitement de la commande Petit Entier (6) mail_coutstockage Le coût de stockage Entier mail_coutrupture Le coût de rupture Entier mail_enattente L état «En attente» Binaire mail_maillonfinal Le maillon est-il le dernier de la chaîne log Binaire mail_tourencours Le tour auquel le joueur du maillon joue Petit Entier (6) Le «numéro maillon» permet de connaître le rang du maillon c est à dire quelle place il occupe dans la chaîne logistique. Le «nom du joueur» est celui que le joueur renseigne lorsqu il commence à jouer une partie. Cette donnée était demandée par les clients dans le cahier des charges et elle nous permet aussi de repérer les maillons qui auxquels aucun joueur n est affecté. L «identifiant Fournisseur» et «client» sont respectivement l identifiant du maillon fournisseur du maillon traité (c est à dire le maillon aval) et l identifiant du maillon client du maillon traité (c est à dire le maillon amont). Ces données peuvent être retrouvées avec l identifiant du maillon, le numéro du maillon et le nombre de maillon de la chaîne logistique. Mais pour éviter de faire cette requête compliquée un grand nombre de fois, nous avons décidé de stocker dans la base ces deux renseignements. Les «délai de commande», de «livraison», de «disponibilité stock» et de «traitement de commande» sont des données dont nous avons besoin dans la vérification des calculs dans la partie «jouer». Les différents rôles et définitions de ceux-ci sont définis dans la partie «Jouer» de ce rapport

18 Les «coûts de rupture» et de «stockage» permettent le calcul des coûts pour chaque tour en fonction du nombre de pièce en stock ou du nombre de pièce en rupture. La présence de ces coûts est justifiée par le cahier des charges. c. Ses relations Un maillon appartient à une seule chaîne logistique. On doit pouvoir repérer pour chaque maillon l identifiant de la chaîne logistique à laquelle il appartient. La table «maillon» doit donc être reliée à la table «chainelog». Elle est la deuxième table fille de la table «partie». Pour ce faire, la table «maillon» possède une clé étrangère : «mail_chl_id». Cette clé correspond à l identifiant de la table «chaînelog». Les deux tables sont donc reliées par l identifiant de la chaîne logistique : chl_id mail_chl_id 4. La table «resultats» a. Son rôle La table «resultats» permet de stocker l ensemble des résultats de chaque tour joué de chaque maillon de chaque chaîne logistique de chaque partie (ouf!). On y retrouve donc l ensemble des données nécessaires pour qu une partie soit analysée et pour en faire ressortir l effet bullwhip. Effectivement, le cahier des charges précise que tous les résultats doivent pouvoir être récupérés pour être ensuite analysés. b. Ses attributs Voici la liste des attributs contenus dans la table «resultats» : Clé Nom attribut Description Type primaire res_id Identifiant de la ligne de résultats Entier/Autoincrément étrangère res_mail_id Identifiant du maillon associé Entier res_tour Numéro du tour n Entier res_demande Demande au tour n Entier res_restealivrer Reste à livrer au tour n Entier res_afournir A fournir au tour n Entier res_livraison Livraison au tour n Entier res_stock Stock du maillon au tour n Entier res_cumulattendus Cumul des attendus au tour n Entier res_reception Réception au tour n Entier res _Commande Commande au tour n Entier res_nberreurjoueur Nombre d erreur que le joueur a faite au tour n Petit Entier (6) resstockdispo Le stock disponible au tour n Entier

19 Le «numéro du tour» est le numéro du tour auquel la ligne de résultats à été enregistrée. La «demande», le «reste à livrer», le «à fournir», la «livraison», le «stock», le «cumul des attendus», la «réception», la «commande» et le «stock disponible» sont des données définies dans le cahier des charges dont l administrateur de la partie a besoin pour analyser les résultats. Ce sont les résultats au tour n c est à dire au tour res_tour. Ces données sont explicitées dans le cahier des charges ou dans la partie «Jouer» de ce rapport. Le «nombre d erreur joueur» est le nombre de fois qu un joueur a validé ses calculs alors qu ils étaient faux au tour res_tour. c. Ses relations Une ligne de résultats appartient à un seul maillon. On doit pouvoir repérer pour chaque ligne de résultats l identifiant du maillon auquel il appartient. La table «resultats» doit donc être reliée à la table «maillon». Elle est la troisième table fille de la table «partie». Pour ce faire, la table «resultats» possède une clé étrangère : «res_mail_id». Cette clé correspond à l identifiant de la table «maillon». Les deux tables sont donc reliées par l identifiant du maillon : mail_id res_mail_id 5. La table «parametres» a. Son rôle Nous avons choisit de créer cette table pour regrouper à un seul endroit toutes les données fixes dans le programme qui pourraient avoir besoin d être changée. Par exemple, le chemin d accès au répertoire «htdocs» est propre au serveur dans lequel le programme est installé. Ce chemin ne devrait pas changer. Par contre, si le serveur change le chemin d accès à ce fichier change aussi. C est pourquoi il est important d avoir facilement accès à cette donnée pour pouvoir la modifiée. Cette table n est pas demandée dans le cahier des charges de l application. Nous l avons créée à notre initiative car elle nous paraissait pratique. Cependant, nous ne n avons pas eu le temps de l exploiter. Nous laissons ce soin à nos successeurs b. Ses attributs Voici la liste des attributs contenus dans la table «parametres» : Clé Nom attribut Description Type primaire param_id Identifiant du paramètre Entier/Autoincrément param_nom Nom du paramètre Caractères (50) Param_Valeur Valeur du paramètre Caractères (255)

20 c. Ses relations Cette table est complètement indépendante de toutes les autres tables. Pour que le programme fonctionne, il faut que la base de données soit correctement installée sur le serveur qui héberge le programme. Dans le dossier «Base de données» vous trouverez le fichier «CreationTables.txt» qui vous permettra de créer toutes les tables de la base «BW» avec toutes les spécifications données précédemment. Vous trouverez aussi dans ce dossier le fichier «requetes SQL.doc» qui donne un exemple de requête SQL à lancer pour remplir la base de données

21 CREER UNE PARTIE Nous allons maintenant entrer dans le détail du code et de l application. Commençons par le commencement : «La Création», la Création de la partie. 1. Approche de la démarche suivie La création de partie consiste à inscrire dans la base de données, toutes les informations qui vont permettre le bon déroulement du jeu. Il faut prévoir la création de partie, chaînes logistiques, maillons mais également des lignes dans la table de résultats pour initialiser la partie. On rappelle le choix de conception suivi : une partie est composée d une ou plusieurs chaînes logistiques elles même composées d un ou plusieurs maillons. L avantage est qu avec une partie, l administrateur peut administrer plusieurs chaînes logistiques 1 (chaînes logistiques appartenant à la même partie bien sur). La totalité de cette action est gérée par un package nommé «CreerPartie.pm» appelé par le navigateur avec le script «CreerPartie.cgi». Ce package se décompose en plusieurs RunModes qui vont être appelés successivement au cours de la navigation. Idée de base : on ne sauvegarde les informations de la partie dans la base une fois que l on a toutes les données vérifiées! Cela permet d éviter l apparition de données incohérentes dans la base. Prenons l exemple d un utilisateur qui commence à créer une partie de quelques maillons puis qu il se déconnecte pour une raison «Y», il ne faut pas que la moitié des données saisies soit sauvegardée dans la base. On aurait là, une partie non finalisée donc incohérente qui ne serait pas exploitable et encombrerait la base pour rien. Pour faire face à ce problème, la solution est de passer toutes les informations accumulées pour la création de partie en champs cachés, via des formulaires. Une fois que toutes les données ont été saisies et validées, on sauvegarde tout d un coup dans la base. 1 Une des plus value de cette application par rapport à celle de l université Canadienne : FORAC

22 2. Présentation des RunModes et Templates A propos des Templates, tous les fichiers Templates relatif au package CreerPartie ont pour extention.htm (ceci afin de faciliter leur édition dans un éditeur favori). a. Le RunMode Creer1 : Le RunMode Creer1 est le RunMode de départ (StartRunMode) du package CreerPartie. En cas de demande d un RunMode qui n existe pas, on retombe sur ce RunMode (grâce à la sub verify_runmode). Il fait passer au Template «Creer01.htm» le paramètre par défaut de type de produit qui est bière ainsi que le titre de la page du navigateur 2. On affiche ensuite ce Template ce qui donne : L utilisateur devra saisir le nom de la partie, le type de produit à gérer, et un mot de passe d administration informations de base pour la création de la partie. Il a pour contraintes de remplir tous les champs et de saisir deux mots de passe identiques dans les champs dédiés. Le clique sur le bouton «Etape suivante >>» nous fait passer au RunMode suivant. 2 Le titre de la page du navigateur est envoyé par chaque RunMode, cette information ne sera pas répétée par la suite

23 b. Le RunMode Creer2 : Ce RunMode reçoit comme paramètres les informations saisies précédemment. Il commence par vérifier que les contraintes énoncées précédemment sont bien respectées, sinon, il revoie le Template précédemment avec un message d erreur. Dans le cas ou tout est correct, il va transmettre les paramètres reçus au Template «Creer02.htm» qui va les stocker sous forme de champs cachés. Cet écran permet à l utilisateur de spécifier l évolution du marché qu il souhaite pour la partie. Avec cette version, il n est possible que de simuler un profil de commande type échelon. L utilisateur est contraint de remplir tous les champs avec des entiers strictement positifs. On appelle ensuite le RunMode suivant. c. Le RunMode Creer3 : Il va recevoir tous les paramètres saisis jusqu'à présent, il re-vérifie les deux contraintes précédentes et renvoie vers le RunMode adéquate si besoin. Si les paramètres sont corrects, le RunMode précédent a également envoyé comme information le numéro du maillon à créer (donc le n 1). On envoie ce paramètre au Template qui va afficher le formulaire d information pour le maillon 1. Le Template «Creer03.htm» donne alors ceci :

24 Pour chaque maillon, l utilisateur doit renseigner tous les champs. Pour tous les champs excepté le nom du maillon. Il faut des nombres entiers : o Les délais D1 et D2 sont compris entre 0 et 9. o Les délais D3 et D4 sont compris entre 1 et 9. Le reste des champs est limité à trois chiffres (nombre maxi 999) dans le formulaire et n est pas limité dans le FormValidator. Le clique sur le bouton «ajouter ce maillon» va envoyer les informations visibles et les informations en champs cachés. Parmi ces dernières, se trouve le champ nummaillon qui a pour valeur le numéro du maillon en cours + 1. Le clique sur ce bouton «Ajouter maillon» appelle le même RunMode et affiche formulaire pour le deuxième maillon. Une fois qu au moins un maillon est créé, on affiche un historique de la chaîne logistique créée : Cet historique, en plus de permettre à l utilisateur de visualiser ce qu il a créé, permet de stocker et transmettre les informations concernant les maillons précédents. En effet, les données sont contenues dans des champs en propriété readonly (leur contenu ne peut pas être modifié depuis la page WEB). Lorsque l on soumet le formulaire (que ce soit en cliquant sur «Ajouter maillon» ou «Valider la chaîne»), toutes les données sont transmises et analysées. En cas d erreur, on réaffiche le même formulaire avec un message d erreur et on envoie le paramètre nummaillon avec une valeur identique à la précédente. Ainsi, l utilisateur doit ressaisir les informations pour le maillon. De même, le bouton «Valider la chaîne» n est plus visible s il y a une erreur, il n est donc pas possible d aller plus loin dans la création tant que les erreurs ne sont pas corrigées. Deux boutons permettent de supprimer soit le dernier maillon créé, soit tous les maillons. Un script Javascript demande confirmation avant de soumettre le formulaire. Si l utilisateur valide le message d alerte, le script modifie la valeur de nummaillon dans le champ caché du formulaire avant de le soumettre. Il est possible de dupliquer les chaînes logistiques créées. Pour éviter de saturer la base de données, le nombre maximum de chaîne logistique duplicable a été limité à 20 (choix de

25 conception). Un script Javascript averti l utilisateur s il a saisi un nombre supérieur à 20 et replace la valeur 20 dans le champ. Lorsque l utilisateur clique sur «valider la chaîne», on soumet le formulaire et on est redirigé vers le RunMode Creer4. d. Le RunMode Creer4 : Ce RunMode va permettre la création de la partie et tout ce qui lui est associé dans la base de données. Toutes les données du formulaire précédent ont été transmises. Tous les champs sont revérifiés et s il y a une seule erreur (contraintes vues précédemment depuis le RunMode Creer1 non respectées), on renvoie le RunMode adéquate avec un message d erreur. La création de la partie ne se fait donc qu à la fin quand on est sûr que toutes les informations saisies sont correctes. Le processus est le suivant : 1. On commence par créer la partie dans la base. On récupère l identifiant de la partie (Id_Partie) ainsi créée On rentre dans la boucle de duplication et on créé la chaîne logistique. On lui attribut pour numéro, le numéro de parcours de la boucle et pour clé étrangère, l Id_Partie. On récupère également l identifiant de la chaîne logistique créée (Id_ChaineLog). 3. Ensuite, on rentre dans une boucle qui va créer chacun des maillons. Pour chacun d entre eux, on attribut en clé étrangère l Id_ChaineLog. 4. On inscrit dans la table «résultats» les paramètres initiaux pour la semaine zéro. On reboucle tant que tous les maillons n ont pas été créés. 5. On retourne à l étape 2 tant que la boucle n a pas été parcourue autant de fois que le nombre de duplication. 6. Une fois toutes ces étapes terminées, on affiche le Template Creer04.htm : 3 La numérotation des identifiants est faite de manière automatique par le serveur MySQL

26 JOUER UNE PARTIE Après la création de la parte, un joueur muni du mot de passe de la partie peut jouer la partie. Voici tous les secrets de cette partie du code : 3. Description de ce que fait le programme Tout d abord, voici une description du code qui gère la partie «Jouer» de l application. a. Ecran d accueil Pour jouer une partie un utilisateur doit se connecter à l application par le web. L écran d accueil s affiche. Voici l aperçu de l écran d accueil : partie. L utilisateur doit alors cliquer sur le bouton «Jouer une partie» s il veut jouer une b. RunMode : jouer_choix_partie Le RunMode «jouer_choix_partie» est le «StartRunMode» c est donc celui qui se lance lorsqu on lance le programme CGI jouer. Le clic sur le bouton «Jouer une partie» de l écran d accueil déclenche le RunMode «jouer_choix_partie» qui récupère toutes les parties qui existent dans la base de données. Le RunMode balaye donc la table «partie» en extrait toutes les parties, ainsi que tous leurs paramètres, et les stocke dans un tableau. Le RunMode appelle ensuite le template «JouerChoixChl.tt2» et lui envoie le tableau de parties

27 Voici un aperçu du template qui est appelé : Ce template possède un menu déroulant qui contient le nom et la date de création de toutes les parties existantes dans la base de données. Il contient une zone de mot de passe où l utilisateur est invité à écrire le mot de passe joueur de la partie qu il a sélectionnée. Un bouton «Valider» permet de valider la saisie du mot de passe et un lien «Retour» permet de revenir à l écran d accueil. c. Rumode : verif_mdp_joueur Le RunMode «verif_mdp_joueur» a pour but de vérifier le mot de passe entré par le joueur. Il est actionné lorsque l utilisateur clique sur le bouton «Valider» du template «jouer_choix_partie». En entrée, ce RunMode reçoit l identifiant de la partie que l utilisateur à sélectionné dans le menu déroulant et le mot de passe que l utilisateur a entré dans la zone de texte du template «jouer_choix_partie». Grâce à l identifiant de la partie reçu, le RunMode peut aller chercher dans la base de données le mot de passe joueur de la partie sélectionnée. Il s agit du champ «part_mdpjoueur» de la table «partie». Ensuite, le RunMode compare le mot de passe de la base de données avec celui entré par l utilisateur : Si les deux mots de passe sont identiques, le RunMode fait appel au template «JouerEntrerNomJoueur.tt2» en lui envoyant l identifiant de la partie. Si les deux mots de passe ne sont pas identiques, le RunMode ajoute le message d erreur «Le mot de passe est incorrect» qu il renvoie au template «JouerChoixChl.tt2». L utilisateur est donc invité à retenter sa connexion. De même, si aucune partie n est sélectionnée le RunMode ajoute le message d erreur «Aucune partie sélectionnée» qu il renvoie au template «JouerChoixChl.tt2». Ce template est donc réaffiché et l utilisateur est donc invité à retenter sa connexion. d. RunMode : enregistrer_joueur Ce RunMode a pour but d enregistrer le joueur et de lui affecter un maillon libre. Ce RunMode est accessible à partir du template «JouerEntrerNomJoueur.tt2»

28 Voici un aperçu de ce template : Ce template informe l utilisateur que sa connexion à la partie a réussi. Il doit alors entrer son nom et valider grâce au bouton «Valider». L utilisateur peut aussi revenir sur ses pas en cliquant sur le lien «Retour». Dans ce cas là, il revient à la page précédente. Le clic sur le bouton «Valider» appelle donc le RunMode «enregistrer_joueur». Le template lui envoie alors l identifiant de la partie et le nom du joueur contenu dans la zone de texte. Le RunMode se connecte à la base et recherche tous les maillons de toutes les chaînes logistiques appartenant à la partie. Il stocke le tout dans un tableau. Ce tableau est un tableau de chaîne logistique et chaque chaîne logistique contient un tableau pour chacun de leur maillon. Il a donc plusieurs tableaux imbriqués dans le tableau de chaîne logistique. Ensuite chaque ligne des deux tableaux est balayée par deux boucles «FOREACH» imbriquées. La première boucle balaye toutes les chaînes logistiques de la partie et la deuxième balaye tous les maillons d une chaîne logistique. Pour chaque ligne, le RunMode regarde si le champ «mail_nomjoueur» de la table maillon est vide ou pas. Ce champ correspond au nom du joueur qui joue le maillon correspondant. Si ce champ est vide, c est qu aucun joueur n a été affecté au maillon. Dans le cas contraire le maillon n est pas libre. Les boucles imbriquées s arrêtent, grâce à la commande «last», dès qu elles ont trouvé un maillon libre. L identifiant du maillon est donc relevé et le joueur est affecté à ce maillon. Ensuite, le nom du joueur est enregistré dans la base dans le champ «mail_nomjoueur» de la ligne du maillon qui lui est affecté. Ainsi, ce maillon ne pourra plus être affecté à un autre joueur. Le RunMode fait ensuite appelle au template «JouerComfirmeLogged.tt2» et lui envoie l identifiant du maillon affecté au joueur. Dans le cas où l utilisateur valide sans avoir entrer son nom, le RunMode le renvoie au template précédent. Il devra à nouveau entrer le mot de passe de la partie. Dans le cas où aucun maillon de l ensemble des chaînes logistiques de la partie n est libre, le RunMode ajoute le message d erreur «Il n'y a plus de maillon libre dans cette partie» et fait appel au RunMode «jouer_choix_partie» qui lui réaffichera le template «JouerChoixChl.tt2» avec le message d erreur

29 e. RunMode : accueil Le RunMode «accueil» initialise le tour à jouer en affichant les données nécessaires au joueur pour remplir le formulaire de calcul. Il est accessible par le template «JouerComfirmeLogged.tt2». Ce template informe l utilisateur qu il a bien été attribué à un maillon et lui spécifie le nom et le numéro du maillon qui lui a été affecté et le numéro de la chaîne logistique à laquelle appartient ce maillon. Voici un aperçu de ce template : Ce template ne possède qu un bouton «Jouer» qui permet à l utilisateur de commencer à jouer la partie. Ce bouton appelle le RunMode «accueil». Après avoir exécuter tout ce qu il devait, ce RunMode appelle le template «Jouer.html» dont voici l aperçu : Cette partie du programme permet d exécuter un tour pour un maillon donné. On passe par plusieurs fonctions de manière séquentielle : ce qui constitue un tour. Plus précisément, on lance de manière successive des RunModes qui affichent l historique des tours précédents, vérifient les calculs et permettent de passer une commande. Dans un premier temps, RunMode «accueil» récupère pour le maillon les valeurs du tour, de la demande et de la réception. Pour le tour, on va lire dans la base de données le tour en cours dans la table «maillon». Pour la demande, on récupère dans un premier temps l identifiant du maillon client dans la table «maillon». Puis en fonction de son délai de commande que l on récupère dans

30 la même table, on va lire la commande passée X tours avant celui-ci (X = délai de commande du maillon client). Dans le cas où il faut aller chercher une commande pour un tour négatif, on utilise la commande initiale qui correspond au tour 0 (paramètre initial demandé lors de la création de la partie). Cependant, il a fallu gérer une exception : le maillon en relation direct avec le marché. Pour lui, l identifiant de son maillon client est égal à 0. On teste donc l identifiant du maillon client récupéré et si celui-ci correspond à un maillon en relation direct avec le marché, on récupère en fonction du tour : soit la valeur du marché initial, soit la valeur du marché final. Pour rappel, le marché est défini par une valeur initiale, une valeur finale et un tour de changement de valeur. Pour la réception, c est un peu le même principe que pour la demande. On récupère dans un premier temps, l identifiant du maillon fournisseur, puis son délai de livraison. En fonction de ces paramètres, le maillon reçoit la livraison de son fournisseur effectuée Y tours avant celui-ci (Y = délai de livraison du maillon fournisseur). De la même manière, si on a besoin d une livraison antérieure au tour 1, on va la récupérer dans la ligne du tour 0 pour le maillon en question. De plus comme pour la demande, il faut gérer une exception : le maillon producteur qui se livre à lui-même. Son identifiant de maillon fournisseur est égal à 0 ce qui permet de le repérer simplement. Pour lui, on utilise son délai de commande pour savoir combien de tour il faut retourner en arrière pour trouver la commande qu il a passé et qu il reçoit donc pour le tour en cours. On envoie ensuite ces paramètres : identifiant du maillon, tour, demande et réception, dans un paramètre global «vue» qui sera récupéré par la fonction «vue_jeu» qui va permettre l affichage et que nous allons décrire maintenant. i. Fonction «vue_jeu» La fonction «vue_jeu» récupère toutes les valeurs à passer à la vue ainsi que l identifiant du maillon qui est compris dedans pour l affichage des paramètres du jeu. C est elle qui va passer au template les valeurs à afficher. Elle permet en particulier d afficher le tour, la demande, la réception ainsi que le tableau de l historique des tours du maillon. La récupération du tableau de l historique du maillon se fait par une simple requête de la table «résultats» avec pour contrainte que l identifiant du maillon soit le même que celui du champs «res_mail_id». La première ligne de cet historique affiche les données nécessaires pour les calculs du tour. Les lignes du tableau sont gérées par un «faux pager» qui affiche seulement les 10 dernièrs tours. Cela permet de ne pas surcharger la page de jeu

31 C est aussi par elle que passe toutes les données annexes à afficher tel que le nom du maillon ou le titre de la page. ii. RunMode : verif Le RunMode «verif» est «activé» par le passage de la valeur verif dans un champ caché nommé rm (suite au RunMode accueil). Il permet, comme son nom l indique, de vérifier les valeurs saisies par le joueur en fonction des calculs à effectuer. Une fois que le joueur a rempli tous les champs : A fournir, Stock disponible, Livraison, Reste à livrer, Stock, Cumul des attendus, il lance le RunMode en cliquant sur le bouton «Vérifier». Les valeurs saisies sont alors vérifiées dans un premier temps par un Data::formValidator qui contrôle que les valeurs saisies sont bien des nombres entiers. En cas, de données invalides ou manquantes, on repasse les valeurs à la vue et on relance le RunMode «accueil» en affichant les erreurs. Sinon, on fait les calculs à partir du tour précédent et on les compare aux valeurs saisies par le joueur. Précisions un peu plus cette étape : On récupère les champs valides du Data::formValidator et les données du tour précédent à l aide d un «resultset» ayant pour contrainte l identification du maillon et le tour en cours. On peut alors faire les calculs : «A fournir» représente ce que le joueur doit fournir au tour en cours. C est la somme de la demande du tour à laquelle s ajoute le reste à livrer du tour précédent. A fournir Tour(N) = Demande Tour(N) + Reste à livrer Tour(N-1) «Stock disponible» correspond au nombre de produit disponible à la livraison pour le tour. C est un paramètre qui dépend du délai de disponibilité au stock. Il se calcule de la manière suivante : Stock disponible Tour(N) = Stock Tour(N-1) + Réception Tour(N) - Somme de i= 0 à (délai de disponibilité au stock 1) des Réceptions Tour(N-i) Pour faire ce calcul, on va d abord récupérer le délai de disponibilité au stock. Puis on va tester si celui ci vaut 0. Si c est le cas, le stock disponible est égal à la somme de stock (total) du tour précédent et de la réception du tour en cours. Sinon, on va d abord calculer la somme des réceptions qui ne sont pas encore disponibles au stock. Pour cela, on a fait une boucle «for» allant de i = 0 à i < (délai de disponibilité au stock 1) dans laquelle on

32 incrémente une variable «réception passée». Comme pour la récupération de réception du RunMode «accueil», s il faut des valeurs pour des tours inférieurs au tour 1, on prend les valeurs initiales du tour 0. Une fois que l on a la somme des réceptions passées, il ne reste plus qu à la soustraire au stock (total) du tour précédent pour obtenir le stock disponible du tour en cours. «Livraison» est ce qui est envoyé au maillon client au tour en cours. Elle dépend de ce qu il y a à fournir et du stock disponible. Elle ne peut prendre que deux valeurs : soit elle est égale au «à fournir», soit elle est égale au «stock disponible». Il faut donc comparer ce qu il y a à fournir et le stock disponible pour la déterminer. Si (A fournir > Stock disponible) Alors Livraison Tour(N) = Stock disponible Tour(N) Sinon Livraison Tour(N) = A fournir Tour(N) «Reste à livrer» correspond à ce qui n a pas été livré mais qui aurait dû. On le calcule à partir de la livraison et de ce qu il y avait à fournir au client. C est un reste à livrer de fin de tour. Reste à livrer Tour(N) = A fournir Tour(N) Livraison Tour(N) Remarque : La formule ne change pas en fonction de la condition sur la valeur de la livraison du tour en cours. «Stock» est défini comme étant le stock total. Il est indépendant du stock disponible et contrairement à ce dernier, il est calculer en fin de tour. Stock Tour(N) = Stock Tour(N-1) + Réception Tour(N) Livraison Tour(N) «Cumul des attendus» correspond au total des commandes fournisseurs qui ont été passées mais qui n ont pas encore été reçues. Cumul des attendus Tour(N) = Cumul des attendus Tour(N-1) + Commande Tour(N-1) Réception Tour(N) Remarque : C est un cumul des attendus avant passage de la commande du tour en cours. On aurait pu faire un cumul des attendus après commande du tour en cours. De plus, cette formule est indépendante des délais

33 Une fois les calculs effectués, on compare les résultats avec les valeurs saisies dans les champs par le joueur. Si les calculs sont mauvais, on l indique au joueur et on incrémente son nombre d erreurs (fonction non réalisée pour plusieurs raisons voir la partie élaboration du code) et on renvoie le RunMode «accueil». Si les calculs sont bons, on passe au RunMode commande, on bloque les champs remplis par le joueur à l aide d un «readonly» et on renvoie la fonction d affichage «vue_jeu». Remarque : les boutons de soumission du formulaire dépendent du RunMode. C est à dire que le bouton Vérifier ne s affiche qu en RunMode «verif» et pareil pour le bouton commande. Ceci est géré dans le template. iii. RunMode : commande Le RunMode «commande» suit le RunMode «verif». Une fois les calculs bons, il ne reste plus qu à passer la commande pour finir le tour. On retrouve au début du RunMode la récupération des paramètres de vue, et la retransmission de ceux-ci. Cela permet de ne pas perdre les valeurs en cas d erreur sur la commande. Lorsqu on appuie sur le bouton pour commande, toutes les valeurs du formulaire passent dans un Data::FormValidator qui contrôle que toutes les valeurs saisies sont des entiers positifs. Normalement il ne peut y avoir des erreurs que sur la commande qui peut être invalide ou manquante, les autres champs étant bloqués. Dans ce cas, on renvoie le RunMode «commande» pour que l utilisateur puisse passer une commande valide