Docstoc

Rapport de projet Serious Game

Document Sample
Rapport de projet Serious Game Powered By Docstoc
					Rapport nal de projet : Serious Game
             Stéphane    Maniaci,
              Baptiste   Saleil,
         sous la direction de monsieur
            Abdelkader     Gouaich.




        Année universitaire 2009  2010




                       1
Remerciements
   Nous tenons à remercier notre tuteur de stage avant tout, monsieur Abdel-
kader Gouaich pour ses conseils et sa conance en nous, Mathieu Triay pour
son expérience et le temps qu'il nous a accordé (approuvé testeur Mac OS), nos
familles pour avoir écouté des conversations axées sur le développement gra-
phique sous framebuer en plein repas, nous-même pour nous être supportés
jusqu'au bout, et enn l'IUT de Montpellier pour sa connexion haut débit et sa
machine à café.




                                      2
Table des matières
I Introduction                                                                       5
1 Dénition du projet                                                                5
  1.1   Énoncé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     5
  1.2   Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     5


2 Cahier des charges                                                                 6

II Analyse et conception                                                             7
3 Maquettes                                                                          7
  3.1   Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    7
  3.2   Conception imaginée . . . . . . . . . . . . . . . . . . . . . . . . .        8


4 Diagrammes UML                                                                     9
  4.1   Cas d'utilisations . . . . . . . . . . . . . . . . . . . . . . . . . . .     9
  4.2   Classes persistantes . . . . . . . . . . . . . . . . . . . . . . . . . .     9
  4.3   Séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      9




III Réalisation                                                                     10
5 Outils et langage                                                                 10
  5.1   Bibliothèque graphique . . . . . . . . . . . . . . . . . . . . . . . .      10
  5.2   Langages    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   11
  5.3   Plateforme de développement . . . . . . . . . . . . . . . . . . . .         12


6 Exemples de code                                                                  13
  6.1   Création d'un prol     . . . . . . . . . . . . . . . . . . . . . . . . .   13
  6.2   Chargement dynamique des jeux         . . . . . . . . . . . . . . . . . .   14
  6.3   Traçage de la souris    . . . . . . . . . . . . . . . . . . . . . . . . .   16


7 Programme nal                                                                    17
  7.1   Résultat eectif . . . . . . . . . . . . . . . . . . . . . . . . . . . .    17
  7.2   Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    19




IV Conclusion                                                                       20
8 Apport du projet                                                                  20
  8.1   Travail en groupe . . . . . . . . . . . . . . . . . . . . . . . . . . .     20
  8.2   Outils manipulés    . . . . . . . . . . . . . . . . . . . . . . . . . . .   20




V Glossaire                                                                         21

VI Annexes                                                                          23
                                         3
Table des gures
  1    Écran d'accueil une fois l'utilisateur connecté    . . . . . . . . . . .   17
  2    Ébauche de la fenêtre de connexion . . . . . . . . . . . . . . . . .       23
  3    Ébauche du menu d'accueil      . . . . . . . . . . . . . . . . . . . . .   23
  4    Diagramme UML des cas d'utilisations . . . . . . . . . . . . . . .         24
  5    Diagramme UML des classes persitantes . . . . . . . . . . . . . .          25
  6    Diagramme UML de séquence : connexion . . . . . . . . . . . . .            26
  7    Diagramme UML de séquence : cas d'exception d'une connexion                27
  8    Diagramme UML de séquence : déroulement d'une partie             . . . .   28
  9    Diagramme UML de séquence : cas d'exception d'une partie . . .             29
  10   Fenêtre d'accueil du programme . . . . . . . . . . . . . . . . . . .       30
  11   Fenêtre de création d'un utilisateur . . . . . . . . . . . . . . . . .     30
  12   Fenêtre de sélection d'un utilisateur    . . . . . . . . . . . . . . . .   30
  13   Fenêtre de statistiques . . . . . . . . . . . . . . . . . . . . . . . .    31
  14   Classage des jeux trouvés en dynamiques . . . . . . . . . . . . . .        31




                                       4
Première partie
Introduction
1 Dénition du projet
1.1 Énoncé
   Le projet dont nous sommes en charge consiste à réaliser un programme
