Вы находитесь на странице: 1из 138

1

CURRICULUM VITAE

ETAT CIVIL

ANDRIAMALAZAHARIZAKA Tiankasina Rakotoarisoa

25 ans

Masculin

Célibataire

Lot IIH4A Alatsinainy Ambalavao 303

lazatiankasina@gmail.com

0342577462 / 0322217437

ETUDES ET DIPLOMES

2013-2014 : Troisième année en formation licence professionnelle en Informatique des


Systèmes et Réseaux au C.U.F.P ;
2012-2013 : Deuxième année en formation licence professionnelle en Informatique des
Systèmes et Réseaux au C.U.F.P ;
2011-2012 : Première année en formation licence professionnelle en Informatique des
Systèmes et Réseaux au C.U.F.P ;
2011 : Obtention du diplôme baccalauréat série D.

EXPERIENCES PROFESSIONNELLES ET REALISATIONS

Novembre 2014 : Suivis d‘un stage au sein du CISCO Ambalavao sur le thème

« GESTION DE LA DEMANDE DE RETRAITE »

Aout 2014 : Conception et réalisation d‘une application web pour la « GESTION DU

CONCOURS CUFP » en utilisant le Framework PHP (Code Igniter).

Juin 2014 : Conception et réalisation d‘une application web intitule « GESTION DU

CONCOURS CUFP » en JSP ;

Novembre 2013 : Suivis d‘un stage au sein du Centre de Service Agricole Ambalavao sur

le thème « GESTION DES DEMANDES HARD ET SOFT » ;

2
Aout 2013 : Conception et réalisation d‘une application pour la « GESTION D‘UNE

AUTO ECOLE » en JAVA et PHP.

COMPETENCES

Linguistiques

COMPETENCES
LANGUES compétences lire Ecriture et Communication
rédaction orale
français Très bien Très bien Très bien bien
anglais bien Très-bien bien Assez-bien

Informatiques

Bureautique Word, Excel, PowerPoint


Systèmes d‘exploitation Windows (XP, Vista, 7, 8), Linux, Free BSD
Technologies web HTML, JSP, JavaScript, PHP
Langages de Programmation Java, C, C++, Visual Basic, Python, Pascal
Administration Réseau Linux, Windows

Maintenance, installation et Matérielle


configuration Logicielle
Navigation
Internet
Configuration
SGBD Oracle, PostgreSQL, MySQL, Access

DIVERS

Sports pratiqués : Foot, Basket, Parapente


Loisirs : Lire, Musique, Jeux vidéo

3
INTRODUCTION

Actuellement dans notre époque, le développement de la technologie moderne sur les


réseaux et la technologie web nous offre la possibilité de collaborer sur des projets de façon
sécurisé et rapide grâce à l‘aide d‘un navigateur web. La célérité dans le traitement de
l‘information est un facteur de développement et de performance essentiel pour une société,
entreprise ou bien un établissement comme la CISCO d‘Ambalavao.

Notre stage de Licence Professionnelle a débuté le mois de Novembre 2014 et mis à


terme le mois de Février 2015 au sein du CISCO Ambalavao. Ce stage est sous la
responsabilité de Mr RANDRIANIVO Mamy Julien, Adjoint Programmation de la CISCO
Ambalavao.

La conception et la réalisation de cette application qu‘on nous a été proposée comme


thème de cette stage et nous a permis de rédiger le présent mémoire qui comporte trois
grandes parties.

Au niveau de la première partie représente le domaine d‘étude de travail dont il


contient la représentation du Centre Universitaire de Formation Professionnalisante,
représentation brièvement l‘organisation du CISCO et l‘organisme dans laquelle notre thème
est consacré.

La deuxième partie contient l‘analyse et la conception du projet. Dans cette partie sont
développées les études effectuées avant la réalisation du projet.

La troisième et dernière partie c‘est la réalisation et la mise en œuvre du projet qui


présente le travail effectué dans le cadre du projet.

4
REMERCIEMENTS

La contribution à ce mémoire est loin d‘être une tâche facile. De nombreux facteurs sont
mis en jeu sur le plan moral et matériel. Ainsi, c‘est avec un immense plaisir que nous
réservons cette page en témoignage de ma reconnaissance envers tous ceux qui m‘ont aidé à
la réalisation de ce stage.

Veuillez ne pas m‘en vouloir, ceux qui ne seront pas cités ci-dessous pour des raisons
d‘oubli regrettable dont je tiens sincèrement à excuser, je cite donc :
- Madame RASOAZANANERA Marie Monique, présidente de l‘université de
Fianarantsoa ;
- Monsieur ANDRIAZAFIMAHAZO Lahinirina Fridolin, Directeur du Centre
Universitaire de Formation Professionnalisante ;
- Monsieur HAJALALAINA Aimé Richard, Chef du département informatique ;
- Monsieur RABETAFIKA Haja Louis enseignant chercheur qui a accepté
d‘encadrer mes travaux ;
- Monsieur ANDRIANIRINA Mamy Julien qui a accepté d‘encadrer mes travaux et
nous a aidé pour les collectes des données. ;
- Tout le personnel du Centre Universitaire de Formation Professionnalisante;
- Tous les membres de ma famille qui nous ont soutenus moralement et
financièrement;
Que chacun d‘eux reçoive la gratitude qu‘il mérite, pour toutes les aides qu‘ils m‘ont
apportées.

5
AVANT-PROPOS

Dans le souci de former des professionnels de haut niveau, Le Centre Universitaire de


la Formation professionnalisante offre à ses étudiants un cursus de formation en Licence. La
licence est conçue dans le but de faciliter l‘insertion professionnelle des étudiants de toutes
filières, y compris l‘informatique. En effet, il s‘inscrit dans le cadre d‘une formation orientée
vers les besoins des entreprises et des organisations dans le domaine des nouvelles
technologies.

A ce stade, chaque étudiant effectue un stage en entreprise d‘une durée de quatre mois.
Afin de permettre aux étudiants de confronter leurs acquis théoriques à la réalité du milieu
professionnel. A la fin de ce stage, les étudiants doivent rédiger un livre de mémoire et le
soutenir devant les membres de Jury. Ce présent document décrit les activités effectuées au
sein de la circonscription scolaire d‘Ambalavao.

6
7
8
9
10
11
12
13
14
PARTIE I : DOMAINE D’ETUDE ET DE TRAVAIL

15
Chapitre 1 : PRESENTATION GENERALE DU CUFP

1.1 HISTORIQUE

Le Centre Universitaire de Formation Professionnalisante (CUFP) a été créé au sein de


l‘Université de Fianarantsoa par le Décret N° 2005/205 du 26 Avril 2005 et prépare le
diplôme de Licence Professionnelle en Administration et en Informatique. Auparavant, il a
été connu sous le nom de Centre de Formation Continue (CFC), créé par l‘arrêté rectoral
N°99-23/UF/R du 10 Mars 1999 et dispensait des formations des Techniciens Supérieurs.
(BACC+2). L‘année Universitaire 2013-2014, le Centre Universitaire de Formation
Professionnalisante (CUFP) est basculé totalement vers le système Licence, Master et
Doctorat (LMD). En effet, les offres formations du centre sont habilitées :

Mention : Administration Economique et Sociale, Grade de Licence (Arrêté No


8007/2014-MESupRES) ;

Mention : Développement d‘Application et Système d‘Information, Grade de Licence


(Arrêté No 8007/2014-MESupRES) ;

Mention : Management Décisionnel, Grade de Master (Arrêté No 8007/2014-


MESupRES) ;

Mention : Système d‘Information - Géomatique — Télédétection et Décision (Arrêté No


23411/2014-MESupRES).

1.2 PARTENAIRES

Le Département des Sciences Sociales (Fac DEGS/UF), Le Département d‘Economie et


de Gestion (Fac DEGS/UF), le Département de Mathématique (Fac SCIENCES/UF) et le
Département de Droit (Fac DEGS/UF). L‘Institut d‘Observation Géophysicien Applique
(IOGA). Le Foibe Taon-tsaritan‘i Madagasikara (FTM). Le ministère des Finances et des
Budgets, le ministère de l‘Education Nationale, le ministère de Transport et de Météorologie,
le ministère de Tourisme. Le BOA, le BFV-SG et le BNI. L‘assurance ARO, NY HAVANA

16
et MAMA. La société Lazan‘i Betsileo, la société STAR, la société JIRAMA et les réseaux
TIAVO.

1.3 CYCLE DE LICENCE

Le Centre Universitaire de Formation Professionnalisante (CUFP) de l‘Université de


Fianarantsoa possède trois (03) cycle de Licence Professionnel dont :

- La Licence Professionnelle en Administration Economique et Sociale (AES);


- La Licence Professionnelle en Développement d‘Application et Système
d‘Information (DASI);
- La Licence Professionnelle en Relations Publiques et Multimédia (RPM).

1.3.1 Licence professionnelle en Administration Economique et Sociale

1.3.1.1 Condition générale

Dans la Formation de Licence Professionnelle en Administration Economique et


Sociale :
La condition d‘admission : Test de niveau ;
La condition d‘accès : Baccalauréat général de toute série (A, C, D), Baccalauréat technique
G1 et G2;
La durée de la formation : 03 années universitaires.

1.3.1.2 Stages

Les étudiants dans la Formation Administration Economique et Sociale doivent effectuer :

- Un stage d‘insertion en entreprise ou voyage études en première année de Licence


(L1);
- Un stage de réalisation suivi d‘un rapport de stage en deuxième année de Licence
(L2);
- Un stage de fin d‘études suivi de la soutenance d‘un mémoire en troisième année
de Licence (L3).

17
1.3.1.3 Diplôme

A la fin de la Formation, les étudiants obtiennent un diplôme de Licence en


Administration Economique et Sociale.

1.3.1.4 Compétences

A l‘issue de la Formation, les étudiants ont les compétences :

Assister le Directeur Général, le Directeur des Ressources Humaines et le Directeur


Administratif et Financier.

Gérer des Ressources Humaines.

Gérer une Entreprise et un projet.

1.3.2 Licence professionnelle en développement d’application et système


d’information (DASI)
1.3.2.1 Condition générale

Dans la Formation de Licence Professionnelle en Développement d‘Application et


Systèmes d‘Information, la condition d‘admission se fait par un test de niveau. Ainsi, les
élèves titulaires du diplôme de Baccalauréat Général Scientifique (Série C et série D),
Baccalauréat Technique Professionnel et Baccalauréat Technique Technologique (Filière :
Industriel, Maintenance Automobile, Ouvrage Bois, Ouvrage Métallique, Génie Civil...)
peuvent être accéder dans la formation. Enfin, la formation a pour durer de 03 années
universitaires.

1.3.2.2 Stages

Les étudiants dans la Formation de Licence en Développement d‘Application et


Systèmes d‘Information doivent effectuer:

- Un stage d‘insertion en entreprise en L1;


- Un stage de réalisation suivi d‘un rapport de stage en L2;
- Un stage de fin d‘études suivi de la soutenance d‘un mémoire en L3.

18
1.3.2.3 Diplôme

A la fin de la Formation, les étudiants obtiennent un diplôme de Licence en


Développement d‘Application et Systèmes d‘Information (DASI).

1.3.2.4 Compétences

A l‘issue de la formation, les étudiants sont compétents en :

- Administration des bases de données ;


- Administration des réseaux et systèmes informatiques ;
- Développement d‘application client/serveur ;

1.3.3 Licence professionnelle en relations publiques et multimédias


1.3.3.1 Condition générale

Dans la Formation de Licence Professionnelle en Relations Publiques et Multimédia :

- La condition d‘admission : Test de niveau ;


- La condition d‘accès : Baccalauréat général de toute série (A, C, D), BAC G1 et G2;
- La durée de la formation : 03 années universitaires.

1.3.3.2 Stages

Les étudiants dans la Formation Relations Publiques et Multimédia doivent effectuer :

- Un stage d‘insertion en entreprise ou voyage études en première année de Licence


(L1);
- Un stage de réalisation suivi d‘un rapport de stage en deuxième année de Licence
(L2);
- Un stage de fin d‘études suivi de la soutenance d‘un mémoire en troisième année
de Licence (L3).

19
1.3.3.3 Diplôme

A la fin de la Formation, les étudiants obtiennent un diplôme de Licence en Relations


Publiques et Multimédia.

1.3.3.4 Compétences

A l‘issue de la Formation, les étudiants ont les compétences :


- Rédiger un article dans un journal,
- Occuper une poste d‘un technicien de presse,
- Travailler dans la revue de presse.

1.3.4 Modalités des recrutements en L1

A chaque année, le Centre Universitaire de Formation Professionnalisante ont été


effectué les recrutements des étudiants en Première Année de Licence Professionnelle en
Développement d‘Application et Systèmes d‘Information (DASI1), en Première Année de
Licence Professionnelle en Administration Economique et Sociale (AES1) et en Première
Année de Licence Professionnelle en Relations Publiques et Multimédia (RPM1). Les
recrutements se font par le test de niveau. Les dates d‘ouverture et de clôture des dossiers des
candidatures ont été fixées par les conseils d‘établissement.

Les pièces à fournir sont :

- Formulaire de candidature ;
- Une demande manuscrite adressée à Monsieur le Directeur du Centre ;
- Une copie certifiée du diplôme du Baccalauréat ou équivalent ;
- Un bulletin de naissance moins de trois (03) mois ;
- Deux (02) enveloppes timbrées à l‘adresse du candidat (Ar 300) ;
- Une (01) enveloppe timbrée grand format (Ar 500) ;
- Trois (03) photos d‘identité ;

Droit d‘examen : Bordereau de versement d‘Ar 30. 000 au nom du Centre Universitaire de
Formation Professionnalissante de l‘Université de Fianarantsoa au compte BOA N°
12939120007.

20
Le dossier d‘inscription doit parvenir à MONSIEUR LE DIRECTEUR DU CENTRE
UNIVERSITAIRE FORMATION PROFESSIONNALISANTE – BP 1135 – 301 Fianarantsoa
OU À déposer au CENTRE UNIVERSITAIRE DE FORMATION
PROFESSIONNALISANTE - TANAMBAO FIANARANTSOA.

Le test de niveau se déroulera dans les centres examen suivants : Fianarantsoa, Antananarivo,
Manakara, Ambositra et Ihosy. Ainsi, les épreuves à composer sont :

Mention : Développement d‘Application et Systèmes d‘Information (DASI) :


- Français ;
- Mathématiques ;
- Test psychotechniques.

Mention : Administration Economique et Sociale (AES) :


- Français ;
- Anglais ;
- Test psychotechniques.

Mention : relations publiques et multimédias:


- Français ;
- Anglais ;
- Test psychotechniques.

1.4 CYCLE DE MASTER

Le Centre Universitaire de Formation Professionnalisante (CUFP) de l‘Université de


Fianarantsoa possède deux (02) cycle de Master Professionnel dont :

- Le Master Professionnel en Management Décisionnel (MD);


- Le Master Professionnel en Système d‘Information – Géomatique – Télédétection et
Décision (SIGDTD).

21
1.4.1 Master professionnel en management décisionnel
1.4.1.1 Condition d’accès

En S7: Sur sélection de dossier après Licence en Administration Economique et Sociale, en


Gestion ou en Économie.

En S9 : Après validation des crédits déjà obtenus par les responsables

1.4.1.2 Durée de formation

La durée de formation est quatre semestres (Deux années universitaires).

1.4.1.3 Objectifs

Le Master Management décisionnel a pour objectif d‘équiper l‘apprenant avec les


outils de prise de décisions en matière de management et de leur donner les compétences
requises dans ce domaine .Comme le management a besoin de se conformer en permanence
aux diverses nouvelles exigences du marché, l‘enseignement doit alors toujours viser à mettre
à jour les connaissances de l‘apprenant par la formulation de programmes de cours qui
tiennent compte de ces nouveautés. Ainsi l‘objectif majeur du parcours est d‘avoir des acteurs
de haut niveau en management décisionnel. Enfin, les parcours préparent des cadres capables
de gérer et créer un projet de développement économique régional et national.

1.4.1.4 Insertion professionnelle

Les sortants de la mention Management Décisionnel travaillent dans les secteurs privé
et public des différentes régions de Madagascar en tant que chefs de conduite de travaux
d‘enquêtes communautaires, concepteurs de projets, chefs de services ou de bureaux, chefs ou
directeurs d‘entreprises. Parmi ces secteurs où ils occupent des postes en conformité avec leur
formation on peut citer :

- Les Organismes (Organisation Non Gouvernemental,…) ;


- Les Ministères, (Ministère des Finances et des Budgets, Ministère du Tourisme,
Ministère de l‘Education Nationale, …) ;
- Les Directions Régionales (Direction Régionale de l‘Environnement et de Forêt,
Direction Régionale de l‘Eau….) ;

22
- Les Communes Urbaines ;
- Les sociétés d‘assurances (Ny Havana, ARO et MAMA) ;
- Les Sociétés Commerciales et industrielles : (Société Lazan‘i Betsileo, Société
JIRAMA, BOA, BNI et BFV-SG).

Enfin, les étudiants obtenus le diplôme de Master en Management Décisionnel sont capables :

