Le processus unifié méthode de développement pour les logiciels orientés objets

Le processus unifié (UP)

ANALYSE ET CONCEPTION

Ce chapitre va présenter la totalité des parties Analyse/Conception du problème présenté dans le chapitre précédent.

Présentation du périmètre du projet

Le périmètre du projet englobe tous les centre étatique du cancer au Maroc, d’une autre façon tous les systèmes d’information hospitalier présents dans les cinq centres hospitaliers universitaires (Rabat, Casablanca, Oujda et Fès).
L’application gère seulement les dossiers médicaux relatives aux tumeurs stromales, ainsi que les taches associés aux services d’oncologies.

Le processus unifié (UP)

Principes

Le processus unifié est une méthode de développement pour les logiciels orientés objets. C’est une méthode générique, itérative et incrémentale. Il vient compléter la systémique des modèles UML.
Il n’existe pas un seul processus de développement, ni de processus standard, cependant des caractéristiques essentielles peuvent être mises en avant :
• Pilotage par les cas d’utilisation
• Focalisation sur l’architecture
• Utilisation de « patrons » de conception (Design Patterns)
• Déroulement itératif et incrémental
2.2 Etude comparative des processus de développement
• Rational Unified Process (RUP)
La méthode RUP est une méthode générique, itérative et incrémentale assez lourde mais elle s’adapte très facilement aux processus et aux besoins du développement.

Analyse et conception

la méthode RUP, permet d’utiliser une architecture qui est basée sur les composants. Ensuite, les modifications qui interviennent au cours du projet peuvent être prises en charge et intégrées directement. Chaque intégration se fait au fur et à mesure du projet, et non tout à la fin quand les risques sont plus grands. Les problèmes sont ainsi découverts en cours de projet et rectifiés.
• 2TUP (2 Tracks Unified Process) Le 2TUP propose un cycle de développement en Y, Il commence par une étude préliminaire qui consiste essentiellement à identifier les acteurs qui vont interagir avec le système à construire, les messages qu’échangent les acteurs et le système, à produire le cahier des charges et à modéliser le contexte (le système est une boîte noire, les acteurs l’entourent et sur l’axe qui lie un acteur au système on aura les messages que les deux s’échangent avec le sens). Le processus s’articule ensuite autour de trois phases essentielles : 1. une branche technique ; 2. une branche fonctionnelle ; 3. une phase de réalisation.
• UP7 Cette démarche est fondée d’une part sur la vision du processus de développement et d’autre part sur les expériences tirées de la réalisation en entreprise de projets avec UML. La démarche est articulée suivant deux axes: les quatre phases qui correspondent à celles d’UP et sept activités. Le schéma ci-dessous représente la démarche globale de la méthodes suivant les quatre phases :

choix du processus à suivre

La méthode 2TUP est choisie comme un processus unifié, que nous avons adopté en se basant sur ses trois branches : La branche fonctionnelle capitalise la connaissance du métier de l’entreprise. Cette branche capture des besoins fonctionnels, ce qui produit un modèle focalisé sur le métier des utilisateurs finaux. La branche technique capitalise un savoir-faire technique et/ou des contraintes techniques. Les techniques développées pour le système le sont indépendamment des fonctions à réaliser. La phase de réalisation consiste à réunir les deux branches, permettant de mener une conception applicative et enfin la livraison d’une solution adaptée aux besoins.
Diagramme de Gantt Le diagramme de Gantt est un outil utilisé en ordonnancement et en gestion de projet et permettant de visualiser dans le temps les diverses tâches composant un projet. Il s’agit d’une représentation d’un graphe connexe, qui permet de représenter graphiquement l’avancement du projet.

Capture des besoins fonctionnels

Création d’un dossier médical

