15. Projets#
Description#
Le projet consiste à réaliser individuellement une mini-application fortement centrée sur la conception du modèle de données et sa réalisation avec JPA/Hibernate. Des énoncés sont donnés ci-dessous.
Pour chacun, la ligne directrice est la même. Je fournis des énoncés dans ce qui suit, vous êtes libres de choisir celui qui vous convient.
Ce qui est impératif#
Il faut impérativement effectuer les étapes suivantes qui constituent le noyau des connaissances à acquérir.
concevoir le modèle de données avec UML (ou équivalent) en distinguant bien les classes, les associations et les relations de généralisation (héritage); ce modèle peut être validé par votre enseignant avant tout début de réalisation, en me l’envoyant par mail (raphael.fourniersniehotta@lecnam.net);
créer le schéma de la base de données et le modèle Java, sur la base de la conception effectuée précédemment; bien entendu, les deux doivent être liés par un mapping JPA;
insérer quelques données et implanter une mini-application Web MVC qui permet de naviguer dans la base et de consulter les données.
Avec JPA, le but et de concevoir des applications orientées-objet dont la persistance n’est qu’un aspect. La base de données ne sert qu’à représenter les données, « nues », les classes représentent les données et les comportements (logique métier). Pour que cela soit bien clair, il sera bon d’implanter quelques calculs « métiers » et de montrer leur résultat. Les énoncés sont prévus en ce sens.
Ce qui est optionnel#
En plus des étapes impératives, l’évaluation du projet tiendra compte des fonctionnalités suivantes:
intégration de l’interface Web dans un template avec menu, logo, etc., comme vu en cours;
utilisation intensive des liens HTML, pour « naviguer » dans la base et bien mettre en évidence sa structure de graphe d’objets;
minimisation des requêtes SQL par utilisation appropriée de HQL;
réalisation d’une transaction applicative.
Ce qui est apprécié#
Enfin, des critères non spécifiques à JPA/Hibernate seront appréciés: bonne organisation de vos classes, normalisation des règles de nommage, documentation, commentaires. C’est l’aspect le moins essentiel, mais pensez à le soigner quand même.
Rendu du projet#
Le code du projet doit être fourni sous la forme d’une archive d’application Web
.war. Cette archive doit pouvoir s’installer directement sous un
environnement Tomcat/MySQL/JPA/Hibernate conforme à celui décrit dans l’ensemble
du cours. La validation par les enseignants consiste à installer l’application,
à consulter les différentes pages et à vérifier les fonctionnalités implantées.
Un extrait de la base de données avec laquelle vous avez travaillé devra être
également fourni, pour faciliter le test des fonctionnalités de votre projet.
Un bref rapport devra accompagner le projet, décrivant l’installation, le schéma de la base, éventuellement un jeu de données (vous pouvez exporter votre base MySQL), une liste des fonctionnalités et quelques copies d’écran. Le fichier sera fourni au format pdf et ne devra pas excéder 10 pages (minimum 1 page).
Les règles de nommage à respecter sont les suivantes :
la base sql porte votre nom. Le dump a pour extension .sql. Exemple : fournier.sql, contenant la base fournier.
le fichier contenant le code porte aussi votre nom, suivi du type de projet. Exemples : fournier-mine.war, fournier-tourisme.war
le rapport a le même schéma de nommage que l’archive WAR, mais pour extension .pdf. Exemple : fournier-tourisme.pdf
les trois fichiers sont à déposer sur la plateforme Moodle, dans la section dédiée et avant la date limite indiquée dans le message de lancement du projet.
les trois fichiers sont inclus dans une archive au format zip (exemple : fournier-tourisme.zip), déposée sur la plateforme Moodle dans la section dédiée et avant la date limite indiquée dans le message de lancement du projet. La plateforme ne permettra pas les rendus au-delà du dimanche suivant (et les retards seront indiqués).
Le non-respect du schéma de nommage sera sanctionné. Les envois de pièces jointes par mail ne seront pas acceptés.
Projet 1: Une exploitation minière#
Les besoins#
Une exploitation minière est chargée d’exploiter des gisements de minéraux précieux (le bouzon) ou de gaz énergétique (le HzK2). L’organisation de cette mine est la suivante.
Tout d’abord le personnel d’exploitation est organisé en équipes, chaque équipe étant affectée à un unique gisement. Il peut en revanche y avoir plusieurs équipes affectées à un gisement important.
Une équipe est constituée d’un ensemble d’ouvriers, qui peuvent être soit des êtres humains, soit des robots. Tous les ouvriers ont un nom et une date d’affectation à leur équipe. Un être humain a un salaire. Un robot n’a pas de salaire: en revanche il est caractérisé par son modèle et son numéro de série. Un modèle est caractérisé par sa date de conception et son coût d’exploitation mensuel. Ajoutons qu’une équipe est dirigée par un des ouvriers humains, le chef d’équipe.
Quelques précisions sur les gisements. Comme dit plus haut on distingue les gisements de bouzon et les gisements de HzK2. Cependant tous les gisements ont en commun une date de mise en service et un rendement mensuel. La valeur du bouzon est estimée à partir de son coefficient de pureté qui varie entre 0 et 1, tandis que la valeur du HzK2 dépend de sa densité (également entre 0 et 1).
On veut donc donner les spécifications du système d’information de la mine. Un des objectifs est d’estimer la rentabilité de chaque gisement: cette rentabilité est la différence entre le coût mensuel des équipes travaillant sur le gisement et le revenu mensuel du gisement. Voici les règles de calcul de ces paramètres.
Le coût d’un robot est la somme de son coût d’exploitation (dépendant de son modèle) et de 0,3546 fois le nombre de jours depuis sa date d’affectation à l’équipe.
Le coût d’un humain est la somme de son salaire et d’un coût fixe de 5 000 euros.
Le revenu d’un gisement de Bouzon est son rendement multiplié par le coefficient de pureté.
Le revenu d’un gisement de HzK2 est le rendement multiplié par la densité multiplié par 18,987.
Bien entendu le coût d’une équipe est la somme du coût des ouvriers la composant.
La conception (diagramme UML)#
Proposez une modélisation des équipes : indiquez les classes, les associations. Précisez soigneusement l’emplacement des attributs.
Définissez une ou plusieurs méthodes permettant de calculer le coût mensuel d’un ouvrier et d’une équipe. Spécifiez chaque méthode avec précision et concision en fonction des attributs définis précédemment (pseudo-code).
Maintenant complétez le modèle en intégrant les informations sur les gisements. Spécifiez la ou les méthodes donnant le revenu d’un gisement.
Définir une méthode calculRentabilite() qui calcule la rentabilité d’un gisement comme indiqué dans l’énoncé.
L’implantation (JPA/Hibernate)#
Donnez le schéma de la base résultant du modèle UML. Implantez ce schéma avec MySQL.
Réalisez le modèle JPA de l’application.
Réalisez une mini-application MVC affichant les données de la base.
La logique métier (en option)#
Implantez le calcul de rentabilité selon les spécifications données.
Projet 2: Un site de services touristiques#
Les besoins#
Vous avez sans doute déjà utilisé un site notant et recommandant des services touristiques, de type TripAdvisor. Il est demandé de modéliser une version simplifiée d’un tel site, et de réaliser une petite application de navigation basée sur les techniques ORM. Nous appellerons cette application CnamTourisme.
Le site propose donc un catalogue de services touristiques. Un service a un nom, une courte description, est nécessairement géolocalisé (adresse, ville, pays). Le catalogue décline plusieurs types de services
les hôtels, avec leur classement (1 à 5 étoiles), le nombre de chambres;
les restaurants, avec leur capacité, quelques indicateurs (terrasse, réservation, etc.);
des activités (visites, sports, etc.), avec leur durée, les horaires.
CnamTourisme a passé un accord avec chaque service pour que ces derniers proposent, à tout moment, leur(s) meilleure(s) offre(s). Une offre est décrite de la manière suivante:
le nombre de personnes;
le prix pour CnamTourisme;
un court descriptif.
Par exemple, une offre d’un restaurant peut être « Repas touristique pour 2 personnes, 89 Euros »; une offre d’un hôtel peut être « 3 nuits en chambre double pour 249 Euros », etc.
CnamTourisme applique une marge à chaque offre:
pour les hôtels: un pourcentage négocié avec chaque hôtel, et appliqué au prix de l’offre (par exemple 5%);
pour les restaurants: une taxe par personne de 3 Euros;
pour les activités: une marge .fixe négociée avec chaque fournisseur.
Après application de la marge, on obtient le coût de l’offre proposée aux internautes.
Les internautes peuvent noter un service touristique, avec une note globale de 1 à 5 et un commentaire. En option, vous pouvez ajouter des critères d’évaluation propres à chaque type de service. Par exemple un hôtel est évalué sur la qualité de la literie ou le calme, un restaurant sur la fraîcheur des plats ou l’accueil, etc.
CnamTourisme doit essentiellement permettre de rechercher des services touristiques par localisation (ville, pays), soit globalement, soit en indiquant un type de service particulier. Pour chaque service, on doit pouvoir consulter la liste des notes et commentaires des autres internautes. On doit aussi pouvoir consulter les offres proposées par chaque service, avec leur coût.
La conception (diagramme UML)#
Proposez une modélisation des services touristiques et des internautes.
Indiquez comment calculer le coût-internaute des offres, pour chaque type de service.
L’implantation (JPA/Hibernate)#
Donnez le schéma de la base résultant du modèle UML. Implantez ce schéma avec MySQL (ou n’importe quel autre système).
Réalisez le modèle JPA de l’application.
Réalisez une mini-application MVC affichant les données de la base.
La logique métier (en option)#
Implantez un mini moteur de recherche permettant d’effectuer des sélections mutli-critères sur les services (par prix, par localisation, par type, etc.)