- De créer une petite entreprise;


- De monter un projet de développement rural ;
- De gérer un grand projet.

1.4.2 Master professionnel en système d’information géomatique – télédétection


et décision
1.4.2.1 Condition d’accès

En S7: Sur sélection de dossier après Licence en Informatique, Gestion, Économie,


Mathématiques et Physique.

En S9 : Après validation des crédits déjà obtenus par les responsables.

1.4.2.2 Durée de formation

La durée de formation est quatre semestres (Deux années universitaires).

1.4.2.3 Objectifs

Le parcours Système d‘Information, Géomatique et Décision a pour objectif de donner


un panorama des recherches actuelles et émergeantes dans le domaine des systèmes d'aide à la
décision. Les systèmes informatiques et la géomatique connaissent en effet actuellement une
forte évolution (voire mutation) avec d'une part les grilles de calcul et d'autre part, les
multiples appareils mobiles intégrant des systèmes informatiques de plus en plus performants
et complexes. Ces systèmes informatiques intégrant un parallélisme massif ou/et une mobilité
des composants sont un défi pour le génie logiciel qui doit apporter de nouvelles méthodes et
des outils de production de logiciel pour la description de l'architecture de ces systèmes
complexes et pour leur validation et/ou certification. En plus, la montée en puissance des
techniques en géomatique va permettre de prendre une bonne décision à partir des données
spatiales et temporelles dans différents domaines.

23
1.4.3 Modalités d’entrée en M1 et en M2
Pour s‘inscrire en Master 1 et en Master 2 en Mention Management Décisionnel (MD) et en
Mention Système d‘Information Géomatique – Télédétection et Décision (SIGTD), les pièces
à fournir sont :

- Formulaire de candidature ;
- Une demande manuscrite adressée à Monsieur le Directeur du Centre ;
- Une copie certifiée du diplôme de Licence et Maitrise ou équivalent ;
- Une copie certifiée des relevés de notes en L1, L2, L3 et M1 ;
- Un curriculum vitae ;
- Une lettre de motivation ;
- Un bulletin de naissance moins de trois (03) mois ;
- Deux (02) enveloppes timbrées à l‘adresse du candidat (Ar 300) ;
- Une (01) enveloppe timbrée grand format (Ar 500) ;
- Trois (03) photos d‘identité ;

Droit d‘examen : Bordereau de versement d‘Ar 30. 000 au nom du Centre Universitaire de
Formation Professionnalisante de l‘Université de Fianarantsoa au compte BOA N°
12939120007.

Le dossier de candidature doit parvenir à MONSIEUR LE DIRECTEUR DU CENTRE


UNIVERSITAIRE FORMATION PROFESSIONNALISANTE – BP 1135 – 301 Fianarantsoa
OU À déposer au CENTRE UNIVERSITAIRE DE FORMATION
PROFESSIONNALISANTE

24
1.5 ORGANIGRAMME DU CUFP
L‘organigramme représente la structure hiérarchisée d‘un établissement de travail. Au
sein du centre, cette hiérarchie est présentée comme suit :

Figure 1.5 : Organigramme du CUFP

25
Chapitre 2 : PRESENTATION GENERALE DE LA CISCO
AMBALAVAO

2.1 HISTORIQUE
Avant 1972, Ambalavao était encore administrée par la Circonscription Scolaire de
Fianarantsoa. Après 1972, le ministère a opté la politique de la malgachisation et la
déconcentration du ministère était appliquée. Ainsi était créée la ZEB ou Zone de l‘Education
de Base dans chaque District.

L‘année 1975 était la date d‘ouverture de la ZEB d‘Ambalavao. Elle était administré
par un Professeur conseiller pédagogique dénommé Chef ZEB en la personne de
M.RANDRIAMARO Irénée, assisté d‘un secrétaire dans le traitement des affaires courantes
(M. RABENIALA René). Le Chef ZEB était le représentant du chef CISCO(Fianarantsoa)
dans le district. Le bureau de la ZEB siégeait encore à cette époque à l‘EPP d‘Avaramanda.

Pendant cette année, un bureau-logement a été construit à Avaratsena, entre le bureau de la


poste et la caserne de la brigade de Zandarimariam-pirenena d‘Ambalavao y a été transféré
sans toutefois libérés, celui de l‘EPP d‘Avaramanda devenu magasin de stockage des vivres
PAM car AMBALAVAO avait été choisi comme pilote pour la création des cantines scolaires
par le projet PAM ou Programme Alimentaire Mondial.

La ZEB ne gérait alors que quelques dizaines d‘EPP et un CEG (Ambohijafy)

A partir de 1975, compte tenu de la politique présidentielle un EPP par Fokontany, un CEG
par Commune, la tâche du Chef ZEB s‘avérait plus lourde, il était seconde par un adjoint
administratif en la personne de RAVOAVY Michel, instituteur de la catégorie «B ».

Petit à petit la ZEB devenait autonome et ne dépendait plus de la CISCO de Fianarantsoa.

Notons que la dénomination de service avait été changé plusieurs fois à savoir ZEB-COZEB-
CIRESEB, avant de devenir en définitif CISCO.

ZEB : Zone de l‘Education de Base ;

26
COZEB : Circonscription de la zone d‘Education de Base ;

CIRESEB : Circonscription de l‘Enseignement Secondaire et de l‘Education de Base ;

CISCO : Circonscription Scolaire.

Au fil des années les attributions de la CISCO s‘alourdissaient au fur et à mesure des
créations de bâtiments scolaires tant du Niveau I, Niveau II, Niveau III, reflet de l‘évolution
de la CISCO n‘ayant auparavant que le CEG d‘Ambohijafy, elle compte actuellement à peu
près un lycée par commune , cette évolution lui procure l‘avantage d‘être choisie comme
CISCO pilote à presque tous les projets obtenus par le ministère (PAM-PRAGAP-APC-
Ecoles Mères)

PAM : Programme Alimentaire Mondial

PRAGAP : Programme de Renforcement et d‘Amélioration de la gestion Administrative et


Pédagogique

APC : Approche par la Compétence

Ecoles-Mères : tenues par les Enseignants Semi-Spécialité (ESS)

A mesure que les attributions de la CISCO s‘agrandissent le nombre du personnel


administratif s‘accroît progressivement.

Chef + un secrétaire
Chef + un adjoint administratif + deux secrétaires
Chef + deux adjoints (administratif et pédagogique) et les secrétaires
Chef + Trois adjoints (administratif, pédagogique et Programmation) et les secrétaires + Chef
ZAP
Chef + Trois adjoints (administratif, pédagogique et Programmation) et les secrétaires + Chef
ZAP + un conseiller pédagogique
Les bureau-logement ne suffisait plus face au nombre du personnel qui faisait fonctionner le
service, la CISCO a dû utiliser l‘ancien bâtiment qui contenait le groupe électrogène qui
alimentait la ville en électricité avant l‘arrivée de la JIRAMA en 1984.

Au temps du Chef CISCO RALAIVAO jeanmuël qui a voulu libérer l‘EPP Avaramanda et
grouper le personnel au même endroit, le troisième bâtiment sis à côté du bureau-logement a
été érigé par le personnel lui-même avec ses propres efforts et moyens.

27
Le quatrième bâtiment servant de salle de matériel informatique n‘a été obtenu qu‘en 2007, ce
qui résulte les quatre bâtiments utilisés par le CISCO jusqu‘à présent.

Au début, le Chef CISCO a été désigné parmi les professeurs conseiller pédagogiques
ayant fait de l‘Institut.
A partir de l‘année 2005, ce poste a fait l‘objet d‘un appel d‘offre lancé par le ministre.
Voici les responsables qui se sont succédé dans la gestion et l‘administration du service selon
la date et la dénomination du service.

- 1975: RANDRIAMARO Irénée (Conseiller pédagogique)

Secrétaire: RABENIALA René

Adjoint administratif : RAVOAVY Michel

- 1984 : RALAIVAO Jeanmuël Andriamaro (Professeur, conseiller pédagogique)

RAVOAVY Michel : Instituteur « cadre B » remplacé par RANAIVOSON Zalimon :


Instituteur « cadre B » lequel remplacer par RAZAFIMANDIMBY Marcel :
Instituteur « cadre B »
RAMARIDY Alexandre (conseiller pédagogique)

- 1987: RAZAFINDRAINIBE Raymond Cyril (Professeur, conseiller pédagogique)

Adjoint Administratif : RAZAFIMANDIMBY Marcel : Instituteur « cadre B »

Adjoint Pédagogique : RAVELO Marcel : Instituteur « cadre B »

Adjoint à la programmation : RAVOAJANAHARY Gilbert: Instituteur« cadre B »

- 1989 : RAZAFINDRAKOTO Joseph (Professeur, conseiller pédagogique)

RAZAFINDRAINIBE Raymond Cyril étant admis à l‘Inspectorat

RANDRIANATOANDRO (Adjoint Maire Ambalavao)

- 1997 : RAKOTOSON George (Professeur Certifié)

Adjoint Administratif : RANDRIAMBAO Roger

Adjoint Pédagogique : RAVELO Marcel

28
Adjoint à la programmation : RANDRIANATOANDRO

- 1999 : RABOTO David (conseiller pédagogique)

Adjoint Administratif : RAZAFIMANDIMBY Marcel

Adjoint Pédagogique : R.Felix

Adjoint à la programmation : RANDRIANATOANDRO

- 2003: RAZAFINDRAKOTO Joseph (Professeur, conseiller pédagogique)

Adjoint Administratif : RAZAFIMANDIMBY Marcel (Retraité plus tard)

Adjoint Pédagogique : RATSIMBAZAFY Noël

Adjoint à la programmation : RANDRIANATOANDRO

- 2010 : RAZANAKOLONA Alfred (Retraité plus tard)

Adjoint Administratif : RAZAFIMALALA Charline

Adjoint Pédagogique : RATSIMBAZAFY Noël

Adjoint à la programmation : RANDRIANATOANDRO (Retraité plus tard)

- 2013 : RASOLOVOAHANGY Andrianantenaina

Adjoint Administratif : RATSIMBAZAFY Noël

Adjoint Pédagogique : RAVELOJAONA Joseph

Adjoint à la programmation : RANDRIANIVO Mamy Julien

29
2.2 ORGANIGRAMME DE LA CISCO AMBALAVAO
Comme la hiérarchie des personnels dans toutes les entreprises, sociétés ou
établissement, la figure suivante représente l‘organigramme de la CISCO Ambalavao

Figure2.2 : Organigramme de la CISCO Ambalavao

30
2.3 CYCLE DES DOSSIERS POUR LA RETRAITE

2.3.1 Gestion des ressources humaines


La gestion des ressources humaines est un ensemble de pratiques ayant pour objectif
de mobiliser et développer les ressources humaines pour une plus grande efficacité et
efficience, en soutien de la stratégie d'une organisation (association, entreprise, administration
publique). C'est une activité essentiellement fonctionnelle de l'entreprise, de nature
transversale (horizontale) par opposition à une activité hiérarchique (verticale).
En simplifiant, elle se divise en deux grandes branches :
d'un côté l'administration des ressources humaines qui est une activité plus verticale
et de l'autre le développement des ressources humaines qui est de plus en plus souvent
partagée avec les managers opérationnels.

2.3.2 Retraite
C‘est la cessation définitive des activités professionnelles conformément aux
dispositions réglementaire et législative.
Il existe trois types de retraite qui sont :
- la retraite en cas de limite d‘âge si le personnel atteint l‘âge de 60 ans ;
- la retraite anticipée qu‘on peut distinguer en deux cas : la retraite d‘ancienneté si la
personnel avait accompli 25 ans de service et la retraite proportionnelle pour le
personnel qui avait accompli de 15 ans de service.

2.3.2.1 Les pièces à fournir


Pour la demande, les pièces à fournir sont très importantes et entre ces deux types de retraire
il y a de différence pour les pièces à fournir.

31
Tableau 2.3.2.1 : Listes des pièces à fournir
Pour la retraite en cas de limite d’âge Pour la retraite en cas anticipée
- Acte de naissance - Demande avec avis favorable du Chef
- Extrait du dernier arrêté hiérarchique
d‘avancement - Acte de naissance
- Relevé de service (établi par la - Extrait du dernier arrêté
CISCO) d‘avancement
- Souche du bon de caisse ou de l‘avis - Relevé de service (établi par la
de crédit CISCO)
- Souche du bon de caisse ou de l‘avis
de crédit

2.3.2.2 Circuit des dossiers

Ce tableau montre les circuits des dossiers suivants les différents bureaux hiérarchiques.
Tableau 2.3.2.2 : Circuit des dossiers

32
PARTIE II : ANALYSE ET CONCEPTION

33
Chapitre 3 : ANALYSE DE L’EXISTANT

L‘Analyse de l‘existant sert à étudier et à critiquer tout ce qui existe dans l‘entreprise.
Cette étude permet de connaitre tous les problèmes et de proposer des solutions pour
résoudre les problèmes concernant les travaux dans le domaine.

3.1 ETUDE DE L’EXISTANT


Au sein du CISCO d‘Ambalavao, le service en informatique offre beaucoup
d‘avantage sur l‘enregistrement des données aux travaux pédagogiques.

3.1.1 Situation des matériels informatiques du CISCO d’Ambalavao


Le tableau ci-dessous présente tous les matériels informatiques du CISCO d‘Ambalavao.

Tableau 3.1.1.1 : Caractéristique des ordinateurs

Marque Processeur RAM HDD Ecran Lecteurs Nombre

DVD-
Intel Core-i3
PROLINK 4 Go 500 Go LED 17‘‘ R/RW 01
2,00 GHz
Intel Pentium
RAFFLE 4 512 Mo 40 Go CRT 15‘‘ CD-R 01
2,00 GHz
Intel Pentium
DELL 4 256 Mo 20 Go CRT 15‘‘ CD-R 01
2,00 GHz
PC bureau
Intel Pentium
NEC 4 512 Mo 20 Go CRT 15‘‘ CD-R 01
2,00 GHz
Intel Pentium
Max Data 4 256 Mo 20 Go CRT 15‘‘ CD-R 01
1,80 GHz
Intel Pentium
CD-R
CONCEPT 4 512 Mo 40 Go CRT 15‘‘ 01
2,00 GHz
Intel Core-i3 DVD-
PC Portable ACER 4 Go 500 Go LCD 15‘‘ 01
1,80 GHz R/RW

Tableau 3.1.1.2 : Caractéristique des imprimantes.

Marque Vitesse Résolution Nombre

hp LaserJet 20 Pages/min 1200 dpi 02

34
Tableau 3.1.1.3 : Caractéristique du switch.

Marque débit Ports Nombre

Prolink 100Mbps 08 01

Tableau 3.1.1.4 : Caractéristique de l‘onduleur.

Marque Nombre

PROLINK 01

3.1.2 Situation des logiciels informatiques du CISCO d’Ambalavao


Tous ces matérielles ont besoins des logiciels pour ses fonctionnements et ainsi pour
les traitements des travaux au niveau bureautique. Chaque ordinateur possède un système
d‘exploitation et des logiciels d‘application;

Voici les logiciels bureautiques que l‘entreprise utilise :

Tableau 3.1.2 : Logiciels existants au sein du CISCO

Désignation Caractéristiques

Systèmes d‘exploitation Windows XP, Windows7, Windows8

Logiciels de bureautique Ms Access, Ms Excel et le Ms Word 2003 et


2007,
Adobe Reader.
Antivirus AVAST, Smadav

Navigateurs Internet explorer, Mozilla Firefox.

35
3.1.3 Diagramme de tâches-documents
Ce tableau présente les différentes tâches et les documents qui circulent entre
système et responsable.

Tableau 3.1.3.1 : Présentation des symboles du « diagramme tâches-documents »

36
Tableau 3.1.3.2 : Présentation de « diagramme tâches-documents »

37
3.1.4 Description de tâches-documents
- Documents

Ce tableau explique l‘état des documents qui passent au système.

Tableau 3.1.4.1 : Présentation de «description de tâches»

Numéro
Numéro document Libellé-rôle
tâche
Informations sur les dossiers: qu‘il s‘agit les
D1 différents dossiers à fournir et le motif. T1, T2 et T3

Dossiers du personnel: qui détermine


D2 l‘information concernant le personnel sur les
dossiers. T2, T3

Demande envoyé: qui détermine les personnels


D3 qui appartiennent les dossiers envoyés. T4 et T5

Sous Microsoft Excel, qui contient les


informations de demandes et les dossiers du
personnel. T1 et T2

Sous Microsoft Excel, qui contient les


informations des dossiers envoyés.
T3 et T4

38
- Tâches

Ce tableau explique l‘état de tâches exécutées par le responsable.

Tableau 3.1.4.2 : Présentation de « description de documents »

N° Document Document
Description Poste de travail Fréquence
tâche entré sorti

Vérification des dossiers : Pour les


contrôles des différents dossiers à
fournir.
T1 Responsable - D1 -

Saisie du personnel :
Enregistrement des informations
concernant les personnels et ainsi
T2 Responsable Par jour D1 -
ses dossiers.

MAJ de l‘état des dossiers :


