2tup

Universit Abou Bekr Belkaid de Tlemcen
Facult des Sciences de lIngnieur Dpartement dInformatique
Suivie des enseignements du LMD par application de la mthode 2TUP

Projet de Fin dEtudes pour lobtention du Diplme dIngnieur dEtat en Informatique
Option : informatique industrielle
Kazi Aouel Bassim et Rostane Zakaria

Encadrs par Mr. Ziani Cherif Salim Prsent le 08 novembre 2007 devant le jury :
Mr. ABDERRAHIM Amine Mr. CHIKH Azzeddine Mr. CHOUITI S-Mohammed
Je ddie ce mmoire mon pre et ma mre pour leur soutien tout au long de mes tudes Un coucou Selma et Sofiane mon grand pre Ba tous mes oncles, tantes, cousins et cousines : nabil, djamil, zakia, dounia, nayla, amel et salim, malik, lamia, arselane, chakib, farid, karim, lina, rachida, mustafa, malik 2, ines, salim, linda A tout mes amis et amies et tous ceux qui mont encourag A la mmoire de mes oncles Lotfi et Amine, que leurs mes reposent en paix Bassim
Je ddie ce mmoire A ma chre mre pour son soutien tout au long de mes tudes A mes surs et frres : nadjia, mohamed, toufik, choumicha, chahrazed ainsi qu mes belles surs et beaux frres : amine, hicham, khalil, sihem, lela sans oublier mes nices et mes neveux : chahinez, wafaa, farah, walid, sarah, ryadh, marouane et mouhcine A tous mes amis et toute mes amies et tous ceux qui mont encourag Zaki
Page 2
Remerciements
On remercie Monsieur Ziani Cherif Salim pour laide quil nous a apport Aussi, on remercie Hakim (Kimz) pour laide quil nous a apport afin de rendre notre rapport meilleur, et Zakia et Nadia pour le temps quils ont pass corriger le mmoire
Page 3
Rsum :
Nous proposons dans le cadre de ce projet de fin dtudes, dappliquer la mthode 2TUP au problme de la gestion des enseignements LMD luniversit de Tlemcen. La gestion dun cycle de vie de logiciel requit un grand sens de la rigueur et de ladaptation aux changements continuels imposs au monde de lentreprise. Cest pour a que nous avons choisi daxer notre travail sur une mthode de dveloppement qui est ne de travaux pousss vers la standardisation et la flexibilit, et ce pour rpondre aux contraintes actuelles de gestion des dveloppements. Le mmoire sera dcoup en 5 grands chapitres : 1. Introduction : nous parlerons dans ce chapitre des objectifs que nous voudrions atteindre, ainsi quun aperu des diffrentes mthodes existantes. 2. La mthode 2TUP : ce chapitre contient les dfinitions des diffrents concepts utiliss dans ce document. 3. Conception du logiciel : cest ici que nous allons appliquer la mthode 2TUP au problme de la gestion des enseignements en suivant les phases suivantes : ltude prliminaire, capture des besoins fonctionnels, analyse, conception et codage. 4. Bilan de la mthode 2TUP : nous allons donner un bref aperu de ce que pourrait tre un ajout dun nouveau besoin fonctionnel. 5. Conclusion gnrale
Page 4
TABLE DES MATIERES

TABLE DES MATIERES ............................................................................................................................................. 5 INTRODUCTION ...................................................................................................................................................... 7 1. 2. 3. 4. LE CONTEXTE DE TRAVAIL.................................................................................................................................. 7 OBJECTIFS ........................................................................................................................................................ 7 COMPARAISON ENTRES LES DIFFERENTES APPROCHES ............................................................................................. 8 PRESENTATION DE LAPPLICATION A RALISER .................................................................................................... 9
LA METHODE 2TUP............................................................................................................................................... 10 1. 2. 3. 4. DEFINITION DUN PROCESSUS DE DEVELOPPEMENT LOGICIEL .............................................................................. 11 LE PROCESSUS UNIFI ...................................................................................................................................... 11 LE PROCESSUS 2TUP ......................................................................................................................................... 12 UN PROCESSUS DE MODELISATION AVEC UML ...................................................................................................... 14
CONCEPTION DU LOGICIEL ................................................................................................................................... 16 1. ETUDE PRLIMINAIRE ................................................................................................................................... 16 1.1. Prsentation du projet raliser ............................................................................................................ 16 1.2. Recueil des besoins fonctionnels ............................................................................................................ 16 1.3. Choix techniques..................................................................................................................................... 18 1.4. Identification des acteurs ....................................................................................................................... 19 1.5. Identification des messages ................................................................................................................... 20 1.6. Modlisation du contexte ....................................................................................................................... 21 CAPTURE DES BESOINS FONCTIONNELS ........................................................................................................... 22 2.1. Dterminer les cas dutilisations............................................................................................................. 22 2.2. Description prliminaire des cas dutilisations ....................................................................................... 25 2.3. Description dtaille des cas dutilisations ............................................................................................. 26 2.4. Structuration des cas dutilisations dans des packages ......................................................................... 43 2.5. Identification des classes candidates ..................................................................................................... 44 ANALYSE ........................................................................................................................................................ 50 3.1. Dcoupage en catgories ....................................................................................................................... 50 3.2. Dpendances entre catgories ............................................................................................................... 51 3.3. Diagramme de packages danalyse ........................................................................................................ 54 3.4. Dveloppement du modle statique ...................................................................................................... 55 3.5. Dveloppement du modle dynamique .................................................................................................. 62 CONCEPTION ................................................................................................................................................. 79 4.1. Architecture de lapplication .................................................................................................................. 79 4.2. Les Design Patterns ................................................................................................................................ 80 CODAGE .......................................................................................................................................................... 89 5.1. La gnration de code avec NetBeans 5.5: ............................................................................................ 89 5.2. Lapplication JStudent ....................................................................................................................... 89
2.
3.
4.
5.
BILAN DE LA METHODE .......................................................................................................................................100 CONCLUSION GENERALE .....................................................................................................................................103
Page 5
BIBLIOGRAPHIE ...................................................................................................................................................104 ANNEXE : .............................................................................................................................................................105 LAPPROCHE ORIENTEE OBJET ............................................................................................................................... 105 UML ....................................................................................................................................................................... 106 LE LANGAGE JAVA .................................................................................................................................................... 108 DIFFERENCE ENTRE LARCHITECTURE 3-TIERS ET LE MODELE MVC ........................................................................... 109
Page 6
Introduction
1. LE CONTEXTE DE TRAVAIL
La complexit croissante des systmes informatiques a conduit les concepteurs

sintresser aux mthodes de dveloppement. Ces dernires ont toujours essay dapporter un contrle continu sur un projet tout au long de son processus de vie. Bien que des mthodes de dveloppement existent depuis 30 ans (Merise, SADT), nous ne pouvons constater aujourdhui lexistence dune rgle qui soit la fois formelle et commune aux diffrentes cultures. Par ailleurs, des mthodes squentielles comme celles se basant sur le cycle en V, ont montr leur limite dans un environnement rgi par des changements rguliers, impliquant une impossibilit revenir en arrire, et de ce fait, laissant une trs petite marge lerreur. Avec lavnement de la pense objet, de nouvelles mthodes sont apparues et diffrentes notations ont t tablies. UML a ouvert le terrain de lunification en fusionnant ces notations et en apportant prcision et rigueur la dfinition des concepts introduits. Sur cet lan, les spcialistes ont aussi pens unifier non pas les processus, mais plus exactement les meilleures pratiques de dveloppement orient objet.
2. OBJECTIFS
Notre but est dappliquer une mthode rigoureuse de conduite dun projet rel. Le
projet en question concerne la gestion des enseignements. Ce projet a pour objectif principal de proposer une solution un problme concret, et ceci en partant dune dfinition des besoins. Nous esprons travers celui-ci, dmontrer limportance de lapplication dune mthodologie de dveloppement, et aussi permettre par la suite que ce produit puisse tre volutif et facilement maintenable par des intervenants tiers.
Page 7
3. COMPARAISON ENTRES LES DIFFERENTES APPROCHES

Modlisation
Par le pass, le modle Entit-Relation reprsentait une grande partie des approches les plus utilises. Actuellement, les nouvelles technologies sappuient sur le modle objet. En termes danalyse et de modlisation objet, UML est devenu un standard incontournable, stabilis, industriel.
Conduite de projet
Au dbut, le cycle en cascade (ex : le cycle en V) tait trs utilis. Mais on a vite constat son incapacit sadapter aux diffrents changements. Une mthode semi-itrative est apparut (RAD) pour pallier aux carences de ce dernier. Litratif sest ensuite impos, parce quil rduit la complexit de ralisation des phases, en travaillant par approches successives et incrmentales. Une mthode fortement axe sur litratif et le modle UML est alors apparut, il sagit de UP (Unified Process). Cette mthode comme son nom lindique, a t le fruit de travail de plusieurs personnes voulants unifier les diffrentes mthodes objets existantes ce moment comme Booch, OMT et OOSE. On constate aujourdhui, lmergence dune nouvelle approche : les mthodes agiles (Agile Modeling). Cest des mthodes itratives planification souple qui leur permettent de sadapter la fois aux changements du contexte et de spcifications du projet. (Chromatic, 2005)
Page 8
4. PRESENTATION DE LAPPLICATION A RALISER
De nos jours, une des tendances les plus en vue et qui concerne tout les secteurs
de dveloppement, est linformatisation. Depuis lapparition de linformatique et son introduction dans le monde conomique, les entreprises et entits publiques aspirent optimiser et rendre fiable la gestion de leur structure interne. Luniversit de Tlemcen possde quelques milliers dtudiants quil est difficile de grer en continu. Avec la mise en place rcente du systme LMD, la situation sest davantage complique et la tche de gestion est devenue plus complexe. Le projet que nous proposons nous permettra de faciliter la gestion des enseignements, travers la conception dun logiciel avec une mthode que nous allons prsenter.
Page 9
La mthode 2TUP
Devant le nombre de mthodes disponibles, le choix parmi elles devient difficile,
beaucoup de questions peuvent se poser un chef de projet lors dun dmarrage de projet : Comment vais-je organiser les quipes de dveloppement ; Quelles tches attribuer qui ; Quel temps faudrait-il pour livrer le produit ; Comment faire participer le client au dveloppement afin de capter les besoins de celui-ci ; Comment viter des drives et de mauvaises estimations qui vont allonger les cots et le temps de dveloppement. Comment vais-je procder pour que le produit soit volutif et facilement maintenable. Nous pouvons citer ce propos les mthodes de dveloppement objet suivantes : 2TUP, RUP, XP, AUP et OpenUP. Notre choix sest port vers la mthode 2TUP, du fait de son approche nouvelle, originale. Notre projet est bas sur un processus de dveloppement bien dfini qui va de la dtermination des besoins fonctionnels attendus du systme jusqu la conception et le codage final. Ce processus se base lui-mme sur le Processus Unifi (Unified Process) qui est devenu un standard gnral runissant les meilleures pratiques de dveloppement. Cette mthode ne se base aucunement sur un processus linaire mais bien, sur un dveloppement itratif et incrmental. Nous allons dabord dfinir les diffrents concepts qui vont tre utiliss dans ce document.
Page 10
1. DEFINITION DUN PROC ESSUS DE DEVELOPPEMENT LOGICIEL
Un processus dfinit une squence dtapes, en partie ordonnes, qui concourent

