Gestion des interventions fluides Ikbel BOUDHIEF .pdf



Nom original: Gestion des interventions fluides Ikbel BOUDHIEF.pdfTitre: INTRODUCTION GENERALEAuteur: del

Ce document au format PDF 1.5 a été généré par Conv2pdf.com, et a été envoyé sur fichier-pdf.fr le 27/03/2016 à 20:20, depuis l'adresse IP 197.19.x.x. La présente page de téléchargement du fichier a été vue 862 fois.
Taille du document: 3.2 Mo (81 pages).
Confidentialité: fichier public


Aperçu du document


Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université de Carthage
Faculté des Sciences Economiques et de Gestion de Nabeul

Rapport de Stage

Présenté en vue d'obtenir le diplôme de la LICENCE APPLIQUEE
SPECIALITE : Informatique Appliquée à la Gestion

Elaboré par

Ikbel BOUDHIEF

Conception et développement d’une application WEB de gestion des
interventions dans le domaine de gestion des fluides (cas de la gestion
de l’EAU par la SONEDE)
Réalisé au sein de

Bonne Gouvernance Informatique

Encadré par
Encadrant(s) universitaire(s)

Encadrant(s) professionnel(s)

Mlle. Amel KHALFALLAH

Mr. Riadh ARFAOUI

Année universitaire
2014 - 2015

i

Dédicaces

Je dédié ce travail :
À mon père Mohamed & ma mère Zina. Vous êtes pour moi
une source de vie, le symbole de la bonté par excellence, la source
de tendresse et l’exemple du dévouement qui n’a pas cessé de
m’encourager et de prier car sans vos sacrifices, votre tendresse et
votre affection je ne pourrais arriver jusqu’au bout. Que Dieu vous
garde.
À mes frères & mes sœurs qui ont été toujours présent pour
moi.
A mes amis avec qui j’ai partagé des moments des plus
agréables.
A tous ceux qui me connaissent, qui sont chères, proches de
mon cœur, et à tous ceux qui m’aiment et qui aurait voulu
partager ma joie …

Ikbel…

ii

Remerciements

Avant de présenter ce rapport, Je remercie ALLAH le tout
puissant de m’avoir donné le courage et la volonté de mener à
terme ce présent travail. J’aime bien présenter mon vif
remercîments à tous ceux ou celles qui, d’une manière directe ou
indirecte, ont contribué par leur collaboration et leur soutient à la
réalisation de ce travail.
J’adresse mes vifs remerciements :
A mes encadreurs Mr. ARFAOUI Riadh et Mlle.
KHALFALLAH Amel pour ses encadrements, ses soutiens sans
failles et ses disponibilités. Ses conseils, ses commentaires, ses
corrections et ses qualités scientifiques ont été très précieux pour
mener à bien ce travail.
Je tiens également à remercier et exprimer mon profond
respect aux membres de jury d’avoir accepté de juger ce travail.

iii

Table des matières

DÉDICACES ............................................................................................................................. II
REMERCIEMENTS ................................................................................................................ III
TABLE DES MATIÈRES ........................................................................................................ IV
LISTE DES FIGURES ............................................................................................................. VI
LISTE DES TABLEAUX ..................................................................................................... VIII
LISTE DES ABRÉVIATIONS ................................................................................................ IX
INTRODUCTION GÉNÉRALE ................................................................................................ 1
CHAPITRE I.
PRÉSENTATION DE CADRE DE PROJET............................................................... 3
I.1 INTRODUCTION ...................................................................................................................................... 3
I.2 PRÉSENTATION DE L’ORGANISME D’ACCUEIL « BONNE GOUVERNANCE INFORMATIQUE (BGI) » ET LA
SOCIÉTÉ BÉNÉFICIAIRE « SOCIÉTÉ NATIONALE D’EXPLOITATION ET DE DISTRIBUTION DES EAUX
(SONEDE)» ................................................................................................................................................... 3
I.2.1
Présentation de l’organisme d’accueil BGI ................................................................................. 3
I.2.2
Activités de BGI ......................................................................................................................... 4
I.2.3
Présentation de société bénéficiaire SONEDE............................................................................ 4
I.3 ANALYSE DE L’EXISTANT ..................................................................................................................... 5
I.3.1
Description et critique de l’existant ............................................................................................ 5
I.3.2
Solution proposée ....................................................................................................................... 6
I.4 CONCLUSION ........................................................................................................................................ 6
CHAPITRE II.
SPÉCIFICATION DES BESOINS ................................................................................ 7
II.1 INTRODUCTION .................................................................................................................................... 7
II.2 ETUDE DES BESOINS ............................................................................................................................ 7
II.2.1
Besoins fonctionnels ................................................................................................................. 7
II.2.2
Besoins non fonctionnels .......................................................................................................... 8
II.3 DIAGRAMME DE CAS D’UTILISATION GÉNÉRAL.................................................................................... 9
II.3.1
Définition d’un diagramme de cas d’utilisation ................................................................... 9
II.3.2
Identification des acteurs ......................................................................................................... 10
II.4 CONCLUSION ..................................................................................................................................... 10
CHAPITRE III. CONCEPTION .............................................................................................................. 11
III.1
INTRODUCTION .............................................................................................................................. 11
III.2
GESTION DU PROJET INFORMATIQUE .............................................................................................. 11
III.2.1
Cycle de vie d’un logiciel ....................................................................................................... 11
III.2.2
Modèle de cycle de vie en V.................................................................................................. 11
III.3
MÉTHODOLOGIE DE CONCEPTION................................................................................................... 12
III.3.1
Choix du langage de modélisation ......................................................................................... 12
III.3.2
Choix de logiciel de conception ............................................................................................. 12
III.3.3
Démarche adoptée ................................................................................................................. 13
III.4
DESCRIPTION DES DIAGRAMMES D’UML ....................................................................................... 14
III.4.1
Description des diagrammes de cas d’utilisation ................................................................... 14
III.4.2
Description de diagramme de séquence ................................................................................. 23

iv

