Ces projets, communs aux groupes de Licence MIAGE 3 et à ceux de Licence Informatique 3 sont dirigés par M. Pierre Crescenzo.
Sujet des projets 2010-2011
1. Modalité de déroulement du mini-projet
Ce projet est à réaliser par équipe de quatre étudiants (s'il reste, à la fin de la composition des équipes, des équipes de moins de quatre étudiants ou des étudiants esseulés, M. Pierre Crescenzo formera alors autoritairement des équipes avec ces étudiants). La formation des équipes est libre et vous pouvez mélanger des étudiants de tous les groupes de TD de Licence MIAGE 3 et Licence Informatique 3. Chaque équipe doit indiquer sa composition par l’envoi d'un courriel à M. Pierre Crescenzo (en mettant obligatoirement en copie les quatre membres du groupe) au plus tard vendredi 5 novembre 2010. Le courriel doit donner les prénom, nom, promotion (MIAGE ou Informatique), groupe de TD et adresse de courriel "unice" de chacun de ses quatre membres.
Le projet est à réaliser à partir du samedi 6 novembre 2010. Il doit être rendu à M. Pierre Crescenzoau plus tard lundi 6 décembre 2010 sous deux formes : un unique PDF par courriel et le même document imprimé et relié dans le casier de Valrose (étage 4 du bâtiment Petit-Valrose) de M. Pierre Crescenzo. Tout retard du courriel ou du rapport papirt sera pénalisé.
Une liste des outils UML est disponible à l’adresse
http://en.wikipedia.org/wiki/List_of_UML_tools
Tout retard dans la formation des équipes (30 novembre) ou la remise du dossier (8 décembre)
entraînera une pénalité sur la note du projet.
2. Sujet
Le mini-projet repose sur la modélisation de l’informatisation d’une bibliothèque universitaire pour
étendre ses fonctionnalités. Votre point de départ est constitué par les TD que vous avez réalisés en
UML. Vous pouvez réutiliser tout ce que vous avez fait, corrections de TD y compris (c’est même
fortement conseillé !).
La conception et la spécification que vous devez réaliser doivent prendre en compte les besoins
suivants :
• Aucune réservation n'est possible sur aucun document. Le système n'a donc pas à gérer les
réservations.
1/2
• Les informations d'emprunt sont maintenues par le système, même après qu'un emprunt soit
terminé, afin d'obtenir l'historique des emprunts pour un adhérent spécifique, un exemplaire de
livre ou un livre.
• La gestion des commandes est effectuée par le système : vous partez de l'hypothèse que les
éditeurs utilisent tous un format standardisé pour fournir les catalogues et que les commandes
peuvent être passées par internet. Le système devra aussi fournir une interface web (en
intranet) pour que les enseignants proposent des achats et consultent les livres déjà présents.
• La gestion de l'état des livres est effectuée par le système. Un livre peut être considéré
"comme neuf", en "bon état", "partiellement abîmé" ou "très abîmé". Le système proposera
d'envoyer "en réparation" les livres très abimés ou de les retirer définitivement du prêt s'ils ne
peuvent être réparés. Le système devra aussi gérer la perte d'un livre (il est considéré comme
perdu 2 mois après la relance). La relance d'un emprunt en retard n'est effectuée qu'une fois,
deux jours après sa date de retour prévue. Tous les adhérents doivent donner un e-mail et les
relances sont font uniquement par courrier électronique. La perte d'un livre est sanctionnée par
une interdiction d'emprunt de 12 mois.
• Les pénalités sont gérées en adaptant ce qui a été explicité dans le premier TD UML : On ne
peut pas emprunter plus de 3 livres en même temps, et la durée maximum d’un prêt est de 15
jours pour un étudiant et de 1 mois pour un enseignant. Les adhérents sont relancés par
courrier électronique lorsqu’ils ne rendent pas leurs livres dans les délais. Les adhérents qui
n’ont pas rendu les livres qu’ils ont empruntés dans les délais ne peuvent pas emprunter de
livres pour une durée égale au dépassement du délai, et cela à partir de la date de restitution
des livres.
3. Contenu du dossier à rendre
Le dossier comprendra la conception et la spécification de votre modélisation. Il sera composé des
éléments suivants :
La conception en UML, avec les diagrammes de cas d’utilisation, un diagramme détaillé de
classes (signature typée des attributs et des méthodes) et pour chaque diagramme de cas
d’utilisation un diagramme de séquence correspondant (chaque diagramme de séquence doit
être accompagné d’une description du scénario spécifié, puisqu’un diagramme de séquence ne
décrit qu’un scénario particulier du cas d’utilisation général). Si nécessaire, les diagrammes
d'état devront aussi être fournis.
La spécification en OCL des invariants, et des préconditions et postconditions pour chaque
classe et/ou méthode importante qui apparaît dans un diagramme de séquence précédemment
demandé, et éventuellement pour chaque méthode que vous jugerez pertinente.
Attention : les assertions qui peuvent spécifier l’intégrité référentielle des associations entre
classes ne sont pas demandées. Seules les autres formes d’assertions doivent apparaître.
Une introduction à la partie UML dans laquelle vous expliquerez vos principales décisions
de conception face aux besoins. Chaque diagramme et chaque spécification pourra comporter
un paragraphe d’introduction dans lequel vous motiverez les choix effectués.
NB-1 : la description du système d’information est forcément incomplète. Vous pouvez compléter et
faire les choix qui vous semblent les plus appropriés pour obtenir une modélisation cohérente, en
n’oubliant pas de préciser ces hypothèses dans la partie d’introduction.
NB-2 : Les classes déjà présentes dans le langage OCL n’ont pas à être spécifiées. En revanche, si
vous avez besoin d’une classe utilitaire que vous connaissez dans une bibliothèque de classes (Java ou
autres), vous pouvez utiliser sa définition en UML, et il serait alors bienvenu de spécifier les parties
utilisées à l’aide d’assertions.
2/2
Vous n'êtes pas connecté. Connexion 