Vers Une Solution Intégrée de Gestion de La Scolarité Des Établissements de L'enseignement Traditionnel

Ddicace
Je ddie ce travail :
mes chers parents, ma grande mre
Je nose pas imaginer une expression qui puisse rsumer ma gratitude

envers votre soutient et encouragement. Aucune ddicace ne saurait exprimer
mon amour et mon respect pour vous.
Que ce travail soit pour vous un tmoignage de ma vive reconnaissance et de

mon amour filial.
mon cher frre Nouaman et

Mes chres surs Siham, Hanane, et Bassma
Avec tout mon amour et mon affection, je vous souhaite une vie pleine
de bonheur et de russite et je vous remercie pour votre soutien durant toutes
les priodes difficiles.
mes amis, lEMI,
tous ceux qui maiment
Sachez que vous mtes trs chres et que je vous suis trs reconnaissant
pour tout lamour et le soutien dont vous faites preuve mon gard.
Je vous remercie du fond du cur.
Anouar Mechti
Projet de fin dtudes 2011/2012

Ddicace
Jai une dette particulire envers ma chre mre dont le soutien et la
sagesse mont guid depuis ma naissance et me
guideront toujours.
mon cher pre
Sans qui je ne serais jamais l o jen suis.
toute ma famille,
mes trs chers amis de lEMI,
Pour tout le soutien que vous mavez offert je vous dis MERCI.
tous ceux qui maiment.
Otman IGHOULASSEN

Remerciements
Nous remercions tout dabord Dieu tout puissant de nous avoir permis de mener
terme ce projet qui prsente pour nous le point de dpart de notre carrire.
Il nous est agrable dexprimer notre reconnaissance auprs de toutes les

personnes, dont lintervention au cours de ce projet, a favoris son aboutissement.
Ainsi, nous tenons remercier nos encadrants Mr. Khalil ATALLA, Mr.
Abdelfattah Idri et Mr. Abdelhay MRABET pour leurs directives prcieuses et leurs
conseils pertinents qui ont t dun appui considrable au cours de ce projet.
Nous remercions galement Mlle Awatif BRIGUI laurat de lEMI de nous

avoir propos ce projet et pour tous les conseils fructueux quelle na cess de nous
prodiguer. Nous tenons remercier aussi toute lquipe de Visual Soft pour leur accueil
chaleureux.
La disponibilit, la gentillesse et la gnrosit de M. Abderrahim HASBI dont les

prcieux conseils et les orientations nous ont t d'un grand secours tout au long de ce
stage. Qu'elle trouve ici, l'expression de notre profonde gratitude et de nos sincres
remerciements.
Nous saisissons aussi loccasion pour remercier tous les membres du jury, M.
Abdellah EL HADRI et M. Karim BOUZOUBAA qui nous ont fait lhonneur
daccepter de juger ce travail.
Nos remerciements sadressent galement tout le corps professoral de lcole

Mohammadia dIngnieurs, pour la qualit de son enseignement ainsi que sa disponibilit
tout au long de ces trois annes de formation.
Que tous ceux et celles qui ont contribu de prs ou de loin laccomplissement de
ce travail trouvent lexpression de nos remerciements les plus chaleureux.

Rsum
Notre projet de fin dtudes effectu VisualSoft consistait en lanalyse, la
conception et la ralisation des modules de gestion des tudiants, des enseignants et des
tablissements de lenseignement traditionnel marocain. Ces modules font partie, parmi
dautres, du grand projet caractre national, lanc par le ministre des Habous et des
affaires islamiques pour la mise en uvre dune solution intgre de gestion de la scolarit
dans les niveaux prscolaire, primaire, collgial, secondaire et terminal de lenseignement
traditionnel marocain.
Pour mener bien notre travail, nous avons dcoup le projet en quatre tapes. Au
dbut, nous avons dfini le contexte gnral du projet, et on a adopt comme dmarche de
conduite de projet, la mthode RUP (Rational Unified Process), qui est une mthode de
dveloppement logicielle itrative base sur le langage UML. Ensuite, on est pass la
phase de lanalyse et la spcification des besoins. Dans ltape suivante, nous avons abord
la phase de conception pour bien structurer la couche mtier de notre application. Enfin, la
dernire tape tait la ralisation et la mise en uvre des modules de notre systme laide
des Frameworks techniques Java/JEE sous lenvironnement de dveloppement Netbeans.
Le prsent rapport synthtise le travail que nous avons ralis durant la priode de
notre stage, et se compose de quatre chapitres qui retracent les diffrentes tapes de notre
projet.

Abstract
Our graduation internship performed at VisualSoft was about the analysis, design
and implementation of the management modules of students, teachers and institutions of
the Moroccan traditional teaching. These modules are part of the big national project
launched by the Ministry of Endowments and Islamic Affairs for the implementation of an
integrated solution for the schooling management in preschool, primary, secondary and
terminal levels of the Moroccan traditional education.
Initially, we defined the general context of the project, and we adopted the Rational
Unified Process (RUP) methodology as an approach to project management, which is an
iterative software development methodology based on UML. Then we went to the phase of
analysis and specification requirements. In the next step, we addressed the design phase to
properly structure the business layer of our application. The final step of our project was
the implementation of the modules of our system using Java/JEE technical frameworks
under the Netbeans development tool.
This report presents the work that we perform during our internship, and consist of
five chapters that trace the various stages of our project.

.VisualSoft

.

.UML
.Java/JEE

Liste des abrviations
Abrviation Signification
AJAX Asynchronous JavaScript + XML
API Application Programming Interface
CRUD Create Retrieve Update Delete
DAO Data Access Object
DET Dpartement de lenseignement traditionnel
DR Dlgation rgionale
DP Dlgation provinciale
EET tablissement de lenseignement traditionnel
HTML HyperText Mark-Up Language
IDE Integrated Development Environment
IHM Interface Homme Machine
JDBC Java Database Connectivity
JEE Java Entreprise Edition
JPQL Java Persistance Query Language
JSF Java Server Faces
JSTL Java Standard Tag Library
MHAI Ministre des Habous et des Affaires Islamiques
MVC Model View Controller
ORM Object-Relational Mapping
POJO Plain Old Java Object
RUP Rational Unified Process
SGBD Systme de Gestion de Base de Donnes
SQL Structured Query Language
UML Unified Modeling Language
XML Extensible Markup Language

Table des figures
Figure I-1 : Organigramme dIT Group ................................................................................ 4
Figure I-2 : Organigramme gnral de la Direction de lEnseignement Traditionnel : ........ 6
Figure I-3 Schma de l'enchainement des activits dans RUP .............................................. 9
Figure II-1: Les acteurs du systme ..................................................................................... 15
Figure II-2: Diagramme de contexte ................................................................................... 16
Figure II-3: digramme de packages des use case ................................................................ 17
Figure II-4: Cas dutilisation inscrire lve ................................................................... 18
Figure II-5: Cas dutilisation Grer tablissement ........................................................ 20
Figure II-6: Cas d'utilisation "gestion des cycles d'enseignement" .................................... 22
Figure II-7: Cas d'utilisation "gestion du personnel administratif et pdagogique" ............ 24
Figure II-8: Diagramme d'activit "inscrire lve".............................................................. 26
Figure II-9: Diagramme de squence "ajouter tablissement" ............................................ 27
Figure II-10: Diagramme de squence "inscrire lve"....................................................... 28
Figure II-11: Diagramme de squence "ajouter employ" .................................................. 29
Figure III-1 Diagramme de paquetage systme ................................................................... 32
Figure III-2: Diagramme d'interaction d'ajout d'un lve .................................................... 34
Figure III-3: Diagramme de classes des informations personnelles de l'lve .................... 35
Figure III-4: Diagramme d'interaction d'inscription d'un lve ........................................... 36
Figure III-5: Diagramme de classes d'inscription ................................................................ 37
Figure III-6 : Diagramme de classes de parcours scolaire................................................... 38
Figure III-7 : Diagramme de classes du package "gestion des lves et tudiants" ............ 39
Figure III-8: Diagramme de classes de gestion des cycles, niveaux et classes ................... 40
Figure III-9 : Diagramme de classes des locaux.................................................................. 41
Figure III-10: Diagramme de classes des employs et du personnel .................................. 42
Figure III-11: Diagramme de classes du package "gestion des tablissements" ................. 43
Figure IV-1: Larchitecture technique de l'application ...................................................... 48
Figure IV-2: Interface de l'application: authentification ..................................................... 50
Figure IV-3: Interface de l'application: Menu principal ...................................................... 51
Figure IV-4: Interface de l'application: liste des lves ajouts .......................................... 52
Figure IV-5: Interface de l'application: formulaire d'ajout d'un lve ................................. 53
Figure IV-6: Interface de l'application: afficher les informations un lve ......................... 53
Figure IV-7: Interface de l'application: Modifier un lve .................................................. 54

Liste des tableaux
Tableau I-1: Les quatre phases du processus RUP .............................................................. 10
Tableau II-1: Description du cas dutilisation inscrire lve ......................................... 19
Tableau II-2: Description textuelle du cas dutilisation Grer tablissement ............... 21
Tableau II-3: Description textuelle Grer cycle denseignement .................................. 23
Tableau II-4: Description textuelle du cas dutilisation gestion employs ................... 25

TABLE DES MATIRES
Table des matires

Introduction gnrale .......................................................................................................... 1
I. Chapitre 1 : Contexte Gnral du Projet ................................................................. 3

1. Prsentation de lorganisme daccueil .......................................................................... 3
2. Prsentation gnrale du projet ................................................................................... 5
2.1. Contexte organisationnel .......................................................................................................... 5
2.2. Structure et statistiques ............................................................................................................ 7
2.3. Objectifs du projet ..................................................................................................................... 7
2.4. Mission du stage ........................................................................................................................ 8
3. Conduite du projet : Mthode RUP (Rational Unified Process) ...................................... 8

3.1. Motivation ................................................................................................................................. 8
3.2. Enchanement dactivits essentielles dans RUP ....................................................................... 9
3.3. Les quatre phases du processus RUP ........................................................................................ 9
4. Conclusion................................................................................................................. 10
II. Chapitre 2 : tude fonctionnelle........................................................................... 12

1. Spcification des besoins ........................................................................................... 12
1.1. SPECIFICATION des besoins fonctionnels ................................................................................ 12
1.2. Spcification des besoins techniques ...................................................................................... 13
2. Analyse du contexte .................................................................................................. 14

2.1. Les rles ................................................................................................................................... 14
2.2. Diagramme de contexte .......................................................................................................... 16
2.3. Diagramme des cas dutilisation .............................................................................................. 16
2.4. Digrammes dactivits ............................................................................................................. 25
2.5. Digrammes de squences ........................................................................................................ 27
3. Conclusion................................................................................................................. 30
III. Chapitre 3 : Conception ....................................................................................... 32

1. Diagramme de paquetage .......................................................................................... 32
2. Le package Gestion des lves et tudiants .......................................................... 33
2.1. Diagramme dinteraction des informations personnelles de llve ....................................... 33
2.2. Diagramme de classes des informations personnelles de l'lve ........................................... 35
2.3. Diagramme dinteraction dinscription .................................................................................... 36
2.4. Digramme de classes d'inscription .......................................................................................... 37
2.5. Diagramme de classes de parcours scolaire ............................................................................ 38
3. Le package Gestion des tablissements ................................................................ 40

