Informatique - Université de Sherbrooke
publicité
Université de Sherbrooke Département d’informatique Rapport de projet Gestion des Équipements IFT785 – Approches Orientées Objets Remis à : M. Sylvain Giroux Par : Youssef Bannari 00 979 686 Hiver 2006 La description du projet Gestion des Équipements Le projet consiste à développer un système permettant la gestion des équipements du laboratoire DOMUS. La gestion est en temps réel, demande une facilité d'utilisation pour la saisie des informations du matériel, mais aussi pour la mise à jour de la personne qui emprunte le matériel. Il est donc demandé de concevoir un système qui permet de gérer le matériel (ajout, suppression, mise à jour) dont la sauvegarde des données peut être migrée vers des supports différents (BD, fichiers XML, fichiers texte, sérialisation, etc.) Le code doit être écrit de A à Z. Certains éléments peuvent être réutilisés de projets existants selon le besoin. Client : Francis Bouchard, étudiant en doctorat au laboratoire DOMUS. Membres de l’équipe: Bannari Youssef Blondel Matthieu Henaff Éric Kchouk Bilel Lebeau Jean-François Meghaoui Ali Paccoud Blandine Contraintes de développement Nous avons définis quelques contraintes avant de commencer l’implémentation du système, elles sont les suivantes : - Les utilisateurs peuvent emprunter un matériel donné pour une période donnée - Les données doivent être stockées dans plusieurs supports (BD, fichiers XML) - Les équipements sont regroupés par type (Laptop, PDA, etc...) - La saisie des informations du matériel se fait soit manuellement soit automatiquement (lecteur de tag RFID). - Architecture trois tiers (client léger) Liste des Tâches Les grandes fonctionnalités de l’application : - Gestion des utilisateurs selon leurs niveaux (Administrateur, prêteur et emprunteur) - Gestion des équipements (ajout, suppression, mise à jour) - Gestion des prêts par utilisateur. - Sauvegarde des données (BD MySQL, fichiers XML) - Notification des utilisateurs par email (le cas d’un retard) - Gérer le lecteur de tag RFID. Contrôle des variables Dans le cadre de programmation extrême, les usagers et les gestionnaires contrôlent normalement 3 des 4 variables. Dans notre cas : Le coût: il est contrôlé par le gestionnaire et le client (40 heures/personne pour le développement) Le temps: il est contrôlé par le gestionnaire et le client (fixer la date de remise) La portée: si nous avons choisi la portée, notre code doit être bien structuré et extensible et que l’interface soit bien conçu. La qualité: si nous avons choisi la qualité il faut que toutes les taches soient réalisées. Le développement de l’application Nous avons utilisé CVS pour le partage de code et de fichiers. Pendant le développement de l’application nous avons parcouru les étapes suivantes: - Implémenter les Classes: Hardware, HardwareType, User, Loan. - Installation/Configuration MySQL et la création de la basse de données. - Gestion des équipements (ajout, suppression, mise à jour) - Gestion des utilisateurs (ajout, suppression, mise à jour) - Gestion des prêts. - Sauvegarde des données dans la BD MySQL. - Création de l’interface Web. - Consultation/Recherche/Historique. - Gestion de la session/authentification selon le niveau de l’utilisateur. - Sauvegarde XML. - Notification par e-mail. - Monitoring. - Gérer le lecteur de tag RFID. - Intégration dans le servlet. Modèle de données HARDWARETYPE HardwareType_Id Description 1,n Hardware have USER User_Id FirstName LastName Email Login Password Level 0,n Loan Loan_Id Loan_Date Loan_Return Loan_Effective_Return Hardware_Id Description SerialNumber 1,1 Brand Available 0,n Comment Mac_Address Diagramme de classes Screenshot Les designs patterns Les designs patterns utilisés sont : Strategy Package server/management/UserRight Utilisé dans DataManagerServices et package servletpages pour gérer les droits d'accès. Mediator DataManager agit comme mediator pour ses quatre composantes internes (UserManager, HardwareManager, etc.) Facade Premier DataManager sur ses quatre composantes internes (UserManager, HardwareManager, etc.) Deuxième DataManager [Web/etc.]Services Factory Method DataManager pour la connetion (avec réflexivité) PageBuilderFactory (avec réflexivité) UserRightAccessFactory Tamplate Method Pour la partie Abstraction: AsbstractManager HardwareManager, UserManager, LoanManager, HardwareTypeManager Pour la partie Implementor: AbstractManagerImpl HardwareManagerImpl Le package sql et le package xml. Builder le package servletPages (IPageBuilder, PageDirector, le package PageBuilders) Singleton DataManager, UserManager, LoanManager, HardwareManager, HardwareTypeManager Expérience personnelle Organisation du travail (Première rencontre) Pour la première rencontre nous avons créé un emploi du temps pour respecter le nombre d’heures allouées et la rotation des membres de l’équipe. Nous avons consacré 40 heures (deux semaines) à la programmation par paires. Chaque membre de l’équipe a travaillé une moyenne de 20 heures par semaine. Programmation extrême et Programmation par paires Programmation Extrême est une méthode agile de gestion de projet informatique, dont l'objectif est de permettre de gérer des projets de manière simple et efficace. Ce que j’ai aimé plus Dans mon expérience, ce que j’ai aimé le plus c’est le concept de la programmation d'équipe, cela renforce énormément l’esprit d’équipe. Nos avons travaillé la plus part du temps ensemble dans la même salle, la communication est immédiate. Malgré le niveau différent de chaque membre de l’équipe en programmation après la première semaine j’ai remarqué une amélioration au niveau de mes connaissances. L’information circulée très rapidement. Refactoriser continuellement, dans la programmation extrême nous sommes toujours entrain d’améliorer notre code, cela permet une longévité et plus de réutilisabilité pour le code. La planification constante : nous pouvons toujours au court du projet de changer la planification initiale. Donc ne nous somme pas toujours pris avec une seule vision, celle initialement conçue. Dans le cas d’un petit projet la programmation extrême est très bénéfique, mais je ne sais pas est ce que ca sera le même cas pour des projets plus grands? Ce que j’ai aimé moins J’aurais aimé avoir une bonne étape de conception surtout au début du projet, a cause il y’a peu de spécifications au départ. Malgré que les tests nous permettent d’avoir une bonne idée de la logique de notre code, le fait d’écrire des tests avant d’écrire du code a provoqué une confusion au départ. L’ampleur des erreurs: après avoir avancé dans le projet si les tests initiaux n'été pas correctement conçus nous prenons un recule. Conclusion En général l’expérience est une bonne initiation à la programmation extrême elle est très appréciée et très bénéfique, j’aimerais bien la vivre dans un projet de grande ampleur. Merci.