Vérification des informations
T3 enregistrées (Modification - Responsable Par jour -
D2
suppression)

Validation des dossiers :


Enregistrement des dossiers
T4 complets après vérification. Responsable Par jour D3 -

MAJ de l‘état des personnel :


Vérification des informations
T5 Responsable
enregistrées (Modification - D4
Suppression) et envoi des dossiers.

3.2 CRITIQUE DE L’EXISTANT


La critique de l‘existant consiste à classer les différents points forts et les points
faibles du système et ainsi les applications existants. Alors, d‘après les analyses faites auprès
de chaque poste de travail, nous avons recensé les informations suivantes:

3.2.1 Les points forts


- La configuration des machines pour la nouvelle application développée sont assez
puissantes et satisfaisantes tous les besoins de cette logiciel ;

39
- Tous les machines sont connectées en réseau pour faciliter la réalisation de
l‘application Client/serveur ;

3.2.2 Les points faibles


- L‘utilisation du tableur Microsoft Office Excel n‘est pas rentable pour les gestions des
différents processus et ainsi les risques de confondre à la conception des données ;
- L‘organisation sémi-manuelle des tâches ;
- Les collections des informations et leurs enregistrements sont faits sur des supports
physiques (papiers, fiches,…). Ce qui risque d‘être endommagé, égarés ou confondus
avec les autres documents.

3.3 SOLUTION ENVISAGEE


Puisque l‘établissement a remarqué que l‘utilisation de l‘informatique diminue les
pertes de temps et facilite les différentes tâches, il est actuellement temps de suivre la
technologie, car en informatique, l‘origine c‘est le développement et ainsi pour la technologie.
Vu les objectifs à atteindre pour exprimer les besoins de l‘établissement de la CISCO
Ambalavao, nous avons proposé quelque solutions. La création d‘une application pour
permettre la mise en place de base de données [1], et pour mieux gérer la gestion des
demandes de retraite. La formation pour l‘utilisateur afin ils puissent utiliser facilement
l‘application. En plus, cette application permettre une large autonomie de paramétrage : les
utilisateurs peuvent disposer d‘outils plus simple et faciles lors de l‘insertion et de la mise à
jour des donnés sans avoir appel à des développements de l‘éditeur (aucune langage
informatique, aucune compétence spécifique de haut niveau ne doivent être requises pour
configurer et administrer la base de données).

3.4 FONCTIONNALITES GENERALES DE L’APPLICATION


L‘application envisagée contiendra les grands points importants suivants :

- Mise à jour dans la base de données : ajout, modification et suppression des


enregistrements des données, dans la base ;
- Consultation, recherche et impression de données ;
- L‘Authentification pour protéger l‘utilisation des données dans la base.

40
3.5 ETUDE D’OPPORTUNITE
En utilisant cette application, l‘établissement de la CISCO d‘Ambalavao bénéficie de
quelques fonctionnalités suivant :

- Les traitements automatiques de la mise à jour et d‘enregistrement de données dans la


base sont rapides, fiables et efficace ;
- L‘application sont facile à utiliser, de rechercher, sauvegarder et imprimer les données
à tout moment voulu ;
- Toutes les informations sont stockées et manipulées dans le Système de Gestion de
Base de Données SGBD.

3.6 ETUDE DE FAISABILITE


Notre étude n‘est autre que la vision de la faisabilité et les échanges apportés de cet
ouvrage quand il est établi dans cette entreprise. Alors, voici quelques points de vue :

3.6.1 Point de vue de sécurité


Pour garantir la sécurité de notre logiciel et ses données indispensables, il vaut mieux
utiliser les matériels de sauvegarde comme : le flash disque, disque dur externe, le Compact
Disk, carte mémoire et les autres matériels fiables pour le stockage des données. En effet,
nous avons suggéré d‘utiliser de préférence le flash disque et le disque dur externe pour
assurer la sauvegarde des données, en vue d‘éviter la défaillance matériel.

3.6.2 Ressources humaines


Pour mettre en place notre présent projet, on a besoin d‘additionner les conditions
suivantes :
- Une formation pour les responsables concernées qui va se servir de l‘application ;
- Une personne compétente pour maintenir l‘application en lisant attentivement
l‘indication proposée et la suivre tout simplement.

41
Chapitre 4 : CONCEPTION

4.1 PRESENTATION DE LANGAGE UML


Né de la fusion des méthodes objet dominantes (OMT, Booch et OOSE), puis
normalisé par l'OMG en 1997, UML est rapidement devenu un standard incontournable.
UML n'est pas à l'origine des concepts objet, mais il en en donne une définition plu formelle
et apporte la dimension méthodologique qui faisait défaut à l'approche objet. Le but de cette
présentation n'est pas de faire l'apologie d'UML, ni de restreindre UML à sa notation
graphique, car le véritable intérêt d'UML est ailleurs. En effet, maîtriser la notation graphique
d'UML n'est pas une fin en soi. Ce qui est primordial, c'est d'utiliser les concepts objet à
bon escient et d'appliquer la démarche d'analyse correspondante. [2]

4.1.1 Les différents types de diagramme en UML


L‘UML ou « Unified Modeling Langage » est un langage de modélisation comme sa
traduction en français « Langage de modélisation d‘objet unifié ».
Voici tous les étapes que la modélisation contient :
Les principaux diagrammes en UML sont :

- Le diagramme des cas d‘utilisation : représente les fonctionnalités que le système doit
savoir faire ;
- Le diagramme de classes et le diagramme d‘objets : représente la description statique
des données et des traitements ;
- Le diagramme états-transitions et le diagramme d‘activités : représente les états des
objets selon les événements ;
- Le diagramme de séquence et le diagramme de collaboration : représente les
interactions entre objets ;
- Le diagramme de composants et le diagramme de déploiement : représente la
réalisation et le déploiement.

42
Parmi les neuf diagrammes d‘UML, nous allons nous limiter à quatre de ces diagrammes pour
résoudre les problèmes. Ces quatre diagrammes sont :

- Diagramme des cas d‘utilisation ;


- Diagramme de séquence ;
- Diagramme de classes;
- Diagramme d‘activités.

4.1.2 Le diagramme des cas d’utilisation avec le formalisme

Les cas d‘utilisation font apparaître les besoins fonctionnels et leur ensemble
constituant le diagramme de cas d‘utilisation décrit les fonctionnalités complètes du système.
Pour avoir plus de clarté, chaque cas d‘utilisation est suivi de :
- Description textuelle des cas d’utilisation : C‘est la présentation des points
essentiels pour spécifier de façon pertinente un cas d‘utilisation c‘est a dire le
nom du cas d‘utilisation, les acteurs, l‘objectif, le résumé du métier, les prés et post
conditions, les enchainements des actions, ainsi que les exceptions ;
- Les scénarios : Ces scénarios sont décrits sous la forme d‘échange d‘évènements
entre l‘acteur et le système. On distingue le scénario nominal, qui se déroule quand il
n‘y a pas d‘erreur, des scénarii alternatifs qui sont les variantes du scénario nominal et
enfin les scénarii d‘exception qui décrivent les cas d‘erreurs.

4.1.2.1 Les éléments constitutifs du diagramme des cas d’utilisation


- Un Acteur
Un acteur est l‘idéalisation d‘un rôle joué par une personne externe, un processus ou une
chose qui interagit avec un système. Il se représente par un petit bonhomme avec son nom
inscrit dessous comme l‘indique la figure ci-dessous.

.
Figure 4.1.3 : Un acteur

43
- Un cas d’utilisation

Un cas d‘utilisation est une unité cohérente représentant une fonctionnalité visible de
l‘extérieur. Il réalise un service de bout en bout, avec un déclenchement, un
déroulement et une fin. Un cas d‘utilisation se représente par une ellipse contenant le nom du
cas.

4.1.2.2 Formalisme du diagramme des cas d’utilisation

Cette figure illustre le formalisme du diagramme des cas d‘utilisation

Figure 4.1.3.1 : Formalisme du Diagramme de cas d‘utilisation

4.1.3 Le diagramme de séquence


Les diagrammes de séquences mettent en valeur les échanges de messages (déclenchant
des événements) entre acteurs et objets (ou entre objets et objets) de manière chronologique.

4.1.3.1 Les éléments constitutifs du diagramme de séquence

- Les lignes de vie


Les lignes de vie sont représentées par des rectangles contenant une étiquette dont la syntaxe
est : [<nom_du_rôle>] : [<Nom_du_type>] Au moins un des deux noms doit être spécifié
dans l‘étiquette, les deux points (:) sont, quant à eux, obligatoire.
La figure ci-dessous montre une ligne de vie

44
Figure 4.1.3.1.1 : Ligne de vie

- Les messages
Un message définit une communication particulière entre des lignes de vie. Plusieurs
types de messages existent, les plus courants sont :
- Messages asynchrones
Ces messages n‘attendent pas de réponse et ne bloquent pas l‘émetteur. La figure ci-dessous
montre un message asynchrone.

Figure 4.1.3.1.1.1 : Formalisme d‘un message asynchrone

- Messages synchrones
L‘émetteur reste bloqué le temps que dure l‘invocation de l‘opération. La figure ci-dessous
montre un message synchrone.

Figure 4.1.3.1.1.2 : Formalisme d‘un message synchrone

45
4.1.3.2 Formalisme du diagramme de séquence

La figure suivante montre le formalisme du diagramme de séquence.

Figure 4.1.3.2 : Formalisme du diagramme de séquence

4.1.4 Le diagramme de classes


Le diagramme de classes exprime de manière générale la structure statique d‘un système,
en termes de classes et de relations entre ces classes. C‘est un diagramme permettant de
décrire de manière abstraite et générale les liens entre objets.

4.1.4.1 Les éléments constitutifs du diagramme de classes


Une classe définit un jeu d‘objets dotés de caractéristiques communes.
La figure ci-dessous illustre une classe

CLASSE
VISIBILITE
- : attribut private
+ : attribut public

Figure 4.1.4.1.1 : Formalisme d‘une classe

46
Les associations

Une association représente une relation structurelle entre classes


d‘objets. La plupart des associations sont binaires, c‘est à dire qu‘elles connectent
deux classes. On représente une association en traçant une ligne entre les classes associées.

Multiplicité des associations :


Un rôle est doté d‘une multiplicité qui fournit une indication sur le nombre d‘objets d‘une
même classe participant à l‘association. La notation est la suivante :

Tableau 4.1.4.1.2 : Multiplicité des associations

Multiplicité Sens
1 Obligatoire (un et un seul)
0..1 Optionnel (0 ou 1)
0..* ou * Quelconque
n..* Au moins n
n..m Entre n et m
l,n,m l, n, ou m

La figure montre le formalisme du diagramme de ci-dessous classes

Figure 4.1.4.1.2 : Formalisme d‘un Diagramme de classes

4.1.5 Le diagramme d’activités


Les diagrammes d‘activités permettent de mettre l‘accent sur les traitements. Ils sont donc
particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de flots de
données. Ils permettent ainsi de représenter graphiquement le comportement d‘une méthode
ou le déroulement d‘un cas d‘utilisation.

47
4.1.5.1 Les éléments constitutifs du diagramme d’activités
Un diagramme d‘activité est composé par des nœuds d‘activités comme l‘indique la figure
suivante.

Figure 4.1.5.1.1 : Eléments constitutifs du diagramme d‘activités

La figure ci-dessous illustre le diagramme d‘activités

Figure 4.1.5.1.2 : Formalisme du Diagramme d‘activités

48
4.2 PHASE DES ETUDES DETAILLEES

4.2.1 Dictionnaire des données


Une méthode ou une notation consiste donc à identifier en premier lieu toutes les
propriétés d‘information à l‘analyse ; c‘est-à-dire qu‘il est intéressant d‘établir un dictionnaire
de données qui ne devront ni synonyme d‘un champ ou des données calculée. Le dictionnaire
de données est utilisé pour pouvoir détailler et bien définir les données nécessaires à la
conception d‘un système d‘information fixé par l‘entreprise. Il est aussi obtenu à partir de
l‘interview en lisant les informations collectées indispensables pour la conception d‘un
système d‘information. Le dictionnaire des données décrit la totalité des données manipulées,
Il est représenté sous forme d‘un tableau comme ci - dessous.

Tableau 4.2.1 : Dictionnaire des donnes.

Mnémoniques Définitions Types Obligatoire Longueur

adresse_pers adresse du personnel texte oui 40

adresse_pers Adresse du responsable texte oui 40

Copie_act Copie d‘acte de naissance texte oui 20

Copie_avcm Copie du dernier avancement texte oui 20

date_dem date de la demande date oui 10

date du dépôt des dossiers en cas


date_depot1 date oui 10
volontaire

date du dépôt des dossiers en cas


date_depot1 date oui 10
anticipé

date_naiss_pers date de naissance du personnel date oui 10

Date_naiss_resp date de naissance du responsable date oui 10

Dmd_papier Demande sur papier libre texte oui 20

id_dem identification de la demande identifiant oui 10

im_pers immatricule du personnel identifiant oui 5

im_resp Immatricule du responsable identifiant oui 5

49
Mnémoniques Définitions Types Obligatoire Longueur

indice_pers Classement du personnel identifiant oui 06

indice_resp Classement du responsable identifiant oui 06

motif_pers motif du personnel texte oui 10

nom_pers nom du personnel texte oui 40

nom_resp Nom du responsable texte oui 40

Num_doss1 Numéro de dossier an cas volontaire identifiant oui 5

Num_doss2 Numéro de dossier an cas anticipé identifiant oui 5

poste_successive poste successive du personnel texte oui 200

prenoms_pers prénoms du personnel texte oui 40

prenoms_resp Prénoms du responsable texte oui 40

Releve_svc Relevé des services texte oui 20

sexe_pers sexe du personnel texte oui 10

Souche_bs Souche bulletin de solde texte oui 20

tel_pers téléphone du personnel texte oui 10

Tel_resp Telephone du responsable texte oui 10

4.2.2 Règles de gestion


Les règles de gestion sont des descriptions des « actions » qui sont à modéliser dans le
système. Ils peuvent s'agir d'une disposition légale, d'une exigence formulée par le client ou
d'un article de règlement interne. Les règles de gestion guident et documentent la création
d'un modèle.
Elles sont régies comme suit :

50
Tableau 4.2.2 : Règles de gestion.

Référence Descriptions
Tous les personnels qui demandent de retraite sont tous enregistrés, et possèdent
RG00 une identification unique.
RG01 chaque personnel appartient à un établissement.

RG02 tous les établissements possèdent chacune un identifiant.

RG03 chaque établissement appartient dans une zap.

RG03 Les zap ont chacune leur identifiant.

RG04 chaque zap appartient dans une cisco.

RG05 chaque cisco possède un identifiant.

RG06 Pour chaque demande, on doit avoir un motif pour cette demande dont elle
possède un identifiant.

4.2.3 Règle d’organisation


L'organisation désigne l'ensemble des responsabilités, pouvoirs et relations entre les
personnes permettant à un organisme d'atteindre ses objectifs.
La règle d'organisation repose de ce fait sur l'établissement d'un certain nombre de procédures
écrites.

Tableau 4.2.3 : Règles d‘organisation

Référence Descriptions
RO01 L‘utilisateur doit enregistrer tous les tous les personnels qui font les demandes
de retraite.
RO02 Le chef CISCO doit contrôler tous les dossiers apportés avec la demande.
RO3 Le chef CISCO doit valider les dossiers de demande.
L‘utilisateur de l‘application peut faire les opérations suivant :
RO04 Ajout d‘un enregistrement
Suppression d‘un enregistrement ;
Mise à jour d‘un enregistrement.

51
4.3 MODELISATION

4.3.1 Modèle de cycle de vie d’un logiciel


Tous les modèles du cycle de développement ne sont pas les mêmes, mais l'idée est
toujours la même : le logiciel est développé en phases discrètes, chacune ayant un résultat
défini et un critère de terminaison défini, et chaque phase est achevée avant que commence la
suivante. Le modèle classique du cycle de développement comprend les phases suivantes :
analyse, conception, implémentation, test, et éventuellement phase d'installation. D‘autres
noms sont parfois donnés à ces phases et un découpage plus fin est souvent utile.

Chaque phase a des entrées et des sorties, qui sont généralement des documents et
parfois des produits. Toute sortie d'une phase servira d'entrée à une phase ultérieure, souvent
celle qui suit immédiatement, mais pas toujours. Certaines activités déployées pendant une
phase lui sont donc spécifiques et d'autres sont destinées à préparer les phases qui suivent.

4.3.2 Présentation des modèles


Il existe plusieurs types de modèle de cycle de vie d‘un logiciel tel que : le modèle en
cascade ; le modèle en V et le modèle en Spirale.

4.3.2.1 Modèle en V
Le principe de ce modèle est qu'avec toute décomposition doit être décrite la
recomposition, et que toute description d'un composant est accompagnée de tests qui
permettront de s'assurer qu'il correspond à sa description. Ceci rend explicite la préparation
des dernières phases (validation-vérification) par les premières (construction du logiciel), et
permet ainsi d'éviter un écueil bien connu de la spécification du logiciel : énoncer une
propriété qu'il est impossible de vérifier objectivement après la réalisation.