Le dossier médical est propre à chaque patient, il contient tous l’historique de ses soins au centre médicale. Il se compose de plusieurs fiches relatives aux services consultés par le patient lors de ses soins.
Le dossier médical est créé par le médecin traitant qui peut être un oncologue, un gastrologue ou un chirurgien. Ces derniers doivent indiquer les informations de base sur le patient, ainsi que les caractéristiques relatives à la première consultation. Ils doivent aussi indiquer les médecins traitants des soins du patients.
En cas d’une métastase (une localisation secondaire d’une affection, principalement les cancers, où la maladie initiale s’est développée à distance du site initialement atteint ), le médecin traitant doit pouvoir modifier la fiche principale du dossier et par la suite, une réaffectation des médecins.
Le dossier médical n’est publié sur l’application, qu’après qu’il soit complet, c’est-à-dire que toutes ces fiches seront bien indiquées par les médecins, d’une autre manière, le patient est ajouté à l’application dès qu’il commence ses soins.

Le stockage des fiches

Lors de la création du dossier médicale, les médecins traitants reçoivent des notifications pour qu’ils saisissent les fiches associés à leurs spécialités.
Dans le cas où le patient a effectué une partie de ses soins en dehors du centre hospitalier, les médecins traitants peuvent remplir les fiches manquantes, selon des droits décris en dessous :
Les fiches se différent selon la spécialité, et selon les types de données à stockées (textes, images, fichiers).
Chaque médecin a le droit de modifier ses fiches. Dans le cas d’un changement du médicament, les acteurs de la fiche thérapeutique ( pharmacien, oncologue) ont le droit d’ajouter d’autres fiches thérapeutiques au dossier médical.

La recherche et les statistiques

Après la publication des dossiers médicaux, les médecin peuvent les explorer selon plusieurs types de recherche.
• Recherches relatives aux dossiers : Age, OMS, centre, IPP, date d’ajout.
• Recherche relative aux fiches de radiologie : Localisation.
• Recherche relative aux fiches de l’anatomopathologies : mutation.
• Recherches relatives aux fiches thérapeutiques : médicament, ligne de traitement.
Ces recherches peuvent être combinées selon le choix du médecin.
L’application va offrir les statistiques suivantes :
• Nombre de patients pour chaque centre.
• Nombre de patients qui ont eu des interventions de chirurgie, pour chaque centre.
• Fréquence et nombre de localisation, OMS, mutation, et ligne de traitement par médicament, pour chaque centre.

L’envoie des cas pour (RCP)

Les médecins traitants doivent avoir la possibilité d’envoyer les dossiers des patients à discuter en réunion de concertation pluridisciplinaire.
L’envoie du cas se fait par une importation d’un fichier PDF suivis par l’IP du patient.
Le médecin traitant n’a le droit d’envoyer qu’un seul fichier pour chaque patient.

Réunion de concertation pluridisciplinaire

Les médecins experts doivent avoir la possibilité d’organiser la réunion à tous moments, la réunion doit être assurée par les services de l’application en offrant une visio-conférence entre les médecins experts de chaque centre.

l’envoie des décisions

A la fin de chaque réunion les médecins experts envoient les décisions prises pour chaque cas au médecin traitant.
Cette décision est envoyé dans la boite de courrier propre au médecin.

Recueil des besoins opérationnels

Sécurité

Pour chaque centre hospitalier, un administrateur est désigné pour gérer les mots de passes et les profils des médecins. Ensuite, chaque utilisateur doit s’authentifier en utilisant un login et un mot de passe pour accéder aux données de l’application et ses différentes fonctionnalités.

Ergonomie

Pour assurer la cohérence des données saisies par les utilisateur, on a défini un ensemble de contraintes à respecter pour la bonne gestion des erreurs. (exemple : nombre et types de fichiers à télécharger).
Nous avons aussi traité les contraintes associées aux choix prises par les utilisateurs en utilisant des fenêtres d’alerte pour affirmer leurs choix.

Identification des acteurs

On peut répartir les acteurs en quatre catégories : L’oncologue (le gastrologue, le chirurgien) :
Il a pour rôle d’ajouter les nouveaux dossiers des patients qu’il souhaite les publier sur l’application. Il attribue toutes les informations générales sur le patient, ainsi que tout ce concerne le premier diagnostic de la tumeur.

Outils et interfaces

Ce dernier chapitre va présenter les outils que j’ai utilisé pour réaliser l’application. Ainsi que les interfaces graphiques de l’application.