3.1. Gestion des cycles, niveaux, et classes Dun tablissement .................................................... 40
3.2. La description des locaux ......................................................................................................... 41
3.3. Dfinition des postes des cardes administratif, enseignants, et agents ................................. 42
3.4. Diagramme Global ................................................................................................................... 42
4. Conclusion................................................................................................................. 44

TABLE DES MATIRES
IV. chapitre 4 : Mise en oeuvre.............................................................................. 46

1. Le design pattern MVC ............................................................................................... 46
2. Java Enterprise Edition............................................................................................... 46
3. Outils et Frameworks utiliss ..................................................................................... 46
3.1. Le framework JSF 2.0 ............................................................................................................... 46
3.2. Enterprise Java Beans (ejb 3) ................................................................................................... 47
3.3. JPA 2.0 ..................................................................................................................................... 47
3.4. Le Framework EclipseLink ........................................................................................................ 47
3.5. Oracle 10g ................................................................................................................................ 48
4. Architecture technique .............................................................................................. 48

5. Dmarche de dveloppement .................................................................................... 49
6. Interfaces de lapplication .......................................................................................... 50
6.1. Authentification ....................................................................................................................... 50
6.2. Gestion des tudiants .............................................................................................................. 52
7. Conclusion................................................................................................................. 54
Conclusion gnrale .......................................................................................................... 55
Bibliographie ..................................................................................................................... 56
Webographie..................................................................................................................... 56
Annexe A : Outils utiliss ................................................................................................... 57
Annexe B : Le cycle de vie phases multiples dune page JSF .............................................. 59
Annexe C : Les maquettes .................................................................................................. 62
Annexe D : Diagramme de classes global ............................................................................ 64

Introduction gnrale:
Introduction gnrale
La stratgie du dveloppement conomique et social qui est adopte par le
gouvernement marocain depuis le dbut de ce troisime millnaire s'articule autour de
plusieurs axes, notamment la rforme et la modernisation de ladministration publique, et
cela travers la promotion de lutilisation des technologies de linformation et de la
communication dans les diffrents dpartements ministriels.
Dans ce cadre, le ministre des Habous et des affaires islamiques a pass

VisualSoft, notre socit daccueil, un projet caractre national, pour la mise en uvre
dune solution intgre de gestion de la scolarit dans les niveaux prscolaire, primaire,
collgial, secondaire et terminal de lenseignement traditionnel marocain (SIGES).
Notre mission dans ce stage au sein de VisualSoft, consiste en lanalyse, la

conception et la ralisation des modules de gestion des tablissements, des lves et des
enseignants.
Le prsent rapport se compose de quatre chapitres. Le premier dfinit le contexte

gnral du projet, savoir la prsentation de lorganisme daccueil et la description de
notre projet.
Le deuxime chapitre prsente une tude fonctionnelle dont lobjectif est de

capturer les besoins fonctionnels du systme futur ainsi que de faire son analyse.
Le troisime chapitre sintresse la conception des diffrents modules de notre

projet moyennant les diagrammes de classes UML.
Nous nous penchons ensuite dans le quatrime et dernier chapitre sur ltude
technique et la mise en uvre de notre projet. En effet, on va dcrire dans un premier
temps larchitecture technique, les outils, et les Frameworks utiliss pour le
dveloppement. Ensuite, nous allons expliquer la dmarche de dveloppement et illustrer
certaines fonctionnalits assures par notre application travers quelques crans.
Finalement, une conclusion rcapitule le travail accompli dans le cadre de ce projet

de fin dtudes et prsente des axes damlioration susceptibles de raffiner davantage
loutil dvelopp.
1
Chapitre 1 : Contexte gnral du projet
Chapitre 1 : Contexte Gnral du Projet
Ce chapitre prsente le contexte, la motivation et les objectifs de notre projet de fin

dtudes. Nous dcrivons dans un premier temps lorganisme daccueil. Nous
prsentons ensuite le cadre gnral du projet et la mission qui nous a t confie, et en
fin nous abordons la dmarche et la conduite du projet.
2
I. CHAPITRE 1 : CONTEXTE GENERAL DU PROJET
1. Prsentation de lorganisme daccueil

IT Group Morocco est un groupement compos de cinq filiales indpendantes et
complmentaires dans leur fonctionnement : I.T. Consulting, RSI, VisualSoft, Business
Apps et IT acadmie, spcialis en tude et conseil en Systmes dInformation et en
dveloppement dapplications client/serveur, Intranet/Internet et formation.
Ce rapprochement quoffre IT Group entre la gouvernance des systmes

dinformation, lexpertise en connectivits S.I. et lIntgration de technologies Web permet
de proposer sous une seule entit une offre complte aux clients, IT Group Morocco
devient ainsi un grand Groupe marocain dans le monde des Systmes dInformation dot
de nombreuses et prestigieuses rfrences.
Nous avons effectu notre stage de fin dtudes au sein de la filiale Visual Soft.
Cest une socit de services en ingnierie informatiques (SSII) cre en 1997, et qui a pour
principal objectif de fournir, aux entreprises et organismes divers, des produits et des
services professionnels de haute qualit.
Visual Soft entretient une culture dentreprise centre sur la qualit et sur le
contentement et la satisfaction du client. Se faisant, elle sengage entretenir avec sa
clientle des rapports srieux et permanents fonds sur des qualits de comptence et de
professionnalisme.
Pour rpondre au mieux aux exigences de ses clients, et mener bien sa mission,
Visual Soft runit plusieurs domaines de comptences :
Le conseil et lassistance en informatique, et ltude et la mise en place de systmes

dinformations ;
Le dveloppement des applications. Ces dernires sont, soit des produits standards,
soit des dveloppements spcifiques aux besoins et la demande des clients. Les
produits standards sont destins aux entreprises prives (gestion de pharmacies, de
cabinets dentaires, de laboratoires danalyses mdicales, de la comptabilit) et aux
organismes publics (gestion des marchs, du personnel, du stock).
3
Le dveloppement de sites Web, ainsi que la conception et la mise en place de

serveurs Intranet et Internet pour la publication de donnes et dinformations ou pour
des applications Client-Serveur.
La formation aux techniques et outils de dveloppement, aux systmes dexploitation
et aux rseaux, et lutilisation avance des logiciels de Bureautique.
IT Group
Morocco
I.T. Business IT
VisualSoft RSI
Consulting Apps acadmie
Figure I-1 : Organigramme dIT Group
4
2. Prsentation gnrale du projet

Dans le cadre de linformatisation de ses diffrents services et activits, le Ministre
des Habous et des Affaires Islamiques a pass Visual Soft un projet caractre national,
pour la mise en uvre dune solution intgre de gestion de la scolarit (SIGES) dans les
niveaux prscolaire, primaire, collgial, secondaire et terminal de lenseignement
traditionnel marocain.
Lapproche retenue pour la ralisation de ce projet de grande envergure, exige une

solution cible qui soit performante, standardise au niveau national, touchant les diffrents
niveaux de gouvernance (tablissements scolaires, dlgations et services centraux).
2.1. Contexte organisationnel

Les tablissements de lenseignement traditionnel, publics ou privs, dclars auprs du
Ministre des Habous et des Affaires Islamiques, sont grs par:
La Direction de lEnseignement Traditionnel pour les activits de consolidation, suivi,

validation, octroi des autorisations, production des situations statistiques, contrle ;
Les dlgations rgionales et provinciales des Affaires Islamiques (qui sont au nombre
de 82) pour la collecte des informations manant des tablissements, la coordination,
le suivi ;
Toutes les informations locales de gestion des tablissements, sont partages avec
les niveaux suprieurs: provincial, rgional et central.
La Direction de lEnseignement Traditionnel a notamment pour mission de :
Fixer la stratgie pdagogique relative l'enseignement traditionnel;

tablir les rgimes des tudes et des examens ;
Dlivrer les autorisations d'ouverture des tablissements de l'enseignement traditionnel
et veiller l'application des textes lgislatifs et rglementaires y affrant, notamment
en ce qui concerne le contrle du respect des obligations pdagogiques et
administratives ;
Examiner les demandes et les propositions de transfert des tablissements privs
d'enseignement traditionnel ;
Proposer les mesures de soutien et d'assistance aux tablissements de l'enseignement
traditionnel afin d'accomplir leur mission dans de bonnes conditions;
5
Contrler et valuer l'excution des programmes et des mthodes ;

Veiller la formation initiale et la formation continue des cadres de l'enseignement
traditionnel ;
Crer des espaces d'ducation et des activits parascolaires en faveur des lves et
tudiants de l'enseignement traditionnel ;
Assurer la coordination et le contact avec les autorits concernes par les questions de
l'enseignement et de la formation.
Direction de lEnseignement Traditionnel
Figure I-2 : Organigramme gnral de la Direction de lEnseignement Traditionnel :
6
2.2. Structure et statistiques

Les tablissements de lenseignement traditionnel sont classs en quatre cycles
denseignement, savoir :
Le prscolaire, o le cursus normal est de 2 ans (les tablissements prscolaires sont

les coles coraniques katatib- ; )
Le primaire, o le cursus normal est de 6 ans ;
Le collgial, o le cursus normal est de 3 ans ;
Le secondaire, o le cursus normal est de 3 ans ;
Le terminal, o le cursus normal est de 3 ans ;
Les tablissements primaires, collgiaux, secondaires et terminaux, sont environ au
nombre de 463, Ils comptent approximativement 26000 lves, 4000 enseignants et prs de
1000 employs (corps administratif et agents). Les katatib comptent prs de 330 000
lves encadrs par environ 13 000 enseignants ( raison gnralement- dun enseignant
par cole prscolaire).
2.3. Objectifs du projet

Lobjectif du projet est la ralisation et la mise en place dune solution intgre de
gestion de la scolarit (SIGES), qui intgre notamment les modules suivant :
Gestion des tablissements ;

Gestion des centres dexamen ;
Gestion des enseignants, du personnel de ladministration scolaire des tablissements,
et des cadres pdagogiques ;
Gestion des lves et tudiants ;
Inspections administrative et pdagogique ;
Calendrier scolaire ;
Programmes et manuels scolaires ;
Horaire et emploi du temps ;
Soutien pdagogique ;
Examens ;
Absences et retards.
La solution intgre cible doit permettre notamment :
Lautomatisation de lensemble des procdures de gestion ;
7
La consolidation des donnes dans une seule base de donnes nationale pour
notamment suivre le parcours des lves et tudiants ;
La reprise de l'existant ;
Llaboration des statistiques, des ditions et des consultations multicritres ;
Larchivage des donnes.
2.4. Mission du stage

Visual Soft a estim la dure totale pour la ralisation de ce projet 900jrs/homme.
De ce fait notre chef de projet, et vue la dure de notre stage, nous a confi comme mission
durant notre stage lanalyse, la conception et la ralisation des modules suivants :
Gestion des tablissements ;

