Évaluation de menu

Dans une application proposant un grand nombre d'actions différentes, il est fréquent de construire un menu qui présente à l'utilisateur toutes les possibilités qui lui sont offertes sous une forme hiérarchique. Cela peut prendre la forme d'une barre de menu pour les actions toujours disponibles, ou d'un menu contextuel pour les actions associées à l'élément d'interface sélectionné.

Chaque option dans un menu peut correspondre à une action ou à un sous-menu, ce qui permet d'organiser les actions et d'éviter de proposer des listes trop longues.

Le défaut de cette technique est que l'utilisateur risque de ne pas trouver l'action qui l'intéresse car elle est cachée dans un sous-menu. Il est donc très important de rendre la répartition intuitive.

À l'aide du premier programme de ce projet, vous allez permettre à un testeur de visiter un menu à la recherche d'une action particulière. Une fois une batterie de tests enregistrée, le second programme devra aider les concepteurs du menu à analyser les résultats et décider si leur organisation est optimale.

Vous produirez deux programmes écrits en Java. En plus de l'API officielle, vous pouvez vous appuyer sur les extensions déjà vues en cours (JUnit et le pilote MariaDB), mais aucune autre bibliothèque n'est permise. Le travail sera fait en binôme ou trinôme, et devra être terminé avant le dimanche 14 janvier 2024 à 23h59. La partie logicielle sera développée dès le départ à l'aide du serveur Gitea du département.

Données de test

Lorsqu'un concepteur souhaite évaluer la qualité de son menu, il le charge dans une base de données de test. Un menu est composé d'options, qui peuvent être soit une action soit un sous-menu. Chaque option possède un intitulé qui est le texte affiché dans la représentation graphique du menu. La base de donnée peut contenir plusieurs menus en même temps, et certaines options peuvent être communes à différents menus.

Pour tester un aspect du menu, il faut imaginer un protocole qui guide les testeurs. Il est composé de quatre éléments :

• la référence, qui est un code alphanumérique servant à identifier le protocole.
• le menu à tester.
• La description de la tâche que le testeur doit accomplir, sous forme de texte.
• L'action correcte dans le menu qui correspond à la tâche demandée.

Lorsqu'un testeur suit le protocole et interagit avec le menu, il produit un résultat dans la base de données. Celui-ci garde la trace de l'ensemble des sous-menus visités par le testeur (ordonnés chronologiquement) et l'action finalement choisie (qui peut ne pas être la bonne action).

Faites un diagramme de classes des tables nécessaires dans la base de données. Il est fortement recommandé de valider ce diagramme auprès de Luc Hernandez avant d'aller plus loin.

Outil de test

Le premier programme est exécuté par un testeur. Il lui demande (avec une interface appropriée) la référence du protocole à utiliser. Le programme consulte alors la base de données et affiche la description de la tâche à accomplir ainsi que le menu (obligatoirement sous la forme d'un JTree).

Le testeur choisit alors quelle action semble la plus appropriée pour répondre à la question posée. Le programme enregistre les sous-menus qui sont déployés ainsi que l'action finalement choisie. Ce résultat est écrit dans la base de données.

Attention Dans ce programme et le suivant, les problèmes liés à la base de données ne doivent pas terminer le programme. Les messages d'erreur ne sont pas affichés dans la console.

Synthèse des tests

Le second programme est exécuté par un développeur. Il commence également par demander la référence du protocole en argument. Le programme rassemble tous les résultats de test ayant employé ce protocole et affiche un camembert qui montre la répartition des actions choisies, l'action correcte ayant systématiquement la couleur verte.

Choisir la bonne action, est important, mais trouver la bonne action rapidement est aussi signicatif. Le développeur pourra basculer vers un second camembert qui montre la répartition du nombre de sous-menus déployés lors de chaque test.

Sources

Les sources de votre projet (et pas les fichiers .class) devront être disponibles à tout moment sur le serveur Gitea du département. Votre dépôt sera privé, nommé obligatoirement SAE31_2023 et incluera Luc Hernandez (login : hernand) dans la liste des collaborateurs. Le nombre de soumissions, leur date et l'équilibre entre leurs auteurs influeront sur la note finale.

Pour chaque classe, vous prévoierez un fichier source. Suivez les consignes habituelles scrupuleusement. La définition de chaque classe et de chaque membre de classe sera précédée d'un commentaire formaté pour permettre la génération de documentation technique par l'outil javadoc (ceci est un exemple de fichier source bien commenté).

Vous devrez respecter l'organisation du code vue au début de l'année. Toutes vos classes appartiendront à un package. Pour chaque programme, le fichier Makefile devra permettre la compilation, la création d'une archive jar, le lancement et le nettoyage de tous les fichiers générés. Transcrivez bien toutes les dépendances entre vos fichiers dans les règles.