lobtention dun systme logiciel ou lvolution dun systme existant. Lobjet dun processus de dveloppement est de produire des logiciels de qualit qui rpondent aux besoins de leurs utilisateurs dans des temps et des cots prvisibles. (Rocques & Valle, 2004)
2. LE PROCESSUS UNIFI
Le Processus Unifi (PU ou UP en anglais pour Unified Process) est une mthode
de dveloppement logiciel construite sur UML ; elle est itrative et incrmentale, centre sur larchitecture, conduite par les cas dutilisation et pilote par les risques. itrative et incrmentale : la mthode est itrative dans le sens o elle propose de faire des itrations lors de ses diffrentes phases, ceci garantit que le modle construit chaque phase ou tape soit affin et amlior. Chaque itration peut servir aussi ajouter de nouveaux incrments. conduite par les cas dutilisation : elle est oriente utilisateur pour rpondre aux besoins de celui-ci. centre sur larchitecture : les modles dfinit tout au long du processus de dveloppement vont contribuer tablir une architecture cohrente et solide. pilote par les risques : en dfinissant des priorits pour chaque fonctionnalit, on peut minimiser les risques dchec du projet. La gestion dun tel processus est organise daprs les 4 phases suivantes : 1. Pretude(Inception) : cest ici quon value la valeur ajoute du dveloppement et la capacit technique le raliser (tude de faisabilit). 2. Elaboration : sert confirmer ladquation du systme aux besoins des utilisateurs et livrer larchitecture de base.
Page 11
3. Construction : sert livrer progressivement toutes les fonctions du systme. 4. Transition : dployer le systme sur des sites oprationnels. Chaque phase est elle-mme dcompose squentiellement en itrations limites dans le temps (entre 2 et 4 semaines). Le rsultat de chacune delles est un systme test, intgr et excutable. Lapproche itrative est fonde sur la croissance et l'affinement successifs dun systme par le biais ditrations multiples. Le systme crot avec le temps de faon incrmentale, itration par itration, et cest pourquoi cette mthode porte galement le nom de dveloppement itratif et incrmental. Il sagit l du principe le plus important du Processus Unifi.
Ces activits de dveloppement sont dfinies par 6 disciplines fondamentales qui dcrivent la capture des besoins, la modlisation mtier, lanalyse et la conception, limplmentation, le test et le dploiement. Notons que ces diffrentes tapes (ou disciplines) peuvent se drouler travers plusieurs phases. Le processus unifi doit donc tre compris comme une trame commune des meilleures pratiques de dveloppement.
3. LE PROCESSUS 2TUP
On dit de la mthode UP quelle est gnrique c..d. quelle dfinit un certain

nombre de critres de dveloppement, que chaque socit peut par la suite personnaliser afin de crer son propre processus plus adapt ses besoins. Cest dans ce cadre que la socit Valtech a cre la mthode 2TUP.
2TUP
signifie 2 Track Unified Process .Cest un processus qui rpond aux caractristiques du Processus Unifi. Le processus 2TUP apporte une rponse aux contraintes de changement continuel imposes aux systmes dinformation de lentreprise. En ce sens, il renforce le contrle sur les capacits dvolution et de correction de tels systmes. 2 Track signifie littralement que le processus suit deux chemins. Il sagit des chemins fonctionnels et darchitecture technique , qui correspondent aux deux axes de changement imposs au systme dinformation.
Page 12
Figure : Le systme dinformation soumis deux types de contraintes
La branche gauche (fonctionnelle) : capitalise la connaissance du mtier de lentreprise. Elle constitue gnralement un investissement pour le moyen et le long terme. Les fonctions du systme dinformation sont en effet indpendantes des technologies utilises. Cette branche comporte les tapes suivantes : La capture des besoins fonctionnels, qui produit un modle des besoins focalis sur le mtier des utilisateurs. Lanalyse.
La branche droite (architecture technique) : capitalise un savoir-faire technique. Elle constitue un investissement pour le court et moyen terme. Les techniques dveloppes pour le systme peuvent ltre en effet indpendamment des fonctions raliser. Cette branche comporte les tapes suivantes : La capture des besoins techniques. La conception gnrique. La branche du milieu : lissue des volutions du modle fonctionnel et de larchitecture technique, la ralisation du systme consiste fusionner les rsultats des 2 branches. Cette fusion conduit lobtention dun processus en forme de Y. Cette branche comporte les tapes suivantes : La conception prliminaire. La conception dtaille. Le codage. Lintgration.
Page 13
Figure : Le processus de dveloppement en Y
4. UN PROCESSUS DE MODELISATION AVEC UML
Le processus 2TUP sappuie sur UML tout au long du cycle de dveloppement,

car les diffrents diagrammes de ce dernier permettent de part leur facilit et clart, de bien modliser le systme chaque tape. Unified Modeling Language : UML se dfinit comme un langage de modlisation graphique et textuel destin comprendre et dcrire des besoins, spcifier, concevoir des solutions et communiquer des points de vue. (Pitman, 2006) UML unifie la fois les notations et les concepts orients objet.il ne sagit pas dune simple notation, mais les concepts transmis par un diagramme ont une smantique prcise et sont porteurs de sens au mme titre que les mots dun langage, cest pour a quUML est prsent parfois comme une mthode alors quil ne lest absolument pas.
Page 14
UML unifie galement les notations ncessaires aux diffrentes activits dun processus de dveloppement et offre, par ce biais, le moyen dtablir le suivi des dcisions prises, depuis la dfinition des besoins jusquau codage. (Roques, 2006) Voici une prsentation rapide des diffrents diagrammes UML qui vont tre utiliss tout au long du projet : Le diagramme des cas dutilisation : reprsente la structure des fonctionnalits ncessaires aux utilisateurs du systme. Il est normalement utilis lors des tapes de capture des besoins fonctionnels et techniques. Le diagramme dactivits : reprsente les rgles denchanement des activits et actions dans le systme. Il peut tre assimil comme un algorithme mais schmatis. Le diagramme de packages : prsent depuis UML 2.0, ce diagramme modlise des catgories cohrentes entre elles, pour un souci de partage des rles. Correspond ltape de modlisation des diffrents scnarios dun cas dutilisation. Le diagramme de classes : srement lun des diagrammes les plus importants dans un dveloppement orient objet. Sur la branche fonctionnelle, ce diagramme est prvu pour dvelopper la structure des entits manipules par les utilisateurs. En conception, le diagramme de classes reprsente la structure dun code orient objet. Le diagramme de squence : reprsente les changes de messages entre objets, dans le cadre dun fonctionnement particulier du systme. Le diagramme dtats : reprsente le cycle de vie dun objet. Il spcifie les tats possibles dune classe et leur enchainement. Ce diagramme est utilis lors des tapes danalyse et de conception.
Page 15
Conception du logiciel
1. ETUDE PRLIMINAIRE Ltude prliminaire (ou Pretude) est la toute premire tape du processus 2TUP. Elle consiste effectuer un premier reprage des besoins fonctionnels et oprationnels, en utilisant principalement le texte, ou diagrammes trs simples. Elle prpare les activits plus formelles de capture des besoins fonctionnels et de capture techniques.
1.1. Prsentation du projet raliser
Cest un logiciel qui doit grer le cursus universitaire des tudiants dans le systme LMD en gnral. Il doit permettre de suivre les tudiants depuis leur inscription luniversit jusqu lobtention du diplme de Licence.
1.2.
Recueil des besoins fonctionnels
Nous avons effectu plusieurs recherches pour identifier au mieux les besoins de lapplication, et ceci afin de rpondre aux attentes des utilisateurs. Nous sommes alls chercher les informations au sein de ladministration de la Facult. Cette phase correspond une recherche sur le terrain pour bien dfinir le cadre de notre systme. Nous nous sommes aussi procur quelques documents, qui expliquent le mode de fonctionnement du systme LMD, et a nous a permis dtablir le cahier des charges prliminaire suivant :
Page 16
Organisation des dpartements : _____________________________________________________________________
Une universit se compose de plusieurs dpartements (informatique, physique, maths, chimie ), dont chacun est dirig par un chef de dpartement. Chaque dpartement voit son parcours de formation structur en 3 paliers : Le premier palier doit tre compos au plus de 2 semestres. Le deuxime palier dau moins 2 semestres. Le troisime palier est une tape de spcialisation.
Organisation du parcours de formation dans le systme LMD: _____________________________________________________________________
La formation en vue de lobtention du diplme de licence est rpartie en 6 semestres, la diffrence dune formation classique. Les parcours sont organiss en units denseignements(UE) articules entre elles. Une UE est constitue dune ou de plusieurs matires dispenss par toute forme denseignements (Cours, Travaux Dirigs, Travaux Pratiques, projets). Chaque UE et chacune de ses matires constitutives sont affectes dune valeur en crdits. La valeur totale de ces crdits est fixe 30 par semestre. Une UE est considre comme acquise si la moyenne de lensemble des notes obtenues dans les matires qui la constituent, affectes de leurs coefficients respectifs, est gale ou suprieur 10. Pour chaque semestre denseignement, deux sessions de contrle sont organises.la deuxime session est une session de rattrapage. Le semestre est acquis pour tout tudiant ayant obtenu lensemble des UEs qui le composent. Le semestre peut tre galement acquis par compensation entres les diffrentes UEs. La moyenne gnrale est calcule sur la base des moyennes obtenues aux UEs composant le semestre pondres par leurs coefficients respectifs. Le semestre est alors acquis si cette moyenne est gale ou suprieure 10. En cas dchec la premire session, ltudiant se prsente aux examens de rattrapage pour les UEs non acquises. Ltudiant garde le bnfice des matires de lUE pour lesquelles il a obtenu une moyenne gale ou suprieure 10.
Progression : _____________________________________________________________________
La progression du premier au second semestre dune mme anne universitaire est de droit pour tout tudiant inscrit dans le mme parcours.
Page 17
La progression de la premire la deuxime anne de la Licence, est de droit si ltudiant a acquis les deux premiers semestres du cursus de formation. Cependant, elle peut tre autorise pour tout tudiant ayant acquis au moins 30 crdits. La progression de la deuxime la troisime anne est de droit si ltudiant a acquis les 4 premiers semestres du cursus de formation. Mais elle peut tre autorise si ltudiant a valid 80% des crdits relatifs aux 4 premiers semestres, et si ltudiant a valid aussi les units denseignements fondamentales. Lacquisition du diplme de Licence est effective si ltudiant a valid les 6 semestres du cursus de formation.
Gestion des promotions : _____________________________________________________________________
Pour chaque dpartement et chaque anne dtudes, une promotion doit tre cre. La promotion contient un certain nombre dtudiants encadrs par des enseignants.
Gestion des tudiants : _____________________________________________________________________
Un tudiant ds son inscription luniversit, peut tre affect une promotion selon la filire quil a choisie.
1.3.
Choix techniques
Voici les choix techniques qui ont t adopts pour le projet : La modlisation avec UML. Adoption dune architecture 3 couches. Utilisation du langage Java. Omission dune base de donnes au profit de la srialisation (Java). Utilisation des Design Patterns (MVC, Etat, Faade ). Utilisation de lEDI NetBeans et de son plugin UML.
Remarque : la branche droite qui dsigne ltude de larchitecture technique va tre ignore, du fait du manque de temps notre disposition et de la complexit de la chose.
Page 18
1.4.
Identification des acteurs
Nous allons maintenant numrer les acteurs susceptibles dinteragir avec le systme, mais dabord nous donnons une dfinition de ce que cest un acteur. Dfinition : un acteur reprsente l'abstraction d'un rle jou par des entits externes (utilisateur, dispositif matriel ou autre systme) qui interagissent directement avec le systme tudi. Les acteurs du systme identifis dans un premier temps sont :
Etudiant : Un tudiant peut consulter ses relevs de notes, son emploi du
temps.
Chef de dpartement : le chef de dpartement tablit le cursus de son
dpartement, il cre les promotions et suit leur volution. Il choisit les enseignants responsables des cours.
Scolarit : la scolarit introduit les notes des tudiants. Enseignant : lenseignant affecte les notes des tudiants de son module. Administrateur : cre les profils utilisateurs et attribue les droits daccs.
Page 19
1.5.
Identification des messages
On va dtailler les diffrents messages changs entre le systme et lextrieur. Dfinition : un message reprsente la spcification dune communication unidirectionnelle entre les objets qui transporte de linformation avec lintention de dclencher une activit chez le rcepteur.
Le systme met les messages suivants : Les relevs de notes des tudiants. Ltat davancement dune promotion. Le cursus dun tudiant. Les emplois du temps dune promotion. Les modules dun dpartement. Les fiches des tudiants. Les fiches des enseignants. Lorganisation dun dpartement. La liste des tudiants passs et recals la fin dun semestre. La liste des tudiants ayant acquis leur diplme.
Le systme reoit les messages suivants : Les crations, modifications, suppressions de fiches des tudiants/enseignants. Les crations, modifications, de promotions. Le lancement/bouclage dune promotion. Laffectation des tudiants/enseignants une promotion. Les ajouts, suppressions, modifications des filires pour un dpartement. Les crations, modifications, suppressions des emplois du temps dune promotion. Les crations, modifications, suppressions de profils utilisateurs. Les crations, modifications de spcialits pour un dpartement.
Page 20
1.6.
Modlisation du contexte
A partir des informations obtenues lors des deux prcdentes tapes, nous allons modliser le contexte de notre application. Ceci va nous permettre dans un premier temps, de dfinir le rle de chaque acteur dans le systme :
Utilisateurs finaux
Description des besoins fonctionnels Lapplication doit permettre au chef de dpartement de : Sauthentifier Crer son dpartement Crer une promotion Crer les spcialits/options Crer les UE et les Modules Suivre les promotions en cours Affecter les tudiants/enseignants une promotion Lapplication doit permettre la Scolarit de : Sauthentifier Crer/modifier les fiches des tudiants Affecter les notes des tudiants Lapplication doit permettre lenseignant de : Sauthentifier Affecter les notes des tudiants pour son module Lapplication doit permettre ltudiant de : Sauthentifier Consulter son relev de notes Consulter son emploi du temps Consulter ses modules en dettes Lapplication doit permettre ladministrateur de : Sauthentifier Crer les profils utilisateurs Donner des droits daccs
Chef de dpartement
Scolarit
Enseignant
Etudiant
Administrateur
Page 21
2. CAPTURE DES BESOINS FONCTIONNELS Cette phase reprsente un point de vue fonctionnel de larchitecture systme. Par
le biais des cas dutilisation, nous serons en contact permanent avec les acteurs du systme en vue de dfinir les limites de celui-ci, et ainsi viter de trop sloigner des besoins rels de lutilisateur final.
2.1.
Dterminer les cas dutilisations
Dfinition : un cas dutilisation reprsente un ensemble de squences dactions ralises par le systme et produisant un rsultat observable intressant pour un acteur particulier. Un cas dutilisation modlise un service rendu par le systme. Il exprime les interactions acteurs/systme et apporte une valeur ajoute notable lacteur concern.
Utilisation doutils de gnration de diagrammes UML :