Gestion des lves/tudiants ;
Gestion des enseignants, du personnel de ladministration scolaire des tablissements
et des cadres pdagogiques ;
3. Conduite du projet : Mthode RUP (Rational Unified Process)
3.1. Motivation
Au dpart, Visual Soft ne savait pas toutes les exigences du projet et comment les
spcifier de faon prcise. Nous avons donc senti que nous serons confronts des
changements continuels, et donc il nous a fallu suivre une dmarche itrative. Aussi, il
fallait prsenter des livrables, et donc la dmarche devrait tre incrmentale (c'est--dire
qu la fin de chaque itration, une version excutable est livre). Et enfin, la
mthode choisie devrait tre construite sur UML et surtout conduite par les cas
dutilisation.
Pour toutes ces raisons, nous avons opt pour la mthode RUP (Rational Unified
Process) qui est un processus de conception/dveloppement de logiciel dfini par
Rational Software, unifi, c'est--dire construit sur UML, itratif, incrmental, centr
sur larchitecture et conduit par les cas dutilisation.
8
3.2. Enchanement dactivits essentielles dans RUP

La mthode RUP propose le cycle de conception/dveloppement suivant (Figure I-3) :
Figure I-3 Schma de l'enchainement des activits dans RUP
Nous avons veill le respecter tout le long de la ralisation de notre projet. En

effet, nous avons commenc par une planification initiale en termes de temps et de
ressources.
Ensuite, nous sommes passs la dfinition des exigences qui a pour but de dfinir
une vision du produit, et de traduire cette vision en cas d'utilisation
Ltape danalyse nous a permis de rpondre la question Quoi faire ? Tandis

que la conception Comment le faire ? .
Nous avons ensuite implment lapplication, tout en procdant par des tests
unitaires afin dvaluer le niveau de qualit atteint, pour enfin les dployer.
3.3. Les quatre phases du processus RUP

La mthode RUP est compose de quatre phases principales comme il est illustr dans le
tableau suivant :
9
Phase Objectifs
- Comprendre le primtre du projet.

Inception - Dfinir les objectifs du projet
- Identification des acteurs et des cas dutilisation
- Choix des outils de dveloppement.
- Spcifier les exigences,

- Description dtaille des cas dutilisation
laboration - Conception des composants du systme
- Implmentation de quelques scnarios critiques
- Finaliser lanalyse, conception, implmentation, et test

Construction des cas dutilisations.
- Une premire version fonctionnelle est livre.
- Prparation de lenvironnement de dploiement ;

Transition - Test du produit et correction derreurs en vue de
livraison ;
- Production de documentation
Tableau I-1: Les quatre phases du processus RUP
4. Conclusion
Dans ce chapitre, nous avons commenc par une prsentation de lorganisme
daccueil. Nous sommes ensuite passs la description du contexte, les motivations
les objectifs du projet, ainsi que la mission de notre stage. On a ensuite prsent le
processus de dveloppement RUP, que nous avons adopt pour conduire notre travail.
Dans ce qui suit, nous allons nous intresser l'analyse et la conception et

l'laboration des diffrents diagrammes UML.
10
Chapitre 2 : tude fonctionnelle
Ce chapitre traite les deux phases les plus cruciales de tout cycle de
dveloppement, savoir la capture des besoins fonctionnels et lanalyse. La premire
partie de ce chapitre prsente la phase de spcification des besoins fonctionnels et
techniques pour identifier les fonctionnalits auxquels le systme doit rpondre. Les
rsultats de la phase de spcification seront la base de la phase danalyse traite dans
la deuxime partie.
11
II. CHAPITRE 2 : TUDE FONCTIONNELLE
1. Spcification des besoins
1.1. SPECIFICATION des besoins fonctionnels
1.1.1. tude fonctionnelle du module : Gestions des lves et des

tudiants
La solution cible envisage doit assurer toutes les oprations de gestion en vigueur
sur une entit lve/tudiant, notamment :
La cration dun nouvel tudiant (premire inscription),

La rinscription dun tudiant,
Le transfert dinscription dun tablissement un autre,
La gestion des absences et dassiduit,
La gestion des diffrents cycles et niveaux scolaires, ainsi que la gestion des classes.
Lapplication doit aussi permettre de garder toutes les informations pertinentes qui
contiennent les donnes personnelles des tudiants (date et lieu de naissance, adresse,
numro de tlphone, nom et prnom de llve et de ses parents ou tuteurs ), ainsi que
les informations concernant le parcours scolaire de llve (les tablissements et les classes
frquentes, les notes, ).
1.1.2. tude fonctionnelle du module : Gestions des tablissements

La gestion des tablissements de lenseignement traditionnel doit permettre
dassurer toutes les oprations en vigueur sur une entit tablissement, notamment :
la cration dun nouvel tablissement,

Fermeture dun tablissement.
Les diffrents cycles scolaires autoriss, possibilit de changement de cycle.
Lapplication cible doit aussi tre en mesure de dtenir et sauvegarder des
informations concernant ltablissement (nom, adresse, localisation, milieu (urbain ou
12
rural), statut (public ou priv), description des locaux (salles de classes, salle de bureaux,
internats, rfectoires, cuisines, magasins, bibliothques)).
Elle doit aussi permettre la dfinition des postes des cadres administratifs, des
enseignants et des agents, ainsi que leurs fonctions et occupations, elle doit aussi permettre
de gnrer et dimprimer des rapports, autorisations et des statistiques.
1.2. Spcification des besoins techniques

Ergonomie :
Lergonomie de lapplication doit favoriser la lisibilit et laccessibilit des
informations, ainsi que leur rutilisation.
Linterface doit tre conviviale, facile manipuler par des utilisateurs simples (non
informaticiens).
Bilinguisme :
Le systme doit prendre en charge les donnes en arabe et en franais
simultanment, au moins pour les noms dlves et personnel, pour toutes les
nomenclatures de base.
Le systme doit prendre en charge les donnes en arabe ou en franais, selon le

choix de loprateur. Linterface utilisateurs doit tre en langue arabe et franaise.
Administration :
Le systme doit permettre aux administrateurs de grer les utilisateurs et groupes,
leurs rles et fonctions par module, et galement de surveiller et grer la liste des
utilisateurs en ligne.
Scurit et intgrit :
La solution doit avoir une interface dauthentification unique.
Tous les modules font partie de la mme solution avec le principe de saisie unique.
Laccs aux fonctions du systme et aux donnes sera permis seulement base
dauthentifications par nom dutilisateur et mot de passe.
Les utilisateurs, les groupes dutilisateurs et les fonctions doivent tre grs par
les administrateurs laide des interfaces appropries.
13
2. Analyse du contexte
Lanalyse du contexte a pour objectif lidentification des diffrents acteurs qui
interagiront avec le systme. Ces acteurs seront regroups par la suite sous forme de rles
dont chacun englobe un ensemble dentits. Le regroupement sera effectu en se basant sur
les interactions.
2.1. Les rles

Un rle rfre une mission et des responsabilits assumes par les acteurs du
systme tudi. Un acteur (utilisateur, dispositif matriel ou autre systme) interagit
directement avec le systme et peut consulter et/ou modifier directement ltat du systme,
par mission et/ou rception de messages ventuellement porteurs de donnes.
Ltude de la typologie des rles a conduit la classification suivante :
Au niveau central :
La Direction de lEnseignement Traditionnel : Gestionnaires
Au niveau rgional et provincial :
Les dlgations rgionales du MHAI : Gestionnaires
Les dlgations provinciales du MHAI : Gestionnaires
Les tablissements de lEnseignement Traditionnel : Gestionnaires, Enseignants,
tudiants.
Les acteurs que nous avons identifis partir de la description des fonctionnalits
ci-dessus sont les suivants :
Gestionnaires :
Gestionnaire DET : les diffrentes oprations de gestion sur les tablissements au
niveau national (cration, modification, fermeture, )
Gestionnaire DR : les diffrentes oprations de gestion au niveau rgional,
notamment la gestion des transferts des tudiants et des enseignants, et
lattribution de bourses.
Gestionnaire DP : les diffrentes oprations de gestion au niveau rgional, la
gestion des transferts, la gestion des candidatures libres aux examens.
Gestionnaire EET : gestion des inscriptions des tudiants, des absences et retards.
Utilisateurs externes :
14
Enseignant : Consultation des listes des tudiants, ditions des notes.

tudiant : Consultation des notes, des informations personnelles.
Administrateurs :
Administration du systme et gestion des rles et des utilisateurs.
Utilisateurs simples (internaute) : ils ont seulement le droit de consulter les donnes du
systme et de faire des recherches suivant des critres prcis.
uc Actors
Utilisateur
externe
GESTINNAIRE
Administrateur
Enseignant
lv e/tudiant
Gestionnaire Gestionnaire Gestionnaire
Gestionnaire
DP DR EET
DET
Figure II-1: Les acteurs du systme
15
2.2. Diagramme de contexte

Le diagramme de contexte a pour but de reprsenter les flux dinformations entre le
systme et les acteurs externes. Il permet disoler le systme en le dlimitant et ainsi
dfinir les lments externes avec lesquels il interagit. Cest ainsi que lon modlise le
contexte gnral du projet par le diagramme de contexte ci-dessous (Figure II-2):
Utilisateur externe
Consulter les notes, prcours scolaire des

tudiants
Gestion et modification du systme Grer les utilisateurs et les rles

Systme SIGES
Gestionnaire
admnistrateur
Consulter des informations gnrales:

statistique
internaute
Figure II-2: Diagramme de contexte
2.3. Diagramme des cas dutilisation

Les cas d'utilisation permettent de recueillir, d'analyser et d'organiser les besoins, et
de recenser les grandes fonctionnalits d'un systme. Il s'agit donc de la premire tape
UML d'analyse d'un systme.
Dans cette section nous allons prsenter les cas dutilisation concernant les
modules de :
gestion des tudiants,

gestion des tablissements,
gestion des enseignants, du personnel de ladministration scolaire des
tablissements et des cadres pdagogiques,
16
Les acteurs principaux de notre systme sont au nombre de quatre : Administrateur,

Gestionnaires, utilisateurs externes (enseignants ou tudiants) et lutilisateur simple
(internaute).
Le diagramme ci-dessous (Figure II-3) regroupe les diffrents cas dutilisations et

les acteurs de notre systme sous forme de packages :
Figure II-3: digramme de packages des use case
17
2.3.1. Gestion des lves et des tudiants

uc Gestion lv es et tudiants
Inscrire lv e
extend
Rinscrire lv e Crer lv e/tudiant
include
Grer abscence et
retard
Gestionnaire
EET include
(from Actors) include
include
Grer parcours
scolaire
include
S'authentifier
include
Transfrer lv e
Gestionnaire include
DP
(from Actors)
include
Grer candidature
libre
Attribuer bourse
Gestionnaire
DR
(from Actors)
Figure II-4: Cas dutilisation inscrire lve
Description du cas dutilisation inscrire lve
18
Cas dutilisation Inscrire lve

Version Version 1.0 du 26/03/2012
Acteur principal - Gestionnaire EET (La scolarit)
Objectifs - Ce cas dutilisation permet dinscrire un lve ou tudiant dans
un tablissement denseignement traditionnel.
Pr conditions - Sauthentifier.
- Vrification pralable des conditions dinscription (ge,
comptences)
Post conditions - Un nouvel lve/tudiant est inscrit, le nombre
dlves/tudiants sincrmente
Scnario nominal - Llve/tudiant prsente sa demande, les informations
ncessaires et les frais dinscription
- Gestionnaire EET vrifie que toutes les informations sont
correctes.
- Gestionnaire EET rempli le formulaire et enregistre le nouvel
lve/tudiant, llve/tudiant est alors inscrit.
Scnario secondaire LEET annule linscription :

