Embed Size (px)
Citation preview
REPOBLIKAN’I MADAGASIKARAFitiavana-Tanindrazana-Fandrosoana
——————————–MINISTERE DE L’ENSEIGNEMENT
SUPERIEURET DE LA RECHERCHE SCIENTIFIQUE
——————————–UNIVERSITE DE MAHAJANGA
——————————–INSTITUT SUPERIEUR DES SCIENCES ETDES TECHNOLOGIES DE MAHAJANGA
——————————–
Mémoire de fin d’étude en vue de l’obtention du diplôme de
Licence Professionnelle en Sciences et Technologies
Parcours : Génie Informatique
No : 7/16/GINF/ISSTM/UMG/DIR
Gestion des dossiers médicaux despatients à la pédiatrie
Présenté par :
Randrianasolo Tojohasambarana Henintsoa Roger
03 Décembre 2016
Devant les membres de jury :Président : Dr RAKOTOVELO GeoslinRapporteur : Mr ANDRIANANTENAINA ChrysostomeExaminateur : Mr TSANGANDRAZANA Judicaël
Promotion : Mahery 2016
ANNÉE UNIVERSITAIRE : 2015-2016
Gestion des dossiers médicaux despatients à la pédiatrie
Randrianasolo Tojohasambarana Henintsoa Roger
03 Décembre 2016
Remerciements
Je voudrais en premier lieu remercier Dieu tout puissant de m’avoir donné la force etla santé de réaliser ce présent mémoire.
Je remercie également aux responsables de l’Université de Mahajanga pour leur soutientout au long de notre formation.
J’adresse mes sincères remerciements Mr le Dr RAKOTOVELO Geoslin , Directeurde l’ISSTM (Institut Supérieur de Sciences et Technologies de Mahajanga) Université DeMahajanga de m’avoir permise à présenter le fruit de mes trois années de formation ausein de l’institut.
Mes remerciements vont également à mes encadreurs, pour leur patience, leur dispo-nibilité et surtout leurs judicieux conseils, qui ont contribué à alimenter ma réflexion :
— Mr TSANGANDRAZANA Judicaël : encadreur pédagogique— Mr RAKOTOARIMANANA Aristide : encadreur professionnelJ’adresse aussi ma gratitude à l’infirmière Madame RAHAJAVOLOLONA Danieline
qui a accepté de me rencontrer et à répondre à mes questions durant mes recherches.Je désire aussi remercier les professeurs de l’ISSTM, qui m’ont fourni les outils né-
cessaires à la réussite de mes études universitaires durant ces trois années. Sans oublierles membres de jury qui ont consacré leur temps à juger mon travail.
Je remercie mes très chers parents qui ont toujours été là pour moi, vous avez toutsacrifié pour vos enfants n’épargnant ni santé ni efforts. Vous m’avez donné un magnifiquemodèle de labeur et de persévérance. Je suis redevable d’une éducation dont je suis fière.Sans oublier, je voudrais exprimer ma reconnaissance envers les amis et collègues quim’ont apporté leur soutien moral et intellectuel tout au long de ma démarche. À tous cesintervenants, je présente mes remerciements, mon respect et ma gratitude.
i
Présentation de l’ISSTM
Depuis la création du Centre Universitaire Régional de Mahajanga en 1977 et aussiaprès la création des six Université de Madagascar en 1988, l’évolution de l’offre de for-mation a été relativement faible. Depuis l’année universitaire 2010/2011, un bon nombred’offres de formations a été créé à l’Université de Mahajanga. L’institut Supérieur deSciences et Technologies de Mahajanga en abrégé par ISSTM est l’un parmi des nouveaucentre de formation de techniciens supérieurs de haut niveau au sein de cette Université.Cet institut est créé au cours de l’année universitaire 2011/2012.
Les exigences du développement économique régional, les insuffisances des cadres tech-niciens intermédiaires dans les entreprises, les collectivités décentralisées et dans le but deréduire les dépenses des parents qui sont obligés d’envoyer leurs enfants hors de la provincede Mahajanga, sont les principales raisons de la mise en place de la licence professionnelleen Sciences et Technologies en Génies Civil et Industriel au sein de l’ISSTM.
Les étudiants sortant de l’ISSTM sont opérationnels dans les domaines du génie ther-mique, du génie industriel, du génie électrique, du génie civil et du génie informatiqueaprès avoir fini leur cursus.
Les contenus de ces formations scientifiques sont accompagnés d’une ouverture au seindes milieux professionnels garantie dans les visites d’imprégnations, les stages en entre-prises et les interventions de professionnels dans les domaines spécialisés du programme.
Le diplôme de licence professionnel délivré par cet institut s’articule autour de quatreparcours :
— GINF (Génie Informatique) ouvert dès la première année de formation ;— FGCI (Fondamentaux des Génies Civil et Industriel) cours de mise à niveau en
première année de formation ;— GITE qui regroupe les trois spécialités : le Génie Industriel (GI), le Génie Ther-
mique (GT) et le Génie Electrique (GE) ouvert en deuxième année ; -— GCBTP (Génie Civil, Bâtiments et Travaux Publics) démarrant en deuxième an-
née.
ii
Figure 1 – Organigramme de fonctionnement de l’ISSTM
iii
Organigramme du service de la pédiatrie
Figure 2 – Organigramme du service de la pédiatrie
iv
Liste des abréviations
MVC : Modèle Vue Contrôleur
POO : Programmation Orienté Objet
WPF : Windows Presentation Foundation
GoF : Gang of Four
RUP : Rational Unified Process
IBM : International Business Machine
GNU : Group Not Unix
PU : Processeur Unifié
SGBDR : Système de Gestion de la Base des Données Relationnelles
DCU : Diagramme de cas d’utilisation
JCP : Java Community Process
JFC : Java Foundation Class
SDK : Software Development Kit
EPL : Eclipse Public License
GPL : General Public License
JDK : Java Development Kit
AWT : Abstract Window Toolkit
SWT : Standard Widget Toolkit
GTK : Gnome ToolKit
OMG : Object Management Group
OOSE : Object Oriented Software Engineering
v
Sommaire
I Introduction 1
1 Généralité 21.1 Introduction à la pédiatrie . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
II Outils et Méthodologies 4
2 Matériels 52.1 Quels outils à utiliser ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Choix des langages . . . . . . . . . . . . . . . . . . . . . . . . . . . 5JAVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Atelier Génie Logiciel de Modélisation . . . . . . . . . . . . . . . . 62.1.3 Choix des bibliothèques graphiques . . . . . . . . . . . . . . . . . . 7
AWT :Abstract Window Toolkit . . . . . . . . . . . . . . . . . . . . 7Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7SWT : Standard Widget Toolkit . . . . . . . . . . . . . . . . . . . . 8JavaFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8La bibliothèque et les modules utilisés . . . . . . . . . . . . . . . . 9
2.1.4 Choix de Système de Gestion de Base des Données Relationnel . . . 9Oracle Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Mysql Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Méthodes 133.1 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Synthèse du cahier de charge fonctionnel . . . . . . . . . . . . . . . . . . . 13
vi
3.2.1 Constatation de départ et ciblage des destinataires . . . . . . . . . 133.2.2 Définition de l’application à réaliser . . . . . . . . . . . . . . . . . . 143.2.3 Les fonctions essentielles que devra remplir l’application . . . . . . 14
3.3 Merise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.1 Les renseignements nécessaires au développement du projet . . . . . 143.3.2 Modèle conceptuel de communication . . . . . . . . . . . . . . . . . 153.3.3 Modèle conceptuel de traitement . . . . . . . . . . . . . . . . . . . 173.3.4 Modèle Conceptuel des Données . . . . . . . . . . . . . . . . . . . . 193.3.5 Modèle Physique des Données . . . . . . . . . . . . . . . . . . . . . 20
3.4 Diagramme UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.2 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.3 Formalisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Les vues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Les diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.4 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 24Sommaire d’identification . . . . . . . . . . . . . . . . . . . . . . . 26Description des scénarios . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.5 Diagramme de Séquence . . . . . . . . . . . . . . . . . . . . . . . . 273.4.6 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.7 Diagramme de package . . . . . . . . . . . . . . . . . . . . . . . . . 31
III Résultats et Discussions 33
4 Résultats 344.1 Installation du Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 Interface Homme-Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Le Splash screen de démarrage . . . . . . . . . . . . . . . . . . . . . 354.2.2 L’onglet Nouveau patient . . . . . . . . . . . . . . . . . . . . . . . . 364.2.3 L’onglet Soins et Paramètre . . . . . . . . . . . . . . . . . . . . . . 384.2.4 L’onglet Paramètre . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.5 L’onglet Recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Discussions 425.1 Difficultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2 Avantage et particularité du logiciel . . . . . . . . . . . . . . . . . . . . . . 43
5.2.1 Utilisation de patron de conception . . . . . . . . . . . . . . . . . . 43Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
vii
Utilité du patron de conception . . . . . . . . . . . . . . . . . . . . 44Patrons de conception du GoF . . . . . . . . . . . . . . . . . . . . . 44
5.2.2 Adoption de l’architecture MVC . . . . . . . . . . . . . . . . . . . 46Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Flux de traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.3 Utilisation de méthode RUP . . . . . . . . . . . . . . . . . . . . . . 48Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
IV Conclusion et Annexe 51
6 Conclusion 52
7 Annexes et Quelques Définitions 537.1 Le génie Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.1.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.1.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.1.3 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.1.4 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.1.5 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.1.6 Gestion de projets . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.1.7 Les outils et méthodes . . . . . . . . . . . . . . . . . . . . . . . . . 547.1.8 La Gestion de la Qualité . . . . . . . . . . . . . . . . . . . . . . . . 557.1.9 La gestion de la configuration . . . . . . . . . . . . . . . . . . . . . 55
7.2 Méthodes de conception de logiciel . . . . . . . . . . . . . . . . . . . . . . 557.2.1 La Bête à Cornes (Analyse fonctionnelle) . . . . . . . . . . . . . . 557.2.2 Cahier des charges fonctionnel . . . . . . . . . . . . . . . . . . . . . 56
7.3 UML et la programmation orientée objet(POO) . . . . . . . . . . . . . . . 567.3.1 L’agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3.2 La composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
viii
Table des figures
1 Organigramme de fonctionnement de l’ISSTM . . . . . . . . . . . . . . . . iii2 Organigramme du service de la pédiatrie . . . . . . . . . . . . . . . . . . . iv
3.1 Diagramme de gantt du projet . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Modèle conceptuel de communication . . . . . . . . . . . . . . . . . . . . . 153.3 Modèle conceptuel de traitement . . . . . . . . . . . . . . . . . . . . . . . 173.4 Modèle conceptuel de Données . . . . . . . . . . . . . . . . . . . . . . . . . 193.5 Modèle Physique de Données . . . . . . . . . . . . . . . . . . . . . . . . . 203.6 Diagramme de cas d’utilisation du système . . . . . . . . . . . . . . . . . . 253.7 Diagramme de séquence des classes participantes . . . . . . . . . . . . . . 283.8 Diagramme de classe de la couche métier . . . . . . . . . . . . . . . . . . 303.9 diagramme de classe de la couche d’accès à la base des données . . . . . . . 313.10 Diagramme de package de l’application . . . . . . . . . . . . . . . . . . . . 32
4.1 Schéma d’installation du logiciel . . . . . . . . . . . . . . . . . . . . . . . 344.2 Splash Sreen de démarrage du logiciel . . . . . . . . . . . . . . . . . . . . 354.3 Formulaire Nouveau Patient . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4 Formulaire d’ajout nouveau soins et de paramètre du patient . . . . . . . . 384.5 Formulaire de Paramètre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.6 Formulaire de Recherche et Liste de patient . . . . . . . . . . . . . . . . . 41
5.1 Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2 Aspects RUP : les aspects dynamiques sont à l’horizontale, les statiques
affichés verticalement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1 La bête à Cornes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
ix
Résumé
A nos jours, l’informatisation de gestion des dossiers de patient n’a pas encore eulieu. En fait, le traitement de dossier se fait encore de manière classique. La difficultéd’accès aux archives règnent encore dans ce domaine. Il devient cependant difficile defournir en temps réel le rapport mensuel et annuel des données relatives à certaines quêtes.L’automatisation suivie du partage des informations sur les patients sera alors l’approchede ce travail. Elle est présumée être meilleure en informatisant la gestion des maladesaprès avoir cerner tous les besoins des utilisateurs finaux. La modélisation fera donc defaçon à avoir des sous systèmes considérés comme de petites parts toute entière et exploiterseulement les abstractions ou les informations nécessaires à résoudre le problème et ignorerd’autres qui peuvent freiner à l’évolution du système.
x
Première partie
Introduction
1
Chapitre 1Généralité
1.1 Introduction à la pédiatrie
La pédiatrie est une branche spécialisée de la médecine qui étudie le développementpsychomoteur et physiologique normal de l’enfant, ainsi que toute la pathologie qui ya trait (maladies infantiles), de la naissance à la période poste-pubertaire où il devientadulte ; c’est la médecine des enfants, l’enfant étant défini en droit comme tout sujet âgéde moins de 18 ans 1. Le médecin spécialisé en pédiatrie s’appelle le pédiatre.
La pédiatrie est différente de la médecine générale puisque s’adressant spécialement àun organisme en développement et en transformation permanente. La précocité du diag-nostic est ici, encore plus qu’ailleurs, vitale pour la santé future de l’enfant et déterminantepour le pronostic.
La néonatalogie est la partie de la pédiatrie qui s’occupe du nouveau-né. C’est lacoopération entre le pédiatre et l’obstétricien qui permet de prévenir les malformationsfœtales et de traiter des maladies à la naissance.
1.2 Problématiques
Dans nos institutions de santé, l’informatisation de gestion des dossiers de patientn’a pas encore eu lieu. En fait, le traitement de dossier se fait encore de manière clas-sique(classement de tous les papiers dans l’archive médical). Sur un nombre des annéesécoulées, cette méthode est de moins en moins pratique. Il devient très difficile d’accéderaux archives où les données étaient stockées, saisies, vu les supports qui les contenaient,car elles sont soit altérés, soit illisibles ou introuvables. Il devient cependant difficile defournir en temps réel le rapport mensuel et annuel des données relatives à certaines quêtes.
Tout système non évolutif ne permet pas au gestionnaire d’une structure sanitaire deprendre des décisions rationnelles sur la gestion des patients. C’est ainsi que dans l’exé-
1. Article 1er de la Convention relative aux droits de l’enfant
2
cution de notre projet, nous essayerons donc de trouver des pistes de solution à cetteproblématique en mettant en œuvre notre savoir afin d’implanter un système d’informa-tion (partagé en réseau local ou pas), plus sécurisé et beaucoup plus fiable.
Afin de bien mener notre étude les questions suivantes valent la peine d’être posées :
1. Comment arriver à produire les statistiques mensuelles et annuelles sur le tauxde natalité, de mortalité par sexe et par âge, et par endémie ; le nombre et letaux des patients souffrants d’une pathologie par âge,par sexe et par entité ; etcomment contourner la lenteur et les risques possibles d’erreurs d’identificationlors de l’édition des fiches et carnets des patients ?
2. Comment aider le personnel soignant à suivre les malades en état de santé souventen dégradation permanente (chroniques) au fil du temps car cela demande unsuivi régulier, et comment rendre disponible les données ou les informations sur lespatients sur chaque poste d’une structure sanitaire ?
1.3 Objectifs
L’automatisation suivie du partage des informations sur les patients sera l’approche dece travail. Elle est présumée être meilleure en informatisant la gestion des malades aprèsavoir cerner tous les besoins des utilisateurs finaux. La modélisation fera un découpageatomique, de façon à avoir des sous systèmes considérés comme de petites parts toute en-tière et exploiter seulement les abstractions ou les infos nécessaires à résoudre le problèmeet ignorer d’autres qui peuvent freiner à l’évolution du système.
3
Deuxième partie
Outils et Méthodologies
4
Chapitre 2Matériels
2.1 Quels outils à utiliser ?
2.1.1 Choix des langages
JAVA
Le langage Java est un langage de programmation informatique orienté objet créépar James Gosling et Patrick Naughton. La particularité et l’objectif central de Java estque les logiciels écrits dans ce langage doivent être très facilement portables sur plusieurssystèmes d’ exploitation tels que UNIX, Windows, Mac OS ou GNU/Linux, avec peuou pas de modifications. Pour cela, divers plateformes et frameworks associés visent àguider, sinon garantir, cette portabilité des applications développées en Java. Le langageJava répond cinq objectifs bien défini :
— simple, orienté objet et familier ;— robuste et sûr ;— indépendant de la machine employée pour l’exécution ;— très performant ;— compilé, multitâches et dynamique.La première caractéristique, le caractère orienté objet (« OO ») et familier, fait ré-
férence à une méthode de programmation et de conception du langage et le fait qu’unprogramme écrit en Java ressemble assez fort à un programme écrit en C++. Mais lesproblèmes récurrents à l’encontre de C++ sont :
— lourde tâche à cause de programmation manuelle de la gestion de la mémoire ;— aboutissement à une fuite de mémoire à cause de l’oublie de désallocation et en-
gendre la consommation abondant du programme.— instabilité et plantage de l’application si par erreur un programme demande plu-
sieurs fois une désallocation, ou emploi une zone de mémoire après avoir demandésa désallocation.
5
C#
Le C# (C sharp en anglais) est un langage de programmation orienté objet, com-mercialisé par Microsoft depuis 2002 et destiné à développer sur la plateforme Microsoft.NET.Il est dérivé du C++ et très proche du Java dont il reprend la syntaxe généraleainsi que les concepts, y ajoutant des autres notions C# est un langage de programma-tion orientée objet, fortement typé, dérivé de C et C++, ressemblant au langage Java. Ilest utilisé pour développer des :
— applications web ;— applications de bureau ;— des services web, des commandes, des widgets ou des bibliothèques de classes.Beaucoup de possibilités de Java se retrouvent dans C# et il y a une forte ressem-
blance entre un code écrit en C# et le code équivalent en Java puisqu’il est crée pourrectifier la faiblesse de Java (la verbosité du code surtout).Son but principal est de créerun application robuste avec un minimum de code. Mais ses inconvénients demeurent sur
En outre,il est intégré dans le WPF ( Windows Presentation Foundation) qui estun bibliothèque utilisé pour développez une application client-riche (y compris MicrosoftSilverlight )en utilisant le langage XAML.
Vues les particularité du langage C# on pourrait lui dire qu’il est un langage pluspuissant que le JAVA mais nous avons choisi le dernier car avec C# on ne peut pasdévelopper un logiciel multiplateformes et ses environnement de développement intégréet ses certains bibliothèques sont disponibles sous licence commercial.
2.1.2 Atelier Génie Logiciel de Modélisation
Pour développer l’application, nous avons travaillé sous le système Debian Jessie(laversion 8 de GNU Linux/Debian).Les ateliers génie logiciel qu’y sont disponible sont citéscomme suit :
— JMerise,— Gantt Project,— UMLet— Eclipse Mars 2.0 IDE— GIMP 2.8
6
2.1.3 Choix des bibliothèques graphiques
Lorsqu’on décide de choisir le langage Java pour développer l’application, on pense di-rectement à la bibliothèque graphique à utiliser pour l’interface homme-machine (I.H.M.)de notre application. De nos jours, Java possède quatre(4) bibliothèques graphiques dedéveloppement d’un logiciel. On va voir les caractéristiques de chaque bibliothèques etleur spécification.
AWT :Abstract Window Toolkit
C’ est une bibliothèque graphique pour Java, faisant partie de JFC (Java FoundationClasses). Cette bibliothèque a été introduite dès les premières versions de Java ; depuisJava 2, la bibliothèque de gestion de fenêtre officielle est Swing. Toutefois, AWT sertencore de fondement à Swing, dans la mesure où de nombreuses classes Swing héritent declasses AWT.
AWT emploie les composants natifs de la plate-forme, alors que Swing utilise descomposants en pur Java.
Swing
Swing est une bibliothèque graphique pour le langage de programmation Java, faisantpartie du package Java Foundation Classes (JFC), inclus dans J2SE. Swing constitue l’unedes principales évolutions apportées par Java 2 par rapport aux versions antérieures. Swingoffre la possibilité de créer des interfaces graphiques identiques quel que soit le systèmed’exploitation sous-jacent, au prix de performances moindres qu’en utilisant AbstractWindow Toolkit (AWT). Il utilise le principe Modèle-Vue-Contrôleur (MVC, les compo-sants Swing jouent en fait le rôle de la vue au sens du MVC) et dispose de plusieurs choixd’apparence pour chacun des composants standards. Avec l’apparition de Java 8 en mars2014, JavaFX devient la bibliothèque graphique officielle du langage Java, pour toutesles sortes d’application (applications mobiles, applications sur poste de travail, applica-tions Web), le développement de son prédécesseur Swing étant abandonné (sauf pour lescorrections de bogues).
Relation avec AWTDepuis les premières versions de Java, Abstract Window Toolkit (AWT) fournit une
API indépendante du système d’exploitation pour mettre en œuvre des composants gra-phiques. Dans AWT, chaque composant est dessiné et contrôlé par un composant tiersnatif spécifique au système d’exploitation. C’est pourquoi les composants d’AWT sont ap-pelés composants lourds. Au contraire, les composants Swing sont décrits comme légers.En effet, ils ne requièrent pas d’allocation de ressources natives de la part du gestion-naire de fenêtres sous-jacent, mais « empruntent » les ressources de leurs ancêtres. Unegrande partie de l’API Swing est une extension complémentaire à AWT plutôt qu’un
7
remplaçant direct. L’affichage est fourni par Java2D, un autre composant des JFC. Ce-pendant, l’usage conjoint de composants légers et lourds au sein d’une même fenêtre estgénéralement déconseillé à cause de problèmes de gestion de la profondeur.
SWT : Standard Widget Toolkit
C’ est une bibliothèque graphique libre pour Java, initiée par IBM. SWT n’est pasun standard Java reconnu par le JCP. Cette bibliothèque se compose d’une bibliothèquede composants graphiques (texte, label, bouton, panel), des utilitaires nécessaires pourdévelopper une interface graphique en Java, et d’une implémentation native spécifique àchaque système d’exploitation qui sera utilisée à l’exécution du programme.
La deuxième partie de SWT n’est en fait qu’une ré-encapsulation des composantsnatifs de système (Win32 pour Windows, GTK ou Motif pour Linux). Plusieurs projetstravaillent aujourd’hui sur une implémentation utilisant les composants de Swing.
L’environnement de développement libre Eclipse, commandité lui aussi par IBM, re-pose sur cette architecture.
Avantages— Implémente en Java les fonctionnalités qui ne sont pas offertes par les toolkits
sous-jacents, d’où sa supériorité sur AWT— N’implémente en Java que les fonctionnalités qui ne sont pas offertes par les tool-
kits sous-jacents, économise donc les ressources, d’où sa rapidité d’exécution parrapport à Swing.
— SWT est un logiciel libre (sous licence EPL), il constitue donc une alternative libreà la bibliothèque Swing qui n’est pas encore complètement implémentée dans lesenvironnements Java libres (comme GNU Classpath).
Inconvénients— Rareté des documentations par rapport à celles de Swing, la communauté des
utilisateurs de SWT étant moins grande— Le look and feel n’est pas imposé, il dépend du toolkit sous-jacent. Par exemple
avec le toolkit GTK, une modification du thème de celui-ci agira sur les applicationsSWT également.
— Gestion des ressources contraignante (libération des couleurs, fontes...) due à l’uti-lisation des fonctions natives.
— L’utiliser pour des Applets est beaucoup plus difficile, car absent des standards.
JavaFX
JavaFX devient la bibliothèque de création d’interface graphique officielle du langageJava, pour toutes les sortes d’application (applications mobiles, applications sur poste detravail, applications Web), le développement de son prédécesseur Swing étant abandonné
8
(sauf pour les corrections de bogues). JavaFX est désormais une pure API Java (le langagede script spécifique qui a été un temps associé à JavaFX est maintenant abandonné).JavaFX contient des outils très divers, notamment pour les médias audio et vidéo, legraphisme 2D et 3D, la programmation Web, la programmation multi-fils etc. Le SDKde JavaFX étant désormais intégré au JDK standard Java SE, il n’y a pas besoin deréaliser d’installation spécifique pour JavaFX. Des projets libres complètent JavaFX enfournissant des composants de haute qualité absents de JavaFX proprement dit, voir parexemple : JFXtras et ControlsFX.
La bibliothèque et les modules utilisés
Certes JavaFX est désormais la bibliothèque officielle du langage Java, mais JavaSwing répond au critère qu’on a besoin. Nous avons parvenu à choisir Java Swing car :
— il est plus mature que le JavaFX ;— même s’il est abandonné,il a eu un minimum de bogue et plus stable par rapport
à JavaFX ;— JavaFX nécessite beaucoup d’un ressource matériel ;Pendant notre développement de notre application, nous avons besoins de quelques
modules qui sont :— Mysql Connector (pour se connecter à la base des données mysql )— JCalendar (pour afficher un Calendrier sous Swing)— JFreeChart (pour afficher une graphe statistique sous Swing)
2.1.4 Choix de Système de Gestion de Base des Données Rela-
tionnel
On va comparer les trois SGBDR que nous trouvons le plus utilisé au développement,en suivant quelques critères de comparaisons :
Oracle Database
Oracle n’est pas un SGBDR optimisé pour de petites bases de données. Sur de petitsvolumes de traitements (2 Go par exemple) et peu d’utilisateurs (une trentaine) vouspourriez trouver des benchmark ou MySql offre des performances quasi comparables àOracle... Si l’on monte à de plus importants volumes de donnée (>200Go) et un grandnombre d’utilisateurs (>300) les écarts de performance entre un MySql et un Oracle,Sybase, Db2 seront très visibles.
9
1. Version actuelle : 11 R2
2. Disponibilité : Linux, Windows, Unix, MacOSX
3. Licence : commerciale, gratuite dans sa version Express
4. Versions— Oracle Enterprise Edition— Oracle Standard Edition— Oracle Personal Edition— Oracle Database 10g Express Edition, limitée à 4 Go, 1 CPU, 1Go de RAM,
32 bits, Linux/Windows, gratuit
5. Avantages— Richesse fonctionnelle— Fonction d’audit évolué— Parallélisme, caches nommés ; haute disponibilité ; grande possibilité de tuning— Procédures stockés en PL-Sql (langage propriétaire Oracle, orienté ADA) ou ...
en JAVA 1 ce qui peut s’avérer utile pour les équipes de développement.— Assistants performants via Oracle Manager Server, possibilité de gérer en in-
terne des tâches et des alarmes— Gestion centralisée de plusieurs instances— Concept unique de retour arrière— Pérennité de l’éditeur : avec plus de 40% de part de marché, ce n’est pas demain
qu’Oracle disparaîtra— Réglages fins : dans la mesure ou l’on connaît suffisamment le moteur, presque
TOUT est paramétrable.— Accès aux données système via des vues, bien plus aisément manipulable que
des procédures stockées.— Interface utilisateur remaniée et extrêmement riche, permettant - enfin ! - le
tuning fin de requêtes par modification des plans d’exécution.— Services Web, support XML— Ordonnanceur intégré— Compression des données et des sauvegardes— Support technique Orion extrêmement riche et fourni
6. Inconvénients— Prix élevé, tant au point de vue des licences que des composants matériels
(RAM, CPU) à fournir pour de bonnes performances— Administration complexe... liée à la richesse fonctionnelle— Fort demandeur de ressources, ce qui n’arrange rien au point précité, Oracle est
bien plus gourmand en ressource mémoire que ses concurrents, ce qui implique
1. Depuis la 8.1.7
10
un investissement matériel non négligeable.— Porosité entre les schémas = difficile de faire cohabiter de nombreuses appli-
cations sans devoir créer plusieurs instances. Il manque réellement la couche"base de données" au sens Db2/Microsost/Sybase du terme.
— Métamodèle propriétaire, loin de la norme.— Tables partitionnées, RAC... uniquement possible à l’aide de modules payants
complémentaires sur la version Enterprise.— Gestion des verrous mortels mal conçue (suppression d’une commande blo-
quante sans rollback)— Faiblesses de l’optimiseur (ne distingue pas les pages en cache ou en disque,
n’utilise pas d’index lors de tris généraux, statistiques régénérées par saccade...)— Une quantité du bugs proportionnelle à la richesse fonctionnelle, surtout sur les
dernières versions— Gestion erratique des rôles et privilèges (pas possible de donner des droits sur
des schémas particuliers sans passer par leurs objets, désactivation des rôleslors d’exécution de packages...)
— Pas de type auto-incrément déclaratif : les séquences ne peuvent être déclara-tivement dédiées à une table spécifique (risque de mélange)
— Nombreuses failles de sécurités liées à l’architecture elle-même
Mysql Server
1. Version actuelle : 5.5
2. Disponibilité : Linux, Windows, MacOSX, Unix, BSD, OS2
3. Licence : GPL et commerciale
4. Versions— MySQL Community Server : licence GPL— MySQL Enterprise = MySQL Community Server + certifié sécurité et perfor-
mance + licence d’entreprise
5. Avantages— Solution très courante en hébergement public— Très bonne intégration dans l’environnement Apache/PHP— OpenSource, bien que les critères de licence soient de plus en plus difficiles à
supporter— Version cluster depuis la version 4— ordonnanceur dès la version 5.1— Partitonnement dès la version 5.1— Facilité de déploiement et de prise en main.
11
— Plusieurs moteurs de stockage adaptés aux différentes problématiques, configu-rable au niveau table.
6. Inconvénients— Ne supporte qu’une faible partie des standards SQL-92— Support incomplet des triggers et procédures stockées— Gestion des transactions avec les moteurs Falcon ou InnoDb uniquement— Assez peu de richesse fonctionnelle— Manque de robustesse avec de fortes volumétries— Pas d’héritage de table— Pas de vue matérialisée— Pas de sauvegarde constistante à chaud
PostgreSQL
1. Version actuelle : 9
2. Disponibilité : Linux, Unix, MacOSX, Windows
3. Licence : BSD et commerciale (sous nom de EnterpriseDB Advanced Server 8.1)
4. Avantages— OpenSource et gratuit— Fiable et relativement performant, tout en restant simple d’utilisation— Supporte la majorité du standard SQL-92 et possède en plus un certain nombre
d’extensions (Java, Ruby, PL-SQL).— Très riche fonctionnellement, notions d’héritage de tables, multitude de modules— Simple d’utilisation et d’administration— Héritage de tables
5. Inconvénients— La modification du fichier de sécurité pg_hba.conf nécessite un reboot pour
être prise en compte— Sauvegardes peu évoluées— Supporte les bases de moyenne importance— Pas de services Web— Pas d’ordonnanceur intégré— Pas de vue matérialisée— Pas de requêtes récursives— Solutions de réplication pas encore totalement packagées
On a choisit Mysql Server car ses avantages satisfont le besoins de notre projet. En plus,il est installé par défaut, dans le système d’exploitation 2 que nous avons utilisé. Mais onpourrait changer, si le programme est beaucoup plus en plus évolué.
2. GNU Linux/Debian 8 Jessie
12
Chapitre 3Méthodes
3.1 Planification du projet
Figure 3.1 – Diagramme de gantt du projet
3.2 Synthèse du cahier de charge fonctionnel
3.2.1 Constatation de départ et ciblage des destinataires
L’idée de créer une application de stockage des informations ou dossier médical concer-nant un patient à la pédiatrie est partie du constat que généralement, les logiciels dispo-nibles dans les toiles ne répondaient pas au critère fixés pour l’exploitation qu’on désirefaire ici à Madagascar. Soit leur orientation est trop comptable, soit pas assez synthétique.L’avantage est également que ce genre d’application réalisée par l’utilisateur principal peuts’adapter en temps réel. Cette application s’adresse donc dans un premier temps à notrepropre structure pédiatrie. Mais elle est assez simple d’utilisation et polyvalente pours’adapter à n’importe quelle domaine de service dans Centre Hospitalier Universitaire
13
P.Za.Ga Androva. L’utilisateur principaux en sont les médecins ou le secrétaire dans leservice pédiatrie.
3.2.2 Définition de l’application à réaliser
L’application à réaliser est une application de base de données assurant l’enregistre-ment et la manipulation des dossiers médicales des patients qui sont hospitalisés ou quiont faits une consultation externe
Cette application est nommée SoftPed en rapport avec le Logiciel de pédiatrie.
3.2.3 Les fonctions essentielles que devra remplir l’application
SoftPed doit remplir d’office certaines fonctions indispensables à la gestion de patientet des consultations. Son premier but est de permettre la constitution d’un véritable« Dossier médical » relatif à chaque patient. L’application devra répondre :
— l’ajout de nouveau dossier médical de patient selon son activité (consultation ouhospitalité).
— la mise à jour de dossier médical existant,— les études statistiques de taux fréquentation de patient, de maladie...
3.3 Merise
La méthode MERISE signifie « Méthode d’Etude et de Réalisation Informatique pourles Systèmes d’Entreprise » 1. Merise est une méthode d’analyse de conception et de gestionde projet informatiques. Elle est très utilisée pour l’informatisation massive des organisa-tions.
3.3.1 Les renseignements nécessaires au développement du projet
Les renseignements concernant le dossier médical d’un patient peut généraliser commesuit :
— Développement de l’embryon et du fœtus ; prévalence de la prématurité et de l’hy-potrophie à la naissance ;
— Croissance et développement somatique, sensoriel et psychologique normal et pa-thologique du nourrisson et de l’enfant ;
— Puberté et sexualité de l’enfant et de l’adolescent ;— Alimentation et nutrition du nourrisson et de l’enfant ;
1. Autre Signification :—Méthode Éprouvée pour Retarder Indéfiniment la Sortie des Études—MEthode pour Rassembler les Idées Sans Effort
14
— Pharmacologie (métabolisme, posologie, action et toxicité) des médicaments usuelsen pédiatrie ;
— Explorations fonctionnelles en pédiatrie ;— Morbidité et mortalité périnatale et infantile dans le monde ;— Épidémiologie, physiopathologie, anatomopathologie, diagnostic, pronostic et trai-
tement des maladies du fœtus et du nouveau-né, du nourrisson, de l’enfant et de l’adolescent ;
— Protection maternelle et infantile, organisation des naissances et prévention de laprématurité et de l’hypotrophie ;
— Prévention et prise en charge des malformations, des maladies génétiques, des han-dicaps et de la maltraitance chez l’enfant ; diagnostic anténatal et dépistage néo-natal ;
— Programme de vaccination ;— Organisation et prise en charge de la douleur chez l’enfant et des urgences médico-
chirurgicales pédiatriques ;
3.3.2 Modèle conceptuel de communication
Figure 3.2 – Modèle conceptuel de communication
15
Message 01 : Demande de soin faite à la réception par le parent du patient.
Message 02 : Demande de renseignement, consultation et remplissage de fiche deconsultation externe et livraison de l’ordonnance au parent par lemédecin.
Message 03 : Demande d’achat de fiche individuel de malade par le médecin.
Message 04 : Réception de fiche individuelle de malade par médecin vient du parentdu patient.
Message 05 : Réception de fiche individuel de malades à remplir par le médecinconsultant pendant hospitalisation du patient.
Message 06 : Retrait de billet d’hospitalisation, du fiche de prescription, du fiched’observation médicale et de cahier de garde faite par le serviced’hospitalisation à la surveillance générale.
Message 07 : Enquête au parent du patient et observation du patient faite par leservice d’hospitalisation.
Message 08 : Réponse de question faite par les parents du malade.
Message 09 : Réception de billet d’hospitalisation, du fiche de prescription,du fiche d’observation médicale et retrait de cahier de garde remplià la surveillance générale faite par le service d’hospitalisation.
Message 10 : Réception de cahier de garde par service de pilotage vient de lasurveillance générale.
Message 11 : Réception de cahier de garde signé vient du service de pilotagepar la surveillance générale.
Message 12 : Envoi de billet d’hospitalisation, du fiche de prescription, du fiched’observation médicale et du cahier de garde au secrétariat fait par lasurveillance générale.
Message 13 : Enregistrement et remise des dossiers médicaux des patients traités ouhospitalisés à la surveillance générale faites par le secrétariat.
Message 14 : Envoi de billet de sortie à la réception faite par la surveillance générale.
Message 15 : Remise de billet de sortie et de l’ordonnance au parent faite par lemédecin consultant.
16
3.3.3 Modèle conceptuel de traitement
Figure 3.3 – Modèle conceptuel de traitement
17
Dans le figure 3.3 ci-dessus, nous montre le modèle conceptuel de traitement. Il nousexplique les mouvement des médecins, de malades au seins de l’hôpital.
Avec la présence du parent et du patient qu’on peut effectuer une observation quise fait par la demande de l’état civil du patient et une diagnostique simple faite par lemédecin. Si l’état du patient est simple, on va passer au traitement direct du patient quise fait par la consultation externe en remplissant de fiche de consultation et de papierd’ordonnance suivi de quelques soins nécessaire. Autrement dit, si le patient est à l’étatcritique ou grave, il va être transférer directement à la service de l’hospitalisation enayant fiche individuel de malade à la main de la garde du patient. Le patient va subir detraitement et des soins intensifs ou pas et va être observer progressivement l’évolution dela santé du patient qui se récapitule dans le fiche d’observation médical, de prescriptionet de l’analyse médical. Si le patient est guéri, on lui fourni un billet de sorti qui va êtresigner avec le cahier de garde et le rapport de réunion de staff s’il y en a par le major deservice. Ces dossiers vont être vérifié et signer par le chef de service et qui seront enregistréet classe dans l’archive médical à la secrétariat.
On peut résumer comme cela, les activités qui sont manifesté toutes les heures au seinde service pédiatrie au minimum.
18
3.3.4 Modèle Conceptuel des Données
Figure 3.4 – Modèle conceptuel de Données
19
3.3.5 Modèle Physique des Données
Figure 3.5 – Modèle Physique de Données
20
3.4 Diagramme UML
3.4.1 Définition
Le langage de modélisation unifié, de l’anglais Unified Modeling Language (UML), estun langage de modélisation graphique conçu pour fournir une méthode normalisée pourvisualiser la conception d’un système. Il est couramment utilisé en développement logicielet en conception orientée objet pour permettre un développement objet plus aisé 2.
L’UML est le résultat de la fusion de précédents langages de modélisation objet :Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaughet Ivar Jacobson, UML est à présent un standard adopté par l’Object Management Group(OMG).
3.4.2 Utilisation
UML est utilisé pour spécifier, visualiser, modifier et construire les documents né-cessaires au bon développement d’un logiciel orienté objet. UML offre un standard demodélisation, pour représenter l’architecture logicielle. Les différents éléments représen-tables sont :
— Activité d’un objet/logiciel— Acteurs— Processus— Schéma de base de données— Composants logiciels— Réutilisation de composantsGrâce aux outils de modélisation UML, il est également possible de générer automati-
quement tout ou partie du code d’une application logicielle, par exemple en langage Java,à partir des divers documents réalisés.
3.4.3 Formalisme
UML 2.3 propose 14 types de diagrammes (9 en UML 1.3). UML n’étant pas uneméthode, leur utilisation est laissée à l’appréciation de chacun, même si le diagrammede classes est généralement considéré comme l’élément central d’UML ; des méthodolo-gies, telles que l’Unified Process, axent l’analyse en tout premier lieu sur les diagrammesde cas d’utilisation (Use Case). De même, on peut se contenter de modéliser seulementpartiellement un système, par exemple certaines parties critiques.
UML se décompose en plusieurs parties :
2. Il permet en fait de « penser objet » au moment de la conception.
21
Les vues : ce sont les observables du système. Elles décrivent le système d’un pointde vue donné, qui peut être organisationnel, dynamique, temporel, architectural,géographique, logique, etc. En combinant toutes ces vues, il est possible de définir(ou retrouver) le système complet.
Les diagrammes : ce sont des ensembles d’éléments graphiques. Ils décrivent lecontenu des vues, qui sont des notions abstraites. Ils peuvent faire partie de plu-sieurs vues.
Les modèles d’élément : ce sont les éléments graphiques des diagrammes.
Les vues
Une façon de mettre en œuvre UML est de considérer différentes vues qui peuvent sesuperposer pour collaborer à la définition du système :
Vue des cas d’utilisation (use-case view) : c’est la description du modèle vu par lesacteurs du système. Elle correspond aux besoins attendus par chaque acteur (c’est leQUOI et le QUI).
Vue logique (logical view ) : c’est la définition du système vu de l’intérieur. Elle expliquecomment peuvent être satisfaits les besoins des acteurs (c’est le COMMENT).
Vue d’implémentation (implementation view ) : cette vue définit les dépendances entreles modules.
Vue des processus (process view) : c’est la vue temporelle et technique, qui met enœuvre les notions de tâches concurrentes, stimuli, contrôle, synchronisation, etc.
Vue de déploiement (deployment view) : cette vue décrit la position géographique etl’architecture physique de chaque élément du système (c’est le OÙ).
Remarque : le POURQUOI, n’est pas défini dans UML.
Les diagrammes
Les diagrammes sont dépendants hiérarchiquement et se complètent, de façon à per-mettre la modélisation d’un projet tout au long de son cycle de vie. Il en existe 14.
— Diagrammes de structure ou diagrammes statiquesLes diagrammes de structure (structure diagrams) ou diagrammes sta-
tiques (static diagrams) rassemblent :Diagramme de classes (class diagram) : représentation des classes intervenantdans le système.Diagramme d’objets (object diagram) : représentation des instances de classes(objets) utilisées dans le système.Diagramme de composants (component diagram) : représentation des com-posants du système d’un point de vue physique, tels qu’ils sont mis en œuvre(fichiers, bibliothèques, bases de données. . . )
22
Diagramme de déploiement (deployment diagram) : représentation des élé-ments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage. . . ) etla manière dont les composants du système sont répartis sur ces éléments matérielset interagissent entre eux.Diagramme des paquets (package diagram) : représentation des dépendancesentre les paquets (un paquet étant un conteneur logique permettant de regrouperet d’organiser les éléments dans le modèle UML), c’est-à-dire entre les ensemblesde définitions.Diagramme de structure composite (composite structure diagram) : re-présentation sous forme de boîte blanche les relations entre composants d’une classe.Diagramme de profils (profile diagram) : spécialisation et personnalisationpour un domaine particulier d’un méta-modèle de référence d’UML.
— Diagrammes de comportementLes diagrammes de comportement (behavior diagrams) rassemblent :
Diagramme des cas d’utilisation (use-case diagram) : représentation despossibilités d’interaction entre le système et les acteurs (intervenants extérieurs ausystème), c’est-à-dire de toutes les fonctionnalités que doit fournir le système.Diagramme états-transitions (state machine diagram) : représentationsous forme de machine à états finis le comportement du système ou de ses compo-sants.Diagramme d’activité (activity diagram) : représentation sous forme de fluxou d’enchaînement d’activités le comportement du système ou de ses composants.
— Diagrammes d’interaction ou diagrammes dynamiquesLes diagrammes d’interaction (interaction diagrams) ou diagrammes dy-
namiques (dynamic diagrams) rassemblent :Diagramme de séquence (sequence diagram) : représentation de façon sé-quentielle du déroulement des traitements et des interactions entre les éléments dusystème et/ou de ses acteurs.Diagramme de communication (communication diagram) : représentationde façon simplifiée d’un diagramme de séquence se concentrant sur les échanges demessages entre les objets.Diagramme global d’interaction (interaction overview diagram) : repré-sentation des enchaînements possibles entre les scénarios préalablement identifiéssous forme de diagrammes de séquences (variante du diagramme d’activité).Diagramme de temps (timing diagram) : représentation des variations d’unedonnée au cours du temps.
23
3.4.4 Diagramme de cas d’utilisation
Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour donnerune vision globale du comportement fonctionnel d’un système logiciel. Ils sont utiles pourdes présentations auprès de la direction ou des acteurs d’un projet, mais pour le déve-loppement, les cas d’utilisation sont plus appropriés. Un cas d’utilisation représente uneunité discrète d’interaction entre un utilisateur (humain ou machine) et un système. Il estune unité significative de travail. Dans un diagramme de cas d’utilisation, les utilisateurssont appelés acteurs (actors), ils interagissent avec les cas d’utilisation (use cases).
UML définit une notation graphique pour représenter les cas d’utilisation, cette no-tation est appelée diagramme de cas d’utilisation. UML ne définit pas de standard pourla forme écrite de ces cas d’utilisation, et en conséquence il est aisé de croire que cettenotation graphique suffit à elle seule pour décrire la nature d’un cas d’utilisation. Dansles faits, une notation graphique peut seulement donner une vue générale simplifiée d’uncas ou d’un ensemble de cas d’utilisation. Les diagrammes de cas d’utilisation sont sou-vent confondus avec les cas d’utilisation. Bien que ces deux concepts soient reliés, les casd’utilisation sont bien plus détaillés que les diagrammes de cas d’utilisation.
Ils permettent de décrire l’interaction entre l’acteur et le système. L’idée forte est dedire que l’utilisateur d’un système logiciel a un objectif quand il utilise le système ! Le casd’utilisation est une description des interactions qui vont permettre à l’acteur d’atteindreson objectif en utilisant le système. Les use case (cas d’utilisation) sont représentés parune ellipse sous-titrée par le nom du cas d’utilisation (éventuellement le nom est placédans l’ellipse). Un acteur et un cas d’utilisation sont mis en relation par une associationreprésentée par une ligne.
Le plus souvent, le diagramme des cas est établi par la maîtrise d’ouvrage (MOA)d’un projet lors de la rédaction du cahier des charges afin de transmettre les besoins desutilisateurs et les fonctionnalités attendues associées à la maîtrise d’œuvre (MOE).
24
Figure 3.6 – Diagramme de cas d’utilisation du système
25
Sommaire d’identification
Titre : Ajouter un nouveau patient
Résumé : Ce cas d’utilisation permet à l’utilisateur de l’application d’ajouter ouinsérer des informations médicaux d’un nouveau patient soigné.
Acteurs : Secrétaire ou Médecin
Description des scénarios
Pré-conditions : Les dossiers médicaux des patients hospitalisés doivent êtrecomplet et traité après la sortie du malade.
Scénario nominal : 1o - Ce cas d’utilisation se commence quand des dossiersmédicaux sont arrivés à la secrétariat.2o - La secrétaire saisit les informations sur le formulaireconcernant l’état civil du patient et les informations relativesà ses parents.3o - La secrétaire valide les données saisi d’un nouveau patient.4o - L’application enregistre les informations dans la base desdonnées.5o - La secrétaire classe les dossiers des patients dans l’archivemédical .
Cet exemple ci-dessus explique le déroulement du cas d’utilisation « Ajouter un nou-veau patient ». Pour des cas plus complexe, il y a de l’enchaînement alternatifs et deserreurs dans la description de scénario.
26
3.4.5 Diagramme de Séquence
Les diagrammes de séquences sont la représentation graphique des interactions entreles acteurs et le système selon un ordre chronologique dans la formulation UML.
Le diagramme de séquence permet de montrer les interactions d’objets dans le cadred’un scénario d’un Diagramme des cas d’utilisation. Dans un souci de simplification, onreprésente l’acteur principal à gauche du diagramme, et les acteurs secondaires éventuelsà droite du système. Le but étant de décrire comment se déroulent les actions entre lesacteurs ou objets.
La dimension verticale du diagramme représente le temps, permettant de visualiserl’enchaînement des actions dans le temps, et de spécifier la naissance et la mort d’ob-jets. Les périodes d’activité des objets sont symbolisées par des rectangles, et ces objetsdialoguent par le biais de messages.
Plusieurs types de messages (actions) peuvent transiter entre les acteurs et objets.— message simple : le message n’a pas de spécificité particulière d’envoi et de récep-
tion.— message avec durée de vie : l’expéditeur attend une réponse du récepteur pendant
un certain temps et reprend ses activités si aucune réponse n’a lieu dans un délaiprévu.
— message synchrone : l’expéditeur est bloqué jusqu’au signal de prise en compte parle destinataire. Les messages synchrones sont symbolisés par des flèches barrées.
— message asynchrone : le message est envoyé, l’expéditeur continue son activité quele message soit parvenu ou pris en compte ou non. Les messages asynchrones sontsymbolisés par des demi-flèches.
— message dérobant : le message est mis en attente dans une liste d’attente de trai-tement chez le récepteur.
Le langage permet de décaler l’envoi et la réception des messages, pour montrer les délaisde communication non négligeables. La plupart des ateliers UML ne prennent cependantpas en compte cette spécificité.
Pour les cas plus complexes, on peut intégrer des algorithmes dans les diagrammesde séquences. Par le biais de cadres d’interaction, on peut préciser les spécificités d’unensemble de messages :
— alt : fragments multiple alternatifs (si alors sinon)— opt : fragment optionnel— par : fragment parallèle (traitements concurrents)— loop : le fragment s’exécute plusieurs fois— region : région critique (un seul thread à la fois)— neg : une interaction non valable— break : représente des scénarios d’exception
27
— ref : référence à une interaction dans un autre diagramme— sd : fragment du diagramme de séquence en entier
Figure 3.7 – Diagramme de séquence des classes participantes
28
La figure 3.7 nous montre les deux diagrammes de séquence de la classe participante.Il nous explique le fonctionnement général de l’application. Cette diagramme pourraitêtre mise à jour au fur et à mesure qu’il y a une modification de la conception. Selon cediagramme, on peut résumer que notre projet se divise en quatre parties de classe :
— La classe « boundary » 3, c’est à dire l’interface homme-machine ou la vue de notreapplication.
— la classe « controller » , c’est le contrôleur ou la couche service— la classe « entity », c’est la classe « entité » 4.— et la classe « manager » ou « Data Access Object » abrévié en DAO .On peut rassembler les deux classes « entity » et « manager » ce qui nous donne
la couche modèle. Cette couche assure les requêtes et les manipulations de la base desdonnées. Le rôle de la couche « boundary » n’est qu’assurer l’affichage de l’interface gra-phique de notre application, c’est la couche vue . La couche contrôleur c’est l’ensembledes classes qui gère l’affichage tel que les événements (souris, clavier, boutons) et quirelie la couche vue à celle du modèle ou effectue certains calculs (les vérifications, lestestes, les algorithmes de programmation). Cette structure appelée « MVC ou Modèle-Vue-Contrôleur », est vraiment important pour développer un projet pour la raison delisibilité du code et de facilité de mise à jour du programme surtout.
Quelques méthodes 5 interagissent entre les classes. Ce sont les méthodes effectué parl’application lors de l’utilisation d’un client. Prenons un exemple sur « sd AjouterPa-tient », un client arrive et saisit les informations sur le formulaire d’ajout de patientet les valider. Les données sont vérifiées par le contrôleur. Quand les données inséréessont validées, un objet entité instancié par le contrôleur est prêt à exécuter la requêted’insertion dans la base des données par un objet « manager »(créé par un contrôleur).Mais avant tout, l’objet « manager » va exécuter d’abord la requête de vérification si lesdonnées existent déjà. Si oui, la requête de mise à jour va être exécuté, sinon passer à lanouvelle insertion. Après cela, le programme va afficher le message de succès à l’utilisateur.
Remarques : Le nom de la classe entité correspond au nom de la table dans la basedes données, et les attributs d’une classe « entité » correspond aux champs de la table.La classe « manager » sert à manipuler la requête SQL.
3. Certains appellent aussi « front-end ».4. « Plain Old Java Object » en Java5. qui n’a pas de rapport dans la vraie classe dans le projet, c’est utilisé tout simplement pour la
vision global de l’application
29
3.4.6 Diagramme des classes
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter lesclasses et les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Cediagramme fait partie de la partie statique d’UML car il fait abstraction des aspectstemporels et dynamiques.
Une classe décrit les responsabilités, le comportement et le type d’un ensemble d’objets.Les éléments de cet ensemble sont les instances de la classe.
Une classe est un ensemble de fonctions et de données (attributs) qui sont liées en-semble par un champ sémantique. Les classes sont utilisées dans la programmation orien-tée objet. Elles permettent de modéliser un programme et ainsi de découper une tâchecomplexe en plusieurs petits travaux simples.
Les classes peuvent être liées entre elles grâce au mécanisme d’héritage qui permet demettre en évidence des relations de parenté. D’autres relations sont possibles entre desclasses, chacune de ces relations est représentée par un arc spécifique dans le diagrammede classes.
Elles sont finalement instanciées pour créer des objets (une classe est un moule à objet :elle décrit les caractéristiques des objets, les objets contiennent leurs valeurs propres pourchacune de ces caractéristiques lorsqu’ils sont instanciés).
Figure 3.8 – Diagramme de classe de la couche métier
30
Figure 3.9 – diagramme de classe de la couche d’accès à la base des données
3.4.7 Diagramme de package
Les diagrammes de paquetages sont la représentation graphique des relations existantentre les paquetages (ou espaces de noms) composant un système, dans le langage UnifiedModeling Language (UML).
DescriptionLes paquetages peuvent avoir des relations de dépendances UML « classiques » telles
que "le paquetage javax.security dépend du paquetage java.lang". Les paquetages peuventaussi avoir des dépendances spéciales de types package import (importation de paquetage)et package merge (fusion de paquetages).
Un package import est « une relation entre un paquetage important un espace denom et un paquetage, indiquant que l’espace de nom qui importe ajoute les noms desmembres du paquetage à son propre espace de nom ». Par défaut, une dépendance entredeux paquetages est interprétée comme une relation de type package import.
Un package merge est « une relation dirigée entre deux paquetages, indiquant que lescontenus des deux paquetages doivent être combinés. Elle est très similaire à la relation degénéralisation dans le sens où l’élément source ajoute conceptuellement les caractéristiquesde l’élément cible à ses propres caractéristiques ; résultant en un élément combinant lescaractéristiques des deux ».
Les diagrammes de paquetages peuvent utiliser des paquetages pour illustrer les diffé-rentes couches de l’architecture en couches d’un système logiciel. Les dépendances entrepaquetages peuvent être parés d’étiquettes ou de stéréotypes pour indiquer les mécanismesde communication entre les couches.
31
Figure 3.10 – Diagramme de package de l’application
32
Troisième partie
Résultats et Discussions
33
Chapitre 4Résultats
4.1 Installation du Logiciel
Figure 4.1 – Schéma d’installation du logiciel
34
La figure 4.1 ci-dessus nous montre le schéma d’installation de l’application SoftPedqui est encore en version testing pour le moment. Tout d’abord, il faut munir de Sys-tème d’exploitation GNU Linux/Debian Jessie ou la dernière version installé dans votreordinateur. Puis installer les programmes requise par l’application qui sont :
— JDK supérieur ou égale à la version 8.— Apache supérieur ou égale à la version 2.4— Mysql Server-Client supérieur ou égale à la version 5.5
Et enfin,importer les tables de la base des données nommée "pediatrix" et exécuter lesrequêtes dans les fichiers ".sql" pour le tester.
4.2 Interface Homme-Machine
4.2.1 Le Splash screen de démarrage
Figure 4.2 – Splash Sreen de démarrage du logiciel
La figure 4.2 ci-dessus nous montre le Splash screen de démarrage de logiciel indiquantle nom de l’application appelé « SoftPed »en rapport avec « Pediatric Software »à l’envers(pour question d’originalité du nom de l’application).
Au démarrage, le logiciel va charger tout les modules nécessaires pour démarrer l’ap-plication. Après avoir fini de charger les modules, l’application va apparaître le formulaired’un nouveau patient comme la figure 4.3 ci-dessous.
35
4.2.2 L’onglet Nouveau patient
Figure 4.3 – Formulaire Nouveau Patient
La figure 4.3 nous montre le formulaire d’un nouveau dossier de patient complet quiva être enregistrer dans la base des données de la pédiatrie au CHU P.Za.Ga. Ce sont lesinformations de bases du patient comme :
— Information générale (Renseignement du patient)— Parents (Renseignement du parent du malade)— Mouvements (entrée et sortie du patient s’il est hospitalisé)— Le contact rapide— La référenceLe formulaire information générale contient le champ :— activité subi par le patient c’est-à-dire qu’il fait une simple consultation externe
seulement ou qu’il se fait hospitalisé par le médecin.— Numéro de fiche individuel du malade (F.I.M) qui sert à identifier le patient passant
au service de la pédiatrie.— le nom et prénoms du malade— le genre (sexe) du patient— Son âge qui est défini par sa date de naissance— Son lieu de naissance— Sa catégorieLe formulaire mouvement du patient contient le champ suivant :— les motifs d’entrée— la date et l’heure d’entrée
36
— la date et l’heure de sortie— la diagnostique de sortieLe formulaire parents du patient contient le champ suivant :— Nom complet du père— Profession du père— l’ethnie du père— nom complet de la mère— Profession de la mère— l’ethnie de la mèreLe formulaire contact rapide du patient contient le champ suivant :— adresse du patient— domicile du patient— nom du personne à contacter— adresse du personne à contacter— la téléphone du personne à contacter
Le formulaire référence du malade contient le champ suivant :— le choix entre VR,VRP,AR 1
— Ref 2
— PEC 3
— Médecin traitant
1. Respectivement Vrai Référé, Vrai Référé Privé, Auto Référé2. Référée par3. Prise en charge
37
4.2.3 L’onglet Soins et Paramètre
Figure 4.4 – Formulaire d’ajout nouveau soins et de paramètre du patient
Quand on clique sur l’onglet Soins et paramètre, cela va afficher le formulaire deparamètre et le formulaire de soin qui correspondent respectivement au fiche de paramètreet le fiche de soins du malade lors de son hospitalisation à la pédiatrie.
Le formulaire de paramètre contient le champ suivant :— Identifiant du patient— la caractéristique de l’urine du malade— Le changement de sa fréquence cardiaque— Le changement de son poids— Le changement de périmètre de crânien ou son périmètre abdominal— Ses vomissements— Eva— Date de prise paramètre— Le changement de sa tension artérielle— Le changement de sa fréquence respiratoire— Le changement de sa température— la caractéristique de son selle— l’evendolLe formulaire soin du malade contient le champ suivant :— Identifiant du patient— Date de prescription du malade— Date de traitement
38
— Types de traitements qui sont :– Injection– Orale– Pansement
39
4.2.4 L’onglet Paramètre
Figure 4.5 – Formulaire de Paramètre
La figure 4.5 nous la contenue de l’onglet qui compose les formulaires suivant :— Ajout de nouvel utilisateur— Exportation des données— Ajout de nouveau docteur— Ajout de nouvelle PathologieLe formulaire d’ajout de nouvel utilisateur contient le champ suivant :— le nom du nouvel utilisateur— son mot de passe— son type de compte ou droit d’utilisateurLe formulaire d’exportation des données contient le champ suivant :— l’action à effectuer (Importer/Exporter)— le chemin de fichierLe formulaire du nouveau docteur contient le champ suivant :— Son nom et ses prénoms— Son immatriculationLe formulaire du nouvelle pathologie contient le champ qui indique le nom de la nou-
velle pathologie.
40
4.2.5 L’onglet Recherche
Figure 4.6 – Formulaire de Recherche et Liste de patient
L’onglet recherche indique dans la figure 4.6 nous montre quelques contenus qui sont :— Les fenêtres internes ou « Internal Frame »en anglais— Le tableau qui indique la liste des patients— Le formulaire de recherche de patientLe formulaire de recherche d’un patient contient le champ suivant :— Le nom du patient à rechercher— Le filtre de résultats à afficher
41
Chapitre 5Discussions
5.1 Difficultés rencontrées
Au cours développement de notre projet, beaucoup de problème qu’on a affronté.Parmi ces problèmes, les grandes lignes sont basées sur la grandeur du projet. En effet,un gros projet demande beaucoup de temps nécessaire puisqu’on a besoins d’implémenterplusieurs modules pour que le programme soit fonctionnel. En plus, la programmation soli-taire de ce gros projet nécessite un certain effort surtout au niveau d’analyse et conceptionqui demandent beaucoup de réflexion et d’abstraction. En outre, pendant qu’ on a conçuet implémenté ce programme, on constate qu’il y a trop des données sensibles c’est-à-direqu’il est indispensable de construire une algorithme complexe sur le système de validationet de vérification des données à insérer. Quant à la planification du projet, il est obligéd’élargir le calendrier de la gestion de projet parce que des coupures électriques répétitiveset à longue durée persistent. Côté matériel, c’est ce qui est l’un de problème qui à retardéle développement car la dernière version de l’IDE 1 qu’on a utilisé 2 consomme beaucoupde mémoire vive et de processeur. Ces circonstances risquent de planter un vieux ma-chine. Lier à ce problème de performance, on n’a pas pu utiliser la fonctionnalité palettesur Eclipse Mars IDE, alors on est obligé de tout coder à la main. Cette situation nousfait aboutir à un ralentissement de l’avancement du développement de l’application. Dupoint de vue individuel, limité en temps et en bibliographie nous n’avons pas été capablede mener à fond notre recherche afin d’arriver à mettre au point un travail beaucoup plusattractif.
1. « Integrated Development Environment »2. En raison de mise à jour de fonctionnalité important
42
5.2 Avantage et particularité du logiciel
La particularité de l’application est qu’ elle n’est qu’un simple 3 logiciel de clinique oud’un cabinet médical. Ce programme est conçu pour s’adapter à tous les départements depédiatrie de tous les CHU à Madagascar. En plus de l’usage simple de l’application, celaimplique la facilité de rapport statistique des enfants malades ou morts nés, des maladiesrécurrentes et des cas de malformations, etc. Pour la côté utilisateur, ce programme résoutles problèmes existants dans le service pédiatrie y compris la rapidité de la tâche et lafacilité de l’utilisation du programme. Pour la côté technique, ce qui rend la qualité duprogramme remarquable, on a employé des méthodes de conception très rigoureux pendantnotre projet qui sont :
— Utilisation de patron de conception— Adoption de l’architecture MVC— Utilisation de la méthode RUP
5.2.1 Utilisation de patron de conception
Définition
En développement logiciel, un patron de conception (plus souvent appelé design pat-tern) est un arrangement caractéristique de modules, reconnu comme bonne pratiqueen réponse à un problème de conception d’un logiciel. Il décrit une solution standard,utilisable dans la conception de différents logiciels.
Un patron de conception est issu de l’expérience des concepteurs de logiciels. Il décritsous forme de diagrammes un arrangement récurrent de rôles et d’actions joués par desmodules d’un logiciel, et le nom du patron sert de vocabulaire commun entre le concepteuret le programmeur. D’une manière analogue à un motif de conception en architecture, lepatron de conception décrit les grandes lignes d’une solution, qui peuvent ensuite êtremodifiées et adaptées en fonction des besoins.
Les patrons de conception décrivent des procédés de conception généraux et permettenten conséquence de capitaliser l’expérience appliquée à la conception de logiciel. Ils ont uneinfluence sur l’architecture logicielle d’un système informatique.
Historique
Formalisés dans le livre du « Gang of Four » (GoF, Erich Gamma, Richard Helm,Ralph Johnson (en) et John Vlissides (en)) intitulé Design Patterns – Elements of Reu-sable Object-Oriented Software en 1995. Les patrons de conception tirent leur origine des
3. C’est-à-dire que le logiciel est spécifié pour un seul centre médical. En plus, les logiciels médicauxstandards, qui sont disponibles sur internet, ne sont pas adapter au système existant
43
travaux de l’architecte Christopher Alexander dans les années 70, dont son livre A PatternLanguage définit un ensemble de patrons d’architecture.
Utilité du patron de conception
Les patrons servent à documenter des bonnes pratiques basées sur l’expérience. Ilsproposent des solutions à des problèmes qui peuvent être difficilement résolus par un seulcomposant : la description de la plupart des patrons implique plusieurs rôles qui peuventêtre joués par plusieurs composants d’un logiciel. Par exemple, le patron Observer impliquedeux rôles qui sont le sujet et l’observateur.
Les patrons apportent un vocabulaire commun entre l’architecte informatique et leprogrammeur : Si le programmeur connait le patron de conception Observer, alors l’archi-tecte informatique n’aura pas besoin de lui donner de longues explications et le dialoguese limitera à « ici, j’ai utilisé un Observer ».
En programmation, les patrons de conception peuvent être utilisés avant, pendant,ou après le travail de programmation : utilisé avant, le programmeur utilisera le patroncomme guide lors de l’écriture du code source ; utilisé après, il servira comme exemple pourrelier différents modules de code source déjà écrits, ce qui implique d’écrire le code sourcenécessaire à leur liaison, et le code qui les fera correspondre au patron de conception ;s’il est utilisé pendant le travail de programmation, le programmeur constatera que lecode qui vient d’être écrit a des points communs avec un patron existant et effectuerales modifications nécessaires pour que le code corresponde au patron. La bonne pratiqueconsiste toutefois à n’utiliser un patron qu’une fois qu’il est clair que sa flexibilité estnécessaire.
Patrons de conception du GoF
On distingue trois familles de patrons de conception selon leur utilisation :— construction ou création : ils définissent comment faire l’ instanciation et la
configuration des classes et des objets ;— structuraux : ils définissent comment organiser les classes d’un programme dans
une structure plus large (séparant l’interface de l’implémentation) ;— comportementaux : ils définissent comment organiser les objets pour que ceux-ci
collaborent (distribution des responsabilités) et expliquent le fonctionnement desalgorithmes impliqués.
Ci-dessous, les 23 patrons GoF selon leur catégorie :— construction ou création : Factory et Abstract factory, Builder, Prototype,
Singleton,Factory Method ;— structuraux : Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy ;
44
— comportementaux :Chain of responsibility, Command,Iterator, Memento, Ob-server, State,Strategy, Interpreter, Template method, Visitor, Mediator.
Le patron Modèle-Vue-Contrôleur (MVC),le patron que nous avons utiliser pour ceprojet, est une combinaison des patrons Observateur, Stratégie et Composite, ce qui formeainsi un patron d’architecture.
45
5.2.2 Adoption de l’architecture MVC
Figure 5.1 – Modèle MVC
Le schéma de cette figure résume lesdifférentes interactions entre le modèle, lavue et le contrôleur. Les lignes pleinesindiquent une dépendance (importation)tandis que les pointillés sont des événe-ments.
Le patron d’architecture logicielle modèle-vue-contrôleur (en abrégé MVC, en anglaismodel-view-controller), tout comme les pa-trons modèle-vue-présentation ou présen-tation, abstraction, contrôle, est un modèledestiné à répondre aux besoins des applica-tions interactives en séparant les probléma-tiques liées aux différents composants ausein de leur architecture respective.
Ce paradigme regroupe les fonctions nécessaires en trois catégories :— modèle (modèle de données) ;— une vue (présentation, interface utilisateur) ;— un contrôleur (logique de contrôle, gestion des événements, synchronisation).Son but principal était de proposer une solution générale aux problèmes d’utilisateurs
manipulant des données volumineuses et complexes. D’abord appelé Model-View-Editor(Modèle-vue-éditeur) 4
Architecture
L’organisation d’une interface graphique est délicate. L’architecture "MVC" ne pré-tend pas en éliminer tous les problèmes, mais fournit une première approche pour ce faire.Offrant un cadre normalisé pour structurer une application, elle facilite aussi le dialogueentre les concepteurs.
L’idée est de bien séparer les données, la présentation et les traitements. Il en résulteles trois parties énumérées plus haut : le modèle, la vue et le contrôleur.
À noter que le modèle MVC est utilisé uniquement pour la couche présentation ( côtéserveur ) dans l’architecture d’une application. La couche métier dans une applicationn’est en aucun cas concernée par ce modèle.
1. Modèle
Le modèle représente le cœur (algorithmique) de l’application : traitements desdonnées, interactions avec la base de données, etc. Il décrit les données manipulées
4. Trygve Reenskaug(créateur du pattern MVC) le renomme Modèle-vue-contrôleur
46
par l’application. Il regroupe la gestion de ces données et est responsable de leurintégrité. La base de données sera l’un de ses composants. Le modèle comportedes méthodes standards pour mettre à jour ces données (insertion, suppression,changement de valeur). Il offre aussi des méthodes pour récupérer ces données. Lesrésultats renvoyés par le modèle ne s’occupent pas de la présentation. Le modèlene contient aucun lien direct vers le contrôleur ou la vue. Sa communication avecla vue s’effectue au travers du patron Observateur.
Le modèle peut autoriser plusieurs vues partielles des données. Si par exemple leprogramme manipule une base de données pour les emplois du temps, le modèlepeut avoir des méthodes pour avoir tous les cours d’une salle, tous les cours d’unepersonne ou tous les cours d’un groupe de TD.
2. Vue
Ce avec quoi l’utilisateur interagit se nomme précisément la vue. Sa première tâcheest de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoirtoute action de l’utilisateur (hover, clic de souris, sélection d’un bouton radio,cochage d’une case, entrée de texte, de mouvements, de voix, etc.). Ces différentsévénements sont envoyés au contrôleur. La vue n’effectue pas de traitement, elle secontente d’afficher les résultats des traitements effectués par le modèle et d’interagiravec l’utilisateur.
Plusieurs vues peuvent afficher des informations partielles ou non d’un même mo-dèle. Par exemple si une application de conversion de base a un entier commeunique donnée, ce même entier peut être affiché de multiples façons (en texte dansdifférentes bases, bit par bit avec des boutons à cocher, avec des curseurs). La vuepeut aussi offrir à l’utilisateur la possibilité de changer de vue. Ceci permet unecertaine récursivité du modèle.
3. Contrôleur
Le contrôleur prend en charge la gestion des événements de synchronisation pourmettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événementsde la vue et enclenche les actions à effectuer. Si une action nécessite un changementdes données, le contrôleur demande la modification des données au modèle afin queles données affichées se mettent à jour. D’après le patron de conception observa-teur/observable, la vue est un « observateur » du modèle qui est lui « observable». Certains événements de l’utilisateur ne concernent pas les données mais la vue.Dans ce cas, le contrôleur demande à la vue de se modifier. Le contrôleur n’effec-tue aucun traitement, ne modifie aucune donnée. Il analyse la requête du client etse contente d’appeler le modèle adéquat et de renvoyer la vue correspondant à lademande.
Par exemple, dans le cas d’une base de données gérant les emplois du temps des
47
professeurs d’une école, une action de l’utilisateur peut être l’entrée (saisie) d’unnouveau cours. Le contrôleur ajoute ce cours au modèle et demande sa prise encompte par la vue. Une action de l’utilisateur peut aussi être de sélectionner unenouvelle personne pour visualiser tous ses cours. Ceci ne modifie pas la base descours mais nécessite simplement que la vue s’adapte et offre à l’utilisateur unevision des cours de cette personne.
Quand un même objet contrôleur reçoit les événements de tous les composants,il lui faut déterminer l’origine de chaque événement. Ce tri des événements peuts’avérer fastidieux et peut conduire à un code peu élégant (un énorme switch).C’est pourquoi le contrôleur est souvent scindé en plusieurs parties dont chacunereçoit les événements d’une partie des composants.
Flux de traitement
En résumé, lorsqu’un client envoie une requête à l’application :— la requête envoyée depuis la vue est analysée par le contrôleur (par exemple un clic
de souris pour lancer un traitement de données) ;— le contrôleur demande au modèle approprié d’effectuer les traitements et notifie à
la vue que la requête est traitée (via par exemple un handler ou callback) ;— la vue notifiée fait une requête au modèle pour se mettre à jour (par exemple affiche
le résultat du traitement via le modèle).
Avantages
Un avantage apporté par ce modèle est la clarté de l’architecture qu’il impose. Celasimplifie la tâche du développeur qui tenterait d’effectuer une maintenance ou une amé-lioration sur le projet. En effet, la modification des traitements ne change en rien la vue.Par exemple on peut passer d’une base de données de type SQL à XML en changeantsimplement les traitements d’interaction avec la base, et les vues ne s’en trouvent pasaffectées.
5.2.3 Utilisation de méthode RUP
Définition
Le processus unifié — PU, ou UP (anglais : unified process) — est une méthode dedéveloppement pour les logiciels orientés objets. C’est une méthode générique, itérativeet incrémentale, contrairement à la méthode séquentielle Merise.
48
Figure 5.2 – Aspects RUP : les aspects dynamiques sont à l’horizontale, les statiquesaffichés verticalement
Le Rational Unified Process (RUP) est l’une des plus célèbres implémentations dela méthode PU, livrée clés en main, permettant de donner un cadre au développementlogiciel, répondant aux exigences fondamentales préconisées par les créateurs d’UML :
— une méthode de développement doit être guidée par les besoins des utilisateurs— elle doit être centrée sur l’architecture logicielle— elle doit être itérative et incrémentale
Fonctionnement
Le pilotage par les diagrammes de cas d’utilisation (DCU) revêt une significationconcrète : des DCU, on doit tirer les modèles d’analyse, de conception, de déploiement.Ce sont eux qui sont implantés et ce sont les cas d’utilisation prévus qui vont présiderà l’élaboration des lignes de tests : les cas d’utilisation doivent finalement être permispar le nouveau logiciel. Les DCU sont les modèles garantissant la cohérence du processusdu développement. Ce sont eux qui unifient. Enfin les DCU sont, de par leur nature,intrinsèquement liés à l’architecture du système.
Celle-ci est conçue dès le départ de façon très pragmatique : elle est adaptée au contextede travail, aux besoins de l’utilisateur, aux possibilités de réutilisation (re-use) de biblio-thèques ou de « briques » préexistantes.
L’élaboration de l’architecture est d’abord grossière et indépendante des cas d’utili-sation (on veillera cependant à ce qu’elle n’empêche pas leur réalisation) puis, un sous-ensemble des fonctions essentielles est identifié et l’architecture est reprise et détailléesuivant cet ensemble. De la spécification à la précision des cas, l’architecture évolue, in-cluant finalement de nouveaux cas, ainsi de suite, jusqu’à ce que l’architecture ait atteint
49
un niveau de développement suffisamment élevé et stable pour donner lieu au développe-ment d’un prototype qui sera présenté au client achevant ainsi une itération.
Une itération est la succession des étapes d’une activité. Un incrément est une avancéedans les stades de développement. À chaque itération on retrouve les phases de spécifica-tion des besoins, de conception, jusqu’au prototypage exécutable. Une nouvelle itération,par exemple après démonstration du prototype aux utilisateurs, reprendra la spécificationen la précisant ou la corrigeant, puis reprenant l’élaboration, etc.
Les incréments sont définis par le projet, et chaque incrément va ajouter de nouvellesfonctionnalités. Les incréments peuvent suivre les différents cas d’utilisation par exemple.La difficulté résidera dans le fait de combiner finalement les sous-projets ou incrémentsensemble et de respecter leurs interdépendances et la cohérence générale du produit envi-sagé. C’est donc également un développement sous forme de composants qui est proposé.Il utilisera au mieux les apports des technologies objets.
PU intègre les deux visées dans le but de minimiser les risques de contre-sens parrapport aux besoins ainsi que le risque de développements infinis, indéfinis, mal définisou inachevés : Ici l’utilisateur peut corriger lui-même, sur les prototypes, la tournure queprend le développement. Dès le début, des résultats tangibles sont obtenus même s’ilsne sont que prototypiques. Certaines implémentations de PU considèrent d’ailleurs lesprototypes comme des versions à part entière du système final. Les fonctions subalternespeuvent très bien, dans une telle optique, être abandonnées en cours de route pour desquestions de coûts ou de délais par exemple. Enfin, si les besoins utilisateurs changent encours de développement, cette évolution peut être, dans une certaine mesure, intégrée. Cen’est pas le cas dans le cadre d’un développement séquentiel.
PU prévoit globalement un cycle de vie où les itérations (spécifications, analyse,conception, implémentation et tests) sont regroupées en catégories d’activités. Ces activi-tés sont soit initiales (création), soit intermédiaires (élaboration, construction) soit finales(transition vers l’utilisateur ou mise en production). Ces catégories d’activité découpentla réalisation du produit comme une succession temporelle (séquences) mais comprennenttoutes les tâches structurantes du projet (raffinage successifs, itérations) et proposent uneorganisation matricielle du volume d’activité total fourni : il est évident qu’en phase decréation, une plus grande partie du temps sera consacrée à l’analyse des besoins qu’auxtests ; inversement, en phase de transition, les tests sont encore en cours alors que l’analysedes besoins et son raffinage sont théoriquement bouclés depuis la phase de construction.
Ces concepts ne sont pas simples à appréhender et à implanter dans une gestion deprojet. Cela nécessite une démarche active de la part de celui qui décide de mener le projetselon ces préceptes de façon que la démarche soit effectivement itérative et incrémentale.
L’utilisation de ces méthodes rend notre application de bonne qualité et plus soupleet robuste.
50
Quatrième partie
Conclusion et Annexe
51
Chapitre 6Conclusion
Bref, tout au long de ce projet, nous avons acquis une certaine compétence surtoutsur l’utilisation de langage de programmation Java et la programmation orientée objet.En outre, même si, le projet n’arrive pas encore à ses fins , nous sommes parvenus àconcevoir une application de qualité au dessus de la moyenne, grâce à l’emploi de laméthodologie en génie logiciel 1 y compris , l’utilisation du cycle en V et la méthodeRUP 2. Les objectifs atteints au cours de ce projet sont l’analyse ou l’expression desbesoins, la conception générale, l’ implémentation ou codage de l’application et le testunitaire. Pendant la phase d’analyse, on a rédigé le cahier de charge fonctionnel et utiliséla méthode MERISE. Quant à la phase de conception, on a adopté la méthode UML. Puisnous avons choisi le langage Java en développant sous l’environnement de développementintégré appelé Eclipse Mars version 2.0 pendant la phase d’implémentation et de testunitaire. Vu la présence de quelques problèmes pendant le développement du projet, nousavons pu tout résoudre grâce à nos efforts et nos recherches des documentations. Si nousavons atteint les deux phases qui sont l’intégration et la validation, on pourra dire que leprogramme est opérationnel dans tous les services de la pédiatrie dans tous les CHU deMadagascar. Cette application est loin d’être terminé car c’est un gros projet informatiqued’entreprise qui peut durer de quatre(4) à neuf(9) mois de développement pour la raisonde sensibilité des données et nécessite au moins quatre(4) personnes 3 pour le terminerd’une manière plus vite possible. De toute façon, nous avons accompli la phase d’analyseet de la conception, alors il ne reste que de développer, de tester et de mettre à jour leprogramme. L’amélioration possible sur l’application est la mise à jour sur la sécurité etla validation des données sur le formulaire.
1. aller à l’annexe page 532. Signifie « Rational Unified Programming ».3. Selon la méthode RUP
52
Chapitre 7Annexes et Quelques Définitions
7.1 Le génie Logiciel
Le génie logiciel (anglais software engineering) est une science de génie industriel quiétudie les méthodes de travail et les bonnes pratiques des ingénieurs qui développentdes logiciels. Le génie logiciel s’intéresse en particulier aux procédures systématiques quipermettent d’arriver à ce que des logiciels de grande taille correspondent aux attentes duclient, soient fiables, aient un coût d’entretien réduit et de bonnes performances tout enrespectant les délais et les coûts de construction.
On peut définir aussi que le génie logiciel est « l’ensemble des activités de conceptionet de mise en œuvre des produits et des procédures tendant à rationaliser la productiondu logiciel et son suivi ».
Les activités clés du cycle de vie d’un logiciel sont : l’analyse fonctionnelle, l’architec-ture, la programmation, les tests, la validation, la maintenance et la gestion de projet.
7.1.1 Analyse des besoins
Consiste à récolter des informations détaillées concernant l’éventail de fonctions quedevra offrir le logiciel, ainsi que les résultats qu’il devra donner. Des connaissances dudomaine d’activité du logiciel (exemple : banque, industrie, administration) facilitent letravail de l’ingénieur.
7.1.2 Conception
Consiste à déterminer et schématiser les grandes lignes des mécanismes qui devrontêtre programmés en vue d’obtenir chacune des fonctions que devra offrir le logiciel. Desplans conceptuels du logiciel selon les formalismes de modélisation (UML par exemple)seront alors réalisé. C’est également à cette étape que l’utilisation de patrons de conceptionlogiciel sont appliqués afin de résoudre certains problèmes de conceptions communs. Le
53
recours à l’architecture logicielle pourra également être effectué.
7.1.3 Construction
Consiste à la rédaction du code source, des instructions de programme qui offriront lesfonctions attendues, et qui sont le corps du logiciel. La programmation est alors effectuéeen suivant les plans initialement établis lors de la conception. Selon la méthodologie choisie(ex : itératif), les ingénieurs pourront retourner sur les planches a dessin afin d’ajuster laconception avec la réalité de la construction.
7.1.4 Tests
Une suite de vérifications faites par les ingénieurs qui servent à déceler un maximum debugs, des défauts de programmation qui provoquent des pannes ou des résultats incorrects.La validation est un examen réalisé par le client durant lequel il vérifie que les fonctionsoffertes par le logiciel correspondent à ses attentes et à ses besoins.
7.1.5 Maintenance
Des opérations d’analyse, de programmation et de test réalisés après coup, une foisque le logiciel a été mis à disposition des utilisateurs et durant lesquelles le logiciel subitdes transformations, des corrections ou des améliorations. La facilité de cette maintenancedépendra de l’importance qui lui a été accordé durant la phase de conception.
7.1.6 Gestion de projets
Une activité réalisée tout au long des travaux sur le logiciel, qui consiste à organiserune équipe d’ingénieurs, répartir les tâches et veiller à l’avancée des travaux en vue definir dans les délais prévus. C’est une activité de management également exercée dansd’autres domaines d’ingénierie.
7.1.7 Les outils et méthodes
Les thématiques du génie logiciel recouvrent notamment les outils et méthodes de spé-cification de fonctionnalités d’un logiciel, les méthodes formelles (Méthode B par exemple),les outils et les méthodes de conception de logiciel, les outils de conception, atelier logiciel,l’automatisation de l’optimisation du code. D’autres domaines sont connexes au génie lo-giciel dans la mesure où ils partagent des outils communs : description formelle du code,grammaires des langages manipulés. Ces domaines sont par exemple :
— la compilation ;— l’interprétation de code ;
54
— la traduction de code d’un langage de programmation vers un autre.— un éditeur dédié au langage de programmation— les bibliothèques de composants— les outils de planification— un outil de gestion des exigences pour développer et gérer les exigences relatives
au code produit— un outil de gestion de configuration pour contrôler les évolutions du code produit— des moyens de tester pour vérifier la conformité du code produit— des outils de génération de métriques pour caractériser la conformité du code pro-
duit
7.1.8 La Gestion de la Qualité
Bien que l’on passe du génie de la production à celui de la décision, ces domaines ont unimpact tellement important sur l’activité de génie logiciel qu’ils doivent être mentionnés :
La gestion de la qualité permet de contrôler l’organisation de la production du code.La qualité repose sur des méthodes. Le management est un modèle et un moyen humainqui a pour but d’améliorer la production.
7.1.9 La gestion de la configuration
Permet de contrôler les évolutions du code produit et les différentes versions du produit.
7.2 Méthodes de conception de logiciel
7.2.1 La Bête à Cornes (Analyse fonctionnelle)
On constate souvent que les acteurs projet privilégient des solutions déjà connues sansanalyser concrètement le besoin qui justifie le projet. Avant d’imposer un "comment" ouune solution, il faut se tourner vers l’utilisateur et/ou le demandeur, pour aboutir demanière structurée à la solution, car un projet n’a de sens que s’il satisfait le besoin. Ilconvient donc d’exprimer le besoin et rien que le besoin dès le lancement du projet. Ils’agit d’expliciter l’exigence fondamentale qui justifie la conception, ou la reconceptiond’un produit. Pour cela, il est essentiel de se poser les trois questions suivantes :
La bête à cornes est un outil de représentation de ces questions fondamentales. C’estun des éléments de la méthode APTE :
— Dans quel but ? (pour quoi faire ?)— pour quoi ce but ?— pour quoi ? Besoin— pourquoi ? Cause (validation du besoin).
55
Figure 7.1 – La bête à Cornes
7.2.2 Cahier des charges fonctionnel
Il s’agit d’exprimer les services que doit rendre l’objet étudié à ses utilisateurs pourcela il faut :
Lister les contextes d’utilisation de l’objet et autres phases ou situations de vie. Pourchacun de ces contextes lister les fonctions de l’objet et en effectuer le contrôle de validitéPour chacune des fonctions, déterminer les critères de valeur et en effectuer le contrôle devalidité.
Les principes de base de l’expression fonctionnelle sont les suivants :— L’objet étudié n’a de fonctions qu’en utilisation— Les fonctions d’un objet sont indépendantes des solutions qui les réalisent— Les fonctions d’un objet sont indépendantes entre elles
7.3 UML et la programmation orientée objet(POO)
7.3.1 L’agrégation
L’agrégation est une association avec relation de subordination, représentée par untrait reliant les deux classes et dont l’origine se distingue de l’autre extrémité (la classesubordonnée) par un losange vide. Une des classes regroupe d’autres classes. L’objet Tutilise une instance de la classe T’.
En programmation orientée objet, l’agrégation permet de définir une entité commeétant liée à plusieurs entités de classe différentes. C’est une généralisation de la composi-
56
tion, qui n’entraîne pas l’appartenance.
7.3.2 La composition
La composition est une agrégation avec cycle de vie dépendant : la classe composéeest détruite lorsque la classe mère disparait. L’origine de cette association est représentéepar un losange plein.
Un lien de composition symbolise l’existence d’une agrégation particulière, dite ’forte’,entre deux entités (classes).
Une composition est définie par les points suivants :— Durée de vie : toute classe agrégée est détruite quand la classe composite est
détruite.— Exclusivité : une classe agrégée ne peut l’être que par une seule classe composite.— Notion de « fait partie de ».
La classe Voiture est une classe composite composée d’un élément de la classe Carburateur(un carburateur). La classe Carburateur est une classe agrégée. Quand une instance de laclasse Voiture (une voiture) est détruite (dans un accident par exemple), le carburateur(instance de la classe Carburateur) aussi. Le carburateur fait partie de la voiture.
À noter que la distinction entre composition et agrégation n’est pas absolue : c’est lecontexte qui détermine ce choix. Ainsi une voiture peut être vue comme l’agrégation d’unhabitacle et 4 roues du point de vue d’un logiciel de casse automobile (la destruction dela voiture n’entrainera pas celle des roues si elles sont récupérées auparavant), ou biencomme une composition du point de vue d’un logiciel de simulation de comportementroutier (où les roues nécessitent d’être traitées comme des entités distinctes, mais où levéhicule reste considéré comme un tout).
57
Bibliographie
[1] S. ELACHOURI. Merise.[2] Pierre Gérard. MERISE, « Modélisation des systèmes d’information ». IUT de Vil-
letaneuse Université de Paris.[3] Michael W Engle Bobbi J. Young Ph.D. Jim Conallen Kelli A. Houston Grady Booch,
Robert A. Maksimchuk. Object-Oriented Analysis and Design with Applications,Third Edition. NA, April 2007.
[4] Wikitionnaire. Pédiatrie, 2016. https ://fr.wikipedia.org.[5] Pascal Roques. UML 2 par la pratique « Etudes de cas et exercices corriges ». Ey-
rolles, 2006. http ://www.editions-eyrolles.com.[6] Grady Booch James Rumbaugh Ivar Jacobson. The Unified Modeling Language
Reference Manual,Second Edition. NA, July 2004.[7] Craig Larman. APPLYING UML AND PATTERNS,« An Introduction to Object-
Oriented Analysis and Design and the Unified Process ,Second Edition ».[8] KevinZhang. Design Patterns,« Elements of reusable Object-Oriented Software ».[9] James R. Trott Alan Shalloway. DESIGN PATTERNS EXPLAINED,« A New Pers-
pective on Object-Oriented Design ».[10] Tutorial Point. JAVA DESIGN PATTERNS,« Problem solving approches ». Tutorial
Point.[11] Cyrille Herby. APPRENEZ À PROGRAMMER EN JAVA. OpenClassroom.[12] Hendrik Ebbers. JAVAFX ENTREPRISE. Edition Canoo.[13] Alla Redko ;Irina Fedortsova. JavaFX,« Working with JavaFX Components Release
8 ». Oracle, August 2014.[14] Joni Gordon Cindy Castillo Jasper Potts, Nancy Hildebrandt. JavaFX,« Getting
Started with JavaFX ». Oracle, August 2014.[15] Greg Brown Irina Fedortsova. JavaFX ,« Mastering FXML Release 2.2 ». Oracle,
January 2014.[16] Cegedim. Logiciel pour les pédiatres, 2016. http ://www.cegedim-
logiciels.com/specialites/8-pediatre.html.[17] Le quotidien du medecin. Tableau 2010 des logiciels médicaux, 2016.[18] E-agenda. Logiciel de pédiatrie, 2016. https ://e-agenda.fr/logiciel-pediatre.php.
58
