Sujet du mini-projet :

Attention, petite modification dans le sujet : plus d'obligation d'utiliser RowSet.

Écrire une application de facturation pour un magasin qui vend des articles de papeterie.

Cette application devra offrir à l'utilisateur une interface graphique pour saisir et afficher sur l'écran une facture pour un client qui vient d'acheter des articles du magasin. Il ne faut donc pas que les manipulations soient longues et complexes, ce qui ralentirait le processus de vente. Vous pourrez supposer que les types d'articles vendus sont fixes. Vous pourrez aussi supposer que les données sur les produits sont déjà dans la base de données et ne sont pas modifiés par l'application (inutile d'écrire du code Java pour saisir de nouveaux produits ou pour modifier leurs caractéristiques).

Il devra aussi être possible de modifier une facture, de faire afficher toutes les factures, ou toutes les factures d'un certain client ou d'un certain numéro et de supprimer une facture.

Pour simplifier, les clients seront représentés seulement par leur nom.

La base de données des articles et des factures sera gérée par Oracle. Cette application constituera le projet qui comptera pour le contrôle continu de ce cours. Le projet devra être rendu avant le jeudi 8 novembre minuit.

Ce que le code devra obligatoirement comporter :

Ce format est vraiment obligatoire et tout projet qui ne le respecte pas sera très fortement pénalisé. 2 objectifs principaux à cette contrainte :

Vous pouvez utiliser tout IDE que vous voulez à partir du moment où vous comprenez tout le travail effectué plus ou moins automatiquement par cet IDE.

Vous devez respecter les grands principes de programmation que vous avez appris : encapsulation (par exemple, pas de variables publiques, et le moins possible de variables protected), modularité, extensibilité (du polymorphisme en particulier plutôt que des "switch"), réutilisabilité, documentation de l'application (javadoc en particulier pour une application Java), etc.

La documentation est particulièrement importante. Le correcteur ne devra pas passer trop de temps à comprendre le code et l'architecture globale de l'application devra être expliquée, si nécessaire.

Vous séparerez le plus possible l'interface graphique, les classes "métier" et la couche de persistance.

Modalités du projet

Chaque groupe de projet doit comporter 4 membres (à la rigueur 5 si le nombre total d'étudiants n'est pas divisible par 4). Un des buts du projet est de vous apprendre à travailler en groupe. Chaque groupe doit comporter un chef de projet qui coordonnera le travail du groupe, veillera à la bonne marche du développement et sera le correspondant de l'enseignant en cas d'échanges de messages. La constitution des groupes devra être envoyée à grin@unice.fr avant le vendredi 28 septembre minuit, avec l'adresse du site Web du projet.

Pour éviter que le correcteur ne passe des heures à corriger votre projet et pour qu'il puisse juger de travail du groupe et de chacun de ces participants, les modalités qui suivent doivent être strictement respectées.

Le correcteur doit pouvoir tester rapidement l'application dans son propre environnement, depuis sa propre machine.

Toute question sur le projet devra être envoyée à grin@unice.fr par le chef de projet. Soyez précis et indiquez bien qui vous êtes (nom, prénom) et dans quelle filière vous travaillez (M1 info, projet BD avancées).

Site du projet

Chaque binôme devra écrire un site Web pour le projet.

Son adresse (cliquable) devra être envoyée par mail à grin@unice.fr avant le vendredi 28 septembre minuit, en même temps que la composition du groupe. A cette date le site pourra ne comporter que le titre du projet et les noms des participants. Vous y indiquerez ensuite (au moins) l'état d'avancement du projet (avec les dates des étapes) et les liens vers des sites que vous aurez utilisés pendant le développement. A la fin du projet, un lien pointera vers la page finale du projet (présentation du projet, exécutable, fichier zip envoyé au correcteur et contenant tout le projet,...).

Le contenu de ce site, et sa mise à jour régulière au fur et à mesure de l'avancement du développement comptera dans la note finale (la forme est secondaire ; inutile de passer trop de temps dessus).

La base de données

Très important : pour éviter les problèmes d'homonymie sur les noms d'entités (tables, index, séquences,...) manipulés par la base de données utilisée par le correcteur, les noms de toutes les entités devront avoir un suffixe unique parmi tous les projets reçus par le correcteur. Pour cela vous suffixerez les noms de ces entités par les initiales des noms de chacun des participants au projet. Par exemple, si les auteurs du projet sont Dupond, Durand, Robert et Dupuis et si une table contient des factures la table s'appelera FACTURE_DDDR. Vérifiez qu'il n'y a pas d'homonymie avec un autre groupe ; si c'est le cas, ajoutez un numéro, par exemple FACTURE_DDDR2. En revanche, les classes Java ne devront pas être suffixées ; par exemple, la classe s'appellera Facture, et pas FactureDddr.

Le test du projet devra partir d'une base de données vide. Le projet devra donc créer les données nécessaires à son exécution (choisissez le moyen que vous voulez du moment où c'est automatiquement fait en lançant les fichiers execute.bat ou execute.sh). Le test doit pouvoir être lancé plusieurs fois consécutives sans provoquer d'arrêt provoqué par des erreurs.

Format obligatoire pour rendre le mini-projet :

Le projet devra être fourni sous forme d'un fichier zip (pas de tar.gz ou autres formats) contenant tout sur le projet (vous devez respecter les noms des fichiers donnés ci-dessous) :

Vous pouvez aussi (c'est optionnel) ajouter des diagramme UML (de classes ou autres) si vous pensez qu'ils peuvent être utiles. Mettez-les dans le fichier zip et indiquez où ils se trouvent par un lien dans le guide de programmation du projet.

IMPORTANT :

Comment rendre le projet

Tout dépassement de la date limite aura un impact négatif sur la note.

Pour rendre le projet, envoyez un message électronique à grin@unice.fr. Un seul message par binôme. Le sujet du message sera du type "Projet M1 info BD avancées de Dupond, Durand, Robert et Dupuis". En cas d'homonymie, précisez le prénom.

Le corps du message devra

  • rappeler le projet choisi et les noms des étudiants du binôme
  • comporter en plus l'adresse (cliquable s'il vous plait !) de la page du projet sur le Web.
  • Le fichier zip (pas un autre format de compression, svp) attaché au message devra comporter tout votre travail sur ce projet (relisez le début de cette page). Ce fichier zip devra aussi être accessible er récupérable depuis la page Web du projet, mais seul le fichier zip envoyé par mail sera utilisé par le correcteur.

    Évitez d'envoyer plusieurs messages pour un même projet. Testez si tout va bien en vous envoyant d'abord le message et en vous plaçant dans un environnement neutre (par exemple pas sur la machine qui contient votre page Web et vos répertoires de développement) pour le tester, comme si vous étiez le correcteur. Seule la première version envoyée sera prise en compte pour la correction.

    Notation

    Il sera tenu le plus grand compte de

    1. la lisibilité
    2. l'extensibilité
    3. l'ergonomie (faites tester par une personne étrangère au développement...)

    de l'application.

    On préfère de très loin une application qui fait le minimum mais qui le fait bien, d'une façon robuste et conviviale et bien documentée, à une application avec beaucoup de fonctionnalités mais qui se plante ou qui est difficile à utiliser et pas extensible.

    Toute application qui ne respectera pas le format indiqué ci-dessus ne sera pas corrigée. Idem pour les applications qui ne seront pas documentées ou qui auront, par exemple, une javadoc sans information véritable. Il est temps de prendre des bonnes habitudes pour ceux qui ne les ont pas déjà (une toute petite minorité évidemment...).

    Bon travail...