Le systme nenregistre rien et le cas dutilisation se termine en
chec
Lge de llve nest pas valide :
Le systme signal lerreur mais peut continuer lopration
dinscription
Exigences Linscription doit tre la plus rapide possible ;

supplmentaires Le systme doit permettre de numriser la photo de
llve/tudiant ;
Le systme doit supporter la saisie de quelques informations en
arabe.
Tableau II-1: Description du cas dutilisation inscrire lve
19
2.3.2. Gestion des tablissements
uc Gstion d'tablissement
Grer tablissement
Crer tablissement
Modifier
tablissement
include
Fermer tablissement include
include
S'authentifier
Grer demande et/ou
include
Gestionnaire DET autorisation
(from Actors)
include
Dfinir Poste et son include

occupation
Gnrer statistiques et
tableau de bord
Figure
FigureII-5:
10: Cas
Casdutilisation
dutilisationCrer
Grertablissement
tablissement
20
Description textuelle du cas dutilisation Crer tablissement :
Cas dutilisation Grer tablissement

Acteur principal - Gestionnaire DET
Objectifs - Ce cas dutilisation permet de crer un nouvel
tablissement de lenseignement traditionnel
et de lajouter dans la base de donnes.
Pr conditions - Ltablissement a t inaugur ou autorise
par la DET.
- Sauthentifier
Post conditions - Un nouvel tablissement denseignement est
cr et ajout la base de donnes.
Scnario nominal - Saisir les donnes concernant ltablissement :
le gestionnaire DET ouvre le formulaire
dajout dun tablissement, remplit les
informations ncessaires le concernant et
valide lajout.
Scenario secondaire - Consulter la liste des tablissements
- Modifier un tablissement : sil saperoit
quune information est errone, le
gestionnaire DET peut le modifier
Tableau II-2: Description textuelle du cas dutilisation Grer tablissement
21
2.3.3. Gestion des cycles denseignement

uc Gstion Cycle d'enseignement
Gstion des tudes
Crer Cycle
extend
Grer Cycle
d'enseignement Modifier cycle
extend
extend
Fermer cycle
Gestionnaire DET
Grer Niv eau
(from Actors) include
include
s'authentifier
Grer classe include
C'est une gstion

pdagogique
Figure II-6: Cas d'utilisation "gestion des cycles d'enseignement"
22
Description textuelle Grer cycle denseignement
Cas dutilisation Grer un cycle denseignement

Acteur principal Gestionnaire DET
Objectifs Ce cas dutilisation permet de grer un cycle
denseignement concernant un
tablissement :
- Autorisation dun cycle
- Cration dun nouveau cycle
- Changement de cycle
Pr conditions - Sauthentifier
Scnario nominal - choisi un tablissement, et lui attribue un
cycle.
Scenario secondaire - Le gestionnaire modifie une information
errone concernant un cycle
- Consultation des cycles autoriss dans un
tablissement
Tableau II-3: Description textuelle Grer cycle denseignement
23
2.3.4. Gestion du personnel administratif et pdagogique

uc Gestion du Personnel administr et pdagogique
Crer enseignant
Crer Employ Crer cadre

administratif
Crer Agent
Affecter Employ
include
include
Grer Transfert s'authentifier

Gestionnaire DET include
include
Grer remplacement
include
Gestionnaire EET
Grer Abscence et
retard des employs
Figure II-7: Cas d'utilisation "gestion du personnel administratif et pdagogique"
Description textuelle du cas dutilisation gestion employs
Cas dutilisation Crer employ

Acteur principal Gestionnaire DET
Objectifs Ce cas dutilisation permet de saisir les informations dun
nouvel employ
Pr conditions Employ ayant t recrut par la DET.
Sauthentifier
Post conditions Nouvel employ cre et ajout la base de donnes
24
Scnario nominal le gestionnaire DET ouvre le formulaire dajout dun

employ, rempli le formulaire dajout et le valide.
Scenario secondaire Le gestionnaire consulte les informations dun employ, les
modifie en cas de donnes errones.
Tableau II-4: Description textuelle du cas dutilisation gestion employs
2.4. Digrammes dactivits

Les diagrammes dactivits permettent de mettre laccent sur les traitements. Ils
sont donc particulirement adapts la modlisation du cheminement de flots de contrle
et de flots de donnes. Ils permettent ainsi de reprsenter graphiquement le comportement
dune mthode ou le droulement dun cas dutilisation.
Nous allons prsenter dans cette section les diagrammes dactivits concernant le
processus dinscription dun tudiant, et celui de la gestion dabsence au sein dun
tablissement denseignement.
2.4.1. Diagramme dactivit dinscription dtudiants

En effet, aprs la demande dinscription de ltudiant, le gestionnaire EET vrifie si
ltudiant vrifie les conditions dadmission, et lajoute la base de donnes et lenregistre
en lui affectant ltablissement, le cycle et la classe.
25
act diagramme d'activ it de "inscrire lv e"
Etudiant gestionnaire EET
Vrifier les conditions

Demande d'inscription
Dbut
[ Demande refuse ]
Fin
[ Demande accepte ]
Fournir les pices et les

informations ncessaires
Entrer les informations

personnelles de l'tudiant
Affecter tablissement
Affecter le cycle d'tudes
Un test sur la capacit

Affecter le niv eau de la classe (nmbre
max ?)
Si nmbre d'etudiants par classe

max
Sinon Crer une nouv elle classe
Affecter classe
Enregistrer et quitter
Fin
d'inscription
Figure II-8: Diagramme d'activit "inscrire lve"
26
2.5. Digrammes de squences

Les diagrammes de squence sont des diagrammes dinteractions qui permettent
de modliser les scnarios. Ils ont pour objectif de mieux reprsenter les interactions entre
les objets de notre projet selon un point de vue temporel.
En effet, une fois les besoins du systme formaliss travers les diagrammes de cas
dutilisation, il faut ensuite modliser les interactions entre le systme et les diffrents
acteurs travers la succession squentielle des actions.
Dans cette section nous allons prsenter des exemples de diagrammes de squences
de notre systme. Diagramme de squence dajout dun tablissement :
sd Gstion d'tablissement
Systme
Gestionnaire DET
Demande d'authentification()
Formulaire d'authentification()
Authentification(login, password)
Vrification()
Menu gestionnaire DET()
Demande d'ajout tablissement()
Formulaire d'ajout tablissement()
Formulaire rempli()
Enregistrement()
accus de cration d'un nouvel tablissement()
(from Actors)
Figure II-9: Diagramme de squence "ajouter tablissement"
27
Le gestionnaire DET accde sa session en sauthentifiant via le formulaire

dauthentification.
Le gestionnaire DET demande le formulaire de cration dun tablissement.
Le systme rpond en lui renvoyant le formulaire.
Le gestionnaire DET rempli le formulaire par les informations ncessaires et valide
lajout.
Le systme vrifie la validit des informations et met jour la base de donnes.
2.5.1. Diagramme de squence dinscription dun tudiant
sd Interaction
<<Systme>>
Gestionnaire EET
{Conditions d'inscription
remplies}
{Gestionnaire
authetifi}
alt Crer lv e
Demander formulaire de cration()
[1re inscription]
Formulaire de cration()
Formulaire rempli()
Enregistrement()
{Nouv el lv e
cr}
Accus de cration()
demande formulaire d'inscription()
Formulaire vide()
Formulaire rempli()
Validation et enregistrement()
{Nouv el lv e
inscrit}
nouvel lve/tudiant inscrit()
(from Actors)
Figure II-10: Diagramme de squence "inscrire lve"
le gestionnaire EET accde sa session en sauthentifiant via le formulaire

dauthentification.
Le cas dun nouvel tudiant :
28
Le gestionnaire EET demande le formulaire de cration dun tudiant

Le systme rpond en lui renvoyant le formulaire de cration dtudiant.
Le gestionnaire EET rempli le formulaire par les informations ncessaires et valide
lajout.
Le gestionnaire demande le formulaire dinscription de ltudiant dans un
tablissement (affecter tablissement).
Le systme rpond en lui renvoyant le formulaire dinscription.
Le gestionnaire EET le rempli et le soumis.
Le systme valide les informations et met jour la base de donnes.
2.5.2. Diagramme de squence de lajout dun employ

sd Gestion du Personnel administr et pdagogique
Systme
GESTINNAIRE
{Nouv eau employ {Gestionnaire

recrut} authentifi}
Demander formulaire d'ajout()
Formulaire vide()
Formulaire rempli()
Vrification et enregistrement()
{Nouv el emply
aj out}
(from Actors)
Figure II-11: Diagramme de squence "ajouter employ"
le gestionnaire DET accde sa session en sauthentifiant via le formulaire

dauthentification.
Le gestionnaire DET demande le formulaire dajout dun employ.
Le systme rpond en lui renvoyant le formulaire dajout demploy.
Le gestionnaire EET rempli le formulaire par les informations ncessaires et valide
lajout.
29
3. Conclusion
Dans ce chapitre nous avons captur les besoins fonctionnels de notre systme et
dans la phase danalyse nous avons dcrit les rgles mtiers en se basant sur des
diagrammes des cas dutilisation et de squence.
Le chapitre suivant sera consacr la conception de notre systme en se basant

sur les rsultats obtenus dans la partie traitant lanalyse.
30
Chapitre 3 : Conception
Dans un premier temps nous avons ralis les diagrammes dinteractions qui
sont particulirement utiles au concepteur pour reprsenter graphiquement ses
dcisions dallocation de responsabilits aux classes, ensuite, et laide de ces
diagrammes, nous avons pu laborer des diagrammes de classes partiels pour en arriver
au diagramme de classes final.
31
III.CHAPITRE 3 : CONCEPTION
1. Diagramme de paquetage
La figure suivante (Figure III-1) montre les packages de notre systme:
pkg Use Case Model
Gestion des lv es et tudiants Gestion des tablissements
use
use use use use
Gestion dabsences et retards Gestion des Matires Gestion des employs
Figure III-1 Diagramme de paquetage systme
Gestion des tablissements

