WWW Memoireonline Com 12 13 8186 Conception Et Implementatio

Rechercher sur le site:
Recherche
Home | Publier un mémoire | Une page au hasard
Memoire Online > Informatique et Télécommunications

Conception et implémentation d'une GMAO ( gestion de maintenance assistée par ordinateur )
pour le département santé de l'Eglise Evangélique du Cameroun ( Télécharger le fichier original ) Disponible en
par Jean- Pierre et Flavien Boris Kamga et Ngomne Bouwa mode multipage
Université des montagnes Cameroun - En vue de l'obtention d'une licence de technologie en génie informatique option informatique et réseaux 2012
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
Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
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,
Initiation des Projets Validation
Développement Analyse et - Cahier de charge du logiciel
et
Spécification -Fiche de version du logiciel
Gestion
Conception -Document de conception
Implémentation et -Dossier de programmation
test unitaire -Manuel d'utilisation
Intégration et test / - Dossier de test d'intégration
d'intégration
Installation et test / -Dossier de test système
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
Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet de consulter tous les équipements qui sont hors service.
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.
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.
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.
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.
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.
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
Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet de renseigner les informations concernant l'intervention qu'il effectue.
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.
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 »
Rechercher sur le site:
Recherche
Verify to continue
We detected a high number of errors from your connection.
To continue, please confirm that you’re a human (and not a
spambot).
I'm not a robot

reCAPTCHA
Privacy - Terms
9Impact, le film from Onalukusu Luambo on Vimeo.
Verify to continue
We detected a high number of errors from your connection.
To continue, please confirm that you’re a human (and not a
spambot).
I'm not a robot

reCAPTCHA
Privacy - Terms
BOSKELYWOOD from Ona Luambo on Vimeo.
J22 - pause à Cahors
Watch later Share
© Memoire Online 2000-2019

Pour toute question contactez le webmaster

Langue

WWW Memoireonline Com 12 13 8186 Conception Et Implementatio

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

WWW Memoireonline Com 12 13 8186 Conception Et Implementatio

Transféré par

Droits d'auteur :

Rechercher sur le site:

Home | Publier un mémoire | Une page au hasard

Memoire Online > Informatique et Télécommunications

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

RAPPORT DE PROJET DE FIN D'ETUDES

Conception et Implémentation d'une GMAO pour le

- Ngomne Bouwa Boris Flavien Mat : 09C048

Sous l'Encadrement Académique de :

Sous l'Encadreur Professionnel de:

Bangangté Octobre 2012

Nous dédions ce modeste travail à

Nos chers parents

Nos frères et soeurs

Ainsi qu'à tous ceux qui nous sont chers.

ï M. Takoudjou Alexis Professeur à l'université des montagnes ;

TABLE DES MATIERES

TABLE DES MATIERES 6

LISTE DES FIGURES 8

LISTE DES CYCLES ET ABRÉVIATIONS 9

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.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.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.3 Justification du choix de développement 16

II.4 ARCHITECTURE ET TECHNOLOGIES À UTILISER 16

II.4.2 Architecture d'une application Java en couche 16

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.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

II. Site web 42