Tout au long du projet, nous sommes passs par plusieurs outils qui gnrent les diagrammes UML. Nous allons faire une prsentation rapide de ceux l. ArgoUML 1: cest un outil gratuit crit avec Java, nous lavons utilis au dbut puis nous lavons dlaiss pour sa lourdeur et son interface peu intuitive. Bouml 2: srement loutil le plus lger sur le march, il est trs puissant et agrable utiliser, et en plus il est gratuit. NetBeansUML 3: cest un plugin intgr lEDI NetBeans, il est trs puissant avec de grandes possibilits de personnalisation, cependant il souffre dune lourdeur assez gnante si on na pas une machine puissante. Nous lavons utilis pour quelques Design Pattern et pour la gnration de code.
1 2
Peut tre tlcharg ladresse suivante : http://argouml.tigris.org/ Peut tre tlcharg ladresse suivante : http://bouml.free.fr/ 3 Le site de NetBeans : http://www.netbeans.org/
Page 22
Identification des cas dutilisation :

Lidentification des cas dutilisation une premire fois, nous donne un aperu des fonctionnalits futures que doit implmenter le systme. Cependant, il nous faut plusieurs itrations pour ainsi arriver constituer des cas dutilisation complets. Dautres cas dutilisation vont apparatre au fur mesure de la description de ceux l, et lavancement dans le recueil des besoins fonctionnels . Pour constituer les cas dutilisation, il faut considrer l'intention fonctionnelle de l'acteur par rapport au systme dans le cadre de l'mission ou de la rception de chaque message. En regroupant les intentions fonctionnelles en units cohrentes, on obtient les cas d'utilisations.
Messages mis/reus par les acteurs Cas dutilisation Acteur principal, acteurs secondaires
Emet : Crer son dpartement, Crer/modifier les spcialits/options, Crer les UE et les Modules.
Organiser un dpartement
Chef de dpartement
Grer les promotions
Chef de dpartement
Emet : Crer une promotion, Affecter les tudiants une promotion Emet : Commencer la promotion, slectionner les enseignants/semestre, commencer/terminer un semestre, passer au prochain semestre, orienter les tudiants vers les spcialits, Reoit : liste des tudiants endetts, Liste des tudiants non endetts. Emet : Crer/modifier les fiches des tudiants. Emet : Affecter les notes aux tudiants, grer les rattrapages, grer les modules en dettes. Reoit : relev de notes
Suivre les promotions
Chef de dpartement
Grer les tudiants
Scolarit
Maintenir les notes
Scolarit, Enseignant
Consulter les notes
Etudiant
Reoit : consulter son relev de notes.
Page 23
Grer les emplois du temps Consulter les emplois du temps Grer les profils
Scolarit Etudiant, Enseignant
Emet : Crer/modifier les emplois du temps Reoit : consulter les emplois du temps. Emet : Cration, modification, suppression de profils.
Administrateur
Remarque : Du fait quelle ne rentre pas dans le cadre de notre projet, la gestion des salles a t dlibrment omise. Remarque 2: Ce premier tableau n'est pas dfinitif, un processus de dveloppement avec UML est itratif, il se peut qu'il change au fur et mesure de l'avancement du projet.
Diagramme des cas dutilisation
Page 24
2.2.
Description prliminaire des cas dutilisations
Voici une description prliminaire des cas dutilisations numrs prcdemment : Organiser les dpartements :
Intention : grer les dpartements. Actions : crer un nouveau domaine, une nouvelle spcialit, une nouvelle
option, crer les UE, modifier les UE
Grer les promotions :

Intention : grer les promotions. Actions : crer une nouvelle promotion, affecter des tudiants, modifier ou
annuler la promotion.
Etablir les emplois du temps :

Intention : crer lemploi du temps pour une promotion. Actions : crer un nouvel emploi du temps, affecter une unit dheure un
module et un enseignant, modifier ou annuler lemploi du temps.
Grer les tudiants :

Intention : suivi des dossiers des tudiants aprs inscription de ces derniers. Actions : crer le dossier tudiant, rattacher ltudiant une anne
universitaire, mettre jour le dossier.
Grer les profils :

Intention : crer les diffrents profils des utilisateurs du systme. Actions : crer un nouveau profil, attribuer une fonction, attribuer des
droits daccs, modifier le profil, crer un mot de passe.
Maintenir les notes des tudiants :

Intention : affecter les notes aux tudiants. Actions : affecter les notes aux tudiants pour chaque module.
Consulter lemploi du temps :

Intention : consulter lemploi du temps dune promotion. Actions : consulter lemploi du temps.
Consulter les notes :

Intention : consulter les notes dun tudiant. Actions : choisir un tudiant et consulter la liste de ses notes.
Page 25
2.3.
Description dtaille des cas dutilisations
Nous allons maintenant dtailler chaque cas dutilisation qui doit faire lobjet dune dfinition a priori qui dcrit lintention de lacteur lorsquil utilise le systme et les squences dactions principales quil est susceptible deffectuer. Ces dfinitions servent fixer les ides et nont pas pour but de spcifier un fonctionnement complet et irrversible. Remarque : les descriptions vont tre organises de la faon suivante : Un sommaire didentification : va rsumer les proprits du cas dutilisation. Une description dtaille : des Prconditions au dclenchement du cas dutilisation doivent tre spcifies, un scnario nominal dcrivant celui-ci additionn des scnarios alternatifs et dexceptions. Les diagrammes (optionnelle): plusieurs diagrammes vont apparaitre (mais pas ncessairement) pour apporter une comprhension additive au cas dutilisation.
Page 26
Organiser les DPARTEMENTS:

Sommaire DIDENTIFICATION: ______________________________________________________________
Titre : Organiser les licences But : crer des domaines, des spcialits, des options. Rsum : crer un nouveau domaine, une nouvelle spcialit, une nouvelle option Acteur : Chef de dpartement
Descriptions des ENCHANEMENTS: ______________________________________________________________
Prconditions :
Le chef de dpartement est authentifi.
Scnario nominal :
Ce cas dutilisation commence lorsque le chef de dpartement demande au systme de crer un nouveau domaine. Enchanement (a) : Crer un domaine en construction
Le chef de dpartement choisit un nom pour le dpartement.
Enchanement (b) : Crer un tronc commun

Pour la premire anne un tronc commun va tre constitu. La dure de ce tronc commun est variable selon le domaine.
Enchanement (c) : Crer les spcialits/options

Il peut spcifier les spcialits/options que le domaine va contenir. Une dure en semestres doit tre renseigne.
Enchanement (d) : valider un domaine en construction

Le chef de dpartement valide la cration.
Page 27
Si le domaine existe dj dclencher : [Exception1 : DomaineExistant]
Enchanements alternatifs :
Enchanement (e) : crer les UE
Le chef de dpartement cre une UE, et choisit le type de cette UE (fondamentale, complmentaire, mthodologique, optionnelle, transversale, dcouverte). Il cre les modules pour cette UE, spcifie un nom, le nombre dheures enseigner, un coefficient, et un crdit pour chaque module. Il valide le module, si Code existe dj dclencher : [Exception2 : ModuleExistant] Il valide lUE, si Code existe dj dclencher : [Exception3 : UEExistante]
Enchanement (f) : Modifier un domaine en construction ou valid

Pour un domaine, le chef de dpartement peut ajouter/supprimer une spcialit/option ou modifier un tronc commun.
Enchanement (g) : Supprimer un domaine

Le chef de dpartement peut supprimer un domaine. Si une promotion appartient ce domaine dclencher :[Exception4 : DomaineUtilise]
Enchanement (h) : Supprimer une UE