III.4.3
Description de diagramme d’activité ..................................................................................... 27
III.4.4
Description de diagramme des classes................................................................................... 30
III.5 CONCLUSION .................................................................................................................................... 32
CHAPITRE IV.
RÉALISATION ............................................................................................................. 33
IV.1
INTRODUCTION .............................................................................................................................. 33
IV.2
ARCHITECTURE DE L’APPLICATION : ARCHITECTURE 3-TIERS ....................................................... 33
IV.3
ENVIRONNEMENT DE DÉVELOPPEMENT ........................................................................................... 34
IV.3.1 Environnement matériel ............................................................................................................... 34
IV.3.2 Environnement logiciel ................................................................................................................ 34
IV.3.3 Choix techniques .......................................................................................................................... 37
IV.4
JEUX D’ESSAI .................................................................................................................................. 38
IV.4.1 Les interface de l’application ...................................................................................................... 39
IV.5 CONCLUSION ........................................................................................................................................ 60

CONCLUSION GÉNÉRALE .................................................................................................. 61
BIBLIOGRAPHIE ................................................................................................................... 62
ANNEXES .............................................................................................................................. 64
ANNEXE JOURNAL DU STAGE ......................................................................................... 64

v

Liste des figures
Figure 1 - Logo BGI [3] .......................................................................................................................... 4
Figure - 2 Logo de SONEDE [5] ............................................................................................................ 5
Figure 3 - Diagramme de cas d’utilisation « Général » ......................................................................... 9
Figure 4 - Modèle en V [8]................................................................................................................... 11
Figure 5 - Logo d’UML [10] ................................................................................................................ 12
Figure 6 - Logo PowerAMC [12] ........................................................................................................ 12
Figure 7 - Méthodologie de conception adoptée .................................................................................. 13
Figure 8 - Diagramme de cas d’utilisation « s’authentifier » ............................................................... 14
Figure 9Digramme de cas d’utilisation « Gestion des ressources humaines» ....................................... 16
Figure 10 - Digramme de cas d’utilisation « Gestion des ressources matérielles» ............................... 20
Figure 11 - Diagramme de cas d’utilisation de « gestion des Affectations» ........................................ 21
Figure 12 - Diagramme de « Gestion des interventions» ...................................................................... 22
Figure 13 - Diagramme de séquence de « Authentification» ................................................................ 23
Figure 14 - Diagramme de séquence de « Ajout d’une ressource humaine» ........................................ 24
Figure 15 - Diagramme de séquence de « Modification d’une ressource humaine» ............................ 25
Figure 16 - Diagramme de séquence de « Suppression d’une ressource humaine» .............................. 26
Figure 17 - Diagramme d’activité « Authentification » ........................................................................ 28
Figure 18 - Diagramme d’activité de «Ressources humaines» ............................................................. 29
Figure 19 - Diagramme de classes ........................................................................................................ 31
Figure 20 - Architecture de l’application [15]....................................................................................... 33
Figure 21 - Logo eclipse [18] ................................................................................................................ 34
Figure 22 –Logo serveur d’application [20].......................................................................................... 35
Figure 23 - Logo MySql [16] ................................................................................................................ 35
Figure 24 - Logo PowerAMC [12] ........................................................................................................ 36
Figure 25 -Logo primesfaces [17] ......................................................................................................... 36
Figure 26 -Logo word [18] .................................................................................................................... 36
Figure 27 – Interface d’Authentification ............................................................................................... 39
Figure 28 –Interface d’erreur ................................................................................................................ 40
Figure 29 – Interface d’accueil.............................................................................................................. 40
Figure 30 - Interface de liste des types des interventions ...................................................................... 41
Figure 31 – Interface d’ajout un type d’intervention ............................................................................ 42
Figure 32 - Interface d’erreur d’ajouter un type d’intervention ........................................................... 42
Figure 33 - Interfaces de succès d’ajouter un type d’intervention ........................................................ 43
Figure 34 – Interface de succès d’ajouter un type d’intervention dans la base de données .................. 44

vi

Figure 35 – Interfaces de succès de modification un type d’intervention dans la base des données . 45
Figure 36 – Interface de succès de suppression un type d’intervention de la base des données ........... 46
Figure 37 - Interface d'ajout une équipe ................................................................................................ 46
Figure 38 - Interface de succès d'ajouter une équipe............................................................................. 47
Figure 39 - Interface de succès de modification une équipe d’intervention.......................................... 48
Figure 40 - Interface de succès de supprimer une équipe d'intervention .............................................. 49
Figure 41 – Interface d’ajout une intervention dans la base des données ........................................... 50
Figure 42 - Interface de succès d’ajouter une intervention dans la base des données .......................... 51
Figure 43 - Interface de modification une intervention dans la base des données ................................ 52
Figure 44 – Interface de succès de modification d’une intervention dans la base des données ............ 53
Figure 45 - Interface de succès de téléchargement PDF d'une liste d'intervention ............................... 53
Figure 46 - Interface de succès de téléchargement un fichier Excel d'une liste d'intervention ............. 54
Figure 47 - Interface de suppression une intervention dans la base des données .................................. 54
Figure 48 – Interface de succès de suppression d’une intervention dans la base des données ............. 55
Figure 49 - Interface de l'agenda avant l'ajout d'une intervention ......................................................... 55
Figure 50 - Interface de l'agenda après l'ajout d'une intervention ......................................................... 55
Figure 51 – Interface d’accueil présentant les détails de l'événement ................................................. 56
Figure 52 - Interface d’ajout une affectation des ressources matérielles dans la base des données ...... 57
Figure 53 - Interfaces de succès d’ajout une affectation des ressources matérielles dans la base des
données ......................................................................................................................................... 58
Figure 54 – Interfaces de succès de modification une affectation des ressources matérielles ............. 59
Figure 55 – Interfaces de succès de suppression une affectation des ressources matérielles dans la base
de données .................................................................................................................................... 59

vii

Liste des tableaux

