Le projet a deux objectifs correspondant aux deux grandes parties du cours. D'une part, il s'agit de mettre en oeuvre une démarche de conception "à la USDP", partant des cas d'utilisation et des scénarios pour proposer un diagramme de classe d'analyse réalisant une partie des scénarios, d'autre part, il s'agira de réaliser une partie de ce diagramme sous la forme d'une application objet distribuée.
L'outil de modélisation UML que vous pourrez utiliser est
Poseidon Community Edition (http://www.gentleware.com),
qui permet de générer du code Java, mais ne permet pas la
rétro-ingénierie. Ce logiciel est multiplateforme,
gratuit, et est installé en salle TP5.
L'outil de développement logiciel est Netbeans (http://www.netbeans.org/). Celui-ci permet de gérer tout son code dans un projet, de compiler, de débugger, etc. La version dernièrement installée permet la prise en charge des EJB et inclut un serveur d'applications.
Un certain nombre d'enseignants de l'UFR informatique souhaite
mettre en place un système d'information pour gérer une
partie du PCI (Permis de Conduire Informatique) qui est actuellement
gérée de façon non centralisée, à
l'aide de courriers électroniques et de fichiers Excel. L'annexe
1 décrit le fonctionnement du Permis de conduire informatique,
tandis que l'annexe 2 présente le cahier des charges mis en
place par les responsables du PCI, c'est à dire tout ce que
devrait permettre de faire le système. Plusieurs
fichiers sont également fournis qui montrent le
fonctionnement actuel.
Chaque groupe de 3 ou 4 personnes aura pour objectif de mener une conception complète du système d'information visé. Il s'agira de mener les activités de capture des besoins, analyse, conception, réalisation et test. Bien entendu, cette volonté de conception complète entraîne la nécessité de modéliser le système de plus en plus finement, et de se concentrer sur des sous-parties.
Ainsi, chaque groupe mènera une analyse du domaine complète, et déterminera l'ensemble des cas d'utilisation et des acteurs liés au système. Par la suite, chaque groupe se concentrera sur un certain nombre de cas d'utilisation, et en raffinera les scénarios de façon beaucoup plus détaillée. Certains scénarios seront ensuite choisis pour être réalisés comme des collaborations d'objets, ce qui permettra de mettre en place un diagramme de classes d'analyse, qu'il s'agira ensuite de raffiner en diagramme de classes de conception, en prenant en compte les contraintes de réalisation. La partie de codage visera à mettre en place une application réalisant les scénarios choisis, qui devra fonctionner.
Chaque groupe devra viser la réalisation d'une partie indépendante de l'application. Il devra néanmoins tenir compte de l'environnement décrit, ainsi que des interactions supposées avec les autres parties. Pour cela, il décrira les interfaces de son système avec le reste de l'application ou l'extérieur.
À l'exception de la première analyse des besoins, chaque groupe se concentrera sur des cas d'utilisation et des scénarios différents :
Le vendredi 20 mai.
Chaque groupe enverra un fichier zip contenant :
Le Permis de Conduire Informatique est une UE transverse de L1
à l'Université Claude Bernard, que tous les
étudiants en science doivent valider. Elle se compose de 12 TP
de 2 heures, ainsi que de 5 cours magistraux, répartis sur un
semestre. Le site http://pci.univ-lyon1.fr détaille les
différents modules de l'UE, et propose les supports au
téléchargement. PCI est piloté par 7
enseignants-chercheurs de Lyon 1 (Noyau Dur), et emploie une
cinquantaine d'enseignants pour les TP (Intervenants). Les
étudiants sont entre 1200 et 1500 chaque premier semestre de
l'année scolaire. PCI occupe en moyenne quatre salles de TP en
parallèle pendant toute la semaine, du lundi matin au vendredi
soir. Chaque séance de TP rassemble une quinzaine
d'étudiants et un intervenant pendant 2 heures, et est
notée entre 0 et 2 pour chaque étudiant. La note de TP
des étudiants est calculée en fin de semestre en
utilisant les notes de chaque TP. Un étudiant peut
également être noté ABJ (absence justifiée),
ABI (absence injustifiée), ou PPN (peux pas noter, par exemple
en cas de panne réseau sur un TP réseau). Les ABI sont
les notes par défaut qu'obtient un étudiant qui n'a pas
de note (ils ne sont pas mis directement, mais déduits de
l'absence d'autre indication).
Un étudiant est inscrit dans un groupe de TP qui a cours dans une certaine salle à une certaine heure. Un étudiant fait également partie d'une lanière, qui regroupe des créneaux de TP sur deux demi-journées (par exemple, si l'étudiant appartient à la lanière A, il aura TP de PCI au cours d'un des créneaux disponibles le lundi matin ou le mardi après-midi). Les affectactions dans les groupes de TP et les créneaux sont faites au début d'année, le plus souvent dans l'urgence. Certains étudiants doivent donc changer de créneau dans les premières semaines (au sein de la lanière), pour cause d'incompatibilité avec d'autres enseignements. D'autre part, certains étudiants arrivent en cours d'année, et il convient de les placer, et de leur faire récupérer les créneaux manqués. Enfin, certains étudiants peuvent être ponctuellement absents, et demander pour un TP à changer de groupe dans la semaine. Tout changement de groupe doit être validé, en favorisant les échanges entre deux groupes aux simples déplacements. Les intervenants gèrent les changements de groupe ponctuels, qui doivent être validés par une raison suffisante, et prévus. Un intervenant se trouve donc au cours d'un TP avec ses étudiants normaux, ainsi que des étudiants en récupération, qu'il devra également noter. Il doit également au cours du TP assurer l'interface avec les organisateurs pour les différentes demandes étudiantes. Un intervenant doit également à la fin de son TP indiquer : le nombre de places disponibles dans son groupe (il y a toujours moins d'étudiants que les étudiants inscrits), ainsi que le nombre de machines qui ne fonctionnent pas. Cela pourra être pris en compte ensuite pour les affectations de récupérations d'étudiants dans les groupes les moins chargés.
A priori, une récupération sera opérée dans la semaine où le créneau original ne convenait pas. On se donne comme règle qu'il y ait au maximum deux types de TP différents dans un même créneau (par exemple, 13 étudiants qui font le TP normal de la semaine, ainsi que 2 qui récupèrent le TP de la semaine précédente). Cette règle pourra être contournée pour les récupérations intensives d'un étudiant arrivé avec un mois et demi de retard.
La mise en place du planning consiste à définir les
groupes de TP, à les affecter à des créneaux et
à des salles, et à leur associer des intervenants, en
gérant les contraintes d'emploi du temps de ceux-ci. Il faut
également tenir compte des jours de congé, et assurer 12
semaines pour 12 TP entre le début des cours et les vacances de
Noël. Les intervenants peuvent être ponctuellement absents,
et doivent donc se faire remplacer. Le principe vu du point de vue du
Noyau dur est que le jeu est à somme nulle : chaque intervenant
sera payé pour 12x2=24 heures de TP par groupe qu'il assure, ce
qui signifie que les intervenants doivent mettre en place des
échanges. Ceci est actuellement réalisé par le
moyen d'un forum, et de résumé hebdomadaires des demandes
d'échange en cours envoyés à tous les intervenants.
L'ensemble du système est accessible par un portail web (i.e. un
site collaboratif possédant une couche applicative et
relié à une base de données). Chaque intervenant
possède un compte sur ce site. Il peut ainsi accéder
à des informations spécifiques (corrigés des TPs,
consignes générales, etc.). À partir de ce compte,
il peut également lancer les applications correspondant aux
différentes tâches à réaliser par le SI
(entrer les notes des étudiants, les rattrapages de TP, ou
accéder à l'application d'échange de
créneaux entre intervenants). Enfin, chaque intervenant
possède une page d'accueil qui lui permet de mettre en ligne des
informations le concernant et spécifiques au PCI. Les membres du
noyau dur ont des comptes avec des droits étendus, ce qui leur
permet en plus de gérer les contenus des pages et de la base. Ce
sont également eux qui doivent valider toute information
publiée vers l'extérieur. Les étudiants n'ont pas
de compte sur le site, mais peuvent accéder à sa partie
publique.
L'application attendue doit être capable :
L'implémentation de l'application devra être réalisée en Java, et utiliser les techniques apprises en cours (servlets, JSP, EJB).