titre	auteurs	date
Rapport_technique_Projet_IHM_Brinet_Besson_Boudjemline	Félix Brinet / Romain Besson / Bilal Boudjemline	2022-12-04

Sommaire

1. ##Introduction

2. Utilisation de l'API

3. Diagramme

4. Fonctionnalités

• Fonctionnalités réussies

• Fonctionnalités non réussies

• Fonctionnalités manquantes

5. Tests

• Tests réussis

• Tests non réussis

• Tests montrant des bugs

6. Conclusions

• Conclusions personnelles

• Conclusion générale

Introduction

Ce projet a été réalisé dans le cadre de la SAE du semestre 3 de la matière DEV.3.1. L'objectif de ce projet est de créer une interface homme-machine (IHM) en java. Nous devons utiliser une API fournie par notre professeur Florent Madeleine. En tout premier, nous devons utiliser le mode non-persistant déjà fournit et à la suite nous avons créer un mode persistant en utilisant une base de données sur PhpMyAdmin.

Utilisation de l'API

Bilal a commencé le projet seul car Romain et Félix étaient encore sur le projet précédent. Il a pu commencer à utiliser à l'API et à tester en modèle non-persistant. À la suite, Félix a créé la base de données et a essayé d'aider Bilal pour le modèle persistant. Ensuite Romain à changé l'interface pour la rendre plus intuitive et plus agréable à utiliser. Il a par exemple utilisé des CardLayout et Jpanel pour éviter d'ouvrir une fenêtre pour chaque fonctionnalité. Il a pu aussi créer un menu afin d'accéder aux différentes applications.

Diagramme

Fonctionnalitées

Pour les 3 vues, nous n'avons pas fait d'interface bien que les vues ont des méthodes en commun. En effet, nous voulons créer des applications indépendantes et déployables sans les autres donc une interface aurait empêché cette séparation.

Fonctionnalitées réussi

Administrateur :

• • (M) Créer, supprimer et renommer un groupe;

  • (M) Ajouter un individu dans un groupe;

  • (M) Déplacer un individu dans un autre groupe;

  • (S) Déplacer un individus en validant sa demande

  • (S) Refus d'une demande (de type 1)

  • (C) Echanger des individus entre 2 groupes à leur demande respectives (demande de type 2)

  • (C) Refus d'une demande (de type 2)

Professeur :

• • (M) Afficher la liste des groupes

  • (M) Afficher la liste des étudiant d'un groupe donné

  • (S) Chercher le groupe d'un étudiant à partir des 3 premières lettres de son nom

Elève :

• • (M) Afficher la liste des groupes

  • (M) Afficher la liste des étudiants d'un groupe donné

  • (M) Demandé à passé dans groupe qui est moins pleins que le sien en ajoutant une explication

  • (S) Voir les demandes de changement de groupe du type 2

  • (S) Demander à passer dans un groupe qui est de même taille ou plus grand en ajoutant une explication (demande de type 2 à faire valider)

Fonctionnalités non réussi

Administrateur :

• Toutes les fonctionnalités ont été réussies.

Professeur :

• • Toutes les fonctionnalités ont été réussies.

Elève :

• - Toutes les fonctionnalités ont été réussies.

Fonctionnalités manquantes

Par choix arbitraire, nous avons décidé de ne pas créer de sous-groupe.

Rajouter un bouton quitter sur la page d'accueil, ce n'est pas indispensable, mais cela pourrait rendre l'interface plus intuitive.

Tests

Tests réussis

Lorsqu'un administrateur clique sur "Changer le groupe d'un étudiant", il peut voir le changement en direct sur l'affichage du tableau à droite. De plus, la base de données est également mise à jour.

Nous pensons que l'ensemble des fonctionnalités demandées ont été faites. (Mis a part ce qui se trouve dans la catégorie : fonctionnalités manquantes).

Tests montrant des bugs

Nous avons fait essayer notre application à d'autres étudiants, dont Kilian Moulin. Il a pu détecter des bugs.

Lors d'un clique sur "Affichage" puis "Plein écran" ou bien "Fenêtré", les différents onglets pour changer de vue de "Menu" disparaissent. Ce qui fait que nous sommes alors coincés sur la vue choisie. Bug corrigé

Si l'utilisateur se rend la vue Administrateur et qu'il choisit "Changer le groupe d'un étudiant" et que l'utilisateur se met ensuite sur la vue professeur ou bien élève en passant par le menu alors il peut déplacer des élèves sans être administrateur. Bug corrigé

Conclusions

Conclusions personnelles

Bilal: J'ai trouvé ce projet intéressant à faire. Il a demandé une mobilisation de quasi toutes les connaissances que nous avons pu acquérir dans le BUT2. Ce que je trouve dommage, c'est que nous étions restreints par l'API.

Félix: Pour ma part, ce projet n'a pas été facile à réaliser, car je n'ai pas bien réussi à comprendre comment utiliser l'API. Mais grâce à l'aide de mes camarades nous avons pu rendre un résultat assez satisfaisant et je suis fier du rendu de ce projet. J'aurais bien aimé rendre l'interface un peu plus jolie, un peu plus coloré.

Romain: J'ai trouvé ce projet intéressant parce que c'est le premier où on a dû créer une application qui interagit avec une base de données. De plus, nous devions utiliser une API qui n'était pas la nôtre, ce qui nous a donc forcées à adapter notre application autour.

Conclusion générale

Ce projet a été un challenge pour nous tous dans le projet. Tout d'abord en raison de sa complexité, mais également, car nous n'avions jamais travaillé ensemble au paravent. Nous sommes assez fiers du rendu du projet, mais nous aurions aimé rajouté plus de fonctionnalités. Nous avons eu des problèmes sur la répartition des tâches à faire. Nous avons pu mettre en valeur les atouts de chacun dans ce projet, Bilal pour l'utilisation de l'API et les fonctionnalités. Romain a pu mettre en avant ses compétences pour créer une interface intuitive et agréable à regarder. Félix a pu organiser les tâches à faire, aider lors de bug en faisait du pair programming et la rédaction du rapport ainsi que la base de données.