Tableau 1 - Détail de cas d’utilisation « S’authentifier» ....................................................................... 14
Tableau 2 – Détail de cas d’utilisation « Ajouter une ressource humaine » ......................................... 17
Tableau 3 – Détail de cas d’utilisation « Modifier une ressource » ...................................................... 18
Tableau 4 – Détail de cas d’utilisation « Supprimer une ressource humaines » ................................... 19
Tableau 5 – Détails des options mères pour le diagramme de séquence............................................... 26
Tableau 6 - Sommaire des différences existantes dans le diagramme d’activité par apport au «
Ressources humaines » ................................................................................................................. 30
Tableau 7 - Tâche de la semaine du 9 Février 2015 .............................................................................. 64
Tableau 8 - Tâche de la semaine du 16 Février 2015 ............................................................................ 64
Tableau 9 - Tâche de la semaine du 23 Février 2015 ............................................................................ 65
Tableau 10 - Tâche de la semaine du 2 mars 2015 ............................................................................... 65
Tableau 11 - Tâche de la semaine du 2 mars 2015 ............................................................................... 66
Tableau 12 - Tâche de la semaine du 2 mars 2015 ............................................................................... 66
Tableau 13 - Tâche de la semaine du 2 mars 2015 ............................................................................... 67
Tableau 14 - Tâche de la semaine du 30 mars 2015 ............................................................................. 67
Tableau 15 - Tâche de la semaine du 6 Avril 2015 ............................................................................... 68
Tableau 16 - Tâche de la semaine du 13 Avril 2015 ............................................................................. 68
Tableau 17 - Tâche de la semaine du 20 Avril 2015 ............................................................................. 69
Tableau 18 - Tâche de la semaine du 27 Avril 2015 ............................................................................. 69

viii

Liste des abréviations

BGI

Bonne Gouvernance Informatique

UML

Unified Modeling Language

HTML

HyperText Markup Language

CSS

Cascading Style Sheets

BD/bd

Base des Données

JSF

Java Server Faces

SONEDE

Société Nationale d’Exploitation et de Distribution des Eaux

ix

INTRODUCTION GÉNÉRALE

Introduction générale
Personne ne peut douter que la vie n’est pas un long fleuve tranquille et toujours nous
trouvons des évolutions et surtouts au niveau de l’informatique qui vient être à l’exploiter
dans tous les domaines. Aucun domaine n’est resté à l’abri de cette politique qui facilite les
tâches aussi bien pour l’entreprise que pour le personnel.
En effet, les systèmes informatiques ont répondu à un besoin vif pour n’importe quel
type d’organisation, c’est pour cela l’organisation doit aujourd’hui être capable de s’adapter
de plus en plus aux évolutions de l’environnement, ce que met l’accent sur la proposition de
Sun Tzu : « Connais ton ennemi et connais-toi toi-même; eussiez vous cent guerres à soutenir,
cent fois vous serez victorieux. Si tu ignores ton ennemi et que tu te connais toi-même, tes
chances de perdre et de gagner seront égales. Si tu ignores à la fois ton ennemi et toi-même, tu
ne compteras tes combats que par tes défaites. » [1]
Autrement dit, les sociétés ont besoin d’un système d’informatique pour améliorer la gestion
de leurs services et rendre l’organisation flexible à l’évolution de l’environnement c’est notre
objectif. Nous nous intéressons à la gestion des interventions. Cette gestion assure la
coordination dans une organisation pour faciliter la gestion des opérations d’intervention.
Cette gestion nécessite une solution informatique simple et performante pour répondre aux
exigences de ces interventions.
Dans le cadre de préparation d’un projet de fin d’études et pour l’obtention du diplôme
de licences appliquée en informatique de gestion, nous allons concevoir et développer une
application de gestion des interventions dans le domaine de gestion des fluides (cas de la
gestion de l’EAU par la SONEDE). A cet effet, l’idée du projet va permettre aux utilisateurs
de gérer les interventions ainsi les équipes d’intervention, ceci en se basant sur des facteurs
qui interviennent dans le choix d’affectation, citons par exemple la disponibilité des
ressources humaines et matérielles à une date bien précise, la zone géographique et ainsi de
suite.
Le présent rapport s’articule autour de quatre chapitres :
Le premier chapitre intitulé « Présentation de cadre de projet » présentera la société
d’accueil et la description de sujet.
1

INTRODUCTION GÉNÉRALE

Le deuxième chapitre intitulé « Spécification des besoins ». Cette partie consiste de faire
collecter et définir les besoins (les besoins fonctionnels et les besoins non fonctionnels).
Le troisième chapitre intitulé « Conception ». Ce chapitre décrit l’étude conceptuelle de
système et enfin le dernier chapitre « Réalisation » qui va contenir une description détaillé
des outils utilisé pour développer notre application et la présentation des principales interfaces
graphiques.
En conclusion, il ne me reste qu’à souhaiter que mon rapport sera précis et outil.

2

CHAPITRE I

PRÉSENTATION DE CADRE DE PROJET

Chapitre I. Présentation de cadre de projet
________________________________________________________

I.1 Introduction
Ce premier chapitre est consacré pour présenter l’organisme d’accueil Bonne
Gouvernance Informatique (BGI) au sein duquel nous avons effectué le stage relatif au
présent projet, ainsi que la Société Nationale d’Exploitation et de Distribution des Eaux
(SONEDE) pour laquelle l’application est destinée puis nous proposerons une solution aux
problèmes rencontrer, enfin nous allons citer les différentes étapes du déroulement du projet.

I.2 Présentation de l’organisme d’accueil « Bonne Gouvernance
Informatique (BGI) » et la société bénéficiaire « Société
Nationale d’Exploitation et de Distribution des eaux
(SONEDE)»
I.2.1 Présentation de l’organisme d’accueil BGI
BGI [2] est une société tunisienne de développement des logiciels. Elle est imposée
dans le secteur des services de la technologie Informatique depuis le 17 Décembre 2007.
Historiquement et présent, elle présente dans le domaine de l’eau et de l’assainissement. Ses
collaborateurs sont pour la plupart des ingénieurs informatiques qui sont le noyau de la
société. Spécialisée dans les nouvelles technologies (JEE, .NET), BGI a été conçu pour le
développement des logiciels dans les domaines suivants:


L’ingénierie logicielle en se basant sur les dernières innovations technologiques et

l’approche SOA (Service Oriented Architecture).


Le pilotage des projets de portails d’entreprise : internet/intranet/extranet.



La sous-traitance pour le compte des entreprises françaises.



L’offre de services comprenant : la création des sites (réalisation, conception, design,

développement et hébergement) et des solutions de commerce électronique (e-commerce, emarketing).

3

CHAPITRE I

PRÉSENTATION DE CADRE DE PROJET

I.2.2 Activités de BGI
BGI a comme principales activités :


Prestations de services en entreprises pour des missions de développement et / ou de

maintenance des logiciels.


Sous-traitance pour des sociétés françaises pour le développement dans le domaine

de gestion des fluides et de l’environnement.


Sous-traitance en faveur de

la société tunisienne ARAB SOFT

pour le

développement en Dot-Net & J2EE.

Figure 1 - Logo BGI [3]

I.2.3 Présentation de société bénéficiaire SONEDE
La SONEDE est une société qui a été créée par la loi 68-22 du 2 juillet 1968. [4]
Elle a comme une mission principale la production et distribution de l’eau portable et ses
quatre activités principales sont :


Gestion commerciale des abonnés.



Etude et réalisation des installations de captage.



Gestion technique des réseaux.



Traitement et production de l'eau potable.

4

CHAPITRE I

PRÉSENTATION DE CADRE DE PROJET

Figure - 2 Logo de SONEDE
[5]

I.3 Analyse de l’existant
I.3.1 Description et critique de l’existant
La description de l’existant est une question d’expliquer comment le travail s’effectue
actuellement au sein de la société. Nous remarquons l’absence d’un système de gestion des
interventions ainsi la difficulté de contrôler la planification des interventions et jusqu’à
aujourd’hui la SONEDE utilise une application desktop d’architecture client lourd.
L’analyse de l’existant nous a permis de dégager les critiques suivantes :


L’absence d’un système d’information pour la gestion des fluides.



L’existence de problème de gestion des interventions qui apparait toujours lorsque la

société –SONEDE- reçoit des réclamations dans différents zones géographiques.


Difficulté d’affecter des demandes d’intervention aux équipes selon la disponibilité, la

zone géographique.


La gestion des équipes d’intervention est gérée manuellement. Ceci rend le choix des

agents difficiles, vu qu’un agent ne peut être intégré qu’après la vérification de sa
disponibilité.


L’existence de problème de gestion des ressources matérielles, vu qu’un matérielle ne

peut être intégré qu’après la vérification de sa disponibilité.


Problème de gestion des zones géographiques car elles ne sont pas gérées selon le

type de secteur et le secteur de travail.

5

CHAPITRE I

PRÉSENTATION DE CADRE DE PROJET

I.3.2 Solution proposée
La solution proposé c’est une application web qui permet de faciliter le travail
quotidienne de SONEDE.
Cette application doit permettre à l’utilisateur de :


Gérer les ressources humaines selon le rôle des agents, leur disponibilité.



Gérer les ressources matérielles selon l’état et la disponibilité.



Gérer les types des interventions et le secteur pour gérer les zones géographiques.



Gérer les types des interventions pour faciliter l’affectation des demandes

d’intervention aux équipes d’intervention.

I.4 Conclusion
Au cours de ce chapitre nous avons présenté la société BGI dans laquelle nous avons
passé notre période de stage ainsi que SONEDE, la société de service fluide à laquelle notre
application destinée, tout en expliquant le déroulement actuelle chez elle pour pouvoir cibler
les points importants de notre application. Le chapitre suivant sera consacré d’une analyse des
besoins fonctionnels et non fonctionnels de notre système informatique.

6

CHAPITRE II

SPÉCIFICATION DES BESOINS

Chapitre II. Spécification des besoins
________________________________________________________

II.1 Introduction
La spécification des besoins est une phase très importante qui nous permet de définir
les besoins fonctionnels et non fonctionnels attendus du système afin de mieux comprendre le
projet.

II.2 Etude des besoins
Cette partie va servir à poser les bases du recueil des besoins du système à réaliser.
Pour pouvoir clarifier les besoins des utilisateurs de notre application, nous allons présenter
les besoins fonctionnels ainsi que les besoins non fonctionnels.

II.2.1 Besoins fonctionnels
Ces sont les besoins indispensables auxquels doit répondre l’application.
Le système à concevoir doit permettre à l’utilisateur d’effectuer les opérations suivantes :



Gestion des ressources humaines et matérielles :

L’administrateur peut gérer deux types des ressources : les ressources humaines
d’où il permet de gérer les congés et les absences et les ressources matérielles
d’où il permet de gérer l’état. Ce dernier permet d’ajouter, modifier ou supprimer
la ressource.


Gestion des équipes d’interventions :

Le chef des travaux va gérer des équipes d’où il permet de faire ces actions :
ajouter, modifier et/ou supprimer.


Gestion des zones géographiques :

L’administrateur va gérer les zones géographiques d’où il permet d’ajouter, de
supprimer ou modifier les zones géographiques.

7

CHAPITRE II



SPÉCIFICATION DES BESOINS

L’affectation des ressources humaines aux équipes :

Pour l’affectation des ressources humaines aux équipes, le chef des travaux
permet d’ajouter l’affectation, modifier ou faire une désaffectation.


Planification des demandes d’intervention :

On a besoin de type d’intervention dans la demande d’où le chef des travaux
permet de gérer ces types d’où il est capable de faire l’ajout la suppression ou la
modification de ce type

et l’agent d’accueil permet de gérer la demande

d’intervention d’où il est capable de faire l’ajout, la modification ou la
suppression d’une demande et permet de l’imprimer.


Affectation des demandes d’intervention aux équipes selon la

disponibilité, la zone géographique et la nature des travaux:
Le chef des travaux va planifier l’intervention d’où il doit identifier la demande
d’intervention et l’équipe et il ne peut pas seulement d’annuler la planification
mais il peut aussi de replanifier l’intervention.

II.2.2 Besoins non fonctionnels
Les besoins non fonctionnels décrivent toutes les contraintes auxquelles est soumis le
système pour sa réalisation et son bon fonctionnement, autrement dit, ils permettraient
d’améliorer la qualité des services de l’application et le système à concevoir doit
nécessairement assurer ces besoins :

 Performance : l’application doit être fiable et toujours fonctionnelle.
 Sécurité: l’application doit être sécurisée.
 Ergonomie : les interfaces doit être simples et leur utilisation doit être facile.
Une bonne rédaction des messages.



Maintenabilité et évolutivité : Le code de l’application doit être bien lisible et
compréhensible afin de le soutenir d’une façon rapide et facile.
8

CHAPITRE II

SPÉCIFICATION DES BESOINS

II.3 Diagramme de cas d’utilisation général
II.3.1 Définition d’un diagramme de cas d’utilisation
Le diagramme de cas d'utilisation décrit les utilisations requises d'un système, ou ce
qu'un système est supposé faire. Les principaux concepts de ce diagramme sont les acteurs,
cas d'utilisation.

Figure 3 - Diagramme de cas d’utilisation « Général »

9

CHAPITRE II

SPÉCIFICATION DES BESOINS

II.3.2 Identification des acteurs
Au niveau de cette section, nous présentons les différents acteurs susceptibles
d’interagir avec le système, mais tout d’abord, nous donnons une définition du concept acteur.
Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur) qui
interagissent directement avec le système étudié.
La mise en marche du système nécessite essentiellement trois acteurs :

Administrateur :
C'est un membre de la société qui a comme rôle, l'alimentation du système par le
paramétrage nécessaire à la gestion des interventions (gérer les ressources humaines,
gérer les ressources matérielles) et il est capable de faire la modification, l’ajout, la
suppression.
Chef des travaux :
C’est un membre de la société qui a comme un devoir de gérer les interventions.

II.4 Conclusion
Ce chapitre nous a permis de définir non seulement les besoins fonctionnels et les
besoins non fonctionnels notre solution mais aussi le diagramme de cas d’utilisation globale,
ainsi les acteurs, nous entamerons dans le chapitre suivant, nous essayerons concevoir
clairement notre système.

10

CHAPITRE III

CONCEPTION

Chapitre III.

Conception

________________________________________________________

III.1 Introduction
La phase de la conception est la phase initiale de la création et de la mise en œuvre de
notre projet. Dans ce chapitre nous allons proposer en détailles la conception de notre projet à
travers les diagrammes UML, ce sui facilite la phase d’implémentation.

III.2 Gestion du projet informatique
La gestion de projet (ou conduite de projet) est une démarche visant à organiser de
bout en bout le bon déroulement d’un projet.

III.2.1 Cycle de vie d’un logiciel
Le « cycle de vie d’un logiciel » (en anglais software life cycle), 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, et la
vérification du processus de développement (l’adéquation des méthodes mises en œuvre). [6]

III.2.2 Modèle de cycle de vie en V
Le modèle de cycle de vie en V part du principe que les procédures de vérification de
la conformité du logiciel aux spécifications doivent être élaborées dès les phases de
conception. [7]

Figure 4 - Modèle en V [8]

11

CHAPITRE III

CONCEPTION

III.3 Méthodologie de conception
III.3.1 Choix du langage de modélisation
Pour la modélisation objet, nous avons choisi le langage UML (en anglais Unified
Modeling Language ou « langage de modélisation unifié ») qui est un langage de
modélisation graphique à base de pictogrammes. Il est apparu dans le monde du génie
logiciel, dans le cadre de la « conception orientée objet ». Couramment utilisé dans les projets
logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au domaine. [9]

Figure 5 - Logo d’UML [10]

III.3.2 Choix de logiciel de conception
PowerAMC : est un logiciel de modélisation (modeleur) de Sybase. Il permet de
moduler des processus métier. Initialement créé sous le nom AMC*Designor par l'éditeur
Powersoft pour la modélisation Merise, ce dernier a été renommé PowerAMC pour la version
française et PowerDesigner pour la version internationale après le rachat par Sybase. [11]

Figure 6 - Logo PowerAMC [12]

12

CHAPITRE III

CONCEPTION

III.3.3 Démarche adoptée
Dans le précédent chapitre, nous avons présenté le digramme de cas d’utilisation
général qui décrit le comportement fonctionnel du système tel qu'il est vu par l'utilisateur, et
ceci ne suffit plus, c’est pour cela, que nous allons présenter les diagrammes des cas
d’utilisation, diagramme d’activité, diagramme de séquence et enfin le diagramme de classe.
Le schéma suivant représente notre métrologie de conception :

Identification des besoins

Identification des acteurs

Diagrammes de cas d’utilisation

Diagrammes d’activité

Diagrammes de séquence

Diagramme de classe

Figure 7 - Méthodologie de conception adoptée

13

CHAPITRE III

CONCEPTION

III.4 Description des diagrammes d’UML
III.4.1 Description des diagrammes de cas d’utilisation


Diagramme de cas d’utilisation « s’authentifier» :

Figure 8 - Diagramme de cas d’utilisation « s’authentifier »

Tableau 1 - Détail de cas d’utilisation « S’authentifier»
Sommaire de « Identification »
But

Ce cas d’utilisation permet aux utilisateurs de s’authentifier.

Acteur

Tous les acteurs prédéfinissent.

Description des enchainements
Pré-condition

Post condition

L’acteur doit s’authentifier

L’acteur est accéder à la page d’accueil.

14

CHAPITRE III

Scénario nominal

CONCEPTION

1.

Ce cas d’utilisation commence lorsque l’utilisateur désir à

accéder à la page d’accueil.
2.

Un formulaire contenant le champ identifiant et mot de passe

est affiché.
3.

L’utilisateur

saisit

ses

coordonnées

et

valide

l’authentification.
4.

Le système vérifie l’existence du l’identifiant et du mot de

passe.
Si le login et le mot de passe sont faux alors
Erreur de connexion
Fin si
Si le login et le mot de passe sont corrects alors
Succès de connexion
Fin si.
5.

En cas de succès l’utilisateur peut accéder à l’interface

d’accueil.

Scénario alternatif

L’utilisateur a entré les données sont incorrectes.
1.

Le système affiche une page d’erreur.

2.

Si l’utilisateur clique sur le bouton « Ressayer »Retour à

l’étape 1 du scénario nominal pour lancer à nouveau la connexion.

15

CHAPITRE III



CONCEPTION

