Application de La Méthodologie 2TUP À La Gestion Des Enseignements

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
Page 3
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 4
R sum :
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 5
Table des matires
TABLE DES MATIRES........................................................................................................................................... 5
INTRODUCTION................................................................................................................................................... 7
1. LE CONTEXTE DE TRAVAIL...................................................................................................................................7
2. OBJECTIFS.......................................................................................................................................................7
3. COMPARAISON ENTRES LES DIFFE RENTES APPROCHES............................................................................................8
4. PRE SENTATION DE LAPPLICATION A RE ALISER...................................................................................................9
LA MTHODE 2TUP............................................................................................................................................ 10
1. DE FINITION DUN PROCESSUS DE DE VELOPPEMENT LOGICIEL.............................................................................11

2. LE PROCESSUS UNIFIE .....................................................................................................................................11
3. LE PROCESSUS 2TUP........................................................................................................................................12
4. UN PROCESSUS DE MODE LISATION AVEC UML.....................................................................................................14
CONCEPTION DU LOGICIEL................................................................................................................................. 16
1. ETUDE PRE LIMINAIRE..................................................................................................................................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
2. 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
3. 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
4. CONCEPTION................................................................................................................................................79
4.1. Architecture de lapplication....................................................................................................................79
4.2. Les Design Patterns..................................................................................................................................80
5. CODAGE.........................................................................................................................................................89
5.1. La gnration de code avec NetBeans 5.5:.............................................................................................89
5.2. Lapplication JStudent ........................................................................................................................89
Page 6
BILAN DE LA MTHODE.................................................................................................................................... 100
CONCLUSION GNRALE................................................................................................................................... 103
BIBLIOGRAPHIE................................................................................................................................................ 104
ANNEXE :......................................................................................................................................................... 105
LAPPROCHE ORIENTE OBJET.................................................................................................................................105

UML..................................................................................................................................................................... 106
LE LANGAGE JAVA...................................................................................................................................................108
Diffrence entre larchitecture 3-tiers et le modle MVC............................................................................108
Page 7
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 8
3. COMPARAISON ENTRES LES DIFFE RENTES APPROCHES
Mod lisation
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.
Conduit d projt
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 9
4. PRE SENTATION DE LAPPLICATION A RE ALISER
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 10
La m thod 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 11
1. DE FINITION DUN PROCESSUS DE DE VELOPPEMENT
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 UNIFIE
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 12
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.
Page 13
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.
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.
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.
La conception prliminaire.
La conception dtaille.
Le codage.
Lintgration.
Page 14
Figure : Le processus de dveloppement en Y
4. UN PROCESSUS DE MODE LISATION 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)
Page 15
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.
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 16
Concption du logicil
1. ETUDE PRE LIMINAIRE
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. Pr sntation du projt a r alisr

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. Rcuil ds bsoins fonctionnls

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 17
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 :
_____________________________________________________________________
Page 18
La progression du premier au second semestre dune mme anne universitaire est de
droit pour tout tudiant inscrit dans le mme parcours.
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 tchniqus

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 19
Page 20
1.4. Idntification ds acturs
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 21
1.5. Idntification ds mssags
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 22
1.6. Mod lisation du contxt
A partir ds informations obtnus lors ds dux pr c dnts taps, nous
allons mod lisr l contxt d notr 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
Chef de dpartement 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
Scolarit Crer/modifier les fiches des tudiants
Affecter les notes des tudiants
Lapplication doit permettre lenseignant de :

Enseignant Sauthentifier
Affecter les notes des tudiants pour son module
Lapplication doit permettre ltudiant de :
Sauthentifier
Etudiant Consulter son relev de notes
Consulter son emploi du temps
Consulter ses modules en dettes
Lapplication doit permettre ladministrateur de :

Sauthentifier
Administrateur Crer les profils utilisateurs
Donner des droits daccs
Page 23
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. D trminr ls 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
Peut tre tlcharg ladresse suivante : http://argouml.tigris.org/
2
Peut tre tlcharg ladresse suivante : http://bouml.free.fr/
3
Le site de NetBeans : http://www.netbeans.org/
Page 24
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,
Organiser un dpartement Chef de dpartement Crer les UE et les Modules.
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,
Suivre les promotions Chef de dpartement passer au prochain semestre,
orienter les tudiants vers les spcialits,
Reoit : liste des tudiants endetts,
Liste des tudiants non endetts.
Grer les tudiants Scolarit Emet : Crer/modifier les fiches des

