|
Modélisation et implémentation d'un système d'aide à la décision pour le diagnostic de la fievre thyphoàŻde( Télécharger le fichier original )par Josué MISSWAY ISC-Kinshasa - Licence 2015 |
CHAPITRE III : SPECIFICATIONS DES BESOINS ET ETUDES DE FAISABILITECe chapitre va s'atteler autour des besoins fonctionnels et non fonctionnels du projet et enfin les faisabilités nécessaires pour la matérialisation du projet. Il sied de signaler que c'est la phase cruciale du développement 2TUP dans la mesure où elle aidera à identifier les acteurs et exprimer les besoins sous formes de cas d'utilisation. 3.1. Narration Avec les enjeux de la mondialisation qu'assiste l'humanité tout entière, les scientifiques mettent au point plusieurs outils pour faciliter l'homme dans l'exercice de ses fonctions. Le diagnostic de maladies n'est pas du reste, motif pour lequel nous pensons mettre à la disposition du personnel soignant un système expert pouvant l'assister dans le diagnostic de maladies notamment la fièvre typhoïde. En ce qui concerne le système qui sera implémenté, à l'arrivée du patient, il est directement reçu par un médecin pour consultation afin de lui soumettre toutes ses plaintes et signes vitaux qu'il présente. Le médecin pour sa part va interroger le système bien entendu dans l'interface de diagnostic. Après quoi, il sera déclenché un message pour signaler la présence de la fièvre typhoïde, en cas d'éventualité, le patient sera soumis à un examen clinique pour ainsi confirmer la présence ou non de la typhoïde. 3.2. Etudes de faisabilité 3.2.1. Faisabilité fonctionnelle Cette partie très importante listera toutes les fonctionnalités de notre application. Elle s'attardera sur les exigences fonctionnelles de tous les différents acteurs dans le cas d'utilisations que nous évoquerons plus tard. 3.2.2. Faisabilité opérationnelle [28] ergonomiques, techniques et esthétiques auxquelles est soumis le système pour sa réalisation et son bon fonctionnement9. Dans le cadre de notre système expert, nous avons pu relever des besoins ci-après : La fiabilité : les données de l'application doivent être fiables ; Robustesse : l'application réagira mieux même si l'on s'écarte aux conditions normales d'utilisation ; Convivialité de l'interface graphique : l'interface sera à même de mettre chaque utilisateur à l'aise par la beauté de son interface graphique ; La disponibilité : l'application s'utilisera par tout utilisateur de la boite. L'intégrité : l'application sera sécurisé contre toute modification ; L'intégrité : elle tiendra compte de l'évolution. 3.3. Choix de la méthode d'ordonnancement Le modèle d'ordonnancement présente plusieurs avantages : La facilitation de l'établissement du planning prévisionnel de réalisation du projet ; La spécification de l'ordre d'exécution des différentes tâches ; La minimisation de la durée d'exécution des travaux ; La facilitation de la construction du diagramme de GANNT pour un bon suivi du projet. Il existe par ailleurs plusieurs méthodes d'ordonnancement pour élaborer le planning prévisionnel des projets notamment la méthode PERT, de potentiel mettra (MPM). Mais dans le cadre de ce projet, nous optons pour la méthode PERT. 9HEDIDAR , A., Conception et réalisation d'une application mobile m-banking, mémoire, Université Virtuelle de Tunis, 2011-2012. [29] 3.3.1. Présentation de la méthode PERT Le bon ordonnancement des taches élémentaires concourant à la réalisation d'un ensemble complexe a été, de tout temps, un souci majeur pour les responsables d'entreprise. Un nouvel outil est intervenu à l'occasion de la réalisation par les spécialistes en recherche opérationnelle de la Marine US et le célèbre cabinet de conseil BOOZALLEN&HAMILTON. Il s'agissait de mettre au point une méthode de planification susceptible de s'assurer de l'achèvement d'un modèle, nécessitant de très nombreux sous-traitants, à une date précise10. Le nom P.E.R.T (Program Evaluation Review Technic) a été attribué à ce nouvel outil de travail. P.E.R.T peut-être traduite par « méthode critique d'évaluation et de contrôle de projet »11. S'agissant du principe de cette méthode, les taches sont représentées par les arcs. La valeur de chaque arc sera la durée de la tâche. 3.3.2. Identification et dénombrement des tâches Le tableau suivant comprend toutes les tâches identifiées pour la réalisation de ce projet ainsi que les contraintes de réalisation de chaque tâche. 10MVIBUDULU, J.A., Note de cours de théorie des graphes, L2 Info, ISC, 2014-2015. 11 Idem. [30] Tableau 1 : Dénombrement des taches
3.3.3. Planning d'exécution des taches et estimations de durées. Tableau 2 : Planning
[31] 3.3.4. Etablissement des liens d'antériorité C'est ce qu'évoque le tableau précédent. 3.3.5. Détermination du niveau des graphes Nx est le nombre d'étape maximal Nx-1 = [10J = R9 Nx-2 = [9J = R8 Nx-3 = [8J = R7 Nx-4 = [7J = R6 Nx-5 = [6J = R5 Nx-6 = [5J = R4 Nx-7 = [4J = R3 Nx-8 = [3J = R2 Nx-9 = [2J = R1 Nx-10 = [1J = R0 N0 N1 N2 N3 N4 N5 N6 N7 N8 N9
93 93 G 109 109 F 7 16 8 7 0 1 0 A 7 19 2 3 7 7 B 26 26 C 23 49 4 49 D 24 73 5 73 E 13 86 6 86 0 31 H 140 140 0 9 13 7' 153 153 i 86 93 [32] 3.3.6 Elaboration du graphe [33] 3.3.7. Détermination des dates au plus tôt et au plus tard Date au plus tôt (Dto) : La date au plus tôt (dto) est la date la plus rapprochée à laquelle il est possible de réaliser une étape. Elle se calcule par la formule suivante : dto(x)=Max{dto(y)+d(i)}. dto(x) est considéré comme 2e étape, dto(y) est considéré comme 1èreétape et i comme une tâche. Calcul Dto(1) =0 Dto(2)= Dto(1) +d(a)=0+7=7 Dto(3)= Dto(2) +d(b)=7+19=26 Dto(4)= Dto(3) +d(c)=26+23=49 Dto(5)= Dto(4) +d(d)=49+24=73 Dto(6)= Dto(5) +d(e)= 73+13=86 Dto(7)= MaxDto(5) +d(e)=Max 86 +7 = 93 (qui est la valeur maximum) Dto(6) +d(f') 86+0 Dto(8)= Dto(7) +d(g)=93+16=109 Dto(9)= Dto(8) +d(h)=109+31=140 Dto(10)= Dto(9) +d(i)=140+13=153 Date au plus tard (Dta) : C'est la date à laquelle il faut impérativement démarrer la tâche x si on veut terminer absolument le projet dans sa durée minimale. Sa formule est : dta(y)=Min dta(x)-d(i). Calcul: Dta(10)=153 Dta(9) = Dta(10)-d(i)=153-13=140 [34] Dta(8) = Dta(9)-d(h)=140-31=109 Dta(7) = Dta(8)-d(g)=109-16=93 Dta(6) = Dta(7)-d(f)=93-7=86 Dta(6) = Dta(7)-d(f')=93-0=93 Dta(5) = Max Dta(6)-d(f)=Max 86-13=73 Dta(4) = Dta(5)-d(d)=73-24=49 Dta(3) = Dta(4)-d(c)=49-23=26 Dta(2) = Dta(3)-d(b)=24-19=7 Dta(1) = Dta(2)-d(a)=7-7=0 3.3.8. Détermination des marges Marge libre : elle est le délai de la mise en route de la tâche (i) sans compromettre la dto de l'étape (y). elle se calcule par la formule : ML(i)= Dto(y)-d(i), Sur base de cette formule que nous allons chercher les marges libre de nos tâches. Calcul : ML(a)=dto(2)-dto(1)-d(a)=7-0-7=0 tâche critique ML(b)=dto(3)-dto(2)-d(b)=26-7-19=0 tâche critique ML(c)=dto(4)-dto(3)-d(c)=49-26-23=0 tâche critique ML(d)=dto(5)-dto(4)-d(d)=73-49-24=0 tâche critique ML(e)=dto(6)-dto(5)-d(e)=86-73-13=0 tâche critique ML(f)=dto(7)-dto(6)-d(f)=93-86-7=0 tâche critique ML (f')=dto(7)-dto(6)-d(f')=93-86-0=7 tâche non critique ML(g)=dto(8)-dto(7)-d(g)= 109-93-16=0 tâche critique ML(h)=dto(9)-dto(8)-d(h)=140-109-31=0 tâche critique Le chemin critique est celui qui relie toute les tâches dont la marge totale (mt) est nul c'est-à-dire a, b, c, d,e,f, g, h, i. [35] ML(i)=dto(10)-dto(9)-d(i)=153-140-13=0 tâche critique Pour que nous puisons déterminer les chemins critiques, lesquelles sont les chemins que nous allons suivre, il nous faut utiliser cette formule (dta-dto). Marge Totale: on appelle marge totale, notée MT(i) le délai disposé pour la mise en route de la tâche (i) sans modifier la dta de l'étape (y) (x) étant le sommet initial de la tâche (i) et y son sommet terminal. Sa Formule est : MT(i)= dta(y)-dto(x)-d(i). dta(y) est le sommet terminal, dto(x) est le sommet initial. Calcul: MT(a)=dta(2)-dto(1)-d(a)=7-0-7=0 MT(b)=dta(3)-dto(2)-d(b)=26-7-19=0 MT(c)=dta(4)-dto(2)-d(c)=49-26-23=0 MT(d)=dta(5)-dto(3)-d(d)=73-49-24=0 MT(e)=dta(7)-dto(4)-d(e)=86-73-13=0 MT(f)=dta(6)-dto(5)-d(f)=93-86-7=0 MT(f')=dta(7)-dto(6)-d(f')=93-93-0=0 MT(g)=dta(8)-dto(7)-d(g)=109-93-16=0 MT (h)=dta(9)-dto(8)-d(h)=140-109-31=0 MT(i)=dta(10)-dto(9)-d(i)=153-140-13=0 NB: - Sidto et dta c'est à dire si dto=dta alors l'étape est critique - Lorsque la ML(i) est égale MT(i) alors la tâche est critique. 3.3.9 Détermination du chemin critique
93 93 G 109 109 F 7 16 8 7 0 0 A 7 7 B 26 26 C 49 49 D 73 73 E 86 86 31 H 1 7 19 2 3 23 4 24 5 13 6 140 140 9 13 153 153 i [36] [37] 3.4. Diagramme de GANTT Ce diagramme nous permet de déterminer les différentes taches à réaliser et leurs durées, à définir les relations d'antériorité entre ces taches, de les représenter par un trait parallèle en pointillé à la tache planifiée par la progression réelle du travail. Tableau 3 : Diagramme de Gantt
3.4.1. Faisabilité financière Tableau 4 : Estimation de durée et cout.
a) La durée d'exécution du projet est de 153 jours qui est dta(10) et dto(10) ; b) Le coût total du projet : 8820$ [38] 3.4.2. Calendrier d'exécution du projet Comme en témoigne bien le tableau ci-dessous qui présente le planning de réalisation de notre projet, la durée de réalisation de notre projet est de 153 jours à dater du 12 Janvier au 13 Juin 2015. Tableau 5 : Calendrier d'exécution du projet
3.5. Modélisation fonctionnelle 3.5.1. Capture de besoins fonctionnels Comme le montre la figure ci-dessous, la capture des besoins fonctionnels est la première étape de la branche gauche du cycle en Y. Elle formalise et détaille ce qui a été ébauché au cours de l'étude préliminaire. Elle est complétée au niveau de la branche droite du Y par la capture des besoins techniques et prépare l'étape suivante de la branche gauche : l'analyse.12 12PASCAL R., UML 2 modéliser une application Web, 4ème Ed. Eyrolles, Paris 2006. [39]
a. Identification des acteurs Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié. Un acteur peut consulter et/ou modifier directement l'état du système, en émettant et/ou en recevant des messages susceptibles d'être porteurs de données13. Selon le professeur MVIBUDULU, les acteurs sont des classificateurs qui représentent des rôles au travers d'une certaine utilisation (cas) et non pas des personnes physiques.14
Acteur Il existe en UML deux types d'acteurs qui sont : Acteur principal : celui pour qui le cas d'utilisation produit la plus-value métier. En conséquence, l'acteur principal est la plupart du temps (mais pas forcément, comme dans le cas précité des traitements batch) le déclencheur du cas d'utilisation. 13PASCAL, R., UML 2 par la pratique étude de cas et exercices corrigés, 5ème Ed. Eyrolles, Paris, 2008. 14MVIBUDULU, J. A., Cours de conception des systèmes d'information, L2 Info, ISC-KIN, 2014-2015. [40] Acteurs secondaires : Sont des autres participants du cas d'utilisation. Les acteurs secondaires sont typiquement sollicités à leur tour par le système pour obtenir des informations complémentaires. Les acteurs ci-dessous ont été identifiés pour notre système : Utilisateur il peut être médecin ou tout personnel du corps soignant. Cogniticien Administrateur : c'est généralement un informaticien. Il aura comme tache la gestion de tous les utilisateurs. b. Identification de cas d'utilisation Un cas d'utilisation en anglais « use case »représente un ensemble de séquences d'interactions entre le système et ses acteurs. Il est tout de même, l'expression d'un service réalisé de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. On peut donc le considérer comme une abstraction de plusieurs chemins d'exécution d'une utilisation du système. Il sied de rappeler que le diagramme de cas d'utilisation est représenté par une ellipse à l'intérieur duquel un verbe à l'infinitif.
Cas d'utilisation Nous présentons dans le tableau ci-dessous les différents acteurs et les cas d'utilisation de notre système. [41] Tableau 6 : Acteurs et cas d'utilisation recensés.
Les relations entre acteurs et cas d'utilisation Il est parfois intéressant d'utiliser des liens entre cas (sans passer par un acteur), UML en fournit de deux types : la relation utilise (include) et la relation étend (ex-tend). Inclusion de cas (include) : La relation d'inclusion (include) est employée quand deux cas d'utilisation ont en commun une même fonctionnalité et que l'on souhaite factoriser celle-ci en créant un sous cas, ou cas intermédiaire, afin de marquer les différences d'utilisation. Extension de cas (extend) : Schématiquement, nous dirons qu'il y a extension d'un cas d'utilisation quand un cas est globalement similaire à un autre, tout en effectuant un peu plus de travail (voire un travail plus spécifique). Cette notion à utiliser avec discernement permet d'identifier des cas particuliers (comme des procédures à suivre en cas d'incident) dès le début ou lorsque l'attitude face à un utilisateur spécifique du système doit être spécialisée ou adaptée. Il s'agit grosso modo d'une variation du cas d'utilisation normale. Généralisation : [42] 3.5.1.1. Diagramme de cas d'utilisation Le diagramme de cas d'utilisation sert à identifier les utilisations du nouveau système. Autrement dit, il spécifie la façon dont le système sera utilisé15. Il est en essence un résumé du tableau des événements. Ainsi, pour la compréhension de notre système, nous représentons les différents acteurs et cas d'utilisations dans les diagrammes de cas d'utilisation ci-dessous : a. Cas d'utilisation pour la consultation
Figure 4 : Diagramme de C.U consultation 15JACKSON, SATZINGER ET BURD., Analyse et conception de systèmes d'information, 2ème éd. Goulet, Paris, 2003. [43] b. Cas d'utilisation pour la gestion des utilisateurs
Figure 5 : Diagramme de C.U gérer utilisateur Diagramme de cas d'utilisation globale Tout ceci peut être représenté dans le diagramme global ci-dessous : [44]
Figure 6 : DCU globale. 3.5.1.1.1. Description de cas d'utilisation Il s'agit ici de faire la description textuelle de chaque cas d'utilisation i.e. associer à chaque cas d'utilisation un nom, un objectif, les acteurs qui y participent, les pré-conditions et des scénarii. [45] a. Cas d'utilisation « S'authentifier )) Tableau 7 : Description du C.U « S'authentifier ))
[46] b. Cas d'utilisation « consulter malade » Tableau 8 : Description du C.U « consulter malade »
[47] c. Cas d'utilisation « gérer utilisateurs » Tableau 9 : Description du C.U « gérer utilisateurs »
3.5.1.2. Diagramme de séquence Un diagramme de séquence illustre la série d'interactions qui se déroulent entre les objets durant le flux des événements pour un scénario ou un cas d'utilisation. Il comprend quatre symboles de base :
[48] Ainsi donc, dans les lignes qui suivent nous représentons les différentes interactions de notre système dans les diagrammes de séquence ci-dessous. a. Diagramme de séquence « s'authentifier »
Figure 7 : Diagramme de séquence « s'authentifier » [49] b. Diagramme de séquence « consulter malade »
Figure 8 : Diagramme de séquence « consulter malade » [50] c. Diagramme de séquence « gérer utilisateurs »
Figure 9 : Diagramme de séquence « gérer utilisateurs » [51] 3.5.2. Capture des besoins techniques A ce stade, il sied de s'intéresser à la branche droite du cycle en Y qui est « la capture des besoins techniques »en couvrant avec celle des besoins fonctionnels les contraintes qui ne traitent pas la description applicative. Nous choisissons lors de cette phase l'environnement de travail ainsi que l'architecture globale utilisée pour notre système.
Figure 10 : Situation de la capture des besoins techniques dans 2TUP I. Architectures Client/serveur L'expression des besoins techniques implique également le choix d'architecture. Ce choix est crucial puisqu'il intervient dans l'évolutivité du système, le temps de développement, le coût et les performances. 1.1 Architecture simple tiers La conception de l'application est élaborée de manière à fonctionner sur un ordinateur unique. En fait, tous les services fournis par l'application résident sur la même machine et sont inclus dans l'application. [52] Toutes les fonctionnalités sont donc comprises dans une seule couche logicielle.
Figure 11 : Architecture simple tiers. 1.2 . Architecture client/serveur C'est une architecture 2-tiers appelée aussi architecture client lourd/serveur. Elle est assez simple dans sa mise en oeuvre. Ce type d'architecture est constitué uniquement de deux parties : le «client lourd» demandeur de service d'une part et le «serveur de données» qui fournit le service d'autre part. Nous aurons donc la base de données qui sera délocalisée sur un serveur dédié appelé le serveur de données qui fournira les données à exploiter.
Figure 12 : client-serveur 1.3 . Architecture trois tiers Cette architecture physique est assez semblable à l'architecture client/serveur, mais en plus des « clients» et du serveur de données évoquées plus haut, un serveur d'application intervient comme un troisième tiers. En effet, les machines clientes, également appelées «clients légers» ne contiennent que l'interface de l'application de manière qu'elles déchargées de tout traitement. [53] En effet, le traitement est ainsi assuré par le serveur d'application, qui sert de liaison entre l'interface applicative et les données localisées au niveau du serveur de données.
Figure 13 : Architecture 3 tiers. Pour ce qui est de notre système, nous avons opté pour l'architecture client-serveur un-tiers. 2. Choix du langage de développement Pour le développement de notre système d'aide à la décision, nous optons pour le langage de programmation Visual C#. 2.1. Présentation de Visual C# Le C# est un langage de programmation orienté objet à typage fort, créé par la société Microsoft, et notamment un de ses employés du nom d'Anders Hejlsberg, le créateur du langage Delphi pour la société Borland. Il a été créé afin que la plate-forme Microsoft.NET soit dotée d'un langage lui permettant d'utiliser toutes ses capacités. Il est très proche du Java dont il reprend la syntaxe générale ainsi que les concepts (la syntaxe reste cependant relativement semblable à celle de langages C et C++). Un ajout notable au C# est la possibilité de surcharge des opérateurs inspirés du C++. Néanmoins, l'implémentation de la redéfinition est plus proche de celle du Pascal objet. Sa plate-forme d'exécution est Microsoft.NET. [54] 3. Choix du SGBD Pour le développement opérationnel de notre système nous portons notre choix sur le SGBD Microsoft SQL Serveur dans sa version 2008. Ce choix se justifie sur le fait que Microsoft SQL serveur est un SGBD de type relationnel [55] |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