Diagramme de cas d’utilisation « Gestion des ressources humaines» :

Figure 9 - Digramme de cas d’utilisation « Gestion des ressources humaines»

Figure 9Digramme de cas d’utilisation « Gestion des ressources humaines»

16

CHAPITRE III

CONCEPTION

Tableau 2 – Détail de cas d’utilisation « Ajouter une ressource humaine »
Sommaire de cas d’utilisation « Ajouter une ressources humaines »
But

Ce cas d’utilisation permet à l’administrateur d’ajouter des ressources
humaines.

Acteur

Administrateur.

Description des enchainements
Pré-conditions

Post condition

L’administrateur doit s’authentifier.

La ressource humaine est ajoutée.

Scénario

1.

L’administrateur clique sur l’option « Ressources humaines ».

Nominal

2.

Le système affiche deux autres options : « Gestion des ressources

humaines » et « Gestion des absences».
3.

L’administrateur clique sur l’option selon son besoin.

4.

Le système affiche une page qui contient une liste.

5.

L’administrateur clique sur le lien « Ajouter »

6.

Le système affiche une page contenant un formulaire.

7.

L’administrateur remplit le formulaire et clique sur le bouton

« Valider ».
8.

Le système vérifie les données saisies puis effectue la mise à jour et

l’ajout dans la base de données et retour à la page qui contient la liste.

L’administrateur n’a pas remplit un champ obligatoire ou a entré des

Scénario

1.

alternatif

données invalides.
2.

le système affiche un message d’erreur.

17

CHAPITRE III

CONCEPTION

Tableau 3 – Détail de cas d’utilisation « Modifier une ressource »
Sommaire de cas d’utilisation « Modifier une ressource humaine»
But

Ce cas d’utilisation permet à l’administrateur de modifier une ressource
humaine.

Acteur

Administrateur.

Description des enchainements
Pré-conditions

Post condition

L’administrateur doit s’authentifier.

La ressource est modifiée.

Scénario Nominal

1-

L’administrateur clique sur l’option « ressources humaines».

2-

Le système affiche deux autres options : « Gestion des

ressources humaines » et « Gestion des absences».
3-

L’administrateur clique sur l’option selon son besoin.

4-

Le système affiche une page qui contient une liste.

5-

Si l’administrateur écrit le nom de ressource

le système affiche toute la ligne qui contient ce nom.
Fin si.
Si non l’administrateur cherche dans la liste sans écrire le nom de
ressource et clique sur la ligne qui contient cette ressource puis sur le
lien « Modifier ».
6-

Le système affiche une page contenant un formulaire

remplit automatiquement.
7-

L’administrateur remplit le formulaire et clique sur le bouton

« Valider ».
8-

Le système vérifie les données saisies puis et retour à la page qui

contient la liste.

18

CHAPITRE III

CONCEPTION

Scénario alternatif 1.

L’administrateur n’a pas remplit un champ obligatoire ou a entré

des données invalides.
2.

le système affiche un message d’erreur.

Tableau 4 – Détail de cas d’utilisation « Supprimer une ressource humaines »
Sommaire de cas d’utilisation « Supprimer une ressource humaine»
But

Ce cas d’utilisation permet à l’administrateur de supprimer une
ressource humaine.

Acteur

Administrateur.

Description des enchainements
Pré-conditions

Post condition

L’administrateur doit s’authentifier.

La ressource est supprimée.

Scénario Nominal

1-

L’administrateur clique sur l’option « Ressources humaines».

2-

Le système affiche deux autres options « Gestion des

ressources humaines » et « Gestion des absences».
3-

L’administrateur clique sur l’option selon son besoin.

4-

Le système affiche une page qui contient une liste.

5-

Si l’administrateur écrit le nom de ressource

le système affiche toute la ligne qui contient ce nom.
Fin si.
Si non l’administrateur cherche dans la liste sans écrire le nom de
ressource et clique sur la ligne qui contient cette ressource puis sur le
bouton« Supprimer».
6-

Le système effectue la mise à jour dans la base de données et

actualise la page.

19

CHAPITRE III



CONCEPTION

Diagramme de cas d’utilisation « Gestion des ressources matérielles» :

Figure 10 - Digramme de cas d’utilisation « Gestion des ressources matérielles»

La description de diagramme de cas d’utilisation de « Gestion des ressources
matérielles » est identique à la description de diagramme de cas d’utilisation « Gestion des
ressources humaines », autrement dit, ce dernier va suivre la même démarche pour faire
l’ajout, la modification et la suppression.

20

CHAPITRE III



CONCEPTION

Diagramme de cas d’utilisation1« Gestion des affectations» :

Figure 11 - Diagramme de cas d’utilisation de « gestion des Affectations»

1

La description de diagramme de cas d’utilisation de « Gestion des affectations» est identique à la description de diagramme
de cas d’utilisation « Gestion des ressources humaines », autrement dit, ce dernier va suivre la même démarche pour faire
l’ajout, la modification et la suppression.

21

CHAPITRE III



CONCEPTION

Diagramme de cas d’utilisation «Gestion des interventions»2 :

Figure 12 - Diagramme de « Gestion des interventions»

2

La description de diagramme de cas d’utilisation de « Gestion des interventions» est identique à la description de
diagramme de cas d’utilisation « Gestion des ressources humaines », autrement dit, ce dernier va suivre la même démarche
pour faire l’ajout, la modification et la suppression.

22

CHAPITRE III

CONCEPTION

III.4.2 Description de diagramme de séquence
Un diagramme de séquence est un document graphique qui montre pour des scénarios
de cas d'utilisation précis, les événements générés et les interactions entre objets en se basant
sur des messages ordonnés. Chaque message transitant sur un lien est symbolisé par une
flèche porteuse d'une expression. La lecture se fait de haut en bas, et l'ordre chronologique
doit respecter ce sens.


Diagramme de séquence « Authentification» :

Figure 13 - Diagramme de séquence de « Authentification»

23

CHAPITRE III



CONCEPTION

Diagramme de séquence « Ajout des ressources humaines» :

Figure 14 - Diagramme de séquence de « Ajout d’une ressource humaine»

24

CHAPITRE III



CONCEPTION