d'aide aux personnes victimes d'un accident vasculo-cérébral (AVC) ayant perdu
une partie de leur mobilité, en leur proposant des séries de mini-jeux basés sur
le mouvement, an de rendre plus ludique leur rééducation.
   Ils auront à disposition une clé USB hébergeant directement le jeu et un
système d'exploitation spécialement conçu, ce qui leur permet de s'entraîner
sans se soucier du système d'exploitation de la machine hôte ou d'un quelconque
                                                                        1
processus d'installation (on emploirea à juste titre le terme Plug & Play ). Notre
projet ne s'occupe pas de cette dernière partie, qui sera délivrée par le tuteur à
la n.



1.2 Plan
   Nous présentons dans ce document la démarche que nous avons suivi pour
tenter de mener à bien ce projet, en décrivant les deux grands axes de dévelop-
pement, c'est-à-dire la conception et l'analyse du projet avec diagrammes UML
à l'appui, la réalisation technique (choix des outils, portions de code, modèle
utilisé), notre avis sur les résultats obtenus et les objectifs initiaux, puis une
conclusion personnelle sur ce projet.




  1 Les   termes soulignés se réfèrent au glossaire en n de rapport


                                               5
2 Cahier des charges
  Notre programme doit orir ces fonctionnalités :

Gestion de prols    Le patient doit être capable de charger son prol et sa
    progression au lancement du programme.

Trace des mouvements       An de mieux décrire la progression du patient, le
    programme doit, à travers tous les jeux, enregistrer les diérents caracté-
    ristiques du mouvement (direction, vitesse, amplitude, etc.)

Réalisation des jeux    Le programme doit fournir de base, un panel de mini-
    jeux à titre d'exemple.

Catégorisation    Pour éviter que le patient s'ennuie, le programme doit pro-
    poser des jeux dans diérentes catégories (vitesse, endurance, etc.) qui
    permettront aussi la diversication des statistiques et de la progression.

API de développement       Parce que nous ne sommes pas initiés au développe-
    ment de jeux-vidéos même de petite envergure, il est nécessaire de prévoir
    une interface pour des développeurs tiers leur permettant de programmer
    des jeux orientés santé, en se concentrant seulement sur le jeu, puisque
    c'est notre programme qui prendra en charge la gestion des statistiques,
    des mouvements et de la journalisation.

Consultation des données      Car chaque patient est suivi par un médecin, une
    interface de suivi de l'évolution du patient serait judicieuse.

Performances     Le patient doit pouvoir pratiquer régulièrement et sur presque
    toutes les machines où il branche sa clé USB contenant les jeux et sa pro-
    gression. Pour assurer des coûts de développement minimes et donc un
    déploiement maximum, nous devions penser à économiser les ressources
    de la machine hôte. Ce serait d'autant plus judicieux si les hopitaux ve-
    naient à s'équiper de terminaux destiné à faire fonctionner des applications
    orientées santé dans un futur proche.




                                       6
Deuxième partie
Analyse et conception
3 Maquettes
3.1 Interface
   Le programme étant dirigé par des personnes à mobilité réduite, nous nous
devions de proposer une interface graphique simple et ecace. Nous avons pensé
que l'accès aux jeux devrait se faire en moins de trois étapes :

  1. Sélection/création d'un prol ;

  2. Visualisation de la progression, sélection d'une catégorie ;

  3. Sélection du jeu.

Les ébauches de fenêtres présentées en   Annexe 1 fûrent élaborés, et nous nous
y sommes tenus tout au long du développement.




                                         7
3.2 Conception imaginée
   Nous avons déni en accord avec notre tuteur quatre catégories décrivant
certaines caractéristiques du mouvement : force, vitesse, endurance et réexes.
Le patient pourra travailler à sa guise sur ces diérentes catégories, et particu-
lièrement celles où il est le moins à l'aise.
   N'étant pas spécialisés dans la conception de jeux vidéos, nos jeux se limitent
à des exemples basiques (en guise de   proof of concept ) et nous proposerons pour
palier à ça une API aux développeurs pour qu'ils puissent créér de nouveaux
jeux facilement intégrable à notre gestionnaire.
   Lorsque le patient lancera son programme, sera connecté, et décidera de