On distingue donc deux sortes de dépendances :

- enchaînement et itération : se déroulent essentiellement de gauche à droite ;


- préparation des phases ultérieures. Par exemple à l'issue de la conception
architecturale le protocole et les jeux de test de l'intégration doivent être
complètement décrits.

52
Conséquences :
- obligation de concevoir les jeux de test et leurs résultats ;
- réflexion et retour sur la description en cours ;
- meilleure préparation de la branche droite du V.

Le model en V comprend généralement les étapes suivantes :

- Analyse des besoins et faisabilité : c‘est-à-dire l‘expression, le recueil et la


formalisation des besoins du demandeur (le client) et de l‘ensemble des contraintes,
puis l‘estimation de la faisabilité de ces besoins.
- Spécifications ou conception générale : Il s‘agit de l‘élaboration des spécifications de
l‘architecture générale du logiciel.
- Conception détaillée : Cette étape consiste à définir précisément chaque sous-
ensemble du logiciel.
- Codage (Implémentation ou programmation) : c‘est la traduction dans un langage de
programmation des fonctionnalités définies lors de phases de conception.
- Tests unitaires : Ils permettent de vérifier individuellement que chaque sous-ensemble
du logiciel est implémenté conformément aux spécifications.
- Intégration : L‘objectif est de s‘assurer de l‘interfaçage des différents éléments
(modules) du logiciel. Elle fait l‘objet de tests d‘intégration consignés dans un
document.
- Qualification (ou recette) : C‘est-à-dire la vérification de la conformité du logiciel aux
spécifications initiales.
- Mise en production : C‘est le déploiement sur site du logiciel.
Notons aussi que les activités de chaque phase peuvent être réparties en 5 catégories :
- assurance qualité ;
- production ;
- contrôle technique ;
- gestion ;
- contrôle de qualité.

53
La figure suivante représente le modèle de cycle de vie en V.

Figure 4.3.2.1 : Le cycle en V

4.3.2.2 Modèle en cascade


Dans ce modèle, le principe est très simple. Chaque phase se termine à une date
précise par la production de certains documents ou logiciels. Les résultats sont définis sur la
base des interactions entre étapes et activités, ils sont soumis à une revue approfondie, on ne
passe à la phase suivante que s'ils sont jugés satisfaisants.

Certaines phases portent le nom d'une activité ce qui signifie que l'activité est
essentielle pour cette phase, mais n'impose pas qu'elle n'ait lieu que dans cette étape. D'autres
activités interviennent, par exemple le contrôle technique et la gestion de la configuration sont
présents tout au long du processus.

Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été


rajoutée ultérieurement sur la base qu'une étape ne remet en cause que l'étape précédente, ce
qui, dans la pratique, s'avère insuffisant.

54
Les développements récents de ce modèle font paraître de la validation - vérification à chaque
étape :

- faisabilité et analyse des besoins : validation ;


- conception du produit et conception détaillée : vérification ;
- intégration : test d'intégration et test d'acceptation ;
- installation : test du système.

Représentation graphique du modèle de cycle de vie en cascade :

Figure 4.3.2.2 : Le cycle en cascade

4.3.2.3 Modèle en spirale


Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent.
Il met l'accent sur l'activité d'analyse des risques : chaque cycle de la spirale se déroule en
quatre phases :
1. détermination, à partir des résultats des cycles précédents ou de l'analyse préliminaire
des besoins, des objectifs du cycle, des alternatives pour les atteindre et des
contraintes;

55
2. analyse des risques, évaluation des alternatives et éventuellement maquettage ;
3. développement et vérification de la solution retenue, un modèle « classique » (cascade
ou en V) peut être utilisé ici ;
4. revue des résultats et vérification du cycle suivant.
L'analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des
maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle
se termine par un processus de développement classique.

Figure 4.3.2.3 : Modèle de cycle de vie en spirale

56
4.3.3 Etudes comparatives de ces trois modèles
Ce tableau représente les avantages et les inconvénients de ces trois modèles :

Tableau 4.3.3 : Comparaison de ces trois modèles de cycle de vie


Modèles Avantages Inconvénients
- Il est un modèle éprouvé car calque sur la
production industrielle classique ;
- Il permet l‘organisation du travail et des équipes ;
- Il favorise la décomposition hiérarchique
En V fonctionnelle ;
Le modèle en V ou en cascade
- Il propose des étapes clés (Documentation, revues)
reportent trop de choses à l'étape
qui entraine un bon suivi du projet ;
programmation. En particulier
- Il permet de garantir une certaine qualité (plan
l'interface utilisateur n‘apparaîtra
assurance qualité) ;
que fort tard. Il n'y a pas assez de
- Il est adapté à des grands projets.
bornes intermédiaires
- chaque développement est moins complexe ;
permettant de valider ce que sera la
- les intégrations sont progressives ;
version finale du produit.
- possibilité de livraisons et de mises en service
En après chaque incrément ;
cascade - meilleur lissage du temps et de l'effort de
développement à cause de la possibilité de
recouvrement des différentes phases.
Ce modèle a été moins expérimenté
- ce modèle de cycle de vie tient compte de la que les deux précédents. Sa mise en
possibilité de réévaluer les risques en cours de œuvre demande de grandes
développement. compétences et devrait être limitée
En - Il couvre l'ensemble du cycle de développement aux projets innovants à cause de
spirale d'un produit. Il met l'accent sur l'activité l'importance qu'il accorde à l'analyse
d'analyse des risques. des risques. Néanmoins, ce dernier
concept peut être appliqué aux autres
modèles.

57
4.3.4 Gestion du projet
Pour la réalisation de l‘application de gestion des demandes de retraite, nous
utilisons le modelé du cycle en V car sa représentation tient d'avantage à la réalité, le
processus de développement n'est pas réduit à un enchaînement de tâches séquentielles.
Elle montre que:
- c'est en phase de spécification que l'on se préoccupe des procédures de
qualification ;
- c'est en phase de conception globale que l'on se préoccupe des procédures
d'intégration ;
- c'est en phase de conception détaillée que l'on prépare les tests unitaires ;
- Le modèle de cycle de vie en V permet d'anticiper sur les phases ultérieures de
développement du produit. En particulier le modèle en V permet de commencer
plus tôt :
- Le plan de tests de qualification ;
- Le plan d'évaluation des performances ;

4.3.5 Choix de l’outil de conception pour UML


Pour l‘outil de conception en UML, Nous utilisons Visual paradigm pour réaliser le
diagramme de cas d‘utilisation et le diagramme d‘activité et Win‘disign pour le diagramme de
séquence. Chaque logiciel sera évalué selon sa qualité à traduire différents éléments d‘un
diagramme de classes.

58
Le tableau ci-dessous représente le différent outil de conception.

Tableau 4.3.5 : Les différents types de l‘outil de conception.

Points Poséidon

Forts -Un grand choix de l‘SGBD est pris en compte.


-La robustesse et la qualité de l‘ergonomie qui permet de travailler facilement avec les
différents diagrammes dans le même environnement.

-La création de classes-associations et de l‘association réflexive n‘est pas aisée

-Les options ne sont pas toutes traduites en français.


faibles
- Les associations n-aire ne sont pas prises en comptes.

-Il n‘y a pas de processus de rétro-conception d‘une base.

-Le niveau logique n‘est pas supporté, la génération du code SQL est plus que limite.
Visual paradigm

Forts -Un grand choix de l‘SGBD est pris en compte, la réactivité et l‘efficacité du support

-Le déplacement des objets et de liens sur un graphique du niveau logique qui n‘est pas
toujours réussi et aussi l‘absence de l‘identifiant de classe et de l‘association n-aire.
faibles
Win‘ design

Forts -C‘est un outil le plus facile à utiliser et son interface est très intuitive.

faibles -Le point faible de la version évaluée concerne la transformation de diagramme UML
complexes en MLD et en MCD. Les problèmes sont connus et en cours de maintenance

59
4.4 REPRESENTATION DU DIAGRAMME DE CAS D’UTILISATION
Pour notre projet, le diagramme de cas d‘utilisation est représenté comme indique la
figure ci-dessous.

Figure 4.4 : Diagramme de cas d'utilisation

4.4.1 Description des fonctionnements des cas d’utilisation

Le diagramme de cas d‘utilisation nous montre les cas d‘utilisation, les acteurs, priorité du
cas d‘utilisation, les prés et post conditions, le système et ces fonctions essentielles, la
description des scénarii, Un modèle de description d‘un cas d‘utilisation est de spécifier de
façon pertinente dans ces points essentiels.

- Les cas d‘utilisation : décrit les grandes fonctions du système du point de vue des
acteurs;
- Les acteurs : ce sont des entités qui utilisent le système à représenter ;
60
- Priorité du cas d‘utilisation : pour la gestion du projet ;
- Les prés condition : elles décrivent dans quel état doit être le système (l‘application)
avant que ce cas d‘utilisation puisse être déclenché;
- Post conditions : elles décrivent l‘état du système à l‘issue des déférents scénarii;
- La description des scénarii : Ils sont décrits sous la forme d‘échanges d‘évènements
entre l‘acteur et le système,

Chaque cas d‘utilisation est décrit par une description fonctionnelle et correspond à un
diagramme de séquence.

4.4.2 Cas d’utilisation : « S’authentifier »

Ce cas d‘utilisation permet de vérifier le groupe d‘utilisateur pour d‘accéder à


l‘utilisation du système. Si non, il doit contacter l‘administrateur du système.
Pour avoir accès à l‘utilisation du système, il faut s‘authentifier.

- Description textuelle

Ce tableau représente la description textuelle pour le cas d‘utilisation s‘authentifier

Tableau 4.4.2.1 : Description « s‘authentifier »

Nom du cas S‘authentifier


Objectifs Vérifier l‘authenticité d‘un acteur pour se connecter
Acteur Principal Utilisateur
Pré Condition Le groupe d‘utilisateur n‘est pas encore inséré dans la
base de données ne peut pas se connecter
Post Condition Ouverture de session
Date 12/01/2015
Responsable Laza
Version 1.0

61
- Description des scénarii

Les tableaux ci-dessous présentent les descriptions des scenarii pour le cas d‘utilisation
s‘authentifier.

Scenario nominal

Tableau 4.4.2.2 : scenario nominal « s‘authentifier »

Utilisateur Système
Ouverture 1.1 Ouverture du formulaire accueil
Authentification Saisie authentification
Authentification avec succès
Accès aux formulaires

Scenario alternatif

Tableau 4.4.2.3 : scenario alternatif « s‘authentifier »

Utilisateur Système
A : Champ obligatoire vide
Vérification des champs obligatoires
Message qui indique que les champs obligatoires
doivent être remplis
Reprendre au point 1
B : Login ou Mot de passe erronée
Recherche d‘information dans la base
Message d‘erreur pour l‘authentification
Reprendre au point 1.

- Diagramme de séquence

Scénario nominal

Le scénario nominal de cas d‘utilisation «s‘authentifier» est représenté comme indique la


figure suivante.

62
Figure 4.4.2.1 : Diagramme de séquence « s‘authentifier » (sn)

Scénario alternatif

Le scénario alternatif de cas d‘utilisation «s‘authentifier» est représenté comme indique la


figure suivante.

Figure 4.4.2.2 : Diagramme de séquence « s‘authentifier » (sa)

63
- Le diagramme de classe

Le diagramme de classe de cas d‘utilisation «S‘Authentifier » est représenté comme indique


la figure ci-dessous.

Figure 4.4.2.3 : Diagramme de classe « S‘Authentifier »

4.4.3 Cas d’utilisation « Fournir dossiers »


Ce cas d‘utilisation permet d‘enregistrer les informations concernant nouveau offre c‘est-à-
dire un offre qui n‘est pas encore enregistré dans la base de données.

- Description textuelle
Le tableau ci-dessous représente la description textuelle pour le cas d‘utilisation « Fournir les
dossiers»

Tableau 4.4.3.1 : Description « Fournir les dossiers »

Nom du cas Fournir les dossiers


Objectifs pour les demandes de retraite
Acteur Primaire Personnel
Acteur Secondaire Responsable
Pré Condition les dossiers ne sont pas encore insérés dans la base
Post Condition dossiers enregistrés dans la base de données
Date 12/01/2015
Responsable Laza
Version 1.0

64
- Description des scénarii

Ces tableaux représentent la description des scenarii pour le cas d‘utilisation « Fournir les
dossiers».

Scenario nominal

Tableau 4.4.3.2 : Description des scenarii « Fournir les dossiers» (sn)

Personnel Système
2 Prépare les dossiers à déposés 2.2 Vérifier les dossiers déposés
2.3 Vérifier la date de dépôt des dossiers
Rapport d‘état

Scenario alternatif

Tableau 4.4.3.3 : Description des scenarii « Fournir les dossiers» (sa)

Personnel Système
2 Prépare les dossiers à déposés 2.2 Vérifier les dossiers déposés
2.3 Vérifier la date de dépôt des dossiers
2.4 Dossier invalide
Reprendre au point 2

- Diagramme de séquence

Scénario nominal

Le scénario nominal de cas d‘utilisation «Fournir les dossiers» est représenté comme indique
la figure ci-dessous.

Figure 4.4.3.1 : Diagramme de séquence «Fournir les dossiers» (sn)

65
Scénario alternatif

Le scénario alternatif de cas d‘utilisation «Fournir les dossiers » est représenté comme indique
la figure ci-dessous.

Figure 4.4.3.2 : Diagramme de séquence «Fournir les dossiers » (sa)

- Le diagramme de classe

Le diagramme de classe de cas d‘utilisation «Fournir les dossiers» est représenté comme
indique la figure suivante.

Figure 4.4.3.3 : Diagramme de classe «Fournir les dossiers»

66
4.4.4 Cas d’utilisation «Enregistrement de personnel»
Le tableau ci-dessous décrit le scénario nominal et alternatif du cas d‘utilisation
«Enregistrement de personnel».

- Description textuelle

Tableau 4.4.4.1 : Cas d‘utilisation « Enregistrement de personnel »

Nom du cas Enregistrement de personnel


Objectifs Ajouter personnel
Acteur Principal Utilisateur
Pré Condition Le personnel n‘est pas encore édité dans la base
Post Condition Le personnel est enregistré dans la base de données
Date 12/01/2015
Responsable Laza
Version 1.0

- Description des scénarii

Le tableau 18 présente la description des scenarii pour le cas d‘utilisation « Enregistrement de


personnel»

Scenario nominal

Tableau 4.4.4.2 : Description du scenarii nominal« Enregistrement personnel»

Utilisateur Système
3. Cliquer sur personnel Affichage du formulaire de personnel
3.3 Saisie sur les champs 3.4 Vérification et contrôle champ
3.5 Enregistrement
3.6 Rapport d‘état

Scenario alternatif
Tableau 4.4.4.3 : Description du scenarii alternatif« Enregistrement personnel»

Utilisateur Système
A : Champ obligatoire vide
Contrôle champs
Message d‘information pour les champs vides
Reprendre au point 3.2
B : Personne déjà existée à la base
Enregistrement
Vérification dans la base
Message d‘information que cette personne est déjà
existée
Reprendre au point 3.2

67
- Diagramme de séquence

Scénario nominal

Le Scénario nominal de cas d‘utilisation «Enregistrement de personnel» est représenté comme


indique la figure ci-dessous.

Figure 4.4.4.1 : Diagramme de séquence «Enregistrement de personnel» (sn)

Scénario alternatif

Le scénario alternatif de cas d‘utilisation «Enregistrement de personnel» est représenté


comme indique la figure suivante.

Figure 4.4.4.2 : Diagramme de séquence «Enregistrement de personnel» (sa)

68
- Diagramme d’activité «Enregistrement de personnel»

Le diagramme d‘activité de cas d‘utilisation «Enregistrement de personnel» est représenté


comme indique la figure ci-dessous.

OK

OK

OK OK

Figure 4.4.4.3 : Diagramme d‘activité «Enregistrement de personnel»

69
- Le diagramme de classe

Le diagramme de classe de cas d‘utilisation «Enregistrement de personnel» est représenté


comme indique la figure ci-dessous.

Figure 4.4.4.4 : Diagramme de classe «Enregistrement de personnel»

70
4.4.5 Cas d’utilisation « Enregistrement dossiers »
Le tableau ci-dessous décrit le scénario nominal et alternatif du cas d‘utilisation
« Enregistrement dossiers ».

Tableau 4.4.5.1 : Cas d‘utilisation «Enregistrement dossiers »

Nom du cas Enregistrement dossiers


Objectifs Ajouter les dossiers fournis
Acteur Principal Utilisateur
Pré Condition Les dossiers ne sont pas encore édités dans la base
Post Condition Les dossiers sont enregistrés dans la base de données
Date 12/01/2015
Responsable Laza
Version 1.0

- Description des scénarii

Le tableau suivant représente la description des scenarii pour le cas d‘utilisation


« Enregistrement dossiers »

Scenario nominal

Tableau 4.4.5.2 : Description des scenarii nominal « Enregistrement dossiers»