Diagramme de séquence « Modification des ressources humaines» :

Figure 15 - Diagramme de séquence de « Modification d’une ressource humaine»

25

CHAPITRE III



CONCEPTION

Diagramme de séquence « Suppression des ressources humaines» :

Figure 16 - Diagramme de séquence de « Suppression d’une ressource humaine»

Le diagramme de séquence est le même pour faire l’ajout, la modification et la
suppression mais il existe quelque différence et l’explication ce traduit dans ce tableau :
Tableau 5 – Détails des options mères pour le diagramme de séquence
L’option

Les options qu’elle englobe et son BD

Acteur

mère
Interventions

Chef des



Gestion des interventions (BD : intervention).

travaux



Gestion des types des interventions (BD :

typeintervention).


Gestion des équipes des interventions (BD :

equipe).
Ressource

Administrateur 

Gestion des ressources humaines (BD :

ressourcehumaine).

26

CHAPITRE III

CONCEPTION

humaines



Ressource

Administrateur 

matérielles

Gestion des absences (BD : absence).
Gestion des ressources matérielles (BD :

ressourcematerielle).


Gestion des états des matérielles (BD :

etatmaterielle).
Affectations

Chef des



travaux

affagent).


Affectation des ressources humaines (BD :

Affectation des ressources matérielles (BD :

affresmat).


Gestion des zones géographiques (BD :

zonegeographique).

III.4.3 Description de diagramme d’activité
Le diagramme d'activité est un diagramme comportemental d'UML, permettant de
représenter le déclenchement d'événements en fonction des états du système et de modéliser
des comportements pouvant être parallèles. Le diagramme d'activité est également utilisé pour
décrire un flux de travail autrement dit il permet de représenter la dynamique de système
d’information. [13]

27

CHAPITRE III



CONCEPTION

Diagramme d’activité « Authentification »

Figure 17 - Diagramme d’activité « Authentification »

28

CHAPITRE III



CONCEPTION

Diagramme d’activité de « Ressources humaines » :

Figure 18 - Diagramme d’activité de «Ressources humaines»

29

CHAPITRE III

CONCEPTION

Le diagramme d’activité pour les autres gestions est le même mais la différence est
existe au niveau des acteurs et l’explication se traduit dans ce tableau comme suit :
Tableau 6 - Sommaire des différences existantes dans le diagramme d’activité par
apport au « Ressources humaines »
Acteur
Chef des travaux

L’option

Les sous options

Interventions



Gestion des interventions.



Gestion des types des interventions.



Gestion des équipes des

interventions.
Administrateur

Chef des travaux

Ressources matérielles

Affectations



Gestion des ressources matérielles.



Gestion des états des matérielles.



Affectation des ressources

humaines.


Affectation des ressources

matérielles.


Gestion des zones géographiques.

III.4.4 Description de diagramme des classes
Le diagramme des classes est considéré comme le plus important de la modélisation
orientée objet car il montre la structure interne. Il contient principalement des classes et une
classe contient des attributs et des méthodes.
Les attributs définissent qu’une classe ou un objet doivent connaitre. Ils représentent les
données encapsulées dans l’objet de cette classe. Chacune de ces informations est définie par
un nom, un type de données et une visibilité. Le nom de l’attribut doit être unique dans la
classe.
Les méthodes : (appelées parfois fonctions membres): Les méthodes d'un objet caractérisent
son comportement, c'est-à-dire l'ensemble des actions (appelées opérations) que l'objet est à
même de réaliser. Ces opérations permettent de faire réagir l'objet aux sollicitations
extérieures (ou d'agir sur les autres objets). De plus, les opérations sont étroitement liées aux

30

CHAPITRE III

CONCEPTION

attributs, car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier.
[14]
Une association représente une relation sémantique entre les objets d’une classe. Elle est
représentée par un trait plein entre les classes associées.

Figure 19 - Diagramme de classes

31

CHAPITRE III

CONCEPTION

III.5 Conclusion
Dans ce chapitre, nous avons adopté le modèle UML. Aussi nous avons fait la
description des diagrammes des cas d’utilisation, de classe et de séquence et d’activité, et de
contexte afin de délimiter le cadre de notre travail et de préparer un terrain favorable pour la
prochaine étape. Maintenant, notre application est prête à être codée. Dans le chapitre suivant,
nous allons nous intéresser à l’implémentation de notre système en se basant sur la conception
détaillée de ce chapitre.

32

CHAPITRE IV

REALISATION

Chapitre IV.

Réalisation

________________________________________________________

IV.1

Introduction
La réalisation est la dernière phase de la construction d’une application. Dans ce

chapitre nous traitons les différentes étapes d’implémentation de l’application, et au fur et à
mesure nous avons établi un ensemble de tests : ce sont les étapes de la phase de réalisation.
En fait, nous allons parler de l’architecture matérielle mise en place ainsi les outils matériels
et logiciels utilisés lors du développement. Ensuite, nous présentons les interfaces globales
ainsi qu’une description du fonctionnement du système.

IV.2

Architecture de l’application : Architecture 3-tiers
Nous avons développé l’application en basant sur l’architecture trois-tiers. En adoptant

cette architecture, le système sera divisé en trois couches (ou niveaux) différents :
présentation des données, logique métier, et accès aux données.

Figure 20 - Architecture de l’application [15]



la présentation des données : correspondant à l'affichage, la restitution sur le poste de

travail, le dialogue avec l'utilisateur.


le traitement métier des données : correspondant à la mise en œuvre de l'ensemble

des règles de gestion et de la logique applicative.

33

CHAPITRE IV


REALISATION

L’accès aux données persistantes : correspondant aux données qui sont destinées à

être conservées sur la durée, voire de manière définitive. [16]

IV.3 Environnement de développement
Dans cette partie, nous allons étudier le choix des outils matériels et surtout les outils
logiciels du développement.
Nous allons présenter les différents langages ; l’environnement matériels d’où nous allons
mentionner

les caractéristiques de l’ordinateur sur lesquelles nous avons développé

l’application parce qu’elles peuvent donner une idée sur les conditions du travail

et

l’environnement logiciels d’où nous allons énumérer au cours de cette partie les différents
outils utilisés tout au long de ce projet pour l’étude et la mise en place de notre application.

IV.3.1 Environnement matériel
L’application a été développée sur un ordinateur portable Dell INSPIRON qui se
caractérise par :


Processeur : Intel® Pentium® CPU B960 @ 2.20GHz 2.20 GHz



Mémoire installée (RAM) : 4,00 Go (3,41 Go utilisable)



Type de système : Système d’exploitation 32 bits.

IV.3.2 Environnement logiciel
Les différents logiciels utilisés lors de phase de conception et de développement sont
les suivants :
Eclipse : est un environnement de développement intégré(EDI) libre extensible, universel et
polyvalent, permettant de créer des projets de développement en s'appuyant principalement
sur Java. [17]

Figure 21 - Logo eclipse [18]

34

CHAPITRE IV

REALISATION

Serveur d’application : « JBoss 7.1.1 » : est une implémentation open source de la suite
Java EE de services. Elle comprend un ensemble d'offres pour les demandeurs qui recherchent
des profils préconfigurés à leurs entreprises. Développée par l’éditeur JBoss Enterprise
Middleware, cette application vous offre un pack d’outils de développement certifié et testé.
[19]

Figure 22 –Logo serveur d’application [20]
MySQL : est un système de gestion de bases de données relationnelles (SGBDR). Il fait
partie des logiciels de gestion de base de données les plus utilisés au monde, autant par le
grand public (applications web principalement) que par des professionnels, en concurrence
avec Oracle, Informix et Microsoft SQL Server. Le SQL dans « MySQL » signifie
"Structured Query Language" : le langage standard pour les traitements de bases de données.
[21]

Figure 23 - Logo MySql [22]

Figure 23 - Logo MySql [16]

PowerAMC : Est un outil de modélisation des données et des processus. Il a été créé par la
société Sybase.

35

CHAPITRE IV

REALISATION

Figure 24 - Logo PowerAMC [12]

Prime Faces : est une bibliothèque open source de composants JSF. Il est basé côté serveur
sur l’API standard de JSF 2. Coté client les scripts de Prime Faces sont basés sur la
librairie la plus populaire de JavaScript jQuery. Prime Faces vise à garder le traitement
propre, rapide et léger. [23]

Figure 25 - Logo primesfaces [23]
Figure 25 -Logo primesfaces [17]

Word 2007 : C’est un logiciel de traitement de texte utilisé pour la réduction de ce rapport.

Figure 26 - Logo word [24]

Figure 26 -Logo word [18]

36

CHAPITRE IV

REALISATION

IV.3.3 Choix techniques


Choix de langages :
Java : est à la fois un langage de programmation informatique orienté objet et un

environnement d'exécution informatique portable il a la particularité principale que les
logiciels écrits avec ce dernier sont très facilement portables sur plusieurs systèmes
d'exploitation tels que Unix, Microsoft Windows, Mac OS ou Linux avec peu ou pas de
modifications... C'est la plate-forme qui garantit la portabilité des applications développées en
Java. [25]
UML : (en anglais Unified Modeling Language ou « langage de modélisation unifié »)
est un langage de modélisation graphique à base de pictogrammes. Il est apparu dans le
monde du génie logiciel, dans le cadre de la « conception orientée objet ». Couramment utilisé
dans les projets logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au
domaine. [26]
HTML : HyperText Markup Language (HTML) est un langage de “mark up” qui
définit la structure logique d’un document WWW diffusé sur le Web [27].
CSS : ( ”Cascading Style Sheets”) est un langage qui permet de gérer la présentation
d’une page web, alors nous avons utilisé ce style pour définir les règles appliquées dans nos
documents HTML comme l’alignement, les polices de caractères, les couleurs, les marges et
espacements et les bordures et nous avons l’utilisé aussi pour le modèle.


Choix standard de développement
JEE :

Java

une spécification pour

Enterprise

Edition,

ou Java

la technique Java d'Oracle plus

EE (anciennement J2EE),
particulièrement

destinée

est
aux

applications d’entreprise. [28]


Choix de Framework
Présentation de JSF : Java Server Faces (JSF), qui est un Framework permettant de

développer des applications Web en Java tout en respectant le modèle d’architecture MVC
(Model View Cotroller), est fondé sur des composants côté présentation. [29]

37

CHAPITRE IV

REALISATION

Hibernate : est un Framework open source offrant un mécanisme de mapping
objet/relationnel ce qui permet la gestion de la persistance des objets en base de données
relationnelle [30]

IV.4 Jeux d’essai
La conception des interfaces de l’application est une étape très importante puisque
toutes les interactions avec le cœur de l’application passent à travers ces interfaces, on doit
alors guider l’utilisateur avec les messages. Dans cette partie, nous allons présenter quelques
interfaces de l’application, répondant aux recommandations ergonomiques et de souplesse.

38

CHAPITRE IV

REALISATION

IV.4.1 Les interface de l’application
Authentification
Cette interface permet à l’utilisateur de s’authentifier d’où il doit entrer son login et son mot
de passe pour accéder à l’application.

Figure 27 – Interface d’Authentification

En cas d’erreur : l’identifiant et/ou le mot de passe sont incorrectes, le système affiche
l’interface suivante :

39


Gestion des interventions fluides Ikbel BOUDHIEF.pdf - page 1/81
 
Gestion des interventions fluides Ikbel BOUDHIEF.pdf - page 2/81
Gestion des interventions fluides Ikbel BOUDHIEF.pdf - page 3/81
Gestion des interventions fluides Ikbel BOUDHIEF.pdf - page 4/81
Gestion des interventions fluides Ikbel BOUDHIEF.pdf - page 5/81
Gestion des interventions fluides Ikbel BOUDHIEF.pdf - page 6/81
 




Télécharger le fichier (PDF)


Gestion des interventions fluides Ikbel BOUDHIEF.pdf (PDF, 3.2 Mo)

Télécharger
Formats alternatifs: ZIP



Documents similaires


rapport
methodes et outils pour la conduite de projet
rapport de stage wangle mohamed el mehdi benabdellah
guide rapport pfe 2014
initiation a la conduite de projet
rapport pfa henibellaaj cloud 1