République du Cameroun Republic of
Cameroon
Ministère de l'enseignement supérieur
Ministry of Higher education
Université des Montagnes
Institut Supérieur des Sciences et de Technologie
251658240
Département Santé
RAPPORT DE PROJET DE FIN D'ETUDES
En vue de l'obtention d'une Licence de Technologie en
Génie Informatique option, Informatique et Réseaux
Titre :
Conception et Implémentation d'une GMAO pour le
Département Santé de l'EEC « GMABIO »
Présenté par:
- Kamga Jean Pierre Mat :
09C029
- Ngomne Bouwa Boris Flavien Mat : 09C048
Sous l'Encadrement Académique de :
- Mr Takoudjou Alexis
Sous l'Encadreur Professionnel de:
- Mr Pelamie Pierre
Bangangté Octobre 2012
DÉDICACES
Après avoir rendu grâce à DIEU LE TOUT
PUISSANT,
Nous dédions ce modeste travail à
Nos chers parents
Nos frères et soeurs
Nos promotionnaires
Ainsi qu'à tous ceux qui nous sont chers.
REMERCIEMENTS
Après avoir rendu grâce à DIEU de nous
avoir donné la force physique, morale et intellectuelle d'achever ce
projet de fin d'études, nous tenons à témoigner notre
profonde gratitude
- A M. le Directeur Général du
département santé de l'EEC pour nous avoir accueillis
dans sa structure ainsi qu'à tous le personnel de cette dernière
;
- A tous nos encadreurs pour leur
disponibilité et leurs conseils, durant toute la durée du projet
à savoir:
ï M. Takoudjou Alexis Professeur
à l'université des montagnes ;
ï M. Pelamie Pierre Chef service
maintenance au département santé de l'EEC, Ingénieur
biomédical ;
- Nous tenons également à remercier tous ceux
qui, de près ou de loin, ont contribué à la
réalisation de ce travail sans oublier nos camarades de promotion.
- L'Université des Montagnes, pour la
formation qu'elle nous a donnée tout au long de notre cycle faisant de
nous des ingénieurs à part entière et capables de
s'insérer dans le monde professionnel.
RÉSUMÉ
La technologie joue un rôle essentiel dans
l'efficacité de la prestation de la santé. Le choix des
technologies médicales appropriées et l'organisation requise pour
maintenir ces technologies en bon état de fonctionnement relèvent
des programmes de gestion des technologies de la santé. La
responsabilité de la gestion des technologies de la santé incombe
souvent au département du génie biomédical (ou de
l'équipement médical), qui teste, répare et entretient le
matériel clinique diagnostique et thérapeutique pour garantir
qu'il peut être utilisé efficacement et en toute
sécurité. Les systèmes de gestion de maintenance
assistée par ordinateur (GMAO) ont été conçus pour
aider les responsables de la gestion des technologies de la santé
à entretenir l'équipement et à suivre les dépenses
connexes automatiquement.
Le but de ce projet de fin d'études est de concevoir et
de développer un système de gestion de la maintenance
adaptée au contexte des hôpitaux et centres
médicalisés de l'oeuvre médicale de l'Eglise
Evangélique du Cameroun. Ce système permettra à
l'entreprise d'avoir une traçabilité et une transparence des
activités d'entretien aussi bien sur le plan technique que humain.
D'après le cahier des charges, le progiciel doit
être un système de gestion de base de données qui doit
enregistrer les activités d'entretien (état avant intervention,
pièces changées, reconduites, travaux, durées,
intervenants, bons de sortie, état du stock etc.) fournir les fiches
machines des équipements (caractéristiques, pièces de
rechange, service concerné), l'historique des interventions.
Ce progiciel que nous avons nommé « GMABIO
Solution » compte deux applications : « GMABIO
Admin » pour l'administration du système et « GMABIO
Client » pour les hôpitaux, elles sont toutes deux
développées sous Netbeans 6.9, avec des outils tels que
Hibernate, AJAX.
ABSTRACT
Technology plays a vital role in the effectiveness of health
delivery. The choice of appropriate medical technologies and organization
required to maintain these technologies are good working condition management
programs of health technologies. Responsibility for the management of health
technologies often falls to the Department of Biomedical Engineering (or
medical equipment), which tests, repairs and maintains diagnostic and
therapeutic clinical equipment to ensure it can be used safely and effectively
safety. Management systems of computer-aided maintenance (CMMS) have been
designed to help those responsible for the management of health technologies to
maintain equipment and related expenses automatically follow. The purpose
of this final project is to design studies and develop a system for maintenance
management adapted to the context of hospitals and medical centers of the
medical work of l'Eglise Evengélique du Cameroun. This system will allow
the company to have a traceability and transparency of maintenance activities
on both the technical and human. According to the specifications, the
package should be a management system database should record maintenance
activities (before state intervention, parts changed, renewed, work, duration,
actors, good output status stock etc.). Plugs provide machinery equipment
(specifications, spare parts service), the history of interventions. The
package that we named GMABIO Solution has two applications:
«GMABIO Admin» for system administration and
«GMABIO Client» for hospitals, they are both
developed in Netbeans 6.9, with tools such as Hibernate, AJAX.
TABLE DES MATIERES
DÉDICACES
2
REMERCIEMENTS
3
RÉSUMÉ
4
ABSTRACT
5
TABLE DES MATIERES
6
LISTE DES FIGURES
8
LISTE DES CYCLES ET ABRÉVIATIONS
9
INTRODUCTION GÉNÉRALE
10
Chapitre 1 CONTEXTE, PROBLEMATIQUE ET METHODOLOGIE
DE TRAVAIL
11
I.1 ETUDE DE L'EXISTANT
11
II.1.1 Présentation de
l'entreprise
11
II.1.2 Etat de la gestion de la
maintenance
11
I.2 PRÉSENTATION DU PROJET
12
I.3 PROBLÉMATIQUE DU PROJET
12
I.4 OBJECTIFS
12
I.5 MÉTHODOLOGIE DU PROJET
13
Chapitre 2 ETAT DE L'ART
14
II.1 FONCTION DE LA MAINTENANCE DANS UNE
STRUCTURE
14
II.1.1 Définition
14
II.1.2 Importance et rôle de la
maintenance
14
II.1.3 Phases de la maintenance
14
II.1.3.1 Choix de
l'équipement
14
II.2 CONCEPT DE GMAO
15
II.3 LOGICIELS DE GMAO
15
II.3.1 Unigest
15
II.3.2 AssetPlus
15
II.3.3 Justification du choix de
développement
16
II.4 ARCHITECTURE ET TECHNOLOGIES À
UTILISER
16
II.4.1 Architecture 3-tiers
16
II.4.2 Architecture d'une application Java
en couche
16
II.4.3 JPA/Hibernate
17
II.4.4 FPDF
18
II.4.5 AJAX
18
Chapitre 3 ANALYSE ET CONCEPTION DE GMABIO
SOLUTION
19
III.1 SPÉCIFICATION FONCTIONNELLE DE
L'APPLICATION
19
III.1.1 Fonctions du système
19
III.1.2 Description des utilisateurs
19
III.1.3 Fonctions liées aux droits
d'accès
20
III.2 EXIGENCES SPÉCIFIQUES
20
III.2.1 Interfaces externes
21
III.2.2 Spécification des cas
d'utilisations
21
III.3 MODÈLE OBJET DU
SYSTÈME
27
III.3.1 Diagramme de classe du module
gestion des interventions
27
III.3.2 Diagramme de classe du module
gestion des équipement
28
III.3.3 Règles de gestion
29
III.4 EXIGENCES D'OPÉRATIONS, DE
COMMUNICATIONS ET DE PERFORMANCE
29
III.5 EXIGENCE DE LA BASE DE
DONNÉES
29
III.5.1 Modèle Conceptuel de
données
29
III.6 CONCEPTION DE L'APPLICATION
30
III.6.1 Domaine d'Application
30
III.6.2 Architecture du système
30
III.6.3 Langages utilisés
30
III.6.4 Diagramme de déploiement
31
III.6.5 Architecture Générale
du système
31
III.6.5.4 Gestion des
Erreurs
34
Chapitre 4 MISE EN OEUVRE
36
IV.1 ENVIRONNEMENT DE TRAVAIL
36
IV.2 DEMARCHE DE TRAVAIL
36
IV.3 DIFFICULTÉS
RENCONTRÉS
37
IV.4 RÉSULTATS OBTENUS
37
BIBLIOGRAPHIE
42
I. Référence
bibliographique
42
II. Site web
42
ANNEXES
43
LISTE DES FIGURES
Figure1 : Architecture 3-tiers
16
Figure2 : Architecture d'une application
java en couche
17
Figure3 : Diagramme des cas
d'Utilisation
22
Figure4 : Diagramme de séquence
« Afficher liste Equipement »
23
Figure5 : Diagramme de classe
« module Intervention »
27
Figure6 : Diagramme de classe
« module Equipement »
28
Figure7 : Architecture
générale de l'application GMABIO Solution
30
Figure8 : Diagramme de
déploiement
31
Figure9 : Architecture
générale du système
32
Figure10 : Architecture application
d'administration
33
Figure11 : Architecture application
cliente
34
Figure12 : Arborescence des paquetages
37
Figure13 : Interface de connexion
application d'administration
37
Figure14 : Fenêtre de choix de
l'opération « module gestion
équipements »
38
Figure15 : Interface fiche
équipement
38
Figure16 : Interface contrat
maintenance « module gestion équipement »
39
Figure17 : Interface connexion application
cliente
39
Figure18 : Interface commencer
Intervention
40
LISTE DES CYCLES ET
ABRÉVIATIONS
2TUP:2 Tract Unified
Process
API: Application
Programming Interface
DAO: Data Access
Object
EEC:
GMABIO: c'est le nom de l'application
IHM : Interface Homme
Machine
JDBC: Java Data
Base Connection
JPA: Java Persistence
API
JSE: Java Standard
Edition
MERISE : Méthode
d'Etude et de Réalisation
Informatique des Systèmes
d'Entreprise
MVC: Model View
Controller
MySQL: My Structured
Query Language
SGBD: Système de
Gestion des Bases de
Données
TCP/IP: Transmission
Control Protocol / Internet
Protocol
UML: Unified
Modeling Language
INTRODUCTION
GÉNÉRALE
La fonction maintenance prend une importance croissance et se
révèle une fonction clé au sein de l'entreprise tout comme
la fonction production. Elle se charge de conserver en bon état le
patrimoine technique de l'entreprise, c'est-à-dire les outils de
production et donc doit avoir une vision à moyen et à long
terme.
Pour être efficace dans sa mission d'assurer l'entretien
et l'amélioration de l'équipement de production, la fonction
maintenance doit se doter d'outils fiables afin de gérer le flux
d'informations qui gravite autour de ses activités quotidiennes :
- Identification de chaque équipement de l'entreprise
(caractéristiques techniques, pièces de rechange etc.),
- Notifications de toutes les interventions effectuées
sur les équipements afin de pouvoir établir leur historique,
- Situation des responsabilités en identifiant les
intervenants et les travaux effectués lors d'une activité
d'entretien,
- Appréciation des agents de maintenance en notifiant
les temps d'interventions (heures normales et supplémentaires,
qualité de la prestation ...)
- Information sur les pièces de rechanges disponibles
afin d'éviter une rupture de stock.
Le progiciel nommé GMABIO que nous avons
développé dans le cadre de ce projet de fin d'études est
un outil de prise de décision qui apporte une solution aux points
énumérés ci-dessus.
Quoiqu'étudié dans le contexte du
département santé de l'EEC, GMABIO peut s'adapter à la
plupart des grands groupes l'hospitalier tel que : ALucem.
Le présent rapport est composé de quatre
chapitres : le premier porte sur la problématique et la
méthodologie du travail à effectuer, le deuxième sur la
revue des concepts et technologie pour la mise sur pied de cette solution
tandis que le troisième et le quatrième traitent respectivement
de l'analyse conceptuelle du progiciel de gestion de la maintenance et de sa
mise en oeuvre.
Chapitre 1
I.1 ETUDE DE
L'EXISTANT
II.1.1 Présentation de
l'entreprise
L'église évangélique du Cameroun dans ses
diverses oeuvres aussi bien religieuses que sociales a créé
plusieurs hôpitaux sur l'étendu du territoire. Ces hôpitaux
sont sous la tutelle des oeuvres département santé EEC qui est
lui-même subdiviser en plusieurs services à savoir :
Ressources Humaines, Pharmacie, Audits et Finances et Maintenance
biomédical.
Le service de la maintenance est celui qui s'occupe de
gérer la maintenance des équipements de tous les
hôpitaux et centres médicalisées. Il convient de
préciser que ces hôpitaux sont aux nombres de seize et que
certains d'entre eux possèdent des centres médicalisés ou
annexes.
II.1.2 Etat de la gestion de la
maintenance
I.1.2.1 Intervenants
Dans le système actuel, les intervenants sont les
responsables des hôpitaux qui interpellent l'ingénieur lorsqu'une
panne survient. Mais ce système est entrain de laisser sa place à
un autre qui fera intervenir des techniciens qui seront dispatchés dans
les centres. Ce qui nous pousse à prendre en compte ces nouveaux
intervenants dans la solution qui nous a été demandée
à mettre sur pied visant a facilité la gestion de ce nouveau
système.
I.1.2.2 Déroulement actuel de la
maintenance
Les activités menées jusqu'ici par le service de
maintenance se déroulent comme suit : lors de l'acquisition d'un
équipement celui-ci est enregistré dans une fiche d'inventaire.
Lorsqu'une panne survient le responsable du centre peut contacter le service
de maintenance en la personne de l'ingénieur responsable du service qui
prend en compte la demande ; se déplace ou fait déplacer
l'équipement dans l'optique d'une intervention. A la fin, il doit
produire une fiche d'intervention qu'il fait viser par le centre demandeur.
Dans la situation contraire à celle décrite ci-dessus le
responsable du centre contacte un fournisseur agrée ou une entreprise de
maintenance de la place.
I.1.2.3 Critique de l'existant
Les remarques que nous avons relevées sont les
suivantes :
- Un traitement lent, dû au traitement manuel de
certaines tâches ce qui peut éventuellement conduire à de
nombreuses erreurs.
- Grande perte d'informations car celles-ci ne sont pas
centralisées.
- Une sauvegarde pas assez fiable de données.
I.2 PRÉSENTATION DU PROJET
Le produit à
développer est un système de gestion de la maintenance
assistée par ordinateur pour le service de maintenance biomédical
du département santé de l'EEC, nommé « GMABIO
Solution».
Le projet consiste à mettre sur pied un système
qui permet une centralisation de l'information, un traitement rapide et plus
efficace des données recueillies. En effet, le nouveau système
permet la gestion informatisée des équipements médicaux
des hôpitaux de l'EEC. Il s'agit non seulement de recenser les
différents types d'équipements présents dans l'entreprise,
leur localisation, mais aussi permettre de connaître l'année
d'acquisition de ces équipements, le nom des fournisseurs, l'historique
des interventions sur chaque équipement, de prendre des décisions
stratégiques et de fournir des statistiques... Le système
comporte deux applications, une application cliente « GMABIO
Client » qui sera accessible aux clients via le
réseau internet et une application serveur « GMABIO
Admin » qui sera accessible via la machine d'administration
et offre une vision globale de l'état et du suivi des équipements
utilisés dans l'entreprise. Ce système s'occupera aussi de la
gestion des ressources humaines et la gestion des inventaires.
I.3
PROBLÉMATIQUE DU PROJET
Les questions qu'on se pose au regard d'un tel projet sont les
suivantes : Comment mettre donc à disposition du département
santé un outil devant aidé à gérer le parc des
équipements de leur hôpitaux ? Comment assurer une bonne gestion
du processus de maintenance ? Quel choix d'architecture allons-nous
opérer pour faciliter la maintenance du futur système ? Comment peut-on modéliser fidèlement la
solution en tenant compte des besoins des utilisateurs et des contraintes de
l'environnement ?
L'objectif principal pour nous sera de satisfaire les attentes
ci-dessous.
I.4 OBJECTIFS
Le logiciel permettra de :
· Fournir à tout moment la localisation d'un
équipement dans l'entreprise;
· Avoir un meilleur suivi et un meilleur contrôle
des équipements (pas de confusion entre les noms des
équipements et pas d'erreurs)
· Produire des statistiques et des rapports (ou des
fiches techniques) sur les équipements ;
· Faciliter la gestion et le contrôle des
équipements ;
· Améliorer la qualité de service et
assurer la meilleure productivité du département Santé en
général et du service de maintenance B.M. en particulier ;
· Mieux planifier les interventions
préventives ;
· Mieux planifier les prévisions d'acquisition et
de remplacement ;
· Avoir une meilleure visibilité sur les
ressources qui vont permettre de prendre de meilleures
décisions
I.5
MÉTHODOLOGIE DU PROJET
La démarche que
nous utiliserons pour ce logiciel sera calquée sur le cycle de vie de ce
dernier; en partant de l'avant-projet jusqu'à l'installation et en
effectuant en parallèle les autres tâches tel que : La
documentation, La vérification, La validation, La gestion. Le tableau
ci-dessous présente le cycle de vie du logiciel.
Activités
|
Sous-Activités
|
Activités Parallèle
|
Documents
|
Autres
|
Avant-projet
|
Etude Préalable
|
-Cahier de charge du Projet
|
Vérification,
Validation
et
Gestion
|
Initiation des Projets
|
Développement
|
Analyse et
Spécification
|
- Cahier de charge du logiciel
-Fiche de version du logiciel
-Document de conception
-Dossier de programmation
-Manuel d'utilisation
|
Conception
|
Implémentation et
test unitaire
|
Intégration et test
d'intégration
|
/
|
- Dossier de test d'intégration
|
Installation et test
système
|
/
|
-Dossier de test système
|
Chapitre 2
II.1 FONCTION DE LA MAINTENANCE DANS UNE STRUCTURE
II.1.1 Définition
L'entretien ou la maintenance est défini comme
étant « l'ensemble des actions permettant de maintenir ou de
rétablir un bien dans un état spécifié ou en mesure
d'assurer un service déterminé» (norme AFNOR X 60-010).
Entretenir, maintenir, c'est donc effectuer des opérations
(dépannage, graissage, visite, réparation, amélioration,
vérification, etc.) qui permettent de conserver le potentiel du
matériel pour assurer la continuité et la qualité du
service ainsi que la sécurité des opérations.
II.1.2 Importance et rôle de la
maintenance
L'importance et le rôle de la maintenance sont
illustrés par la nécessité d'assurer la
disponibilité permanente et le bon fonctionnement des installations
matérielles de production. Le rôle de la maintenance serait, en
définitive, de permettre aux structures hospitalières et autres
de remplir leurs fonctions en obtenant un rendement optimum.
II.1.3 Phases de la
maintenance
La planification de la maintenance se fait en trois phases
successives qui sont: le choix de l'équipement, son utilisation et la
gestion de la maintenance de l'équipement.
II.1.3.1 Choix de
l'équipement
Le choix de l'équipement, sa conception ou son achat,
marque le début de la planification de la maintenance. Elle est une
étape décisive, en ce sens que, une mauvaise décision
à cette étape peut avoir pour effet un entretien difficile,
fréquent et coûteux. Les différents aspects à
prendre en considération lors du choix sont: la maintenabilité,
la standardisation et la fiabilité.
II.1.3.2 Utilisation de l'équipement
C'est la deuxième phase de la maintenance où des
mesures et des observations sont effectuées afin de faire des
appréciations sur l'utilisation de l'équipement. On peut noter
dans cet aspect, une bonne ou mauvaise utilisation et une sous ou sur
utilisation de la machine qui en découle des exigences du constructeur
et parfois aussi du non-respect des planifications des maintenances faite par
le responsable en charge.
II.1.3.3 Gestion de la maintenance
La gestion de la maintenance qui est la troisième et
dernière phase de la maintenance, consiste à optimiser les
différentes activités d'entretien qui permettent au
système de production de produire à temps, la qualité et
la quantité d'unités requises, au meilleur coût. Ceci
nécessite la mise sur pied d'un système de gestion qui, à
l'aide de différentes données recueillies, fournit entre autres,
un programme d'entretien et divers rapports.
II.2 CONCEPT DE GMAO
Un système de GMAO est composé de champs, de
tables et de modules remplis de données fournies par le
département du génie biomédical ou d'équipement
d'un établissement donné. Un système de GMAO permet
d'accéder aux données essentielles, de les manipuler et de les
analyser au moyen d'interfaces faciles à utiliser. Les rapports
émanant du système peuvent aider les responsables des politiques
à prendre les décisions concernant les technologies de la
santé. Il convient toutefois d'examiner plusieurs facteurs avant de
décider d'adopter ou de concevoir un système de GMAO. Les
facteurs tels que les ressources financières et techniques jouent un
rôle important dans la décision d'acheter un produit commercial,
d'utiliser un logiciel libre, ou de concevoir un système sur place. La
mise en oeuvre passe par un certain nombre d'étapes qui permettront une
planification complète du système. Au terme de ce processus
échelonné, les options de déploiement auront
été évaluées en profondeur ; un système
adapté aura été choisi, installé et
personnalisé ; les données seront enregistrées ; et une
formation à la GMAO sera dispensée.
Les organisations dotées des ressources requises pour
la mise en oeuvre de cet outil tireront un grand profit de la GMAO. Bien
utilisé, cet outil d'une grande souplesse pourra transformer la gestion
de l'équipement biomédical tout en améliorant la
disponibilité et la fonctionnalité des technologies requises pour
prévenir, diagnostiquer et traiter les maladies.
II.3 LOGICIELS DE GMAO
II.3.1 Unigest
Unigest GMAO est un logiciel de gestion des
interventions dans le domaine du biomédicale. Nos clients
recherchent avant tout un outil simple et adapté à leur budget.
UNIGEST a été développé dans cet objectif et a mis
au point avec le partenariat de professionnels de haut niveau. La
priorité est de vous apporter un outil simple, convivial et puissant
à la fois. Basé conjointement sur une application Windows et une
interface web simple, le produit a pour vocation de saisir les interventions,
d'en gérer le traitement et de délivrer un historique clair.
II.3.2
AssetPlus
AssetPlus est une solution clef en main, unique, de gestion
pour toutes les directions hospitalières. Depuis plus de 15 ans,
AssetPlus propose des fonctionnalités de GMAO. adaptées aux
procédures et aux contraintes du milieu hospitalier. Sous l'impulsion de
ses utilisateurs, AssetPlus est devenu un véritable outil de
référence pour le suivi de la maintenance et des investissements
nécessaires au bon fonctionnement des institutions de santé. En
véritable ERP technique, AssetPlus permet le suivi complet du cycle de
vie de tous les actifs en agissant comme un microscope pour identifier,
analyser et corriger les dysfonctionnements.
II.3.3
Justification du choix de développement
Dans la mesure où toutes ses GMAO proposent des
solutions bien plus adaptées aux exigences du maître d'ouvrage qui
dans ce plan constitue déjà en l'objet d'un problème
lié à l'utilisation mais encore qui sont à des prix pas
très abordables, c'est alors qu'il nous a été
confié la tâche de mettre sur pied une application qui respectera
les exigences aussi bien professionnelles qu'académiques dans l'optique
d'un projet de fin d'études.
II.4 ARCHITECTURE ET TECHNOLOGIES À UTILISER
Vu que notre logiciel est une double application : une
application Java standard (JSE) en couche basée sur une
architecture 3-tiers et utilisant les technologies JPA/ Hibernate pour
l'administration et une application web en couche basée sur une
architecture 3-tiers, nous allons présenter les architectures et les
outils à utiliser.
II.4.1 Architecture
3-tiers
L'architecture 3-tiers est une architecture ou on retrouve
trois entités communicants ensemble. On peut avoir les cas suivant.
- Un client
- Un serveur d'application web (serveur web + moteur PHP) qui
répond aux requêtes http de l'utilisateur.
- Un système de gestion de base de données
(SGBD) qui traite et répond les requêtes qui lui sont
émises par le serveur d'application.
Figure1 :
Architecture 3-tiers
II.4.2 Architecture d'une application Java en couche
Afin de permettre l'indépendance et la
réutilisation des composants, nous avons opté pour une
architecture en couche. Ceci dit l'application sera divisée en cinq
couches.
Couche Données : cette couche
contient les données physiques stockées dans la base de
données MySQL. Elle ne requiert pas d'implémentation Java
particulière et fonctionne simplement comme un espace de consultation
massif.
Couche Mapping : cette couche
contient l'implémentation des accès à la base de
données afin de la masquer à la couche métier. Cette
couche est entièrement gérée par JPA.
Couche Métier : cette couche
contient les objets métiers de l'application. Il existe un objet par
fonctionnalité de l'application. Ces objets implémentent les
fonctionnalités spécifiques relatives à la location de
voitures, et font le lien entre la couche contrôleur et la couche
Mapping.
Couche Application : cette couche
contient la partie fonctionnelle de l'application. Elle s'appuie sur les objets
métier pour réaliser les actions sollicitées par
l'utilisateur par l'intermédiaire de la couche présentation. Elle
est en charge de vérifier la validité des requêtes de la
couche présentation.
Couche Présentation : cette
couche représente les interfaces qui permettent à utilisateur
d'interagir avec l'application.
Pour l'illustration, nous avons la figure suivante :
Figure2 :
Architecture d'une application java en couche
II.4.3
JPA/Hibernate
L'idée principale de JPA est que le développeur
n'ait besoin que de travailler avec de simples instances de classes et non pas
avec des requêtes SQL dont il doit ensuite passer le résultat.
Hibernate vient se placer entre la couche [dao] écrite
par le développeur et la couche [JDBC]. Hibernate est un ORM (Object
Relational Mapping), un outil qui fait le pont entre le monde relationnel des
bases de données et celui des objets manipulés par Java. Le
développeur de la couche [dao] ne voit plus la couche [JDBC] ni les
tables de la base de données dont il veut exploiter le contenu. Il ne
voit que l'image objet de la base de données, image objet fournie par la
couche [Hibernate]. La couche [Hibernate] est une couche d'abstraction qui se
veut la plus transparente possible. L'idéal visé est que le
développeur de la couche [dao] puisse ignorer totalement qu'il travaille
avec une base de données.
II.4.4 FPDF
FPDF est une bibliothèque PHP qui aide dans la
génération des états en fichier PDF. Il présente
l'avantage d'être assez flexible, bien documenté.
II.4.5 AJAX
La technique de développement Ajax
(acronyme d'Asynchronous JavaScript and XML) permet
de construire des applications Web et des sites web dynamiques interactives sur
le poste client. Ajax combine JavaScript, les CSS, XML, le DOM et le
XMLHttpRequest afin d'améliorer maniabilité et confort
d'utilisation des Applications Internet Riches.
II.4.1 Réplication MySQL
Depuis la version 3.23.15, MySQL supporte la
réplication unidirectionnelle interne. Un serveur sert de maître,
et les autres serveurs servent d'esclaves. Le serveur entretient des logs
binaires de toutes les modifications qui surviennent. Il entretient aussi un
fichier d'index des fichiers de logs binaires, pour garder la trace de la
rotation des logs. Chaque esclave, après connexion réussie au
serveur maître, indique au maître le point qu'il avait atteint
depuis la fin de la dernière réplication, puis rattrape les
dernières modifications qui ont eu lieu, puis met en attente des
prochains événements en provenance du maître. Un esclave
peut aussi servir de maître à son tour, pour réaliser une
chaîne de réplication.
Chapitre3
III.1 SPÉCIFICATION FONCTIONNELLE DE L'APPLICATION
III.1.1 Fonctions du système
- Module gestion des équipements : Le
système doit permettre l'ajout d'un équipement, enregistrer les
informations relatives au type de l'appareil et son emplacement physique.
Permettre la modification des données de l'équipement et le
retirer lorsqu'il est mis en rancart. Le système permettra de trouver
l'équipement selon son code ou sa variété.
- Module gestion des pièces
détachées : Le système permettra d'ajouter dans la
banque de données toutes les pièces qui s'avéreront un
jour nécessaire pour une intervention et permettra aussi de faire une
décrémentation quand celle-ci sera utilisée.
- Module gestion des fournisseurs : Le système
permettra aussi d'enregistrer les fournisseurs en fonctions des services
offerts et des types de partenariat.
- Module gestion des interventions : Le système
gérera toute intervention qui surviendra sur équipement, il
permettra d'accéder en interne à une fiche de suivi, d'y associer
un nom d'utilisateur (pour bien gérer les historiques) avant d'y
apporter certaines informations relatives au travail à accomplir. Il
permettra aussi de planifier la maintenance préventive. Trois types de
droits pourront être attribués : usager, technicien et
administrateur.
- Module gestion des bons de commande : Ce module
permettra à l'administrateur de directement ressortir les états
afin de contacter les fournisseurs pour passer des commandes bien
précises.
- Module gestion des techniciens : Ce module permettra
à l'administrateur de créer et d'effectuer les mises à
jour sur les techniciens ; c'est-à-dire création, affection
dans un centre, suivi ...
- Module Statistiques : Ce module permettra de faire
ressortir l'historique et certains diagrammes de toutes les opérations
qui seront effectuées via cet outil afin d'avoir les rapports sur les
différents modules.
III.1.2 Description des utilisateurs
Ce système a plusieurs types d'utilisateurs avec des
droits d'accès différents et des restrictions d'utilisation qui
seront définies aux niveaux de la couche présentation et de la
couche application.
Ø Administrateur
Il est le super-utilisateur qui aura les droits d'accès
à tous les différents modules ainsi qu'à leurs fonctions.
Il pourra ainsi créer les autres utilisateurs et charger les
informations dans l'application « GMABIO » afin de rendre
l'application opérationnelle pour les autres utilisateurs.
Ø Technicien
Il est le personnage ayant le deuxième droit
d'accès le plus élevé derrière l'administrateur lui
permettant ainsi de renseigner toutes ses interventions et d'effectuer
d'autres tâches en fonction des droits qui lui sont associés.
Ø L'usager (responsable de centre)
Il appartient à un centre et c'est donc via ce centre
qu'il accède à l'application lui permettant ainsi d'effectuer une
seule opération primordiale celui de déclarer une panne (demande
d'intervention) mais en plus il pourra avoir accès à la liste des
demandes d'intervention liées à son centre.
III.1.3 Fonctions liées aux droits d'accès
- L'utilisateur
Ses droits lui permettent juste de faire une demande
d'intervention et d'afficher toute la liste de toutes les demandes faites par
le centre auquel il est rattaché et commande les équipements.
- Le Technicien
Le technicien pourra accéder de façon
générale à des modules tels que :
ü Equipements
ü Interventions
ü Pièces Détachées
ü Statistiques
Mais alors l'accès à ces modules ne sera que
partiel car certains de ces modules leur permettra juste de bien renseigner
leur opération d'intervention. Il s'agit des modules : Equipement
(où ils pourront accéder à la liste des équipements
se trouvant dans le centre où ils sont affectés), pièces
détachées (qui leur permettra de changer les pièces
défectueuses sur les équipements en panne) et statistiques (pour
avoir certains rapports sur certaines fonctions les concernant directement).
Le module Interventions est le seul module qui pourra
être totalement parcouru par un technicien.
- Administrateur
En ce qui concerne ce dernier il possède tous les
droits sur les modules du système. Et c'est lui qui rend le
système utilisable.
III.2 EXIGENCES SPÉCIFIQUES
Dans cette partie, les exigences du système seront
définies de façon détaillée. Le niveau de
détail permettra de procéder à la conception du
système.
III.2.1 Interfaces externes
Cette section a pour but de décrire les
différentes interfaces qu'offre ou nécessite le système
GMABIO Solutions.
III.2.1.1 Interface usagers
o Client
L'interface usager est sous la forme WEB accessible via le
site web du département à l'aide du navigateur Mozilla Firefox de
préférence. Avant de pouvoir utiliser les fonctionnalités
du système, l'usager devra s'authentifier à l'aide de son login
et mot de passe en ce qui concerne le « technicien » et d'un mot de
passe uniquement (mot de passe attribué par hôpital que seuls les
employés d'une firme devraient savoir) pour l ' « utilisateur
simple » bien sûr après avoir précisé
l'hôpital où il est en fonction.
o Administrateur
L'interface administrateur est sous forme «Windows
classique» installé sous sa machine. Avant de pouvoir utiliser les
fonctionnalités du système, l'usager devra s'authentifier
à l'aide de son login et mot de passe.
III.2.1.2 Interfaces matériels
On devra installer par centre des postes clés qui
seront connectés à internet afin de permettre aux
différents clients de pouvoir atteindre l'application
hébergée.
III.2.1.3 Interfaces aux logiciels
La partie cliente du système aura un hyperlien sur le
site web du département santé et offrira une interface WEB
accessible via Mozilla Firefox tandis que le système administratif
résidera sur la machine de l'administrateur.
III.2.1.4 Interfaces de communication
o . Client
A partir des postes client connecte au réseau internet,
il sera possible d'accéder au site web.
o Administrateur
A partir de son poste connecte au réseau internet,
l'administrateur sera capable d'accéder à la base de
données distante via son application.
III.2.2 Spécification des cas d'utilisations
Diagramme des cas d'utilisation du système
Figure3 : Diagramme
des cas d'Utilisation
Ø Fonctions du module d'Inventaire DM (gestion
des équipements)
But :
Ces fonctions permettent de gérer les dispositifs
médicaux des hôpitaux du département et offrent des
techniques de recherche.
- Afficher équipements
· Fiche cas d'utilisation
Acteur(s): Administrateur, technicien
Description: Ce cas d'utilisation est
déclenché par un acteur. Il lui permet de consulter les
dispositifs médicaux auxquels il est rattaché.
Dépendances: AUTHENTIFIER
Pré-condition : L'acteur doit
être authentifié.
Post-condition : La liste des DM est
affichée à l'écran. Cette liste contient les informations
suivantes concernant les DM: nom, emplacement, code CNEH, numéro de
série, date de mise en service et le type.
Raisons : Pour aider l'administrateur du
système dans le processus d'acquisition de nouveaux équipements
et de remplacements ceux qui sont en pannes.
Exceptions :
Ligne 2 : Si la liste est vide, le système affiche
un message «aucun équipement » indiquant qu'il n'a
trouvé aucun équipement.
·
Diagramme de séquence
Figure4 : Diagramme
de séquence « Afficher liste Equipement »
- Afficher
équipements Hors-services
· Fiche
cas d'utilisation
Acteur(s): Administrateur, technicien
Description: Ce cas d'utilisation est
déclenché par un acteur. Il lui permet de consulter tous les
équipements qui sont hors service.
Dépendances: AUTHENTIFIER
Pré-condition : L'acteur doit
être authentifié.
Post-condition : Une liste des
équipements qui sont hors services est affichée à
l'écran. Cette liste contient les informations suivantes concernant les
équipements: nom, emplacement, code CNEH, numéro de série,
date de mise en service et le type.
Raisons : Pour aider l'administrateur du
système dans le processus d'acquisition de nouveaux équipements
et de remplacer ceux qui sont en panne.
Exceptions :
Ligne 2 : Si la liste est vide, le système affiche
un message «aucun équipement hors service» indiquant qu'il n'a
pas trouvé les équipements dont le critère de
recherche : staut de l'équipement = `hors service'.
- Ajouter
équipement
· Fiche
cas d'utilisation
Acteur(s): Administrateur
Description: Ce cas d'utilisation est
déclenché par un acteur. Il lui permet d'ajouter un
équipement.
Dépendances: AUTHENTIFIER
Pré-condition : L'acteur doit
être authentifié.
Post-condition : La fiche de
l'équipement est créée et sauvegardée dans la base
de données.
Exceptions :
Ligne 4: Si le nom existe déjà, le
système affiche un message d'erreur et le traitement est interrompu.
- Supprimer
équipement
· Fiche
cas d'utilisation
Acteur(s): Administrateur.
Description: Ce cas d'utilisation est
déclenché par un acteur. Il lui permet de supprimer un
équipement.
Dépendances: AUTHENTIFIER
Pré-condition : authentification de
l'acteur réussie
Post-condition : L'équipement est
supprimé.
Post-condition : la suppression de
l'équipement est effectué.
- Recherche
d'équipements selon un attribut
· Fiche
cas d'utilisation
Acteur(s): Administrateur, Technicien
Description: Ce cas d'utilisation est
déclenché par un acteur. Il lui permet de rechercher un
équipement à partir d'un attribut qui sera spécifié
par l'acteur.
Dépendances: AUTHENTIFIER
Pré-condition : L'acteur doit
être authentifié.
Post-condition : La fiche de description
de l'équipement est affichée s'il s'agit d'un
élément à retourner ou une liste s'il s'agit de plusieurs
équipements.
Exceptions :
Ligne 2: Si un équipement identifié par
l'attribut spécifié n'existe pas, affichage d'un message
avertissant l'usager de la situation.
Recherche Avancée
d'équipements
· Fiche
cas d'utilisation
Acteur(s): Administrateur, Technicien
Description: Ce cas d'utilisation est
déclenché par un acteur. Il lui permet de rechercher avec plus
de précision un équipement.
Dépendances: AUTHENTIFIER
Pré-condition : L'acteur doit
être authentifié.
Post-condition : La fiche de description
de l'équipement est affichée.
Exceptions :
Ligne 3 : Si un équipement identifié par un
ou plusieurs attributs choisis n'existe pas, affichage d'un message avertissant
l'usager de la situation.
Ø Fonctions du module de gestion des
interventions
But :
Ces fonctions permettent de gérer les interventions.
-
Prévention maintenance
· Fiche
cas d'utilisation
Acteur(s): Administrateur
Description: Ce cas d'utilisation est
déclenché par un acteur. Il lui permet de planifier les dates
d'interventions pour la maintenance préventive.
Dépendances: AUTHENTIFIER
Pré-condition : l'acteur doit
être autorisé à l'aide de son identificateur utilisateur et
son mot de passe.
Post-condition : les informations de
prévention sont enregistrées.
- Commencer
Intervention
· Fiche
cas d'utilisation
Acteur(s): Administrateur, technicien
Description: Ce cas d'utilisation est
déclenché par un acteur. Il lui permet de renseigner les
informations concernant l'intervention qu'il effectue.
Dépendances: AUTHENTIFIER
Pré-condition : l'acteur doit
être autorisé à l'aide de son identificateur utilisateur et
son mot de passe, une panne doit être déclarée.
Post-condition : une fiche d'intervention est
créée.
Ø Fonctions du module de gestion demander
intervention
But :
Ces fonctions permettent de gérer les
déclarations de panne.
-
Déclaration de panne
· Fiche
cas d'utilisation
Acteur(s): Utilisateur
Description: Ce cas d'utilisation est
déclenché par un acteur ou par le système lorsque la date
de maintenance préventive est arrivée. Il lui permet de
déclarer une panne survenue sur un équipement.
Dépendances: AUTHENTIFIER
Pré-condition : l'acteur doit
être autorisé à l'aide de son identificateur utilisateur et
son mot de passe.
Post-condition : confirmation de
déclaration.
III.3 MODÈLE OBJET DU SYSTÈME
III.3.1 Diagramme de classe du module gestion des
interventions
Figure5 : Diagramme
de classe « module Intervention »
III.3.2 Diagramme de classe du module gestion des
équipement
Figure6 : Diagramme
de classe « module Equipement »
III.3.3 Règles de gestion
Les règles de gestion décrivent la nature des
relations entre les entités d'un système d'information.
L'ensemble de ces règles permet de définir un système
correspondant à une problématique métier
précisément adaptée aux besoins du client. Ces
règles de gestion sont utilisées directement dans le
modèle métier : chaque règle correspond à une
relation entre 2 (ou plusieurs) entités.
R1 : un type d'équipements rassemble un ou plusieurs
dispositifs médicaux.
R2 : un technicien ne peut intervenir que sur un
équipement qui a été l'objet d'une demande
d'intervention.
R3 : un technicien ne peut avoir accès qu'aux
interventions dont il est le coordonnateur.
R4 : plusieurs techniciens peuvent intervenir sur
équipements dans le cadre où le premier technicien a
recommandé un autre ou encore si l'administrateur a décidé
de s'occuper d'un équipement qui faisait déjà l'objet
d'une intervention.
R5 : un prestataire extérieur ne peut avoir
accès à l'application, il doit avoir recourt à un
technicien pour faire suite à une intervention faite sur
équipement.
R6 : un équipement peut bénéficier d'un
seul contrat partenaire.
R7 : le prix unitaire d'une pièce
détachée est le prix unitaire du dernier stock entré au
magasin.
III.4 EXIGENCES D'OPÉRATIONS, DE
COMMUNICATIONS ET DE PERFORMANCE
Le flot de données entre les clients et le serveur web
n'est pas excessif, on négligera le trafic occasionné par l'outil
puisque la bande passante de la connexion internet sera de 256kbps.
III.5 EXIGENCE DE LA BASE DE DONNÉES
III.5.1 Modèle Conceptuel de
données
La représentation du système d'information a
été réalisée à l'aide du diagramme de classe
et de la méthode MERISE. Cette méthode nous a permis de
réaliser le Modèle Conceptuel de Données ou MCD, qui fait
le lien entre le modèle métier et le modèle logique. Le
MCD est un modèle dit « entités-relations » qui
modélisent l'ensemble des règles de gestion et des contraintes du
système. Il correspond globalement au modèle métier, en
détaillant le contenu des entités métiers (attributs).
La construction du MCD a été
réalisée à partir des spécifications du cahier des
charges, du modèle métier et des réunions avec le
maître d'ouvrage. Celui-ci a été
généré grâce au logiciel Win Design, qui permet de
transformer le MCD en MLR et de générer le script de la base de
données correspondant.
III.6 CONCEPTION DE L'APPLICATION
III.6.1 Domaine d'Application
L'objectif de ce projet est de fournir un système
destiné à gérer le parc des DM des hôpitaux et
centres médicalisé du département santé de l'EEC.
Ce système contient deux applications, une application d'administration
installée au siège du département, et une application web
héberger sur le web et accessible via un navigateur.
L'application d'administration permet d'avoir une vue global
sur le système, de gérer et de contrôler le travail des
techniciens sur le terrain tout en centralisant les informations sur les DM se
trouvant dans les différents hôpitaux.
L'application web permet au technicien sur le terrain de
renseigner leurs activités, d'avoir les informations sur les DM et aux
usagers de déclarer les pannes.
III.6.2 Architecture du système
Figure7 :
Architecture générale de l'application GMABIO Solution
III.6.3 Langages utilisés
Voici la liste des différents langages utilisés
dans le projet GMABIO Solution:
- SQL pour les scripts de création de
la base de données (création de tables et insertions des tuples
dans la BD) ainsi que pour les requêtes spécifiques de l'AM.
- Java pour le développement de
l'application administrative.
- HTML 5, CSS 3, PHP et
JavaScript 2.0 pour le développement de l'application
cliente.
- XML pour les fichiers de configuration
Spring, JPA.
III.6.4 Diagramme de déploiement
Figure8 : Diagramme
de déploiement
III.6.5 Architecture Générale du
système
Chaque application bénéficie d'une architecture
séparée, où le seul point commun est la base de
données centrale. Dans ce paragraphe, nous allons nous attarder sur les
problèmes d'architecture fondamentaux du système. Tous les autres
choix de conception sont expliqués dans le chapitre « Conception
détaillée ».
Figure9 :
Architecture générale du système
III.6.5.1 Architecture 4 couches pour
l'application administrative
L'application nationale est divisée en quatre couches
de fonctionnalités, totalement autonomes les unes des autres, et
communiquant par un système de file : chaque couche ne dialogue qu'avec
les couches voisines supérieure et inférieure. Toutes les couches
doivent agir de façon transparente les unes des autres. La
séparation des couches est la suivante :
Couche Données : cette couche
contient les données physiques stockées dans la base de
données MySQL. Elle ne requiert pas d'implémentation Java
particulière et fonctionne simplement comme un espace de consultation
massif.
Couche Mapping : cette couche
contient l'implémentation des accès à la base de
données afin de la masquer à la couche métier. Cette
couche est entièrement gérée par JPA.
Couche Métier : cette couche
contient les objets métiers de l'application. Il existe un objet par
fonctionnalité de l'application. Ces objets implémentent les
fonctionnalités spécifiques relatives à la location de
voitures, et font le lien entre la couche contrôleur et la couche
mapping.
Couche Présentation : cette
couche représente les interfaces qui permettent de présenter les
contenus générés par la couche métier, grâce
à des vues dynamiques (JAVA). Elle se charge d'afficher des contenus
à l'utilisateur et de lui offrir des interfaces avec la couche
contrôleur pour interagir avec l'application.
Figure10 :
Architecture application d'administration
III.6.5.2 Synchronisation des
données
La problématique de la synchronisation prend une part
importante dans la conception du système et notamment de la base de
données et des parties applicatives. Pour rappel ces synchronisations
interviennent lorsque l'administrateur veut faire coïncider les
données qu'il possède sur sa machine avec celles stockées
en base de données centrale (sur le serveur distant). Le cas
d'utilisation type se présente ainsi :
- Au démarrage du logiciel, l'application
administrative se synchronise avec la base MySQL pour avoir des données
à jour ;
- Lors de ses déplacements (vers une zone sans
connexion), il peut consulter, modifier, insérer ou supprimer (ou tout
autre opération possible) des données chargées dans la
base de données sans connexion réseau ;
- Et une fois la connexion retrouvée, l'application
administrative se chargera de synchroniser ses mises à jour et de
récupérer celles des autres
III.6.5.3 Architecture de l'application
cliente
Sur l'application cliente, la stratégie adoptée
est d'utiliser un modèle en couches similaire. Cependant, la taille de
l'application n'impose pas une séparation aussi fine que l'application
nationale. Nous appliquons donc un modèle à 3 couches
organisées comme suit :
Couche Présentation : cette couche
effectue la présentation des données à l'utilisateur par
l'intermédiaire de formulaires et de listes de données
interactives. L'utilisateur accède à l'application par cet unique
moyen ; elle est développée en HTML5-CSS3.
Couche Métier : de même que pour
l'application administrative, cette couche contient d'une part les objets
métier, correspondant aux données métier à
manipuler dans l'application, d'autre part, les services métiers
reliés à ces objets (création, recherche, suppression,
modification et autres services spécifiques). A l'image de l'application
administrative, cette couche s'occupe de garantir que le métier de
l'application est respecté, que les règles liées aux
données sont toujours suivies. Dans cette couche, on retrouve
également les méthodes d'accès à la base de
données (présentes dans la couche Données dans
l'application administrative).
Couche Données : cette couche contient
les données physiques stockées dans la base de données
MySQL. A ce niveau, tenant compte du fait qu'on aura deux bases de
données (une locale et l'autre distante) nous allons dans le cadre d'une
mise à jour des bases de données gérer la fonction de
réplication de bases de données pour résoudre les demandes
à satisfaire par ce service.
Figure11 :
Architecture application cliente
III.6.5.4 Gestion
des Erreurs
Lorsqu'une erreur est rencontrée par un
contrôleur, il place un message d'erreur dans le modèle. Celui-ci
sera ensuite automatiquement affiché à l'utilisateur par la
couche présentation.
Ø
Compatibilité Firefox/Internet Explorer
La problématique de compatibilité entre les deux
navigateurs les plus utilisés par les internautes doit être prise
en compte très tôt, car ce sont surtout les styles CSS qui doivent
être écrits avec ces contraintes. En effet, certains styles ne
sont reconnus que par l'un ou l'autre des navigateurs. La feuille de style a
été définie dès l'établissement des
maquettes des écrans. Elle peut donc être utilisée tout au
long du développement pour être testée.
Ø
Authentification utilisateur
L'application GMABIO comporte une interface de gestion
destinée à gérer les différents processus du
département Santé EEC. Cette partie de l'application n'est pas
destinée à être accessible par une personne
extérieure. L'authentification des employés est donc
nécessaire.
Les connexions utilisateurs sont effectuées par
identification classique : login et mot de passe. Ces informations sont
stockées dans la base de données, leur vérification est
donc immédiate lors de l'authentification de l'utilisateur.
Ø
Gestion des droits d'utilisateurs
Au sein du département, il existe plusieurs
catégories d'employés qui n'ont pas accès aux mêmes
fonctionnalités. Les groupes d'employés considérés
sont les suivants :
- Chef service maintenance (administrateur)
- Techniciens
- utilisateur (celui en charge d'un dispositif
Médical
Il est possible de définir des fonctionnalités
au sein de l'application. Celles-ci pourront, pour chaque type
d'employé, contenir le type d'autorisation d'accès défini.
Par exemple, les techniciens n'auront pas accès aux fonctions
liées à leur gestion ni d'autant plus à la gestion des
différents centres. La solution est donc de stocker une matrice
fonction/types d'utilisateurs qui permettra de savoir à un moment
précis quels droits sont accordés à tel type d'utilisateur
pour telle fonctionnalité.
Ø
Sessions utilisateurs
L'authentification d'un utilisateur conduit à
l'ouverture d'une session qui permettra à celui-ci de naviguer sur tout
le site sans devoir s'identifier à chaque page. La technologie
employée pour la réalisation du site permet de définir une
session utilisateur contenant un nombre quelconque de variables de sessions,
définies et existantes pendant toute la durée de la session.
Il est important de conserver le login (ou le nom
associé) de l'employé connecté, pour des raisons de
traçabilité. Les droits alloués à cet utilisateur
doivent être conservés. On conserve donc les droits
associés au type d'utilisateur auquel appartient l'employé. Lors
de la connexion de l'utilisateur, une entité contenant les droits de
celui-ci sera donc initialisée pour la session ouverte.
Ø
Gestion interne de l'authentification
Il convient de détailler les différents
composants qui rentrent en jeu lors d'une authentification utilisateur. Lors de
la soumission du formulaire d'identification par l'utilisateur, une
première vérification est effectuée, permettant de
s'assurer que ni le champ de mot de passe, ni le champ de login ne sont vides.
Ensuite, les données sont comparées avec les données
stockées en base :
- vérifier que le mot de passe correspond bien à
l'utilisateur ;
- dans le cas où le mot de passe est erroné,
rediriger vers le formulaire avec une notification d'erreur ;
- dans le cas où le mot de passe est correct, charger
les droits de l'utilisateur et rediriger vers la page d'accueil de
l'application.
Chapitre 4
IV.1 ENVIRONNEMENT
DE TRAVAIL
L'environnement de développement utilisé pour
développer les applications a été Netbeans 6.9 qui est un
IDE proposant tous les outils nécessaires à la création
d'applications professionnelles avec les langages Java, C / C++, JavaScript,
Ruby, PHP et HTML. En plus il permet une intégration facile des
Framework comme JPA et Hibernate. Nous avons aussi utilisé EASYPHP qui
intégre un serveur web (Apache), un interpréteur PHP avec le
serveur de base de données MYSQL.
IV.2 DEMARCHE DE TRAVAIL
Après avoir spécifié et conçu le
logiciel, nous avons créé un projet nommé
« GMABIO » sous Netbeans 6.9, nous avons créé
les paquetages « Entity»,
« Dao », « IHM »,
« Application »
- Paquetage « Entity»
Dans ce paquetage on crée une classe « Entity
Classes from Database » qui permet après configuration
d'éffectuer le Mapping entre la base de données et le projet,
elle génère également les objets Persistants et le
fichier persistence.xml.
- Paquetage « Dao»
Qui contient les classes Data Access Object des classes Entity
généré par mapping. Ces classes permettent l'accès
aux données des objets persistant.
- Paquetage « IHM »
Ce paquetage contient les classes des différentes
interfaces de l'application d'administration.
- Paquetage « Application »
Il contient les classes de la couche application qui assure
l'interaction entre les interfaces et les Dao.
Représentation des paquetages
Figure12 :
Arborescence des paquetages
IV.3
DIFFICULTÉS RENCONTRÉS
Dans le développement de l'application
« GMABIO Solution » nous avons rencontré plusieurs
difficultés parmi lesquelles :
- La communication des deux bases de données (mise
à jour)
- La gestion des interfaces
- La gestion des MVC
IV.4
RÉSULTATS OBTENUS
- Application d'administration
· Connexion
Figure13 : Interface
de connexion application d'administration
· Fenêtre du Module gestion des Equipements
- Fenêtre de choix de l'opération
Figure14 :
Fenêtre de choix de l'opération « module gestion
équipements »
- Fenêtre fiche équipement
Figure15 : Interface
fiche équipement
- Fenêtre de contrat de maintenance d'un
équipement
Figure16 : Interface
contrat maintenance « module gestion
équipement »
- Application Cliente
· Connexion
Figure17 : Interface
connexion application cliente
· Fenêtre Commencer Intervention
Figure18 : Interface
commencer Intervention
Ce projet de fin d'étude est à cheval entre
l'informatique qui est notre première compétence et la
maintenance qui est aussi l'un des aspects de notre formation. Ce travail nous
a permis, d'une part, d'approfondir nos connaissances en conception des
systèmes d'informations, développement des applications 3 tiers
et d'autre part de renforcer notre esprit d'organisation et de gestion du
patrimoine technique des centres médicalisées mais aussi de
profiter de l'expérience professionnelle de notre encadreur aussi bien
en maintenance biomédicale qu'en management. Tout au long de ce projet,
nous avons pu suivre le processus de maintenance d'un dispositif médical
ce qui nous a donné les moyens nécessaires à la conception
de notre solution « GMABIO Solution ».
Destiné à résoudre les problèmes
de traçabilité des activités de maintenance,
« GMABIO Solution» peut s'adapter à la plupart des
structures médicales de la place.
Lors de la programmation de cette solution nous avons
porté une grande attention à sa simplicité d'exploitation
(par un environnement intuitif et des contrôles de saisi) afin de
permettre au technicien ou à un utilisateur qui n'a pas de notion en
informatique de s'adapter très vite; Cependant, comme tout travail
humain, le nôtre peut comporter des imperfections et nous sommes ouverts
aux critiques et suggestions en vue de l'améliorer.
Notre ambition est de faire évoluer « GMABIO
Solution » en ajoutant d'autres fonctionnalités comme la
gestion de tout le personnel technique, la commande d'équipements et de
pièces détachées en ligne etc.
I. Référence
bibliographique
- Apprenez à programmer en Java - site du zéro -
cysboy et John-John
- Cours de génie logiciel dispensé par Monsieur
TAKOUDJOU Alexis pour l'année scolaire 2011-2012
- Développer en AJAX - Michel Plasse - Eyrolles
- Java Persistance et Hibernate - Anthony Patricio - Eyrolles
2008
- Manuel de référence MySQL 5.0
- Système de gestion de maintenance assistée par
ordinateur Série technique de l'OMS sur les dispositifs médicaux,
2012 ISBN 978 92 4 250141 4
II. Site web
- Encyclopédie en ligne - www.wikipedia.com
- Site web du logiciel Unigest, une GMAO -
http://www.unigest.fr/index.php
- Notice simplifiée d'utilisation de votre gmao en ligne -
http://www.biomesnil.com
Ø Cahier de charge :
conception et Implémentation d'une GMAO pour le département
santé de l'EEC.
Ø Document de spécification des exigences
logiciel : conception et Implémentation d'une GMAO pour le
département santé de l'EEC.
Ø Document de conception : conception et
Implémentation d'une GMAO pour le département santé de
l'EEC.
Ø Fiche d'intervention générer par
« GMAOBIO Client »
|