|
Mise en place d'une application web pour la gestion des patients du service médecine interne au centre hospitalier régional El Hadji Ahmadou Sakhir Ndiéguène de Thièspar Abdoul Aziz Ba Université Alioune Diop de Bambey - Licence professionnelle 2020 |
CHAPITRE 3 : ÉTUDE CONCEPTUELLEComme n'importe quel type de projet, un projet informatique nécessite une phase d'analyse, suivi d'une étape de conception. Dans la phase de conception, on apporte plus de détails à la solution et on cherche à clarifier des aspects techniques, tels que l'installation des différentes parties logicielles et la modélisation des besoins des utilisateurs. Le cycle de vie d'un logiciel (en anglais software lifecycle), désigne toutes les étapes du développement d'un logiciel, de sa conception à sa disparition. L'objectif d'un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, correspondant à l'adéquation des méthodes mises en oeuvre. L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé qu'elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés. Pour fournir une meilleure réalisation de notre projet, nous avons opté pour le modèle 2TUP(Two Tracks Unified Process) qui est un processus de développement logiciel qui met en oeuvre la méthode du PU(Processus Unifiée). Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des aspects fonctionnels. 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 sont reliés à lui, sur l'axe qui lie un acteur au système on met les messages que les deux s'échangent avec le sens). Le processus s'articule ensuite autour de trois phases essentielles : · une branche technique ; · une branche fonctionnelle ; · une phase de réalisation. 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. Etude préliminaire Capture des besoins fonctionnels Analyse Capture des besoins techniques Conception générique Conception Conception détaillé Réalisation et déploiement Branche fonctionnelle Branche technique
Phase de réalisation Modéliser, c'est décrire de manière visuelle et graphique les besoins et les solutions fonctionnelles et techniques de notre projet logiciel. L'exemple que l'on peut prendre est celui d'une construction de maison. Si on faisait le plan de la maison de manière textuelle cela allait être difficile à comprendre et ne motivera pas le lecteur à cause de sa longueur. Raison pour laquelle les ingénieurs ont pensé à le faire de manière graphique. C'est exactement ce à quoi UML sert dans des projets de réalisation de logiciels ! Un document de texte décrivant de façon précise ce qui doit être réalisé contiendrait plusieurs dizaines de pages. En général, peu de personnes ont envie de lire ce genre de document. De plus, un long texte de plusieurs pages est source d'interprétations et d'incompréhension. UML nous aide à faire cette description de façon graphique et devient alors un excellent moyen pour visualiser le futur logiciel. Un logiciel qui a été réalisé sans analyse et sans conception (étapes où l'on modélise le futur logiciel) risque lui aussi de ne pas répondre aux besoins, de comporter des anomalies et d'être très difficile à maintenir. 2. Présentation du langage UML
Pour faire face à la complexité des systèmes d'information, de nouvelles méthodes et outils ont été créées. La principale avancée des quinze dernières années réside dans la programmation orientée objet. Face à ce nouveau mode de programmation, les méthodes de modélisation classique (telle que MERISE) ont rapidement montré certaines limites et ont dû s'adapter. De très nombreuses méthodes de modélisation ont également vu le jour comme Booch, OMT ... Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception orientée objet, l'OMG (Object Management Group) a eu comme objectif de définir une notation standard utilisables dans les développements informatiques basés sur l'objet. C'est ainsi qu'est apparu UML (qui signifie en français langage de modélisation unifiée), qui est issu de la fusion des méthodes de Booch, OMT et OOSE. C'est un langage de modélisation qui permet de représenter graphiquement les besoins des utilisateurs à l'aide de diagramme. Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle. C'est une perspective du modèle, pas « le modèle ». Chaque type de diagramme UML possède une structure.
Figure 4 : Les différents diagrammes d'UML Il existe deux types de vues du système constituant chacune des diagrammes qui sont répartis selon leurs aspects statiques ou dynamiques. Selon les vues statiques nous avons : Ø Le diagramme des cas d'utilisation Le diagramme de cas d'utilisation permet de structurer les besoins des utilisateurs et les objectifs correspondants d'un système. Il essaiera de répondre à des questions du genre : Qui devra pouvoir faire quoi grâce au logiciel. Les acteurs principaux qui sont liés à un package auront besoin de cette partie du logiciel pour réaliser une plusieurs lots d'actions. Ø Le diagramme d'objet Le diagramme d'objet sert à illustrer les classes complexes en utilisant des exemples d'instances2(*). A l'exception de la multiplicité, qui est explicitement indiquée, le diagramme d'objets utilise les mêmes concepts que le diagramme de classes. Ils sont essentiellement utilisés pour comprendre ou illustrer des parties complexes d'un diagramme de classes. Ø Le diagramme des classes Le diagramme des classes représente les entités manipulées par les utilisateurs.L'intérêt du diagramme des classes est de modéliser les entités du système d'information.Le diagramme met en évidence d'éventuelles relations entre les classes ou les entités. Ø Le diagramme des composants Le diagramme des composants décrit tous les composants utiles à l'exécution du système (application, librairies, instances de base de données, exécutables, etc.). En général, ils ne sont utilisés que pour des systèmes complexes. Ø Le diagramme de déploiement Les diagrammes de déploiement correspond à la description de l'environnement d'exécution du système (matériel, réseau...) et de la façon dont les composants y sont installés.Les diagrammes de déploiement sont donc très utiles pour modéliser l'architecture physique d'un système. Selon les vues dynamiques nous avons : Ø Le diagramme de collaboration Le diagramme de collaboration (appelé également diagramme de communication) permet de mettre en évidence les échanges de messages entre objets. Cela nous aide à voir clair dans les actions qui sont nécessaires pour produire ces échanges de messages. Et donc de compléter, si besoin, les diagrammes de séquence et de classes. Ø Le diagramme de séquence Le diagramme de séquence permet de décrire les différents scénarios d'utilisation du système. C'est une variante du diagramme de collaboration sauf qu'il possède intrinsèquement une dimension temporelle mais ne représente pas explicitement les liens entre les objets. Ø Le diagramme d'états-transitions Le diagramme d'état-transition permet de décrire le cycle de vie des objets d'une classe. Il définit l'enchaînement des états de classe et font donc apparaitre l'ordonnancement des travaux. Ø Le diagramme d'activités Le diagramme d'activité représente le déroulement des actions, sans utiliser les objets. En phase d'analyse, il est utilisé pour consolider les spécifications d'un cas d'utilisation. Conscient de la complémentarité qui existe entre ces différents diagrammes, et sachant qu'UML ne préconise aucune démarche, on a jugé nécessaire de ne prendre que certains de ces diagrammes qui répondent bien à nos besoins afin de concevoir notre système. Cependant, les diagrammes qui vont être utilisés dans la suite de notre exposé sont les suivants : v Le diagramme des cas d'utilisation ; v Le diagramme des classes ; v Et le diagramme des séquences.
Anciennement connu sous le nom de JUDE (environnement de développement Java et UML), Astah est un outil de modélisation UML simple et léger créé par la société japonaise Change Vision. Dans la fenêtre principale, il est possible d'afficher le diagramme, sa structure et les propriétés de l'objet, chacun dans une section distincte. En ce qui concerne les types de diagramme pris en charge, le programme nous permet de créer tous les types de diagrammes UML. Il inclut tous les objets associés auxquels nous pouvons accéder dans une barre d'outils dédiée, quel que soit le type pris en charge. Cela inclut diverses images, formes et blocs de texte que nous pouvons insérer et organiser dans nos projets à l'aide de la collection intégrée d'options d'alignement. De plus, il est possible de changer l'ordre d'affichage de ces éléments, ainsi que de personnaliser la couleur de chaque élément des diagrammes a. Diagramme des cas d'utilisation général Les différents besoins exprimés par les utilisateurs sont matérialisés par le schéma ci-dessous, qui matérialise en même temps leurs interactions avec le système.
Figure 5 : Diagramme de cas d'utilisation globale du système Ce diagramme centre l'expression des exigences du système sur ses utilisateurs, et permet de structurer leurs besoins et les objectifs correspondants au système. La description accompagnant ce diagramme est détaillé dans le tableau suivant :
Tableau 2 : Description du cas d'utilisation global du système b. Diagramme des cas d'utilisation gestion des rendez-vous Le schéma ci-dessous représente lecasd'utilisation« gestion des rendez-vous » avec les utilisateurs correspondant. Les utilisateurs doivent au préalable s'authentifier pour pouvoir accéder aux différentes fonctionnalités liées à cette option.
Figure 6 : Diagramme de cas d'utilisation « gestion des rendez-vous » Dans le tableau suivant nous avons une description plus détaillée de ce diagramme.
Tableau 3 : Description du cas d'utilisation « gestion des rendez-vous » c. Diagramme des cas d'utilisation gestion des consultations Ci-dessous, nous avons le diagramme qui représente le cas d'utilisation « consultation » avec les options qui lui sont liées. Ce diagrammemontre comment le système facilite au médecin la consultation des patients. Le médecin doit au préalable s'authentifier.
Figure 7 : Diagramme de cas d'utilisation « gestion des consultation » La description qui accompagne ce diagramme est détaillée dans le tableau suivant :
Tableau 4 : Description du cas d'utilisation « gestion des consultations » d. Diagramme des cas d'utilisation gestion des hospitalisations Le cas d'utilisation « hospitalisation » est illustré par le schéma ci-dessous avec les différentes fonctionnalités associées. Ce diagramme offre à l'utilisateur toutes les fonctionnalités lui permettant d'avoir un bon suivi et une bonne prise en charge des malades hospitalisés. Ces fonctionnalités ne sont accessibles qu'après une authentification.
Figure 8 : Diagramme des cas d'utilisations « gestion des hospitalisations » La description textuelle de ce diagramme est détaillée dans le tableau ci-dessous :
Tableau 5 : Description du cas d'utilisation « gestion des hospitalisations » e. Diagramme des cas d'utilisation gestion des tableaux de bords Le schéma ci-dessous représente le cas d'utilisation « gestion des tableaux de bords » et permet au médecin d'avoir une vue globale de la répartition des patients selon les données démographique et les données clinique.
Figure 9 : Diagramme de cas d'utilisation « gestion tableaux de bords » La description textuelle qui l'accompagne est détaillée dans le tableau suivant :
Tableau 6 : Description du cas d'utilisation « gestion tableaux de bords » a. Diagramme des séquences du cas d'utilisation « s'authentifier » Le schéma ci-dessous illustre les différents scenarios du cas d'utilisation « s'authentifier » et permet de spécifier les interfaces pour chaque utilisateur.
Figure 10 : Diagramme de séquence du cas d'utilisation « s'authentifier » La description détaillée qui accompagne le schéma ci-dessus est la suivante :
Tableau 7 : Description séquentielle du cas d'utilisation « s'authentifier » b. Diagramme des séquences du cas d'utilisation consultation Le diagramme ci-dessous correspond au cas d'utilisation « Consultation » et décrit comment le médecin peut procéder à la consultation d'un patient par un modèle simple contenant un formulaire.
Figure 11 : Diagramme de séquence du cas d'utilisation « consultation » La séquence du cas d'utilisation « consultation » ne peut être fonctionnelle qu'après une authentification de l'utilisateur. Une description plus détaillée de ce diagramme est résumée dans le tableau suivant :
Tableau 8 : Description séquentielle du cas d'utilisation « consultation »
Figure 12 : Diagramme des classes globales du système Le diagramme ci-dessus exprime la structure statique du système en termes de classes et de relations entre ces classes. Ce diagramme permet de représenter l'ensemble des informations finalisées qui sont gérées par le domaine. Ces informations sont structurées, c'est-à-dire qu'elles sont regroupées dans des classes. Les informations concernant l'état civil du patient sont inscrites dans la classe « patients ». Cette classe étant liée avec les classe « consultations », « hospitalisations » et « rendez-vous » permet aux utilisateurs de gagner du temps en évitant la redondance dans la saisie des données du patient. En résumé, ce chapitre nous a permis d'édifier les aspects fonctionnels correspondant aux besoins exprimés. Cette édification ne saurait être facile et compréhensive sans l'utilisation de diagrammes et de tableaux descriptifs. En effet, comme nous l'avons souligné précédemment, une description purement textuelle décrivant ce qui doit être réalisé contiendrait plusieurs dizaines de pages, ce qui ne motiverait pas les lecteurs. Voulant éviter ceci, nous avons cherché à être brefs et précis. Après avoir pris la peine de concevoir notre système de manière saine, il est maintenant temps de passer à sa réalisation. C'est ce que nous verrons dans le prochain chapitre. * 2Une instance est un exemple concret de contenu d'une classe. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