jouer, le programme analysera le répertoire des jeux (que nous aurons déni) et
achera ensuite à l'utilisateur la liste des jeux trouvés, rangés par catégorie. Le
patient lancera alors un jeu, et ne pourra en lancer un autre qu'une fois celui en
cours terminé. Durant le jeu, le déplacement de la souris est analysé, puis traité
par une fonction spéciale pour extraire des valeurs remarquables. Ces valeurs
sont remontées à la n du jeu vers notre application.
   Enn, nous imaginons éventuellement une interface Web pour permettre à
une équipe de médecin de suivre la progression des patients sur un serveur
collectant les données de jeux, pour comparer et analyser les diérents résultats
qu'ils auront obtenus.




                                          8
4 Diagrammes UML
4.1 Cas d'utilisations
   Voir   Annexe 2.

4.2 Classes persistantes
   Voir   Annexe 3.

4.3 Séquences
   Voir   Annexe 4. Les gures de l'annexe 4 sont les diagrammes de séquences
décrivant respectivement :
    La connexion d'un utilisateur au système ;
    La connexion dans le cas d'exception ;
    Déroulement d'une partie ;
    Déroulement d'une partie dans le cas d'exception ;




                                      9
Troisième partie
Réalisation
5 Outils et langage
5.1 Bibliothèque graphique
   Parce que le projet se devait d'acher des performances optimales, notre tu-
teur nous a orienté vers l'utilisation de la bibliothèque Qt (prononcé Kyute),
développée par Nokia et largement utilisée à travers le monde. Elle présente
l'avantage d'orir une large collection de widgets répondant à nos besoins, tant
pour la création de l'interface graphique que pour la réalisation des minis-jeux,
mais aussi de proposer une version libre, gratuite, et prévue pour le développe-
ment embarqué (Qt Embedded Open Source Edition), ce qui veut dire qu'elle
est déployable sur des machines à faible ressources telles que les téléphones mo-
biles, les PDAs, et bien entendu les ordinateurs à conguration modeste. Cette
capacité à s'exécuter sur des machines faibles réside dans le fait qu'au lieu d'uti-
liser, comme sur la plupart des systèmes Linux actuels, un serveur X pour gérer
l'achage graphique des applications, Qt Embedded écrit les images en dialo-
guant directement avec la carte graphique, sur le framebuer. C'est un gain de
ressources considérable, et donc un atout essentiel pour nous. C'est aussi une
librairie développée en C++, orientée objet, avec un système de gestion des
signaux (utilisés pour que les widgets interagissent entre eux) très puissant.




   Enn, c'est une libraire gratuite, libre et multi-plateforme, ce qu'illustre son
slogan Codez moins, crééz plus, déployez partout.




                                        10
5.2 Langages
Programmation
   Comme nous devons rendre notre programme modulaire et extensible, un
langage orienté objet était nécessaire. Ajoutons à celà le fait que Qt propose son
API en C++ seulement, notre choix en fut grandement simplié.


Code source
   Nous avons choisi d'écrire notre code source en anglais : tout d'abord parce
