WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


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

 > 

Conception et implémentation d'une base de données dynamique et partagée de gestion clinique


par Eddy MUGISHO IMANI
Institut supérieur d'informatique et de gestion de Goma - Licence 2009
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

CHAPITRE II.  RECHERCHE METHODOLOGIQUE ET ANALYSE

DU SYSTEME EXISTANT

2.1. METHODOLOGIE

2.1.1. INTRODUCTION

Une méthodologie est cet ensemble des techniques, méthodes et procédures adoptées en terminologie pour arriver au but d'une recherche.31(*)

2.1.2. METHODES DU TRAVAIL

La méthode hypothético-déductive a été choisie pour l'élaboration de ce sujet. Comme méthode scientifique elle nous a aidé à formuler des hypothèses afin d'en déduire des conséquences observables futures mais également passées permettant d'en déterminer la validité.

La méthode analytique  nous a aidé à diviser l'analyse du problème apparemment complexe en sous problèmes plus simples.

2.1.3. TECHNIQUE

Comme opération, une technique recouvre tout travail fait avec une certaine méthode, en vue d'atteindre un certain résultat et comme phénomène elle est la préoccupation de l'immense majorité des hommes de notre temps de rechercher en toutes choses la méthode absolument la plus efficace.32(*)

Pour le cas précis de notre travail, nous nous sommes servis de la technique documentaire dans le parcourt des différents documents mis à notre disposition par le CSMR/C et autres ouvrages de la bibliothèque ainsi que les sites Internet en rapport avec notre sujet. Et la technique d'interview libre nous a permis de poser des nombreuses questions, formulées et non formulées, aux personnes qui pouvaient détenir de l'information qui nous a aidé à modéliser le système d'information du CSRM/C.

2.2. DEFINITION DES EXIGENCES METHODOLOGIQUE DU PROJET

2.2.1. INTRODUCTION

Le système devra exiger une méthodologie prototype dans un bon ordre afin de conduire le projet et d'atteindre les objectifs établis précédemment. Le model de développent retiendra que les besoins évoluent au rythme de l'organisation. Une organisation très réactive par rapport aux besoins du marché sera plus sujette qu'une autre à une évolution rapide des besoins en cours de projet. D'autre part, des besoins définis par des utilisateurs qui ont parfois du mal à se représenter les solutions qui en découlent seront également susceptibles d'évolutions tardives.

2.2.2. MODELE DU DEVELOPPEMENT DU PROJET

2.2.2.1. INTRODUCTION

Modéliser une application n'est pas une activité linéaire, il s'agit d'une tâche très complexe, qui nécessite une approche itérative et incrémentale, car il est plus efficace de construire et valider par étapes, ce qui est difficile à cerner et à maîtriser. Cette modélisation est centrée sur l'architecture et est guidée par la prise en compte des besoins des utilisateurs qui motivent l'existence même du système à concevoir.

2.2.2.2. MODELE DE LA TRANSFORMATION AUTOMATIQUE

Dans ce modèle la transformation des spécifications en code n'intervient que lorsque les spécifications sont complètement définies.

DUT

Définition des Spécifications besoins

Réalisation

Expérimentation

Fig 2. Modèle de la transformation automatique

2.2.3. LES CYCLES DE CONSTRUCTION DU SYSTÈME

Le développement d'un logiciel est vu comme un processus graduel d'élimination de risques. A chaque itération, on refait les spécifications, la conception, l'implémentation et les tests.

Fig. 3. Processus graduel du développement d'un logiciel

Les risques majeurs sont traités en priorité. Chaque itération donne lieu à un incrément et produit une nouvelle version exécutable.

2.2.4. PHASES DU MODEL PROTOTYPE

2.2.4.1. EXIGENCE D'ANALYSE

Une démarche d'analyse et de conception objet est nécessaire afin de ne pas effectuer une analyse fonctionnelle et se contenter d'une implémentation objet, mais penser objet dès le départ, définir les vues qui permettent de décrire tous les aspects d'un système avec des concepts objets. Il faut donc disposer d'un outil qui donne une dimension méthodologique à l'approche objet et qui va permette de mieux maîtriser sa richesse.

2.2.4.2. ANALYSE RÉDUCTIONNISTE