tudiants.
Emet : Affecter les notes aux tudiants,
grer les rattrapages,
Maintenir les notes Scolarit, Enseignant grer les modules en dettes.
Reoit : relev de notes
Page 25
Consulter les notes Etudiant Reoit : consulter son relev de notes.
Grer les emplois du temps Scolarit Emet : Crer/modifier les emplois du temps
Consulter les emplois du Etudiant, Enseignant Reoit : consulter les emplois du temps.
temps
Emet : Cration, modification, suppression
Grer les profils Administrateur de profils.
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 26
Page 27
2.2. Dscription pr liminair ds 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 28
2.3. Dscription d taill ds 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 29
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
Page 30
Le chef de dpartement valide la cration.
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.
Page 31
[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.
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 :
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
Page 32
Le chef de dpartement slectionne tous les tudiants faisant partie de la promotion.
Si ltudiant appartient dj une promotion dclencher : [Exception2 :
EtudiantDejaAffecte]
Enchanement (f) : fixer les dates dexamens
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 33
Suivre une PROMOTION:
______________________________________________________________
Titre : Suivre une promotion
But : permettre le suivi du cursus des tudiants.
Rsum : commencer les tudes, affecter des enseignants chaque semestre

______________________________________________________________
Prconditions :
2- Au moins un enseignant existe dans la base.
3- Au moins un domaine existe.
4- Au moins une promotion existe.
Scnario nominal :
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 34
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 les
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.
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 35
Diagramme dactivits reprsentant lenchainement des tapes dune promotion
Page 36
Etablir les emplois du TEMPS:
______________________________________________________________
Titre : Etablir les emploies du temps
But : crer des emplois du temps.
Rsum : crer un nouvel emploi du temps, en modifier un.

______________________________________________________________
Prconditions :
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 : [Exception1 :
moduleErreur]
Il affecte un enseignant cette plage horaire.
Page 37
Si lenseignant est dj pris pour cette plage alors dclencher : [Exception2 :
enseignantErreur]
Enchanement (c) : Valider un emploi du temps en construction
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: _____________________________________________________________
Page 38
Diagramme dactivits
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 39
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 40
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 41
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.

_______________________________________________________
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.
Page 42
Exceptions :
[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 confirmation 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 43
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 44
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 45
2.4. Structuration ds cas dutilisations dans ds packags
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 Chef de dpartement

Gestion des promotions
Suivre les promotions Chef de dpartement
Maintenir les notes Scolarit, Enseignant

Gestion des notes
Consulter les notes Etudiant
Grer les emplois du temps Scolarit

Gestion des emplois du temps
Consulter les emplois du Etudiant, Enseignant

temps
Page 46
Grer les profils Administrateur Gestion des profils
2.5. Idntification ds classs candidats

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 47
Page 48
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 49
Etablir les promotions :
Promotion, Domaine, Enseignant, Etudiant, Tronc_Commun, Specialite.
Diagramme des classes participantes Etablir les promotions
Page 50
Suivre les promotions :
Promotion, Semestre, Domaine, Enseignant, Etudiant.
Diagramme des classes participantes Suivre les promotions
Page 51
Etablir les emplois du temps :
Emploi du temps, Plage horaire, UE, Module, Enseignant.
Diagramme des classes participantes Etablir les emplois du temps
Page 52
Maintenir les notes tudiants :
Fiche notes, Note, Module, Etudiant.
Diagramme des classes participantes Maintenir les notes
Page 53
3. ANALYSE
3.1. D coupag n cat goris
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 54
Dcoupage en catgories
3.2. D pndancs ntr cat goris
Classe Promotion :
Page 55
Associations de la classe Promotion
Classe Fiche notes :
Page 56
Associations de la classe Fiche Notes
Classe Emploi du temps :
Page 57
Associations de la classe Emploi du temps
Page 58
3.3. Diagramm d packags danalys
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 59
3.4. D vloppmnt du mod l statiqu
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.
Cat gori Etudes :

Voici le diagramme de classe de la catgorie Etudes.
Diagramme de classe
Page 60
Page 61
Cat gori Promotions :
Voici le diagramme de classe de la catgorie Promotion et aussi Etudiants.
Diagramme de classe de la catgorie Promotion
Page 62
Et voici les oprations/attributs de la classe Promotion.
Classe Promotion (attributs/oprations)
Page 63
Et voici les oprations/attributs de la classe Semestre.
Classe Semestre (attributs/oprations)
Page 64
Cat gori 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.
Page 65
Classes ReleveNotes et Note (attributs/oprations)
Cat gori Enseignants :

Voici le diagramme de classe de la catgorie Enseignants.
Diagramme de classe
Page 66
Et voici les oprations/attributs de la classe Enseignant.
Classe Enseignant (attributs/oprations)
Cat gori Etudiant :
Classe Etudiant (attributs/oprations)
Cat gori Emploi du temps :

Voici le diagramme de catgories de la classe Emploi du temps.
Page 67
Associations de la catgorie Emploi du temps
3.5. D vloppmnt du mod l dynamiqu

Le dveloppement du modle dynamique constitue la troisime activit de ltape
danalyse. Il sagit dune activit itrative, fortement couple avec la modlisation
statique.
Idntification ds sc narios :
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 ;
Page 68
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.
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.
Page 69
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.

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.
Page 70
Diagramme de squences du scnario crer un nouveau domaine
OL_N2 : crer des UE pour un Tronc_Commun ou Specialite.
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.

o Un objet Domaine cre au cours du scnario.
o Un objet Tronc_Commun/ Specialite cre au cours du scnario.
o Un objet UE cre au cours du scnario.
o Un objet Module cre au cours du scnario.
Page 71
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 72
SCNARIOS DE Etablir les promotions :
Parmi tous les scnarios possibles pour le cas dutilisation Etablir les
promotions (EP) nous avons choisi les suivants :

Scnarios nominaux :
EP _N1 : crer une nouvelle promotion.
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.
EP _E1 :
EP _E2 :

Scnarios nominaux :
EP_1 : crer une nouvelle promotion.

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.
o Une Promotion cre au cours du scnario.
Page 73
o Un multi-objet reprsentant les Modules de la spcialit ou du
tronc_commun cre cours du scnario.
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.
Page 74
Diagramme de squences du scnario crer une nouvelle promotion
EP _A1 : modifier une promotion par ajout dun enseignant.
Page 75
Il slectionne une promotion.
Le chef de dpartement ajoute un enseignant la promotion.

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.
Il slectionne un module.
Page 76
Il attribue le module un enseignant.

o Un objet Enseignant qui va est affect la promotion.
o 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.
Page 77
Il slectionne un enseignant faisant parti de la promotion.
Il dsaffecte lenseignant de son module.

o Un objet Enseignant qui va tre affect la promotion.
o 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.
Page 78
Il slectionne un tudiant.
Il dsaffecte ltudiant de la promotion.

o Un objet Etudiant qui va tre affect la promotion.
Diagramme de squence du scnario modifier une promotion ajout/enlvement dun tudiant
Page 79
SCNARIOS DE Etablir les emplois du temps :

Scnarios nominaux :
EET_1 : crer un nouvel emploi du temps.
Il choisit la promotion.
Il choisit le semestre.
Pour chaque plage horaire slectionne, il affecte un module.

o Un emploi du temps cre au cours du scnario.
o Une Promotion.
o Un Module.
o Une plage horaire cre au cours du scnario.
Page 80
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 :

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.
o Un acteur Scolarit.
Page 81
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 :

Scnarios nominaux :
MN _N1 : crer une fiche de notes.
MN _N2 : affecter les notes pour un tudiant.
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.
MN _E1 :
MN _E2 :

Scnarios nominaux :
MN _N1 : crer une fiche de notes.
Elle choisit une promotion.
Elle slectionne un tudiant.
Elle cre la fiche de notes.
o Une Fiche notes.
Page 82
Diagramme de squence du scnario crer une fiche de notes
MN _N2 : affecter les notes pour un tudiant.
Elle choisit une promotion.
Elle slectionne un tudiant.
Pour chaque module, elle affecte une note (examen, TD, TP, Devoir).
Le calcul de la moyenne se fait automatiquement.
o Un objet Promotion cre au cours du scnario.
o Un objet Note.
Page 83
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 84
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 85
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.
Page 86
Etudes termines : cet tat survient aprs quun tudiant ait termin ses
tudes suprieures.
Diagramme dtats de la classe Etudiant
Page 87
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. Architctur d 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 88
Architecture 3-Tiers
4.2. Ls Dsign Pattrns

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 89
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 90
La Classe Promotion :
Diagramme dtats de la classe Promotion
Page 91
La classe Promotion dlgue la gestion de ses tats linterface EtatPromotion et
ses diffrentes implmentations (EtatEnCreation, EtatValide, EtatEnCours,
EtatTerminee)
Page 92
La classe Promotion et ses diffrents tats
La Classe Etudiant :
Page 93
Design Pattern Etat de la classe Etudiant
Page 94
La classe Etudiant dlgue la gestion de ses tats linterface EtatEtudiant
Page 95
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 96
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.
Page 97
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
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 98
Page 99
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 g n ration d cod avc NtBans 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 JStudnt
Page 100
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 101
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 102
La classe Domaine ( gauche les Attributs et les Mthodes)
Page 103
La classe Etudiant ( gauche les Attributs et les Mthodes)
Page 104
La couche Prsentation :
Voici quelques figures reprsentants linterface du logiciel :
La fentre principale
Page 105
Fiche de cration dun nouvel tudiant
Page 106
Fiche de cration dune nouvelle promotion
Page 107
Fiche de consultation dune promotion
Page 108
Fiche de relev de notes
Page 109
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 110
Bilan d la m thod
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.
Etud du cas : Gstion ds 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.
Idntification du bsoin :
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 111
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 .
Dscription d taill 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
Idntification ds classs candidats :
Page 112
A la suite de cette description dtaille, nous pouvons en dduire dj deux
classes : Bloc, Salle.
Concr tmnt dans l cod :

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.
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 113
Conclusion g n ral
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 114
Bibliographi
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 115
Annx :
LAPPROCHE ORIENTE 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 116
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.
Page 117
Lapproche objet permet en principe la matrise douvrage des exprimer de
faon prcise selon un vocabulaire qui, tout en transcrivant les besoins du mtier,
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)
Page 118
diagramme de cas dutilisation (Use case diagram)
diagramme dactivits (Activity diagram)
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++.
Page 119
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).
DIFFRENCE ENTRE LARCHITECTURE 3-TIERS ET LE

MODLE 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 ?
Page 120
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).
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 121

Application de La Méthodologie 2TUP À La Gestion Des Enseignements

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Application de La Méthodologie 2TUP À La Gestion Des Enseignements

Transféré par

Droits d'auteur :

Formats disponibles

Universit Abou Bekr Belkaid de Tlemcen

Facult des Sciences de lIngnieur

Kazi Aouel Bassim et Rostane Zakaria

Encadrs par Mr. Ziani Cherif Salim

Prsent le 08 novembre 2007

Mr. ABDERRAHIM Amine

A la mmoire de mes oncles Lotfi et Amine, que leurs mes

On remercie Monsieur Ziani Cherif Salim pour laide quil nous

1. Introduction : nous parlerons dans ce chapitre des objectifs que nous

2. La mthode 2TUP : ce chapitre contient les dfinitions des

3. Conception du logiciel : cest ici que nous allons appliquer la

4. Bilan de la mthode 2TUP : nous allons donner un bref aperu de

TABLE DES MATIRES........................................................................................................................................... 5

1. DE FINITION DUN PROCESSUS DE DE VELOPPEMENT LOGICIEL.............................................................................11

1. ETUDE PRE LIMINAIRE..................................................................................................................................16

CONCLUSION GNRALE................................................................................................................................... 103