que c'est le langage universel de développement, et que cela optimiserait les
chances de voir des développeurs étrangers apporter leur contribution à notre
programme, tout comme cela faciliterait les demandes d'aide à des développeurs
expérimentés (un ingénieur de Nokia a répondu à notre mail sur des questions
d'ordre technique à propos de Qt). Ensuite, la librairie Qt possède une API en
anglais, nous avons donc écrit en anglais par souci de cohérence. Heureusement,
Qt ore un module nommé Qt Linguist, qui permet de réunir aisément toutes
les chaînes du programme marquées pour la traduction (encadrées par une fonc-
tion spéciale   tr())   dans un seul chier qui sera ensuite dérivé dans les langues
voulues.




                                          11
5.3 Plateforme de développement
   Nous avons en accord avec le tuteur décidé d'utiliser les services de Google
Code pour le développement, mettant à notre disposition un wiki, un serveur
SVN pour le partage du code et un gestionnaire de bogues. Pour les raisons
décrites en annexe, nous avons préféré utiliser Git pour notre développement,
mais toujours sur les serveurs de Google, par le biais de l'outil git-svn.




                                        12
6 Exemples de code
      Nous n'avons pas jugé utile d'include l'intégralité de notre code dans ce
rapport, mais nous décrirons seulement quelques extraits qui nous paraissent
intéressants.



6.1 Création d'un prol
      La fonction de création d'un prol sert aussi à charger les prols existants,
i.e   si un utilisateur rentre un nom de prol déjà existant, c'est ce prol qui
est chargé. Cela permet aussi de n'appeller qu'une seule fonction pour ces deux
tâches.
      En détail : on se sert de la classe          QSettings proposée par Qt qui permet
de gérer des chiers de congurations, qu'on instancie avec le nom d'utilisateur
transmis en paramètre (la chaîne de caractères                  QString qui arrive soit du dia-
logue de création de prol, soit de celui de sélection), dans le dossiers users/
.
      On teste ensuite si le prol existe déjà en testant la propriété name. Si elle
ne contient rien, on instancie toutes les valeurs à 0 et le nom au nom transmis.


                          Listing 1  Construction d'un utilisateur

User : : User ( QString            name )
{
        // Q S e t t i n g s : : NativeFormat t e l l s t h e c o n s t r u c t o r
        // t o use t h e n a t i v e p l a t f o r m e x t e n s i o n .
        config =        new     Q S e t t i n g s ( " u s e r s / "+name ,
                                                 Q S e t t i n g s : : NativeFormat ) ;


        // c h e c k i n g i f f i l e doesn ' t e x i s t by t e s t i n g "name"
        if    ( ! config−>c o n t a i n s ( "name" ) )            {
             config −>s e t V a l u e ( "name" ,        name ) ;
             config −>s e t V a l u e ( " games " ,       0);
             config −>s e t V a l u e ( " p l a y t i m e " ,     0);


             config −>s e t V a l u e ( " c a t e g o r y 1 " ,       0);
             config −>s e t V a l u e ( " c a t e g o r y 2 " ,       0);
             config −>s e t V a l u e ( " c a t e g o r y 3 " ,       0);
             config −>s e t V a l u e ( " c a t e g o r y 4 " ,       0);
        }
}




                                                   13
6.2 Chargement dynamique des jeux
     Le chargement dynamique étant un point-clé de notre projet, nous allons
vous expliquer ici la procédure que nous avons suivi pour y parvenir. La pre-
mière étape était de dénir le lien entre l'application et le jeu, une interface
par laquelle ils puissent communiquer et travailler ensemble. Cette interface
s'appelle GameInterface, elle est dénie comme suit :


                                Listing 2  Interface GameInterface

c l a s s G a me I n t e rf a c e
{
public :
    virtual ~G a m eI n t e r fa c e ( ) { } ;

          /∗   plugin_info ()           returns       a    QStringList          storing     ∗
           ∗ informations about the plugin . I t ' s                           indexed      ∗
           ∗ like this :
           ∗ 0 : category
           ∗ 1 : name
           ∗ 2 : description
           ∗ 3 : author
           ∗ 4 : version
           ∗/
          virtual Q S t r i n g L i s t p l u g i n _ i n f o ( ) = 0 ;

          virtual void mouseLogger ( QGraphicsSceneMouseEvent ∗ e ) = 0 ;
};

     On dénit donc trois méthodes pures et virtuelles, c'est à dire à implémenter
forcément les objets qui possèdent cette interface. Le destructeur                              GameInter-
face(), nécessaire, la fonction            QStringList plugin_info() qui retourne une liste
de chaînes de caractères telles que décrites dans le code, c'est cette fonction
qu'on appelle dans la portion de code ci-après et enn mouseLogger() qui trace
les mouvements de la souris, que nous verrons un peu plus loin.


                                Listing 3  Chargement dynamique

QDir ∗ c u r = new QDir ( QDir : : c u r r e n t P a t h ()+ " / games / " ) ;

// f o r e a c h    :   Qt   keyword ,       use    first      argument        in   second      argument
f o r e a c h ( QString f i l e n a m e ,
                cur −>e n t r y L i s t ( Q S t r i n g L i s t ( " ∗ . s o " ) ,
                QDir : : F i l e s ) ) {
     //    loader
     QPluginLoader l o a d e r ( cur −>a b s o l u t e F i l e P a t h ( f i l e n a m e ) ) ;

     //    instance
     QObject ∗ p l u g i n = l o a d e r . i n s t a n c e ( ) ;

     //    interface
     G a me I n t e rf a c e ∗ t e s t ;

     i f ( plugin ) {
          t e s t = q o b j e c t _ c a s t <G a me I n t e rf a c e ∗ >( p l u g i n ) ;


                                                          14
        if ( test ) {
            qDebug()<<" S u c c e s s f u l l y l o a d e d game : " + f i l e n a m e ;
            QString c a t e g o r y = t e s t −>p l u g i n _ i n f o ( ) . a t ( 0 ) ;
            QListWidgetItem ∗ e n t r y = new QListWidgetItem ( ) ;
            entry −>s e t T e x t ( t e s t −>p l u g i n _ i n f o ( ) . a t ( 1 ) ) ;
            entry −>s e t T o o l T i p ( t e s t −>p l u g i n _ i n f o ( ) . a t ( 2 ) ) ;
            i f ( c a t e g o r y == " endurance " ) {
                end−>addItem ( e n t r y ) ;
            } e l s e i f ( c a t e g o r y == " s p e e d " ) {
                spe −>addItem ( e n t r y ) ;
            } e l s e i f ( c a t e g o r y == " a c c u r a c y " ) {
                acc −>addItem ( e n t r y ) ;
            } e l s e i f ( c a t e g o r y == " r e f l e x " ) {
                r e f −>addItem ( e n t r y ) ;
            } else {
                qDebug()<<"Unknown c a t e g o r y " ;
            }
        }
    }
}

Étape par étape : on créé un répertoire à l'emplacement de l'application suxé
de /games, où seront stockés les jeux. Puis on parcourt grâce à l'aide du mot-clé
foreach tous les chiers se terminant par .so dans les chiers (ltre QDir : :Files)
avec une variable lename.
    On créé ensuite en chargeur pour nos extensions, le QPluginLoader, qui
tente de charger notre lename. Une fois chargé, on tente de l'instancier avec
la fonction   instance() du chargeur. Si l'instanciation réussie, on initialise une
interface    GameInterface vue précédemment avec le jeu, et on teste à nouveau
si cela a fonctionné.
    Si l'interface est bien présente, alors il ne nous reste plus qu'à récupérer la
catégorie en utilisant le parcours de la             QStringList       avec la fonction at() au
rang 0 puisque c'est là que se situe la catégorie (voir code précédent).
    Enn, on teste la catégorie et on l'ajoute aux widgets correspondants (nous
avons utilisé des listes, voir captures d'écran à la n).




                                                  15
6.3 Traçage de la souris
    Nous avons déni dans notre interface une autre fonction
void mouseLogger(QGraphicsSceneMouseEvent ∗e)                     : cette fonction reçoit un
évènement QGraphicsSceneMouseEvent, c'est à dire une interaction de l'utilisa-
teur avec la souris sur la scène. Cette fonction trace donc la souris et enregistre
des valeurs remarquables, pour le moment le minimum et le maximum des co-
ordonnées horizontales et verticales, récupérées grâce à la fonction           scenePos()
qui renvoie les coordonnées de l'évènement par rapport à la scène.
    Cette fonction nécessite encore du travail, on pourrait notamment éviter
de restreindre l'évènement survenu à un            QGraphicsSceneMouseEvent pour
permettre d'autres interactions aux développeurs, et aussi extraire d'autres va-
leurs remarquables.


                                 Listing 4  Traçage souris

void
Pong : : mouseLogger ( QGraphicsSceneMouseEvent ∗ e )
{
     s t a t i c int xmax = 0 ;
     s t a t i c int xmin = 0 ;
     s t a t i c int ymax = 0 ;
     s t a t i c int ymin = 0 ;

       //   event     coordinates        relative      to   the   scene
       int x = e−>s c e n e P o s ( ) . x ( ) ;
       int y = e−>s c e n e P o s ( ) . y ( ) ;

       if   (x   <   xmin )   xmin   =   x;
       if   (x   >   xmax )   xmax   =   x;
       if   (y   <   ymin )   ymin   =   y;
       if   (y   >   ymax )   ymax   =   y;
}




                                                  16
7 Programme nal
7.1 Résultat eectif
   Après trois mois de travail et de recherche, obstrué par nos dicultés à ins-
taller correctement la bibliothèque Qt avec un framebuer en état, nous sommes
arrivés à obtenir un programme fonctionnel, qui gère les prols utilisateurs, en-
registre la progression, propose une API de développement pour les mini-jeux
et fournit une interface claire, ergonomique et traductible. Nous avons certes
quelque peu peiné à programmer des mini-jeux, mais notre objectif, la réali-
sation de l'architecture soutenant ces mini-jeux, est rempli dans sa majorité.
Certaines tâches n'ont cependant pas été menées à bien, tels que la journalisa-
tion que nous avons eu du mal à cerner, et aussi l'API de développement qui
est certes fonctionnelle, mais nécessite sûrement de nouvelles fonctions pour per-
mettre aux déveolppeurs une plus grande exibilité et liberté dans leur processus
de création de jeux ; on doit celà à l'absence de tutoriaux ecaces sur Internet,
notamment concernant le chargement dynamique, et donc au décryptage de la
documentation de Qt (en anglais) assez lourde parfois.




            Fig. 1  Écran d'accueil une fois l'utilisateur connecté


   D'autres captures d'écran sont disponibles dans l'   Annexe 5.


                                       17
Perspectives
   À présent, il ne reste plus qu'à diuser notre API aux développeurs intéressés,
en ayant aux préalables pris le temps de mener à bien une batterie de tests
garantissant la robustesse de notre application. On pourrait aussi penser à une
interface multi-joueurs, pour que les malades puissent se retrouver dans une
salle de jeu et travailler ensemble. Enn, il serait utile de mettre en place un
site Internet présentant des tutoriaux pour les développeurs, que ce soit de la
description de l'API à la marche à suivre pour proposer son jeu à une équipe
de médecins.


Diusion
   Il est encore un peu tôt pour proposer aux hopîtaux un programme vieux
de trois mois, mais il se trouve que Stéphane entreprend son stage aux Labo-
ratoire d'Informatique, de Robotique et de Micro-électronique de Montpellier
(LIRMM), où il continuera à travailler sur le projet, et éventuellement tentera
de prendre contact avec les hopîtaux environnants pour discuter et éventuelle-
ment engager une phase de test avec les hopîtaux locaux, une fois le programme
consolidé.




                                       18
7.2 Discussion
   Nous avons réalisé que notre projet se distinguait de la majorité des autres
par plusieurs points, ce dont nous sommes certes ers, mais qui nous a donné
du l à retordre comparé aux autres groupes.

 Langage : nous avons développé en C++, un langage qui n'était certes pas
     nouveau pour nous, mais en tout cas beaucoup plus que le Java enseigné
     à l'IUT ;

 Développement à l'IUT : La bibliothèque Qt n'étant pas installée sur les ma-
     chines de l'IUT, nous ne pouvions pas développer pendant notre temps
     libre entre les cours, à moins d'avoir pris notre ordinateur portable avec
     nous ;

 Framebuer : Parce que nous développions pour de l'embarqué, il nous a fallu
     activer le framebuer de nos machines pour coder notre programme. Hélas,
     c'est une man÷uvre qui requiert des modications obscures dans certains
     chiers système et qui fût source d'une certaine exaspération ;

 Libraire Qt : la libraire Qt orant une vaste gamme d'outils, tant pour le son,
     que l'image ou le traitement de chiers, son temps de compilation en est
     d'autant plus long, et même en désactivant la plupart des options oertes,
     nous avons du attendre une bonne centaine de minutes pour chaque compi-
     lation. De plus, cette compilation ne tirait pas prot de notre framebuer
     lors des premiers essais, nous avons du recompiler maintes fois sans nous
     décourager, pour une perte de quelques semaines au nal.

C'était donc un projet plutôt ardu pour nous, mais nous sommes ravis d'avoir
appris un nouveau langage largement répandu dans l'industrie, d'avoir codé
et rééchi à une interface graphique, et enn d'avoir inspecté les rouages du
développement embarqué en plein essor (GPS, cellulaires, etc).




                                      19
Quatrième partie
Conclusion
8 Apport du projet
8.1 Travail en groupe
   Une des plus grosse diculté tout au long du projet reste à nos yeux le
travail en groupe. Parce que nous possédons des aptitudes diérentes, des inté-
rêts diérents pour la conception, la programmation ou encore la rédaction, il a
fallu s'organiser dès le début pour déléguer les tâches à chacun et dénir préci-
sément la politique de développement (concepts et outils utilisés, style du code,
etc.) pour que la mise en commun se fasse le plus simplement possible. Nous
avons tous les deux encourager l'autre dans les moments diciles (compilations
échoués, erreurs mystérieuses), et partager nos rééxions sur le développement
du projet.



8.2 Outils manipulés
   Ce projet a aussi été l'occasion pour nous d'apprendre un nouveau langage
beaucoup utilisé par les entreprises actuellement, de nous familiariser avec la
programmation graphique, le modèle vue-contrôleur, mais aussi de se construire
un environnement de développement ecace et adapté à nos besoins. Nous avons
utilisé pour ce projet :
    Emacs/Gedit pour le code ;
     A
    L T Xpour le rapport ;
        E
    Dia pour les diagrammes UML ;
    Epiphany/Firefox pour la recherche Internet ;
    Fedora Linux et Ubuntu Linux.
On notera par ailleurs que tous ces logiciels sont libres et gratuits.




                                        20
Cinquième partie
Glossaire
API    Une API, pour    Applicable Programmation Interface,      est un ensemble de
       fonctions, procédures ou classes mises à disposition des développeurs an
       de faciliter le développement des diérents composants logiciels d'un pro-
       gramme.

Bibliothèque logicielle      En programmation, une bibliothèque, autrement ap-
       pellée librairie, est un ensemble de chiers pré-compilés fournissant au dé-
       veloppeur des fonctionnalités exploitables à travers une API. Cela permet
       notamment d'éviter la redondance de code entre diérents programmes et
       la réinvention de la roue lorsqu'on a besoin de certaines fonctions précises.

C++     Langage orienté objet créé par Bjorn Soustrap au début des années 80,
       le C++ a pour mission d'incrémenter le C des fonctionnalités nécessaires
       à la programmation objet.

Framebuer       Le framebuer, littéralement tampon de trame, est une couche
       d'abstraction graphique indépendante du matériel utilisé. Cela permet
       d'acher des images sans passer par d'autres bibliothèques, ou le recours
       à un serveur X. En pratique, la mémoire est directement écrite à l'écran.

Git   Développé par Linus Torvalds en vue de simplier le développement com-
       plexe du noyau Linux, Git est un DCVS, pour       DeCentralized Versionning
       System,   et apporte par rapport à SVN la gestion du code hors-ligne (pas
       besoin d'être connecté à Internet pour apporter des changements) et des
       performances accrues.

Interface Voir API.
Plug & Play Littéralement Brancher & Jouer, ce terme désigne les périphé-
       riques d'un ordinateur qui n'ont pas besoin d'un processus d'installation
       pour marcher. Il sut de brancher et ça fonctionne. D'après Microsoft.

Serveur X     Composante graphique de la plupart des systèmes Linux qui gère
       et distribue l'achage , c'est un projet vieux d'une dizaine d'années, d'une
       stabilité inébranlable mais plutôt gourmand en ressources.

SVN     Subversion est un CVS, pour       Centralized Versionning System,     c'est à
       dire un système de gestion de code basé sur le versionnage. Ainsi, quand
       plusieurs développeurs travaillent en même temps, ils peuvent rester à
       jour, et travailler sur les dernières sources, puis sauvegarder leurs éventuels
       changements et les soumettre en amont. Bien que très populaire à une
       époque, SVN est peu à peu remplacé par des systèmes plus récents et plus
       performants, tels que Git.

Widget     Terme sans véritable équivalent français, un widget désigne un compo-
       sant graphique. Une fenêtre avec un bouton et une boîte de texte contient
       donc trois widgets (la fenêtre elle-même étant un widget). Il est souvent
       interactif (sensible à des signaux et des évènements).

Wiki    Tiré de l'hawaïen wiki wiki qui veut dire vite vite, un wiki mais c'est
       un ensemble de pages éditables par un groupe de personnes restreint ou
       non, qui permet de mettre en commun le savoir du projet.




                                          21
git-svn   Programme ajoutant à Git des commandes permettant d'utiliser le
     serveur SVN pour partager le code. On peut le voir comme une laison de
     Git vers SVN.

UML   L'UML, pour    Unied Modeling Language, est un langage graphique com-
     posé de schémas, permettant de modéliser des données et des traitements.
     Ce langage est utilisé lors de l'analyse d'un projet pour permettre aux dé-
     veloppeurs d'organiser au mieux leur programme avant de réaliser celui-ci.




                                      22
Sixième partie
Annexes
Annexe 1




           Fig. 2  Ébauche de la fenêtre de connexion




              Fig. 3  Ébauche du menu d'accueil




                               23
Annexe 2




           Fig. 4  Diagramme UML des cas d'utilisations




                                24
Annexe 3




       Fig. 5  Diagramme UML des classes persitantes




                            25
Annexe 4




       Fig. 6  Diagramme UML de séquence : connexion




                            26
Fig. 7  Diagramme UML de séquence : cas d'exception d'une connexion




                                27
Fig. 8  Diagramme UML de séquence : déroulement d'une partie




                             28
Fig. 9  Diagramme UML de séquence : cas d'exception d'une partie




                               29
Annexe 5




            Fig. 10  Fenêtre d'accueil du programme




           Fig. 11  Fenêtre de création d'un utilisateur




           Fig. 12  Fenêtre de sélection d'un utilisateur




                                 30
        Fig. 13  Fenêtre de statistiques




Fig. 14  Classage des jeux trouvés en dynamiques




                       31
Sitographie
http ://doc.trolltech.com/4.6/index.html        La référence de la libraire Qt
    4.6, notre site favori depuis trois mois.

http ://doc.qtfr.org/post/2007/02/18/Creation-de-plugin-avec-Qt              Un
    tutoriel sur la création d'extension dynamique avec Qt, qui n'a certes pas
    su à être lu pour fonctionner, mais mérite mention.

www.wikipedia.org     Certaines dénitions du glossaires sont appuyés par l'ir-
    remplaçable Wikipedia.

www.google.com     Recherche, mails, documents, code source, merci à Google
    pour les services oerts.




                                      32
Résumé
   Le projet Serious Game a pour but de réaliser un gestionnaire de
jeux servant à la rééducation des victimes d'accidents vasculaires cé-
rébraux. Ce programme doit pouvoir être lancé directement sur une
clé USB, indépendemmant des machines. Ce gestionnaire de jeux
doit permettre à un patient de créer un compte sur le programme,
de pouvoir ensuite s'y connecter, et de pouvoir suivre sa progression
au l des parties. Les mini-jeux sont divisés en quatre catégories
axées sur le mouvement que le patient peux travailler à sa guise. Ce
gestionnaire doit supporter en outre l'ajout de nouveaux mini-jeux
dynamiquement, sans réinstallation nécessaire, en orant aux déve-
loppeurs tiers une interface leur permettant de créer de nouveaux
jeux dont notre application tirera automatiquement des données ju-
dicieuses à la rééducation du patient.


Summary
   The Serious Game projet aims to create a manager for health-
oriented videogames, played by people victims of stroke (or acute
cerebrovascular attack). This program can be launched directly from
an USB key, on any hardware. This manager allows the patient to
create an account on the program, connect this account and fol-
low his progression along the games. The videogames are divided
in four categories describing movement characteristics, all playable
by the patient at his will. The manager must also support the ad-
dition of new videogames dynamically, without any re-installation
procedures, by providing an interface to developers allowing them
to create new games automatically handled by our application to
extract useful data for the patient's reeducation.




                                 33

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:17
posted:8/4/2011
language:French
pages:33