Bachelor's degree final project

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
1
UNIVERSITE CADI AYYAD
FACULTE DES SCIENCES SEMLALIA MARRAKECH
DEPARTEMENT D’INFORMATIQUE
Projet de Fin d’Etudes
Licence Sciences Mathématiques et Informatiques
Développement d’une Application Web Java EE
pour la gestion destâches d’un SI
Lieu de stage: La Régie Autonome de Distribution d'Eau et d'Electricité de
Marrakech.
Réalisé par: Encadré par:
EL MIAYAR OUMAIMA Pr. SADGAL MOHAMED
TAHIRI FATIMA Mr. BOULMANE YASSINE
Année Universitaire 2018-2019

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
2
Remerciement
Il est souvent difficile de remercier les gens qui vous aident à accomplir le travail à réaliser, et
pourtant nous devons exprimer l’entière gratitude que nous ressentons envers eux.
Avant toute chose, nous tenons à témoigner toute notre reconnaissance en premier à notre DIEU,
notre créateur pour nous avoir donnée la force pour accomplir ce travail.
Nous tenons à adresser nos remerciements à notre encadrant Pr SAGDAL Mohamed d’avoir
accepté de nous encadrer et de nous orienter durant l’élaboration de ce modeste travail. Vous
nous avez apporté un grand soutien tout au long de notre stage.
Nous tenons également à exprimer toute notre reconnaissance à Monsieur le Directeur de la
RADEEMA MOUNTASSIR Salaheddine qui nous a accordé le privilège de passer notre stage
au sein de la régie pour une durée de deux mois.
Nous tenons à remercier vivement notre maître de stage, Mr BOULMANE Yassine chef de
service administration des système au sein du département système d’information, et Mlle
BOUGTAYA Omaima , pour nous avoir encadrées tout au long de ce stage ,pour le partage de
leurs expertise au quotidien et sans hésiter à aucun moment de nous consacrer une part de leurs
temps précieux afin de nous aider considérablement dans la réalisation de ce travail, aussi d’être
source d’information, de communication , d’encadrement et d’orientation technique et grâce à
leur confiance nous avons pu nous accomplir dans nos missions.
Nos profondes gratitudes et nos profonds respects aux membres du jury Pr SADGAL Mohamed et
Pr ELBACHARI Essaid pour nous avoir honorées en acceptant d’évaluer et de juger ce travail.
Enfin, nous tenons à remercier toutes les personnes qui ont contribué au succès de notre stage
et qui nous ont aidées lors de la rédaction de ce rapport.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
3
Dédicaces
Nous dédions ce modeste travail, comme preuve de respect et de
reconnaissance à :
NOS CHERS ET AIMABLES PARENTS :
Pour les efforts qu’ils ont consentis pour notre éducation et notre
formation, pour leur précieux soutien moral et matériel, pour leurs
encouragements continus, et pour leurs sacrifices tout au long de notre vie,
que nous serons tellement très reconnaissants.
NOS FRERES ET SŒURS :
D’être à nos côtés et nous encourager tous le temps.
NOS FAMILLES :
Qui nous a soutenues tout au long des études.
NOS AMIS :
Qui ont partagé avec nous une période d’étude inoubliable.
ET A VOUS CHERS LECTEURS

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
4
Résumé
Ce présent rapport constitue le mémoire de notre stage de deux mois au sein de la régie
autonome de distribution d'eau et d'électricité de Marrakech. Ce stage était dans le cadre de
validation de la troisième année de licence fondamentale en sciences mathématiques et
informatiques.
Ce travail vise à réaliser une application web d’architecture applicative 3-tiers pour la gestion
des tâches de système d'information planifiés telles que les batchs, les sauvegardes, et non
planifiés telles que les restaurations, les recouvrements, les changements et les mises à jour pour
assurer la bonne marche et un suivi minutieux des différentes opérations techniques effectuées
avec préservation de leur traçabilité.
En effet, l’application est réalisée à l’aide du langage de programmation Java Web EE, en
interaction avec l’API « JPA » comme outil de persistance des données avec une base de
données Oracle et le serveur d’application Glass Fish selon le modèle MVC.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
5
Sommaire
Listes des tableaux……………………………………………………………………………........9
Listes des figures…………………………………………………………………………….........10
Introduction générale ……………………. …………………………………………………….12
Chapitre 1: Contexte du projet …….…………………………………………………………...13
Introduction…………………………………………………………………………………….....14
I. Structure d’accueil…………………………………………………………………………...14
1. Présentation générale de la RADEEMA……………………………………………………....14
2. Historique…………………………………………………………………………………..….14
3. Engagements de la RADEEMA……………………………………………………………….15
4. Organisation de la RADEEMA………………………………………………………………..15
5. Présentation du département systèmes d’information…………………………………………16
II. Présentation du projet………………………………………………………………………..17
1. Problématique……………………………………………………………………………..........17
2. Solutions existantes…………………………………………………………………………….18
3. Solutions retenue………………………………………………………………………….........19
4. Cahier des charges………………………………………………………………………….......20
5. Plan qualité projet(PQP) ……………………………………………………………………….20
5.1. Diagramme de Gantt…………………………………………………………………...............20
5.2. Qualité : Module de cycle de vie………………………………………………………………21
5.2.1. Modèle cycle de vie utilisé…………………………………………………………………..21
5.2.2. Choix cycle de vie……………………………………………………………………………21
Conclusion…………………………………………………………………………………………..22
Chapitre 2 : Analyse et spécification des besoins…………….………………………………….23
Introduction………………………………………………………………………………………....24
I. Analyse des besoins……………………………………………………………………………24
1. Besoins Fonctionnels…………………………………………………………………………….24
1.1.Expressions des besoins…………………………………………………………………………24
1.2.Expression détaillée du besoin…………………………………………………………………..25
2. Besoins non fonctionnels…………………………………………………………………..........27
3. Démarche méthodologique…………………………………………………………………..…27

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
6
3.1.Méthode Merise ………………………………………………………………………………27
3.2.Processus unifié ………………………………………………………………………………28
3.3.Choix de la méthode…………………………………………………………………………..28
4. Outil de modélisation………………………………………………………………………….29
4.1.Qu’est-ce que PowerAMC…………………………………………………………………….29
4.2.Choix de PowerAMC…………………………………………………………… ……………29
II. Etude détaillée de la solution………………………………………………………………..30
1. Identification des acteurs………………………………………………………………………30
2. Diagrammes de cas d’utilisation ………………………………………………………………30
2.1. Diagramme de cas d’utilisation global………………………………………………………..31
2.2.Diagramme de cas d’utilisation d’authentification…………………………………………….32
2.3.Diagramme de cas d’utilisation Gérer objet…………………………………………………....33
2.4.Diagramme de cas d’utilisation Gérer utilisateur……………………………………………....34
2.5.Diagramme de cas d’utilisation Consulter objet……………………………………………….34
3. Diagramme de séquence système global……………………………………………………….35
Conclusion………………………………………………………………………………………….35
Chapitre 3 : Conception détaillée…...………………………………………………………….....36
Introduction…………………………………………………………………………………………37
I. Conception de l’aspect dynamique……………………………………………………………37
1. Diagrammes d’activité……………………………………………………………………..........37
1.1.Diagramme d’activité Authentification………………………………………………………….38
1.2.Diagramme d’activité gérer Utilisateur………………………………………………………….39
2. Diagramme de séquence………………………………………………………………...............39
2.1. Diagramme de séquence Authentification………………………………………………………40
2.2. Diagramme de séquence Ajouter Utilisateur…………………………………………………....41
2.3. Diagramme de séquence Modifier Batch……………………………………………………….42
2.4. Diagramme de séquence supprimer Changement………………………………………………43
2.5. Diagramme de séquence Reporting…………………………………………………………….44
II. Conception de l’aspect statique……………………………………………………………….45
1. Description des classes…………………………………………………………………………..45
2. Diagramme de classes…………………………………………………………………………...45
Conclusion………………………………………………………………………………………47

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
7
Chapitre 4 : Etude technique et réalisation……………………………………………….….48
Introduction………………………………………………………………………………………49
I. Etude technique…………………………………………………………………………….49
1. Environnement de réalisation………………………………………………………………..49
1.1.Matériel de base…………………………………………………….......................................49
1.2. Choix des langages de développement……………………………………………………...50
1.3.Choix de base de donnée…………………………………………………………………….51
1.4.Choix d’environnement de développement………………………………………………….52
1.5.Choix d’architecture…………………………………………………………………………52
1.5.1. Architecture 3 tiers……………. ………………………………………………………..52
1.5.1.1 Serveur d’application utilisé…………………………………………………………….53
1.5.1.2 Java Persistence API…………………………………………………………………….54
1.5.2 Architecture MVC…………………………………………………………………………55
1.6. Choix de Framework………………………………………………………………………..56
II. Structure et maquette de l’application…………………………………………………….56
III. Les composantes applicatives réalisées…………………………………………………...58
1. Interface de connexion……………………………………………………………………….58
2. Interfaces d’accueil…………………………………………………………………………..59
2.1.Page d’accueil (Acteur : Administrateur) …………………………………………………...59
2.2.Page d’accueil (Acteur : Opérateur/Observateur) ………………………………………..….60
3. Menus……………………………………………………………………………………..….60
4. Menu utilisateur…………………………………………………………………………...….62
4.1.Liste des utilisateurs……………………………………………………………………..…...62
4.2.Ajouter utilisateur…………………………………………………………………………….62
4.3.Modifier utilisateur…………………………………………………………………………...63
4.4.Affiche détails…………………………………………………………………………….…..63
4.5.Liste organisations……………………………………………………………………………63
5. Menu Batch…………………………………………………………………………………...64
5.1.Liste des paramètres initiaux des batchs……………………………………………………...64
5.2.Liste des batchs……………………………………………………………………………….64
5.3.Créer un nouveau batch………………………………………………………………………65
5.4.Chercher Batch……………………………………………………………………………….65
5.5.Générer un graphe des batchs………………………………………………………………...66
5.6.Afficher les détails d’un batch……………………………………………………………......66

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
8
6. Menu sauvegarde……………………………………………………………………………..67
6.1.Liste des paramètres initiaux des sauvegardes………………………………………………..67
6.2.Modifier sauvegarde…………………………………………………………………………..67
6.3.Chercher sauvegarde………………………………………………………………….……....68
6.4.Chercher restauration…………………………………………………….………………...…68
7. Menu recouvrement……………………………………………………………………..…….69
7.1.Liste des paramètres initiaux des recouvrements.…………………………………….….……69
7.2.Générer un graphe des recouvrement………………………………………………….………69
7.3.Exporter liste des recouvrements vers un fichier PDF…………………………………….…...70
7.4.Exporter liste des recouvrements vers un fichier Excel………………………………………..70
7.5.Ajouter recouvrement………………………………………………………………….……….70
8. Menu changement et mise à jour…………………………………………………...…………..71
8.1.Liste des changements……………………………………………………………………….…71
8.2.Ajouter changements……………………………………………………………………….…. 71
8.3.Ajouter mise à jour……………………………………………………………………….…….72
Conclusion………………………………………………………………………………………….72
Conclusion générale et perspectives……………………………………………………………...73
Bibliographie &Webographie ………………………………………………………………........75
Glossaire ………………………………….......................................................................................76
Annexe …………………………………………………………………………………………......79

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
9
Liste des tableaux
Table 1 : Fonctionnalités de gestion de référentiel de données.
Table 2 : Niveau de Merise.
Table 3 : Identifications des acteurs.
Table 4 : Matériel de base.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
10
Liste des figures
Figure 1 : Organigramme de Direction.
Figure 2 : Organigramme de Département SI.
Figure 3: Diagramme de GANTT.
Figure 4 : Modèle de cycle de vie en V.
Figure 5: Diagramme général de cas d’utilisation.
Figure 6: Diagramme de cas d’utilisation Authentification.
Figure 7: Diagramme de cas d’utilisation Gérer Mise à Jour.
Figure 8 : Diagramme de cas d’utilisation Gérer Utilisateur.
Figure 9 : Diagramme de cas d’utilisation Consulter Objet.
Figure 10 : Diagramme de séquence système global.
Figure 11 : Diagramme d’activité Authentification.
Figure 12: Diagramme d’activité Gérer utilisateur pour l’administrateur.
Figure 13: Diagramme de séquence Authentification.
Figure 14: Diagramme de séquence Ajouter Utilisateur.
Figure 15: Diagramme de séquence Modifier Batch.
Figure 16: Diagramme de séquence Suppression changement.
Figure 17: Diagramme de séquence Reporting.
Figure 18: Diagramme de classe.
Figure 19 : Modèle physique 3 tiers.
Figure 20: Rôle de JPA.
Figure 21 : Modèle MVC.
Figure 22 : Structure de l’application pour l’administrateur.
Figure 23 : Authentification.
Figure 24 : Erreur d’authentification 1.
Figure 25 : Erreur d’authentification 2.
Figure 26 : Page d’accueil d’administrateur.
Figure 27 : Page d’accueil d’opérateur/observateur.
Figure 28 : Menu Batch.
Figure 29 : Menu sauvegarde et restauration.
Figure 30 : Menu recouvrement.
Figure 31 : Menu changement et Mise à jour.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
11
Figure 32 : Menu utilisateurs.
Figure 33 : Menu administration pour l’utilisateur.
Figure 34 : Liste des utilisateurs.
Figure 35 : Ajouter utilisateur.
Figure 36 : Modifier utilisateur.
Figure 37 : Détails d’un utilisateur.
Figure 38 : Liste des organisations.
Figure 39 : Liste des paramètres initiaux des batchs.
Figure 40 : Liste des batchs.
Figure 41 : Ajouter batch.
Figure 42 : Chercher Batchs.
Figure 43 : Graphe des Batchs.
Figure 44 : Afficher les détails d’un utilisateur.
Figure 45 : Liste des paramètres initiaux des sauvegardes.
Figure 46 : Modifier sauvegarde.
Figure 47 : Chercher sauvegarde.
Figure 48 : Chercher restauration.
Figure 49 : Liste des paramètres initiaux des recouvrements.
Figure 50 : Générer un graphe des recouvrements.
Figure 51 : Exporter Liste des recouvrements vers un fichier PDF.
Figure 52 : Exporter Liste des recouvrements vers un fichier Excel.
Figure 53 : Ajouter recouvrement.
Figure 54 : Liste des changements.
Figure 55 : Ajouter changement.
Figure 56 : Ajouter mise à jour.
Figure 57: Architecture Java Web EE.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
12
Introduction Générale
De nos jours, chaque entreprise cherche le meilleur moyen pour augmenter sa production et de
confronter les différents conflits qui peuvent être engendrés par le manque de coordination et
d’organisation au sein de ses différentes équipes. En effet, vu la croissance des activités au sein des
entreprises, la tâche de gérer efficacement toutes ces actions s’avère de plus en plus complexe. En
plus, le pilotage des données, aujourd’hui, n’est plus une mince affaire. Pour surpasser ces
difficultés, une entreprise doit utiliser des outils optimisés et adaptés, facilitant les tâches et offrant
des fonctionnalités riches et utiles.
Dans ce contexte, La Régie Autonome de Distribution d'Eau et d'Electricité de Marrakech a fixé des
objectifs pour améliorer chaque tâche de ses activités afin rendre le travail facile à gérer. Nous y
participons dans le cadre d’un stage de fin d’études.
L’objet de ce stage est de créer une application en Java EE pour la gestion des tâches de système
d'information planifiés telles que les batchs, les sauvegardes, et non planifiés telles que les
restaurations, les recouvrements, les changements et les mises à jour en utilisant comme langage de
programmation JAVA SERVER FACES et API JPA comme outil de persistance des données avec
une base de données. Cette application nous a permis de faire un suivi des différentes opérations
techniques effectuées avec préservation de leur traçabilité, ce qui permet ainsi de respecter les
exigences de qualité requises particulièrement par les audits de certification Et pour la réalisation de
cette tâche. Notre choix s’est porté sur la méthode de développement logiciel UP et UML comme
langage de modélisation.
Ce rapport va s'articuler autour de quatre chapitres. Il fait la synthèse de notre étude durant la période
de stage. Dans le premier chapitre, nous allons fournir une présentation générale de l’entreprise
RADEEMA et du projet, le travail à réaliser dans son contexte et sa problématique, ainsi que la
solution proposée. Le second chapitre est consacré à l’analyse en spécifiant les besoins qui
comportera la problématique, les spécification fonctionnelles et non fonctionnelles ainsi que la
description de la logique de l’application à réaliser en présentant les cas d’utilisations. Dans le
troisième chapitre nous allons détailler la conception de ces derniers. La description de
l’implémentation de ces cas d’utilisation est présentée dans le quatrième chapitre consacré à la
réalisation ou on a mis en œuvre notre projet.
Finalement on clôture ce rapport par une conclusion générale tout en évoquant des perspectives
pour l’amélioration du projet.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
13
Chapitre 1 :
Contexte du projet

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
14
Introduction
Chaque organisation possède ses propres spécificités et se distingue des autres structures qui
l’entourent. Il y a donc lieu de la présenter sous ses différents aspects organisationnels et fonctionnels
afin d’avoir une idée précise sur la nature de ses activités, les relations, souvent complexes, qu’elle
peut entretenir avec son environnement aussi bien interne qu’externe.
Nous introduisons donc le cadre de notre PFE, à savoir l’organisme d’accueil, et le sujet qui nous a
été communiqué par notre encadrant au sein la société RADEEMA afin de relever ses insuffisances
et de proposer une solution efficace. Nous clôturons enfin par la démarche adoptée.
I. Structure d’accueil
1. Présentation générale de la RADEEMA
La RADEEMA assure la distribution d'eau et d'électricité et la gestion du service d'assainissement
liquide au sein de la ville de Marrakech. Les trois métiers couvrent une zone d'action de 24 000 ha et
une population d'environ 950 000 habitants.
La mission de la RADEEMA et sa préoccupation majeure est d'accompagner le développement
important que connait la ville de Marrakech, sécuriser l'approvisionnement et la bonne gestion des
services assurés.
Le volet environnemental et écologique est au centre des actions engagées par la RADEEMA
notamment le traitement et la réutilisation des eaux usées. Ainsi, les principales actions entreprises ont
porté sur le renforcement des infrastructures de base, la sécurisation de l’alimentation en eau et en
électricité, la lutte contre la pollution du milieu récepteur et la protection de l’environnement et la
généralisation de l’accès aux services et ce dans le cadre de l’initiative nationale du développement
humain.
2. Historique
La société d’Electricité de Marrakech est constituée le 27 juin 1922.
Le 17 juillet 1964, la ville de Marrakech a signé un protocole pour le rachat de la concession, laquelle
fut confiée à la Société Marocaine de Distribution (SMD) Le 26 Décembre 1970 et suite aux
délibérations du conseil communal de la ville de Marrakech, il a été décidé de créer à partir du premier

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
15
janvier 1971, la régie autonome de distribution d’eau et d’électricité de Marrakech, dénommée
RADEEMA et ce en en vertu du Décret n° 2-64-394 du 29 Septembre 1964 relatif aux régies
communales.
Le premier janvier 1998, la RADEEMA a pris en charge la gestion du service de l’assainissement liquide
suite aux délibérations de la communauté urbaine de Marrakech.
Le 09 Juillet 2010, la RADEEMA est passée au contrôle d'accompagnement en substitution du contrôle
préalable conformément aux dispositions de l'article 18 de la loi 69.00 pour un mandat de 2 ans soit
2010-2012.
2012 : Première triple certification QSE soit, ISO 9001 v 2008, ISO 14001 v 2004, OHSAS 18001 v
2007.
2013-2016 : 2éme mandat du contrat de programme avec l’état.
2016 : Renouvellement de la triple certification QSE dans ses nouvelles versions, soit ISO 9001 v 2015,
ISO 14001 v 2015 et OHSAS 18001 v 2007.
2017-2019: 3éme mandat du contrat de programme avec l’état.
3. Engagements de la RADEEMA
Dans le but d’accompagner l’essor de la ville, la RADEEMA a entamé la réalisation d’un programme
d’investissement d’envergure d’un montant de 1,6 Milliards DH qui s’étale jusqu’à 2017. Ce programme
s’inscrivant dans le cadre de la convention, signée le 6 janvier 2014 sous la présidence effective de Sa
Majesté le Roi Mohamed VI, que Dieu l’Assiste, comporte :
Une composante concernant la préservation de l’environnement avec une enveloppe de 842 Millions
DH, incluant essentiellement l’extension de la station d’épuration des eaux usées, le traitement des
boues résiduaires, l’extension du réseau d’assainissement, le renouvellement du réseau de la médina et
la mise en place des collecteurs principaux d’assainissement autour de la ville.
Et une deuxième composante relative à l’accompagnement de la mise à niveau urbaine avec un montant
de 758 Millions DH, et ce par notamment de nouveaux réservoirs d’eau, la mise en place de gros feeders
d’eau potable autour de la ville, l’extension et le renouvellement des réseaux d’eau et d’électricité, la
construction d’un nouveau poste source d’électricité.
4. Organisation de la RADEEMA
Il existe à la RADEEMA plusieurs divisions et services représentés sous forme d’organigramme:

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
16
Figure 1 : Organigramme de la Direction
C’est dans le département systèmes d’information que nous avons effectué notre stage de fin d’études et
plus précisément au sein du service administration des systèmes.
5. Présentation du département systèmes d’information
Le département des systèmes d’information est l’entité de la RADEEMA responsable de toute activité
informatique dans la régie, à savoir : la mise à disposition de l’infrastructure, le support technique aux
utilisateurs ainsi que la mise en place des procédures de sécurité et d’administration nécessaires au bon
fonctionnement de tous les systèmes.
L’organigramme ci-dessous représente la structure du département des systèmes d’information mise en
place par la régie dans le cadre de sa nouvelle organisation. Ce département comporte plusieurs services
ayant chacun un ensemble de tâches prédéfinies.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
17
Figure 2 : Organigramme de département système d’information
II. Présentation du projet
Les systèmes d’information sont tous différents par leurs tailles, leurs natures, leurs criticités. Ils
sont cependant pour point commun d’être le théâtre de l’incident, à un moment où à un autre.
La loi de Murphy est immuable. Si quelque chose peut mal tourner, alors elle finira infailliblement
par mal tourner.
A cet effet il s’avère important que la RADEEMA intègre des fonctionnalités de gestion des tâches
de leur système d’information pour assurer la bonne marche et un suivi minutieux de ces tâches
planifiées et non planifiées.
1. Problématique
Parmi les soucis principaux de chaque moyenne ou grande entreprise figure la gestion des tâches de
leur SI. Cette activité permet de faire un suivi des différentes opérations techniques effectuées avec
préservation de leur traçabilité, ce qui permet ainsi de respecter les exigences de qualité requises

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
18
particulièrement par les audits de certification. En effet, la RADEEMA s’est engagée dans une
démarche de qualité et qui lui a permet d’obtenir la certification QSE (Qualité, Sécurité et
Environnement).
Et lorsqu’on parle des tâches, on parle notamment de leurs données correspondantes, qui sont d’une
importance capitale pour l’entreprise. La perte de ces données pourrait la paralyser et même dans les
cas extrêmes, lui être fatale.
Parmi les principales tâches qu’il faut gérer au sein du département d’information de la RADEEMA,
on trouve des tâches planifiées tel que les batchs, les sauvegardes, et non planifiés tel que les
restaurations, les recouvrements, les changements et les mises à jour ainsi que la création des reporting
des données enregistrées.
2. Solutions existantes
Sur le marché nombreuses solutions de gestion de tâches d'un système d'information existent aujourd’hui
on trouve des offres éditeurs ainsi que des offres open source.
Les offres libres
Une offre libre est un logiciel qui est distribué selon une licence libre. Précisément, ce sont les licences
libres qui définissent les logiciels comme tels.
Plus concrètement et de manière un peu simplifiée, cela se matérialise par le fait qu’une offre libre est un
logiciel qui peut être utilisé, modifié et redistribué sans restriction par la personne à qui l’a été distribué.
Une telle offre est ainsi susceptible d'être soumis à étude, critique et correction. Cette caractéristique
confère aux logiciels libres une certaine fiabilité et réactivité.
Malgré que ces applications soient des logiciels libres sous licence GPL, il ne présente pas mal
d’inconvénient :
✓ Interface non ergonomique et complexe ;
✓ Configuration fastidieuse via beaucoup de fichiers pour avoir toutes les fonctionnalités ;
✓ Difficulté de faire développement spécifiques pour faire des adaptations ;
✓ Un développement lent, peu de versions et très espacées.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
19
Ces inconvénients sont le résultat que ces logiciels ne sont pas spécifiques aux besoins bien déterminés
de la RADEEMA.C’est une solution libre.
Exemple des offres libres : Paymo, Team Task Manager, DropTask…
Ils ont un point commun : Ne satisfaire pas tous les besoins soit ils ont plus d’options soit ils en
ont moins.
Les offres éditeurs
Les solutions sur le marché sont dans la plupart en mode Abonnement Saas (Software as a Service), qui
propose des solutions sous la forme d'un service hébergé.
Une offre éditeur ou bien un logiciel en tant que service ou software as a service est un modèle
d'exploitation commerciale des logiciels dans lequel ceux-ci sont installés sur des serveurs distants plutôt
que sur la machine de l'utilisateur. Les clients ne paient pas de licence d'utilisation pour une version, mais
utilisent librement le service en ligne ou, plus généralement, payent un abonnement.
Exemple des offres éditeurs : Taskworld, Wrike, Tamplo…
Ces solutions n’ont qu’un seul point commun : un prix élevé et ne satisfait pas tous les besoins.
3. Solution retenue
Vu que les solutions détaillées dans la sous-section précédente ne satisfont pas tous les besoins de
notre département en ce qui concerne la gestion des batchs, des sauvegardes, des changements, des
mises à jour, et des recouvrements, nous allons concevoir et mettre en place une application de
gestion des tâches d’un système d'information au sein de la RADEEMA « sur mesure » que nous
allons décrire ultérieurement pour aboutir à la satisfaction des besoins.
• Solution proposée :
En vue de remédier aux insuffisances :
Nous proposons la réalisation d’une application conviviale que nous allons nommer RADEEMA
TASK MANAGER, pour faciliter le travail dans le département système d’information.
Les résultats attendus de cette application sont :
✓ Traçabilité des tâches planifiées et non planifiées ;
✓ Amélioration de la sécurité et la protection des données ;

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
20
✓ Réduction du temps de recherche et de diffusion des informations récentes ;
✓ Création du reporting à partir des données enregistrées ;
✓ Répondre au besoin de l’auditeur qualité.
4. Cahier des charges
Le travail que nous allons réaliser consiste à concevoir et à développer une application de gestion des
tâches de système d’information de la RADEEMA, et effectue les objectifs suivants :
• Gestion des batchs ;
• Gestion des recouvrements ;
• Gestion des sauvegardes et des restaurations ;
• Gestion des changements ;
• Gestion des mises à jour ;
• Création du reporting de certaines tâches ;
• Générer le rapport final.
5. Plan qualité projet (PQP)
Le Plan Qualité de Projet (ou PQP) a pour objectif la définition et le suivi des dispositions à prendre
dans le cadre du projet afin d’en assurer la qualité et d’atteindre les résultats attendus.
5.1. Diagramme de Gantt
Afin de mieux exploiter le temps alloué à la réalisation du projet de fin d’étude, une bonne gestion de
ce temps est nécessaire, c’est pour cela nous avons eu recours au diagramme de Gantt afin d’illustrer le
déroulement du projet.
Le diagramme de GANTT est un outil permettant de modéliser la planification de tâches nécessaires à
la réalisation d'un projet.
Pour arriver à réaliser ce projet, nous avons suivi le planning suivant :

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
21
Figure 3: Diagramme de GANTT
La figure suivante vous montre les différentes tâches à faire pendant la période de stage, avec des
durées d’accomplissements approximatives.
5.2. Qualité : Module de cycle de vie
Le « cycle de vie d'un logiciel » désigne toutes les étapes du développement d'un logiciel, de sa
conception à sa disparition. L'objectif d'un tel découpage est de permettre de définir des jalons
intermédiaires permettant la validation du développement logiciel, c'est-à-dire la conformité du
logiciel avec les besoins exprimés Il existe une variété de ces modèles : en cascade, W, Y.
5.2.1. Modèle de cycle de vie utilisé
Le modèle en V demeure actuellement le cycle de vie le plus connu et certainement le plus utilisé. 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 doit être 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.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
22
5.2.2. Choix cycle de vie
La méthode adéquate que nous avons mise en œuvre dans ce travail est le modèle en V. Ce modèle
est plus récent et plus proche de la réalité de l'articulation entre les activités de spécification et de
conception, avec celles de validation et vérification. En effet, contrairement au modèle de cascade, ce
modèle fait apparaître le fait que le début du processus de développement conditionne ses dernières
étapes :
Figure 4: Modèle de cycle de vie en V.
Conclusion
A travers ce 1
er
chapitre, nous avons pu nous placer dans le contexte général de notre projet en
introduisant le domaine de l’application ainsi que le cadre du travail en faisant une étude préalable qui
comporte l’étude de l’existent et son critique et les solutions proposés et leurs limites et nous avons fini
par la solution retenue. Par conséquent, nous essayerons dans les étapes suivantes de répondre à ces
besoins en entamant la phase d’analyse et de conception dans les chapitres suivants.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
23
Chapitre 2 :
Analyse et spécification
des besoins

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
24
Introduction
Après avoir présenté le cadre général du projet, le présent chapitre nous permet d’identifier toutes les
fonctionnalités de notre futur système pour chaque utilisateur, et ceci en recensant les besoins
fonctionnels et d’appréhender la liste des exigences traduites par les besoins non fonctionnels.
Ceci se fera par l’identification des acteurs et la définition de tous les besoins qui seront modélisés
par les diagrammes de cas d’utilisation général et détaillés et le diagramme de séquence système
global après avoir présenté le langage de conception adoptée ainsi l’outil de modélisation choisi.
I. Analyse des besoins
La phase d’analyse a pour objectif de décrire de manière précise, concise, correcte et compréhensible
les besoins et les exigences du client. Il s’agit de livrer des spécifications pour permettre la conception
de la solution. La phase d’analyse permet de s’accorder sur « ce que doit faire l’application ?
1. Besoins fonctionnels
Il s'agit des fonctionnalités du système. Ce sont les besoins spécifiant un comportement d'entrée / sortie
du système.
- Maitrise d'ouvrage : Département systèmes d’information RADEEMA ;
- Maitrise d'œuvre : EL MIAYAR OUMAIMA & TAHIRI FATIMA.
1.1. Expression des besoins
L’objectif de ce projet est de réaliser une application permettant de gérer les tâches de système
d’information au sein de la RADEEMA.
Cette application doit permettre l’ajout, la modification, la consultation ou la suppression de référentiel
de données (Batch, Sauvegarde, Restauration, Changement, Mise à jour…) dans la base de données et
aussi la génération des rapports.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
25
1.2. Expression détaillée du besoin
Module authentification : Le contrôle d'accès assure la sécurité et confidentialité par la vérification de
l'identité d'un utilisateur, s’authentifier par un login et mot de passe pour avoir accès à la page d’accueil.
Module gestion de référentiel de données : il comporte les fonctions suivantes :
Axes de
l’application
Fonctionnalités Attributs
Gestion des
Batchs
- Gérer des Batchs ;
- Reporting.
Nom du batch, Usage du
batch, résultat (réussi ou
incident),date début
programmée, date fin
programmée, date début
d’exécution, date de fin
d’exécution, durée.
- Gestion des paramètres
d’initialisation des batchs
(default batch).
Nom du batch, usage du
batch, résultat, date début
programmée, date fin
programmée.
Gestion des
Sauvegardes
- Gestion des sauvegardes;
- Reporting.
Libellé, produit sauvegardé
Site, Système d’exploitation,
date suivie
Résultat, durée, support de
sauvegarde, méthode de
sauvegarde.
- Gestion des paramètres
d’initialisation des
Sauvegardes (default
Sauvegarde) ;
- Reporting.
Libellé, Système
d’exploitation, Site, Date
début programmée, Date fin
programmée.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
26
Gestion des
restaurations
- Gestion des restaurations ;
- Reporting.
Libellé, Produit
sauvegardé
Support de sauvegarde,
Méthode de sauvegarde,
Date de sauvegarde,
Date de restauration
Site, Système
d’exploitation.
Résultat, Durée.
Gestion
Des
Changements
- Gérer les changements ;
- Gérer les plateformes;
- Reporting.
Sujet, Catégorie, Statut,
Site, Priorité, Date début
d’échéance, Date fin
d’échéance, Soumis par,
Impact infrastructure,
Impact ressource
Gestion
Des mises à
jour
- Gérer les mises à jour ;
- Gérer les plateformes;
- Reporting.
Sujet de la mise à jour,
Priorité, Catégorie,
Date d’échéance ,Type,
Version de la mise à jour
, Description de la mise à
jour.
Gestion
des
utilisateurs
- Gérer les connexions;
- Gérer les organisations.
Nom de l’utilisateur,
Prénom de l’utilisateur,
Login, Mot de passe
(password),Privilège
(admin, opérateur,
observateur).
Table 1 : Fonctionnalités de gestion de référentiel de données.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
27
2. Besoins non fonctionnels
Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de performance, de
type de matériel ou le type de conception. Ces besoins peuvent concerner les contraintes
d'implémentation (langage de programmation, type SGBD, de système d'Exploitation...).
Dans le cadre de ce travail, l'application devra :
• Etre facile à utiliser et à interpréter les erreurs en cas d'erreur d'utilisation ;
• Etre compatible avec n'importe quel système d'exploitation et avec d'autres logiciels ;
• Etre sécurisée car les informations ne devront pas être accessibles qu’aux personnes autorisés ;
• Etre extensible : la possibilité d'ajouter ou de modifier de nouvelles fonctionnalités ;
• Garantir la Réutilisabilité d'un logiciel en tout ou en partie, dans de nouvelles applications.
3. Démarche méthodologique
Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système.
C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence.
3.1. Méthode Merise
Merise étant une méthode de conception et de développement de système d’information daté de 1978-
1979, il est basé sur la séparation des données et des traitements à effectuer en plusieurs modèles
conceptuels et organisationnels, physiques.
Table 2: Niveaux de Merise.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
28
3.2. Processus unifié(UP)
Le processus unifié est un processus de développement d’une application itérative, centré sur
l'architecture, piloté par des cas d'utilisation et orienté vers la diminution des risques, il regroupe les
activités à mener pour transformer les besoins d’un utilisateur en système logiciel.
C’est une méthode de prise en charge du cycle de vie d’un logiciel et donc du développement, pour les
logiciels orientés objets. C’est une méthode générique, itérative et incrémentale, contrairement à la
méthode séquentielle Merise.
L'objectif d'un processus unifié est de maîtriser la complexité des projets informatiques en diminuant
les risques. En répondant aux préoccupations suivantes :
QUI participe au projet ?
QUOI, qu'est-ce qui est produit durant le projet ?
COMMENT doit-il être réalisé ?
QUAND est réalisé chaque livrable ?
3.3. Choix de la méthode
UML
Pour la réalisation de cette application, notre choix a été porté sur le Processus Unifié. En effet, le
processus unifié est une solution de développement logiciel adaptée à tout type de projet. Ses traits
distinctifs tiennent compte de trois notions : piloté par les cas d'utilisation, centré sur l'architecture,
itératif et incrémental.
Le langage de modélisation que nous avons utilisé est UML (Unifier Modeling Langage), qui est une
partie intégrante de la démarche UP.
Ses diagrammes sont largement utilisés dans chaque étape et phase de ce processus de développement,
il est idéal pour :
✓ Concevoir et déployer une architecture logicielle développée dans un langage objet (Java, C++,
VB.net). Certes UML, dans sa volonté "unificatrice" a proposé des formalismes.
✓ Pour modéliser les données (le modèle de classe réduit sans méthodes et stéréotypé en entités),
mais avec des lacunes que ne présentait pas l'entité relation de Merise.
✓ Pour modéliser le fonctionnement métier (le diagramme d'activité et de cas d'utilisation) qui sont
des formalismes très anciens qu'avait, en son temps, amélioré Merise...

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
29
✓ Pour l'implémentation, le choix s'est porté sur le langage de programmation JSP/JSF
implémenté dans un environnement J2EE avec une base de données Oracle.
Environnement de modélisation utilisé : On va utiliser le logiciel power designer comme
environnement de modélisation qui permet d’élaborer des différents modèles de conception.
4. Outil de modélisation
4.1. Qu’est-ce que PowerAMC
POWER AMC
C’est l’un des premiers outils qui permet d’élaborer des modèles de données que cela soit MERISE,
UML ou autre, de manière graphique et de les implémenter quel que soit le SGBD et ce de manière
automatique. De même, l’outil permet de modéliser les processus métiers. Le lien entre la
modélisation des données et la modélisation des processus peut être effectué, offrant ainsi aux
entreprises qui possèdent POWER AMC / AMC Designer l'opportunité de mettre un œuvre un
référentiel unique des développements et des processus que ceux-ci soient informatisés ou non.
Aussi Power AMC est une force dans tout nouveau projet d'entreprise car il permet d'identifier avec
précision quels processus, quelles personnes et/ou quelles données seront impactés. L'estimation et
maîtrise des coûts en est grandie.
4.2. Choix de PowerAMC
PowerAMC fournit un jeu unique d'outils de modélisation professionnels qui associent les techniques
et notations standard de la modélisation de processus métiers, de la modélisation des données et de la
modélisation des diagrammes UML et d'autres fonctionnalités puissantes afin d’aider à analyser,
concevoir, construire et maintenir des applications, en utilisant les techniques les plus élaborées
d'ingénierie logicielle.
La solution de modélisation PowerAMC permet d'intégrer étroitement la conception et la
maintenance des couches de données centrales de l'application et exigences de projet, processus
métiers, code orienté objet, vocabulaires XML et informations de réplication de base de données.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
30
II. Etude détaillée de la solution
Nous traitons dans cette partie l’analyse fonctionnelle de notre projet. D’abord nous identifions les
acteurs impliqués, ensuite nous spécifions les cas d’utilisations de notre application et nous finalisons
notre chapitre par le diagramme séquence global :
1. Identification des acteurs
Un acteur est un humain ou une machine ne faisant pas partie de la solution à réaliser mais
qui participe au fonctionnement général de la solution par une interaction. Nous identifions
trois acteurs : l’Observateur, l’Opérateur et l’Administrateur.
Acteur Responsable de la tache Rôle
Observateur
- Chef de service méthode et
qualité ;
- Chef de département du
système d’information.
- Consulter des rapports ;
- Suivi qualité.
Opérateur
- Techniciens réseau, système et
bases de données.
- Saisi des données des
tâches.
Administrateur
- Chef du service administration
des système.
- Paramétrage de
l’application ;
- Gestion des utilisateurs ;
- Suppression des objets.
Table 3 : Identifications des acteurs.
2. Diagrammes de cas d’utilisation
Un cas d’utilisation est une manière spécifique d’utiliser un système. C’est l’image d’une
fonctionnalité du système, déclenchée en réponse à la stimulation d’un acteur externe. Les cas
d’utilisation apportent une solution aux problèmes de la détermination et de la compréhension des
besoins.
La figure 5 sise ci-dessous présente le digramme global des cas d’utilisation de notre application.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
31
2.1. Diagramme de cas d’utilisation global
Un diagramme de cas d’utilisation global représente tous les cas d'utilisation relative à notre système.
Il est utilisé pour donner une vision globale du comportement fonctionnel du système logiciel.
Figure 5 : Diagramme général de cas d’utilisation.
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Observateur
Opérateur
Administrateur
Consulter les objets
Gérer Batch
Gérer Sauvegarde
Gérer Restauration
Gérer Recouvrement
Gérer Changement
Gérer Mise à jour
Supprimer les objets
Gérer utilisateur
S'authentifier
<<include>>
<<include>>
<<include>>
Reporting
<<include>>

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
32
En s’appuyant sur la figure (5), nous avons distingué les cas d’utilisations suivants :
1. Authentification : l’application doit vérifier que l’utilisateur est bien celui qui prétend d’être afin de
lui autoriser l’accès à l’application ;
2. Gestion des utilisateurs : pour l’administrateur de site qui comprend l’ajout, la modification et la
suppression d’un utilisateur ;
3. Suppression des objets : pour l’administrateur de site ;
4. Mise à jour des données qui comprend : la création et la modification des batchs / sauvegardes /
restaurations /changements /mise à jour/recouvrements ;
5. Consulter les objets: obtenir des informations sur les batchs / sauvegardes / restaurations
/changements /mise à jour/recouvrements ;
6.Reporting : Création des rapports à partir des données enregistrées.
A l’issue de l’expression des besoins à l’aide du diagramme des cas d’utilisation globale, dans ce qui
suit, nous détaillons chacun des cas d’utilisation présente dans les figures (6), (7), (8) et (9), en
donnant sa description textuelle.
2.2. Diagramme de cas d’utilisation Authentification
Figure 6: Diagramme de cas d’utilisation Authentification.
Acteur principal : utilisateurs (Administrateur /opérateur/observateur).
Objectif : S’assurer que l’utilisateur est bien celui qui prêtant être.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
33
2.3. Diagramme de cas d’utilisation Gérer Objet
Exemple : Gérer Mise à Jour
Figure 7: Diagramme de cas d’utilisation Gérer Mise à Jour.
Objectif : Pouvoir consulter une mise à jour pour l’observateur.
Pouvoir ajouter, modiﬁer et consulter une mise à jour pour l’opérateur.
Pouvoir ajouter, modiﬁer, consulter et supprimer une mise à jour pour l’administrateur.
Note : c’est les mêmes étapes pour les diagrammes de cas d’utilisation de la gestion des batchs, des
sauvegardes, des restaurations, des recouvrements et des changements.
Operateur
Modifier
Ajouter
Authentification
Gérer Mise à jour
<<extends>>
<<extends>>
<<include>>
Supprimer Mise à jour
Consulter Mise à jour
Administrateur
Observateur
<<include>>
<<include>>

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
34
2.4. Diagramme de cas d’utilisation Gérer Utilisateur
Figure 8: Diagramme de cas d’utilisation Gérer Utilisateur.
Acteur principal : Administrateur.
Objectif : Pouvoir ajouter, modiﬁer, consulter et supprimer un utilisateur.
2.5. Diagramme de cas d’utilisation Consulter objet
Figure 9: Diagramme de cas d’utilisation Consulter Objet.
Administrateur
Modifier
Ajouter
Authentification
Gérer Utilisateur
<<extends>>
<<extends>>
<<include>>
Supprimer
<<extends>>
Consulter
<<extends>>
Observateur
Batch
Sauvegarde
Authentification
Consulter objet
<<extends>>
<<extends>>
<<include>>
Changement
<<extends>>
Mise à jour <<extends>>
Restauration
Recouvrement
<<extends>>
Opérateur
Administrateur
<<extends>>

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
35
Ce diagramme précise la consultation des objets qui va permettre les acteurs de prendre connaissance
de la tâche traitée et ses informations.
3. Diagramme de séquence système global
Figure 10: Diagramme de séquence système.
Ce diagramme est utilisé pour présenter les interactions entre les acteurs et le système en cas
d’authentification.
Conclusion
Dans ce chapitre nous avons analysé les besoins du projet ensuite nous avons spécifié les différents
objectifs et définir les acteurs ainsi que les diagrammes de cas d’utilisation et le diagramme de séquence
général. Dans le chapitre suivant on va entamer la phase de conception de système à réaliser.
Sequence Diagram System
Gérer Mise à jour()
Gérer Changement()
Gérer Recouvrement()
Gérer Réstauration()
Gérer Sauvegarde()
Gérer Batch()
Accée page d'accueil()
Authentification()
Utilisateur
Système
Gérer Mise à jour()
Gérer Changement()
Gérer Recouvrement()
Gérer Réstauration()
Gérer Sauvegarde()
Gérer Batch()
Accée page d'accueil()
Authentification()

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
36
Chapitre 3 :
Conception détaillée

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
37
Introduction
La conception permet d’acquérir une compréhension approfondie des contraintes liées au langage de
programmation, à l’utilisation des composants et au système d’exploitation. Elle détermine les
principales interfaces et les transcrit à l’aide d’une notation commune en donnant un point de départ à
l’implémentation
En effet dans ce chapitre, nous allons présenter la conception détaillée du système en commençons par
la conception dynamique et en fini par la conception statique en se basent sur les différents diagrammes.
I. Conception de l’aspect dynamique
Points de départ : Modèles de la vue cas d’utilisation.
Objectif : modéliser les algorithmes des cas d’utilisation.
Après la construction des diagrammes de cas d’utilisation dans le chapitre précédent, la modélisation
des aspects dynamiques répond globalement à la question « Comment est spécifié le comportement du
système, c’est-à-dire comment sont spécifiés les algorithmes des cas d’utilisation ? »
Afin de répondre à cette question, nous allons présenter dans ce qui suit les diagrammes d’activité
d’authentification et de la gestion des batchs pour le cas d’administrateur, et les diagrammes de
séquence pour chaque cas d’utilisation dans notre système.
1. Diagrammes d’activités
Un diagramme d'activités visualise un graphe d'activités qui modélise le comportement interne d'une
méthode (une réalisation d'une opération), d'un cas d'utilisation ou plus généralement d'un processus
impliquant un ou plusieurs classificateurs (classes / cas d'utilisation / ...).
Un diagramme d'activités représente l'état d'exécution d'un mécanisme, sous la forme d'un déroulement
d'étapes regroupées séquentiellement dans des branches parallèles de flots de contrôle. Il ne représente
ni la collaboration ni le comportement des objets. Il est utile pour la représentation des processus
métiers et les cas d'utilisation.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
38
Le diagramme d'activités comprend :
✓ Des activités (une activité= une étape d'exécution, état-activité). Une activité représente une
exécution d'un mécanisme, un déroulement d'étapes séquentielles. Le passage d'une activité
vers une autre est matérialisé par une transition ;
✓ Des transitions qui sont automatiques entre activités, il est inutile également de préciser les
événements. Les transitions sont déclenchées par la fin d'une activité et provoquent le début
immédiat d'une autre.
1.1. Diagramme d’activités Authentification
Figure 11: Diagramme d’activité Authentification.
Ce diagramme teste la validité du login et mot de passe, s’ils sont corrects, il ouvre la page d’accueil,
sinon un retour vers la page d’authentiﬁcation sera eﬀectué avec un message d’erreur.
[Login ou mot de
passe éroné]
[Annuler]
[Login ou mot de
passe validé]
saisir Login et mot de
passe
Ouvrir la page d'acceuil
.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
39
1.2. Diagramme d’activités Gérer Utilisateur
Figure 12: Diagramme d’activité Gérer Utilisateur pour l’administrateur.
3. Diagrammes de séquence
Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le
système selon un ordre chronologique dans la formulation UML. Ces communications entre les classes
sont reconnues comme des messages. Le diagramme des séquences énumère des objets
horizontalement, et le temps verticalement. Il modélise l’exécution des diﬀérents messages en fonction
du temps.
Pour réaliser les diagrammes des séquences nous avons utilisé des opérateurs d’interactions.
Un opérateur d’interaction déﬁnit le type d’un fragment composé.
Les opérateurs d’interaction que nous avant utilisés dans les diagrammes de séquences sont :
✓ Référence (réf) : cet opérateur désigne que le fragment fait référence à un cas vue
[identifiants incorrects]
[Annulation]
[identifiants corrects]
Authentification
..
Gérer Utilisateur
.
Modifier
Connsulter
Ajouter
Valider Annuler
Supprimer

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
40
précédemment.
✓ Alternative(Alt) : cet opérateur désigne que le fragment composé représente un choix de
comportement. Une opérande d’interaction au maximum sera choisie. L’opérande choisi doit
avoir une expression de garde implicite ou explicite qui a la valeur ”true” à ce point de
l’interaction.
Les figures (13) jusqu’à (17) présenterons respectivement les diagrammes de séquence :
authentification, ajouter/modifier/supprimer un objet, et finalement la création de reporting.
2.1. Diagramme de séquence authentification
Figure 13: Diagramme de séquence Authentification.
• Le système affiche l'interface d'authentification ;
• L'utilisateur introduit un login et un mot de passe et valide ;
• Le système vérifie le login et le mot de passe ;
• Si les données saisies sont correctes, le système affiche l'interface de l'application, sinon le
système demande de répéter la saisie de login et mot de passe.
Sequence Diagram Authentification
_Affichage de la page d'accueil
Vérifier(Login,Password)
Connexion()
AfficheMessageErreur()
AccèsNonAutoriser()
AccèsAutoriser()
Saisir(Login,Password)
Utilisateur
Page
Authentification Base de donnéePage d'accueil
Utilisateur existe
sinon
alt
_Affichage de la page d'accueil
Vérifier(Login,Password)
Connexion()
AfficheMessageErreur()
AccèsNonAutoriser()
AccèsAutoriser()
Saisir(Login,Password)

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
41
2.2. Diagramme de séquence ajouter utilisateur
Figure 14: Diagramme de séquence Ajouter Utilisateur
• Après une authentification réussite, la page d’acceuil sera affichée ;
• L’administrateur choisit dans le menu l’option Gérer Utilisateur ;
• La liste des utilisateurs sera affichée ;
• L’administrateur choisit l’option Créer Utilisateur ;
• L' administrateur saisit les informations relative à l’utilisateur et valide.
• Si les données saisies sont complète l’utilisateur ajouté sera affiché dans la liste sinon
un message d’erreur sera affiché dans le cas ou les champs non complèts.
Sequence Diagram Add User
MessageConfirmation()
ChoisirGestionUtilisateur()
DemandeListeUtilisateur()
ListeUtilisateur()
AfficheListe()
ChoisirCréer()
AfficheFormulaireAjout()
RemplirChamps()
Valider()
Verifier Champs()
AfficheMessageEreur()
EnregistrerUtilisateur()
ListeUtilisateurActualisé()
Administrateur
Page d'acceuil Gestion Utilisateur Base Donnée
ref
Sequence Diagram
Authentification()
Champs manquants
sinon
alt
ChoisirGestionUtilisateur()
DemandeListeUtilisateur()
ListeUtilisateur()
AfficheListe()
ChoisirCréer()
AfficheFormulaireAjout()
RemplirChamps()
Valider()
Verifier Champs()
EnregistrerUtilisateur()
ListeUtilisateurActualisé()

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
42
2.3. Diagramme de séquence modifier Batch
Figure 15: Diagramme de séquence Modifier Batch.
Ce diagramme est utilisé pour présenter les interactions entre les acteurs (l’administrateur ou
l’opérateur) et l’application en cas de modifier Batch .
Sequence Diagram Edit Batch
ChoisirGestionBatch()
DemandeListeBatch()
ListeBatch()
AfficheListe()
ChoisirModifierr()
AfficheFormulaireModification()
RemplirChamps()
Valider()
Verifier Champs()
EnregistrerBatch()
ListeBatchActualisé()
Administrateur/Opérateur
Page d'acceuil Gestion Batch Base Donnée
ref
Sequence Diagram
Authentification()
Champs manquants
sinon
alt
ChoisirGestionBatch()
DemandeListeBatch()
ListeBatch()
AfficheListe()
ChoisirModifierr()
AfficheFormulaireModification()
RemplirChamps()
Valider()
Verifier Champs()
EnregistrerBatch()
ListeBatchActualisé()

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
43
2.4. Diagramme de séquence supprimer changement
Figure 16: Diagramme de séquence Suppression changement.
• Après une authentification réussite, la page d’acceuil sera affichée ;
• L’administrateur choisit dans le menu l’option Gérer Changement ;
• La liste des changements sera affichée;
• L’administrateur sélectionne l’enregistrement à supprimer ;
• L’administrateur choisit l’option à supprimer ;
• Après la supression de l’enregistrement , la liste du changements sera affichée ;
Sequence Diagram Delete Changement
ListeChangementActualisé()
SupprimerChangement()
Supprimer
SelectionnerEnregistrementSupprimer()
AfficheListe()
ListeChangement()
DemandeListeChangement()
ChoisirGestionChangement()
Administrateur
Page d'acceuil Gestion Changement Base Donnée
ref
Sequence Diagram
Authentification()
ListeChangementActualisé()
SupprimerChangement()
Supprimer
SelectionnerEnregistrementSupprimer()
AfficheListe()
ListeChangement()
DemandeListeChangement()
ChoisirGestionChangement()

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
44
2.5. Diagramme de séquence Reporting
Figure 17: Diagramme de séquence Reporting.
• Après une authentification réussite, la page d’acceuil sera affichée.
• L’utilisateur choisit dans le menu batch puis l’option Reporting ;
• La page de reporting sera affichée ;
• L’utilisateur remplit les champs : entité, nom batch , et les dates d’execution maximale et
SequenceDiagramReportingBatch
SaisirEntite
TéléchargerRapport
Télécharger
ViderChampsRempli
Initialiser
AfficherRapport
GenererChart
ChoisirReporting
Valider
SaisirDateMax
SaisirDateMin
Affiche()
EnvoyerDonnee
RecupereDonnée
ChoisirGestionBatch
Utilisateur
Page d'acceuil Page Reporting Batchs Base Donnée
ref
Sequence Diagram
Authentification()
Initialer
Télécharger
alt
SaisirEntite
TéléchargerRapport
Télécharger
ViderChampsRempli
Initialiser
AfficherRapport
GenererChart
ChoisirReporting
Valider
SaisirDateMax
SaisirDateMin
Affiche()
EnvoyerDonnee
RecupereDonnée
ChoisirGestionBatch

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
45
minimale puis il valide .
• Si les données saisies sont correctes, le système génère les charts, sinon le système initialise les
paramètres et vide les champs.
Note : c’est les mêmes étapes pour les diagrammes de séquence de la gestion des autres taches.
II. Conception de l’aspect statique
Après l’expression des besoins exprimés sous la forme de fonctionnalités modélisées comme des cas
d’utilisation et les diagrammes d’activités et de séquence, nous pouvons modéliser la structure logique
du système, c’est-à-dire les aspects statiques du système. Cette modélisation est en grande partie
effectuée dans des diagrammes de classes. Le contenu principal de cette section est donc la
présentation des éléments de modélisation du diagramme de classes.
1. Description des classes
Classe = famille d’objets ayant les mêmes caractéristiques et le même comportement.
Attributs = caractéristiques (données membres, informations, propriétés).
Opérations = comportement (méthodes, fonctions, procédures, messages, services).
Les classes décrivent les différents types d’objets que le système possède.
Une classe est un type de quelque chose. Vous pouvez penser à une classe comme à un modèle au
sens patron) à partir duquel les instances ou objets conformes au type défini par la classe sont créés.
Concrètement, une classe, c'est quoi ?
Une classe est une entité regroupant des variables et des fonctions. Chacune de ces fonctions aura
accès aux variables de cette entité.
La notation UML autorise à représenter une classe uniquement avec son nom, ou avec son nom et ses
attributs, ou avec son nom et ses opérations, ou encore avec les trois caractéristiques. Les classes
contiennent la définition des objets que l'on va créer par la suite, la classe contient donc le plan de
fabrication d'un objet et on peut s'en servir autant qu'on veut afin d'obtenir une infinité d'objets.
2. Diagramme de classes
Un diagramme de classe constitue l’un des pivots essentiels dans la modélisation avec le PU. Il
permet de définir quelles seront les composantes du système final en mettant en évidence les
différentes classes d’un système et en modélisant les relations qui les associent, les interactions et les

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
46
hiérarchisations.
Figure 18: Diagramme de classes.
En s’appuyant sur la ﬁgure (18), nous avons distingué les classes suivantes :
1..1 0..*
1..1
0..* 1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
0..*
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
Entite
-
-
id_E
libele
: long
: String
DefalutBatch
-
-
-
-
-
id_DB
nom
usage
date_deb_prg
date_fin_prg
: long
: String
: String
: Date
: Date
Batch
-
-
-
-
-
-
-
-
-
-
-
id_B
nom
usage
date_suivi
resultat
date_deb_prg
date_fin_prg
date_deb_exc
date_fin_exc
duree
observation
: long
: String
: String
: Date
: String
: Date
: Date
: Date
: Date
: double
: String
Utilisateur
-
-
-
-
-
-
id_U
nom
prenom
login
password
privilege
: long
: String
: String
: String
: String
: String
MiseAjour
-
-
-
-
-
-
-
-
-
-
id_MJ
sujet
priorite
categorie
dateechance
type
version_maj
description
formulaire
observation
: long
: String
: String
: String
: Date
: String
: String
: String
: String
: String
Plateforme
-
-
id_P
libele
: long
: String
Changement
-
-
-
-
-
-
-
-
-
-
-
-
-
id_Ch
sujet
categorie
statut
site
priorite
datedebut
dateechance
soumis_par
impact_infra
impact_ressource
formulaire
observation
: long
: String
: String
: String
: String
: String
: Date
: Date
: String
: String
: String
: String
: String
DefaultRecouvrement
-
-
id_DRc
libele
: long
: String
ReseauRecouvrement
-
-
id_RR
libele
: long
: String
TypeRecouvrement
-
-
id_TR
libele
: long
: String
Recouvrement
-
-
-
-
-
-
-
-
-
-
-
id_Rc
libele
date_suivi
resultat
date_ext
nbr_trs
valeur
nbr_rejet
observation
type
reseau
: long
: String
: Date
: String
: Date
: long
: double
: long
: String
: String
: String
Sauvegarde
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
id_Sv
libele
site
SysExp
date_suivi
resultat
observation
date_deb_prog
date_fin_prog
date_deb_exc
date_fin_exc
duree
pathImage
prodsau
support
methode
: long
: String
: String
: String
: Date
: String
: String
: Date
: Date
: Date
: Date
: long
: String
: String
: String
: String
Restauration
-
-
-
-
-
-
-
-
-
-
-
-
-
id_Res
Libele
site
SysExp
date_Restauration
date_Sauvegarde
resultat
pathImage
duree
observation
prodsau
Support
methode
: long
: short
: String
: String
: Date
: Date
: String
: String
: long
: String
: String
: String
: String
SystemeExploitation
-
-
id_SE
libele
: long
: String
MethodeSauvegarde
-
-
id_MSv
Libele
: long
: String
DafaultSauvegarde
-
-
-
-
-
-
id_DSv
libele
SysExp
site
date_deb_prg
date_fin_prog
: long
: String
: String
: String
: Date
: Date
SupportSauvegarde
-
-
id_SSv
libele
: long
: String
ProduitSauvegarde
-
-
id_PSv
nom_prd_svg
: long
: String
LogicielExploite
-
-
id_LExp
libele
: long
: String
TypeProdSauvegarde
-
-
id_TpSv
libele
: Long
: String

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
47
✓ Utilisateur : c’est la classe qui représente un utilisateur de l’application qui est soit un
administrateur, un opérateur ou un observateur ;
✓ Entité : c’est la classe qui représente l’organisme qui encadre ou réglemente la conduite de ses
membres (Département système d’information, Service administration de base de donnée,
Service administration de système, Division MDI…).
✓ Batch : c’est la classe qui représente une tâche planifier effectuer automatiquement ;
✓ Recouvrement : c’est la classe qui représente l’ensemble des démarches effectuées par la
RADEEMA pour récupérer les valeurs (sommes) qui lui sont dues par le client à travers des
réseaux de recouvrement;
✓ Plateforme : c’est la classe qui représente les équipements matériels (routeur switch, serveur…)
ou bien les plateformes logicielles (OS, ERP…) ;
✓ Sauvegarde : c’est la classe qui représente une tâche planifier qui permet de sauvegarder un
produit de type spécifié sur un support (disque, USB, bande…) en utilisant une méthode de
sauvegarde définie (VeemBackup…) ;
✓ Restauration: c’est la classe qui représente la restauration d’un produit sauvegardé ;
✓ Changement : c’est la classe qui représente le changement d’une plateforme technique ;
✓ Mise à jour: c’est la classe qui représente la mise à jour d’une plateforme technique ;
✓ DefaultBatch / DefaultRecouvrement / DefaultSauvegarde: des classes qui représentes les
paramètres initiaux des classes Batch/Recouvrement/Sauvegarde.
Conclusion
Dans ce chapitre nous avons réalisé la partie la plus importante qui conduit à la réussite de notre
projet qu’est la conception détaillée avec ses différents aspects, nous allons entamer la partie
réalisation en se basant sur cette chapitre.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
48
Chapitre 4 :
Etude technique &
Réalisation

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
49
Introduction
Après avoir élaboré la conception de notre application, nous abordons dans ce chapitre le dernier
volet de ce rapport, qui a pour objectif d'exposer la phase de réalisation. Cette dernière est considérée
comme étant la concrétisation finale de toute la méthode de conception. Nous menons tout d’abord
une étude technique où nous décrivons les ressources logicielles utilisées dans le développement de
notre projet. Nous présentons en premier lieu notre choix de l’environnement de travail, où nous
spécifions l’environnement matériel et logiciel que nous avons utilisé pour réaliser notre application
puis nous détaillons l’architecture, aussi nous présentons quelques interfaces réalisées pour illustrer
le fonctionnement de quelques activités du système.
I. Etude technique
L'étude technique est une phase d'adaptation de conception à l'architecture technique. Elle a pour
objectif de décrire au plan fonctionnel la solution à réaliser d'une manière détaillée ainsi que la
description des traitements. Cette étude, qui suit l'étude détaillée, constitue le complément de
spécification informatique nécessaire pour assurer la réalisation du futur système. Cette étude permet
également de déterminer :
✓ La structure informatique de la base de données ;
✓ L'architecture des programmes ;
✓ La structure de chaque programme et l'accès aux données.
1. Environnement de réalisation
1.1. Matériels de base
Le développement de l’application est réalisé via deux ordinateurs portables ayant les caractéristiques
suivantes :

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
50
Caractéristique Hp Acer
Processeur Intel® Core™, i3- 5005U CPU
@2.00GHz ;
Intel Pentium® CPU 2020M
2.40GHz
Disque Dur 500 Go. 500 Go
RAM 4.00 Go ; 2.00 Go
Système d’exploitation Windows 10 Windows 10
Table 4 : Matériel de base.
1.2. Choix des langages de développement :
Java Entreprise Edition (JEE)
Java EE (Java Enterprise Edition) est une spécification pour la technique Java d’Oracle plus
particulièrement destinée aux applications d’entreprise. Ces applications sont considérées dans une
approche multi-niveaux. Dans ce but, toute implémentation de cette spécification contient un ensemble
d’extensions au Framework Java standard (JSE, Java Standard Edition) afin de faciliter notamment la
création d’applications reparties.
Notre application a été programmée en suivant la spécification Java EE 7.
JSP
JSP est l’acronyme de Java Server Page. C’est une technologie java qui permet la génération des pages
web dynamiques. La technologie JSP permet de séparer la présentation sous forme de code HTML et les
traitements sous formes de classes.
La technologie JSP possède plusieurs avantages dont nous pouvons situer:
✓ L'utilisation de Java par les JSP permet une indépendance de la plate-forme d'exécution mais
aussi du serveur web utilisé ;
✓ La séparation des traitements et de la présentation : la page web peut être écrite par un designer
et les tags Java peuvent être ajoutés ensuite par le développeur ;
✓ Les traitements peuvent être réalisés par des composants réutilisables (des Java beans).
✓ Les JSP sont basées sur les servlets : tout ce qui est fait par une servlet pour la génération de pages
dynamiques peut être fait avec une JSP.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
51
JavaScript :
Le JavaScript est un langage informatique utilisé dans le développement des pages web. Ce langage a la
particularité de s'activer sur le poste client, Autrement dit, c’est votre ordinateur qui va recevoir le code
et qui devra l'exécuter. C'est en opposition à d'autres langages qui sont activé côté serveur. L'exécution
du code est effectué par votre navigateur internet tel que Firefox ou Internet Explorer.
CSS (Cascading Style Sheet-feuille de style en cascade) :
CSS est l’acronyme de Cascading Style Sheets, est un langage de feuille de style utilisé pour décrire la
mise en forme d'un document écrit avec un langage de balisage. Il permet aux concepteurs de contrôler
l’apparence et la disposition de leurs pages web.
XHTML (Extensible HyperText Markup Language)
XHTML est un langage de balisage servant à écrire des pages pour le World Wide Web. Conçu à
l'origine comme le successeur de HTML, XHTML se fonde sur la syntaxe définie par XML, plus récente,
mais plus simple que celle définie par SGML sur laquelle repose HTML. Il s'agissait en effet à l'époque
de tirer parti des bénéfices techniques attendus de la simplification offerte par XML. Notre choix est
justifié par les raisons suivantes :
✓ C'est la version la plus récente et celle qui a le plus d'avenir ;
✓ Si sa syntaxe est plus précise, elle est également plus logique, et donc plus facile à
comprendre ;
✓ Notons que les différences de syntaxe entre HTML et XHTML sont minimes et qu'il est facile
de passer de l'un à l'autre.
1.3. Choix de base de donnée :
Oracle
Un Système de Gestion de bases de données (SGBD) est un logiciel qui prend en charge la
structuration, le stockage, la mise à jour et la maintenance des données ; c’est l’interface entre la base
de données et les utilisateurs ou leurs programmes.
Pour la création de notre base nous avons installé Oracle 11g Express Edition. Il s’agit, en fait, d’un

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
52
système de gestion de base de données relationnelle d'entrée de gamme et à petite empreinte mémoire.
Il est libre de développer, déployer et distribuer, rapide à télécharger, et simple à administrer.
1.4. Choix d’environnement de développement
NetBeans
NetBeans est un environnement de développement intégré (EDI), placé en open source par Sun en Juin
2000 sous licence CDDL (Common Développent and Distribution Licence) et GPLv2. Il comprend
toutes les caractéristiques d’un IDE moderne (éditeur en couleur, projets multi-langage, refactoring,
éditeur graphiques d’interfaces et de pages web).
Conçu en Java (qui est multiplateforme), NetBeans est disponible sous Windows, Linux, Solaris (sur
x86 et SPARC), MAC OS X ou sous une version indépendante des systèmes d’exploitation (requérant
la machine virtuelle de Java, la JVM). CDDL GPLv2 IDE SPARC JVM
Pour notre application, nous avons utilisé la version 8.0.2 de NetBeans.
Les choix que nous avons dû faire ont été essentiellement pour les outils de travail étant donné que les
technologies étaient connues ou imposées, c’est pour cela que nous avons opté pour les deux IDE Eclipse
et NetBeans.
Et finalement nous avons choisi NetBeans pour son aptitude à gérer un serveur d’application et à faire
de la conception web en Java, en mode visuel (contrairement à Eclipse qui ne le permet qu’en textuel).
1.5. Choix d’architecture
Une architecture est un modèle générique et conceptuel qui se rapporte à un sujet et qui représente
la fonctionnalité, la structure, le positionnement, l’interrelation des diﬀérents types d’éléments
(hardware, logiciels, infrastructure) qui la compose l'architecture physique élabore des solutions
concrètes permettant d'exécuter l'architecture fonctionnelle du système.
1.5.1. Architecture 3 tiers
Des modèles standards de répartition de niveaux ont été définis dans les projets au fur et à mesure
de l’évolution des capacités matérielles et des besoins.
✓ Modèle à 1 tiers : Le modèle à 1 niveau (ou tiers) correspond à un binaire dans lequel
s’exécutent toutes les couches, de la présentation à la persistance. C’est l’exemple de

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
53
l’application utilisée en monoposte, les données sont stockées sur un fichier local ou partagées
sur un serveur de fichiers.
✓ Modèle à 2 tiers : Le modèle à 2 niveaux, encore appelé « client/serveur », repose sur
l’utilisation de moteurs de bases de données relationnelles. Ces moteurs permettent de distribuer
la gestion de la persistance sur un serveur.
✓ Modèle à 3-tiers : Dans l'architecture à 3 niveaux (appelées 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 un navigateur web (Internet Explorer, Google
Chrome.);
• Le serveur d'application (appelé aussi middleware): le serveur chargé de fournir la
ressource mais faisant appel à un autre serveur. Dans notre cas c’est Glass Fish ;
• Le serveur secondaire (généralement un serveur de base de données), fournissant un
service au premier serveur. Pour notre application, nous avons choisi le serveur de base
de donnée Oracle.
Architecture adoptée :
Figure 19: Modèle physique 3 tiers [1].
Les avantages de l'architecture 3-tiers sont principalement au nombre de quatre:
✓ Les requêtes clients vers le serveur sont d'une plus grande flexibilité que dans celles de
l'architecture 2- tiers basées sur le langage SQL ;
✓ Cette flexibilité permet à une entreprise d'envisager dans le cadre d'une architecture 3-
tiers une grande souplesse pour l'introduction de toutes nouvelles technologies;

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
54
✓ D'un point de vue développement, la séparation qui existe entre le client ;
✓ Le serveur et le SGBD permet une spécialisation des développeurs sur chaque tiers de
l'architecture.
1.5.1.1. Serveur d’application utilisé.
GlassFish
GlassFish est le nom du serveur d'applications Open Source Java EE 5 et qui sert de fondation au produit
Sun Java System Application Server de Sun Microsystems. Pas n’importe quel serveur d’ailleurs : il
s’agit du serveur de référence, celui qui implémente à la lettre les spécifications Java EE, puisque c'est
Oracle - la maison mère de tout l'écosystème Java - qui édite ce serveur.
GlassFish est désormais le serveur de référence Java EE développé par Oracle en forte progression ces
dernières années. GlassFish utilise en standard le moteur de persistance et propose plusieurs outils et
services afin de faciliter la création et la maintenance d’applications Web.
GlassFish est principalement formé des composants suivants :
• Un serveur Web nommé Grizzly, permettant de répondre aux requêtes statiques des clients
(pages HTML, images, JavaScripts...) ;
• Un serveur conteneur de Servlets, pages JSP ou JSF ;
• Un conteneur d’Enterprise JavaBean permettant la gestion des session beans, entity beans et
message-driven beans ;
• Une implémentation de l’API de persistance JPA basée sur EclipseLink.
1.5.1.2. Java Persistence API
JPA
Littéralement « Java Persistence API », il s’agit d’un standard faisant partie intégrante de la plate-
forme Java EE, une spécification qui définit un ensemble de règles permettant la gestion de la
correspondance entre des objets Java et une base de données, ou autrement formulé la gestion de la
persistance. Ce mécanisme qui gère la correspondance entre des objets d’une application et les tables
d’une base de données se nomme ORM, pour « Object-Relational Mapping ».

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
55
JPA masque intégralement le moyen de stockage au développeur, en lui permettant de travailler
uniquement sur un modèle objet. C'est le Framework qui se charge dans les coulisses de dialoguer avec
la BDD pour assurer la correspondance avec le modèle.
Figure 20: Rôle de JPA [2].
1.5.2. Architecture MVC
Dans la réalisation de notre projet, nous avons opté pour une architecture MVC afin de garantir une
assurance de la maintenabilité, la modularité de l’application et la rapidité de développement.
MVC littéralement Modèle Vue Contrôleur est une architecture qui organise l'interface Homme-
Machine d'une manière à ce que le développement puisse se faire en couches indépendantes. Il impose
la séparation entre les données, la présentation et les traitements, ce qui donne trois parties
fondamentales dans l'application finale: le modèle de données, le contrôleur et la vue.
✓ Couche Modèle : permet d'enregistrer les données, de les récupérer, de les lister, de les
supprimer, et de les mettre à jour.
✓ Couche Vue : la vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première
tâche est de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes
les actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons, etc.). Ces différents
événements sont envoyés au contrôleur, elle se contente d'afficher les résultats des traitements
effectués par le modèle et d'interagir avec l'utilisateur.
✓ Couche Contrôleur : le contrôleur prend en charge la gestion des événements de synchronisation
pour mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de
l'utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des
données, le contrôleur demande la modification des données au modèle, et ce dernier notifie la
vue que les données ont changée pour qu'elle se mette à jour.
Au sein de l’architecture 3 tiers, l’architecture MVC peut être représentée comme suit ;

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
56
Figure 21: Modèle MVC [3].
1.6. Choix de Framework
Prime Faces
JavaServer Faces (abrégé JSF) est un Framework basé sur la notion de composants et destiné au
développement d’applications WEB. JSF est techniquement comparable à Swing ou SWT sauf qu’ils
sont utilisés pour le développement d’applications de bureau. En JSF et en Swing, l’état d’un composant
(représenté par un objet java) est enregistré lors du rendu de la page, pour être ensuite restauré au retour
de la requête.
L’objectif de JSF est de faciliter le développement des interfaces utilisateurs des applications WEB, or
les deux composants standards de JSF (html et core) s’avèrent limités et insuffisants pour le
développement d’applications d’entreprise. Des jeux de composants additionnels qui offrent de
nouveaux composants plus riches sont indispensables pour le développement en JSF, PrimeFaces en
offre un qui a prouvé son efficacité.
L’implémentation de la technologie JSF que nous avons utilisé pour notre application est donc Prime -
Faces (version 5.0).
II. Structure et maquette de l’application
Le schéma ci-après, présenté dans la ﬁgure (22) récapitulée l’organisation des pages de l’application
(Diagramme de navigation).

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
57
Figure 22: Structure de l’application pour l’administrateur.
Par ailleurs, nous avons aussi procéder après la spéciﬁcation des besoins vue précédemment et en
suivant la structure présentée dans la ﬁgure (22) un ensemble de maquettes élaborées pour
l’administrateur.
Note : Pour l’opérateur, il n’a pas le droit de gérer les utilisateurs et d’où l’absence de l’option Gérer
Utilisateur, la même structure est adaptée pour l’observateur.
Authentification
Acceuil
Batch
Paramètrage
Param.d'initialisation
ReportingGérerBatchs
Sauvegardeetrestauration
Gérer
sauvegardes
Gérer
restaurations
Paramètrage.
Param.d'initialisation.ProduitssauvegardésLogicielsexploitésTypesprodsauvegardéMéthodesdesauvegardeSupportdesauvegardeAssociationsauvegardeSystèmed'exploitation
Reporting.
Recouvrement
Gérer
Recouvrement
RT
Paramètrage..
GérerréseauxTyperecouvrement
Reporting..
ChangementsetMàj
GérerchangementsGérermàj
Rapport
Résumé
Utilisateurs
Gérer
Organisation
Gérer
Connexions

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
58
III. Les composantes applicatives réalisées
Ce paragraphe sera réservé pour présenter la majorité des scénarios possibles dans notre application
sous forme de captures écrans.
1. Interface de connexion
L’utilisateur de l’application doit tout d’abord s’authentifier, il ne peut accéder au reste de
l’application que si son identificateur et son mot de passe sont reconnus sinon le système affiche un
message d’erreur .
Figure 23: Authentification.
Cette figure donne l’aperçu d’authentification de chaque utilisateur après l’ouverture de l’application.
L’utilisateur de l’application doit tout d’abord s’authentifier, il ne peut accéder au reste de
l’application que si son identificateur et son mot de passe sont reconnus sinon le système affiche un
message d’erreur.
Une fois l’authentification s’est déroulée avec succès, on donne accès à l’interface qui concerne
l’utilisateur authentifié.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
59
Figure 24: Erreur d’authentification 1.
Le cas d’échec d’authentification 1 est représenté par la figure ci-dessus où on affiche un message
pour annoncer qu’il faut remplit tous les champs d’authentification.
Figure 25: Erreur d’authentification 2.
Le cas d’échec d’authentification 2 est représenté par la figure ci-dessus où on affiche un message
pour annoncer qu’il faut vérifier les informations d’authentification.
2. Interfaces d’accueil
Dans l’application, on a deux interfaces qui se différent selon la catégorie de l’utilisateur.
2.1. Page d’accueil (Acteur : Administrateur)
Figure 26: Accueil d’administrateur.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
60
2.2. Page d’accueil (Acteur : Opérateur, Observateur)
Figure 27: Accueil d’opérateur et d’observateur.
La page d’accueil présente les menus déroulants horizontal et vertical permettent l’accès aux divers
services de l’application selon l’acteur authentifié, La figure (27) précise l’absence de l’option Gérer
Utilisateur pour les deux utilisateurs opérateurs et observateur.
3. Menus
Figure 28: Menu Batch.
Le menu Batch nous donne la main pour gérer les batchs, les paramètres initiaux des batchs et de
générer le graphe (Chart) des batchs filtrés.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
61
Figure 29: Menu sauvegarde et restauration.
Ce menu nous donne la main pour gérer les sauvegardes, les restaurations, les paramètres initiaux des
sauvegardes et de générer le graphe(Chart) des sauvegardes filtrées.
Figure 30: Menu recouvrement.
Ce menu nous donne la main pour gérer les recouvrements, les paramètres initiaux des recouvrements,
les réseaux des recouvrements, les types des recouvrements et de créer le Reporting des recouvrements
concernés.
Figure 31: Menu changement et mise à jour.
Le menu changement et mise à jour permet de gérer les changements et les mises à jour.
Figure 32: Menu utilisateurs.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
62
Le menu utilisateur permet de gérer les connexions et les organisations.
Figure 33: Menu Administration pour l’utilisateur.
Le menu Administration permet à l’utilisateur connecté de changer son mot de passe et de se
déconnecter.
4. Menu utilisateurs
4.1 Liste des utilisateurs
Figure 34: Liste des utilisateurs.
Cette fenêtre permet à l’administrateur de l’application d’ajouter, modifier et supprimer les utilisateurs
et affiche la liste des utilisateurs.
4.2 Ajouter utilisateur
Figure 35: Ajouter utilisateur.
Cette fenêtre permet à l’administrateur de l’application d’ajouter un nouvel utilisateur.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
63
4.3 Modifier utilisateur
Figure 36: Modifier utilisateur.
Cette fenêtre permet à l’administrateur de l’application de modifier un nouvel utilisateur.
4.4 Affiche détails
Figure 37: Détails d’un utilisateur.
Cette fenêtre affiche les détails d’un utilisateur.
4.5 Liste des organisations
Figure 38: Liste des organisations.
Cette fenêtre permet à l’administrateur de l’application d’ajouter, modifier et supprimer les

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
64
organisations et affiche la liste des organisations.
5. Menu Batch
5.1 Liste des paramètres initiaux des batchs
Figure 39: Liste des paramètres initiaux des batchs.
Cette fenêtre affiche la liste des paramètres initiaux des batchs et permet l’utilisateur de l’application
d’ajouter, modifier et supprimer des paramètres initiaux.
5.2 Liste des batchs
Figure 40: Liste des batchs.
Cette fenêtre affiche la liste des batchs et permet l’utilisateur de l’application d’ajouter, modifier et
supprimer les batchs et d’exporter sa liste vers un fichier Excel ou PDF.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
65
5.2 Créer un nouveau batch
Figure 41: Ajouter batch.
Cette fenêtre permet d’ajouter un nouvel batch.
5.3 Chercher des Batchs
Figure 42: Chercher Batchs.
Cette fenêtre permet à l’utilisateur de l’application d’afficher la liste des batchs spécifiés entre deux
dates définies d’un résultat précisée et de l’exporter vers un fichier Excel ou PDF.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
66
5.4 Générer un graphe des Batch
Figure 43: Graphe des batchs.
Cette fenêtre permet à l’utilisateur de l’application de générer le graphe de taux de réussite des batchs
spécifiés d’une entité (organisation) entre deux dates définies.
5.4 Affiche les détails d’un batch
Figure 44: Affiche les détails d’un batch.
Cette fenêtre affiche les détails d’un batch.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
67
6. Menu sauvegarde
6.1 Liste des paramètres initiaux des sauvegardes
Figure 45: Liste des paramètres initiaux des sauvegardes.
Cette fenêtre affiche la liste des paramètres initiaux des sauvegardes et permet à l’utilisateur de
l’application d’ajouter, modifier et supprimer des paramètres initiaux.
6.1 Modifier Sauvegarde
Figure 46: Modifier sauvegarde.
Cette fenêtre permet de modifier une sauvegarde.

Rapport de stage
-----------------------------------------------------------------------------------------------------------------
68
6.3 chercher sauvegarde
Figure 47: Chercher sauvegarde.
Cette fenêtre permet à l’utilisateur de l’application d’afficher la liste des sauvegardes avec un résultat
et un site spécifié entre deux dates définies et de l’exporter vers un fichier Excel ou PDF.
6.4 chercher des restaurations
Figure 48: Chercher restauration.
Cette fenêtre permet à l’utilisateur de l’application d’afficher la liste d’une restauration avec un résultat
et un site spécifié entre deux dates définies et de l’exporter vers un fichier Excel ou PDF.

Bachelor's degree final project

Bachelor's degree final project

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Bachelor's degree final project

Similaire à Bachelor's degree final project (20)

Bachelor's degree final project