Utilisateur Système
2 Cliquer sur Ajouter 2.1 Affichage du formulaire d‘ajout
Remplissage des champs et Vérifie si les dossiers édités sont complets
Validation du formulaire d‘ajout Contrôle des champs
Contrôle de saisie
Insertion dans la base de données
Rapport d‘état

71
Scenario alternatif

Tableau 4.4.5.3 : Description des scenarii alternatif « Enregistrement dossiers»

Utilisateur Système
A : Vérification des dossiers
Remplissage des champs Vérifie si les dossiers insères sont exactes
Message qui indique que ce dossier est invalide
Reprendre au point 2.1
B : Dossiers incomplètes
Remplissage des champs 3.2 Vérifie les dossiers manqués
Message qui indique qu‘il y a encore des dossiers
incomplets
Reprendre au point 2.1

- Diagramme de séquence

Scénario nominal

Le Scénario nominal de cas d‘utilisation «Enregistrement dossiers» est représenté comme


indique la figure ci-dessous.

Figure 4.4.5.1 : Diagramme de séquence «Enregistrement dossiers» (sn)

72
Scénario alternatif

Le scénario alternatif de cas d‘utilisation «Enregistrement dossiers» est représenté comme


indique la figure ci-dessous.

Figure 4.4.5.2 : Diagramme de séquence «Enregistrement dossiers» (sa)

73
- Diagramme d’activité «Enregistrement dossiers»

Le diagramme d‘activité de cas d‘utilisation «Enregistrement dossiers» est représenté comme


indique la figure ci-dessous.

OK

OK

OK OK

Figure 4.4.5.3 : Diagramme d‘activité «Enregistrement dossiers»

74
- Le diagramme de classe

Le diagramme de classe de cas d‘utilisation «Enregistrement dossiers» est représenté comme


indique la figure ci-dessous.

Figure 4.4.5.4 : Diagramme de classe « Enregistrement de personnel »

75
4.4.6 Cas d’utilisation « Mise à jour dossiers et personnels »
Le tableau ci-dessous décrit le scénario nominal et alternatif du cas d‘utilisation
«Mise à jour dossiers et personnels».

- Description textuelle

Tableau 4.4.6.1 : Cas d‘utilisation «Mise à jour dossiers et personnels»

Nom du cas Mise à jour dossiers et personnels


Objectifs Mettre à jour les données enregistrées
Acteur Principal Utilisateur
Pré Condition les données ne sont pas encore supprimées dans la
base
Post Condition La mise à jour dossiers et personnels sont réussit
Date 12/01/2015
Responsable Laza
Version 1.0

- Description des scénarii

Le tableau ci-dessous représente la description des scenarii pour le cas d‘utilisation «Mise à
jour dossiers et personnels»

Scenario nominal

Tableau 4.4.6.2 : Description de scenarii nominal «Mise à jour dossiers et personnels»

Utilisateur Système
3 Cliquer sur mise à jour 3.1 Affichage du formulaire mise à jour
Saisie sur les champs à modifier Vérifie pour qu‘il n‘y à pas d‘identifiant identique
puis terminer Contrôle champs
Insertion à la base
Rapport d‘état

76
Scénario alternatif

Tableau 4.4.6.3 : Description des scenarii alternatif «Mise à jour dossiers et personnels»

Utilisateur Système
A : Champ obligatoire non rempli
Contrôle champs
Indique que les champs obligatoires non remplis
Reprendre au point 3.1
B : identifiant identique
4.4 Vérifier les identifiants dans la base
Informe que l‘identifiant est déjà existé dans la base
Reprendre au point 3.1

- Diagramme de séquence

Scénario nominal

Le Scénario nominal de cas d‘utilisation «Mise à jour dossiers et personnels» est représenté
comme indique la figure ci-dessous.

Figure 4.4.6.1 : Diagramme de séquence «Mise à jour dossiers et personnels» (sn)

77
Scénario alternatif

Le Scénario nominal de cas d‘utilisation «Mise à jour dossiers et personnels» est représenté
comme indique la figure ci-dessous.

Figure 4.4.6.2 : Diagramme de séquence «Mise à jour dossiers et personnels» (sa)

- Diagramme d’activité «Mise à jour dossiers et personnels »

Le Scénario nominal de cas d‘utilisation «Mise à jour dossiers et personnels» est représenté
comme indique la figure suivante.

78
OK

OK

OK OK

Figure 4.4.6.3 : Diagramme d‘activité «Mise à jour dossiers et personnels »

- Diagramme de classe

Le diagramme de classe de cas d‘utilisation «Mise à jour dossiers et personnels» est


représenté comme indique la figure suivante.

79
Figure 4.4.6.4 : Diagramme de classe «Mise à jour dossiers et personnels»

80
4.4.7 Cas d’utilisation «Envoie dossiers »
Le tableau ci-dessous décrit le scénario nominal et alternatif du cas d‘utilisation
« Envoie dossiers »

- Description textuelle
Tableau 4.4.7.1 : Cas d‘utilisation «Envoie dossiers»
Nom du cas Envoie dossiers
Objectifs Pour trouver les dossiers complets et envoyés
Acteur Principal Responsable
Pré Condition Les dossiers ne sont pas encore envoyés
Post Condition Afficher la liste des dossiers envoyés
Date 12/01/2015
Responsable Laza
Version 1.0

- Description des scénarii

Le tableau suivant représente la description des scenarii pour le cas d‘utilisation «Envoie
dossiers»
Scenario nominal

Tableau 4.4.7.2 : Description de scenarii nominal « Envoie dossiers»


Utilisateur Système
6 Cliquer sur dossiers envoyés Affichage du formulaire des dossiers envoyés
sélections des dates 6.4 Contrôle de saisie
6.5 validation 6.6 Enregistrement
6.7 Rapport d‘état

Scenario alternatif
Tableau 4.4.7.31 : Description de scenarii alternatif « Envoie dossiers»
Utilisateur Système
A : date invalide
6.7 Vérifie la date de début de service par rapport
à la date de dépôt des dossiers.
Informe que c‘est une durée invalide
B : Champs obligatoire non rempli
Contrôle champs
Message qui indique qu‘il y a encore des champs
obligatoires non remplis
Reprendre au point 6.1

81
- Diagramme de séquence

Scénario nominal

Le Scénario nominal de cas d‘utilisation «Envoie dossiers» est représenté comme indique la
figure ci-dessous.

Figure 4.4.7.1 : Diagramme de séquence «Envoie dossiers» (sn)

Scénario alternatif
Le Scénario nominal de cas d‘utilisation «Envoie dossiers» est représenté comme indique la
figure suivante.

Figure 4.4.7.2 : Diagramme de séquence «Envoie dossiers» (sa)

82
- Diagramme d’activité «Envoie dossiers»

Le Scénario nominal de cas d‘utilisation «Envoie dossiers» est représenté comme indique la
figure suivante.

OK

OK

OK OK

Figure 4.4.7.3 : Diagramme d‘activité «Envoie dossiers»

83
- Diagramme de classe

Le diagramme de classe de cas d‘utilisation «Envoie dossiers» est représenté comme indique
la figure suivante.

Figure 4.4.7.4 : Diagramme de classe «Envoie dossiers»

4.4.8 Cas d’utilisation « Contrôler dossiers envoyés »


Le tableau ci-dessous décrit le scénario nominal et alternatif du cas d‘utilisation
«Contrôler dossiers envoyés».

84
- Description textuelle
Tableau 4.4.8.1 : Cas d‘utilisation «Contrôler dossiers envoyés»

Nom du cas Contrôler dossiers envoyés


Objectifs Rechercher les dossiers envoyés dans la base de
données
Acteur Principal Utilisateur
Pré Condition La recherche des dossiers envoyés n‘est pas encore
effectuée.
Post Condition Effectue une recherche des dossiers envoyés
enregistrer dans la base de données
Date 12/01/2015
Responsable Laza
Version 1.0
- Description des scénarii
Le tableau suivant représente la description des scenarii pour le cas d‘utilisation « Contrôler
dossiers envoyés»

Scenario nominal
Tableau 4.4.8.2 : Description de scenarii nominal « Contrôler dossiers envoyés »
Utilisateur Système
6 Placer le curseur sur le champ 6.1 Effectue la recherche
de recherche et taper le numéro Affichage du résultat de recherche
immatricule

Scenario alternatif
Tableau 4.4.8.3 : Description des scenarii alternatif « Contrôler dossiers envoyés »
Utilisateur Système
Dossiers non trouvé
7.2 Vérifier si les dossiers sont déjà insérés dans la
base
Indique que ce dossier est non trouvé
Message d‘information

85
- Diagramme de séquence
Scénario nominal
Le scénario nominal de cas d‘utilisation «Contrôler dossiers envoyés» est représenté comme
indique la figure ci-dessous.

Figure 4.4.8.1 : Diagramme de séquence «Contrôler dossiers envoyés» (sn)

Scénario alternatif

Le Scénario alternatif de cas d‘utilisation «Contrôler dossiers envoyés» est représenté comme
indique la figure ci-dessous.

Figure 4.4.8.2 : Diagramme de séquence «Contrôler dossiers envoyés» (sa)

86
- Diagramme d’activité « Control Préparation des travaux »

Le diagramme d‘activité de cas d‘utilisation «Contrôler dossiers envoyés» est représenté


comme indique la figure ci-dessous.

OK

OK

OK OK

Figure 4.4.8.3 : Diagramme d‘activité «Contrôler dossiers envoyés»

87
- Diagramme de classe

Le diagramme de classe de cas d‘utilisation «Contrôler dossiers envoyés» est représenté


comme indique la figure suivante.

Figure 4.4.8.4 : Diagramme de classe «Contrôler dossiers envoyés»

4.5 LE DIAGRAMME DE CLASSE FINAL

Un diagramme de classes est une collection d'éléments de modélisation statiques


(classes, paquetages...), qui montre la structure d'un modèle. Un diagramme de classes fait
abstraction des aspects dynamiques et temporels. Pour un modèle complexe, plusieurs
diagrammes de classes complémentaires doivent être construits.

88
Voici se présente le diagramme de classe total :

Figure 4.5 : Diagramme de classe final

89
PARTIE III : PHASE DE REALISATION

90
Chapitre 5 : LA REALISATION

La phase finale de la conception d‘un projet informatique est la réalisation. Elle


consiste à écrire les programmes pour arriver aux traitements souhaités pour les besoins de
l‘entreprise.

Elle consiste aussi à représenter physiquement les données en utilisant un SGBD et un


logiciel d‘application pour gérer la base de données.

Elles seront aussi mettre en évidence le choix des outils et de la méthode de


développement, des SGBD, et la présentation de l‘application telle qu‘elle sera exploitée.

5.1 LA BASE DES DONNEES

5.1.1 Définition
Le cœur d‘une application est la base de données proprement dite, mémoire à terme des
informations utilisées par l‘application. C‘est une sorte de classeur informatique qui renferme
des informations structurées de telle façon qu‘il soit facile de s‘y reporter.

Base de données : désigne un fichier ou un groupe de fichiers contenant des données


réelles. Ces informations sont accessibles au moyen d‘un ensemble de programmes appelé
SGBD.

5.1.2 Caractéristique d’un SGBD


Un SGBD digne de ce nom doit disposer d‘un certain nombre de caractéristiques minimales :

 Gestion de gros volumes de données ;


 Sécurité des données ;
 Concurrence d‘accès en lecture et écriture (avec une bonne granularité) ;
 Gestion (efficace) des transactions ;
 Portabilité sur différents OS, des données et du code ;
 Administrable (existence d‘outils d‘administration généraux).

91
5.1.3 Utilité
Une base de données permet de mettre des données à la disposition d‘utilisateurs pour une
consultation, une saisie ou bien une mise à jour, tout en s‘assurant des droits accordés à ces
derniers. Une base de donne peut être locale, c'est-à-dire utilisable sur une machine par un
utilisateur, ou bien repartie, c'est-à-dire que les informations sont stockées sur des machines
distantes et accessibles par réseau.

5.1.4 Choix de SGBD pour l’application


5.1.4.1 MySQL
MySQL est un SGBDR édité par Oracle corporation. Il apporte divers avantages du fait
que :

- il est « open source » ;


- il est facile à déployer et à prendre en main ;
- il est une solution très courante en hébergement public ;
- il effectue une très bonne intégration dans l'environnement Apache/PHP ;
- une version cluster existe depuis la version 4 ;
- un ordonnanceur et un partitionnement sont intégrés depuis la version 5.1 ;
- il dispose de plusieurs moteurs de stockage configurables au niveau des tables et
adaptés aux différentes problématiques.

Il a aussi quelques inconvénients :

- il dispose de peu de richesse fonctionnelle ;


- il ne supporte pas l'héritage de tables ;
- il ne supporte qu'une faible partie des standards SQL-92 ;
- il ne supporte pas les triggers et les procédures stockées ;
- la gestion des transactions se fait, uniquement, avec les moteurs en Falcon ou
InnoDb;
- il manque de robustesse pour de fortes volumétries de données ;
- il ne dispose pas de vue matérialisée ;
- le cluster par clonage de base provoque un impact prépondérant sur la volumétrie.

92
5.1.4.2 PostgreSQL
PostgreSQL est un SGBD édité par la société PostgreSQL.
Il donne différents avantages par le fait que :
- Il est « open source » et gratuit ;
- il est facile à utiliser et à administrer ;
- il supporte l‘héritage de tables.
- il est très riche fonctionnellement et possède une multitude de modules ;
- il est fiable et relativement performant, tout en restant simple d'utilisation ;
- il supporte la majorité du standard SQL-92 et possède en plus un certain nombre
d'extensions (Java, Ruby, PL-SQL) ;

Cependant, PostgreSQL possède aussi certains inconvénients :

- la modification du fichier de sécurité pg_hba.conf nécessite un reboot pour être prise


en compte ;
- les sauvegardes ne sont pas très évoluées ;
- il ne supporte que les bases de moyenne importance ;
- il n‘offre pas de services Web ;
- il ne dispose pas ni d‘un ordonnanceur intégré ni d‘une vue matérialisée ;
- il ne supporte pas les fonctions d'agrégat OLAP et les requêtes récursives ;
- les solutions de réplication ne sont pas encore totalement packagées ;
- la solution en cluster n‘est pas encore finalisée (abandon de PgCluster, développement
en cours de PgCluster2).

5.1.4.3 Oracle
Oracle est un SGBD édité par la société du même nom Oracle Corporation, leader
mondial des bases de données.
Il offre des avantages du faite que :

- La cohérence des données


- La confidentialité des données
- L'intégrité des données
- La sauvegarde et la restauration des données
- La gestion des accès concurrents

93
Cependant, Oracle aussi possède certains inconvénients :

- Licence payante
- Complexité à la manipulation

5.1.4.4 Choix et justification


La base de donne SGBD que nous utilisons pour le développement de cette application
est PostgreSQL. Il y a plusieurs possibilités pour un système de gestion de base de données,
partant des SGBD gratuits jusqu‘aux SGBD destinés spécialement aux professionnels,
comportant de plus nombreuses fonctionnalités, mais plus couteux. Le postegrSQL représente
les avantages suivants :

 Licence BSD
- Coût nul ;
- Code source disponible ;
- Aucune contrainte de redistribution.
 Robustesse
- Sécurité des données ;
- Résistance aux bogues applicatifs.
 Souplesse, extensibilité
- Facilité de configuration de PostgreSQL ;
- Montée en puissance et en charge progressive ;
- Gestion des gros volumes de données.

Voici un tableau récapitulatif comparant PostgresSQL, MySQL et Oracle


Tableau 5.1.4.42 : Tableau comparatif de SGBD
SGBD Licence Documentation Manipulation

MySQL Gratuite plusieurs API moyenne

PostgreSQL Gratuite plusieurs API moyenne

Oracle Payante plusieurs API complexe

94
5.1.4.4.1 Historique

Depuis son origine, PostgreSQL a toujours privilégié la stabilité et le respect des


standards plutôt que les performances.

 Années 1970 : Ingres est développé à Berkeley ;


 1985 : Ingres est redéveloppé à partir de rien. Le nouveau projet est nommé
Postgres ;
 1995 : Ajout du langage SQL. Postgres est renommé en Postgres95 ;
 1996 : Postgres95 devient PostgreSQL ;
 1996 : Création du PostgreSQL Global Développement Group.

L‘histoire de PostgreSQL remonte à la base de données Ingres, développée à Berkeley


par Michael Stonebraker. Lorsque ce dernier décida en 1985 de recommencer le
développement de zéro, il nomma le logiciel Postgres, comme raccourci de post-Ingres. Lors
de l‘ajout des fonctionnalités SQL en 1995 par deux étudiants chinois de Berkeley, Postgres
fut renommé Postgres95. Ce nom fut changé à la fin de 1996 en PostgreSQL.
De longs débats en flammés animent toujours la communauté pour savoir s‘il faut revenir au
nom initial Postgres. À l‘heure actuelle, le nom Postgres est accepté comme un alias du nom
officiel PostgreSQL. [3]

5.1.4.4.2 Fonctionnalité

MVCC (Multi Version Concurrency Control) est le mécanisme interne de PostgreSQL


