Home

Projet ARGOSI

1. Haa TITS de d veloppe Mea osei E E ea NEE A a INDE 4 11 2 4 Limites de la COR EN edenmnraltercsptermsntnennenedenaneeee eur tnteeseeee etre none net Ont iini 4 11 2 5 Penes de COMCEL dd filet dalt a 5 11 2 6 DAS e ROCES DR A R AL 5 2 7 DOS ESSE A lan EE ET 5 11 3 PEA AONE TEE lata 5 11 4 TEST ET CONTR LE DU CODE DE L APPLICATION cccooccoonnconnnconnncnonaconanonnnoconnncnnnnnnnnnonnnncnnn aran nc terene reene rerent 6 IL S GESTI N DE PROJET ociosa its 7 HI A A E E E E E E E EE 7 HI 1 COUVERTURE DES BESOINS FONCTIONNELS nues secesrernennne secs eeerennene sec enernnenee secs ecenenneneee seen 7 II 2 VALIDATION DE L ARCHITECTURE ET DES CHOIX TECHNIQUES cccocooononnnonccnononnanononcnnononnnnnnonconononnanananonoos 7 LES ANALYSE ET ONCE TON aid nee 8 Wa PROGRAMMATION DE L APPLICATION coi teen ERE EES Eo diner SEREK ESE STi EEES 8 IT 4 1 A a Lu EL LA SR a ER E E EEA IRE A OARE 8 111 4 2 Diler gces DIE GUEO br caes eat aa AA a je ie 9 1 4 3 A linsesblne E E lanta E E ttes etant enese Me dti 9 LS QUALITE VERIFICATION VALIDA TION ETE ennemies 9 MA DS LE EN TO ads 9 IV MISE EN PLACE DU SECOND INCR MENT seras 10 D A a E a E O 10 D TE e a OOO 10 W3 ROLUS enren a E A ant tone O EE der 10 A PLANIFICATI N E E E EAE ET 10 V GLOSSAIRE ET ARRE IRON cin daa 11 VI BIBLIOGRAPHIE ET DOCUMENTATION o conccccoconncconcnncononnnncnnnocononnnnccononncnonnoncccon ce nconcn no rocano coronan 11 25 11 04 PAGE 2 LIN T1 6 DC A 1 0 I INTRODU
2. ajouter les fonctionnalit s pr vues dans l analyse pour la gestion des membres e Analyser et ventuellement concevoir et r aliser la partie Gestion des s minaires e Tester e R utiliser Quelques pistes d tude pour valider l architecture et les choix techniques e Autre choix de BD de syst me IHM e Tests d architecture 3 tiers IV 2 T ches D composer les objectifs en t ches selon la nomenclature des activit s indiqu es dans le rapport LIN T1 5 NT A 1 0 Estimer les charges et les incidences entre t ches D tailler les produits du d veloppement documentations codes IV 3 R les Nommer les participants leur cursus et leurs connaissances Donner les r les des participants au projet D pend de l quipe de projet IV 4 Planification Planifier les t ches en fonction des r les et du temps Planifier les risques et leur r cup ration 25 11 04 PAGE 10 LIN T1 6 DC A 1 0 Jalons obligatoires V GLOSSAIRE ET ABBR VIATIONS Cette partie est incomplete BD Base de donn es IHM Interface homme machine Mod le d interface graphique de l application SGBD Syst me de Gestion de Bases de Donn es UC Use Case cas d utilisation UML UML Unified Modeling Language VI BIBLIOGRAPHIE ET DOCUMENTATION AV 01 Conception des syst mes d information Panorama des m thodes et des techniques Pascal Andr et Alain Vailly Editions ellipses 2001 ISBN 2 7298 0479 X AV 03
3. interface 25 11 04 PAGE 6 LIN T1 6 DC A 1 0 graphique actuelle permet de r aliser des tests mais ne correspond pas aux interface s graphique s n cessaire s aux utilisateurs Le test fonctionnel doit en principe s appuyer sur la description des cas d utilisation et les sc narios test bo te noire on peut l affiner en contr lant les diagrammes de s quence Le contr le du code se fait par des lectures ILS Gestion de projet Les aspects gestion de projet recouvrent des l ments relatifs e L organisation et la planification les tudiants se sont organis s en deux groupes selon l architecture logicielle base de donn e et application Java e Les normes les tudiants suivent la norme de documentation du projet LIN T1 5 NT A 1 0 et une codification du nommage des variables p 8 IUP T7 NT B 3 0 e La formation au moins un tudiant n tait pas form UML e Le suivi des r unions hebdomadaires ont permis de recentrer le projet et prendre les d cisions n cessaires Le d part du chef de projet a p nalis le d roulement du projet p 18 IUP T7 NT B 3 0 Les objectifs du premier incr ment n ont pas t atteints III CRITIQUES Dans cette partie l objectif est de mettre en vidence des lacunes des erreurs ou simplement des points faibles du premier incr ment Plusieurs approches sont possibles on reprend la structure de l analyse de l existant point par poi
4. La couverture fonctionnelle insuffisante et surtout pas assez mise en vidence un tableau r capitulant ce qui est pr vu ce qui est fait serait appr ci 111 4 2 Interfaces graphiques Les interfaces sont rudimentaires peu agr ables et peu ergonomiques on doit deviner a quoi les boutons correspondent et dans quel ordre on doit proc der Par exemple les recherches ne sont pas intuitives les r percussions des suppressions ne sont pr cis es les attributs fournir pour les requ tes sont deviner On pr f re une interface avec une barre de menus et diff rents modes d aide On peut s inspirer des applications courantes sous Linux ou Windows Ce point nous semble revoir 1 4 3 M thode et codage Comme dans la plupart des projets la mise en uvre et surtout sa documentation les derni res tapes du d veloppement sont loin d tre finalis s Les principaux reproches sont les suivants e Documentation insuffisante malgr un manuel utilisateur et un manuel de r f rence Il faut tester soi m me te lire le code pour comprendre e Hormis une norme de nommage des variables pas toujours appliqu e aucune r gle de programmation n est mise en vidence e Peu de commentaires dans le code et pas toujours pertinents IILS Qualit v rification validation et tests Comme pour toute application il est important de penser la qualit des sp cifications et du logiciel produit AV 01 En particulier la va
5. hender variables inutilis es champs de la BD inexploit s Les modules ne semblent pas con us en vue d une r utilisation IIL6 Documentation La documentation est in gale Notons que le rapport de projet IUP est un condens de la documentation normale du projet dossier de conception notes techniques compte rendu des r unions Tout cela ne nous tait pas fourni 25 11 04 PAGE 9 LIN T1 6 DC A 1 0 La pr sentation des documents devrait tre normalis e selon le mod le d crit dans le document LIN T1 5 NT A 0 1 Le code est assez peu document et sa documentation n est pas normalis e Les modules ne semblent pas con us en vu d une r utilisation IV MISE EN PLACE DU SECOND INCR MENT IV 1 Objectifs L objectif principal du second incr ment est de valider l architecture logicielle Cela sous entend plusieurs aspects affiner et valider e Articulation entre l application Java et la base de donn es mettre au point les m canismes de communication choisir au besoin un nouveau SGBD un environnement de d veloppement adapt e Mise au point des interfaces pr sentation biblioth ques de classes Java ergonomie e Compl ter la prise en compte des besoins et tudiant la bonne int gration des nouveaux l ments l application existante r utilisabilit et incr mentalit D autres objectifs sont affich s e Maintenir le code du premier incr ment corriger les erreurs
6. CTION Dans le cadre du d veloppement du second incr ment pour le projet ARGOSI document LIN T1 1 DC A 1 1 il est pr vu la remise d un dossier pr liminaire du second incr ment dont le plan nous a t remis en s ance de TP Ce dossier fait la liaison entre les deux incr ments c est dire qu il synth tise le travail r alis dans le premier incr ment et pr pare le travail du second incr ment La synthese se traduit par une analyse section II des produits mis notre disposition dossier d analyse LIN T2 5 SP A 1 0 rapport de projet des tudiants d IUP Miage 3 IUP T7 NT B 3 0 code des tudiants Cette analyse de l existant nous conduit une critique de l existant section III qui met en vidence les points forts et les points faibles du d veloppement du premier incr ment Enfin la section II d crit la pr paration du second incr ment qui se con oit en quatre parties objectifs principaux d coupage en t ches r les des participants planification r partition des t ches sur les r les et dans le temps Ce document est clairement un contrat pour la gestion de ce projet IT ANALYSE DE L EXISTANT Le projet ARGOSI dans son ensemble consiste en la mise en place d un syst me d information automatis relatif la gestion de l association administration et de ses activit s s minaires et p les L existant de ce projet est le r sultat les produits du premier incr ment savoir un
7. Exercices corrig s en UML Passeport pour une ma trise de la notation Pascal Andr et Alain Vailly Editions ellipses 2003 ISBN 2 7298 1725 5 RUP 99 The Unified Software Development Process James Rumbaugh et al Addison Wesley 1999 ISBN 0 201 57169 2 CLO 99 RUP XP Architectures et outils de Pierre Yves Cloux Dunod 2003 ISBN 2 100 06430 4 RV 03 UML en action de Pascal Roques et Franck Vall e dition 2003 ISBN 2 212 11213 0 Documentation ARGOSI 25 11 04 Eyrolles 2 LIN T1 1 DC A 1 1 Pr sentation du projet IUP Miage 3 GIN TIJS ENT SA 140 Normes de pr sentation des documents LIN T2 5 SP A 1 0 Analyse du cas ARGOSI LIN T1 4 NT A 1 0 Synth se de cours UML TUP T7 NT B 3 0 Rapport de projet IUP Miage 3 2003 2004 LIN T1 6 DC A 1 0 Dossier pr liminaire du second incr ment LIN T1 4 DD A 0 2 Plan du dossier de conception PAGE 11
8. Projet ARGOSI Dossier pr liminaire du second incr ment Version 1 0 Ident_Doc LIN T1 6 DC A 1 0 Pr par par Pascal Andr LINA 2 rue de la Houssini re BP 92208 44322 NANTES cedex 3 France Tel 33 02 51 12 59 65 Fax 33 02 51 12 58 12 email Pascal Andre Quniv nantes fr http www sciences univ nantes fr info perso permanents andre R sum Ce document est le dossier pr liminaire de conception du second incr ment du projet ARGOSI II r sume le premier incr ment analyse et critique r alis par un groupe d tudiants en projet et pr sente la planification du second incr ment c est dire les objectifs t ches r les estimations et r partitions des travaux ainsi qu un planning initial de notre travail Date de cr ation 16 10 2004 Date de derni re r vision 25 11 2004 Documents r f renc s LIN T1 1 DC A 1 1 LIN T1 5 NT A 1 0 LIN T1 1 DC A 0 1 LIN T2 5 SP A 1 0 LIN T1 6 DC A 1 0 E INTRODUCTION cnor a EONS encens tn een oca 3 IL ANALYSE DEL EXISTANT o ssnssisncestetinssesdiseceessessnsscsseidnsenee seen cssocnnssee eue dedans encens ei saiveteese esse ete te 3 11 1 ANALYSE DES BESOINS ET ANALYSE ooocoooonnnncnnononnannnnnnnconcnnonnnnnnnnononnennnnnnncononnnnnnnnnnononnenonnnnanonononannnnnnanos 3 IL2 A AS 4 H21 E AS eaii ar en aise ere eai EEEE EEE EEE E E A E EEA A E tee 4 2 2 COPIER ISPIUUES iio 4
9. T B 3 0 Application Java Nous impl mentons les classes principales Membre R union FonctionCA et les classes d ensembles respectives Ens FonctionCA Ens Membre et Ens Reunion En revanche pour la classe d mission nous ne jugeons pas utile de constituer une classe mais nous ajoutons un champ d mission pour l attribut tat de type num r EnumM Nous ajoutons des classes permettant la gestion de l interface comme les classes Frm_oper Frm_table et Frm_Main Base de donn es Nous reprenons galement le diagramme des classes pour constituer la base de donn es Oracle Les classes se transforment principalement en des tables membre fonctionCA r union Nous ressentons alors le besoin d en ajouter d autres Pour les types num r s EnumC EnumD EnumF EnumM EnumR de nouvelles tables sont ainsi constitu es avec une cl primaire se rapportant au champ num r Une autre table convocation est aussi cr e de fa on r aliser la convocation d un membre une r union En fait peu de d tails sont fournis Une description succincte des interfaces est donn e sous forme de copie d crans et de commentaires p 12 IUP T7 NT B 3 0 L interface est rudimentaire le menu principal est donn dans une fen tre individuelle et comprend la gestion des membres des fonctions et des r unions Ces trois parties ont des interfaces similaires affichage ajout modification suppression effacement et recher
10. architecture et des choix techniques Les contraintes techniques pr voient l usage de la BD non pas comme une partie de l application mais un support la persistance De ce fait l application n est pas simplement une interface d acc s la BD mais un programme autonome qui doit pouvoir fonctionner sans BD avec un syst me de sauvegarde diff rent Compte tenu de cette remarque deux choix de conception sont discuter 25 11 04 PAGE 7 LIN T1 6 DC A 1 0 e Liaison application et BD Dans la conception il a t choisi un chargement complet plut t qu un chargement la demande car plus facile implanter dans un premier temps Nous pensons qu il serait plus int ressant de mettre en uvre une politique de chargement la demande sous forme de transactions BD e Choix du SGBD Le SGBD Oracle a t choisi parce que les tudiants le connaissaient et en disposait pour le projet parce qu il permet de d velopper l application sur Linux ou Windows en Java Il n est pas crucial de b n ficier de traitements pointus sur la BD hormis la persistance c est pourquoi la plupart des SGBD conviennent qu ils soient relationnels ou pas En l absence de contraintes pr cises ce sujet il nous semble important de b n ficier d une offre BD multi plateforme Unix Windows ce qui limine l offre propri taire Access de Microsoft On privil giera un SGBD gratuit pour Pinstant Un point important est la co
11. che plus ou moins volu e soit des fonctions de navigation dans des listes des ensembles ici 112 7 Apports m thodologiques Les tudiants ont travaill sur deux points 11 3 La traduction de UML Java annexe 1 a IUP T7 NT B 3 0 La traduction de UML un SGBD relationnel annexe 1 b IUP T7 NT B 3 0 R alisation et test La r alisation appel e impl mentation reprend la partie de la conception en fait de l analyse relative la gestion des membres La r alisation pr voit p 15 IUP T7 NT B 3 0 25 11 04 PAGE 5 LIN T1 6 DC A 1 0 e La Gestion des Membres Dans cette partie de l application nous pouvons retrouver un membre de l association partir d une recherche sur le nom de l entreprise Plusieurs membres peuvent travailler dans la m me entreprise L acc s ceux ci se fera par les boutons suivant et pr c dent L ajout la modification et la suppression de membres sont possibles Pour certain d entre eux des fonctions leur sont attribu es e La Gestion des Fonctions du Bureau Au cours de sa vie dans l association un membre peut occuper plusieurs fonctions dans le bureau pr sident secr taire tr sorier La gestion du bureau incorpore des possibilit s d acc s aux membres assurant une fonction une date donn e et permet galement de retrouver la r union au cours de laquelle la fonction a t attribu e L ajout et la modification de fonctions sont pos
12. es tudiants d IUP Miage 3 IUP T7 NT B 3 0 Puisqu il ne s agit pas d un rapport technique il ne se focalise pas uniquement sur la conception et la r alisation mais inclut des l ments de gestion de projet de documentation et d appr ciation personnelle Nous devons donc commencer par extraire l information pertinente Nous la structurons dans les sous sections suivantes 11 2 1 Architecture du logiciel Le logiciel comprend principalement une application Java et une base de donn es relationnelle pour les objets persistants Il s agit donc d une architecture client serveur simplifi e 11 2 2 Contraintes techniques Le cahier des charges implique l usage du langage de programmation Java pour d velopper l application Cela permet de rester dans le monde objet entre l analyse et la r alisation La conception pr liminaire pr voyant un stockage des objets persistants dans une base de donn es il a t choisi le SGBD Oracle pour des consid rations pratiques li es l usage du syst me d exploitation Linux p 7 IUP T7 NT B 3 0 11 2 3 Outils de d veloppement Outre le SGBD Oracle les tudiants ont opt pour EDI Environnement de d veloppement int gr Eclipse p 7 IUP T7 NT B 3 0 11 2 4 Limites de la conception La conception reprend la partie de l analyse relative la gestion des membres La conception pr voit p 7 IUP T7 NT B 3 0 25 11 04 PAGE 4 LIN T1 6 DC A 1 0 1 La gestion d
13. es adh rents Il s agit ici d enregistrer de nouveaux adh rents de modifier leurs caract ristiques comme leur adresse par exemple de radier des adh rents de d finir le bureau ou de d mettre un membre de ce bureau d diter des listes de membres 2 La gestion des assembl es g n rales Il s agit de g rer les convocations des membres l assembl e g n rale et g rer les lections du bureau Il nous faut programmer une assembl e G n rale AG convoquer une AG et organiser le syst me de vote 3 La gestion des r unions La gestion des r unions consiste en la programmation de celles ci en la convocation des membres celles ci en la composition du bureau en la demande de d mission de membres du bureau et en l dition de la liste des membres du bureau 112 5 Principes de conception Les principes de conception sont relatifs l implantation de toutes les classes en Java et des classes m tier dans une base de donn es Il y a donc une repr sentation double pour les classes m tier Le chargement peut se faire la demande ou globalement La seconde option a t choisie car elle est plus simple mettre en uvre p 12 IUP T7 NT B 3 0 La communication entre l application et la BD se font via JDBC 112 6 D tails de la conception La conception appel e analyse conceptuelle reprend la partie de l analyse relative la gestion des membres La conception pr voit p 11 IUP T7 N
14. h rence entre les classes m tiers de l application et leur repr sentation dans la BD classes tables types domaines contraintes Pour l instant les deux sont implant s s par ment cf les m thodes de traduction de UML Java annexe 1 a IUP T7 NT B 3 0 et de UML aux relations annexe 1 b IUP T7 NT B 3 0 La v rification de coh rence est manuelle lors des s ances de mise en correspondance entre les deux parties de l application On pourra affiner les m thodes d implantation mais surtout tablir un protocole automatis si possible pour v rifier la conformit On note par exemple des probl mes de contraintes DELETE CASCADE dans les tables Pour l instant une architecture 2 3 a t con ue et implant e Il n a pas t discut d une architecture en 3 tiers type web envisageable pour une association dont les membres sont distants Il s agit l d un objectif de l application discuter avec le client Argosi Les tudiants ne donnent pas de r f rences pour les outils utilis s et les versions dans leur rapport Le choix d clipse peut se r v ler int ressant puisqu un module UML peut y tre ajout Il nous semble important de mettre en vidence des outils pour la g n ration de documentation 111 3 Analyse et conception L analyse pr sente assez clairement la situation et nous semble une bonne introduction au projet ARGOSI Un des int r ts se situe dans les commentaires sur la
15. lidit la robustesse la facilit d utilisation pour l utilisation et les qualit s suivantes pour les d veloppeurs l extensibilit la r utilisabilit et la portabilit Concernant la facilit d utilisation nous avons d j critiqu les IHM Pour la validit et la robustesse on fait appel la v rification et au test La v rification n a pas t abord e elle concerne l tude des propri t s des produits mod le d analyse de conception programme et du processus coh rence entre les tapes quel lien entre l analyse et la conception la conception et l implantation etc En particulier les fen tres des interfaces ne refl tent pas les sc narios de l analyse des besoins ou de l analyse Il n est pas fait mention d une validation des utilisateurs Le rapport ne fait pas mention d un test organis e Pas de plan de test e Pas de pr cisions sur le traitement des erreurs exception messages Pas de r gle adopt e Concernant les principales qualit s pour le d veloppement la portabilit est induite par l usage de java et d un SGBD multi plateformes L extensibilit induite par le d veloppement objet est mesurer lors du d veloppement du second incr ment elle est li e la documentation du code et aux crit res de groupement modulaires dans les classes de l interface et du contr le Nous n avons aucune garantie sur l usage du code ni d aide pour l appr
16. m thode de travail Son principal d faut est la compl tude Tous les cas d utilisation des parties s lectionn es ne sont pas d crits de m me que tous les sc narios des UC choisies Il faut donc compl ter cette description fonctionnelle et la poursuivre dans l analyse et la conception La conception est quasi inexistante et semble se r sumer la r alisation Il nous semble important de mettre en vidence cette tape cl qui met en correspondance l architecture technique li e aux choix techniques et l architecture logique issue de l analyse et surtout de mettre clairement en vidence les choix de conception leur argumentation pour qu on puisse ensuite les contr ler et les valider Cette remarque vaut tant pour le SGBD et son interface que pour l IHM D un point de vue fonctionnel il manque la gestion des situations depuis l analyse l historique des fonctions les lections etc 111 4 Programmation de l application Le choix du langage Java est impos libert est donn e pour l environnement de d veloppement voir choix techniques et les biblioth ques de classes La r alisation est l image de la conception inachev e De nombreuses lacunes sont d plorer relatives e la couverture fonctionnelle e les interfaces graphiques e la m thode et la documentation du codage D taillons ces diff rents points 111 4 1 Couverture fonctionnelle 25 11 04 PAGE 8 LIN T1 6 DC A 1 0
17. n des cas d utilisations qui permet de fixer les informations principales manipul es La description est pr cis e par les contraintes OCL 25 11 04 PAGE 3 LIN T1 6 DC A 1 0 ARGOSI Administration S minaires Gestion des embres__ Gestion des situations Analyse des besoins P les Figure 1 Cadrage de lanalyse des besoins et de l analyse du cas Argosi L analyse reprend une partie des cas d utilisation et des sc narios sous forme de s quences et de collaborations qui mettent en vidence la structure logique du syst me en faisant appara tre de nouveaux objets li s l interface ou au contr le de l application et en affinant les objets m tiers du mod le du domaine Compte tenu du type d application il a t choisi une sp cialisation des objets en trois cat gories interface contr le m tier p 20 LIN T2 5 SP A 1 0 Il en r sulte un nouveau mod le des objets m tiers support de la base de donn es En r sum une description volontairement incompl te mais qui fixe les id es II 2 Conception La conception pr liminaire est abord e superficiellement dans le document LIN T2 5 SP A 1 0 Elle indique simplement que l application est structur e en une base de donn e et une ou plusieurs applications relatives la partie Administration Les principes de conception sont tudi s plus finement dans le rapport de projet d
18. nt ou bien on recadre en fonction des objectifs g n raux du second incr ment ou alors on tablit mixage des deux approches ou encore on d finit une structure ad hoc On choisit cette derni re approche On ne traite pas ici de la gestion de projet consid rant qu il s agit d un autre d veloppement avec une autre quipe IIL1 Couverture des besoins fonctionnels Le passage de l analyse des besoins la r alisation d un prototype a t une succession de r ductions s v res de l espace de travail En effet seuls les gestions des membres des fonctions et des r unions sont abord es qui plus est partiellement Les fonctions rudimentaires d ajout modification suppression et recherche ont t implant es Les listes ne sont pas implant es Les liens entre ces diff rentes gestions sont implant s En r sum le premier incr ment n atteint pas notre avis une couverture suffisante pour bien valuer l architecture et l environnement technique Bien s r s agissant d un premier incr ment il est indiqu clairement dans l analyse la limitation volontaire des besoins fonctionnels Cependant la conception et la r alisation qui la refl te un peu trop est ce une r tro conception marquent plus une restriction due un manque de temps une cons quence due aux difficult s de mise en uvre qu un choix de conception Cela n est pas mis en vidence dans le rapport II 2 Validation de l
19. premier document LIN T2 5 SP A 1 0 contenant l analyse des besoins l analyse et la conception pr liminaire un second document IUP T7 NT B 3 0 contenant des l ments relatifs la conception et la r alisation et enfin un code Java II 1 Analyse des besoins et analyse L analyse du cas ARGOSI document LIN T2 5 SP A 1 0 comprend une analyse des besoins une analyse et quelques l ments de la conception L ensemble est document l aide de la notation UML L analyse des besoins met en vidence les besoins fonctionnels de l application clairement s par s en trois parties administration s minaires et p les Cette analyse des besoins est volontairement incompl te le premier incr ment de l analyse ne vise qu une des trois parties principales la partie Administration et plus particuli rement la gestion des membres puisque la gestion des situations est ignor e section Il p 15 LIN T2 5 SP A 1 0 Dans la Figure 1 nous avons mis en vidence par partie analys e vis vis de l ensemble de l application Les intersections montrent que les parties ne sont pas compl tement ind pendantes L analyse des besoins affine la sp cification fonctionnelle de la gestion des membres par diff rents cas d utilisation illustr s par des sc narios Ici aussi la description est incompl te tous les cas d utilisation et tous les sc narios ne sont pas explor s Un mod le du domaine compl te la descriptio
20. sibles e La Gestion des R unions La recherche d une r union se fait par la date On pourra observer toutes les r unions qui ont lieu le m me jour les membres qui sont convoqu s et ajouter des convocations si n cessaire L ajout et la modification de r unions sont possibles L articulation de l application est la suivante Main Chargement de la base de donn es en m moire Chargement interface graphique gestion des membres gestion des fonctions estion des r unions 8 Appel aux classes ensembles Visualisation des interfaces graphiques Appel des m thodes des classes ensembles charg es en m moire suite un v nement ajout suppression modification convocation Il n est pas fait mention de test organis II 4 Test et contr le du code de l application Un manuel d utilisation est fourni annexe 2 IUP T7 NT B 3 0 Pour fonctionner compilation r ussie il faut que la connexion la base de donn e soit tablie Autrement dit il faut la cr er manuellement sous Oracle Un manuel de programmation est fourni annexe 3 IUP T7 NT B 3 0 qui inventorie diff rentes fonctions non implant es Les dates sont actuellement sous forme de String et aucun contr le sur leur coh rence n est r alis La gestion des AG et des membres candidats n est pas r alis e La gestion des votes n est pas r alis e La gestion des demandes de d mission n est pas r alis e L

Projet ARGOSI

Contents

Download Pdf Manuals

Related Search

Related Contents