Il peut aussi modifier une UE ou la supprimer. Si lUE est utilise dans une promotion dclencher :[Exception5 : UEUtilisee]
Exceptions :
[Exception1 : DomaineExistant] : le domaine est marqu en anomalie tant que le code na pas t chang. [Exception2 : UEExistante] : lUE est marqu en anomalie tant que le code na pas t chang. LUE ne peut plus tre valide. [Exception3 : ModuleExistant] : le module est marqu en anomalie tant que le code na pas t chang. Le module ne peut plus tre valid. [Exception4 : DomaineUtilise] : un message est affich lcran avisant lutilisateur que le domaine ne peut pas tre supprim. [Exception5 : UEUtilisee] : un message est affich lcran avisant lutilisateur que lUE ne pas tre supprime.
Ce cas dutilisation se termine lorsque le chef de dpartement a valid un domaine.
Page 28
Etablir les PROMOTIONS:

Titre : Etablir les promotions But : grer des promotions. Rsum : crer une nouvelle promotion, lui rattacher des tudiants Acteurs : Chef de dpartement
Prconditions :
1- Le chef de dpartement est authentifi. 2- Au moins un enseignant existe dans la base. 3- Au moins un domaine existe.
Scnario nominal :
Ce cas dutilisation commence lorsque le chef de dpartement demande au systme de crer une nouvelle promotion. Enchanement (a) : Crer une promotion en construction
Le chef de dpartement choisit un code/nom et lanne de cration pour la promotion.
Enchanement (b) : Rattacher un domaine

Il rattache la promotion un domaine. Si le tronc commun/Spcialit na pas dUE dclencher : [Exception1 : NoUECree]
Enchanement (c) : Rattacher les tudiants