utilisé pour garantir la consistance des données lorsque plusieurs processus accèdent à la
même table. C‘est la qualité de l‘implémentation de ce système qui fait de PostgreSQL un des
meilleurs SGBD au monde. Voici donc la fonctionnalité de la PostegreSQL :

 Standard SQL ;
 Respect complet d‘ACID ;
 MVCC (supérieur au verrou de lignes) ;
 Intégrité référentielle (clés étrangères) ;
 Index fonctionnels et partiels.

95
5.2 LE LANGAGE DE PROGRAMMATION

5.2.1 Choix des technologies


Une page web est composée d‘un langage dont il a son fonctionnalité particulière par
rapport aux autres langages. C‘est pour cela que nous allons décrire et comparer les trois
langages qui sont les plus utilisés pour le développement des pages Web dynamiques : ASP,
PHP et JSP.

5.2.1.1 Langage coté serveur


5.2.1.1.1 PHP (Personal Home Pages)

PHP est aussi un langage interprété côté serveur, sa syntaxe simple (héritée du C et de
PERL), ses fonctions particulièrement adaptées aux applications Web et la documentation
permettent une grande productivité et une rapidité au niveau du développement. PHP est riche
car il dispose d'un grand nombre d'extensions qui lui permettent de couvrir l'essentiel des
besoins relatifs aux applications Web. PHP permet aussi de réutiliser librement des
applications telles que les interfaces de gestion de base de données, des interfaces mail, etc.
PHP s‘allie surtout avec les Open Source ; avec LINUX comme système d‘exploitation,
APACHE comme serveur Web, MySQL comme base de données, le tout forme une entité très
puissante pour un site assez moyen. [4]

5.2.1.1.2 ASP (Active Server Page)

ASP se présente comme un environnement d'interprétation de script côté serveur, il


peut utiliser des langages de script Web tels que Microsoft JScript, Microsoft VBScript de
Visual Basic ou des langages de script compatible COM (Component Object Model),
notamment JavaScript ou PERL. Sa rapidité de développement, sa simplicité, sa facilité
d‘intégration en environnement Microsoft lui vaut sa réputation depuis sa création en 1996.

L‘inconvénient majeur d‘ASP est qu‘il est une technologie Microsoft, seuls les
serveurs Web Microsoft IIS (Internet Information Server) sous Microsoft Windows NT
Server et PWS (Personal Web Server) sous Windows 95 / 98 supportent ASP, une nécessité à
acheter les licences n‘est pas à exclure pour le système d‘exploitation Microsoft bien que
l‘application serveur soit gratuite. [5]
96
5.2.1.1.3 CGI (Common Gateway Interface)

Les premiers serveurs HTTP ne comportaient pas de programmes pour générer des
réponses de façon dynamiques. Des interfaces étaient utilisées pour appeler d'autres
programmes capables de traduire les requêtes en un contenu exécutable. Le premier standard
utilisé a été CGI, c'est une norme qui définit un mécanisme qui permet au serveur HTTP de
transmettre les informations d'une requête à des programmes externes.

Le langage Perl est le langage le plus utilisé pour écrire des scripts CGI, mais on peut écrire
des langages scripts dans bien d'autres langages.
L'inconvénient de ces scripts est qu'ils sont très gourmand en ressources systèmes. Chaque
scripts utilisent un processus différent ce qui demande beaucoup de mémoire et d'utilisation
processeur. [6]

5.2.1.1.4 JSP (Java Server Page)

JSP est une technologie de script exécuté du côté serveur (mieux pour la
sécurité), il est basé sur le langage de programmation Java. Héritant des avantages de Java,
JSP profite de tout ce qu'offre ce langage pour le développement et le déploiement
d'applications. En effet Java est un langage orienté objet fortement typé, permettant
l'encapsulation, le traitement des exceptions et la gestion automatique de la mémoire. JSP est
aussi multiplateforme, si le script marche sur un système d‘exploitation, il fonctionnera
toujours sur un autre type de système ayant le support adéquat. Toutes les applications Web
réalisées en JSP bénéficieront alors de tous ces avantages. [7]

5.2.1.2 Choix et justification

Du fait que la technologie Java fournit de multiples avantages, on a choisi de développer


une application web basée sur le langage JSP (Java Server Page).

JSP est un langage de script (ou langage interprété) exécuté du côté serveur. Il est utilisé
pour la réalisation d‘application web dynamiques très puissants .C‘est un langage complet, il
permet ainsi de réaliser d‘autres applications serveur tourner sous web grâce à :

- La simplicité d‘écriture de scripts,


- La possibilité de gérer l‘objet,
- La simplicité d‘interfaçage avec des bases de données,
97
- La portabilité sur différentes plateformes,
- L‘intégration au sein de nombreux serveurs web,
- La richesse fonctionnelle : JSP comporte plus de 1200 fonctions, parmi lesquelles
les fonctions d‘images, les protocoles internet, etc…,
- La grande évolutivité par l‘intégration continuelle de nouvelles fonctionnalités à
travers les mises à jour successives.

Essayons de rassembler ces critères de comparaison dans un tableau, avec une échelle allant
de faible à élever de oui ou non:

Tableau 5.2.1.2 : Comparaison de ces quarte langages


LANGAGE ASP CGI PHP JSP

Puissance moyen moyen moyen Elevé

Complexité Faible Faible moyen moyen

Portabilité faible faible Elevé Elevé

Ressources peu peu énorme énorme

Architecture
Non Oui Oui Oui
neutre

Sécurité Non Non Oui Oui

Multithread Non Oui Oui Oui

5.2.1.3 Langage coté client

JSP peut être combiné avec d‘autres langages de script pour la facilité de
développement et de l‘interaction du fonctionnement de l‘application web.

5.2.1.3.1 Le langage HTML (HyperText MarkupLanguage)

Le HTML n'est pas un langage de programmation mais c‘est un langage à balises, c'est
un simple fichier texte contenant des balises permettant de mettre en forme le texte, les
images, etc... Le HTML est un système qui formalise l'écriture d'un document avec des balises

98
de formatage indiquant la façon dont doivent être présentés le document et les liens qu'il
établit avec d'autres documents.

5.2.1.3.2 Le langage CSS (Cascading Style Sheets)

Le principe des feuilles de style consiste à regrouper dans un même document des
caractéristiques de mise en forme associées à des groupes d'éléments. Il suffit de définir par
un nom un ensemble de définitions et de caractéristiques de mise en forme, et de l'appeler
pour l'appliquer à un texte. Il est ainsi possible de créer un groupe de titres en police Arial, de
couleur verte et en italique.

Les feuilles de style ont été mises au point afin de compenser les manques du HTML
ce qui concerne la mise en page et la présentation. En effet, le HTML offre un certain nombre
de balises permettant de mettre en page et de définir le style d'un texte, toutefois chaque
élément possède son propre style, indépendamment des éléments qui l'entourent. Grâce aux
feuilles de style, lorsque la charte graphique d'un site composé de plusieurs centaines de pages
web doit être changée, il suffit de modifier la définition des feuilles de style en un seul endroit
pour changer l'apparence du site tout entier. [8]

Elles sont appelées « feuilles de style en cascade » car il est possible d'en définir
plusieurs et que les styles peuvent être hérités en cascade.

Les feuilles de style permettent notamment :

- d'obtenir une présentation homogène sur tout un site en faisant appel sur toutes les
pages à une même définition de style ;
- de permettre le changement de l'aspect d'un site complet entier par la seule
modification de quelques lignes ;
- une plus grande lisibilité du HTML, car les styles sont définis à part ;
- des chargements de page plus rapides;
- un positionnement plus rigoureux des éléments.

99
5.2.1.3.3 Javascript

Le Javascript est un langage de script incorporé dans un document HTML.


C‘est un langage de programmation qui permet d'apporter des améliorations au langage
HTML en permettant d'exécuter des commandes du côté client, c'est-à-dire au niveau du
navigateur et non du serveur web. Ainsi le langage Javascript est fortement dépendant du
navigateur.
Le code Javascript est intégré complètement dans le code HTML, et interprété par le
navigateur client. Le Javascript est un langage de programmation structurée qui concourt à
enrichir le HTML, à le rendre plus intelligent et interactif. C'est un langage de script,
dépendant de HTML. Le Javascript est donc une extension de HTML. [9]

5.2.1.3.4 Technologie AJAX (Asynchronous JavaScript and XML)

AJAX est basé sur les standards web JavaScript, XML, HTML et CSS. Il utilise le
PHP ou autre langage de script, et peut être fonctionnel du coté serveur .Il permet de modifier
partiellement la page affichée par le navigateur pour la mettre à jour sans avoir à recharger la
page entière.
Traditionnellement, pour obtenir des informations stockées sur le serveur, on a recours
aux méthodes GET ou POST et la réponse du serveur est obtenue toujours sous la forme
d‘une nouvelle page. Ce chargement de page à chaque réponse ralentit considérablement le
fonctionnement de l‘application. Grâce à AJAX, JavaScript peut communiquer directement
avec le serveur à travers l'objet XMLHttpRequest.
Ainsi, une page web peut effectuer une requête HTTP et obtenir une réponse du
serveur sans rechargement de la page entière. Le navigateur du client n'est pas nécessairement
rafraîchi et tout est transparent pour l'utilisateur. [10]

5.2.1.3.5 JQuery

JQuery est un framework JavaScript libre et Open Source, implanté côté client, qui
porte sur l‘interaction entre le DOM, JavaScript, AJAX et le Html. Cette librairie JavaScript a
pour but de simplifier les commandes communes du JavaScript. La bibliothèque jQuery
fournit une couche d‘abstraction générique pour les scripts web. Elle est donc utile pour la
plupart des développements de scripts. Toutefois, les fonctionnalités standard permettent de
répondre aux besoins suivants :

100
- Accéder aux éléments d’un document. Sans l‘aide d‘une bibliothèque
JavaScript, il faut écrire de nombreuses lignes de code pour parcourir
l‘arborescence du DOM (Document Object Model) et localiser des parties
spécifiques de la structure d‘un document HTML. jQuery fournit un mécanisme
de sélection robuste et efficace qui permet de retrouver n‘importe quels éléments
d‘un document afin de les examiner ou de les manipuler.
- Modifier l’aspect d’une page web. CSS propose une solution puissante pour
modifier le rendu des documents, mais elle montre ses limites lorsque les
navigateurs web ne respectent pas les mêmes standards. Avec jQuery, les
développeurs peuvent contourner ce problème en se fondant sur une prise en
charge identique des standards quels que soient les navigateurs. Par ailleurs, la
bibliothèque permet de modifier les classes ou les propriétés de style appliquées à
une partie du document, même après que la page a été affichée.
- Altérer le contenu d’un document. jQuery ne se borne pas à des changements
cosmétiques mais permet de modifier le contenu du document. Du texte peut être
changé, des images peuvent être insérées ou interverties, des listes être
réordonnées, l‘intégralité de la structure du contenu HTML peut être revue et
étendue. Toutes ces possibilités sont permises par une API (Application
Programming Interface) simple d‘emploi.
- Répondre aux actions de l’utilisateur. Même les comportements les plus
élaborés et les plus puissants ne sont d‘aucune utilité si leur exécution n‘est pas
contrôlée. La bibliothèque jQuery propose une solution élégante pour intercepter
une grande variété d‘événements, comme un clic sur un lien, sans avoir à mélanger
des gestionnaires d‘événements au code HTML. De plus, cette API de gestion des
événements permet de passer outre les incohérences des navigateurs, qui
constituent une véritable nuisance pour les développeurs web.
- Animer les modifications d’un document. Pour la bonne mise en œuvre des
comportements interactifs, le concepteur doit également fournir un retour visuel à
l‘utilisateur. La bibliothèque jQuery apporte son aide en proposant des animations,
comme les effets de fondu et de volet, ainsi qu‘une boîte à outils pour en
construire de nouvelles.[11]

101
5.2.1.4 Fonctionnement du JSP

JSP présente de nombreux avantages par rapport aux autres langages de génération de
contenu. Comme il s'agit d'une technologie basée sur Java, JSP profite de tous ce qu'offre ce
langage pour le développement et le déploiement d'applications. En effet Java est un langage
orienté objet fortement typé, permettant l'encapsulation, le traitement des exceptions et la
gestion automatique de la mémoire.

D'autre part, grâce aux API normalisées pour les JSP et à la portabilité du byte code compilé
Java, on n'est pas limité à un seul type de plate-forme, de système d'exploitation. On peut
changer les composants d'une page JSP comme on le souhaite.
De plus, JSP utilise l'ensemble de la plateforme JAVA sous-jacente ; par conséquent, les JSP
peuvent directement tirer avantage de toutes les API Java.

JSP n'est pas rattaché à un éditeur particulier, les développeurs peuvent donc choisir les
solutions de leurs choix.

Lorsque la page est demandée par un utilisateur en HTTP, alors le serveur web HTTP va
transmettre sa requête à un moteur de JSP qui va interpréter le page, compiler le code et
générer la réponse. L'utilisateur ne verra aucune ligne de code Java dans les sources de la
page qu'il aura reçu.

5.3 LA METHODOLOGIE DE DEVELOPPEMENT D’UNE


APPLICATION WEB

Le modèle MVC (Modèle-Vue-Contrôleur) consiste à séparer clairement les couches


présentation, traitement et accès aux données. L‘application réalisée respecte le modèle MVC
qui est reconnu sous le nom « architecture à trois couches » telles que la couche présentation,
la couche métier et la couche donnée. La couche présentation

La couche présentation affiche les données. Elle envoie les demandes de l‘utilisateur à la
couche métier pour que ce dernier les traite. Et elle reçoit les résultats renvoyés par la couche
métier et les affiche.

102
5.3.1 La couche métier
Cette couche renferme la logique de l‘application : Elle reçoit et analyse les demandes de
l‘utilisateur, elle retrouve et modifie les données via la couche données et elle renvoie les
résultats à la couche présentation

5.3.2 La couche de donnée


Cette couche se charge la modification et la récupération des données. Et elle assure la
sécurité et l‘intégrité des données.

5.4 LES OUTILS COMPLEMENTAIRES

5.4.1 Apache Tomcat

Le projet Tomcat a été lancé comme implémentation de référence par James Duncan
Davidson architecte logiciel chez Sun. Il a contribué à rendre le projet libre et a joué un rôle
majeur dans sa donation par Sun à la fondation Apache. Davidson aspirait dès le départ à
rendre le projet libre. Comme la plupart des projets libres sont associés à un livre O‘Reilly
avec un animal en couverture, il a souhaité donner un nom d'animal au projet. Il a choisi le
nom Tomcat (litt.matou) car cet animal représentait quelque chose qui peut prendre soin de
lui-même. Son souhait de voir une couverture d'animal s'est finalement concrétisé lorsque
O'Reilly a publié un livre sur Tomcat avec un félin en couverture.

Apache Tomcat est un conteneur libre de servletJava 2 Entreprise Edition. Issu du


projet Jakarta, Tomcat est un projet principal de la fondation Apache. Tomcat implémente les
spécifications des servlets et des JSP du Java CommunityProcess. Il est paramétrable par des
fichiers XML et de propriétés, et inclut des outils pour la configuration et la gestion. Il
comporte également un serveur HTTP. Tomcat est un serveur Web qui gère les servlets et les
JSP. C'est le compilateur Jasper qui compile les pages JSP pour en faire des servlets. Le
moteur de servlet Tomcat est souvent employé en combinaison avec un serveur Web Apache
ou d'autres serveurs Web. Tomcat a été écrit en langage Java. Il peut donc s'exécuter via la
machine virtuelle Java sur n'importe quel système d'exploitation la supportant.

103
5.4.2 Principe de fonctionnement

Tomcat est souvent utilisé en association avec un autre serveur web, en général
Apache. Apache s'occupe de toutes les pages web traditionnelles, et Tomcat uniquement des
pages d'une application web Java. On peut utiliser le module mod jk pour paramétrer la
communication entre Apache et Tomcat. Techniquement, Apache communique avec Tomcat
sur le port 8009 (via le protocole ajp13), mais Tomcat peut aussi être atteint via son propre
port (8080 par défaut).

L'installation par défaut de Tomcat comprend les répertoires suivants :

- bin : Scripts et exécutables pour différentes tâches : démarrage (startup), arrêt, etc. ;
- common : Classes communes que Catalina et les applications Web utilisent ;
- conf : Fichiers de configuration au format XML et les DTD que ces fichiers XML
utilisent ;
- logs : Journaux des applications Web et de Catalina ;
- server : Classes utilisées seulement par Catalina ;
- shared : Classes partagées par toutes les applications Web ;
- webapps : Répertoire contenant les applications web (et les éventuels .war);
- work : Fichiers et répertoires temporaires (le cache).

5.4.3 Java Development Kit (JDK)

Le Java Development Kit (JDK) est l'environnement dans lequel le code Java est
compilé pour être transformé en bytecode afin que la machine virtuelle Java (JVM) puisse
l'interpréter. Les composants primaires du JDK sont une sélection d'outils de programmation,
incluant :