Les outils et méthodes de développements

Le choix des outils et méthodes de développement était basé sur les technologies utilisés dans les systèmes d’information des centres hospitaliers. Les outils et les méthodes de développement que nous avons utilisé sont :
• MVC.
• Apache Tomcat.
• MySQL.
• Java EE.
• HTML 5.
• CSS 3.
• Bootstrap.
• JavaScript.
• JSF.
• PrimeFaces.
• Hibernate.
• Web RTC.
• Bistri.

MVC

Le patron d’architecture logicielle modèle-vue-contrôleur ,tout comme les patrons modèle-vue-présentation ou présentation, abstraction, contrôle, est un modèle destiné à répondre aux besoins des applications interactives en séparant les problématiques liées aux différents composants au sein de leur architecture respective. Ce paradigme regroupe les fonctions nécessaires en trois catégories : 1. un modèle (modèle de données). 2. une vue (présentation, interface utilisateur). 3. un contrôleur (logique de contrôle, gestion des événements, synchronisation).

Apache Tomcat

Apache Tomcat est un conteneur web libre de servlets et JSP Java EE. Issu du projet Jakarta, c’est un des nombreux projets de l’Apache Software Foundation.
Il implémente les spécifications des servlets et des JSP du Java Community Process5, est paramétrable par des fichiers XML et des propriétés, et inclut des outils pour la configuration et la gestion. Il comporte également un serveur HTTP.

MySQL

MySQL est un serveur de bases de données relationnelles SQL développé dans un souci de performances élevées en lecture, ce qui signifie qu’il est davantage orienté vers le service de données déjà en place que vers celui de mises à jour fréquentes et fortement sécurisées. Il est multithread et multi-utilisateur.
C’est un logiciel libre, open source, développé sous double licence selon qu’il est distribué avec un produit libre ou avec un produit propriétaire.

Java EE

Java Platform, Enterprise Edition, Java EE est une spécification pour la plate-forme Java d’Oracle, destinée aux applications d’entreprise2.
La plate-forme étend Java Platform, Standard Edition (Java SE) en fournissant une API de mapping objet-relationnel, des architectures distribuées et multitiers, et des services web3. La plate-forme se fonde principalement sur des composants modulaires exécutés sur un serveur d’applications.

Table des matières

Liste des tableaux 
Liste des figures
Listes des abréviations
INTRODUCTION
CHAPITRE I : Cadre général du projet
1.Présentation du centre hospitalier HASSAN II
1.1 Structure du centre hospitalier HASSAN II
1.2 Matériels du centre hospitalier HASSAN II
1.3 Service d’informatique
1.4 Service d’oncologie
2. Etude de l’existant
2.1 Description de l’existant
2.2 critique de l’existant
3. Description du projet
CHAPITRE II : ANALYSE ET CONCEPTION 
1.Présentation du périmètre du projet
2. Le processus unifié (UP)
2.1 Principes
2.2 Etude comparative des processus de développement
2.3 choix du processus unifié utilisé
3. Diagramme de Gantt
4. Capture des besoins fonctionnels
4.1 Création d’un dossier médical
4.2 Le stockage des fiches
4.3 La recherche et les statistiques
4.4 L’envoie des cas pour (RCP)
4.5 Réunion de concertation pluridisciplinaire
4.6 l’envoie des décisions
5. Recueil des besoins opérationnels
5.1. Sécurité
5.2. Ergonomie
6. Identification des acteurs
7.Conception
7.1 UML
7.2. Diagramme de contexte
7.3 Diagramme de cas d’utilisation
7.4. Diagramme de séquence
7.5. Diagramme de classes
CHAPITRE III : Outils et interfaces
1.Les outils et méthodes de développements
1.1 MVC
1.2 Apache Tomcat
1.3 MySQL
1.4 Java EE
1.5 HTML
1.6 CSS
1.7 Bootstrap
1.8 JavaScript
1.9 JSF
1.10 PrimeFcaes
1.11 Hibernate
1.12 WebRTC
1.13 Bistri
2.Interfaces de l’application
CONCLUSION
Webographie

Télécharger le rapport complet