Application de gestion des masters MIAGE de Paris-Dauphine
Le département MIDO propose six masters MIAGE : IF, ID, SITN, chacun en formation classique et en formation par apprentissage. Chaque master a ses cours, ses enseignants intervenants, etc. Les responsables de ces masters souhaitent disposer d’un outil informatique pour faciliter leur gestion, par exemple, recruter et affecter les enseignants aux cours, affecter les étudiants aux cours facultatifs en fonction de leurs préférences, des places disponibles et des contraintes horaires, etc.
L’outil actuellement utilisé (PoleInfo3) n’est plus maintenu et ne communique pas avec l’extérieur, gardant donc privées des données qui pourraient être utiles, et ne bénéficiant pas des données centrales de Dauphine (éventuellement mieux mises à jour). Il est demandé, en vue de son remplacement sans discontinuité de service, d’exposer les données de l’outil existant pour permettre la création d’interfaces graphiques compatibles et la réutilisation des données existantes.
Vous repartirez et enrichirez le projet existant Dauphine Pole Info, qui a posé les jalons utiles pour le remplacement de PoleInfo3 et propose un modèle de données proche de celui-ci. En outre, plusieurs fonctionnalités bénéficieront du (ou au) projet « Dauphine Open Data » (DOD), la communication entre les deux projets sera donc utile.
- AutoDB
-
Automatiser la création d’une BD MySQL de schéma attendu par l’application PoleInfo3 (cf. Readme du projet existant Dauphine Pole Info et de poleinfo3), documenter la façon de faire dans votre Readme au format Asciidoctor. (1)
- Basics
-
Des objets pour stocker une personne et un cours (voir table Contenu), en vue de stocker les éléments de la base existante (voir schéma application existante poleinfo3). Même chose pour Master et toutes informations nécessaires pour lier cours, enseignants et master (voir schéma SQL). (1)
- Repr
-
Pouvoir encoder et décoder en JSON chacun de ces objets pris isolément, donc sans les informations de lien entre eux (par exemple, la représentation textuelle d’un cours ne mentionne pas ses enseignants ni les masters qui le comprennent). (0,5)
- Prefs
-
Un objet permet de stocker les préférences d’un étudiant concernant les cours facultatifs auxquels il a accès. (Voir schéma SQL.) Pouvoir l’encoder et décoder en JSON. (1)
- BasicServlets
-
Chaque objet de base Thing (Pour Thing valant Course, Person) a un id et trois servlets associées : setThing(id, txt), où txt est la représentation textuelle de Thing, getThing(id), et setThing(id, field1, field2, …). Les servlets ne permettent pas de modifier les interactions entre objets (par exemple de changer l’enseignant d’un cours), seulement les détails des objets eux-mêmes (par exemple le titre d’un cours). (1)
- ServletPref
-
Servlet setPref(id étudiant, pref), getPref(id étudiant), getPrefByCourse(id course) qui retourne (en JSON) les préférences indiquées par tous les étudiants ayant choisi ce cours. (1)
- BasicClient
-
Implémenter un client qui permet, avec un GUI rudimentaire ou en ligne de commande, la modification des informations de base de Course et Person. (1)
- CDM-JAXB
-
Pouvoir encoder et décoder automatiquement des instances conformes au schéma CDM-fr à l’aide de JAXB. (2)
- ObjectsXML
-
Encoder / décoder une partie de vos objets de base en XML. Repartir du schéma CDM-fr, simplifié. (« Vos objets de base » comprend ici Master.) Encoder / décoder le reste de vos objets de base en JSON, y compris les relations. (1)
- ExtBasicServlets
-
Étendre servlets existants pour accepter et renvoyer à la demande du XML ou JSON en plus du texte. Transformer en REST. Cookie permet de mémoriser un id person, il est utilisé si l’id person n’est pas fourni, pour les servlets qui requièrent ce paramètre. (1)
- LinkServlets
-
Servlet permettant de récupérer, effacer, ajouter des liens entre master, cours et person, par id uniquement. Mêmes instructions que ci-dessus. (0,5)
- LinkClient
-
Étendre le client pour permettre de modifier les liens entre cours, master, enseignants, le munir d’un GUI moins rudimentaire. (1)
- Lib
-
Isoler la partie bibliothèque du reste du code. La publier comme un projet Maven indépendant (suffixer le nom du projet de -lib) et faire dépendre le reste du code de cette bibliothèque. Isoler la partie client du reste du code, publier comme un projet indépendant (ProjectName-client). Publier la partie serveur comme un projet indépendant (ProjectName). (1,5)
- SetDB
-
Implémenter des entités JPA et les méthodes permettant d’écrire et de lire depuis la BD de façon à garantir la compatibilité avec l’application existante. (1,5)
- UseDB
-
Modifier les servlets pour qu’ils écrivent dans et lisent la BD. (1)
- SOAP
-
Transformer certains servlets pour en faire des services SOAP. (1)
- SOAPClient
-
Transformer les clients pour en faire des clients SOAP. (1)
- DoubleReader
-
Votre client communique uniquement avec DOD au lieu de votre serveur. (DOD communique quand à lui avec votre serveur.) Votre client reçoit (en lecture seule) et affiche, en plus, les informations centrales de DOD. (1)
- Merger
-
Ajoutez, en concertation avec l’équipe DOD, un servlet sur DOD et une entité BD, qui permet de compléter l’information de poleinfo avec l’information de Dauphine centrale (là où c’est pertinent). Votre client prend en compte cette information quand elle existe. (2)
-
Un étudiant peut entrer ses préférences
-
Un responsable peut affecter les étudiants aux cours facultatifs. Ce faisant, il voit combien d’étudiants sont déjà inscrits aux cours, ce qui l’aide à équilibrer la charge.
-
Accès à la maquette d’un parcours, générée. (Cf. maquettes existantes.)