Le chef de dpartement slectionne tous les tudiants faisant partie de la promotion. Si ltudiant EtudiantDejaAffecte] appartient dj une promotion dclencher : [Exception2 :
Enchanement (f) : fixer les dates dexamens
Page 29
Le chef de dpartement fixe les dates des examens. Il fixe les dates de dbut/fin, il cre les groupes
Enchanement (g) : valider une promotion en construction

Le chef de dpartement valide la promotion si aucune exception nest leve.
Enchanement (h) : Modifier une promotion en construction ou valide
Le chef de dpartement peut changer en cours dtudes, lenseignant en charge dun module.
Enchanement (i) : Supprimer une promotion

Le chef de dpartement peut supprimer une promotion si celle-ci na pas encore commenc les tudes.
Exceptions :
[Exception1 : NoUECree] : la promotion est marqu en anomalie tant quune UE na pas t cre. La promotion ne peut plus tre valide. [Exception2 : EtudiantDejaAffecte] : un message derreur est affich sur lcran avisant lutilisateur que ltudiant appartient dj la promotion.
Ce cas dutilisation se termine lorsque le chef de dpartement a valid une promotion.
Page 30
Suivre une PROMOTION:

Titre : Suivre une promotion But : permettre le suivi du cursus des tudiants. Rsum : commencer les tudes, affecter des enseignants chaque semestre Acteurs : Chef de dpartement
Prconditions :
1234Le chef de dpartement est authentifi. Au moins un enseignant existe dans la base. Au moins un domaine existe. Au moins une promotion existe.
Scnario nominal :
Ce cas dutilisation commence lorsque le chef de dpartement demande au systme de commencer les tudes dans une promotion. Enchanement (a) : commencer les tudes
Il slectionne les enseignants chargs de donner des cours, et attribue pour chacun deux un ou plusieurs modules enseigner. Si le module est dj attribu dclencher : [Exception1 : ModuleDejaAttribue ] Il spcifie les caractristiques du module TD/TP/Projet/Sminaire/confrence. Commencer le 1er semestre et la promotion.
Enchanement (b) : remplir les relevs de notes

Cas dutilisation Maintenir les notes
Enchanement (c) : terminer le semestre
Page 31
Si tous les relevs de notes sont remplis terminer le semestre, sinon dclencher : [Exception2 : SemestreIncomplet ]
Enchanement (d) : passer au prochain semestre Si cest le premier semestre de lanne, le passage est automatique pour tous les tudiants, sinon si cest le deuxime, alors une session de rattrapage est prvu pour l es tudiants qui nont pas tous les crdits requis. Les rsultats la suite des rattrapages vont dterminer :
Les tudiants aptes passer au palier suprieur. Les tudiants recals. Si le dernier semestre est termin, remise des diplmes aux tudiants ayants russis. Si une spcialisation se prsente, orienter les tudiants vers les spcialits choisies. Enchanements alternatifs :
Enchanement (e) : Exclure un tudiant de la promotion

Le chef de dpartement peut exclure un tudiant de la promotion. Exceptions : [Exception1 : ModuleDejaAttribue] : un message derreur est affich lcran avisant lutilisateur que le module est dj attribu. [Exception2 : SemestreIncomplet]: un message derreur est affich sur lcran avisant lutilisateur que des relevs de notes ne sont pas complets.
Ce cas dutilisation se termine lorsque le chef de dpartement a termin une promotion.
Diagramme DACTIVITS: ______________________________________________________________
Voici un diagramme dactivits reprsentant lenchainement des vnements pour le cas dutilisation : Suivre une promotion.
Page 32
Diagramme dactivits reprsentant lenchainement des tapes dune promotion
Page 33
Etablir les emplois du TEMPS:

Sommaire DIDENTIFICATION: ______________________________ ________________________________
Titre : Etablir les emploies du temps But : crer des emplois du temps. Rsum : crer un nouvel emploi du temps, en modifier un. Acteurs : Chef de dpartement
Prconditions :
1- Le chef de dpartement est authentifi. 2- Au moins une promotion a t cre.
Scnario nominal : Ce cas dutilisation commence lorsque le chef de dpartement demande au systme de crer un nouvel emploi du temps.
Enchanement (a) : Crer un emploi du temps en construction
Le chef de dpartement choisit une promotion pour qui lemploi du temps est destine. Il slectionne un semestre pour lanne en cours. Il slectionne une plage horaire.
Enchanement (b) : Affecter les charges

Il slectionne un module parmi les modules de la promo. Il affecte le module enseigner cette plage horaire. Si le module enseigner est dj attribu alors dclencher : moduleErreur] Il affecte un enseignant cette plage horaire. Si lenseignant est dj pris pour cette plage alors dclencher : [Exception2 : enseignantErreur] [Exception1 :
Enchanement (c) : Valider un emploi du temps en construction
Page 34
Le chef de dpartement valide lemploi du temps.
Enchanement (d) : Modifier un emploi du temps en construction ou valid
Le chef de dpartement dsaffecte une charge pour une plage horaire.
Enchanement (e) : Supprimer un emploi du temps

Le chef de dpartement supprime un emploi du temps.
Exceptions :
[Exception1 : moduleErreur] : un message derreur reste affich sur lcran tant que le module na pas t enlev de lemploi du temps. [Exception2 : enseignantErreur] : un message derreur reste affich sur lcran tant que lenseignant na pas t enlev de lemploi du temps.
Ce cas dutilisation se termine lorsque le chef de dpartement a valid un emploi du temps.
Diagramme DACTIVITS: _____________________________________________________________
Diagramme dactivits
Page 35
Consulter les emplois du TEMPS:

Titre : Consulter les emploies du temps But : consulter un emploi du temps. Rsum : sauthentifier et afficher lemploi du temps pour une promotion. Acteurs : enseignant, tudiant.
Prconditions :
Lutilisateur est authentifi.
Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur demande consulter lemploi du temps.
Enchanement (a) : Consulter un emploi du temps
Lutilisateur slectionne une promotion. Lutilisateur slectionne ensuite un semestre pour lanne en cours. Il affiche ensuite lemploi du temps correspondant.
Ce cas dutilisation se termine lorsque lutilisateur se dconnecte.
Page 36
Grer les fiches des tudiants :

Titre : Grer les fiches des tudiants But : crer des dossiers tudiants. Rsum : crer un nouveau dossier, modifier un dossier existant. Acteurs : Scolarit.
Prconditions :
La Scolarit est authentifie.
Scnario nominal : Ce cas dutilisation commence lorsque le chef de dpartement/Scolarit demande au systme de crer un nouveau/modifier un dossier tudiant.
Enchanement (a) : Crer un dossier tudiant en construction
Le chef de dpartement choisit un nom/prnom/date et lieu de naissance. Il remplit le numro dinscription. Il peut choisir ventuellement lanne dinscription. Remplir les informations sur ltat civil.
Enchanement (b) : Valider dossier tudiant en construction

Le chef de dpartement doit avoir rempli toutes les informations obligatoires.
Enchanement (c) : Modifier un dossier tudiant en construction ou valid
Le chef de dpartement met jour ce dossier quand cela est ncessaire. Si ltudiant est dj inscrit, spcifier la nouvelle anne dinscription.
Page 37
Enchanement (d) : Supprimer un dossier tudiant

Le chef de dpartement peut supprimer un dossier tudiant sil nappartient aucune promotion au pralable.
Ce cas dutilisation se termine lorsque le chef de dpartement a valid un dossier tudiant. Diagrammes dactivits : ______________________________________________________________
Diagramme dactivits
Page 38
Maintenir les notes des TUDIANTS:

Titre : Maintenir les notes But : affecter les notes aux tudiants. Rsum : choisir un tudiant, un module, affecter la note. Acteurs : Enseignant, Scolarit.
Descriptions des ENCHANEMENTS: _______________________________________________________
Prconditions :
1. Le responsable de la scolarit ou lenseignant est authentifi. 2. Au moins une promotion existe. 3. Au moins un dossier tudiant est cre.
Scnario nominal : Ce cas dutilisation commence lorsque le responsable de la scolarit affiche le relev de notes.
Enchanement (a) : remplir le relev de notes
Le responsable de la scolarit ou lenseignant choisit une promotion. Il choisit un tudiant et affiche son relev de notes. Choisir un module et affecter une note celui-ci.
Enchanement (b) : Valider une fiche notes

Valider les donnes.
Enchanement (c) : modifier une fiche notes en construction/valide
La scolarit peut modifier une note dun module.
Exceptions :
Page 39
[Exception1 : FicheNotesDejaExistante] : un message derreur saffiche lcran avisant lutilisateur que la fiche existe dj pour ce semestre. [Exception2 : ModuleDejaNot] : Si lacteur est lenseignant alors il ne peut plus modifier la note, sinon un message dinformation reste affich sur lcran demandant la confirmati on du changement de la note et de la raison.
Ce cas dutilisation se termine lorsque le chef de dpartement a valid la fiche de notes de ltudiant.
Diagrammes dactivits : ______________________________________________________________
Diagramme dactivits
Remarque : cet algorithme, ne correspondant pas assez aux besoins du langage choisi et lIHM, va tre sensiblement chang.
Page 40
Consulter les NOTES:

Titre : Consulter les notes But : consulter une fiche de notes. Rsum : sauthentifier et afficher la fiche de notes pour un tudiant. Acteurs : tudiant.
Prconditions :
1. Lutilisateur est authentifi. 2. Au moins un dossier tudiant est cre.
Scnario nominal :
Ce cas dutilisation commence lorsque ltudiant se connecte son compte. Enchanement (a) : Slectionner un tudiant
Le responsable choisit une promotion. Il choisit un tudiant.
Enchanement (b) : Afficher les notes

Il slectionne un semestre afficher et affiche ses notes.
Ce cas dutilisation se termine lorsque ltudiant sest dconnect.
Page 41
Grer les PROFILS:

Titre : Grer les profils But : crer les profils utilisateurs. Rsum : crer un nouveau profil et lui affecter des droits daccs. Acteurs : Administrateur.
Prconditions :
Aucunes.
Scnario nominal :
Ce cas dutilisation commence lorsque ladministrateur lance le logiciel. Enchanement (a) : Crer un profil en construction
Ladministrateur choisit un nom / mot de passe pour le compte. Il choisit le type de ce compte.
Ce cas dutilisation se termine lorsque le chef de dpartement a valid un profil en construction.
Page 42
2.4.
Structuration des cas dutilisations dans des packages
Cette phase va permettre de structurer les cas dutilisations en groupes fortement cohrents, ceci afin de prparer le terrain pour la prochaine phase qui est le dcoupage en catgories . Dfinition : un package reprsente un espace de nommage qui peut contenir : 1. Des lments dun modle. 2. Des diagrammes qui reprsentent les lments du modle. 3. Dautres packages. La structuration des cas dutilisations se fait par domaine dexpertise mtier c..d. les lments contenus dans un package doivent reprsenter un ensemble fortement cohrent et sont gnralement de mme nature et de mme niveau smantique.
Cas dutilisation
Acteurs
Package
Organiser un dpartement
Chef de dpartement
Gestion des dpartements
Grer les promotions Suivre les promotions

Maintenir les notes
Chef de dpartement Gestion des promotions Chef de dpartement Scolarit, Enseignant Gestion des notes
Consulter les notes Grer les emplois du temps
Etudiant Scolarit Gestion des emplois du temps Etudiant, Enseignant
Consulter les emplois du temps
Page 43
Grer les profils
Administrateur
Gestion des profils
2.5.
Identification des classes candidates
Cette phase va prparer la modlisation oriente objet en aidant trouver les classes principales du futur modle statique danalyse. La technique utilise pour identifier les classes candidates est la suivante : Chercher les noms communs importants dans les descriptions textuelles des cas dutilisation. Vrifier les proprits objet de chaque concept (identit, proprits, comportement), puis dfinir ses responsabilits.
Dfinition : une responsabilit est une sorte de contrat, ou dobligation, pour une classe. Elle se place un niveau dabstraction plus lev que les attributs ou les oprations. On formalise ensuite ces concepts mtier sous forme de classes et dassociations rassembles dans un diagramme statique pour chaque cas dutilisation. Ces diagrammes prliminaires sont appels diagramme des classes participantes , nont pas pour objectif dtre complet. Ils servent uniquement dmarrer la dcouverte des classes du modle danalyse. Exemple :
Resp onsabilits de la classe Domaine
Page 44
Diagramme des classes participantes du cas dutilisation Organiser les dpartements :

Les classes candidates sont tires de la description textuelle du cas dutilisation et des diagrammes dynamiques reprsentant celui-ci :
Domaine, Discipline, UE, Module.
Diagramme des classes participantes Organiser les dpartements
Page 45
Diagramme des classes participantes du cas dutilisation Etablir les promotions :

Promotion, Domaine, Enseignant, Etudiant, Tronc_Commun, Specialite.
Diagramme des classes participantes Etablir les promotions
Page 46
Diagramme des classes participantes du cas dutilisation Suivre les promotions :

Promotion, Semestre, Domaine, Enseignant, Etudiant.
Diagramme des classes participantes Suivre les promotions
Page 47
Diagramme des classes participantes du cas dutilisation Etablir les emplois du temps :
Emploi du temps, Plage horaire, UE, Module, Enseignant.
Diagramme des classes participantes Etablir les emplois du temps
Page 48
Diagramme des classes participantes du cas dutilisation Maintenir les notes tudiants :
Fiche notes, Note, Module, Etudiant.
Diagramme des classes participantes Maintenir les notes
Page 49
3. ANALYSE
3.1. Dcoupage en catgories
Cette phase marque le dmarrage de lanalyse objet du systme raliser. Elle utilise la notion de package pour dfinir des catgories de classes danalyse et dcouper le modle UML en blocs logiques les plus indpendants possibles. Le dcoupage en catgories constitue la premire activit de ltape danalyse et elle va saffiner de manire itrative au cours du dveloppement du projet. Elle se situe sur la branche gauche du cycle en Y et succde la capture des besoins fonctionnels. Pour passer lanalyse, il faut se baser sur les principes de lApproche Oriente Objet, notamment celle de lencapsulation. cet effet, il faut passer dune structuration fonctionnelle via les cas dutilisations, une structuration objet via les classes et les catgories. Dfinition : une catgorie consiste en un regroupement logique de classes forte cohrence interne et faible couplage externe. Le dcoupage en catgories de notre projet a donn le rsultat suivant :
Page 50
Dcoupage en catgories
3.2.
Dpendances entre catgories

Classe Promotion :
Associations de la classe Promotion
Page 51
Classe Fiche notes :
Associations de la classe Fiche Notes
Page 52
Classe Emploi du temps :
Associations de la classe Emploi du temps
Page 53
3.3.
Diagramme de packages danalyse
Ce diagramme va reprsenter les diffrentes dpendances entre les packages danalyse :
Diagramme de packages danalyse
Remarque : ce diagramme a t obtenu aprs plusieurs itrations. Remarque 2: cette phase peut tre utilise par un chef de projet pour constituer les quipes. Chaque quipe pourra se concentrer sur le dveloppement dune seule catgorie/package.
Page 54
3.4.
Dveloppement du modle statique
Le dveloppement du modle statique constitue la deuxime tape danalyse. Les diagrammes de classes tablis sommairement dans les diagrammes de classes participantes, puis rorganiss lors du dcoupage en catgories, vont tre, complts, et optimiss. Il sagit dune activit itrative, fortement couple avec la modlisation dynamique.
Catgorie Etudes :
Voici le diagramme de classe de la catgorie Etudes.
Diagramme de classe
Page 55
Catgorie Promotions :
Voici le diagramme de classe de la catgorie Promotion et aussi Etudiants.
Diagramme de classe de la catgorie Promotion
Page 56
Et voici les oprations/attributs de la classe Promotion.
Classe Promotion (attributs/oprations)
Page 57
Et voici les oprations/attributs de la classe Semestre.
Classe Semestre (attributs/oprations)
Page 58
Catgorie Relev de notes :

Voici le diagramme de classe de la catgorie Relev de notes.
Diagramme de classe de la catgorie Relev de Notes
Et voici les oprations/attributs des classes Relev de Notes et Note.
Classes ReleveNotes et Note (attributs/oprations)
Page 59
Catgorie Enseignants :
Voici le diagramme de classe de la catgorie Enseignants.
Diagramme de classe
Et voici les oprations/attributs de la classe Enseignant.
Classe Enseignant (attributs/oprations)
Page 60
Catgorie Etudiant :
Classe Etudiant (attributs/oprations)
Catgorie Emploi du temps :

Voici le diagramme de catgories de la classe Emploi du temps.
Associations de la catgorie Emploi du temps
Page 61
3.5.
Dveloppement du modle dynamique
Le dveloppement du modle dynamique constitue la troisime activit de ltape danalyse. Il sagit dune activit itrative, fortement couple avec la modlisation statique.
Identification des scnarios :

Un cas dutilisation dcrit un ensemble de scnarios. Un scnario dcrit une excution particulire dun cas dutilisation du dbut la fin.il correspond une slection denchainements du cas dutilisation. On peut distinguer plusieurs types de scnarios :
Nominaux : ils ralisent les post conditions du cas dutilisation, dune faon naturelle et frquente ; Alternatifs : ils remplissent les post conditions du cas dutilisation, mais en empruntant des voies dtournes ou rares ; Aux limites : ils ralisent les post conditions du cas dutilisation, mais modifient le systme de telle sorte que la prochaine excution du cas dutilisation provoquera une erreur ; Derreur : ne ralisent pas les post conditions du cas dutilisation.
Il faut signaler que tous les scnarios possibles ne peuvent tre numrs et dcrits du fait quils en existent beaucoup. Cest pour cette raison que nous allons faire une description des scnarios les plus pertinents.
Page 62
SCNARIOS DE Organiser les licences :

Parmi tous les scnarios possibles pour le cas dutilisation Organiser les licences (OL) nous avons choisi les suivants : Enumration des scnarios :
Scnarios nominaux : OL_N1 : crer un nouveau domaine. OL_N2 : crer des UE pour un Tronc_Commun ou Specialite.
Scnarios alternatifs : OL_A1 : modifier un domaine par ajout dune spcialit. OL_A2 : modifier un domaine par ajout dune option. OL_A3 : modifier un domaine par cration dUE et modules. OL_A4 : modifier un domaine par suppression dune UE. Scnarios dexception : OL_E1 : non validation de la cration de domaine pour cause de nom existant dj. OL_E2 : non validation de la modification du domaine par suppression dune UE pour cause dexistence dune promotion utilisant lUE.
Description dtaille des scnarios : La description dtaille va permettre de, mettre en vidence les interactions entre les diffrents objets. Cependant, du fait de lexistence de nombreux scnarios, nous allons dtailler seulement quelques uns dentre eux.
Scnarios nominaux : OL_N1 : crer un nouveau domaine. Le chef de dpartement donne un nom/mot de passe didentification. Il choisit un code/nom pour le domaine. Un tronc commun est cr. Le chef de dpartement fixe la dure en semestres de celui-ci. Il cre les spcialits du domaine, en choisissant pour chacune delle la dure. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o Un acteur Chef de dpartement.
Page 63
o Un objet Domaine cre au cours du scnario. o Un objet Tronc_Commun cre au cours du scnario. o Un objet Specialite cre au cours du scnario.
Diagramme de squences du scnario crer un nouveau domaine
OL_N2 : crer des UE pour un Tronc_Commun ou Specialite.

Le chef de dpartement donne un nom/mot de passe didentification. Il slectionne un Domaine existant. Il slectionne le tronc commun / une spcialit qui na pas encore des UE. Il cre une UE en donnant un code/intitul/crdit. Pour chaque UE cre, il cre plusieurs modules en spcifiant un code/intitul/crdit. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o Un acteur Chef de dpartement. o Un objet Domaine cre au cours du scnario. o Un objet Tronc_Commun/ Specialite cre au cours du scnario.
Page 64
o Un objet UE cre au cours du scnario. o Un objet Module cre au cours du scnario.
Diagramme de squences du scnario crer une UE
OL_E1 : non validation de la cration de domaine pour cause de nom existant

dj.
Diagramme de squences du scnario non validation de la cration dun domaine
Page 65
SCNARIOS DE Etablir les promotions :

Parmi tous les scnarios possibles pour le cas dutilisation Etablir les promotions (EP) nous avons choisi les suivants : Enumration des scnarios :
Scnarios nominaux : EP _N1 : crer une nouvelle promotion.
Scnarios alternatifs : EP _A1 : modifier une promotion par ajout dun enseignant. EP _A2 : modifier une promotion par attribution dun module un enseignant non encore attribu. EP _A3 : modifier une promotion par libration dun enseignant charg dun module. EP _A4 : modifier une promotion par ajout dun tudiant. EP _A5 : modifier une promotion par enlvement dun tudiant. Scnarios dexception : EP _E1 : EP _E2 :
Description dtaille des scnarios :

Scnarios nominaux : EP_1 : crer une nouvelle promotion. Le chef de dpartement donne un nom/mot de passe didentification. Il choisit un nom pour la promotion et la dure en semestres, il choisit quel domaine elle appartient, si cest un tronc commun ou une spcialit le cas chant il spcifie lanne du LMD. Le chef de dpartement slectionne les enseignants et leur attribue un module enseigner. Le chef de dpartement slectionne les tudiants faisant partie de la promotion. Le chef de dpartement valide la promotion. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o Un acteur Chef de dpartement. o Une Promotion cre au cours du scnario. o Un multi-objet reprsentant les Modules de la spcialit ou du tronc_commun cre cours du scnario.
Page 66
o Un multi-objet reprsentant lensemble des instances de Enseignant qui vont tre affects la nouvelle promotion. o Un multi-objet reprsentant lensemble des instances de Etudiant qui vont tre rattachs la nouvelle promotion.
Diagramme de squences du scnario crer une nouvelle promotion
Page 67
EP _A1 : modifier une promotion par ajout dun enseignant.

Le chef de dpartement donne un nom/mot de passe didentification. Il slectionne une promotion. Le chef de dpartement ajoute un enseignant la promotion. Le chef de dpartement valide la promotion. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o Un acteur Chef de dpartement. o Une Promotion cre au cours du scnario. o Un objet Enseignant qui va tre affect la promotion.
Diagramme de squence du scnario modifier une promotion par ajout dun enseignant
EP _A2 : modifier une promotion par attribution dun module un enseignant non
encore attribu. Le chef de dpartement donne un nom/mot de passe didentification. Il slectionne une promotion.
Page 68
Il slectionne un module. Il attribue le module un enseignant. Le chef de dpartement valide la promotion. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o o o o Un acteur Chef de dpartement. Une Promotion cre au cours du scnario. Un objet Enseignant qui va est affect la promotion. Un objet Module qui va tre affect un enseignant.
Diagramme de squence du scnario modifier une promotion par attribution dun module un enseignant non encore attribu
EP _A3 : modifier une promotion par libration dun enseignant charg dun
module. Le chef de dpartement donne un nom/mot de passe didentification.
Page 69
Il slectionne une promotion. Il slectionne un enseignant faisant parti de la promotion. Il dsaffecte lenseignant de son module. Le chef de dpartement valide la promotion. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o o o o Un acteur Chef de dpartement. Une Promotion cre au cours du scnario. Un objet Enseignant qui va tre affect la promotion. Un objet Module qui va tre affect un Enseignant.
Diagramme de squence du scnario modifier une promotion par libration dun enseignant charg dun module
EP _A4, EP_A5: modifier une promotion par ajout/enlvement dun tudiant.

Le chef de dpartement donne un nom/mot de passe didentification.
Page 70
Il slectionne une promotion. Il slectionne un tudiant. Il dsaffecte ltudiant de la promotion. Le chef de dpartement valide la promotion. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o Un acteur Chef de dpartement. o Une Promotion cre au cours du scnario. o Un objet Etudiant qui va tre affect la promotion.
Diagramme de squence du scnario modifier une promotion ajout/enlvement dun tudiant
Page 71
SCNARIOS DE Etablir les emplois du temps :

Enumration des scnarios :
Scnarios nominaux : EET_1 : crer un nouvel emploi du temps. Le chef de dpartement donne un nom/mot de passe didentification. Il choisit la promotion. Il choisit le semestre. Pour chaque plage horaire slectionne, il affecte un module. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o o o o o Un acteur Chef de dpartement. Un emploi du temps cre au cours du scnario. Une Promotion. Un Module. Une plage horaire cre au cours du scnario.
Page 72
Diagramme de squence du scnario crer un nouvel emploi du temps
SCNARIOS DE Grer les fiches tudiants :

Parmi tous les scnarios possibles pour le cas dutilisation Grer les fiches tudiants (GF) nous avons choisi les suivants : Enumration des scnarios :
Scnarios nominaux : GF_1 : crer un nouveau dossier tudiant. La scolarit donne un nom/mot de passe didentification. Il saisit les informations obligatoires (n inscription, nom, prnom). Il saisit les informations facultatives. Il saisit les informations sur ltat civil. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o Un acteur Scolarit. o Un tudiant cre au cours du scnario.
SCNARIOS DE Maintenir les notes tudiants :

Parmi tous les scnarios possibles pour le cas dutilisation Etablir les promotions (MN) nous avons choisi les suivants : Enumration des scnarios :
Scnarios nominaux : MN _N1 : crer une fiche de notes. MN _N2 : affecter les notes pour un tudiant. Scnarios alternatifs : MN _A1 : modifier une note pour un tudiant. MN _A2 : modifier une promotion par attribution dun module un enseignant non encore attribu. MN _A3 : modifier une promotion par libration dun enseignant charg dun module. Scnarios dexception : MN _E1 : MN _E2 :
Page 73
Description dtaille des scnarios :

Scnarios nominaux : MN _N1 : crer une fiche de notes. La scolarit donne un nom/mot de passe didentification. Elle choisit une promotion. Elle slectionne un tudiant. Elle cre la fiche de notes. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o o o o Un acteur Scolarit. Un tudiant cre au cours du scnario. Une Promotion cre au cours du scnario. Une Fiche notes.
Diagramme de squence du scnario crer une fiche de notes
MN _N2 : affecter les notes pour un tudiant.

La scolarit donne un nom/mot de passe didentification. Elle choisit une promotion. Elle slectionne un tudiant.
Page 74
Pour chaque module, elle affecte une note (examen, TD, TP, Devoir). Le calcul de la moyenne se fait automatiquement. Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes : o o o o Un acteur Scolarit. Un tudiant cre au cours du scnario. Un objet Promotion cre au cours du scnario. Un objet Note.
Diagramme de squence du scnario affecter les notes pour un tudiant
Remarque : Du fait des contraintes du langage, ces diagrammes sont difficilement implmentables en ltat. Cependant, ils servent faire surgir les interactions possibles entres les diffrents objets.
Page 75
Construction des diagrammes dtats :

On recourt au concept de machine tats finis, qui consiste sintresser au cycle de vie dun objet gnrique dune classe particulire au fil de ses interactions avec les autres classes, dans tous les cas possibles. Cette vue locale dun objet, dcrivant comment il ragit des vnements en fonction de son tat courant et passe dans un nouvel tat, est reprsente graphiquement sous forme dun diagramme dtats. Dfinition : un tat reprsente une situation durant la vie dun objet pendant laquelle :

Il satisfait une certaine condition ; Il excute une certaine activit ; Ou bien il attend un certain vnement.
Un objet passe par une succession dtats durant son existence. Un tat a une dure finie, variable selon la vie de lobjet, en particulier en fonction des vnements qui lui arrivent. Diagramme dtats de la classe Promotion :
En attente : de la cration dune instance de Promotion sa validation, cet tat inclut toutes les oprations de rattachement un domaine, de rattachements denseignants, de rattachements dtudiants. Valide (cre) : il reprsente une Promotion cre et valide. En cours : cet tat reprsente une Promotion en cours denseignement. Aucun tudiant ne peut tre ajout ce moment et aucun changement de Module ou dUE ne peut tre autoris. Cependant, un enseignant peut tre remplac. Termine : cet tat survient aprs la fin des dlibrations de la dernire session dexamen.
Page 76
Diagramme dtats de la classe Promotion
Diagramme dtats de la classe Etudiant :
Nouvellement inscrit : cet tat reprsente un tudiant qui vient dtre inscrit luniversit.il se produit lorsque ltudiant est introduit la premire fois dans la base et que cest sa premire anne la facult. Rattach : cet tat reprsente un tudiant qui est attach une promotion. En cours dtudes : cet tat reprsente un tudiant qui est entrain dtudier. En cours de passage : cet tat survient aprs quun tudiant ait russi le passage au niveau suprieur. Au cours de cet tat, ltudiant fait le choix de la prochaine branche. Recal : cet tat survient aprs quun tudiant ait chou le passage au niveau suprieur. Etudes termines : cet tat survient aprs quun tudiant ait termin ses tudes suprieures.
Page 77
Diagramme dtats de la classe Etudiant
Page 78
4. CONCEPTION
La conception prliminaire est ltape o seffectue la fusion des tudes fonctionnelles et techniques. La conception dtaille qui vient juste aprs est une activit qui sinscrit dans lorganisation dfinie par la conception prliminaire. Le modle logique y est particulirement important dans la mesure o cest dans cette tape quon gnre le plus grand nombre dinformations. Il est ainsi possible de confier les catgories des personnes diffrentes, qui pourront travailler indpendamment les unes des autres. Les concepteurs dans cette phase construisent les classes, les vue dIHM, les interfaces, les tables et les mthodes qui vont donner une image prte coder de la solution.
4.1.
Architecture de lapplication
La technologie Objet requiert une architecture. C'est cette architecture qui organise les interactions entre objets. On a l'habitude de regrouper ces objets en classes, ces classes en domaines, et ces domaines en couches. Les couches permettent de prsenter l'architecture de l'application. Les quipes de ralisation s'attribuent alors des responsabilits sur le dveloppement de chaque couche. Aussi, si modliser est indispensable, construire une architecture couche est un critre de qualit dans le cadre d'un dveloppement Objet. Reste choisir le nombre de couches et dfinir leur contenu.
Architecture 3-Tiers :
Pour avoir une architecture robuste, modulable et volutive, il nous faut utiliser le principe de couche . Nous allons donc sparer au maximum les diffrents types de traitement de lapplication (Dao, Mtier, Prsentation). Ceci correspond une architecture 3-Tiers :
Page 79
Architecture 3-Tiers
4.2.
Les Design Patterns
De nombreuses mthodes existent pour simplifier la phase de conception des logiciels. Parmi les plus connues, considrons Merise et UML. Mais une autre mthode existe, plus proche de l'implmentation. Lors de la conception d'une application de nombreux problmes peuvent survenir. Le systme des Design Patterns, ou motifs de conception, reprsente un systme objet destin la rsolution de problmes techniques. (Eric Freeman, 2005) Un Design Pattern constitue un petit ensemble de classes apte offrir la solution la plus efficace un problme. La dfinition d'un motif de conception repose donc sur trois critres. Premirement, le problme rsoudre est classique et bien connu. Ensuite, l'ensemble des classes employes porte un nom unique (on parle par exemple du motif "Decorator"). Enfin, la solution que propose ce motif correspond la rsolution la plus optimale du problme. (Guy)
Page 80
Les Designs Patterns proviennent du travail de nombreux dveloppeurs qui se sont tour tour penchs sur les mmes problmes. En mettant en corrlation ces travaux on a pu dsigner les meilleures solutions dcouvertes sous le terme de motifs de conception. La connaissance de ces motifs permet au programmeur de trouver rapidement des implmentations pour ses programmes. La principale difficult rside dans l'identification du problme et dans sa mise en relation avec des motifs connus. Pour nous, les Design Pattern nous ont aid trouver une solution lgante un problme conceptuel. En fait, ils vont nous aider coder les diffrents concepts qui se dgagent dans la phase de conception. Donc on peut dire que les Design Pattern interviennent aussi dans la phase de codage.
Le Design Pattern Etat :

Dfinition : Le Design Pattern Etat est une faon de concevoir le diagramme dtats dune classe danalyse. La gestion des tats est dlgue de sorte qu chaque tat corresponde une classe du patron. Une classe gre ainsi les activits et les transitions attaches ltat quelle reprsente.
Le Design Pattern Etat
Remarque : les diagrammes qui vont suivre ont t cre avec loutil UML de NetBeans 5.5 Voici les diffrents diagrammes Etats que nous avons conus :
Page 81
La Classe Promotion :
Diagramme dtats de la classe Promotion
Page 82
La classe Promotion dlgue la gestion de ses tats linterface EtatPromotion et ses diffrentes implmentations (EtatEnCreation, EtatValide, EtatEnCours, EtatTerminee)
Page 83
La classe Promotion et ses diffrents tats
La Classe Etudiant :
Design Pattern Etat de la classe Etudiant
Page 84
La classe Etudiant dlgue la gestion de ses tats linterface EtatEtudiant
Page 85
Le Design Pattern Faade :

Dfinition : Le patron de conception Faade a pour but de cacher une conception et une interface complexe difficile comprendre. La faade permet de simplifier cette complexit en fournissant une interface simple du sous-systme. Habituellement, la faade est ralise en rduisant les fonctionnalits de ce dernier mais en fournissant toutes les fonctions ncessaires la plupart des utilisateurs.
Un exemple du Design Pattern Faade
Lapplication de ce Design Pattern notre application se concrtise comme suit :
Page 86
La couche Mtier accs la BDD grce au Pattern DAO
Le Design Pattern Observateur :

Dfinition : Le Design Pattern Observateur consiste synchroniser des objets en minimisant les dpendances qui devraient stablir entre eux. Nous distinguons de ce fait le sujet et les observateurs. Le sujet centralise les donnes et il est unique.il comprend des oprations permettant aux observateurs daccder ses donnes. Lobservateur restitue les donnes du sujet auquel il est abonn, et plusieurs peuvent se synchroniser sur le mme sujet. La dynamique dchange entre le sujet et ses observateurs abonns stablit partir dune notification indiquant une modification du sujet. Ce dernier en avise ses observateurs qui questionnent en retour le sujet pour obtenir les informations ncessaires leur mise jour. Ce Design Pattern est intgr Java au travers des classes Observable et Observer du package Java.util. (Florian GRISONI) Remarque : Ce Design Pattern a t intensment utilis dans notre logiciel pour sa facilit de mise en uvre, et les diffrentes possibilits quil nous offre afin de mettre en pratique un autre Design Pattern qui est le MVC.
Le Design Pattern MVC :

L'architecture Modle Vue Contrleur (MVC) est une mthode de conception pour le dveloppement d'applications logicielles qui spare le modle de donnes, l'interface utilisateur et la logique de contrle. Ce modle d'architecture impose la sparation entre les donnes, les traitements et la prsentation, ce qui donne trois parties fondamentales dans l'application finale : le modle, la vue et le contrleur :
Le Modle : reprsente le comportement de l'application : traitements des donnes, interactions avec la base de donnes, etc. Il dcrit les donnes manipules par l'application et dfinit les mthodes d'accs. la Vue : correspond l'interface avec laquelle l'utilisateur interagit. Les rsultats renvoys par le modle sont dnus de toute prsentation mais sont prsents par les vues. Plusieurs vues peuvent afficher les informations d'un mme modle. Elle peut tre conue en html, ou tout autre langage de
Page 87
prsentation. La vue n'effectue aucun traitement, elle se contente d'afficher les rsultats des traitements effectus par le modle, et de permettre l'utilisateur d'interagir avec elles. le Contrleur : prend en charge la gestion des vnements de synchronisation pour mettre jour la vue ou le modle. Il n'effectue aucun traitement, ne modifie aucune donne, il analyse la requte du client et se contente d'appeler le modle adquat et de renvoyer la vue correspondant la demande.
En rsum, lorsqu'un client envoie une requte l'application, celle-ci est analyse par le contrleur, qui demande au modle appropri d'effectuer les traitements, puis renvoie la vue adapte au navigateur, si le modle ne l'a pas dj fait. Un avantage apport par ce modle est la clart de l'architecture qu'il impose. Cela simplifie la tche du dveloppeur qui tenterait d'effectuer une maintenance ou une amlioration sur le projet. En effet, la modification des traitements ne change en rien la vue. Par exemple on peut passer d'une base de donnes de type SQL XML en changeant simplement les traitements d'interaction avec la base, et les vues ne s'en trouvent pas affectes. (Wikipedia) Comme exemple, Swing la bibliothque graphique de Java pour la cration dinterfaces graphiques, est base sur le modle MVC. (Cornell)
Page 88
5. CODAGE
Le choix du langage sest port vers Java, qui tant Orient Objet la base, nous facilitera la transformation de notre modle objet vers le code. La programmation peut se faire pour des exemples simples avec le compilateur javac, mais pour avoir plus de confort il est prfrable d'utiliser un environnement de dveloppement intgr ou IDE. Notre choix sest port vers lEDI NetBeans, qui nous fournit le confort et la simplicit ncessaires un dveloppement propre et rapide.
5.1.
La gnration de code avec NetBeans 5.5:
Grace au plugin UML intgr NetBeans, nous avons pu crer les diffrents diagrammes UML dfinis lors de la phase de conception. Mais aussi, nous allons lutiliser pour la gnration du code partir des diagrammes de classes. Nous bnficierons dans ce cas dun gain de temps non ngligeable, du fait quil peut gnrer aussi les diffrents packages avec leurs classes respectives.
5.2.
Lapplication JStudent
Page 89
Structure gnrale de lapplication :

Lapplication est dcoupe en 3 couches distinctes, Prsentation, Mtier et DAO. La couche Prsentation est charge de tout ce qui est affichage. La couche Mtier est la logique mtier de lapplication, elle est le cur et cest elle qui dfinit toutes les rgles rgissantes au fonctionnement de lapplication. La couche DAO est lintermdiaire entre les autres couches et la Base de donnes.
Figure reprsentant les 3 couches de lapplication
Page 90
La couche Mtier :
Voici quelques figures reprsentants un chantillon du code source de cette couche :
La classe Promotion ( gauche les Attributs et les Mthodes)
Page 91
La classe Domaine ( gauche les Attributs et les Mthodes)
Page 92
La classe Etudiant ( gauche les Attributs et les Mthodes)
Page 93
La couche Prsentation :
Voici quelques figures reprsentants linterface du logiciel :
La fentre principale
Page 94
Fiche de cration dun nouvel tudiant
Page 95
Fiche de cration dune nouvelle promotion
Page 96
Fiche de consultation dune promotion
Page 97
Fiche de relev de notes
Page 98
Le stockage de donnes :
La technique choisie pour persister les donnes est : la srialisation. Une technique plus aboutie aurait t un meilleur choix comme : le mapping Objet/Relationnel avec un outil comme Hibernate. Cependant, lapprentissage de cet outil demande un temps supplmentaire. Mais la solution de la srialisation rponds largement nos besoins pour ce projet, cest pour a que nous avons jug pertinent de la garder.
Page 99
Bilan de la mthode
Du fait de notre manque dexprience dans le domaine et, du cadre limit (humain et matriel) dans lequel nous avons men notre projet, on ne va pas tirer de conclusion dfinitive sur la mthode. Mais en ce qui concerne la prise en compte dune volution possible de lapplication, on va alors donner un cas concret de ce que pourrait tre un ajout dun nouveau besoin fonctionnel.
Etude du cas : Gestion des SALLES

Nous avons signal au dbut que la gestion des salles a t ignore pour manque de temps et pour rduire la complexit de notre projet. Nous allons donc montrer comment on pourrait ajouter cette fonctionnalit notre projet de faon concrte.
Identification du besoin :
On suppose que la gestion de salles se trouve finalement, tre un besoin rel pour les utilisateurs de notre application. Nous allons dabord identifier les acteurs du systme devant interagir avec le systme travers cette nouvelle fonctionnalit : Il sagit de la scolarit qui devra pour chaque promotion, chercher une salle libre afin que les cours puissent y tre enseigns.
Page 100
Cas dutilisation Grer les salles
On peut la suite de cration dune promotion, lui affecter une salle. De ce fait, le cas dutilisation grer les salles pourra tendre le cas dutilisation tablir les promotions . La gestion des salles pourra aussi tre comprise comme une spcification de chaque dpartement. Ce qui nous amne lintroduire au package Gestion des dpartements .
Description dtaille du cas dutilisation :

Ce cas dutilisation commence lorsque la scolarit demande au systme de crer une nouvelle salle. Enchanement (a) : Crer une salle en construction
La scolarit choisit le bloc auquel la salle appartient. Elle choisit un numro. Elle spcifie ltage, le nombre de places disponibles Dautres enchainements
Enchanement alternatifs : Crer un bloc en construction
Identification des classes candidates :

A la suite de cette description dtaille, nous pouvons en dduire dj deux classes : Bloc, Salle.
Concrtement dans le code :

Normalement, il aurait fallu faire une tude plus approfondie, et continuer avec le modle statique et dynamique, afin de dgager les liens possibles entre ces deux classes et les autres classes des autres packages. Nous pouvons cependant dire que ce nouveau besoin fonctionnel, se traduira par un ajout de ces deux classes au package Etudes. Et il devrait y avoir un lien entre la classe Salle et Promotion. Dans le code, a se traduira par lajout dun attribut de Type Salle.
Page 101
Ceci ne devrait pas affecter le codage en gnral, du fait que les responsabilits des diffrentes classes et packages ont t bien spares.
Conclusion
Nous pouvons constater que lajout de nouvelles fonctionnalits peut tre simplifi, pour peu quon respecte bien les tapes dfinies par 2TUP. a demande de faire une itration complte ou partielle selon le besoin, du cycle Y, et ne pas succomber la tentation de toucher rapidement au code.
Page 102
Conclusion gnrale
Nous avons tent travers ce projet de dmontrer limportance de lapplication dune mthode de dveloppement. Nous pensons aussi que 2TUP pourra tre utilise dans des projets de moyenne grande envergure. A titre personnel, le bnfice quon en a tir est lapprentissage de concepts la pointe de la technologie et des tendances actuelles dans le monde professionnel. Une recherche profonde a t indispensable pour essayer de comprendre ces concepts l. Nous pouvons citer ce propos, un excellent livre traitant ce sujet qui sappelle : UML 2 En Action. Ce projet nous a permis denrichir nos connaissances dans des domaines trs varis comme : LOrient Objet, UML, 2TUP, le langage JAVA, les Design Patterns, Swing En termes dvolution, lapplication pourra par la suite tre adapte une utilisation luniversit. Par exemple, une base de donnes pourra tre utilise soit par le biais dun pont JDBC, ou par le biais dune solution de Mapping Objet/ Relationnel comme Hibernate. Aussi, un dploiement sur un rseau pourra tre fait grce au framework J2EE. Nous esprons que la lecture de ce mmoire a t agrable et claire.
Page 103
Bibliographie
Chromatic. (2005). Extreme programming. O'Reilly. Cornell, G. Au Coeur de Java. Campus Press. Eric Freeman, E. F.-C. (2005). Design Patterns Tte la premire. O'Reilly. Florian GRISONI, N. G. (s.d.). Rcupr sur http://www.cyber06.com/article/mvc.php Guy, R. (s.d.). Rcupr sur http://www.progx.org Meyer, B. (2000). Conception et Programmation orientes objet. Eyrolles. Pitman, N. (2006). UML 2 en concentr. O'Reilly. Rocques, P., & Valle, F. (2004). UML 2 En Action (De l'analyse des besoins la conception J2EE). Eyrolles. Roques, P. (2006). UML 2 en pratique. Eyrolles. Wikipedia. (s.d.). Rcupr sur Wikipedia: http://fr.wikipedia.org/
Page 104
Annexe :
LAPPROCHE ORIENTEE OBJET
Notion de classe
Tout dabord, introduisons la notion de classe. Une classe est un type de donnes abstrait, caractris. Par des proprits (attributs et mthodes) communes toute une famille dobjets et permettant de crer (instancier) des objets possdant ces proprits. Les autres concepts importants quil nous faut maintenant introduire sont lencapsulation, lhritage et lagrgation.
Encapsulation
Lencapsulation consiste masquer les dtails dimplmentation dun objet, en dfinissant une interface. Linterface est la vue externe dun objet, elle dfinit les services accessibles (offerts) aux utilisateurs de lobjet. Lencapsulation facilite lvolution dune application car elle stabilise lutilisation des objets: on peut modifier limplmentation des attributs dun objet sans modifier son interface, et donc la faon dont Lobjet est utilis. Lencapsulation garantit lintgrit des donnes, car elle permet dinterdire, ou de restreindre, laccs direct aux attributs des objets.
Hritage, Spcialisation, Gnralisation et polymorphisme

Lhritage est un mcanisme de transmission des proprits dune classe (ses attributs et mthodes) vers une sous-classe. Une classe peut tre spcialise en dautres classes, afin d y ajouter des caractristiques spcifiques ou den adapter certaines. Plusieurs classes peuvent tre gnralises en une classe qui les factorise, afin de regrouper les caractristiques communes dun ensemble de classes.
Page 105
Ainsi, la spcialisation et la gnralisation permettent de construire des hirarchies de classes. Lhritage peut tre simple ou multiple. Lhritage vite la duplication et encourage la rutilisation. Le polymorphisme reprsente la facult dune mthode pouvoir sappliquer des objets de classes diffrentes. Le polymorphisme augmente la gnricit, et donc la qualit, du code.
LAgrgation
Il sagit dune relation entre deux classes, spcifiant que les objets dune classe sont des composants de lautre classe. Une relation dagrgation permet donc de dfinir des objets composs dautres objets. Lagrgation permet donc dassembler des objets de base, afin de construire des objets plus complexes. (Meyer, 2000)
UML
Introduction
La description de la programmation par objets a fait ressortir ltendue du travail conceptuel ncessaire: dfinition des classes, de leurs relations, des attributs et mthodes, des interfaces etc. Pour programmer une application, il ne convient pas de se lancer tte baisse dans lcriture du code : Il faut dabord organiser ses ides, les documenter, puis organiser la ralisation en dfinissant les modules et tapes de la ralisation. Cest cette dmarche antrieure lcriture que lon appelle modlisation; son produit est un modle. Les spcifications fournies par la matrise douvrage en programmation imprative taient souvent floues: les articulations conceptuelles (structures de donnes, algorithmes de traitement) sexprimant dans le vocabulaire de linformatique, le modle devait souvent tre labor par celle-ci. Lapproche objet permet en principe la matrise douvrage des exprimer de faon prcise selon un vocabulaire qui, tout en transcrivant les besoins du mtier,
Page 106
pourra tre immdiatement compris par les informaticiens. En principe seulement, car la modlisation demande aux matrises douvrage une comptence, un professionnalisme qui ne sont pas aujourdhui rpandus.
UML en uvre
UML nest pas une mthode (i.e. une description normative des tapes de la modlisation): ses auteurs ont en effet estim quil ntait pas opportun de dfinir une mthode en raison de la diversit des cas particuliers. Ils ont prfr se borner dfinir un langage graphique qui permet de reprsenter, de communiquer les divers aspects dun systme dinformation (aux graphiques sont bien sr associs des textes qui expliquent leur contenu). UML est donc un mta-langage car il fournit les lments permettant de construire le modle qui, lui, sera le langage du projet. Il est impossible de donner une reprsentation graphique complte dun logiciel, ou de tout autre systme complexe, de mme quil est impossible de reprsenter entirement une statue ( trois dimensions) par des photographies ( deux dimensions). Mais il est possible de donner sur un tel systme des vues partielles, analogues chacune une photographie dune statue, et dont la juxtaposition donnera une ide utilisable en pratique sans risque derreur grave.
Les diagrammes dUML

UML 2.0 comporte ainsi treize types de diagrammes reprsentant autant de vues distinctes pour reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en deux grands groupes: Diagrammes structurels ou diagrammes statiques (UML Structure)
diagramme de classes (Class diagram) diagramme dobjets (Object diagram) diagramme de composants (Component diagram) diagramme de dploiement (Deployment diagram) diagramme de paquetages (Package diagram) diagramme de structures composites (Composite structure diagram)
Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)