ANNEXE :......................................................................................................................................................... 105

LAPPROCHE ORIENTE OBJET.................................................................................................................................105

La complexit croissante des systmes informatiques a conduit les concepteurs

Par le pass, le modle Entit-Relation reprsentait une grande partie des

Litratif sest ensuite impos, parce quil rduit la complexit de ralisation

On constate aujourdhui, lmergence dune nouvelle approche : les

Devant le nombre de mthodes disponibles, le choix parmi elles devient difficile,

Nous pouvons citer ce propos les mthodes de dveloppement objet suivantes :

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

itrative et incrmentale : la mthode est itrative dans le sens o elle

centre sur larchitecture : les modles dfinit tout au long du processus de

pilote par les risques : en dfinissant des priorits pour chaque

1. Pretude(Inception) : cest ici quon value la valeur ajoute du

2. Elaboration : sert confirmer ladquation du systme aux besoins des

4. Transition : dployer le systme sur des sites oprationnels.

Chaque phase est elle-mme dcompose squentiellement en itrations limites

Ces activits de dveloppement sont dfinies par 6 disciplines fondamentales qui

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

Cest dans ce cadre que la socit Valtech a cre la mthode 2TUP.

Figure : Le systme dinformation soumis deux types de contraintes

La branche gauche (fonctionnelle) : capitalise la connaissance du mtier de

La branche droite (architecture technique) : capitalise un savoir-faire technique. Elle

La branche du milieu : lissue des volutions du modle fonctionnel et de

4. UN PROCESSUS DE MODE LISATION AVEC UML

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

Unified Modeling Language : UML se dfinit comme un langage de modlisation

Le diagramme des cas dutilisation : reprsente la structure des fonctionnalits

Le diagramme dactivits : reprsente les rgles denchanement des activits et

Le diagramme de packages : prsent depuis UML 2.0, ce diagramme modlise

Le diagramme de classes : srement lun des diagrammes les plus importants

Le diagramme de squence : reprsente les changes de messages entre objets,

1. ETUDE PRE LIMINAIRE

1.1. Pr sntation du projt a r alisr

1.2. Rcuil ds bsoins fonctionnls

Une universit se compose de plusieurs dpartements (informatique, physique, maths,

- Le premier palier doit tre compos au plus de 2 semestres.

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

Pour chaque semestre denseignement, deux sessions de contrle sont organises.la

La progression de la premire la deuxime anne de la Licence, est de droit si ltudiant

Lacquisition du diplme de Licence est effective si ltudiant a valid les 6 semestres du

Gestion des promotions :

Gestion des tudiants :

1.3. Choix tchniqus

La modlisation avec UML.

Remarque : la branche droite qui dsigne ltude de larchitecture technique va tre

Les acteurs du systme identifis dans un premier temps sont :