Logiciel de statistiques pour le Volley-ball

Transcription

1 Lucas society Logiciel de statistiques pour le Volley-ball Partie Modèle Anthony 13

2 Table des matières I) Préambule...2 1) Motivation...2 2) Contrainte...2 II) Introduction...3 1) Le travail en équipe...3 2) Les difficultés propres au modèle...3 III) Solutions techniques...4 1) Présentation...4 2) Le mapping relation-objet...4 3) L automate...5 a) Les états...5 b) Les actions...6 c) Les signaux...7 d) Diagnostique mémoire...7 IV) Axe d amélioration...9 1) A court terme...9 2) A moyen terme...9 3) A long terme...9 Modèle Page 1

3 I) Préambule Logiciel de statistiques pour le Volley-ball 1) Motivation Lors d un match de Volley-ball, il est important que l entraineur puisse récolter des informations. Ces informations peuvent être de différentes natures : réceptions, services, fautes Elles permettent d analyser un joueur et donc de juger de sa qualité durant le match. Cette analyse permettra ensuite de conseiller l entraineur quant aux remplacements, placements qu il devra mettre en œuvre pour gagner un match. 2) Contrainte Lors de ce projet, nous devions travailler sur un logiciel en temps réel développée sur Android. Ce système d exploitation nous obligea à nous adapter à des contraintes particulières : le langage Java s est imposé de lui-même, le développement Android en C++ n étant pas encore bien enseigné sur le net. De plus, le Java n étant pas un langage économique, d un point de vue mémoire vive, processeur et temps d exécution, il nous fallut optimiser le code suffisamment pour ne surtout pas avoir de ralentissement de l application. Modèle Page 2

4 II) Introduction 1) Le travail en équipe Nous avons dû choisir une division équitable des taches lors de ce projet. Nous avons donc commencé par découper le programme en sous-partie. Nous avons choisi de le découper en respecter le modèle-vue-contrôleur, à ceci nous avons rajouté la gestion de la base de données. Une personne s est occupée de la vue et des contrôleurs, un groupe de deux personnes s est penché sur la gestion de la base de données, et la dernière s est occupée du modèle. 2) Les difficultés propres au modèle Lors de l étape de conceptualisation du modèle, plusieurs problèmes se sont posés. Comme énoncé lors du préambule, des contraintes de rapidité d exécutions ont été au cœur de mûre réflexion. La base de données est longue en accès et en écriture, puis qu il s agit de fichier présent sur le disque dur (carte SD ). Le temps d analyse d un match est à considérer aussi. Il faut que toute les informations du match en cours soit rapidement disponible et analysable. Le modèle doit aussi, particulièrement rapidement gérer des maladresses que l entraineur pourrait commettre : - Si l action indiquée par l entraineur est impossible en vue de l état actuel, il ne faut pas se mettre dans un état impossible. - Si l action indiquée par l entraineur est fausse, dû à une erreur de manipulation de l interface graphique, il faut pouvoir rectifier le tir, en annulant la dernière action rapidement sans faire de calcul et sans se placer dans un état incohérent. Modèle Page 3