- javac – le compilateur, qui convertit le code source en fichier .class (contenant le


bytecode Java) ;
- jar – l'archiveur, qui met sous forme d'un paquetage unique l'ensemble des fichiers
class en un fichier JAR ;
- javadoc– le générateur de documentation, qui génère automatiquement de la
documentation à partir des commentaires du code source ;
- jdb – le débogueur.

104
L'environnement d‘exécution Java fait également partie du JDK.

Le Java Development Kit, communément appelé JDK, est le kit de développement de base
que propose gratuitement la firme Sun Microsystem. Le Kit de développement comprend
plusieurs outils, parmi lesquels :
- java: un interpréteur d'applications (machine virtuelle) ;
- applet viewer: un interpréteur d'applets ;
- javap: un décompilateur, pour revenir du bytecode au code source ;
- jar: un compresseur de classes Java ;

5.4.4 Le compilateur
javac est un compilateur, c'est-à-dire qu'il transforme le code source en bytecode, un
fichier binaire intermédiaire interprétable par la machine virtuelle sur n'importe quelle plate-
forme. javac s'utilise avec la syntaxe suivante :
javac -g nom_du_fichier.java
L'option -g permet tout simplement d'inclure dans le pseudo-code des informations de
débogage afin de pouvoir utiliser le débogueur jdb.

5.4.5 L'interpréteur
L'interpréteur java est une machine virtuelle fonctionnant en mode texte, c'est-à-dire
sans interface graphique. Sa syntaxe est la suivante : javanom_du_fichier.

5.5 IMPLEMENTATION DE L’APPLICATION

5.5.1 Configuration minimale requise pour le serveur

Le tableau suivant définit la configuration minimale requise pour le serveur.


Tableau 5.5.1 : Configuration minimale pour le serveur
Disque Dur 40 Go
Mémoire vive 512 Mo
Processeur Pentium 4 de fréquence 1,8Ghz

105
5.5.2 Configuration minimale requise pour le client
Concernant les postes clients (les utilisateurs), la configuration requise est
présentée dans le tableau 5.5.2 suivant :

Tableau 5.5.2 : Configuration minimale requise pour les clients


Disque Dur 20 Go
Mémoire vive 256 Mo
Processeur Pentium 4 de fréquence 1,8Ghz

5.5.3 Architecture du système

Le système utilise selon l‘architecture à trois niveaux.


Dans l‘architecture à trois niveaux (appelée architecture 3-tiers), il existe un niveau
intermédiaire, c‘est-à-dire que l‘on a généralement une architecture partagée entre :
- Le client : le demandeur de ressources ;
- Le serveur d‘application : le serveur chargé de fournir les ressources mais faisant
appel à un autre serveur ;
- Le serveur secondaire (généralement un serveur de base de données), fournissant des
services au premier serveur.
La figure 5.5.3 ci-après représente l‘architecture du système :

Figure 5.5.3 : Architecture du système

106
5.5.4 Architecture
5.5.4.1 Architecture logicielle
JSP est un programme Java s'exécutant côté serveur Web. C‘est un programme source
Java embarqué dans une page HTML ce qui le différencie du Servlet. Le Servlet est un
programme "autonome" stocké dans un fichier «. Class » sur le serveur. Servlet et JSP
peuvent s‘exécuter sur tous les serveurs Web (Apache, IIS, ...) auxquels un "moteur" de
servlet/JSP est ajouté, le plus connu est Tomcat. JSP est compilé automatiquement en servlet
par le moteur.

Figure 5.5.4.1 : « Architecture logicielle »

1- L‘utilisateur exécute une requête à partir de son navigateur ;


2- Tomcat qui tourne avec le serveur Apache ou IIS reçoit la requête et reconnaît le
fichier qui contient le programme JSP d‘extension «.jsp ».
Remarque : Tomcat peut être indépendant du Serveur Apache ou IIS (Internet
Information Server) ;

3- Le ficher «.jsp » va être transformé en Servlet puis il sera compilé par la machine
virtuelle Java JVM (Java Virtual Machine) pour avoir un fichier « .class » ;
4- Après compilation, le Servlet renverra un fichier HTML qui sera interprété par le
navigateur de L‘utilisateur. [12]

107
5.5.4.2 Architecture matérielle

L‘architecture matérielle de l‘application à concevoir est représentée par la figure suivante.

Figure 5.5.4.2 2: Architecture Matérielle


L‘utilisateur s‘authentifie pour y accéder puis demande l‘affichage d‘une page au serveur web
(soit en cliquant sur le lien ou en valident un formulaire après avoir rempli). Le serveur reçoit
la demande et va charger la page. Deux choix s‘imposent :

 La page est totalement au format HTML (ne nécessite pas une interprétation serveur),
elle sera retournée à l‘utilisateur qui l‘apercevra.
 La page est dans un format «. jsp » :
- Le serveur envoie la page à un interpréteur qui va exécuter les commandes
inscrites dans les scripts de la page.
- Après compilation, la page est totalement en HTML, elle sera retournée à
l‘utilisateur qui l‘apercevra.

108
5.6 OUTILS DE DEVELOPPEMENT

5.6.1 NetBeans (Version 7.3)

NetBeans est un IDE (Integrated Development Environment ou Environnement de


Développement Intégré) conçu pour développer, déboguer, déployer et gérer des applications
comme PHP, Java, JSP, C, C++ et des nombreux autres langages de programmation.
NetBeans est fourni avec des mises à niveaux mineures gratuites. Il envoie plusieurs mises à
jour de produit chaque année avec des nouvelles fonctionnalités. NetBeans est une plateforme
ouverte comptant plus de 3 millions d‘utilisateurs. Grâce à NetBeans les programmeurs ont
accès à plus de 1000 plugins et de profiter de systèmes de contrôle de configuration source et
de gestion de projet. Par ailleurs, NetBeans prend en charge plusieurs langages de
programmation, cela signifie que les utilisateurs utilisant Java et PHP peuvent utiliser
facilement NetBeans comme environnement de développement.

Donc, la totalité de l‘application a été programmée sur NetBeans, car il nous offre des
nombreuses fonctionnalités, une palette d‘outils complète et performante et un système de
gestion des applications ou des applets efficace. NetBeans combine l‘éditeur de code et
l‘éditeur de mise en page ce qui permet un travail plus rapide et plus productif.

5.6.2 Macromedia Dreamweaver (Version 8)

Dreamweaver est un outil à multiples facettes qui permet d‘intervenir sur chacun des
langages qui composent le web. Il est très simple et très souple de pouvoir modifier ou
composer l‘ensemble des documents d‘un site grâce à Dreamweaver CS5.

Macromedia Dreamweaver est un éditeur HTML professionnel destiné à la


conception, au codage et au développement de sites, de pages et d‘applications Web. Quel que
soit l‘environnement de travail utilisé (codage manuel HTML ou environnement d‘édition
visuel), Dreamweaver propose des outils qui nous aideront à créer notre application Web.

Dreamweaver 8 nous aide à organiser et à gérer nos fichiers. Il comprend une série de
fonctions permettant de gérer et de transférer des fichiers depuis et vers un serveur distant.
Lorsqu‘on transfère des fichiers entre le site local et le site distant, Dreamweaver conserve la
même structure de fichiers et de dossiers sur les deux sites.

109
Dreamweaver crée automatiquement les dossiers nécessaires s'ils n'existent pas déjà
sur le site de destination.

On peut également synchroniser les fichiers entre le site local et le site distant. Dans ce
cas, il copie les fichiers requis dans les deux sens et supprime, le cas échéant, les fichiers
inutiles.

On peut utiliser la fonction de rapports sur le déroulement du travail afin de générer


des rapports sur notre site et obtenir ainsi des informations sur l'état des archivages et des
extractions ou rechercher les Design Notes jointes aux fichiers.

C‘est pour ces multiples avantages que nous avons décidé de choisir cet outil pour
réaliser notre projet.

110
Chapitre 6 : METRIQUE DE L’APPLICATION

La métrique d‘une application est la représentation de toutes les caractéristiques de


l‘application comme le nombre de fichier, le nombre des classes, le nombre de lignes de
codes…etc. La métrique de cette application est représentée par le tableau ci-dessous.

Remarque : Les données du tableau ne sont pas représentées de manières exhaustives


car le système est en perpétuelle évolution.

Tableau 6.1 : Métrique de l'application

Métrique Totale Librairie Généré Développé

Fichiers 109 6 8 95

Lignes de codes 28905 5 400 28500

Commentaire 15% 0 0 15%

Classe 52 2 30 20

Interfaces 10 0 0 10

Copie/Coller 15% 3 0 15%

6.1 Généralité sur LE COCOMO


COCOMO est un modèle qui permet d'estimer le coût, l'effort et le temps nécessaire au
développement d‘un logiciel. Le modèle original de COCOMO a été édité la première fois par
le Dr. Barry Boehm en 1981 et a reflété les pratiques en matière de développement de logiciel
de cette époque. Durant les 15 années suivantes les techniques de développement de logiciel
ont changé.
Ces changements ont inclus :
 Une disparition des traitements la nuit pour laisser la place à des traitements en
temps réel sur les postes client ou sur les serveurs.
 La réutilisation ou l‘acquisition d‘objets.
 Des efforts pour la conception des applications.
 L‘apparition des ateliers de génie logiciel très performants.

111
Ces changements ont commencé à faire apparaître des problèmes dans le modèle
original de COCOMO. La solution était de réinventer le modèle pour les années 90.
COCOMO II est né après plusieurs années d‘efforts combinés d'USC (Université de
Californie du sud), d'IRUS- UC, et des organismes partenaires.
Ce nouveau modèle prend en compte les évolutions des techniques de développement
survenues depuis les années 70. Il est aussi prêt pour les évolutions futures.
La méthode COCOMO se base sur une approche algorithmique pour déterminer « l‘effort »
et le « temps de développement » d‘une application.
Elle ne prend pas en compte les activités concernant les phases ne faisant pas partie du cycle
de développement :
 Les études de faisabilité ;
 La spécification des besoins techniques ;
 La validation opérationnelle chez le client ;
 L‘exploitation ;
 La maintenance.
Son principe est basé sur le nombre de lignes de code en Kilo. Sont prises en compte :
 Les instructions et les déclarations de format ou de données effectivement produites
concernant uniquement le logiciel fournit au client ;
 Les commandes des différentes procédures. [13]

6.2 Application du COCOMO dans ce présent projet


Dans ce projet, nous avons à peu près dégagé le premier modèle ou le modèle de base.
Mais en premier lieu nous présenterons les nombres de lignes (en KLS ou Kilo Ligne Source)
de code suivant la complexité :
Notre projet comporte à peu près 30 000 lignes de code (30 KLS) dont chaque ligne de code
coute à 400 ariary, ce qui donne au total 12 000 000 ariary.

112
6.3 Qualification du projet
Pour qualifier notre application, il faut vérifier toutes les caractéristiques qui
déterminent la qualité d‘un logiciel, il y a plusieurs caractéristiques qui déterminent cette
qualité de logiciel, mais nous avons ici les dix qui sont les plus importantes, on a :

 Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies
par le cahier des charges et les spécifications ;
 Fiabilité (ou robustesse) : aptitude d'un produit logiciel à fonctionner dans des
conditions anormales ;
 Extensibilité : facilité avec laquelle un logiciel se prête à une modification ou à une
extension des fonctions qui lui sont demandées ;
 Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de
nouvelles applications ;
 Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres
logiciels ;
 Efficacité : Utilisation optimales des ressources matérielles ;
 Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents
environnements matériels et logiciels ;
 Vérifiabilité : facilité de préparation des procédures de test ;
 Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès
non autorisés ;
 Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données,
d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.

Bref, COCOMO, grâce à son principe de conception, permet d‘estimer correctement le


coût et le temps de développement nécessaire des nouveaux projets. La difficulté réside dans
l‘estimation des différents CostDrivers et du nombre de lignes de code. Ces estimations ne
peuvent se faire que par des personnes ayant une bonne expérience du développement et une
bonne maîtrise du domaine d‘application du logiciel.

113
Chapitre 7 : MISE EN ŒUVRE

7.1 Mise en place de l’application


Pour mettre en place cette application, l‘installation des divers pilotes sont nécessaires et ainsi
la base de donnée :

- Installation du JDK ;
- Installation du logiciel postegreSQL en utilisant le manuel d‘installation ;
- Copie de tous les dossiers contenant les fichiers l‘application ;
- Importation du fichier « .sql » en utilisant le manuel d‘utilisation de l‘application.

7.2 Lancement de l’application


Pour lancer l‘application, il suffit de :

- Cliquer 2 fois sur le fichier « .war » pour le lancement ;


- Un formulaire d‘authentification serait disponible ;
- Une fois où l‘authentification est réussie, le formulaire d‘accueil serait disponible et
près à utiliser.

7.3Fonctionnalité de l’application

En général, notre application utilise 9 menus pour la gestion.


La répartition de 4 de ces menus est comme suit :
- « Authentification » pour assurer la sécurité, l‘application est protégée par une
authentification à son ouverture ;
- « Accueil » : cet onglet est spécial pour l‘utilisateur de l‘application. Tous les menus
sont disponibles et prêts à utiliser ;
- « Recherche avancée » : cette menu est spécial pour l‘utilisateur de l‘application
puisse rechercher à partir d‘une date ;
- « Aide » : cet onglet contenant le manuel d‘utilisation de cette application.

114
7.4 Les Menu de l’application
- Le menu personnels, dossiers et responsables
Dans chaque menu, on a la possibilité de faire l‘insertion, puis après enregistrement on
aperçue les listes et dans laquelle on peut les mettre à jour, l‘imprimer et supprimer des
données.
- Le menu rapport
On peut donc contrôler les rapports des dossiers envoyé. Lister et imprimer tous les dossiers
envoyés.
- Menu recherche avancé
On peut faire une recherche à partir d‘une date, des dossiers.
- Statistique
Chaque statistique est présentée par une fourchette de date de chaque année. Chaque tableau
sera représenté graphiquement sous forme de diagramme.
Voici la liste des différentes statistiques à générer :
 Concernant le taux de retraite limite d‘âge chaque année ;
 Concernant le taux de retraite anticipé chaque année ;
- Authentification

Pour assurer sa sécurité, l‘application est protégée par une authentification à son ouverture.
Paramétrage :

 Les utilisateurs sont catégorisés selon les services exerçant sur l‘application. Leurs
droits sont modifiables selon le choix de l‘administrateur ;
 L‘utilisateur admet le droit d‘autoriser, de modifier ou de supprimer un droit d‘un
autre utilisateur ;
 La suppression d‘une entité est validée par une fenêtre de confirmation ;
 L‘utilisateur doit d‘abord entrer son login et son mot de passe avant d‘utiliser le
logiciel ;
Cet écran permet aux utilisateurs de cette application d‘introduire le login et son mot de passe.

115
Chapitre 8 : DEROULEMENT DE REALISATION DU SYSTEME

8.1 Déroulement du projet


Notre projet s‘est déroulé le mois de novembre 2014 jusqu‘au mois Mars 2015. Nous
avons fait une sorte de rapprochement envers l‘encadreur le plus souvent afin d‘évaluer et de
vérifier l‘avancement du projet ainsi que de corriger les erreurs éventuelles.

8.2 Planifications du projet (ou planning)


Le tableau suivant montre les temps et les activités qui se coulent durant la
réalisation de ce projet.

Tableau 8.2 : Planning du projet

Semaine 1 Semaine 2 Semaine 3 Semaine 4

Création de la base de données.


Novembre Etude de l‘existant et analyse des
Modification de la base de données
2014 besoins

Développement de Modification et
Décembre l ‗authentification décoration de
Création des divers formulaires
2014 des administrateurs l‘interface

Janvier
Codage sur les divers formulaires
2015

Test final et
Test de chaque modification du code
Février Codage sur les divers formulaires
partie en fonction des
2015
problèmes rencontrés

Présentation finale
Mars
au service
2014
[14]
116
Quelque part de certaines tâches que nous avons effectué occupe plus de temps que
prévu comme la modélisation et l‘analyse du problème ainsi que la programmation des
interfaces.

8.3 Création et implémentation des bases de données

8.3.1 Création de la base de données

Comme ce que le tableau précédemment a démontré, nous avons créé la base dans la
troisième et quatrième semaine (Après l‘étude de l‘existant et l‘analyse des besoins). La
première chose que nous avons fait c‘est de déterminer tous les entités, puis nous avons fait
les liaisons sur les différentes entités qui se correspondent.

8.3.2 Implémentation de la base de données

Chaque modèle crée était exporté en script de création SQL avec Visual Paradigm. Un
fichier au format SQL contenant les requêtes de création des tables d‘une base de données est
généré par l‘outil. Il ne reste plus qu‘à exécuter ce fichier dans l‘interface d‘administrateur
pgAdmin de PostgreSQL.

Lors de l‘exécution du script, tous les objets du modèle (les entités, associations)
étaient créés sans aucun problème ; les clés primaires et clés étrangères étaient toutes
présentes. Le script généré par Visual Paradigm convenait à PostgreSQL. Ce qui fait
l‘avantage de Visual Paradigm par rapport aux autres outils de création de base de données.

117
8.3.3 Création des requêtes