diagramme de cas dutilisation (Use case diagram) diagramme dactivits (Activity diagram)
Page 107
diagramme dtats-transitions (State machine diagram) diagrammes dinteraction(Interactiondiagram) diagramme de squence (Sequence diagram) diagramme de communication (Communication diagram) diagramme global dinteraction (Interaction overview diagram) diagramme de temps (Timing diagram)
Ces diagrammes, dune utilit variable selon les cas, ne sont pas ncessairement tous produits loccasion dune modlisation. Les plus utiles pour la matrise douvrage sont les diagrammes dactivits, de cas dutilisation, de classes, dobjets, de squence et dtats-transitions. Les diagrammes de composants, de dploiement et de communication sont surtout utiles pour la matrise duvre qui ils permettent de formaliser les contraintes de la ralisation et la solution technique.
LE LANGAGE JAVA
Java est la fois un langage de programmation et un environnement dexcution. Le langage Java a la particularit principale d'tre portable sur plusieurs systmes dexploitation. C'est la plateforme qui garantit la portabilit des applications dveloppes en Java. (Cornell) Lors de la cration du langage Java, il avait t dcid que ce langage devait rpondre 5 objectifs : 1. utiliser une mthode oriente objet, 2. permettre un mme programme d'tre excut sur plusieurs systmes d'exploitation diffrents, 3. pouvoir utiliser de manire native les rseaux informatiques, 4. pouvoir excuter du code distant de manire sre, 5. tre facile utiliser et possder les points forts des langages de programmation orients objet comme le C++. Le systme Java est bas sur le langage Java, la machine virtuelle java, et l'API JAVA (ces deux derniers composants forment l'environnement d'excution, ou JRE, pour Java Runtime Environment).
Page 108
DIFFERENCE ENTRE LA RCHITECTURE 3-TIERS ET LE MODELE MVC