5 III) Solutions techniques 1) Présentation La première partie traitera de la base de données. Afin de garantir un accès simple et rapide, nous avons choisi de créer un mapping relationobjet (ORM, pour nos amis anglais). On a analysé le volley-ball en tant que sport et l on a formulé quelques conclusions. Le volley est dirigé par un ensemble de règles. Celles-ci sont facile à implémenter parce qu elles sont claires et dirigistes. Apres mûre réflexion, on a décidé de modéliser un match de Volley de la façon qui suit : - On garde en mémoire chaque état d'un match à chaque instant. - Chacun de ces états sont déduit les uns des autres par une action de volley (service, faute...). Pour la bonne vie du projet, il nous fallut aussi proposer une solution flexible, simple à modifiée : - Si les règles du volley venaient à être changées - Si l'on voulait ajouter des modes de jeu (beach-volley, volley-ball pour différente tranche d'âge) Avant tout, il faut conserver le déroulement du match dans les moindres détails et permettre de modifier des actions pendant le match, après la fin du match tout en conservant l'intégrité logique du match. Cette modélisation conduit à produire un automate générateur qui fut le choix final technique choisi. 2) Le mapping relation-objet Le constat est que la base de données et très longue, et compliqué à l usage. Nous avons donc choisi de transformer les lignes d informations présentes dans la base de données en classe Java. Ainsi, deux classes ont été créées : Team et Player. Il y a par contre un problème : la redondance d information. En effet, si l on laisse la base de données gérer la création de ces classes, on risque de dédoublé l instance d un même joueur. Pour comprendre, il faut savoir que la classe Team contient la liste des joueurs qui la compose. Via des requêtes, l obtention de ces informations, en faisant attention de ne pas créer deux fois le même joueurs est périlleux et long. Ainsi, on a créé la classe DBInfo qui manipule deux tableaux associatifs (technologie arbre rouge-noir, pour accélérer l insertion, et la recherche par clef) ayants pour clef l id présent dans la base de données, et comme valeur pour l un une Team, et pour l autre un Player. Ainsi, il est instantané de savoir si un joueur a été déjà enregistré dans la mémoire vive. Cette classe DBInfo présente certaine fonction pour charger des équipes ou des joueurs, grâce à leur nom mais il est plus simple d invoquer la méthode chargertout() qui charge en mémoire, toutes les équipes et le joueurs présent dans la base de donnée. Modèle Page 4

6 Il existe des bibliothèques déjà conçu en Android afin de faire ça mais l on ne les connaissait pas, et il a été rapide à mettre en œuvre notre propre mapping relation-objet. 3) L automate De longues heures de réflexion ont été consacrées au contenu de cette automate. Il fallait à la fois que l automate enregistre suffisamment d information pour réduire les calculs au maximum, afin d avoir une application rapide et à la fois condensé au maximum les informations présente dans celui-ci car les tablettes ne sont pas équipées de grande capacité mémorielle. a) Les états Les états de l automate représentent de façon exhaustive toutes les informations à un instant précis d un match. On a choisi de stocker : - La position des joueurs de chaque équipe - Le score - L équipe ayant le service - Les disponibilités des joueurs à être remplacé - Le nombre de set gagné par chaque équipe - Le numéro du set en cours - Un booléen indiquant si le match est fini - Les actions attendues pour poursuivre dans un état cohérant et logique La position des joueurs est modélisée par un SparseArray, un tableau Android fonctionnant comme un tableau associatif de technologie arbre rouge-noir ayant pour clef un entier, on y associe donc la place d un joueur avec ce joueur. On en enregistre donc deux, un pour chaque équipe. Le score est enregistré sur un Short, on enregistre le score de chacune des deux équipes, on se retrouve donc avec deux Short. L équipe ayant le service est signalée via un pointeur vers Team. Les disponibilités des joueurs à être remplacé sont gérer par un tableau associatif (rougenoir toujours), la clef est l id du joueur remplacé, et la valeur est l id du joueur remplaçant. De la même façon que le score, le nombre de set gagné par chaque équipe est enregistré via deux Short. Le numéro du set en cours est enregistré sous la forme d un Short. Le booléen stockant la fin du match est choisi comme Static, il indique si l automate est dans un état final. Les actions attendu sont sauvegarder sous la forme d un SparseArray, ayant comme clef l id d une action, et comme valeur un booléen disant si l action est possible. Modèle Page 5

7 b) Les actions Pour les actions, deux solutions s offrir à nous : - Une classe, contenant une énumération de toutes les actions possibles - Une arborescence de classe, héritant chacune d'une action générique La première solution est assez peu agréable. En effet, si l on voudrait ajouter des actions, ou en retirer, il faut modifier dans chacune des fonctions de cette classe le cas où cette action se produit. La deuxième solution est plus agréable, elle permet de simplement ajouter une action en ajoutant une classe qui hérite d une classe générique. Ainsi, on économise de la mémoire, en ne mettant les attributs communs entre toutes les actions dans la classe générique, et en spécialisant dans les classes filles. Cela permet une économie de mémoire. Les méthodes sont redéfinies dans les classes filles, ce qui rend le code plus lisible que la première méthode. La classe mère contient : - Le joueur ayant fait l action - L équipe ayant fait l action - La date de l action - L id de la faute Le joueur et l équipe sont des pointeurs fournis en constructeur de l action. La date est au format Date de Android. L id de l action est un entier, il peut paraitre étrange de le retrouver dans la classe mère, mais pour simplifier l écriture de l arborescence, il est préférable de l écrire ici, et de déclarer que l id 0 indique qu il n a pas de faute. De plus les id de faute sont comprises entre 1 et 29. L arborescence est ainsi faite : - Une action indiquant qu un point est marquée - Une action indiquant qu une faute a été commise lors d un échange - Une action indiquant qu une réception a été faite - Une action indiquant qu un service a été effectué - Une action indiquant un remplacement L action du service est plus compliqué que les autre, elle contient plus d information, en premier lieu la nature du service peut être triple : - Il est suivi d une réception - Il est en faute - Il marque le point directement (ace) Afin de simplifier, nous n avons fait de sous classe, mais une énumération de ces trois cas. L action remplaçant contient le joueur remplaçant. Modèle Page 6

8 Grace à ces actions, un match peut être totalement couvert d'un point de vue "descriptif". De plus chaque action contient une méthode, qui renvoie l id qui lui correspond, chaque action à un numéro. Ce numéro correspond à l id d une faute, si l action correspond à une faute, c est l id de cette faute qui est l id de l action, sinon un id a été écrit pour chaque action à partir de 30. Pour récupérer une chaine de caractère correspondant à l id, une classe Static a été mise en œuvre nommée ActionManager. Elle comporte une méthode nommée actionreader qui prend une action en argument. c) Les signaux Afin de simplifier, la transmission d information entre l automate et la vue, on a mis en place un système de signaux. Le système de signal est créé à partir d une interface Java. Un schéma explicatif s impose : Court Vue Signaux Automate L automate remonte des signaux indiquant : - Changement de joueurs - Point marque - Un service - Une rotation - Une faute - Un remplacement - La fin du match Court implémente de son côté les choses à faire sur la vue lorsque les signaux remontent. d) Diagnostique mémoire Rapidement, le souci de la place mémoire a été évoqué. En effet, à chaque nouvelle action, on génère une nouvelle instance d Action et d Etat. Alors, on va faire un petit calcul : Un état prend environ : - Position des joueurs : 6joueurs*4(taille d un pointeur)*2equipes - Score : 2(taille d un Short)*2equipes - Equipe ayant service : 4(taille d un pointeur) - Disponibilité pour les remplacements : 12joueurs*4(taille d un entier)*2equipes - Set en cours : 2(taille d un Short) - Actions attendues : 4(moyenne)*4(taille d un entier) - Total : 170octets Modèle Page 7

9 Une action prend environ : - Joueur ayant fait l action : 4(taille d un pointeur) - Equipe ayant fait l action : 4(taille d un pointeur) - Date : 3(heure/minute/seconde)*4(taille d un entier) - Id de la faute : 4(taille d un entier) - Total : 24 Il y a n états et n-1 actions. Supposons que l on est 199actions : On a 4776octets d action et 34000octets d état. Soit environ 37Ko, ce qui est raisonnable. Il y a bien sûr de la mémoire supplémentaire qui sera alloué, pour les méthodes et autre impératif du langage Java, mais cela reste raisonnable pour une tablette. Modèle Page 8

10 IV) Axe d amélioration 1) A court terme Il faut rajouter un assistant à l entraineur à ce modèle. Il pourrait être simplement implémenté dans l automate. Il pourrait récolter les informations à chaque changement d état et analyser les faiblesses des joueurs durant le match. Par exemple, il pourrait compter le ratio de faute par action d un joueur, et en déduire s il faut le remplacer. 2) A moyen terme Il serait envisageable de modifier le code, et ajouter différent mode de jeu, par exemple permettre au Benjamin de jouer avec leur propres règles spécifique, le logiciel ne gérant à l heure actuel que les règles des matchs officielles. 3) A long terme Ce projet peut être repris pour être utilisé de façon universelle dans tous les sports. Le code peux être simplement modifié, et le cout de redéveloppement pour un autre sport serais très faible. Modèle Page 9