Permettre dassurer toutes les oprations de gestion en vigueur sur une entit
tablissement scolaire: cration, cycles autoriss ;
tre en mesure de dtenir des informations concernant l'tablissement, le nom,
ladresse, la localisation, le milieu (urbain ou rural), le statut (public ou priv), la
description des locaux (salles de classes, salles de bureaux, internats des lves -
filles ou garons-, rfectoires, cuisine, magasin, bibliothques)
Gestion des lves et tudiants
Assurer toutes les oprations de gestion en vigueur sur une entit lve/tudiant:
premire inscription, rinscription, transfert dinscription, niveau, cycle, classe,
Garder toutes les informations pertinentes qui contiennent des donnes
personnelles (date et lieu de naissance, adresse, numro de tlphone, nom et
prnom en arabe et en franais de llve et de ses parents ou tuteurs, ), les
informations concernant le parcours scolaire de llve (les tablissements et
classes dans lesquelles l'lve a tudi, notes, notes finales, la frquentation, )
32
Gestion des enseignants

Conserver des informations dtailles sur un enseignant, y compris des
renseignements personnels, matires enseignes (par anne et cycle), spcialit,
les degrs d'ducation.
Matires enseignes aux lves et tudiants

Renseigner les types et intitul des matires
Permettre la gestion du volume horaire pour chaque matire et les coefficients et
notes liminatoires par niveau (primaire, collgial, secondaire et terminal) et par
anne scolaire/universitaire.
partir des diagrammes de squences labors dans la phase danalyse, et en

tenant compte des rgles mtiers nous avons pu identifier les diagrammes de classes
concernant chaque package.
2. Le package Gestion des lves et tudiants

Afin dlaborer le diagramme de classes final de ce package nous avons d passer
par le diagramme dinteraction et aussi nous avons ralis des diagrammes de classes
partiels.
2.1. Diagramme dinteraction des informations personnelles de

llve
Par rapport aux diagrammes de squence systme, nous allons remplacer le systme
vu comme une bote noire par un ensemble dobjets en interaction. Pour cela, nous
utiliserons les trois types de classes danalyse, savoir les dialogues, les contrles et les
entits.
Les classes qui permettent les interactions entre le site web et ses utilisateurs sont
qualifies de dialogues . Cest typiquement les crans proposs lutilisateur : les
formulaires de saisie, les rsultats de recherche, etc.
Celles qui contiennent la cinmatique de lapplication seront appeles contrles.

Elles font la transition entre les dialogues et les classes mtier, en permettant aux crans de
manipuler des informations dtenues par un ou plusieurs objet(s) mtier.
33
Celles qui reprsentent les rgles mtier sont qualifies d entits . Elles
proviennent directement du modle du domaine, mais sont confirmes et compltes cas
dutilisation par cas dutilisation.
Dans notre cas et pour ce package nous prsentons le diagramme dinteractions

suivant:
sd Diagramme d''interactions
Gestionnaire EET dialogue:<Ajouter control : entity :<Eleve> entity : entity :<Personne> entity :<Adresse>
eleve> <ajouterEleve> <Parent_eleve>
Demander formulaire d'ajout()

formulaire d'ajout()
formulaire()
formulaire()
formulaire rempli() verificationSyntaxe()
formulaire rempli()
Ajouter eleve()
ajouter personne(eleve)
ajouter_adresse_eleve(adresse)
affecter parent()
crer parent()
affecter adresse parent()
accus()
Confirmation()
(from Actors)
Figure III-2: Diagramme d'interaction d'ajout d'un lve
Pour ajouter un nouvel lve, on passe par une interface graphique qui reprsente la
couche prsentation. Aprs avoir valid les informations qui seront envoys, nous passons
par le contrleur qui va grer laccs aux ressources de notre systme, pour enfin arriver
aux entits, et plus prcisment la couche model.
Daprs ce diagramme nous avons pu identifier des entits quon va modliser dans le
diagramme de classes partiel ci-dessous.
34
2.2. Diagramme de classes des informations personnelles de l'lve
class Informations personnelles d''un lv e
Adresse
- adresse: string
- ville: string
- codePostal: long
- adresseAr: string
- pays: string = Maroc
+ getAdresse() : string
+ Adresse()
Personne
- nom: string
- prenom: string Personne
- email: string
Elev eTuteur
- dateNaissance: Date
- lieuNaissance: string Personne - fonction: string
- telDomicile: string
Elev eParent
- nomAr: string + getNom() : string
- prenomAr: string - fonction: string + Personne()
- genre: boolean
- CIN: string + getNom() : string
- Image: Image + Personne()
- telMobile: string 0..1
+ getNom() : string
+ Personne() 0..2
Personne
Elev e
- CNE: long
- boursier: boolean
- noInternat: string
- abandon: boolean
- id: int
+ getNom() : string
+ Personne()
Figure III-3: Diagramme de classes des informations personnelles de l'lve
Cette figure (Erreur ! Source du renvoi introuvable.) montre les diffrentes

classes concernant la gestion des informations personnelles dun lve, on peut remarquer
quon dispose dune classe personne qui regroupe les informations communes aux
lves et leurs parents et/ou leurs tuteurs. Les trois classes lve , EleveParent et
EleveTuteur hritent de la classe personne . Parmi les finalits de cet hritage est de
gagner du temps en effectuant les oprations CRUD (Create, Read, Update, Delete)
pendant la phase de ralisation.
35
Lentit Adresse est un objet complexe qui contient plusieurs attributs (ville,
rue, numro, pays) qui le dfinissent, de ce fait, ladresse est modliser non pas par un
simple attribut de la classe personne mais dune classe qui est en relation dagrgation
avec celle-ci.
2.3. Diagramme dinteraction dinscription

sd inscrire
Gestionnaire EET dialogue:<inscrire> control :<inscrire> entity :<eleve> entity :<classe> entity :
<AnneScolaire>
demander formulaire d'inscription()
formulaire d'inscription()
formulaire rempli()
verifier_Syntaxe()
erreurSyntaxe()
formulaireCorrig()
verifierSyntaxe()
inscrire(eleve, classe, anneScolaire)
affecterEleve(eleve)
eleveAffect()
affecterClasse(classe)
classeAffecte()
affecterAnneScolaire(AnneeScolaire)
anneScolaireAffecte()
createConfirmation()
Confirmation()
(from Actors)
Figure III-4: Diagramme d'interaction d'inscription d'un lve
Daprs ce diagramme dinteractions nous avons pu identifier les entits qui nous
serons utiles pour concevoir le diagramme de classes partiel suivant.
36
2.4. Digramme de classes d'inscription

class Inscription
Classe
- designation: string
- capaciteAcceuil: int
- nombreEleves: int 1
1..*
0..* Personne
Personne
Elev e
- CNE: long
- boursier: boolean
AnneeScolaire - noInternat: string
- abandon: boolean
- dateDebut: date - id: int
- dateFin: date Inscription
- designation: string 0..*
0..* + getNom() : string
- cloturee: boolean + Personne()
Figure III-5: Diagramme de classes d'inscription
Ce diagramme regroupe les trois classes AnneeScolaire , Classe , et

Eleve contribuant effectuer une inscription. Elles sont mises dans une relation
dassociation de type n-aire exactement 3-aire . Il sagit dune association
promue au rang de classe. Elle possde tout la fois les caractristiques dune
association et celles dune classe et peut donc porter des attributs qui se valorisent pour
chaque lien.
En ce qui concerne les cardinalits, et par exemple lassociation entre Eleve et

classe est traduite ainsi : un Eleve nappartient qu une seule classe et que
classe possde plusieurs Eleve et au moins un.
37
2.5. Diagramme de classes de parcours scolaire
class Parcours scolaire
Personne
Personne
Elev e Note Matiere AnneeScolaire
- CNE: long 1 0..* - note: float - designation: string
- dateDebut: date
- boursier: boolean - appreciation: string 1..* 1 - coefficient: float
- dateFin: date
- noInternat: string - designation: string
- abandon: boolean
1..* - cloturee: boolean
- id: int
+ getNom() : string
+ Personne()
Parcours_scolaire
0..* 0..* 1..*
Bulletin Periode
- appreciation: string - designation: string

- /noteFinale: float - dateDebut: date
- dateFin: date
- cloturee: boolean
Figure III-6 : Diagramme de classes de parcours scolaire
Lassociation de type 2-aire entre la classe Periode et la classe Bulletin est

une classe dassociation qui contient le rsum du parcours scolaire dun lve. Le
parcours scolaire regroupe des informations propres chaque lve qui sont : une note
pour chaque matire .Chaque matire a un coefficient que lon utilise avec la note pour
calculer la note finale du bulletin. Chaque Bulletin est associ un semestre de lanne
scolaire
Daprs les diagrammes de classes partiels ci-dessus, on a pu laborer le

diagramme de classes global du package gestion des lves et tudiants :
38
class Diagramme Global
Adresse
Personne
- adresse: string Personne AbscenceElev e
- ville: string Elev eParent
Elev eTuteur - dateDebut: Date
- codePostal: long - fonction: string
- fonction: string - dateFin: Date
- adresseAr: string
- justifiee: boolean
- pays: string = Maroc + getNom() : string - remarque: String
+ Personne() + getNom() : string
+ getAdresse() : string + Personne()
+ Adresse()
0..2 0..1
0..1
MotifAbscence
Personne - motif: string
- image: image
- nom: string
- prenom: string
Personne
- email: string
- dateNaissance: Date Elev e SeanceCours
- lieuNaissance: string
- CNE: long - dateDebut: date
- telDomicile: string 0..* 0..* - 1..*
- boursier: boolean duree: date
- nomAr: string
- noInternat: string - typeSeance: string
- prenomAr: string
- abandon: boolean
- genre: boolean
- id: int
- CIN: string
- Image: Image
+ getNom() : string
- telMobile: string
+ Personne()
Note
+ getNom() : string 1 0..*
+ Personne() - note: float
1..* 1..* -
0..* appreciation: string
1..*
1
Matiere
Enseignant
enseigne - designation: string
- echelle: string 0..* 0..* - coefficient: float 1
- echelon: string
+ Personne()
0..*
AnneeScolaire
Etablissement Classe
Inscription
1 - dateDebut: date
- nom: string - designation: string
- noAutorisation: string capaciteAcceuil: int 0..* 0..* - dateFin: date
1..* - - designation: string
- statut: boolean - nombreEleves: int
- cloturee: boolean
- capacite: int
Parcours_scolaire
- semestre: string
- note: float
- classement: int
1..*
Bulletin Periode
- appreciation: string - designation: string

- /noteFinale: float 0..* 0..* - dateDebut: date
- dateFin: date
- cloturee: boolean
Figure III-7 : Diagramme de classes du package "gestion des lves et tudiants"
On peut remarquer que ce diagramme global se compose en plus des diagrammes

de classes partiaux quon a labors ci-dessus de dautres portions qui seront dtaills
aprs. Cela montre bien la dpendance entre les packages.
39
3. Le package Gestion des tablissements

En suivant la mme dmarche quon a suivie pour concevoir le package gestion
des lves et tudiants , nous avons ralis le diagramme de classes du package gestion
des tablissements partir des diagrammes partiaux suivants, et aussi partir des
dpendances existantes entre les packages de notre systme.
3.1. Gestion des cycles, niveaux, et classes Dun tablissement

class DC1
Etablissement Classe
Cycle Niv eau
- nom: string - designation: string
- noAutorisation: string - designation: String - designation: string
1..* 1..* 1..* 1..* - capaciteAcceuil: int
- statut: boolean - nombreEleves: int
- capacite: int
Figure III-8: Diagramme de classes de gestion des cycles, niveaux et classes
Chaque tablissement propose un ou plusieurs cycles denseignement. Chaque

cycle est compos de plusieurs niveaux, et chaque niveau contient une ou plusieurs classes.
40
3.2. La description des locaux

class DC2
Etablissement
- nom: string
- noAutorisation: string
- statut: boolean
- capacite: int
Local
1
Cuisine
1..*
Local Local
Local - designation: string Internat
Magasin - responsable: Employe [0..*] - designation: string
- disponibilite: boolean - capaciteAccueil: int
- genre: boolean
- exploitable: boolean
Local
Bibliotheque
1..*
Local Local Chambre

Refectoire Salle
Salle
Salle SalleDeCours
SalleDeBureau
- capaciteAccueil: int
- proprietaire: Personne[0..*] - nbrePaillasses: int
- note: string - disponibilite: boolean
- note: string
Figure III-9 : Diagramme de classes des locaux
Chaque tablissement possde un ou plusieurs locaux, et chaque local a ses propres

caractristiques qui le dcrivent, titre dexemple : un tablissement a plusieurs salles
quils soient des salles de cours ou bien des salles de bureaux, un internat se compose de
plusieurs chambres etc.
41
3.3. Dfinition des postes des cardes administratif, enseignants, et

agents
class diagramme de classes partiel etablissement
Diplome
- dateObtention: date
- lieuObtention: string
- mention: string
- note: string
0..*
Personne
Personne
Employe
- salaire: float
- dateEmbauche: date
- situationFamiliale: string
- decede: boolean
- nbreEnfant: int
+ getNom() : string
+ Personne()
Employe
Cadre_administratif Employe
Employe
- fonction: string Agent
Enseignant
- grade: string
- fonction: string
- echelle: string
- echelon: string + getNom() : string
+ getNom() : string
+ Personne()
+ Personne()
+ getNom() : string
+ Personne()
1..* 1 1
Etablissement
- nom: string
- noAutorisation: string
- statut: boolean
- capacite: int
Figure III-10: Diagramme de classes des employs et du personnel
Chaque employ 0 ou bien plusieurs diplmes, on pourra avoir un agent qui na

aucun diplme comme on peut trouver un enseignant qui possde plusieurs diplmes.
La classe Employe est une classe mre qui regroupe les informations communes tous
les employs.
3.4. Diagramme Global

En regroupant les diagrammes de classes partiels ci-dessus nous avons labor le
diagramme de classes global du package gestion des tablissements suivants :
42
class Gestion etablissement
Diplome
Adresse
- adresse: string - dateObtention: date
- ville: string - lieuObtention: string
- codePostal: long - mention: string
- adresseAr: string - note: string
- pays: string = Maroc
0..*
+ Adresse()
Personne
Employe
- salaire: float
Personne
- nom: string - decede: boolean
- prenom: string - nbreEnfant: int
- email: string
- dateNaissance: Date + getNom() : string
- lieuNaissance: string + Personne()
- telDomicile: string Employe
- nomAr: string Enseignant Employe
- prenomAr: string Employe
Agent
- genre: boolean - echelle: string Cadre_administratif
- CIN: string - echelon: string - fonction: string
- Image: Image - fonction: string
- telMobile: string + getNom() : string - grade: string + getNom() : string
+ Personne() + Personne()
+ getNom() : string + getNom() : string
+ Personne() + Personne()
Local
Etablissement
Cuisine
- nom: string
1..* - noAutorisation: string 1
- statut: boolean
- capacite: int
1..* 1..* Cycle
1
Local - designation: String
- responsable: Employe [0..*] 1..*
- disponibilite: boolean
Local
Magasin
1..*
Local
Internat Niv eau
- designation: string - designation: string
- capaciteAccueil: int
Local - genre: boolean
Salle - exploitable: boolean
Local - designation: string

Refectoire
Local 1..*
Bibliotheque
Classe
1..*
Chambre - capaciteAcceuil: int
- nombreEleves: int
Salle Salle
SalleDeBureau SalleDeCours
- proprietaire: Personne[0..*] - capaciteAccueil: int

- note: string - nbrePaillasses: int
- note: string
Figure III-11: Diagramme de classes du package "gestion des tablissements"
43
4. Conclusion
Nous avons prsent dans ce chapitre une vue conceptuelle de la solution mettre
en place. Ainsi nous avons prsent les diagrammes dinteractions dUML pour mieux
comprendre les fonctionnalits offertes et qui nous taient utiles pour laborer le
diagramme de classes global.
Dans le chapitre suivant, nous allons aborder le dernier chapitre consacr la

ralisation, dans lequel on va prsenter l'environnement de travail de notre projet, ainsi que
quelques interfaces reprsentants les fonctionnalits de notre application.
44
Chapitre 4 : Mise en uvre
Dans ce chapitre, nous prsentons ltude technique et la mise en uvre de la

solution. En effet, nous allons dans un premier temps dcrire le design pattern MVC et
larchitecture JEE dune part, et dune autre part larchitecture logicielle et les outils et
les Frameworks techniques utiliss pour le dveloppement. Ensuite, on va expliquer la
dmarche suivie durant la phase de ralisation. Finalement, nous allons illustrer
certaines fonctionnalits de lapplication travers quelques interfaces.
45
IV. CHAPITRE 4 : MISE EN OEUVRE
1. Le design pattern MVC

Le Modle-Vue-Contrleur organise l'interface Homme-machine d'une application
logicielle en un modle (objet mtier, encore modle de donnes), une vue (prsentation,
interface utilisateur) et un contrleur (logique de contrle, gestion des vnements,
traitement), chacun ayant un rle prcis dans l'interface. Ce design pattern impose la
sparation entre les donnes, la prsentation et les traitements, ce qui donne trois parties
fondamentales dans l'application finale : le modle, la vue et le contrleur [MVC].
2. Java Enterprise Edition

JEE est une plate-forme fortement oriente serveur et ddie au dveloppement et
l'excution d'applications distribues. Elle permet la simplification du processus de
dveloppement [JEE]. JEE permet une grande flexibilit dans le choix de l'architecture de
l'application en combinant les diffrents composants. Ce choix dpend des besoins
auxquels doit rpondre l'application mais aussi des comptences dans les diffrentes API
de JEE.
L'architecture d'une application se dcoupe idalement en au moins trois tiers :
La partie cliente : il sagit de la couche prsentation correspondante l'interface

homme machine (IHM), c'est la partie qui permet le dialogue avec l'utilisateur.
La partie mtier : c'est la partie qui encapsule les traitements (dans des EJB ou des
JavaBeans).
La partie donne : c'est la partie qui stocke les donnes dans des fichiers, dans des
bases de donnes relationnelles ou XML, dans des annuaires d'entreprise.
3. Outils et Frameworks utiliss
3.1. Le framework JSF 2.0