Elle va consister à décomposer les systèmes biologiques en niveaux d'organisation et en unités élémentaires, les plus petites et les plus simples possible. Puis à chaque niveau d'organisation, chacune de ces unités élémentaires sera étudiée en détail par une discipline spécialisée, afin de comprendre sa structure et son fonctionnement.

2.3. OUTILS DE SUPPORT D'ANALYSE

2.3.1. INTRODUCTION

La principale avancée des quinze dernières années réside dans la programmation orientée objet (P.O.O.). Face à ce nouveau mode de programmation, les méthodes de modélisation classique telle que MERISE ont rapidement montré certaines limites. De très nombreuses méthodes ont également vu le jour. Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception « Orientée objet », l'Object Management Group (OMG) a eu comme objectif de définir une notation standard utilisable dans les développements informatiques basés sur l'objet. C'est ainsi qu'est apparu UML (langage de modélisation objet unifié «Unified Modified Language »), Issu du terrain et fruit d'un travail d'experts reconnus, UML favorise donc le prototypage, et c'est là une de ses forces.

2.3.2. CHOIX D'UML QUE DE MERISE

Il n'est cependant pas très intéressants d'établir des liens de correspondance entre les modèles de MERISE et d'UML car les 2 modèles ne sont pas réalisés avec les mêmes objectifs et n'utilisent pas toujours les mêmes concepts. MERISE permet de modéliser le métier de l'entreprise indépendamment des techniques, aux niveaux conceptuel et organisationnel. Le système informatique est un sous-ensemble du système d'information. Les modèles sont progressivement élaborés et enrichis, et constituent des supports de communication et de participation pour les utilisateurs. UML présente des caractéristiques voisines. Les modèles basés sur un nombre déterminé de diagrammes en fonction de la vue sont progressivement enrichis. Mais UML reste incontournable si l'entreprise veut utiliser les techniques objets.

2.3.3. CYCLE DE CONSTRUCTION DU SYSTEME D'INFORMATION EN UML

A. Cycle de vie

Le cycle de développement sous-jacent est itératif et incrémental, guidé par les cas d'utilisation et centré sur l'architecture.

B. Cycle d'abstraction 

Laisse le soin de présenter les diagrammes cohérents qui contiennent des objets de même niveau de préoccupation et modélise le système aux différents niveaux d'abstraction.

C. Cycle de décision 

Il concerne les différentes décisions et choix qui sont effectués tout au long du cycle de vie, et permet de faire valider petit à petit le système que l'on est en train de construire en se souciant d'associer étroitement les utilisateurs dans les tâches d'analyse et de conception (notamment au niveau des cas d'utilisation).

2.3.4. OBJETS DE L'ANALYSE UML

A. Acteur 

Il représente un rôle joué par une personne ou une chose qui interagit avec le système. La même personne physique peut donc être représentée par plusieurs acteurs en fonction des rôles qu'elle joue. Plusieurs personnes jouant le même rôle vis-à-vis du système, sont représentées par un seul acteur.

B. Attribut 

Il représente la modélisation d'une information élémentaire représentée par son nom et son format.

C. Association 

Elle est la plus courante et la plus riche du point de vue sémantique qu'une relation. Une association est une relation statique n-aire (le plus souvent : elle est binaire), c'est-à-dire qu'elle relie plusieurs classes entre elles.

D. Classe 

Elle correspond à un concept global d'information et se compose d'un ensemble d'informations élémentaires, appelées attributs de classe. Les classes sont représentées par des rectangles compartimentés; le premier compartiment représente le nom de la classe, le deuxième compartiment représente les attributs de la classe et le troisième compartiment représente les opérations de la classe.

E. Messages 

Elles sont le seul moyen de communication entre les objets. Ils sont décrits essentiellement par l'objet émetteur et l'objet récepteur.

F. Multiplicité

