Gestion D'un Centre de Formation

Mmoire de Projet de Fin dAnne
Pour lObtention du Diplme BAC+4 en

Ingnierie des Systmes dInformatiques

Sujet
Gestion dun Centre de Formation

Soutenu par : Sous la direction de :
Mr. Ech-Charafi Yassine Mr. Zellou Ahmed
Mr. Hammani Mourad

Anne Universitaire 2012-2013

2

Ddicace

Nous ddions ce travail :

A Nos chers parents que nous remercions de tous nos curs pour
leurs conseils qui nous ont guids tout au long de notre chemin
dtude;

A Notre encadrant qui nous as normment aid et soutenu tout au
long de la ralisation de travail.

A Nos enseignants pour leurs formations, leurs conseils et leurs aides.

A Nos amis pour leurs encouragements et soutien.

A ceux qui nous ont indiqus la bonne voie en nous rappelant que la
volont fait toujours les grandes personnes.

3

Remerciements

Si jai vu plus loin, cest en me tenant sur les paules des gants qui mont prcd
Isaac Newton

Nous tiendrons remercier dans un premier temps, Monsieur Ahmed ZELLOU pour laide
et les conseils fournis lors des diffrents suivis se rapportant aux missions voques dans ce
rapport.

Nous remercions galement toute lquipe pdagogique de SUPMIT et tous les intervenants
professionnels pour avoir assur la partie thorique de notre formation.

Nous remercions dans un dernier temps nos ami(e)s et toutes les personnes qui ont contribu
de prs ou de loin la conception et au bon droulement de ce travail.

4
Rsum

Ce document prsente notre Projet de Fin dAnne dans le cadre du diplme BAC+4 en
Ingnierie des Systmes dInformatiques de SUPMTI. Il a pour objectif dappliquer nos
acquis et connaissances.

Il nous a t confi la ralisation dune application Web offrant des services de Gestion dun
centre de formation.

Ce projet est destin aux bnficiaires dsirant faire linscription en ligne dans des diffrentes
formations, il propose une solution complte :
Une application volue base sur un modle mtier pour la prsentation des
formations.
La gestion et mise en relation entre les formateurs, bnficiaires et les formations.
Lajout et la gestion des thmes, catalogues et les formations.

Pour la ralisation de ce projet, nous avons adopt le processus de dveloppement 2TUP qui
fait une large place la technologie et la gestion du risque, nous avons aussi utilis le
langage UML pour la modlisation.
En ce qui concerne le dveloppement, nous avons utilis le langage Php5, JavaScript et Ajax
et MySQL pour la base de donnes.

Dans le prsent document nous allons dcrire plus en dtail les tapes que nous
avons ralises dans le cadre de notre projet.

Mots-cls : Centre de formation, 2TUP

5

Abstract

This document presents our Final Project Year in the degree BAC +4 Engineering of
Information Systems SUPMTI. It aims to apply our learning and knowledge.

We have been entrusted the creation of a website offering services management training
center.

This project was designed for beneficiaries who wishing to register online in different
formations, it offers them a complete solution:
An evolved web site based on a business model for the presentation of formations.
The management and interaction between trainers, beneficiaries and formations.
The insertion and management themes, catalogs and formations.

For this project we adopted the process 2TUP development has a strong focus on technology
and risk management, we also used the UML for modeling.
Concerning the development, we used Php5, JavaScript and Ajax and MySQL for the
database.

In this paper we will describe in more detail the steps we have made in our project.

6

Liste des abrviations

Abrviation Dsignation
2TUP 2 Track Unified Process
AJAX Asynchronous JavaScript and XML
BPMN Business Process Model and Notation
CSS Cascading Style Sheets
DOM Document Object Model
FTP File Transfer Protocol
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IHM Interface Homme Machine
LDAP Lightweight Directory Access Protocol
MSP Microsoft Project
MVC Model View Controller
OMG Object Management Group
PBS Product Breakdown Structure
PHP Hypertext Preprocessor
RUP Rational Unified Process
SQL Structured Query Language
UML Unified Modelling Language
XML Extensible Markup Language
XP Extreme Programming
XSL Extensible Stylesheet Language

7
Table des figures

Figure 1: Le processus de dveloppement en Y ....................................................................... 17
Figure 2: Lorganigramme PBS ............................................................................................... 19
Figure 3: Planning prvisionnel du projet ................................................................................ 20
Figure 4: Branche fonctionnelle du processus Y ..................................................................... 28
Figure 5: Diagramme de cas d'utilisation ................................................................................. 30
Figure 6: Diagramme de squence (Authentification) ............................................................. 31
Figure 7: Diagramme de squence (Ajouter Formation) ......................................................... 32
Figure 8: Diagramme de squence (S'inscrire) ........................................................................ 33
Figure 9: Diagramme de squence (S'inscrire dans formation) ............................................... 34
Figure 10: Diagramme de squence (S'inscrire comme Formateur) ........................................ 35
Figure 11: Branche technique du processus Y ......................................................................... 37
Figure 12: Architecture 3 tiers ................................................................................................. 39
Figure 13: Architecture du dsigne pattern MVC ................................................................... 44
Figure 14: Phase de mise en uvre dans le processus Y ......................................................... 47
Figure 15: Architecture logicielle du projet ............................................................................. 48
Figure 16: Diagramme de classes ............................................................................................. 52
Figure 17: L'interface d'accueil de l'application ....................................................................... 53
Figure 18: L'interface d'authentification .................................................................................. 54
Figure 19: L'interface de cration d'un profil formateur .......................................................... 54
Figure 20: L'interface d'ajout d'une formation ......................................................................... 55
Figure 21: L'interface de lister et grer des bnficiaires ......................................................... 55

8
Liste des tableaux

Tableau 1: Tableau comparatif entre les processus de dveloppement ................................... 16
Tableau 2: Liste des acteurs ..................................................................................................... 26
Tableau 3: Les vues de l'application ........................................................................................ 49
Tableau 4: Description de la classe formateur ......................................................................... 51
Tableau 5: Description de la classe formation ......................................................................... 51

Table des matires
9
Table des matires

Introduction gnrale ................................................................................................................ 11
Prsentation de la structure daccueil ....................................................................................... 14
1.1 Mission ........................................................................................................................ 14
1.2 Description .................................................................................................................. 14
Contexte du projet .................................................................................................................... 15
Conduite du projet .................................................................................................................... 15
1.3 Processus de dveloppement ....................................................................................... 15
1.4 Langage de modlisation ............................................................................................. 18
1.5 Planification du projet ................................................................................................. 18
1.5.1 Structure de rpartition du produit (PBS) ............................................................ 19
1.5.2 Diagramme de Gantt ............................................................................................ 19
Conclusion ................................................................................................................................ 20
1 Cahier des charges .............................................................................................................. 22
1.1 Introduction ................................................................................................................. 22
1.2 Prsentation gnrale du projet ................................................................................... 22
1.3 Recueil des besoins fonctionnels ................................................................................. 23
1.4 Recueil des besoins oprationnels ............................................................................... 25
2 Identification des acteurs .................................................................................................... 26
3 Conclusion .......................................................................................................................... 26
1 Ltude fonctionnelle dans le processus Y ......................................................................... 28
2 Capture des besoins fonctionnels ....................................................................................... 28
3 Diagrammes de cas dutilisation ........................................................................................ 29
Diagramme de squence ........................................................................................................... 31
Conclusion ................................................................................................................................ 35
1 Ltude technique dans le processus Y .............................................................................. 37
2 Capture de besoin technique .............................................................................................. 37
2.1 Spcification technique ............................................................................................... 38
2.1.1 Spcification darchitecture .................................................................................. 38
2.1.2 Architecture 3-tiers ............................................................................................... 39
Conception gnrique ............................................................................................................... 40
2.2 Technologies et outils utilises ................................................................................... 40
2.2.1 PHP ....................................................................................................................... 40
Table des matires
10
2.2.2 JavaScript ............................................................................................................. 41
2.2.3 AJAX .................................................................................................................... 41
2.2.4 Microsoft Project .................................................................................................. 42
2.2.5 Dreamweaver ....................................................................................................... 42
2.2.6 Enterprise Architect .............................................................................................. 43
2.2.7 XAMPP ................................................................................................................ 43
2.3 Design patterns ............................................................................................................ 44
2.3.1 MVC ..................................................................................................................... 44
Conclusion ................................................................................................................................ 45
1 La mise en uvre dans le processus Y .............................................................................. 47
2 La Conception prliminaire ............................................................................................... 47
2.1 Architecture logicielle implmente ........................................................................... 48
2.2 numrations des vues de lapplication ...................................................................... 48
3 La Conception dtaille ..................................................................................................... 49
3.1 Classes mtiers dtailles ............................................................................................ 50
3.1.1 Conception des classes ......................................................................................... 50
3.1.2 Conception des attributs ....................................................................................... 50
3.1.3 Description des classes ......................................................................................... 50
3.1.4 Diagramme de classes .......................................................................................... 52
4 Ralisation .......................................................................................................................... 53
4.1 Implmentation des IHM ............................................................................................ 53
4.1.1 Linterface daccueil de lapplication .................................................................. 53
4.1.2 Linterface dauthentification ............................................................................... 54
4.1.3 Linterface de cration dun profil formateur ..................................................... 54
4.1.4 Linterface dajout dune formation ..................................................................... 55
4.1.5 Linterface de lister et grer des bnficiaires ..................................................... 55
Conclusion gnrale et perspective .......................................................................................... 57
Bibliographie et Webographie ................................................................................................. 58

Introduction gnrale
11

Introduction gnrale

Aujourd'hui, vu l'intrt croissant de vouloir gagner en temps, de conserver les donnes en
toute scurit, de limiter le nombre d'employs et bien d'autres raisons, ont pouss petites,
moyennes et grandes entreprises chercher des solutions informatiques capables de rpondre
leurs besoins.

Dans ce cadre s'inscrit notre projet de fin danne qui consiste de raliser une solution web
destine la gestion des formations des diffrents thmes.

La solution mettre en place sera compose dun modle mtier pour la prsentation du
catalogue des formations, la gestion des bnficiaires, des formateurs, et les relations entre les
diffrents intervenants.

Afin dadopter des lments de rponse cette demande, le prsent mmoire dtaille travers
ses diffrents chapitres la dmarche adopte et les rsultats atteints. Le prsent rapport
comporte quatre chapitres :

Le premier chapitre sera consacr au contexte gnral du projet, nous prsentons lcole
SupMTI ainsi nous dfinissons la conduite suivre, en choisissant une mthode pour le
processus de dveloppement (la mthode en Y), toute en respectant une planification bas sur
deux mois.

Dans le deuxime chapitre on va faire une tude prliminaire, on posant le cahier des charges
tout en spcifiant les acteurs (Administrateur, Formateur, Bnficiaire). Enfin, nous
dterminons les jalons de la capture des besoins du systme.

Introduction gnrale
12
Dans le troisime chapitre qui est consacr ltude fonctionnelle, nous nous intressons la
capture des besoins fonctionnels, ensuite nous ralisons la description des cas dutilisation et
la description de squence des scnarios les plus importants (ajouter formateur par exemple).

Au niveau du quatrime chapitre, nous allons aborder dune part la description de la
spcification technique par le choix dun style darchitecture en 3-tiers, et dautre part, les
technologie et les outils utilises comme PHP, JavaScript, Ajax, Dreamweaver, Xamppen
utilisant la mthode darchitecture MVC.

Le cinquime chapitre concrtisera le modle de conception entam lors des prcdents
chapitres, surtout en des couches applicatives et des interfaces homme/machine (interface
dajout dune formation par exemple).

Dans la conclusion, nous synthtisons le travail ralis et numrons les perspectives
envisages (dveloppement dune solution de E-Learning par exemple).

13

Chapitre 1

Contexte gnral du projet

Ce chapitre prsente le sujet du projet. Et prcise lobjectif et la conduite du projet
ainsi que le planning gnral de la ralisation.

Chapitre 1 Contexte gnral du projet
14

Prsentation de la structure daccueil
Ecole suprieure de Management, dInformatique et de Tlcommunication
1.1 Mission
Lcole suprieure de Management, dInformatique et de Tlcommunication, SupMIT, a
pour mission dassurer une formation dexcellence aussi bien thorique et pratique dans les
domaines lis au management et des systmes dinformation et de tlcommunication.
Lcole SupMIT est convaincue qu'une formation de qualit passe par une comprhension et
une proximit du monde conomique. Cette proximit favorise linnovation scientifique et la
qualit pour une insertion russie dans le monde du travail. de part lexprience de son quipe
pdagogique, SupMIT reprsente un pont entre les savoirs de luniversit et les attentes
oprationnelles des entreprises.
Tout au long du cursus, sont offerts aux futurs laurats :
Des enseignements d'ouverture sur le monde conomique, depuis les jeux de
simulation et de gestion d'entreprise jusqu'aux cours de sensibilisation l'thique
industrielle.
Des stages obligatoires dans le monde professionnel.

1.2 Description
Pour rpondre aux exigences d'un enseignement de haut niveau la quasi-totalit des
professeurs SupMIT sont titulaires d'un Doctorat ou d'un PhD et issus des grandes coles :
ENSIAS, INPT, EMI, ISCAE, ENSG.)
Dots d'expriences professionnelles en entreprise ou en socits de conseil, remarques pour
leurs travaux de recherche et leurs publications au niveau national et international, ils
apportent une relle valeur ajoute aux enseignements qu'ils dispensent.

Plusieurs enseignants sont certifis sur plusieurs nouvelles technologies. Ils prparent ces
tudiants la certification sur des produits en forte demande sur le march :
CISCO
Microsoft
HP

15
Contexte du projet
Notre projet a t ralis au sein de lcole SupMIT, il a pour but de dvelopper une
application dinscription en ligne des formations varies au domaine informatique.

Cette application contient des diffrents modules :

Module Administrateur : cest lui qui fait la totalit de la gestion dapplication,
parmi ces missions gestion des formations, gestion des bnficiaires, gestion des
formateurs.

Module Bnficiaire : cest un acteur majeur pour lapplication, il peut sinscrire
sans rserver une formation ou bien il peut sinscrire au moment de la
rservation. Aprs la rservation, il a le droit de modifier ou supprimer une
rservation.

Module Formateur : sa principale mission est dassist une formation aprs
linscription, ou bien linscription sans engager une formation.

Tous ces acteurs ont besoin dauthentifier avant chaque opration.

Conduite du projet
Afin de mieux organiser le droulement des activits du projet, nous avons suivi une
dmarche de gestion de projet pour aboutir aux objectifs en organisant le droulement
temporel des taches, partir de llaboration du cahier des charges la ralisation du produit
souhait.

1.3 Processus de dveloppement

En gnral, la gestion dun projet informatique consiste choisir un processus de
dveloppement adquat. Ce dernier constitue un facteur dterminant dans la russite dun
projet, du fait quil cadre ses diffrentes phases et caractrise les principaux traits de sa
conduite.

Pour cela le choix dune mthode de dveloppement adquate aux exigences fonctionnelles,
techniques et qualitatives dun projet doit tre labor au pralable afin dobtenir un produit
16
qui rpond aux besoins et attentes des utilisateurs.

Devant une multitude de mthodologies disponibles, le choix devient difficile, Pour cela,
nous tions amenes effectuer un benchmarking entre les principaux processus.

Le tableau 1 suivant prsente une tude comparative entre diffrents processus :

Description Points Forts Points Faibles
RUP
RUP est la fois une
mthodologie de conduite et de
dveloppement de projets et un
outil prt l'emploi
Propose des modles de
documents, et des canevas
pour des projets types
Coteux personnaliser.
Trs ax processus, au dtriment
du dveloppement : peu de place
pour le code et la technologie
XP
XP est une mthode agile plus
particulirement oriente sur
l'aspect ralisation d'une
application, sans pour autant
ngliger l'aspect gestion de
projet
Prparation des phases de
vrification au moment de
lAnalyse et de la Conception
Obligation de la prsence du
client Dveloppement en
binme.
2TUP
2TUP propose un cycle de
dveloppement en Y, qui
dissocie les aspects techniques
des aspects fonctionnels
Fait une large place la
technologie et la gestion
du risque
Ne propose pas de documents
types
Tableau 1: Tableau comparatif entre les processus de dveloppement

Nous constatons que toutes ces mthodologies proposent de travailler de faon itrative, que
ce soit au niveau des plannings, des spcifications ou du dveloppement. Si l'itratif s'est
impos, c'est parce qu'il rduit la complexit de ralisation des phases en travaillant par
approches successives et incrmentales.

Il est alors possible de prsenter rapidement aux utilisateurs des lments de validation. De
plus, l'itratif permet une gestion efficace des risques en abordant, ds les premires itrations,
les points difficiles. Le choix de la technologie et de larchitecture logicielle et applicative de
notre futur systme est lune des phases les plus importantes de notre projet vu le degr lev
de sa complexit technique. Ainsi 2TUP semble tre le mieux adapt pour mener bien notre
projet, puisquil rserve une branche entire aux aspects techniques dans le processus de
dveloppement.
Le processus 2TUP propose un cycle de dveloppement en Y, qui dissocie les aspects
techniques des aspects fonctionnels. Illustr en figure 1, le processus en Y s'articule autour de
3 branches [Roques & Valle, 2007] :
17
Une branche fonctionnelle
Une branche technique
Une phase de ralisation

Figure 1: Le processus de dveloppement en Y

La branche fonctionnelle capture des besoins fonctionnels pour laborer un modle des
besoins focaliss sur le mtier des utilisateurs. Elle qualifie au plus tt le risque de produire un
systme inadapt aux utilisateurs. De son ct, la matrise duvre consolide les
spcifications et en vrifie la cohrence et lexhaustivit de lanalyse, qui consiste tudier
prcisment la spcification fonctionnelle de manire obtenir une ide de ce que va raliser
le systme en termes de mtier. Les rsultats de lanalyse ne dpendent daucune technologie
particulire.
Quant la branche technique, elle permet de rassembler les besoins techniques (scurit,
monte en charge, intgration l'existant..).Elle propose galement une architecture logicielle
et applicative qui rpond aux contraintes prsentes dans le dossier technique. Et enfin elle
permet de proposer des rgles de dveloppement afin d'industrialiser l'implmentation
(gestion des exceptions, rgles de nommage, rgles de codage, ...).
18
La troisime branche comporte la conception qui intgre le modle danalyse et de
larchitecture technique puis tudie comment raliser chaque composant. Elle comporte aussi
ltape de codage qui produit ces composants et teste les units de codes ralises et ltape de
validation qui consiste enfin valider les fonctions du systme dvelopp.

1.4 Langage de modlisation
UML (langage de modlisation unifi) est un concept permettant de modliser un problme de
faon standard. Ce langage est n de la fusion de plusieurs mthodes existant auparavant, et
est devenu dsormais la rfrence en terme de modlisation objet, un tel point que sa
connaissance est souvent ncessaire pour obtenir un poste de dveloppeur objet.

UML se dcompose en plusieurs sous-ensembles :
Les vues : Les vues sont les lments observables du systme. Elles dcrivent le
systme d'un point de vue donn, qui peut tre organisationnel, dynamique,
temporel, architectural, gographique, logique, etc. En combinant toutes ces vues il
est possible de dfinir (ou retrouver) le systme complet.
Les diagrammes : Les diagrammes sont des graphiques. Ceux-ci dcrivent le
contenu des vues, qui sont des notions abstraites. Les diagrammes peuvent faire
partie de plusieurs vues.
Les modles d'lment : Les modles d'lment sont les briques des diagrammes
UML, ces modles sont utiliss dans plusieurs types.

1.5 Planification du projet
Conduire un projet, cest assur le pilotage dun processus de changement avec des ressources
ddies en optimisant les comptences, lorganisation, les systmes et les outils de conduite.
Une approche managriale ractive, souple et systmatique pour mener bien des
changements importants, complexes, cibls sur le but atteindre, il y a trois niveaux de
gestion de projet : la gestion de la production, des ressources et du temps. A fin de satisfaire
ce dernier critre quest la gestion du temps, il est ncessaire dtablir un planning
prvisionnel. Sachant que la ressource affecte ce projet est llve ingnieur et que le
prsent planning est rajust au fur et mesure de lavancement du projet.
La premire tape de notre projet a t danalyser des besoins fonctionnels du systme en
tudiant les spcifications de notre projet. Cette tape nous a permis de dgager les besoins
fonctionnels du projet. Ensuite, nous avons effectu des recherches sur larchitecture
19
logicielle afin de choisir lenvironnement de dveloppement le plus adquat aux exigences
techniques de notre application.
La seconde tape a t de proposer la modlisation du systme, puis la dernire tape a t de
mettre en uvre lenvironnement et implmenter notre application.

1.5.1 Structure de rpartition du produit (PBS)
Conformment aux exigences fonctionnelles spcifies dans le cahier des charges, le projet
peut tre dcompos en cinq grandes phases savoir : le dmarrage et linitialisation,
Lanalyse et la conception, le dveloppement, les tests, le dploiement et clture du projet.
Chaque phase est dcompose en un ensemble dactivits, et donne en rsultat un ou plusieurs
livrables comme montre la figure 2 :

Figure 2: Lorganigramme PBS

1.5.2 Diagramme de Gantt
La Figure suivant prsente sommairement le planning des tapes du droulement de notre
projet Figure 3 :

20

Figure 3: Planning prvisionnel du projet

Conclusion
Apres avoir survol le contexte gnral dans lequel sinscrit notre projet dans cette premire
partie de ce mmoire, la dmarche prconise pour les raliser, la description des besoins du
projet, ltude fonctionnelle sera dtaille dans le chapitre suivant.

21

Chapitre 2

Etude Prliminaire

Ce chapitre a pour objectif de dterminer les jalons de la capture des besoins du
systme mettre en place. Nous commencerons par donner une version textuelle du cahier
des charges et ensuite enchainerons avec un premier modle contextuel afin dtablir
avec prcision les limites fonctionnelles du systme. Ceci naturellement aprs
identification des acteurs qui interagiront avec le systme.

Chapitre 2 Etude Prliminaire

22

1 Cahier des charges
1.1 Introduction
LEcole SupMIT qui dispose parmi les missions quelle sest astreinte la formation, dsire
amliorer la qualit des services quelle offre. Cette cole dans le cadre de ltude quelle a
men, a considr quil y avait un besoin de cration et de mise au point une application web
dinscription en ligne aux formations proposes. Notamment, pour offrir un service de qualit
et augmenter le rendement de son Dpartement de formation et le fortifier. Par ailleurs, une
application dinscription en ligne permettra SupMIT de complter les prestations quelle
offre aux entreprises et aux clients particuliers.

1.2 Prsentation gnrale du projet
L'application devra tout d'abord tre extrmement fiable. En effet, son domaine d'application
concerne le cur de l'activit des tablissements des formations professionnelles, et son
utilisation quotidienne ne devra pas laisser place l'ventuel point faible.

L'objectif principal est la gestion des bnficiaires, des formateurs, des thmes, des catalogues
et des formations.

L'application devra notamment :
Permettre d'inscrire des nouveaux bnficiaires et formateurs.
Permettre de faire la gestion des bnficiaires et des formateurs.
Permettre lajout et la gestion des thmes, des catalogues et des formations.
Permettre d'tablir des statistiques relatives aux informations enregistres.
Permettre d'impression de certaines pages (attestation, fiche bnficiaire.....).

Nous devons alors atteindre les rsultats suivants :
Disposer de la base de donnes reprsentant la partie stockage des informations
concernant les bnficiaires, les formateurs, et le catalogue des formations.
Assurer la scurit de l'application par l'authentification au premier cran, l'enregistrement
des informations sur les vnements qui ont lieu.
Disposer d'un module d'administration de l'application permettant la gestion, la mise
jour et la maintenance de l'application.

Ceci est fait en suivant les tapes suivantes :

23
Cration de planning.
Elaboration d'un scnario maquette et des esquisses des crans d'application.
Conception de la base de donnes en laborant les cas dutilisations, Diagramme de
squence, diagramme de classe.
Implmentation de la base de donnes.
Dveloppement de notre application (codage ou programmation).
Validation de l'application par des scnarios de tests d'excution.

1.3 Recueil des besoins fonctionnels

Un premier tour dhorizon des besoins exprims par la direction de SupMIT a permis
dtablir le cahier de charges prliminaire suivant :

! La cration du compte formateur

Cette phase est obligatoire pour tous les formateurs qui veulent donner des formations.
Lorsquun formateur veut participer a une formation, il doit commencer par crer un compte
suite cette opration un profil sera cr en remplissant le formulaire de cration de compte
qui contient les champs suivantes : CIN, Civilit, Nom, Prnom, Mot de passe, Date de
Naissance, Lieu de Naissance, Email, Niveau dEtude, Exprience, Tlphone, Adresse, CV,
Photo.

Apres la cration, ce compte sera vrifi selon les critres suivants :
Validation de ladresse mail : pour bloquer les robots de messagerie.
Vrifier que la cration dun compte avec un mot de passe vide est rejete
Vrifier quon ne peut crer quun seul compte unique.

Aprs lattachement une formation, le formateur a le droit de consulter la liste des
bnficiaires qui les forment.

! La cration du compte bnficiaire


24

Cette phase est trs importante pour les bnficiaires qui veulent sinscrire lapplication
pour avoir le droit de participer une ou plusieurs formations.

Lorsquun bnficiaire veut utiliser lapplication comme moyen de recherche de
format i ons dsi res, il doit commencer par la cration dun compte. Lors de cette
tape, il saisit des informations suivantes :
CIN, Nom, Prnom, Mot de passe, Sexe, Date de Naissance, Lieu de Naissance, Email,
Niveau dEtude, Tlphone, Adresse, CV, Photo.

Les bnficiaires peuvent faire des recherches pour dcouvrir les formations disponibles.

! Grer les comptes formateurs et bnficiaires

Ladministrateur a le droit de grer les comptes formateurs et bnficiaires comme suit :
" Permettre de modifier le profile formateur et bnficiaire.
" De lister les comptes des formateurs et des bnficiaires inscrits.
" Dsactiver ou supprimer un compte.
" Inscrire un bnficiaire dans une formation.
" Affecter un formateur une formation cre.

! Gestion des profils

Cette opration est consacre aux formateurs et aux bnficiaires pour avoir la capacit de
grer leurs propres profils (consultation, modification et la suppression dun profil).

! Gestion des thmes, catalogues et formations par ladministrateur

Ladministrateur a la possibilit de grer des thmes, catalogues et formations, cest--dire
lajout, la mise jour et la suppression.


25
1.4 Recueil des besoins oprationnels

Scurit

Pour se connecter au systme, chaque utilisateur doit fournir son login et son mot de
passe. En cas de succs de connexion, le systme devra restituer le rle de lutilisateur
afin de dterminer les fonctionnalits auxquelles il a droit.

Disponibilit

Le systme doit tre en permanence la disposition de ses utilisateurs.

Fiabilit

Le systme doit excuter les fonctions attendues avec la prcision requise.

Performance

Le systme devra tre capable de rpondre aux requtes des diffrents utilisateurs en un
temps raisonnable.

Intgrit des donnes

Le systme mettre en place devra garantir lintgrit des donnes en toute circonstance.

Le recueil des besoins tant ralis, nous pouvons passer maintenant la description du
Contexte du systme. Cette description stale sur trois activits qui sont :

Lidentification des acteurs,
Le recensement des messages,
La production des diagrammes de contexte


26
2 Identification des acteurs
Un acteur reprsente labstraction dun rle jou par des entits externes (utilisateur,
dispositif matriel ou autre systme) qui interagissent directement avec le systme tudi. Il
peut consulter et/ou modifier directement ltat du systme, en mettant et/ou en recevant
des messages ventuellement porteurs des donnes.
Aprs la phase danalyse, nous avons identifi trois catgories dutilisateurs :
Les bnficiaires, les formateurs et les administrateurs.

Le tableau suivant prsente les trois acteurs identifies et le rle de chacun deux Tableau 2:

Acteur Type Description du Rle

Administrateur
Humain
Prpare les sessions et mettre en place les formations
selon un calendrier. Gere les bnficiaires, et les
formateurs.

Formateur
Humain
Utilise le systme pour dposer son CV et voir la liste
des bnficiaires.

Bnficiaire
Humain
Consulte les formations, rserve les cours selon les
priodes disponibles via une interface conviviale. Il
peut aussi voir ses notes.
Tableau 2: Liste des acteurs

3 Conclusion
Dans ce chapitre, nous avons fait le recueil initial des besoins fonctionnels et
oprationnels. Nous avons ensuite identifi les acteurs et ses rles dans le systme.
Le chapitre suivant sera consacr ltude fonctionnelle de notre projet.

27

Chapitre 3

Etude Fonctionnelle

Nous prsentons dans ce chapitre la mthodologie utilise pour lanalyse et la
conception de la base de donnes et les diagrammes quon a pu tablir.

Chapitre 3 Etude Fonctionnelle

28

1 Ltude fonctionnelle dans le processus Y

La branche fonctionnelle Figure 4 du processus Y a pour objectif la capture des
spcifications et des contraintes fonctionnelles. Durant lanalyse, nous nous concentrons
sur le mtier indpendamment de toute technologie, et nous essayons dadapter le plus
possible notre systme aux besoins des utilisateurs.

Figure 4: Branche fonctionnelle du processus Y

2 Capture des besoins fonctionnels

La capture des besoins fonctionnels est la premire tape de la branche gauche du cycle en
Y. Dans cette section, nous allons formaliser et dtailler ce qui a t bauch au cours de
ltude prliminaire.


29

La capture des besoins fonctionnels a pour objectif :

" Lidentification des cas dutilisation du systme par ses acteurs"
" La description des cas dutilisation.
" Lidentification des classes des modles danalyse.

3 Diagrammes de cas dutilisation

Les diagrammes de cas d'utilisation sont des diagrammes UML utiliss pour donner Une
vision globale du comportement fonctionnel d'un systme logiciel. Un cas Dutilisation
reprsente une unit discrte d'interaction entre un utilisateur (humain ou Machine) et un
systme. Il est une unit significative de travail. Dans un diagramme de cas d'utilisation, les
utilisateurs sont appels acteurs (actors), ils interagissent avec les cas dutilisation (use cases).

UML dfinit une notation graphique pour reprsenter les cas d'utilisation. Cette notation est
appele diagramme de cas d'utilisation. UML ne dfinit pas de standard pour la forme crite
de ces cas d'utilisation. En consquence, il est ais de croire que cette notation Graphique
suffit elle seule pour dcrire la nature d'un cas d'utilisation. Dans les faits, une notation
graphique ne peut donner qu'une vue gnrale simplifie d'un cas ou d'un ensemble de cas
d'utilisation. Les diagrammes de cas d'utilisation sont souvent confondus avec les cas
d'utilisation. Bien que ces deux concepts soient relis, les cas dutilisation sont bien plus
dtaills que les diagrammes de cas d'utilisation.


30
La figure 5 dcrit les diffrents cas d'utilisations de chaque acteur. Elle permet de distinguer les
rles et les acteurs du projet.

Figure 5: Diagramme de cas d'utilisation


31
Diagramme de squence

Les diagrammes de squence sont couramment utiliss par un bon nombre d'acteurs d'un
projet. En effet, le diagramme de squence est une reprsentation intuitive lorsque l'on
souhaite concrtiser des interactions entre deux entits (deux sous-systmes ou deux classes
d'un futur logiciel).
Ils permettent l'architecte/designer de crer au fur et mesure sa solution. Cette
reprsentation intuitive est galement un excellent vecteur de communication dans une
quipe d'ingnierie pour discuter cette solution.
Les diagrammes de squence peuvent galement servir la problmatique de test. Les traces
d'excution d'un test peuvent en effet tre reprsentes sous cette forme et servir de
comparaison avec les diagrammes de squence raliss lors des phases d'ingnierie.
Les diagrammes de squence tels que dfinis en UML souffraient cependant d'un gros
inconvnient. La quantit de diagrammes raliser pouvait atteindre un nombre lev ds
lors que l'on souhaitait dcrire avec un peu de dtail les diffrentes branches
comportementales d'une fonctionnalit.

La figure 6 montre la squence d'authentification. C'est la premire squence dclenche
dans ce projet. Ladministrateur entrain de se connecter attend la rponse pour tre redirig
vers la page d'accueil correspondante son profil.

Figure 6: Diagramme de squence (Authentification)

La figure 7 dcrit la faon avec laquelle un administrateur cre une formation. Il doit spcifier

32
le catalogue et vrifier la disponibilit de formateur spcialiste.

Figure 7: Diagramme de squence (Ajouter Formation)

La Figure 8 dmontre le processus suivi par le bnficiaire pour sinscrire dans lapplication.

33

Figure 8: Diagramme de squence (S'inscrire)

La Figure 9 dmontre le processus suivi par le bnficiaire pour sinscrire dans une
formation.

34

Figure 9: Diagramme de squence (S'inscrire dans formation)

La Figure 10 dmontre le processus suivi par le Formateur pour sinscrire dans lapplication
en choisissant les formations encadrer.

35

Figure 10: Diagramme de squence (S'inscrire comme Formateur)

Conclusion
Dans ce chapitre, nous avons abord la description des cas dutilisation et la description des
diagrammes de squence des scnarios les plus importants. Le chapitre suivant sera consacr
ltude technique de du projet.

36

Chapitre 4

Etude Technique

Ce chapitre est consacr conformment au cycle de dveloppement en Y, la branche
technique. Dans cette partie, nous allons aborder la capture des besoins techniques,
Larchitecture 3-tiers, les designs patterns, les systmes et les outils de travail utiliss.

Chapitre 4 Etude Technique

37

1 Ltude technique dans le processus Y

Lobjectif de la branche technique du processus Y Figure 11 est de recenser les contraintes
et les choix techniques et matriels dimensionnant la conception du systme. Le but est
dviter les risques techniques et les problmes que lapplication pourrait rencontrer tels que
les problmes dintgration, de maintenance, d'volution

Figure 11: Branche technique du processus Y

2 Capture de besoin technique

La capture des besoins techniques couvre, par complmentarit avec celle des besoins
fonctionnels, toutes les contraintes qui ne traitent ni de la description du mtier des
utilisateurs, ni de la description applicative. La spcification technique est une activit
primordiale pour la conception darchitecture.


38

2.1 Spcification technique

Les prrequis techniques ont t exprims dans ltude prliminaire, lors de lexpression des
besoins oprationnels. Elles concernent la performance daccs aux donnes, la scurit du
systme, linteroprabilit, lintgrit des donnes, la disponibilit, et la fiabilit.

2.1.1 Spcification darchitecture

Lexpression des prs requis techniques implique galement le choix dun style
darchitecture client/serveur. Ce choix conditionne la faon dont seront organiss et dploys
les composants dexploitation du systme.

Composant dexploitation et composant mtier

" Un composant dexploitation est une partie du systme logiciel qui doit tre connue,
installe, dclare et manipule par les exploitants du systme. Un composant
dexploitation doit tre interchangeable entre diffrentes versions et peut tre arrt
ou dmarr sparment. Il assume des fonctions bien identifies dans le systme, de
sorte quen cas de dysfonctionnement, le composant incrimin est facilement
reprable.
" Un composant mtier est un composant dexploitation dont la fonction est de
distribuer les services dun ou de plusieurs objets mtier de lentreprise.

Lintgration de composants mtier implique le recours un style darchitecture 3-tiers.

Style darchitecture en tiers
Le style darchitecture en tiers (tier signifie partie en anglais) spcifie lorganisation des
composants dexploitation mis en uvre pour raliser le systme. Chaque partie indique une
responsabilit technique laquelle souscrivent les diffrents composants dexploitation dun
systme. [Roques & Valle, 2007]
On distingue donc plusieurs types de composants en fonction de la responsabilit technique
quils jouent dans le systme. Un systme client/serveur fait rfrence au moins deux types
de composants, qui sont les systmes de base de donnes en serveur, et les applications qui en
exploitent les donnes en client.
Le style darchitecture 2-tiers correspond la configuration la plus simple dun systme
client/serveur. Dans ce cas, il incombe aux clients de grer linterface utilisateur et les
processus dexploitation. Les serveurs ont pour responsabilit de traiter le stockage des
donnes.

39

Lintgration des objets mtier sous la forme de composants mtiers fait passer larchitecture
client/serveur du 2-tiers au 3-tiers, car elle implique un nouveau type de composants
dexploitation qui sinsre entre les clients et les serveurs de donnes.

Larchitecture 3-tiers Figure 12 a t davantage choisie parce quelle permet de satisfaire les
exigences techniques que nous avons repris au niveau de la spcification des besoins
techniques savoir essentiellement :

# La scurit : elle permet de la dfinir indpendamment de service et de chaque
niveau.
# La performance : elle est assure du fait du partage des tches entre les diffrents
serveurs.
# La disponibilit : elle est assure pour les mmes raisons que la performance

Figure 12: Architecture 3 tiers

2.1.2 Architecture 3-tiers

Larchitecture adopte pour notre application est celle la plus utilise dans le dveloppement
des grandes applications, cest larchitecture 3-tiers. Elle permet de rendre les trois couches
(prsentation, mtier et accs aux donnes) indpendantes les unes des autres grce aux
interfaces.

La couche Prsentation
Elle reprsente le premier niveau de larchitecture et est la partie visible de lapplication et
interactive avec lutilisateur. Dans notre cas, elle est reprsente en HTML et est exploite
par des navigateurs Web.

40

La couche Mtier
Cest la couche du second niveau de larchitecture. Elle reprsente la partie fonctionnelle de
lapplication. Cette couche opre sur les donnes en fonction des requtes des utilisateurs
effectues au travers de la couche prsentation (Couche intermdiaire).

La couche accs aux donnes
La fonction principale de cette couche est de grer les donnes. La faon dont elle organise,
manipule et stocke les donnes est transparente vis--vis des applications externes et des
utilisateurs.

Conception gnrique
Elle consiste dvelopper la solution qui rpond aux spcifications techniques que nous
avons prsentes ltape capture des besoins techniques. Cette conception est qualifie de
gnrique car elle est entirement indpendante des aspects fonctionnels spcifis au niveau
de la branche de gauche. La conception gnrique reste donc une activit de la branche de
droite.
La standardisation des techniques de dveloppement, laquelle nous avons assist ces
dernires annes, rend cette tape moins consquente quavant. En effet, la diffusion de
composants gratuits, tels que Dreamweaver, XAMPP, propose en quelque sorte des
architectures logicielles cls en main, et gnralement de qualit, quil suffit de rutiliser.
Cest pour cette raison que nous allons focaliser sur lexigence technique principale de notre
projet, nous avons cit les technologies, Framework et composants utiliss.

2.2 Technologies et outils utilises
Pour satisfaire les besoins fonctionnels et techniques numrs dans ltude prliminaire, nous
avons opts pour les technologies suivantes :

2.2.1 PHP
PHP est un langage de programmation. Sa principale application se situe au niveau de la
gestion des sites web dynamiques.

Les capacits de PHP ne sarrtent pas la cration de pages web. Il est aussi possible de
manipuler des images, de crer des fichiers PDF, de se connecter des bases de donnes ou

41
des serveurs LDAP, et mme dinstancier des objets Java. Un module annexe lui permet
galement de fournir des interfaces graphiques classiques (client lourd, sans navigateur ou
serveur web), via GTK.
PHP est lorigine un langage de script conu spcifiquement pour agir sur les serveurs web.
En ajoutant quelques lignes de PHP une page HTML, le serveur excute les instructions
correspondantes pour crire du code HTML la place. Le rsultat (le code HTML initial ajout
celui produit par PHP) est envoy au navigateur. Cela permet par exemple dafficher la date
du jour un endroit bien prcis du visuel. On parle alors de page dynamique.
PHP dispose de prs de 3 000 fonctions utilisables dans des applications trs varies et couvre
pratiquement tous les domaines en rapport avec les applications web. PHP 5 et ses nouveauts
propulsent PHP dans le monde des plates-formes dentreprises comme .Net ou J2EE.

2.2.2 JavaScript
Cest un langage de script incorpor dans un document HTML. Historiquement il s'agit du
premier langage de script pour le Web. Ce langage est un langage de programmation qui
permet d'apporter des amliorations au langage HTM pour excuter des commandes du ct
client, c'est--dire au niveau du navigateur et non du serveur web. JavaScript a t mis au
point par Netscape en 1995. A l'origine, il se nommait LiveScript et tait destin fournir un
langage de script simple au navigateur Netscape Navigator 2. Il a, l'poque, longtemps t
critiqu pour son manque de scurit, son dveloppement peu pouss et l'absence de messages
d'erreur explicites rendant difficile son utilisation. Le 4 dcembre 1995, suite une association
avec le constructeur Sun, Netscape rebaptise son langage JavaScript (un clin d'il au langage
Java dvelopp par Sun). A la mme poque, Microsoft mit au point le langage Jscript, un
langage de script trs similaire.
Ainsi, pour viter des drives de part et d'autre, un standard a t dfini pour normaliser les
langages de script, il s'agit de l'ECMA 262, cr par l'organisation du mme nom (ECMA,
European Computer Manufactures Association).

2.2.3 AJAX
Ajax dsigne une approche innovante dans la conception de pages web dont l'objectif est
d'optimiser leur interactivit et leur confort d'utilisation conjointe dans les pages web de
diffrentes technologies. Ainsi AJAX incorpore :
le XHTML et les feuilles de style CSS
le JavaScript
le DOM
lObject XMLHttpRequest
le XML et le XSL


42
2.2.4 Microsoft Project
Microsoft Project (ou MS Project ou MSP) est un logiciel de gestion de projets dit par
Microsoft. Il permet aux chefs de projet et aux planificateurs de planifier et piloter les projets,
de grer les ressources et le budget, ainsi que d'analyser et communiquer les donnes des
projets.

Microsoft Project permet la planification des projets, cest--dire la cration dun plan. Il
permet la cration de tches et de jalons, leur hirarchisation, et de dfinir des liens entre les
tches. Une estimation de la dure et de la charge (ou travail) ncessaire la ralisation de
chaque tche peut ensuite tre ralise.

Microsoft Project permet la gestion des ressources de chaque projet, cest--dire la cration de
lquipe projet puis laffectation des ressources dfinies.

Microsoft Project offre une palette de possibilits danalyse des donnes du projet et propose
de nombreux rapports. Il est mme possible dexporter les informations du projet dans
Microsoft Excel ou Microsoft Visio pour analyser le travail et les cots du projet en fonction
de diffrents axes danalyse (tches, ressources, affectation, temps), via des tableaux,
graphiques et diagrammes croiss dynamiques.

Microsoft Project permet de communiquer les informations des projets : copie du diagramme
de Gantt, impression et surtout, depuis la version 2010, possibilit de crer une frise
chronologique exportable vers Microsoft PowerPoint ou dans un message lectronique.

2.2.5 Dreamweaver
Dreamweaver est un diteur de site web WYSIWYG pour Microsoft Windows, et Mac OS X
cr en 1997, commercialis par Macromedia puis Adobe Systems sous licence utilisateur
final.

Dreamweaver fut l'un des premiers diteurs HTML de type tel affichage, tel rsultat , mais
galement l'un des premiers intgrer un gestionnaire de site (CyberStudio GoLive tant le
premier). Ces innovations l'imposrent rapidement comme l'un des principaux diteurs de site
web, aussi bien utilisable par le nophyte que par le professionnel.

Dreamweaver offre deux modes de conception par son menu affichage. L'utilisateur peut
choisir entre un mode cration permettant d'effectuer la mise en page directement l'aide
d'outils simples, comparables un logiciel de traitement de texte (insertion de tableau, d'image,
etc.). Il est galement possible d'afficher et de modifier directement le code (HTML ou autre)
qui compose la page. On peut passer trs facilement d'un mode d'affichage l'autre, ou opter


43
pour un affichage mixte. Cette dernire option est particulirement intressante pour les
dbutants qui, terme, souhaitent se familiariser avec le langage HTML.

Dreamweaver a volu avec les technologies de l'internet. Il offre aujourd'hui la possibilit de
concevoir des feuilles de style. Les liaisons avec des bases de donnes ont galement t
amliores ainsi que le chargement des fichiers sur les serveurs d'hbergement. Il propose en
outre l'utilisation de modles imbriqus de pages web, selon un format propritaire.

2.2.6 Enterprise Architect
Outil de Modlisation UML / BPMN / SysML et dingnierie dirige par les modles
(Model-Driven) Enterprise Architect est lun des outils de modlisation UML les plus
utiliss dans le monde. Ce succs est d plusieurs facteurs : un support complet dUML
2.4.1, une excellente ergonomie, un niveau de performance lev, des versions frquentes et
enfin un cot dacquisition et de maintenance ultra comptitifs.
Enterprise Architect bnficie dune communaut trs active et de lapprobation des
organismes de standardisation tels que lOMG. Il a fait ses preuves par des rsultats
exceptionnels sur de nombreux projets.
Fort de 12 ans de dveloppement par Sparx Systems, Enterprise Architect est employ par de
nombreuses entreprises dans tous les domaines dactivit ainsi que par diffrents organismes
de normalisation.

2.2.7 XAMPP
Xampp est une application libre regroupant en son sein un serveur web apache, un serveur de
base de donnes (MySQL), un serveur FTP mais galement PHP qui communique avec le
serveur web apache et traite les pages PHP. Vous disposez aussi d'une interface agrable
(PHPMyAdmin) pour grer aisment les bases de donnes.
2.2.7.1 MySQL
MySQL est un systme de gestion de bases de donnes relationnelles SQL dvelopp dans
un souci de performances leves en lecture, ce qui signifie qu'il est davantage orient vers
le service de donnes dj en place que vers celui de mises jour frquentes et fortement
scurises. Il est multi-thread et multi-utilisateur. C'est un logiciel dvelopp sous double
licence en fonction de l'utilisation qui en est faite: dans un produit libre ou dans un produit
propritaire.
2.2.7.2 Apache
Apache est un serveur HTTP cr et maintenu au sein de la fondation Apache. C'est le

44
serveur HTTP le plus populaire du World Wide Web. Il est distribu selon les termes de la
licence Apache.
Apache est conu pour prendre en charge de nombreux modules lui donnant des
fonctionnalits supplmentaires : interprtation du langage Perl, PHP, Python et Ruby, serveur
proxy, Common Gateway Interface, Server Side Includes, rcriture d'URL, ngociation de
contenu, protocoles de communication additionnels, etc. Nanmoins, il est noter que
l'existence de nombreux modules Apache complexifie la configuration du serveur web.

2.3 Design patterns
2.3.1 MVC
Pour raliser notre projet nous avons utilis les Pattern MVC Figure 13 :

Figure 13: Architecture du dsigne pattern MVC

L'architecture (Modle Vue Contrleur) est une mthode de conception pour le dveloppement
d'applications logicielles qui spare le modle de donnes, l'interface utilisateur et la logique de
contrle. Ce modle d'architecture impose la sparation entre les donnes, les traitements et la
prsentation, ce qui donne trois parties fondamentales dans l'application finale le modle, la
vue et le contrleur :
Le Modle : reprsente le comportement de l'application : traitements des donnes, interactions
avec la base de donnes, etc. Il dcrit les donnes manipules par l'application et dfinit les
mthodes d'accs.

45
La Vue : correspond l'interface avec laquelle l'utilisateur interagit. Les rsultats renvoys par
le modle sont dnus de toute prsentation mais sont prsents par les vues. Plusieurs vues
peuvent afficher les informations d'un mme modle. Elle peut tre conue en html, ou tout
autre langage de prsentation. La vue n'effectue aucun traitement, elle se contente
d'afficher les rsultats des traitements effectus par le modle, et de permettre l'utilisateur
d'interagir avec elles.
le Contrleur : prend en charge la gestion des vnements de synchronisation pour mettre
jour la vue ou le modle. Il n'effectue aucun traitement, ne modifie aucune donne, il analyse la
requte du client et se contente d'appeler le modle adquat et de renvoyer la vue
correspondant la demande

En rsum, lorsqu'un client envoie une requte l'application, celle-ci est analyse par le
contrleur, qui demande au modle appropri d'effectuer les traitements, puis renvoie la vue
adapte au navigateur, si le modle ne l'a pas dj fait. Un avantage apport par ce modle est
la clart de l'architecture qu'il impose. Cela simplifie la tche du dveloppeur qui tenterait
d'effectuer une maintenance ou une amlioration sur le projet. En effet, la modification des
traitements ne change en rien la vue. Par exemple on peut passer d'une base de donnes de type
SQL XML en changeant simplement les traitements d'interaction avec la base, et les vues ne
s'en trouvent pas affectes. Comme exemple, Swing la bibliothque graphique de Java pour
la cration dinterfaces graphiques, est base sur le modle MVC.

Conclusion

Dans ce chapitre, nous avons abord la description des spcifications techniques, larchitecture
logicielle et applicative.
Le chapitre suivant sera consacr la phase de Mise en uvre de la solution.

46

Chapitre 5

Mise en uvre de la solution

Lobjectif de ce chapitre qui constitue la dernire branche du processus de
dveloppement 2TUP est de concrtiser le modle de conception prsent lors des
prcdents chapitres en des couches applicatives et des interfaces
homme/machine et le tester pour valuer les objectifs. Dans cette partie, nous
allons successivement nous appesantir sur les phases suivantes :
Conception prliminaire,
Conception dtaille,
Codage,
Tests,
Dploiement

Chapitre 4 Mise en uvre de la solution

47
1 La mise en uvre dans le processus Y
Aprs les tudes fonctionnelles et techniques, on aborde la phase de codage et tests pour
chaque module. Ensuite, ces modules sont tests unitairement en vue dtre intgres dans
le systme tout entier. Une fois cette tape est termine, le systme sera prt pour
lactivit de test. Cette activit a pour but de tester le systme fabriqu en implmentation.

Figure 14: Phase de mise en uvre dans le processus Y

2 La Conception prliminaire
La conception prliminaire est certainement ltape la plus dlicate du processus 2TUP car
elle en reprsente le cur. Cest en effet cette occasion que seffectue la fusion des tudes
fonctionnelles et techniques. En consquence, plusieurs activits doivent coexister. Il
convient de :
# Passer de lanalyse objet la conception.
# Intgrer les fonctions mtier et applicatives du systme dans larchitecture technique.
# Adapter la conception gnrique aux spcifications fournies par lanalyse. La
conception prliminaire sappuie sur les points de vue de spcification fonctionnelle
et structurelle de lanalyse.


48
2.1 Architecture logicielle implmente

Larchitecture logicielle vient pour dmontrer comment le systme informatique doit tre
conu de manire rpondre aux spcifications de la matrise douvrage. Larchitecture
logicielle implmente se prsente comme suit Figure 15 :

Figure 15: Architecture logicielle du projet

2.2 numrations des vues de lapplication

Cette section consiste lister les IHM qui dfinissent les interfaces travers lesquelles les
utilisateurs interagissent avec les diffrents composants du systme.

Nous prsentons dans le tableau ci-aprs, les plus importantes dentre elles Tableau 3 :


49
IHM Description
Linterface de prise en compte
dun formateur
Linterface dajout dun formateur qui permet ce dernier de remplir les
champs suivants : CIN, Civilit, Nom, Prnom, Mot de passe, Date de
Naissance, Lieu de Naissance, Email, Niveau dEtude, Exprience etc..
Linterface de prise en compte
dun bnficiaire
Linterface dajout dun bnficiaire qui permet ce dernier de remplir les
champs suivants : CIN, Nom, Prnom, Mot de passe, Sexe, Date de
Naissance, Lieu de Naissance, Email etc..
Linterface dajout dun thme
Linterface dajout dun thme. Dans laquelle ladministrateur saisit le champ
suivant : Nom Thme
Linterface dajout dun
catalogue
Linterface dajout dun catalogue. Dans laquelle ladministrateur saisit les
champs suivant : Dsignation, Dure, Description, Coeff_Cours, Coeff_TP
parmi les thmes disponibles
Linterface dajout dune
formation
Linterface dajout dune formation. Dans laquelle ladministrateur saisit les
champs suivant : Prix, dateDebut, dateFin, Horaire parmi les catalogues
disponibles
Linterface de lister et grer
tous les formateurs et
bnficiaires
Cette interface permet de lister et grer tous les formateurs et bnficiaires
inscrits dans lapplication.
Linterface de grer tous les
thmes, catalogues et
formations
Cette interface permet de grer tous les thmes, catalogues et formations
disponible dans lapplication (afficher, modifier ou supprimer)
Linterface dauthentification
Cette interface permet de connecter chaque utilisateur (administrateur,
formateur, bnficiaire) et le redirige vers son propre vue selon son privilge.
Tableau 3: Les vues de l'application

3 La Conception dtaille
La conception dtaille qui vient juste aprs est une activit qui sinscrit dans lorganisation
dfinie par la conception prliminaire. Le modle logique y est particulirement important
dans la mesure o cest dans cette tape quon gnre le plus grand nombre dinformations. Il
est ainsi possible de confier les catgories des personnes diffrentes, qui pourront travailler
indpendamment les unes des autres. Les concepteurs dans cette phase construisent les
classes, les vues dIHM, les interfaces, les tables et les mthodes qui vont donner une image
prte coder de la solution.


50
3.1 Classes mtiers dtailles

A partir du modle logique de conception et des interfaces, le microprocessus de conception
de la mthode 2TUP permet de dfinir les classes implmenter. Cette activit consiste :

Concevoir les classes : transformer les classes et mta classes provenant de l'analyse
en codage dans un langage de dveloppement.

Concevoir les associations : dfinir la faon d'exploiter chaque association et les
techniques qui seront employes dans le codage.

Concevoir les attributs : identifier les structures de donnes, les itrations et d'autres
types complexes permettant de reprsenter les attributs d'analyse dans le langage
utilis.

3.1.1 Conception des classes
Les classes issues de lanalyse sont conformes aux possibilits offertes par PHP le langage
dimplmentation choisi. Nous navons donc pas dautres classes en dehors de celles
provenant de lanalyse.

3.1.2 Conception des attributs
Dans cette section, nous allons dfinir le type dattributs identifis en analyse. Nous pouvons
dores et dj constater que tous les attributs des diffrentes classes se satisfasse des types de
base de PHP. Concevoir les attributs, cest galement prciser leur visibilit et leur mode
daccs. Pour notre part, les attributs sont privs. Enfin concevoir les attributs cest aussi
spcifier les mthodes qui servent la mise jour des attributs.

3.1.3 Description des classes
Dans cette section nous allons dcrire quelques classes tableau 4 et 5:


51

Classe : Formateur

Attributs
Visibilit Nom Description Type
Private idFormateur Identifiant de formateur Entier
Private Nom Nom de formateur Texte
Private Niveau dEtude Niveau dtude de formateur Texte
Private CV
Informations personnels et
professionnels de formateur
Texte

Mthodes
Visibilit Nom Description
Public displayFormateur() Permet dafficher les informations dun formateur
Public addFormateur() Permet dajouter un formateur
Public updateFormateur()
Permet de modifier les informations dun
formateur
Public deleteFormateur() Permet de supprimer un formateur existant
Tableau 4: Description de la classe formateur

Classe : Formation

Attributs
Visibilit Nom Description Type
Private Prix Prix de la formation Dcimal
Private dateDebut Date de dbut de la formation Date
Private dateFin Date de fin de la formation Date
Private Horaire Horaire dtude de la formation Texte

Mthodes
Visibilit Nom Description
Public displayFormation() Permet dafficher les informations dune formation
Public addFormation() Permet dajouter une formation
Public updateFormation()
Permet de modifier les informations dune
formation
Public deleteFormation() Permet de supprimer une formation existante
Tableau 5: Description de la classe formation


52
3.1.4 Diagramme de classes
Le diagramme de classes est un schma utilis en gnie logiciel pour prsenter les classes et
les interfaces d'un systme ainsi que les diffrentes relations entre celles-ci. Ce diagramme
appartient la partie statique d'UML car il fait abstraction des aspects temporels et
dynamiques.
Une classe dcrit les responsabilits, le comportement et le type d'un ensemble d'objets. Les
lments de cet ensemble sont les instances de la classe.
Une classe est un ensemble de fonctions et de donnes (attributs) qui sont lies ensembles par
un champ smantique. Les classes sont utilises dans la programmation oriente objet. Elles
permettent de modliser un programme et ainsi de dcouper une tche complexe en plusieurs
petits travaux simples.
Les classes peuvent tre lies entre elles grce au mcanisme d'hritage qui permet de mettre
en vidence des relations de parent. D'autres relations sont possibles entre des classes,
chacune de ces relations est reprsente par un arc spcifique dans le diagramme de classes.
Elles sont finalement instancies pour crer des objets (une classe est un moule objet : elle
dcrit les caractristiques des objets, les objets contiennent leurs valeurs propres pour chacune
de ces caractristiques lorsqu'ils sont instancis).
Le diagramme de classe obtenu aprs fusion des diagrammes de classes des diffrentes
catgories se prsente comme suit Figure 16 :

Figure 16: Diagramme de classes

53

4 Ralisation
Dans cette section, nous allons essentiellement nous taler sur les tches suivantes :
# Implmentation des IHM.
# Codage et tests.
# Dploiement.

4.1 Implmentation des IHM

Nous prsentons dans cette section un aperu de quelques interfaces homme-machines de
lapplication, rsultat de la ralisation des diffrents modules fonctionnels conus.

4.1.1 Linterface daccueil de lapplication
Cest la page daccs par dfaut lapplication. Parmi les composants principaux de la page
daccueil:
Zone pour dfinir lobjectif de lapplication.
Zone dauthentification et dinscription des utilisateurs.
Zone de diffrentes formations disponibles.

Figure 17: L'interface d'accueil de l'application

54
4.1.2 Linterface dauthentification
A partir de cette interface lutilisateur peut accder son profil.

Figure 18: L'interface d'authentification

4.1.3 Linterface de cration dun profil formateur

Cette vue reprsente le formulaire qui permet aux formateurs de crer un profil formateur sur
la plateforme de lapplication.

Figure 19: L'interface de cration d'un profil formateur


55
4.1.4 Linterface dajout dune formation
Un formulaire saffiche lorsque ladministrateur veut ajouter une formation dans la
plateforme de lapplication.

Figure 20: L'interface d'ajout d'une formation

4.1.5 Linterface de lister et grer des bnficiaires
Cette vue permet de lister et grer tous les bnficiaires inscrits dans lapplication.

Figure 21: L'interface de lister et grer des bnficiaires


56

Conclusion

Dans ce chapitre nous avons abord la conception prliminaire travers la conception
dtaille par le biais du diagramme de classes documenter.

Ce chapitre boucle galement le processus 2TUP qui nous avons commenc par ltude
Pralable.
Conclusion gnrale et perspective

Conclusion gnrale et perspective

Jusqu' prsent, lcole SupMIT ne disposait pas de plateforme informatique pour
linscription en ligne des bnficiaires et formateurs qui veulent participer a des formations
dtermines et utilise principalement des moyens non informatiss pour mdiatiser et grer
son travail. Cest dans ce cadre que tait sinscrit notre projet de fin danne dans lequel, il
nous a t demand de concevoir et raliser une plateforme scurise dinscription en ligne.

Le systme doit permettre aux formateurs de sinscrire pour tre engag dans des futures
formations, et aux bnficiaires de sinscrire pour rserver une ou plusieurs formations
dsires.

Nous avons pu effectuer, dans les dlais, lanalyse et la conception ainsi que la ralisation du
Systme tout en respectant le cahier des charges initialement dtermin et dlimit.

Au cours de ce projet, nous avons eu lopportunit de mettre en application les diffrentes
connaissances acquises durant nos tudes. Nous avons galement pu approfondir notre savoir
en informatique par la dcouverte de nouvelles technologies.

En perspectives, il y a faire tous ce qui est valuation de formateurs de la part des
bnficiaires, incluant les commentaires.

Et aussi il reste la deuxime partie de la solution qui est le dveloppement dune solution de
E-Learning dans le quelle les formateurs aurons tous ce qui ncessaire de la technologie pour
faciliter les formateurs en ligne et en particulier travers la prsente solution web, en
facilitant les procdures de paiement lectronique pour les bnficiaires.

A la fin, nous prcisons que la solution conceptuelle et architecturale que nous avons pu
mettre en uvre permettra, sans aucun doute, ladhsion de nouveaux modules et
composants sans pour autant nuire au bon fonctionnement du systme.

Annexe B Modle Bibliographie
58

Bibliographie et Webographie

[Roques & Valle, 2007]
4me dition EYROLLES
UML2 en action De lanalyse des besoins la
conception
[Eric Daspet & Cyril Pierre de
Geyer]
4me dition EYROLLES
PHP 5 avanc
[Vincent Capitaine, 2010]
Dunod, Collection InfoPro
Project 2010 : guide pratique pour les chefs de projet
[Luc Van Lancker]
ENI dition
Ajax : Dvelopper pour le Web 2.0

[Wikipdia] http://fr.wikipedia.org/wiki/Adobe_Dreamweaver
[Sparxsystems] http://www.sparxsystems.fr/
[Site du Zro] http://www.siteduzero.com/informatique/tutoriels/votre-
serveur-local/mamp

Gestion D'un Centre de Formation

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

Gestion D'un Centre de Formation

Transféré par

Droits d'auteur :

Formats disponibles

Mmoire de Projet de Fin dAnne

Pour lObtention du Diplme BAC+4 en

Vous aimerez peut-être aussi