Les noms d'architectures MVC et 3-Tiers sont trs couramment utiliss dans les cours de gnie logiciel. Il est facile de s'emmler les pinceaux car ces deux pratiques sont la fois diffrentes et similaires.
L'architecture MVC
Model View Controller (Modle Vue Contrleur) est souvent dcrit comme un simple design pattern (motif de conception) mais c'est plus un architectural pattern (motif d'architecture) qui donne le ton la forme gnrale d'une solution logiciel plutt qu' une partie restreinte. Les trois parties du pattern MVC sont les suivantes :
1. Model : Le modle dfini les donnes de l'application et les mthodes d'accs. Tout les traitements sont effectus dans cette couche. 2. View : La vue prend les informations en provenance du modle et les prsente l'utilisateur. 3. Controller : Le contrleur rpond aux vnements de l'utilisateur et commande les actions sur le modle. Cela peut entrainer une mise jour de la vue.
L'architecture 3-Tiers
L'architecture 3-Tiers spare, tout comme MVC, l'application en trois parties bien distinctes :
1. User interface : La partie prsentation de l'application. 2. Buisness logic : La couche mtier qui s'occupe du traitement de l'information. 3. Data access : La partie accs et stockage des donnes
Architecture MVC ou 3-Tiers ?

La diffrence fondamentale se trouve dans le fait que l'architecture 3-Tiers spare la couche Buisness logic (couche mtier) de la couche Data access (accs aux donnes). Pour qu'une application MVC soit une vraie application 3-Tiers il faut lui ajouter une couche d'abstraction d'accs aux donnes de type DAO (Data Access Object).
Page 109
Inversement pour qu'une application 3-Tiers respecte MVC il faut lui ajouter une couche de contrle entre User interface et Buisness logic. Loin d'tre antagonistes, ces deux pratiques se combinent et sont la fondation de la plupart des frameworks de cration d'applications Web.
Page 110