Java Server Faces est un Framework Java EE utilis pour le dveloppement
dapplications web. Il propose une librairie de composants pour le dveloppement de pages
46
web et une API de gestion de balise XHTML, dvnement, de conversion de donnes, de

validations de saisies, de dfinition de la navigation ou encore le support de
linternationalisation. JSF implmente larchitecture MVC, le modle reprsent par la
couche Managed Bean associ une entit de persistance, la vue est reprsente par les
pages XHTML et le contrleur par la Servlet Faces Servlet livre avec JSF.
3.2. Enterprise Java Beans (ejb 3)

Enterprise JavaBeans (EJB) est une architecture de composants logiciels ct
serveur pour la plateforme de dveloppement JEE.
Cette architecture propose un cadre pour crer des composants distribus (cest--
dire dploys sur des serveurs distants) crit en langage de programmation Java hbergs
au sein d'un serveur applicatif (conteneur EJB) permettant de reprsenter des donnes (EJB
dit entit), de proposer des services avec ou sans conservation d'tat entre les appels (EJB
dit session), ou encore d'accomplir des tches de manire asynchrone (EJB dit message).
Tous les EJB peuvent voluer dans un contexte transactionnel.
3.3. JPA 2.0

Java Persistance API (JPA) est un standard Java utilis pour la persistance des
donnes qui utilise le principe de mapping objet/relationnel afin de permettre de stocker les
objets dans la base de donnes, et inversement, de pouvoir lire les donnes relationnelles et
les transformer en objets. LAPI JPA 2.0 offre les services suivants :
La gestion de persistance,
Un langage de requtage volu : Java Persistance Query Language (JPQL),
Un mcanisme de mapping objet/relationnel ORM partir de mtadonnes
(fichiers XML ou annotations),
Une API typage fort pour le requtage.
3.4. Le Framework EclipseLink

EclipseLink est un Framework open source de mapping objet-relationnel (ORM)
pour les dveloppeurs Java. Il fournit une plateforme puissante et flexible permettant de
stocker des objets Java dans une base de donnes relationnelle et/ou de les convertir en
documents XML. Il supporte un certain nombre d'API relatives la persistance des
donnes et notamment la JPA.
47
3.5. Oracle 10g

Oracle est un SGBD (systme de gestion de bases de donnes) dit par la socit
du mme nom (Oracle Corporation), leader mondial des bases de donnes. Oracle permet
dassurer la manipulation, la confidentialit, lintgrit et la cohrence des donnes. Il gre
aussi les accs concurrents ainsi que la sauvegarde et la restauration des donnes.
4. Architecture technique
Larchitecture technique prsente les diffrents outils utiliss dans le
dveloppement de chaque partie du projet. La figure suivante prsente larchitecture
technique de notre application :
Figure IV-1: Larchitecture technique de l'application
La couche prsentation est constitue dun ensemble de composants JSF. Les JSF
Managed Beans sont utiliss pour faire le lien entre la couche prsentation et la couche
mtier. Ils permettent ainsi de rcuprer les donnes saisies par les utilisateurs, les valider
et les transmettre la couche mtier.
48
La couche mtier est un ensemble de composants EJB session qui encapsulent la

logique mtier de lapplication. Les EJB entits reprsentent le modle des donnes. Ceux-
ci sont directement persists dans la base de donnes grce lapi de persistance JPA.
5. Dmarche de dveloppement
Afin de mieux organiser la phase de mise en uvre, nous avons veill procder
par tapes. Ainsi, nous avons procd de la manire suivante pendant la phase de
dveloppement:
Crations de classes entits partir de la base de donnes :

Dans ce projet nous allons utiliser une base de donnes. On ne va pas manipuler
des donnes directement en SQL mais sous forme d'objets particuliers, objets persistants
qu'on appelle des "classes entits".
Gnralement, une classe entit correspond une table, elle porte le mme nom
(aux majuscules/minuscules prs), et ses attributs correspondent aux colonnes de la table.
Les instances de cette classe entit seront des objets correspondant des lignes dans cette
table.
Cration des Stateless Session Bean pour la gestion des classes entits :
La gestion des diffrentes classes entits sera centralise dans les Stateless Session
Bean. On va donc crer au niveau de chaque Stateless Session Bean une "faade" pour les
oprations lmentaires sur les entits (cration, suppression, recherche, modification),
ainsi que les diffrentes mthodes mtiers agissant sur les classes entits.
Cration des pages JSF et les Managed Bean associs :
Dans cette tape nous avons dvelopp les interfaces graphiques suivant le modle
quon a tabli dans la partie conception. Cette tape concerne linteraction entre le systme
et les requtes de lutilisateur travers les interfaces Homme-Machine que nous avons
dvelopp en utilisant les pages JSF (Facelet), chacune de ces interfaces est associe
une classe Managed Bean.
Une page JSF contient des balises qui dcrivent les composants qui reprsenteront
la page sur le serveur. Elle Contient aussi des parties en EL, et utilise souvent une (ou
plusieurs) bibliothque de composants, mais ne contient pas de traitements (pas de code
49
Java ou autre code comme dans les pages JSP pour crer les pages affiches
lutilisateur).
Un Managed Bean (dit aussi Backing Bean) assure les diffrents traitements lis
directement linterface utilisateur, et fait appels des EJB ou des classes Java ordinaires
pour effectuer les traitements qui ne sont pas lis directement linterface utilisateur.
Les Managed Beans associs aux pages JSF, font donc la liaison entre les
composants JSF de linterface, les valeurs affiches ou saisies dans les pages JSF et le
code Java qui effectue les traitements mtier.
6. Interfaces de lapplication
Durant cette section, nous prsentons un scnario dutilisation de lapplication par
quelques interfaces.
6.1. Authentification
Pour pouvoir accder au menu principal de lapplication, il est impratif de
sauthentifier, et cela en renseignant un identifiant et un mot de passe.
Figure IV-2: Interface de l'application: authentification
50
Lorsque lutilisateur se connecte, celui-ci voit safficher un menu, selon le

profil quil possde. Lutilisateur connect est redirig vers lcran contenant le menu
suivant :
Figure IV-3: Interface de l'application: Menu principal
On voit bien dans ce menu les diffrents modules de gestion que nous avons
dvelopps. Lutilisateur pour accder un module na qu cliquer sur licne
correspondante.
Dans ce qui suit on va prsenter les diffrentes interfaces reprsentant les

diffrentes fonctionnalits du module de gestion des tudiants.
51
6.2. Gestion des tudiants

Consultation de la liste des tudiants :
En accdant au module gestion des tudiants, lutilisateur est redirig vers une page
listant les diffrents tudiants enregistrs sous forme dun tableau, avec la possibilit de
consulter, modifier ou supprimer les informations concernant un tudiant, et cela en
cliquant sur licne correspondante chacune de ses action.
Pour ajouter un nouvel tudiant, lutilisateur na qu cliquer sur le bouton se

trouvant au-dessous du tableau.
Figure IV-4: Interface de l'application: liste des lves ajouts
Ajout dun nouvel tudiant :

En cliquant sur le bouton Ajouter un nouvel lve , une page contenant un
formulaire constitu de quatre onglets saffiche. Chaque onglet contient un ensemble
dinformations ncessaires pour enregistrer un lve.
Le premier onglet Informations personnelles contient le nom, prnom, genre,

code national lve, CIN ainsi que la date et le lieu de naissance.
Le deuxime onglet Contact contient ladresse, le tlphone et lemail de

llve. Le quatrime onglet quant lui contient des informations sur le parent de llve,
alors que le dernier onglet est utilis pour confirmer les informations saisies dans les
onglets prcdents.
52
Figure IV-5: Interface de l'application: formulaire d'ajout d'un lve
Consultation des informations dun lve :

En cliquant sur licne loupe , une page contenant les dtails dun lve sous
forme de tableau saffiche. Dans cette mme page lutilisateur a la possibilit de supprimer
ou de modifier les informations concernant llve.
Figure IV-6: Interface de l'application: afficher les informations un lve
53
Modifier les informations dun lve :

En cliquant sur licne stylo , un cran semblable celui de la consultation
saffiche, mais cette fois-ci, les diffrentes informations de llve sont ditables.
Figure IV-7: Interface de l'application: Modifier un lve
7. Conclusion
Ce chapitre avait pour but de dcrire lenvironnement technique et les diffrentes
tapes de la mise en uvre de lapplication.
En effet, nous avons dcrit dans un premier temps larchitecture technique.

Ensuite, nous avons recens les diffrentes tapes de la phase de dveloppement, et enfin
nous avons prsent quelques interfaces dcrivant certaines fonctionnalits de
lapplication.
54
Conclusion gnrale
Conclusion gnrale
Notre projet de fin dtudes que nous avons effectu au sein de VisualSoft,
consistait en ltude, lanalyse, la conception et la ralisation des modules de gestion des
tablissements, des lves, et des enseignants. Ces modules font partie du projet lanc par
le ministre des Habous et des affaires islamiques pour la mise en uvre dune solution
intgre de gestion de la scolarit dans les niveaux prscolaire, primaire, collgial,
secondaire et terminal de lenseignement traditionnel marocain.
Ce projet sest droul selon quatre phases. Dans la premire phase, nous tions
amens faire une tude fonctionnelle dont le but est de spcifier et danalyser les besoins.
Dans la deuxime phase nous nous sommes penchs sur la conception de notre systme
afin de bien structurer la couche mtier de lapplication. La troisime phase a t
consacre ltude technique o lon a dtaill larchitecture technique et les outils et les
Frameworks utiliss dans le dveloppement. Finalement, la quatrime phase a t
consacre la ralisation et la mise en uvre des diffrents modules de notre systme.
Lapproche de conduite de projet RUP quon a mis en uvre prend en compte les
changements continuels qui peuvent survenir lors de la ralisation, et cela pour que le
rsultat obtenu soit en accord avec les besoins rels des utilisateurs. Cette approche
combine avec lutilisation des Frameworks de dveloppement, permet de rduire
considrablement le cot ralisation et de la maintenance applicative, et aussi davoir une
architecture de lapplication qui se veut flexible et extensible, ce qui facilitera son
intgration avec les autres modules futurs dvelopper.
Ce stage a t pour nous loccasion de faire le lien entre nos connaissances

acadmiques et le monde professionnel. En effet, il nous a permis de dvelopper nos
comptences techniques, dapprofondir nos connaissances thoriques et les mettre en
pratique. Cette exprience a aiguis nos capacits danalyse et de synthse, et nous a
permis de renforcer nos connaissances concernant larchitecture JEE, notamment le
Framework JSF 2, les EJB ainsi que lAPI JPA.
Enfin, ce stage fut une exprience trs enrichissante pour nous sur les deux plans
personnels et professionnels. En effet, il a t loccasion de dcouvrir le dynamisme et
lenthousiasme qui caractrisent lquipe de VisualSoft. Les runions rgulires effectues
avec les encadrants VisualSoft nous ont permis de mettre en uvre les concepts de
gestion de projets acquis lEMI.
55
Bibliographie, Webographie
Bibliographie
Jrme LAFOSSE, Dveloppement n-tiers avec Java EE , dition ENI, collection
Epsilon (7 mars 2011).
Pascal Roques, UML2 : Modliser une application web , dition EYROLLES,

collection les Cahiers du Programmeur (4e dition : 02/10/2008).
Antonio Goncalves, Java EE 5 : EJB 3, JPA, JSP, JSF, GlassFish , dition

EYROLLES, collection les Cahiers du Programmeur (2e dition : 25/05/2007).
Webographie
[MVC] Model View Controller, disponible sur :
https://sites.google.com/site/floriangrisoni/informatique/design-pattern-
mvc
[JEE] Java Enterprise Edition, disponible sur :
http://www.jmdoudoux.fr/java/dej/chap-j2ee-javaee.htm#j2ee-javaee-1
[NetBeans] Getting Started with Java EE 6 Applications, disponible sur:
http://netbeans.org/kb/docs/javaee/javaee-gettingstarted.html
[JSF 2] JSF 2 Templating with Facelets example, disponible sur:
http://www.mkyong.com/jsf2/jsf-2-templating-with-facelets-example/
[EJB 3] EJB3 Introduction, disponible sur :
http://www.datadisk.co.uk/html_docs/ejb/ejb3_introduction.htm
Tutoriel : TP1 2011 EJB 3.1/JPA/JSF2, MIAGE Nice, diponible sur :
EJB3.1/JPA/J http://miageprojet2.unice.fr/Intranet_de_Michel_Buffa/Cours_composants
SF2 _distribu%C3%A9s_pour_l'entreprise_%2f%2f_EJB_2009/TP1_2011_EJ
B_3.1%2f%2fJPA%2f%2fJSF2
[EclipseLink] Tutorial : the basic steps of developing, packaging, and deploying a Web
application using the EclipseLink, disponible sur:
http://wiki.eclipse.org/EclipseLink/Examples/JPA/JSFTutorial
56
Annexe A : outils utiliss
Annexe A : Outils utiliss
Balsamiq, Mockups Version 2.1.15
Propose par les studios

Balsamiq, Mockups est une
application permettant de
concevoir des modles
d'interface. Entre l'outil de dessin
vectoriel et Microsoft Visio,
celle-ci donne la possibilit
l'utilisateur de travailler de
manire collaborative l'laboration de croquis dans lesquels il pourra placer des croquis, des
notes, des couleurs, des icnes, des fentres flottantes ainsi que divers outils.
Enterprise Architect Version 7.5
Enterprise Architect est un

outil d'analyse et de cration
UML, couvrant le
dveloppement de logiciels
du rassemblement
d'exigences, en passant par
les tapes d'analyse, les
modles de conception et les
tapes de test et d'entretien.
Cet outil graphique bas sur Windows, peut tre utilis par plusieurs personnes et conu pour
vous aider construire des logiciels faciles mettre jour. Il comprend un outil de production
de documentation souple et de haute qualit.
57
Annexe A : outils utiliss
NetBeans IDE Version 7.1.2
NetBeans IDE est un environnement de

dveloppement qui s'adapte aux langages de
programmation (Javascript, Python, PHP,
Groovy, C/C++, etc.), aux outils et aux
ressources dont vous disposez. Le programme
dtecte automatiquement la prsence de Java,
JDK, SOA, Ruby, MySQL, etc. sur votre systme, ainsi que les serveurs Apache ou
GlassFish, pour vous fournir les plugins ncessaires. Vous pourrez ainsi crer facilement des
applications Web, des portails d'entreprise, des logiciels multiplateforme sous Java, des
logiciels pour mobiles, etc. Vous disposerez de nombreux outils d'dition, d'un debugger,
d'une module de prvisualisation, de modles et de bibliothques, de fonctions de compltion
et d'implmentation, etc. La dernire version de NetBeans IDEsupporte dornavant les
spcifications du langage de dveloppement Java SE 7. Il s'intgre galement avec les
serveurs Oracle WebLogic et supporte Oracle Database et GlassFish 3.1. On note au passage
la facilit d'dition HTML5 et un nouveau GridBagLayout conu pour amliorer le
dveloppement d'interfaces utilisateur et l'dition de code Java.
Adobe Dreamweaver CS5
Adobe Dreamweaver CS5 propose aux dveloppeurs Web une

plateforme de dveloppement pour la cration de sites et
d'applications Web. Le logiciel propose d'utiliser des outils
d'inspection CSS pour la conception et de dvelopper et amliorer
des systmes de gestion de contenus tels que Joomla, Wordpress
ou encore Drupal. Adobe Dreamweaver CS5 dispose galement
d'un module de tests de compatibilit avec les navigateurs grce
l'intgration avec Adobe BrowserLab.
58
Annexe B : Le cycle de vie phases multiples dune page JSF
Aprs une prsentation rapide de la notion de cycle de vie phases multiples dune
page JSF, cette annexe dcrit chacune des phases en question. Elle apporte des informations
purement thoriques, expliquant comment une application JSF assure la prise en charge de la
gestion des vnements ainsi que la conversion et la validation des donnes.
Principe :
Le cycle de vie dune page JSF est partitionn en plusieurs phases, dans le but de
pouvoir rpondre efficacement aux attentes lies cette technologie: capture dvnements au
niveau des composants graphiques, validation ou conversion de composants, liaison entre
composants dinterface et objets sexcutant ct serveur. Deux types de requtes doivent tre
distingus :
la requte initiale au cours de laquelle linternaute accde pour la premire fois la page
JSF,
la requte dite postback correspondant le plus souvent la validation dun formulaire pr
cdemment charg dans le navigateur du client.
Prsentation des diffrentes phases :
59
a) Phase de restitution de la vue (Restore view) :
Ds quun internaute tente datteindre une page JSF, la phase de restitution de vue est
excute. Son but est dassocier une vue la page visite. Lapplication web cre une vue
vierge dans le cas dune requte initiale; elle restitue la vue prcdemment associe la page
dans le cas dune requte postback. Tous les gestionnaires dvnements ainsi que les
validateurs requis par les composants graphiques de la page sont lis la vue. Un arbre de
composants est constitu. La vue est ensuite sauvegarde dans lobjet prdfini FacesContext.
b) Phase Application des paramtres de requte (Apply request values)
lissue de la phase prcdente, une vue est associe la page JSF visite. Cette vue
dispose obligatoirement dun arbre de composants. Ces composants sont alors parcourus
successivement pour invoquer leur mthode decode(). Celle-ci est charge danalyser la
requte pour attribuer au composant la valeur qui doit lui tre affecte.
la fin de cette phase, tous les composants associs la vue disposent dune nouvelle
valeur. Les messages
etlesvnementsventuelssontenattentedetraitementparlobjetFacesContext.
c) Phase Processus de validation (Process Validation)
Dans cette tape, lapplication JSF effectue toutes les validations attendues pour
chacun des composants de larbre associ la vue.
Pour cela, les attributs de composant dfinissant les rgles de validation sont
examines, puis compars la valeur du composant. Lorsque cette valeur est effectivement
incorrecte, un message derreur est ajout lobjet FacesContext et le cycle de vie se poursuit
directement par la phase de traduction de la rponse: la page web est alors restitue
linternaute, accompagne du message derreur issu du processus de validation.
d) Phase Mise jour du modle (Update Model Values)
Chaque composant dinterface JSF peut tre associ un JavaBean ct serveur.

Aprs stre assure de la validit des donnes saisies lors de la phase Processus de validation,
lapplication JSF parcourt nouveau larbre de composants pour affecter la valeur de chaque
composant graphique au JavaBean qui lui est associ. L encore, si un problme de
60
conversion survient au moment de la mise jour de la proprit du JavaBean, le cycle de vie

de la page se poursuit directement par la phase de traduction de la rponse et un message
derreur adapt est prsent linternaute.
e) Phase Appel de lapplication (Invoke application)
Lorsque linternaute valide un formulaire, ou clique sur un lien hypertexte,

lapplication JSF gnre respectivement un objet de type "vnement de formulaire" ou un
objet de type "vnement de commande". Ces objets sont qualifis dvnements de niveau
application : ils sont pris en charge par des gestionnaires spcifiques au cours de cette phase
dont le rle est de mentionner une URL vers laquelle la navigation est dirige.
f) Phase de restitution de la rponse (Render response)
Cette phase correspond au moment o limplmentation Java Server Faces rend la

main au conteneur en charge des pages JSP de lapplication web. Tous les composants sont
alors prsents dans linterface utilisateur, dans ltat qui est le leur au moment o survient la
phase Render response
61
Annexe C : Les maquettes

Une maquette est un produit jetable donnant aux utilisateurs une vue concrte mais
non dfinitive de la future interface de lapplication. Cela peut consister en un ensemble de
dessins raliss avec des outils spcialiss tels que Dreamweaver, Adobe Illustrator ou plus
simplement avec Powerpoint ou mme Word. Par la suite, la maquette intgrera des
fonctionnalits de navigation pour que lutilisateur puisse tester lenchanement des
crans, mme si les fonctionnalits restent fictives.
La maquette est dveloppe rapidement afin de provoquer des retours de la part des
utilisateurs. Elle permet ainsi damliorer la relation dveloppeur-client. La plupart du temps,
la maquette est considre comme jetable, cest--dire que la technologie informatique
employe pour la raliser nest pas forcment assez robuste et volutive pour tre intgre
telle quelle. Pensez lanalogie de la maquette davion qui est trs utile en soufflerie, mais
qui ne peut pas voler !
Dans un premier temps, les besoins ont t modliss au moyen des cas dutilisation
UML. Ils seront maintenant reprsents de faon plus concrte par une maquette dIHM
(Interface Homme-Machine) destine faire ragir les futurs utilisateurs. Les figures
(Maquette de la page "Ajouter un lve") (Maquette de la page "rechercher lve") montrent
les maquettes que nous avons ralis.
On a essay de respecter les rgles et les standards dIHM des pages web savoir :
une entte qui se compose dun logo cliquable renvoyant au menu principal, un menu
horizontal, un menu vertical, on a aussi reprsent des informations sur lutilisateur avec la
possibilit de se dconnect partir de nimporte quelle page de notre application, un fil
dAriane (Breadcrumb) [une aide la navigation sous forme de signalisation de la
localisation de linternaute dans une page dun site web. Leur but est de donner aux
utilisateurs un moyen de garder une trace de leur emplacement l'intrieur dun site web], et
un pied de page.
62
Maquette de la page "Ajouter un lve"
Maquette de la page "rechercher lve"
63
class Diagramme de classes V2
Adresse
MotifAbscence
- adresse: string
Elev eTuteur - motif: string
- ville: string
- codePostal: long - image: image
1 - fonction: string
- adresseAr: string
- pays: string = Maroc 0..*
1
+ Adresse() Elev eParent
AbscenceElev e
1 - fonction: string
Possde - dateDebut: Date
- dateFin: Date
- justifiee: boolean
0..2 - remarque: String
Personne
1..*
- nom: string
- prenom: string
Elev e 1..* SeanceCours
- email: string
- dateNaissance: Date - CNE: long - dateDebut: date
- lieuNaissance: string - boursier: boolean 0..* 0..* - duree: date
- telDomicile: string - noInternat: string - typeSeance: string
Annexe D : Diagramme de classes global
- nomAr: string - abandon: boolean

- prenomAr: string - id: int 0..* 0..*
- genre: boolean
0..*
- CIN: string
- Image: Image Note 0..*
- telMobile: string
- note: float 0..* 1..* Inscription
+ getNom() : string - appreciation: string
+ Personne() Appartient
1..*
Annexe D : Diagramme de classes global
Parcours_scolaire
Enseignant 1 1
- echelle: string
- echelon: string 0..* Classe
0..*
- designation: string 0..*
enseigne
- capaciteAcceuil: int
0..* - nombreEleves: int Bulletin
- appreciation: string
- /noteFinale: float
1..* 0..* 0..*
1
0..1 AnneeScolaire
0..* 0..*
1
- dateDebut: date
Matiere - dateFin: date
- designation: string 1
1 - cloturee: boolean
- coefficient: float
Niv eau 1
Cycle
- designation: String Periode
1 1..* 0..3
Etablissement 0..* 1..5 - dateDebut: date
- nom: string - dateFin: date
- noAutorisation: string - cloturee: boolean
- statut: boolean Local Magasin
Employe - capacite: int
0..* 0..* 1 0..*
- salaire: float
- responsable: Employe [0..*]
- decede: boolean Cuisine
- nbreEnfant: int Internat Chambre
- designation: string - designation: string
- capaciteAccueil: int 1 1..*
- genre: boolean
- exploitable: boolean
Salle SalleDeCours Diplome
Cadre_administratif Agent
- designation: string SalleDeBureau
Refectoire - capaciteAccueil: int - designation: string
- fonction: string - fonction: string
Bibliotheque - proprietaire: Personne[0..*] - nbrePaillasses: int - dateObtention: date
- grade: string
- note: string - disponibilite: boolean - lieuObtention: string
- note: string - mention: string
- note: string
0..*

Vers Une Solution Intégrée de Gestion de La Scolarité Des Établissements de L'enseignement Traditionnel

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

Vers Une Solution Intégrée de Gestion de La Scolarité Des Établissements de L'enseignement Traditionnel

Transféré par

Droits d'auteur :

Formats disponibles

Ddicace

mes chers parents, ma grande mre

Je nose pas imaginer une expression qui puisse rsumer ma gratitude

Que ce travail soit pour vous un tmoignage de ma vive reconnaissance et de

mon cher frre Nouaman et

mes amis, lEMI,

tous ceux qui maiment

Je vous remercie du fond du cur.

Projet de fin dtudes 2011/2012

Jai une dette particulire envers ma chre mre dont le soutien et la

sagesse mont guid depuis ma naissance et me

mon cher pre

Sans qui je ne serais jamais l o jen suis.

mes trs chers amis de lEMI,

tous ceux qui maiment.

Projet de fin dtudes 2011/2012

Il nous est agrable dexprimer notre reconnaissance auprs de toutes les

Nous remercions galement Mlle Awatif BRIGUI laurat de lEMI de nous

La disponibilit, la gentillesse et la gnrosit de M. Abderrahim HASBI dont les

Nos remerciements sadressent galement tout le corps professoral de lcole

Projet de fin dtudes 2011/2012

Projet de fin dtudes 2011/2012

Projet de fin dtudes 2011/2012

Projet de fin dtudes 2011/2012

Projet de fin dtudes 2011/2012

Projet de fin dtudes 2011/2012

Projet de fin dtudes 2011/2012

Table des matires

I. Chapitre 1 : Contexte Gnral du Projet ................................................................. 3

3. Conduite du projet : Mthode RUP (Rational Unified Process) ...................................... 8

II. Chapitre 2 : tude fonctionnelle........................................................................... 12

2. Analyse du contexte .................................................................................................. 14

III. Chapitre 3 : Conception ....................................................................................... 32

3. Le package Gestion des tablissements ................................................................ 40

Projet de fin dtudes 2011/2012

IV. chapitre 4 : Mise en oeuvre.............................................................................. 46

4. Architecture technique .............................................................................................. 48

Projet de fin dtudes 2011/2012

Dans ce cadre, le ministre des Habous et des affaires islamiques a pass

Notre mission dans ce stage au sein de VisualSoft, consiste en lanalyse, la

Le prsent rapport se compose de quatre chapitres. Le premier dfinit le contexte

Le deuxime chapitre prsente une tude fonctionnelle dont lobjectif est de

Le troisime chapitre sintresse la conception des diffrents modules de notre

Finalement, une conclusion rcapitule le travail accompli dans le cadre de ce projet

Chapitre 1 : Contexte Gnral du Projet

Ce chapitre prsente le contexte, la motivation et les objectifs de notre projet de fin

I. CHAPITRE 1 : CONTEXTE GENERAL DU PROJET

1. Prsentation de lorganisme daccueil

Ce rapprochement quoffre IT Group entre la gouvernance des systmes

Le conseil et lassistance en informatique, et ltude et la mise en place de systmes

Le dveloppement de sites Web, ainsi que la conception et la mise en place de

Figure I-1 : Organigramme dIT Group

2. Prsentation gnrale du projet

Lapproche retenue pour la ralisation de ce projet de grande envergure, exige une

2.1. Contexte organisationnel

La Direction de lEnseignement Traditionnel pour les activits de consolidation, suivi,

La Direction de lEnseignement Traditionnel a notamment pour mission de :

Fixer la stratgie pdagogique relative l'enseignement traditionnel;

Contrler et valuer l'excution des programmes et des mthodes ;

Direction de lEnseignement Traditionnel

Figure I-2 : Organigramme gnral de la Direction de lEnseignement Traditionnel :

2.2. Structure et statistiques

Le prscolaire, o le cursus normal est de 2 ans (les tablissements prscolaires sont