Les requêtes SQL permettent d‘accomplir une action sur les bases de données comme
la sélection d‘informations, la création de tables, l‘ajout, la suppression et la modification des
informations.

Par exemple : Requêtes SQL permettant d‘insérer et supprimer un enregistrement dans la base
de données.

INSERT INTO etudiant VALUES (1, ‗Pierre‘,‘Michelle‘)

DELETE FROM CLIENT WHERE Nom = ‗RAKOTO‘ AND Prenom = ‗Jean‘

8.3.4 Création des fonctions

Les fonctions sont la base d‘une programmation claire et efficace. Une sorte de
sous-programme isolé du reste du code. Elle peut être exécutée à tout moment, depuis
n‘importe quelle partie du code principal ou n‘importe quelle autre fonctions, par simple
appel et en incluant le nom de fichier contenant la fonction. Le principal avantage des
fonctions est le non répétition de la même séquence de code. L‘utilisation des fonctions
permet ainsi le gain de productivité, la meilleure lisibilité du code, et une maintenance facile.

Exemple : « Fonction de connexion à une base de données ». Cette fonction appelle en


arguments le nom de la machine hôte où se trouve le serveur, le nom de l‘utilisateur autorisé
et le mot de passe de cet utilisateur.

8.4 Conception de l’IHM

8.4.1 Création de menus et interfaces

La partie visuelle de l‘application est l‘intermédiaire entre l‘utilisateur et la base de


données. C‘est la partie immédiatement visible pour l‘utilisateur et elle mérite une attention.

Il doit être facile à comprendre et facile à utiliser alors une forme générale a été
adoptée pour tous les formulaires. Cette forme sera divisée en trois parties : L‘entête et le pied
de page, les rubriques et le contenu de la page.

118
L‘entête de page sera constitué d‘une bannière avec le logo du service et les différents
pavés dépendant du contenu du site, l‘identification du site sera inscrite en haut de la page.
Les rubriques seront placées sur la partie gauche et droite de la page tandis que le contenu
sera au milieu.

Figure 8.4.1 : Forme générale des pages

8.4.2 Fonctionnalités

La fonctionnalité de base de toute IHM est de permettre une interaction entre les
utilisateurs de l‘application et le système interactif. La population visée par cette application
est large et son niveau présupposé en informatique est basique.

Il est donc primordial de concevoir une interface :

 Agréable esthétiquement ;
 De prise en main rapide ;
 Intuitive ;
 A l‘ergonomie classique c‘est à dire non déroutante.
De même, il est absolument inenvisageable de considérer une IHM qui ne permettrait
pas le contrôle total de l‘application : données, paramètres,…etc.

119
8.4.2 Quelques captures d’interface

Les figures suivantes représentent le choix que nous avons adopté pour les formulaires
pour la mise en place des éléments de contrôle de notre IHM.

Le menu vertical à gauche permet de contrôler les personnels et ses dossiers et ainsi le
menu horizontal en haut pour les besoins de menus particuliers comme recherche avancée.

Figure 8.4.3.1 : Présentation du formulaire d‘accueil

En cliquant sur le menu personnel on obtient le formulaire suivante dont il y a de


champs pour la saisie, il y a aussi le bouton ajout pour l‘enregistrement. Il est donc nécessaire
de bien remplir les champs pour que l‘enregistrement soit réussite.

120
La figure suivante représente le formulaire de saisie du personnel. Tous les champs
sont obligatoirement à remplir.

Figure 8.4.3.2 : Formulaire ajout personnel

121
CONCLUSION

Pour conclure, durant cette 4 mois de stage au sein de la CISCO Ambalavao, grâce
aux interviews pour le regroupement des informations, nous avons pu faire cette rapport et
ainsi programmé un logiciel pour la gestion de la demande de retraite afin de mieux gérer
cette demande sans complication ni difficulté surtout la gestion des dossiers et la recherche.
En fait, l‘utilisation de ce logiciel fournit d‘avantage pour la CISCO Ambalavao grâce à son
efficacité et sécurité.
Personnellement, ce stage m‘a permis de mettre en pratique et d‘approfondir les
connaissances reçues au CUFP notamment en programmation, base de données et surtout en
conduite de projet. Il m‘a confronté une nouvelle fois au monde du travail et m‘a permis
d‘intégrer auprès d‘une équipe pluridisciplinaire. Le fait d‘être intégré dans une équipe
dirigeante au sein de ce service m‘a permis de mieux comprendre les objectifs et les moyens
mis en œuvre pour réaliser un projet, en fonction de divers paramètres, aussi bien humains,
qu‘administratifs.

122
LISTE DES ANNEXES

123
DEPLOIEMENT ET INSTALLATION DE L’APPLICATION

Les programmes à installer reposent sur une base, un support qu‘on appelle aussi
plate-forme. Dans le cas de la JSP, la plate-forme Java est obligatoire.

1. Installation de la plate-forme Java

Dans le cas, la plate-forme adéquate est le J2EE (Java 2 Platform, Enterprise Edition),
Java version entreprise.

De notre projet, nous avons choisi la dernière version stable de Java, version standard,
jdk 1.8.0_11-windows-i586, téléchargeable sur le site officiel de Sun Microsystems
(http://java.sun.com/j2se/1.4.1/download.html.

L‘installation est assez simple car il suffit de suivre les instructions une par une.

Figure 93 : Installation de la plate-forme Java

124
Pour reconnaître cette plate-forme sur tout le système, il faut configurer les variables
d‘environnement. Dans le cas de Windows, il faut y aller dans l‘option « Propriété » du Poste
de travail puis dans l‘onglet « Avancé » pour trouver le bouton « Variable d‘environnement ».
A la variable PATH, la valeur [C:\Program Files\Java\jdk1.8.0_11\bin] est ajoutée, la valeur à
ajouter par défaut est [C:\Program Files\Java\jdk1.8.0_11\bin].

La plate-forme Java est prête à l‘emploi, l‘étape suivante est l‘installation du serveur Web.

2. Installation du serveur Web : TOMCAT

Tomcat est un Conteneur Web, hébergeant des applications Web composées de


servlets et/ou JSP. Tomcat est Téléchargeable sur son site officiel (http://jakarta.apache.org).
Mais comme Netbeans intègre déjà ce conteneur, il suffit juste de cocher la case portant le
nom du serveur lors de l‘installation du Netbeans. Tomcat fera office de serveur Web dans
notre cas.

Figure 10 : Installation du Serveur Web Tomcat

125
Le répertoire qui peut contenir les scripts JSP est le répertoire « webapps » dans
C:\Program Files\Apache Software Foundation\Apache Tomcat\webapps.

Le serveur Web peut contenir maintenant notre site Web mais pour rendre ce site
dynamique, l‘utilisation d‘un Système de Gestion de Base de Données (SGBD) est
appropriée.

3. Installation du SGBD PostgreSQL

PostgreSQL est téléchargeable, en fichier zip, sur son site officiel et la dernière version
stable a été PostgreSQL-8.4.4 win.zip.

Le lien de téléchargement est ftp://ftp.postgresql.org.

L‘installation est assez simple. On décompresse le fichier zip à l‘aide d‘un utilitaire comme
Winzip ou WinRAR dans le répertoire voulu et on lance le fichier « Setup.exe » et suivre les
instructions (Choisir le nom d‘utilisateur, mot de passe, le répertoire d‘installation…). Le
répertoire d‘installation choisi pour PostgreSQL a été le répertoire par défaut [C:\Program
Files\PostgreSQL].

Figure 3 : Installation de la base de données PostgreSQL

126
Une fois l‘installation terminée, On peut insérer notre base portant le nom :
« base_site_srat » dans le PostgreSQL. Grâce à l‘existence de cette base, les données
pourront être stockées dans des tables spécifiques à une application donnée. Cependant
PostgreSQL ne peut pas encore interagir avec les interfaces du site dans le serveur web
Tomcat. Pour se connecter donc à une base de données, Java utilise le pilote JDBC (Java
DataBase Connectivity).

4. Installation de JDBC ou Java DataBase Connectivity

JDBC est une API qui permet l‘exécution des expressions SQL, et qui permet aussi
d‘accéder à des bases de données en utilisant le langage Java. JDBC rend l‘accès facile à
n‘importe quelle base de données, autrement dit, il offre la possibilité d‘accès à une base SQL
notamment MySQL, Oracle, PostgreSQL et tant d‘autres.

JDBC inclut des classes pour des constructions de bases de données classiques, telles
que les connexions de base de données, les instructions SQL et les jeux de résultats. La
technologie JDBC nécessite par ailleurs un pilote (driver) pour chaque type de base de
données. Dans le cas de notre SGBD, le pilote JDBC employé est le « PostegreSQL JDBC
Driver » intégrant déjà dans Netbeans. On a juste inséré ce pilote dans le dossier «Libraries »
de notre projet et on peut y accéder dans toutes les bases dans PostgreSQL.

127
GLOSSAIRES

API : Application Programming interface ou API est une interface de programmation


fournissant un ensemble de fonctions ou de classes normalisées et documentées, permettant à
des applications d‘utiliser les fonctionnalités offertes par un produit, un composant ou une
librairie.

Application : C‘est un ensemble de programme permettant de fournir des fonctions


spécifiques (Par exemple : traitement de texte, tableur, traitement de vidéo…).

Administrateur : Un administrateur est une personne qui possède les pleins pouvoirs sur un
système donné.

Base de Données : C‘est un ensemble de données organisées de telle manière qu‘on puisse
les exploiter.

Cahier des charges : C‘est un document décrivant le plus explicitement possible le contenu
de la prestation et de la fourniture attendue et des éventuelles contraintes concernant les
conditions techniques de développement, d‘exploitation et de qualité.

Cycle de vie : C‘est la suite des étapes nécessaires au développement et à la mise au d‘une
application. Il comporte successivement : l‘expression de la faisabilité des besoins, la
conception préliminaire du système, les spécifications fonctionnelles du système, la
conception préliminaire de l‘application, la conception détaillée du logiciel, le codage de
l‘application…etc.

DOM ou Document Object Model : Modèle Objet de description de document spécifié par le
World Wide Web Consortium (W3C) et permettent d‘accéder au contenu de documents Html
et XML.

Fonctionnalité : Une fonctionnalité est l‘ensemble des possibilités qu‘offre un système


informatique.

Framework (ou cadre d'applications): C‘est un ensemble d'outils et de composants


logiciels organisés conformément à un plan d'architecture et des design filtrer. L'ensemble
forme un squelette de programme. Il est souvent fourni sous la forme d'une bibliothèque
logicielle, et accompagné du plan de l'architecture cible du Framework.

128
Internet : Réseau mondial associant des ressources de télécommunication et des ordinateurs
destiné à l‘échange de messages électroniques, d‘informations multimédias et des fichiers.

Intranet : Réseau local et privé utilisant les technologies de l‘internet.

JDBC : Java DataBase Connectivity ou JDBC est un ensemble d'API permettant à un


programme Java l'accès aux bases de données.

JavaScript : Langage de script développé par Netscape et initialement baptisé Livescript, qui
s‘exécute dans les pages HTML côté client. Il permet d‘interagir avec les composants
normalement statiques d‘une page HTML.

JAVA : Langage de développement, produit par la société Sun et lancé le 23 mai 1995 et écrit
par James Gosling, pour créer des applications autonomes et de doter les documents HTML
de nouvelles fonctionnalités : animations interactives, modèles 3D.

Logiciel : C‘est un ensemble d‘éléments informatiques qui permet d‘assurer une tâche ou une
fonction bien précise (exemple : Logiciel de comptabilité, Logiciel de gestion des prêts).

Open source : L‘expression Open Source caractérise les logiciels dont le code source est
visible, modifiable et librement redistribuable sous certaines conditions, ces conditions
pouvant être plus ou moins strictes.

Planning (Plan de développement): C‘est un document permettant de préparer de manière


détaillée l‘exécution de projet, notamment en termes de démarche, de répartition de tâches et
suivi d‘avancement.

Requête : Commande répondant à une syntaxe précise permettant la manipulation


d‘informations à l‘intérieur d‘une base de données.

SGBD : (Système de Gestion de Base de Données), logiciel permettant de stocker les


données, de les mettre à jour et de les consulter.

Script : Ensemble de codes capables d‘automatiser certaines tâches d‘un programme.

Système d’information : C‘est l‘ensemble organisé de ressources : matériels, personnels,


données et procédures permettant d‘acquérir, traité, stocker communiquer des informations
(Sous forme de données, texte, image, son ….).

TOMCAT : Tomcat est un serveur web Java pour permettre de supporter la technologie JSP.

129
REFERENCES WEBOGRAPHIQUES ET
BIBLIOGRAPHIQUES

Référence webographique
1. Sur le langage JSP, HTML, CSS, JQuery, Ajax
Ces sites sont très complets et bien structuré. Un site de base aussi bien pour les
professionnels que pour les néophytes.

http://www.javafr.com/

http://www.codes-sources.com/

http://www.w3.org

http://www.developpez.com

www.ccim.be/ccim328/js/index.htm

http://uml.free.fr/cours

http://ego.developper.com/uml/tutoriel/casUtilisation

http://www.openweb.eu.org

Site expliquant comment utiliser le langage HTML ainsi que le XHTML et le CSS. Le
contenu est utile mais surtout à réserver aux expert en programmation web.

http://mammouthaland.free.fr/cours/css/index.php

Site généraliste possédant un espace dédié à l‘explication de l‘utilisation des feuilles de style
CSS. Explication complètes, bien structurées et faciles d‘accès.

http://www.siteduzero.com

Site spécialisé dans l‘explication du langage JSP ou PHP ou ASP ou autre langage de
programmation aux débutant. Contient cependant des informations complexes comme la
création d‘un HT Access sur son site. Très bien réalisé, explications simples et concises.

http://www.tutorialspoint.com/index.html

Site expliquant plusieurs fonctionnalités et script JSP telles que les fonctions date (), mail (),
etc.… Le site contient également des espaces dédiés aux langages ASP, PERL, CSS, HTML,
JavaScript… Très bien conçu mais mériterait plus d‘explications des fonctions.

130
2. Sur le SGBD PostgreSQL
ftp://ftp.postgresql.org

Un manuel de référence complète en ligne sur PostgreSQL.

3. Sur la conduite de projet


http://www.dsi.cnrs.fr/conduite-projet.php

Un site complet sur la conduite de projet informatique.

Référence bibliographiques
[1] Encyclopédie comment ça marche ;

[2] UML2 Laurent AUDIBERT Édition 2007-2008

[3] Jean Fruitet Université de Marne-La-Vallée jf@univ-mlv.fr

[4] Damien Seguy 1997 1998 1999 2000 PHP Documentation Group.

[5] Active Server Pages Source. Contributeurs: Abrahami, Alecs.y, AlexKarpman, Alno,
Alternax82, Athymik, Auxerroisdu68, Badmood.

[6] Site du zéro par Nanocom.

[7] Comment ça marche.

[8] Site du zéro par Itello.

[9] Tutoriel Javascript, Université de Nice – Sophia Antipolis.

[10] commentcamarche.

[11] Site du zéro par Sainior

[12] Support de cours JSP de Monsieur HAJALALAINA Aimé Richard 2013 -2014;

[13] D.V. Ferens, COCOMO, Encyclopedia of Software Engineering, pp103-110,

[14] Support de cours système conduits de projet de Monsieur Bakari Maëcha 2013 – 2014 ;

[15] « Evaluation des IHM et ergonomie ». Stéphanie Jean-Daubias.

131
132
133
134
135
136
137
RESUME DU STAGE

Notre stage s'est déroulé le mois de Novembre 2014 et s‘est mise à terme jusqu‘au
mois de Février 2015 au sein du CISCO Ambalavao. Le sujet du stage qu‘on nous a confié est
la « Conception et réalisation d‘une application pour la gestion des demandes de retraite»
dans le cas de la CISCO Ambalavao. Ce sujet a été donné par Monsieur
RASOLOVOAHANGY Andrianantenaina, Chef circonscription scolaire d‘Ambalavao. Le
but du projet est de « géré automatiquement les demandes de retraite des personnels au sein
du CISCO Ambalavao et visualisé les personnels qui vont à la retraite de chaque année ».
Pour la création cette application, nous avons effectué une analyse approfondie sur le sujet en
utilisant le langage de modélisation UML pour la conception car nous avons utilisé la théorie
orientée objet pour ce travail. La réalisation a été développée en JSP (Java Server Pages) et un
système de gestion de base de données PostgreSQL.

ABSTRACT

My training course proceeded November 2014 and will be spread out until February
2015 within the CISCO of Ambalavao. The subject of the training course that one entrusted
to me is ―demand retirement control‖ for the CISCO of Ambalavao. This subject was given
by Mr. RASOLOVOAHANGY Andrianantenaina, Chef CISCO of Ambalavao. The goal of
the project is ―automatically control of personal retirement demand every year―. For the
creation of this application, we had to carry out a thorough analysis of the subject by using the
language of modeling UML for the design because we used the directed theory object for this
work. The realization was developed in JSP (Java Server Pages) and a data base management
system PostgreSQL was used.

138

Вам также может понравиться