2tup

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2tup

Uploaded by

Copyright:

Available Formats

Universit Abou Bekr Belkaid de Tlemcen

Facult des Sciences de lIngnieur Dpartement dInformatique

Suivie des enseignements du LMD par application de la mthode 2TUP

Kazi Aouel Bassim et Rostane Zakaria

Mr. ABDERRAHIM Amine Mr. CHIKH Azzeddine Mr. CHOUITI S-Mohammed

TABLE DES MATIERES

La complexit croissante des systmes informatiques a conduit les concepteurs

3. COMPARAISON ENTRES LES DIFFERENTES APPROCHES

4. PRESENTATION DE LAPPLICATION A RALISER

1. DEFINITION DUN PROC ESSUS DE DEVELOPPEMENT LOGICIEL

Un processus dfinit une squence dtapes, en partie ordonnes, qui concourent

On dit de la mthode UP quelle est gnrique c..d. quelle dfinit un certain

Figure : Le systme dinformation soumis deux types de contraintes

Figure : Le processus de dveloppement en Y

4. UN PROCESSUS DE MODELISATION AVEC UML

Le processus 2TUP sappuie sur UML tout au long du cycle de dveloppement,

Recueil des besoins fonctionnels

Organisation des dpartements : _____________________________________________________________________

Organisation du parcours de formation dans le systme LMD: _____________________________________________________________________

Identification des acteurs

Identification des messages

Dterminer les cas dutilisations

Utilisation doutils de gnration de diagrammes UML :

Identification des cas dutilisation :

Grer les promotions

Suivre les promotions

Grer les tudiants

Maintenir les notes

Consulter les notes

Reoit : consulter son relev de notes.

Scolarit Etudiant, Enseignant

Diagramme des cas dutilisation

Description prliminaire des cas dutilisations

option, crer les UE, modifier les UE

Grer les promotions :

Etablir les emplois du temps :

module et un enseignant, modifier ou annuler lemploi du temps.

Grer les tudiants :

universitaire, mettre jour le dossier.

Grer les profils :

droits daccs, modifier le profil, crer un mot de passe.

Maintenir les notes des tudiants :

Consulter lemploi du temps :

Consulter les notes :

Description dtaille des cas dutilisations

Organiser les DPARTEMENTS:

Descriptions des ENCHANEMENTS: ______________________________________________________________

Enchanement (b) : Crer un tronc commun

Enchanement (c) : Crer les spcialits/options

Enchanement (d) : valider un domaine en construction

Si le domaine existe dj dclencher : [Exception1 : DomaineExistant]

Enchanement (f) : Modifier un domaine en construction ou valid

Enchanement (g) : Supprimer un domaine

Enchanement (h) : Supprimer une UE

Ce cas dutilisation se termine lorsque le chef de dpartement a valid un domaine.

Etablir les PROMOTIONS:

Descriptions des ENCHANEMENTS: ______________________________________________________________

Enchanement (b) : Rattacher un domaine

Enchanement (c) : Rattacher les tudiants

Enchanement (f) : fixer les dates dexamens

Enchanement (g) : valider une promotion en construction

Enchanement (i) : Supprimer une promotion

Ce cas dutilisation se termine lorsque le chef de dpartement a valid une promotion.