Elle définit le nombre d'instances de l'association pour une instance de la classe. La multiplicité est définie par un nombre entier ou un intervalle de valeurs. La multiplicité est notée sur le rôle (elle est notée à l'envers de la notation MERISE). Elle est représentée sous la forme d'un couple de cardinalités.

1..1

noté 1 Un et un seul

0..1

Zéro ou un

0..*

noté * De Zéro à n

1..*

De un à n

n..m

De n à m

G. Noeud 

Elle représente au diagramme de déploiement un cube dont le nom respecte la syntaxe des noms de classes. Les noeuds peuvent être associés comme des classes et on peut spécifier des multiplicités.

H. Opération

Elle comprend l'ensemble des activités que le domaine peut effectuer à partir des informations fournies par l'événement, et de celles déjà connues dans la mémoire du système d'information.

I. Propriété 

Elle est la modélisation de l'information élémentaire. C'est un ensemble de données ayant la même structure et représentant des informations analogues. La modélisation des propriétés doit éviter les synonymes et les polysémies. Les attributs et les opérations sont les propriétés d'une classe. Leur nom commence par une minuscule.

J. Relation 

Elle existe entre classes pour former les liens entre leurs objets.

K. Synchronisation

Elle est une condition préalable au démarrage d'une opération. Elle se traduit par une opération logique.

2.3.5. MODELISATION DE LA GESTION CLINIQUE DU CSRM/C

2.3.5.1. DIAGRAMME DE CAS D'UTILISATION

Il décrit les grandes fonctions d'un système du point de vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas d'utilisation, modélise à QUOI sert le système. C'est à ce niveau qu'on assimile les fonctionnalités demandées par le client, en montrant ce qu'on attend du système.

Cependant dans le cadre de notre travail, ce diagramme va nous monter les différentes personnes et choses qui vont devoir interagir par leurs informations échangées au sein du système du CSMR/C.

2.3.5.2. DIAGRAMME DE CLASSES

Il est au coeur de la conception d'un système, permet de spécifier la structure et les liens entre les objets dont le système est composé. Il spécifie QUI sera à l'oeuvre dans le système pour réaliser les fonctionnalités décrites par les diagrammes de cas d'utilisation. Le diagramme de classes modélise des règles.

Dans ce travail les différentes classes vont montrer les différentes entités qui gèrent et gardent l'information pour qu'elle soit cohérente et fluide.

2.3.5.3. DIAGRAMME ACTIVITE

Il montre toute la dynamique du système. Le diagramme d'activité offre une manière graphique et non ambiguë pour modéliser les traitements où une activité représente une exécution d'un mécanisme, un déroulement d'étapes séquentielles. Le passage d'une activité à l'autre est matérialisé par une transition.

Dans le présent travail, ce diagramme va nous montrer, de l'arrivé à la sortie du centre de santé, les différents processus qu'un patient doit devoir franchir.

2.3.5.4. DIAGRAMME DE SEQUENCES

Elle aide à comprendre comment les éléments du système interagissent entre eux et avec les acteurs en s'échangent des messages. En outre, il montre des interactions sous un angle temporel en mettant l'emphase sur le séquencement temporel.

Les séquences pour le cas du CSMR/C montrent les différents postes de travails et surtout les informations qui y sont échangées.

2.3.5.5. DIAGRAMME DE DEPLOIEMENT

Elle montre la disposition physique des différentes ressources matérielles (l'architecture du système) qui entrent dans la composition d'un système et la répartition des instances de composants, processus et objets qui « vivent » sur ces matériels.

Dans le cadre de notre travail elle nous prépare à l'implémentation de l'architecture technologique du système à mettre en place.

2.3.5.6. DIAGRAMME D'INFRASTRUCTURE TECHNOLOGIQUE

Elle montre la technologie physique et les équipements utilisés sur le réseau local créé. Nous trouvons les différents postes qui pourront communiquer ensemble et se comprendre par un dialogue avec un protocole commun. Cette technologie est composée des matériels puissants et récents pour supporter la gestion de la base de données. A cette technologie il faudra y alloué les utilisateurs qualifiés ou formés.

Son succès s'explique facilement de part les nombreux avantages dont il disposera : outre le réseau sera le plus évolutif puisque nous pourrons rajouter des composants à l'infini, modifier l'architecture du réseau comme bon nous semblera ou encore ajouter un ou plusieurs PC sans changer les paramètres des PC déjà reliés. Nous pourrons de plus relier nos PC les plus éloignés par un concentrateur.

2.3.5.7. DICTIONNAIRE DE DONNEES

Il est l'ensemble des schémas et des règles de passage entre les schémas associés à une base de données, combinés à une description de la signification des données.

Pour ce travail il nous a permis de quitter le model existant pour passer à la conception du model future en passant par l'étape de la validation et de délimitation du système à modéliser. Notre existant diffère du futur par le fait qu'à part le Personnel Soignant nous ne nous sommes plus intéressés du reste du Personnel.

ATTRIBUT

TYPE DES DONNEES ET

DESCRIPTION

SERVICES

 

CLASSE SERVICE

code_serv

char(5)

code du service

design_serv

varchar(100)

désignation service

PERSONNEL SOIGNANT

 

CLASSE DU PERSONNEL

code_pers

char(5)

code du personnel

nom_pers

varchar(25)

nom du personnel

postnom_pers

varchar(25)

post-nom du personnel

sexe_pers

char(9)

sexe du personnel ("masculin" ou "féminin")

grade_pers

varchar(50)

grade du personnel

fonction_pers

varchar(50)

fonction du personnel

telephone_pers

varchar(50)

téléphone du personnel

email_pers

varchar(50)

adresse mail du personnel

adress_pers

varchar(50)

adresse physique du personnel

datenais_pers

date

date de naissance du personnel

daterecrut_pers

date

date d'entrer en fonction du personnel

PATIENT

 

CLASSE DU PATIENT

code_pat

char(5)

code du patient

nom_pat

varchar(25)

nom du patient

postnom_pat

varchar(25)

post-nom du patient

sexe_pat

char(9)

sexe du patient ("masculin" ou "féminin")

adresse_pat

varchar(100)

adresse du patient

telephone_pat

varchar(50)

téléphone du patient

email_pat

varchar(50)

adresse mail du patient

origine_pat

varchar(100)

origine du patient (aire_santé,hors_air,hors_zone)

poids_pat

varchar(6)

poids du patient

profession_pat

varchar (25)

profession du patient

datenais_pat

date

Date de naissance du patient

RECEPTION

 

CLASSE RECEPTION

id_consult

integer

numéro d'ordre de la consultation

code_pat

char(5)

code du patient

code_pers

char(5)

code du personnel

type_consult

varchar(100)

type de la consultation (cpn,cpon,cps,curative)

observation

varchar(100)

observation (diagnostiques)

frais_consult

varchar(100)

frais de consultation

date_consult

date

date du jour de la consultation

HOSPITALISATION

 

CLASSE HOSPITALISATION

id_consult

integer

numéro d'ordre hospitalisation

code_pat

char(5)

code du patient

code_chambre

char(5)

code de la chambre

observation

varchar(100)

observation

date_arriv

timestamp

date d'entrée à l'hospitalisation

date_sort

timestamp

date de sortie à l'hospitalisation

LABORATOIRE

 

CLASSE LABORATOIRE

id_labo

integer

numéro d'ordre échantillon

type_exam

varchar(100)

type d'examen

code_pat

char(5)

code du patient

code_exam

char(5)

date de l'examen

observation

varchar(100)

observation sur résultat examen

date

timestamp

date de l'examen

TRAITEMENT

 

CLASSE TRAITEMENT

id_trait

integer

numéro d'ordre traitement

code_pat

char(5)

code du patient

code_maladie

char(5)

code maladie

detail_trait

varchar(100)

détail du traitement

observation

varchar(100)

observation sur malades (signes vitaux)

date_debut_trait

timestamp

date de début du traitement

date_fin_trait

timestamp

date de fin du traitement

etat_fin_trait

varchar(100)

état à la fin du traitement

CHAMBRE

 

CLASSE CHAMBRE

code_chamb

char(5)

code de la chambre

localisat_chamb

varchar(100)

localisation de la chambre (par ex. pediatrie,...)

categorie_chamb

varchar(100)

catégorie de la chambre (par ex. clinique,...)

capacité

varchar(100)

capacité de lit (nombre de lits)

prix_chamb

varchar(100)

prix de la chambre

MALADIE

 

CLASSE MALADIE

code_maladie

char(5)

code maladie

famille_maladie

varchar(100)

famille de la maladie

sous_famille

varchar(100)

sous famille de la maladie

designation_maladie

varchar(100)

désignation de la maladie

prix_trait

varchar(100)

prix du traitement de la maladie

EXAMEN

 

CLASSE MORTALITE

code_exam

char(5)

code examen

type_exam

varchar(100)

type examen

prix_exam

varchar(100)

prix examen

* 31 http://www.btb.gc.ca/btb.php?lang=fra&cont=700, visité le 28/09/2010 à 15h20

* 32 http://agora.qc.ca/dossiers/Technique. visité le 28/09/2010 à 15h25

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy