|
[1]
REPUBLIQUE DEMOCRATIQUE DU CONGO
MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET INSTITUT
SUPERIEUR DE COMMERCE DE UNIVERSITAIRE
KINSHASA
«I.S.C/KIN»
SECTION: SCIENCES COMMERCIALES, FINANCIERES
ET
INFORMATIQUE DE GESTION
DEPARTEMENT D'INFORMATIQUE
CYCLE DE
LICENCE
B.P.16596
KINSHASA-GOMBE
MODELISATION ET IMPLEMENTATION
D'UN
SYSTÈME D'AIDE A LA DECISION POUR LE
DIAGNOSTIC DE LA FIEVRE
TYPHOÏDE
MISSWAY KINDIA Josué
Travail de fin d'études présenté et
défendu en
vue de l'obtention de titre de licencié
en
informatique de gestion.
Option: Conception des Systèmes
d'Information
Directeur: Professeur MUSANGU LUKA Rapporteur: Assistant
KABAMBA MBIKAY
Année académique : 2014-2015
[2]
IN MEMORIAM
A mon père Anicet MISSWAY KINDIA pour son amour et
surtout son souci qu'il avait de me faire un vrai homme utile à la
société.
Ma reconnaissance à son égard se voudra grande et
profonde.
[3]
EPIGRAPHE
« La preuve de la valeur d'un système informatique
est son existence. »
Alan Jay Perlis
[4]
DEDICACE
A ma mère,
Et à mes frères et soeurs
MISSWAY KINDIA Josué
[5]
REMERCIEMENTS
Ce travail qui sanctionne la fin de notre cycle de licence est
le résultat abattu avec le concert de quiconque. C'est pourquoi la
reconnaissance nous oblige de pouvoir remercier sincèrement tous ceux ou
toutes celles qui ont apporté leur pierre à cet
édifice.
Aussi voudrons-nous avant toute chose, exprimer notre profonde
gratitude au Professeur MUSANGU LUKA, qui nonobstant ses multiples occupations
n'a pas hésité d'assurer la direction de ce travail. Ses riches
conseils, sa disponibilité, ses remarques et critiques constructifs nous
ont été d'une grande utilité. Qu'il veuille bien accepter
nos vifs et sincères remerciements.
Nous tenons ensuite à remercier de tout coeur notre
rapporteur, le doctorant Hervé KABAMBA MBIKAYI, pour les encouragements
e conseils pratiques.
Nos remerciements vont aussi droit à tous les membres
du corps académique.
Nous pensons également à notre oncle Alexis
TURI, notre beau-frère Guylain IKAVU ainsi que sa fille Guyslaine, la
famille TOKO, et à tous nos oncles, tantes, cousins, cousines,
grands-parents, neveux et nièces dont le soutien moral, matériel
et financier nous ont été inestimables. Qu'ils trouvent tous ici
l'expression sincère de notre gratitude.
Nous tenons aussi à exprimer notre reconnaissance aux
messieurs et demoiselles : Paul OLEKO, Délux LUKUSA, Hervé
MUYEMBE, Olivier NIAMADJOMI, Jethro FUABONGO, Grace NSELE, Jonathan MPOYI,
Meilleur NSANGANI, Steve NANGO, Placide GABIE, Grace MALULU, Glodi BIMA, Serge
MFUNYI, Hester WEDJOLO, Ruth NGEYITALA, Sharonne MBOMBO, Sarah FUTI, Parfait
LUBAMBA, Phillip KASUKUMA, Reagan MBUYA, Michel BINDA, Hardy MUPU, Fabrice
KAMULETE, Harvey FAYA, Eben MAMBUVE, Jabin MUZIR, Sylvain PITAMA, Paul NGANGU,
Merveille MUDE, Gustave MUTHI, Félicien TUTU, Reagan IKIE et Albert
BOMBO. Qu'ils trouvent dans ces lignes l'expression de notre grande et profonde
reconnaissance.
Enfin, que tous ceux ou toutes celles qui ont contribué
directement ou indirectement à notre devenir et dont les noms ne sont
pas expressément cités daignent croire ici en l'expression de
notre grande reconnaissance.
[6]
Liste de tableaux
Tableau 1 : Dénombrement des taches 30
Tableau 2 : Planning 30
Tableau 3 : Diagramme de Gantt 37
Tableau 4 : Estimation de durée et cout. 37
Tableau 5 : Calendrier d'exécution du projet 38
Tableau 6 : Acteurs et cas d'utilisation recensés.
41
Tableau 7 : Description du C.U « S'authentifier »
45
Tableau 8 : Description du C.U « consulter malade »
46
Tableau 9 : Description du C.U « gérer
utilisateurs » 47
Tableau 10 : Dictionnaire de données. 58
Tableau 11 : Liste des classes 59
Tableau 12 : Multiplicités 60
Tableau 13 : Représentation des associations simples
61
Tableau 14 : Diagramme de classe. 61
[7]
Liste de figures
Figure 1 : Structure d'un système expert
Figure 2 : Caractéristique de l'approche
itérative
Figure 3 : processus de développement 2TUP
Figure 4 : Branche gauche de Y
Figure 5 : Diagramme de C.U Consultation
Figure 6 : Diagramme de C.U gérer utilisateur
Figure 7 : DCU global
Figure 8 : Diagramme de séquence « s'authentifier
»
Figure 9 : Diagramme de séquence « consulter malade
»
Figure 10 : Diagramme de séquence « gérer
utilisateurs »
Figure 11: Situation de la capture des besoins techniques dans
2TUP
Figure 12: Architecture simple tiers
Figure 13: Architecture client-serveur
Figure 14:architecture 3 tiers
Figure 15:Branche gauche du cycle en Y
Figure 16 : Diagramme d'activités s'authentifier
Figure 17: Modèle bayésien
Figure 18:Diagramme de déploiement
Figure 19 : Fenêtre d'authentification
Figure 20 : Fenêtre d'enregistrement du patient
Figure 21: fenêtre du diagnostic
[8]
CHAPITRE I : INTRODUCTION 1.1. Mise en
contexte
Depuis plusieurs décennies et cela de par le monde, les
entreprises, les institutions aussi bien commerciales que sanitaires, bref les
hommes éprouvent les besoins du progrès social; pour y parvenir,
ils visent à minimiser les coûts et maximiser les revenus. Le
diagnostic rapide de maladies devient un aspect non négligeable à
la rentabilité et à l'émergence du secteur sanitaire et
surtout il est une étape très cruciale dans la thérapie de
maladies, de surcroît la réduction de la pauvreté.
La bonne prise de décision rapide et optimale
grâce à l'outil informatique avec la pluralité d'avantages
qu'il offre est un facteur de développement harmonieux dans l'atteinte
de tous les objectifs assignés par l'institution.
Compte tenu du fait que les NTIC ont une influence très
considérables sur la productivité et le profit, à l'issue
de cette étude, nous tacherons de modéliser et mettre en oeuvre
un système expert qui assistera le corps médical à
diagnostiquer rapidement la maladie du patient afin d'assurer la bonne prise en
charge de ce dernier.
1.2. Problématique
Aujourd'hui la fièvre typhoïde parait un
fléau qui touche beaucoup plus des pays sous-développés.
La République démocratique du Congo n'est pas en reste, en ce
sens que la majeure partie de la population n'a pas accès à l'eau
potable et aux soins de santé.
Face à cette situation précaire, il a
été constaté qu'à l'absence de médecins
considérés comme experts dans certaines formations
médicales, le diagnostic de cette maladie combien mortelle
dévient de plus en plus difficile.
Or, nous sommes sans ignorés que le diagnostic est l'un
des éléments non négligeables dans la décision
médicale car il est généralement le préalable d'une
meilleure prise en charge du patient. Les médecins qui en assurent font
parfois face à des multiples problèmes d'ordre familial,
personnel, que professionnel qui peuvent surement entraver leur prise de
décision ou d'influer négativement sur la décision prise.
Raison pour laquelle, la mise au point d'un système expert de diagnostic
de la fièvre typhoïde pourrait résoudre effectivement ce
problème.
Cette problématique se résume autour des
questions ci-après :
[9]
V' Quelle est la quintessence ou le bien fondé
du système expert de diagnostic de la fièvre typhoïde ?
V' Est-il vrai que cet outil pouvait être un
début de solution dans l'amélioration de la prise en charge de la
fièvre typhoïde ?
V' Quels sont les aspects techniques, économiques
et sociaux à donner au futur système ?
1.3. Hypothèse
De tout ce qui précède, à l'issue de
cette étude, nous pensons mettre à la disposition du
médecin un outil d'aide à la décision grâce à
un modèle probabiliste notamment le réseau bayésien
à partir d'un ordinateur pouvant aider le personnel médical dans
le diagnostic de la fièvre typhoïde en vue d'assurer au mieux la
prise en charge de patients.
1.4. Choix et intérêt du sujet
Le choix de notre sujet sur la modélisation et
l'implémentation d'un système d'aide à la décision
pour le diagnostic de la fièvre typhoïde s'avère très
judicieux d'autant plus que la situation sanitaire en ROC est très
précaire, nous avons voulu à travers ce sujet apporter notre
contribution dans la réduction de ce fléau en y apportant une
solution informatique.
Quant à son intérêt, il est triple :
V' Sur le plan économique, c'est outil
s'avère être un véritable moteur de développement
car il permettra au médecin dans un temps record de diagnostiquer plus
d'un patient ; d'où un gain en temps, or le temps est un grand facteur
d'émergence.
V' Sur le plan scientifique, il est un outil de
recherche pour toute personne intéressée au domaine de conception
des systèmes d'information et plus précisément
l'intelligence artificielle.
V' Enfin sur le plan personnel, c'est une
façon pour nous de pouvoir contribuer à la réduction de la
fièvre typhoïde qui touche beaucoup des congolais
1.5. Délimitation du travail
Ce travail visant contribuer à résoudre un
problème réellement constaté dans un contexte purement
congolais, puis qu'il est ici question du diagnostic de la fièvre
typhoïde il ne s'avère pas indispensable qu'il
[10]
soit délimité dans l'espace, ni dans le temps car
le diagnostic est effectif partout et il est un processus continu.
1.6. Méthode et techniques
utilisées
a. Méthode
La méthode se définit comme étant
l'ensemble de règles et de disciplines qui organisent le mouvement
d'ensemble de la connaissance, c'est-à-dire les relations entre l'objet
de la recherche et le chercheur, entre les informations concrètes
rassemblées à l'aide des techniques et le niveau de la
théorie et des concepts.1
Ainsi pour la conception de l'application qui sera
développée nous avons opté pour la méthode UP
construit sur UML ; un processus itératif et incrémental.
En ce qui concerne la méthode de conduite du projet
nous avons opté pour la méthode PERT.
b. Techniques
La technique est l'ensemble de procédés ou de
moyens pratiques pouvant aider à concrétiser les principes
fixés par la méthode2.Bref, elle permet la collecte
des informations.
Afin de recueillir toutes les informations utiles de notre
recherche nous avons recouru aux techniques ci-après :
y' Technique d'interview : elle nous a permis de
poser des questions aux personnes concernées de notre étude en
vue de récolter les données nécessaires pour celle-ci.
y' Technique d'observation : elle nous a aidé
de voir à l'oeil nu la façon dont se déroule le processus
de diagnostic des maladies.
y' Technique documentaire : elle nous a permis de
consulter tous les ouvrages nécessaires pour notre étude.
1.7. Difficultés rencontrées
A titre de rappel, ce travail aborde le diagnostic qui est
évidemment un domaine sanitaire, tout au long de sa recherche nous avons
heurtés plusieurs difficultés dans la récolte de
données auprès des
1MUKUNA, B., Essai méthodologique sur la
rédaction d'un travail scientifique, éd. CRIGED, Janvier
2006, ISC/Kinshasa, p.28
2BINDUNGWA, M., Comment élaborer
un travail de fin de cycle ? Contenu et étapes, ed.
Médiaspaul, Kinshasa 2008.
[11]
experts du domaine, la première difficulté est
liée à l'inadéquation due au jargon médical, la
seconde c'est dans la mise en application du réseau bayésien dans
ce diagnostic.
1.8. Canevas du travail
Le présent travail est divisé en sept chapitres
de valeurs non négligeables.
Au premier chapitre nous allons présenter
l'introduction générale de notre travail.
Au deuxième chapitre intitulé les approches
théoriques. Nous aborderons les généralités sur
l'intelligence artificielle, le système expert, le langage de
modélisation ainsi que les concepts liés au sujet.
Le chapitre troisième s'articulera sur la
spécification des besoins et études de faisabilité. Dans
cette partie, nous allons décrire les besoins fonctionnels et non
fonctionnels du système en plus l'étude de faisabilité de
notre projet.
Le quatrième chapitre qui constitue un de noeuds
essentiels de notre travail sera synonyme de l'élaboration de notre
système. Ici nous allons faire la modélisation statique et
dynamique du système.
Le chapitre cinquième développera la
construction de notre système. Il nous aidera à construire et
implémenter le modèle de la base de connaissances.
Le sixième chapitre et avant dernier chapitre gravitera
autour de la transition. Ici, il sera question de mettre l'outil à la
disposition des utilisateurs finaux.
Enfin, le septième chapitre marquera la conclusion de ce
travail.
[12]
CHAPITRE II : APPROCHES THEORIQUES
Dans ce chapitre, il est question d'aborder les
généralités sur l'intelligence artificielle, objet de la
première section, le système expert qui est une branche de
l'intelligence artificielle, objet de la deuxième section, le processus
unifié objet de la troisième section, le langage UML comme objet
de la quatrième section et enfin le diagnostic comme objet de la
cinquième section.
2.1. Généralités sur l'intelligence
artificielle 2.1.1. Définition
L'intelligence artificielle étant un concept a par
conséquent plusieurs définitions :
A en croire LAROUSSE, elle se définit comme
étant un ensemble de théories et de techniques mises en oeuvre
pour réaliser des machines dont le fonctionnement s'apparente à
celui d'un cerveau humain.
D'après BUCHANAN3, l'intelligence
artificielle est définie comme le domaine informatique qui effectue les
traitements symboliques et qui emploie des méthodes non
algorithmiques.
RICH pour sa part soutient que l'intelligence artificielle est
le domaine qui étudie comment faire exécuter par ordinateur des
tâches pour lesquelles l'homme est encore toujours
meilleur4.
Nous pouvons encore définir l'intelligence artificielle
selon quatre approches suivantes5 :
Systèmes qui pensent comme les humains
L'intelligence artificielle est l'automatisation des
activités que nous lions au processus de pensée comme la prise de
décision, la résolution des problèmes,
apprentissage,...(Bellman, 1978)
Systèmes qui pensent rationnellement
C'est l'étude des facultés mentales à
l'aide de l'usage des modèles computationnels. (Charniak et McDermott,
1985).
3 R. Lindsay, B. Buchanan, E.Feignbaum.,
Application of artificial intelligence to organic
chemistri : the dendra project, Mc Graw-hill 1980.
4RICH, E., Intelligence artificielle, Ed.
Masson, paris 1987.
5 KUTANGILA, D., Intelligence artificielle et
systèmes experts approfondis, L1 Info, ISC-KIN, 2013-2014.
[13]
Systèmes qui agissent comme les humains
Elle est l'art de développer des machines avec
capacités pour réaliser des fonctions qui, quand elles sont
réalisées par des personnes, exigent de l'intelligence.
(Kurzweil,1990).
Systèmes qui agissent rationnellement
Selon Nilson, l'intelligence artificielle est en rapport avec
la conduite intelligente des automates.
2.1.2. Branches de l'intelligence
artificielle
L'intelligence artificielle a plusieurs branches parmi
lesquelles :
Les systèmes experts : un système expert est un
système de traitement qui émule l'habilité de prendre de
décisions comme un spécialiste humain
La robotique : Larousse définit la robotique comme
étant une science et technique de conception et construction des robots.
Il est à signaler que présentement dans les usines il ya des
robots industriels qui ont fait leur apparition.
La parole : malgré l'évolution technologique,
l'humanité est encore loin de produire un logiciel capable de
reconnaitre les paroles d'un quelconque locuteur et cela essentiellement
d'autant plus que la compréhension d'un mot, d'une phrase requiert
beaucoup d'information extra-langagière.
Le langage naturel
Les systèmes artificiels neuronaux : durant les
années 80 surgissent un nouveau développement dans la
programmation des paradigmes les systèmes neuronaux
artificiels basé sur la manière dont le cerveau
traite
l'information. Ce paradigme est parfois appelé connexionisme,
d'autant plus qu'il modélise les solutions aux problèmes en
entrainant des neurones simulés, connectés à un
réseau de travail.
La compréhension
La vision artificielle
[14]
2.1.3. Avantages de l'IA
L'intelligence artificielle offre plusieurs avantages notamment
:
La limitation d'erreurs
L'homme est dispensé de certains travaux pénibles
La pérennité des connaissances
Les machines sont exemptes à la fatigue
2.2. Le système expert
2.2.1. Introduction
Le système expert est l'un des domaines de
l'intelligence artificielle relatif à la conception des systèmes
d'aide à la décision à base de connaissances.
Il est de surcroit un programme informatique intelligent,
capable d'agir comme expert dans un domaine. Aujourd'hui, de par le monde, les
industries utilisent beaucoup des systèmes experts pour assurer la
maintenance, la réparation des machines complexes.
2.2.2. Définition
Il y a plusieurs façons de définir le
système expert. Le professeur Edward Feigenbaum de l'Université
de Stamford, pionnier en technologie des systèmes experts, le
définit comme étant un programme de traitement intelligent qui
utilise des connaissances et les procédures d'inférence pour
résoudre des problèmes tellement difficiles qu'ils exigent une
expérience significative pour leur solution.
Un système expert est un système d'aide à
la décision basé sur un moteur d'inférence et une base de
connaissances. Il est la transcription logicielle de la réflexion d'un
expert dans un domaine donné. Néanmoins, il reste un outil d'aide
à la décision et loin de prétendre remplacer
l'intelligence humaine.
Il est aussi important de signaler que les termes
systèmes experts ou systèmes à base de connaissances ou
système expert basé sur la connaissance s'utilisent comme
synonymes.
[15]
2.2.3. Les acteurs
La mise en oeuvre d'un système expert est un processus
d'ingénierie de connaissances qui impliquent plusieurs personnes
notamment :
? Expert
Un expert ou un spécialiste est une personne qui a une
parfaite connaissance dans un domaine, due à une longue durée de
travail. Il est considéré comme le socle même du
développement d'un système expert. De ce fait, il doit être
disponible lors de la phase d'extraction de ses connaissances car c'est lui qui
a le monopole de savoir et de savoir-faire de son domaine d'expertise. C'est
l'expert qui fournit les connaissances nécessaires liées au
problème.
? Le cogniticien
Autrement appelé Ingénieur des connaissances,
c'est une personne ayant des bonnes bases en informatiques et
généralement ingénieur en intelligence artificielle. Il
est chargé d'extraire les connaissances auprès de l'expert. A ce
titre, il établit un dialogue avec l'expert pour obtenir ses
connaissances, il le codifie de façon explicite dans la base de
connaissances sous formes des règles.
? Les managers : sont des personnes pour qui on développe
le système.
2.2.4. Architecture d'un système
expert
La structure ou l'architecture d'un système expert se
présente dans la figure ci-dessous :
[16]
Utilisateur
Base de faits
Base de connaissances
Moteur d'inférence
Base de règles
Figure 1 : Structure d'un système expert 2.2.5.
Composants d'un système expert
Selon son architecture simple présentée
ci-dessus, nous distinguons trois composants de base d'un système expert
notamment :
? La base de connaissances ? La base de faits
? Le moteur d'inférence
2.2.5.1. La base de connaissances
Elle contient la connaissance qui permet au mécanisme
d'inférence de tirer de conclusions ; celles-ci sont de réponses
du système à la consultation spéciale de l'utilisateur.
2.2.5.2. La base de faits
Elle contient tout ce que le système expert sait sur le
cas étudié. La base de faits est ainsi variable au cours de
l'exécution et est vidée lorsque l'exécution se
termine.
Les faits sont des connaissances factuelles et les
règles constituent des connaissances opératoires.
[17]
2.2.5.3. Le moteur d'inférence
Autrement dit mécanisme d'inférence, il
contrôle l'exécution des règles. Il décide sur
quelles règles exécuter et quand. Il permet d'inférer des
connaissances nouvelles à partir de la base de connaissances du
système.
Il est le coeur du système, et qui contient un
algorithme de résolution dont la fonction consiste à effectuer
des déductions en partant des faits initiaux et en s'appuyant sur les
règles contenues dans la BR, dans le but final de produire
(c'est-à-dire de déduire) de nouveaux faits. Il peut fonctionner
en chaînage avant, chaînage arrière ou chaînage
mixte6.
? Chaînage avant : le principe
du chaînage avant est simple, il requiert l'accès aux
prémices afin de déclencher les règles d'inférences
adéquates définies par les mérules. L'application de
règles donne des résultats, ceux-ci sont évalués
afin de savoir si l'on accédé à une solution finale
potentielle. Si c'est le cas, on arrêté et cette solution est
proposée. Si c'est le cas, la solution est proposée à
l'utilisateur. S'il la valide, la solution est enregistrée dans la base
de faits comme solution, sinon comme simple résultat et on continue dans
le cas suivant.
? Chaînage arrière : le
principe du chaînage arrière est plus compliqué, il s'agit
dans ce cas de partir d'un effet ou d'une solution et de tenter de remonter la
chaîne afin de déterminer les causes d'un effet (fait). La
procédure est à partir d'un effet, de déterminer,
grâce aux métarules, les règles d'inférence qui
aurait pu être à l'origine de ce fait et de déterminer les
paramètres les plus probables. A partir de là, on analyse les
paramètres : Si le paramètre est un fait enregistré dans
la base de fait, c'est qu'il est le résultat d'une règle. La
procédure précédemment décrite est donc
relancée. Si le paramètre n'est pas un fait de la base de fait,
on en reste là.
? Chaînage mixte :il utilise
une combinaison de ces deux approches chaînage avant et chaînage
arrière.
6 MUJINGA, S., Conception et réalisation d'un
système expert de diagnostic du cancer de la peau, mémoire,
Unikin, 2013.
[18]
2.2.6. Les apports des systèmes
experts
Les motivations pour une entreprise de réaliser un
système expert sont regroupées en trois catégories :
? La gestion de l'expertise
? L'augmentation de la capacité de l'expert ? La diffusion
des connaissances
2. 2. 6.1. La gestion de l'expertise
Le rôle d'une entreprise est de prendre en charge
l'intelligence qu'elle utilise qui naturellement est distribuée, de la
formaliser et de la sauvegarder. En effet, les experts sont des hommes rares,
très chers et difficiles à remplacer.
D'où l'impérieuse nécessité pour
une entreprise de s'approprier de la technique des systèmes experts et
de conserver ainsi l'expertise sous une forme aussi claire et accessible
à tous. Le système expert dévient alors un moyen de
formation.
2.2.6. 2. L'augmentation de la capacité de l'expert
Un système peut donc assister un spécialiste du
fait que sa connaissance provient de plusieurs experts. D'autres parts,
l'expert étant un homme, il peut donc être sujet à la
fatigue, à l'oubli, etc. alors que le système expert est
insensible à de telles considérations. On peut ainsi au moyen
d'un système expert, trouver plus rapidement une solution à un
problème en donnant accès aux connaissances des autres experts du
domaine.
2.2.6.3. La diffusion de l'information
Les experts étant des hommes, il est souvent
nécessaires pour une entreprise que leur expertise soit diffusée
à des nombreux services afin de décentraliser les prises de
décisions et d'ainsi accroitre la rapidité et
l'homogénéité. Ainsi, la diffusion permet aux utilisateurs
de disposer à tout moment de l'expertise.
[19]
2.2.7. Avantages des systèmes experts
Les systèmes experts présentent plusieurs
avantages que nous
citons :
> Danger réduit : les systèmes
peuvent être utilisés dans des environnements qui pourraient
être dangereux pour un humain.
> Permanence : l'expérience est
permanente.
> Grande disponibilité :
l'expérience est disponible pour tout matériel de traitement
adéquat.
> Explication : le système expert peut
expliquer clairement et en détail le raisonnement qui conduit à
une conclusion, cela augmente la confiance que la décision prise
était correcte.
> Enseignement intelligent : un système
expert peut agir comme un enseignant intelligent en laissant que
l'étudiant exécute.
> Réponse rapide : u système expert
peut répondre plus rapidement qu'un spécialiste humain.
2.2.8. Inconvénients du système
expert
Le système expert présente deux
inconvénients majeurs :
> Le chômage du moment où il peut
à lui seul réaliser ce qui pourrait se faire un groupe de
personnes.
> Le système s'appuie à des
connaissances même si il ne plus utilisable.
2.3. Le processus unifie (UP)
Le processus unifié est un processus de
développement moderne, itératif, efficace sur des projets
informatiques de toutes tailles. Très complet, il couvre l'ensemble des
activités, depuis la conception du projet jusqu'à la livraison de
la solution.
Intégrant une organisation de projet type, une
méthodologie utilisant UML et un ensemble de bonnes pratiques
cohérentes entre elles, il permet de circonvenir aux problèmes
récurrents que rencontrent nombre de réalisations : dérive
des coûts et des délais, qualité insuffisante,
réponse incomplète aux attentes des utilisateurs.
[20]
Un point d'excellence de cette démarche est son
adaptabilité : UP peut se décliner en fonction de l'ampleur d'un
projet, de l'expérience de l'équipe qui l'assume, de la nature de
la solution à construire.
2.3.1. Les Principes d'UP
Le processus de développement UP, associé
à UML, met en oeuvre les principes suivants :
· processus guidé par les cas d'utilisation,
· processus itératif et incrémental,
· processus centré sur l'architecture,
· processus orienté par la réduction des
risques.
Ces principes sont à la base du processus unifié
décrit par les auteurs d'UML.
a) Processus guidé par les cas
d'utilisation
L'orientation forte donnée ici par UP est de montrer
que le système à construire se définit d'abord avec les
utilisateurs. Les cas d'utilisation permettent d'exprimer les
interactions du système avec les utilisateurs, donc de capturer les
besoins.
b) Processus itératif et
incrémental
Ce type de démarche étant relativement connu
dans l'approche objet, il paraît naturel qu'UP préconise
l'utilisation du principe de développement par itérations
successives. Concrètement, la réalisation de maquette et
prototype constitue la réponse pratique à ce principe. Le
développement progressif, par incrément, est
aussi recommandé en s'appuyant sur la décomposition du
système en cas d'utilisation.
Les avantages du développement itératif se
caractérisent comme
suit :
· Les risques sont évalués et
traités au fur et à mesure des itérations ;
· Les premières itérations permettent
d'avoir un feed-back des utilisateurs ;
· Les tests et l'intégration se font de
manière continue,
· Les avancées sont évaluées au fur
et à mesure de
l'implémentation.
[21]
Figure 2 : Caractéristiques de l'approche
itérative
c) Processus centré sur
l'architecture
Les auteurs d'UP mettent en avant la préoccupation de
l'architecture du système dès le début
des travaux d'analyse et de conception. Il est important de définir le
plus tôt possible, même à grandes mailles, l'architecture
type qui sera retenue pour le développement, l'implémentation et
ensuite le déploiement du système. Le vecteur des cas
d'utilisation peut aussi être utilisé pour la description de
l'architecture.
d) Processus orienté par la réduction des
risques
L'analyse des risques doit être
présente à tous les stades de développement d'un
système. Il est important de bien évaluer les risques des
développements afin d'aider à la bonne prise de décision.
Du fait de l'application du processus itératif, UP contribue à la
diminution des risques au fur et à mesure du déroulement des
itérations successives.
2.3.2. Les phases du processus unifie et les
activités
Les phases d'un processus de développement sont des
états de celui-ci à un instant t. Le cycle de
développement du Processus Unifié organise les tâches et
les itérations en quatre phases7 :
? Inception ou (commencement) : Cette phase
correspond à l'initialisation du projet où l'on
mène une étude d'opportunité et de faisabilité du
système à construire. Une évaluation des risques est aussi
réalisée dès cette phase.
7ROQUES, P. et VALLEE, F., UML 2 en action de
l'analyse des besoins à la conception, Ed. EYROLLES, Paris,
2005,
[22]
En outre, une identification des principaux cas d'utilisation
accompagnée d'une description générale est
modélisée dans un diagramme de cas d'utilisation afin de
définir le périmètre du projet.
? Élaboration : Cette phase reprend les
résultats de la phase
d'inception et élargit l'appréciation de la
faisabilité sur la quasi-totalité des cas
d'utilisation. Ces cas d'utilisation se retrouvent dans le diagramme des cas
d'utilisation qui est ainsi complété.
Cette phase a aussi pour but d'analyser le domaine technique
du système à développer afin d'aboutir à une
architecture stable. Ainsi, toutes les exigences non recensées dans les
cas d'utilisation, comme par exemple les exigences de performances du
système, seront prises en compte dans la conception et
l'élaboration de l'architecture.
? Construction : Cette phase correspond
à la production d'une première version du
produit. Elle est donc fortement centrée sur les activités de
conception, d'implémentation et de test.
En effet, les composants et fonctionnalités non
implémentés dans la phase précédente le sont
ici.
? Transition :Après les
opérations de test menées dans la phase précédente,
il s'agit dans cette phase de livrer le produit pour une
exploitation réelle. C'est ainsi que toutes les actions liées au
déploiement sont traitées dans cette phase. De plus, des «
bêta tests » sont effectués pour valider le nouveau
système auprès des utilisateurs.
2.3.3. Activités du processus
Les activités représentent les actions à
effectuer au cours d'une phase : une phase passe par l'ensemble des
activités. Le temps passé par activité est fonction des
phases.
Nous nous limiterons donc à ne donner qu'une
brève explication de chaque activité.
Expression des besoins
UP propose d'appréhender l'expression des
besoins en se fondant sur une bonne compréhension du domaine
concerné pour le système à développer et une
modélisation des procédures du système existant.
Ainsi, UP distingue deux types de besoins :
? les besoins fonctionnels qui conduisent à
l'élaboration des cas
d'utilisation,
? les besoins non fonctionnels (techniques) qui aboutissent
à la
rédaction d'une matrice des exigences.
[23]
Analyse
L'analyse permet une formalisation du
système à développer en réponse à
l'expression des besoins formulée par les utilisateurs. L'analyse se
concrétise par l'élaboration de tous les diagrammes donnant une
représentation du système tant statique (diagramme de classe
principalement), que dynamique (diagramme des cas d'utilisation, de
séquence, d'activité, d'état-transition...).
Conception
La conception prend en compte les choix
d'architecture technique retenus pour le développement et l'exploitation
du système. La conception permet d'étendre la
représentation des diagrammes effectuée au niveau de l'analyse en
y intégrant les aspects techniques plus proches des
préoccupations physiques.
Implémentation
Cette phase correspond à la production du
logiciel sous forme de composants, de bibliothèques ou de
fichiers.
Test
Il permet de vérifier :
? La bonne implémentation de toutes les exigences
(fonctionnelles et techniques),
? Le fonctionnement correct des interactions entre les objets,
? La bonne intégration de tous les composants dans le
logiciel.
2.3.4. Adaptation du processus unifié
Il existe plusieurs processus de développement qui
implémente UP dont les plus connues sont :
? RUP : Rational Unified Process
? XP : eXtreme Programming
? 2TUP : Two Tracks Unified Process,
Dans le cadre de notre étude, nous allons utiliser le
2TUP, tout développement peut être décomposé et
traités en parallèle selon un axe fonctionnel et un axe
technique. Nous pouvons ainsi suivre les évolutions liées aux
changements des besoins fonctionnels et aux changements des besoins
techniques8.
8ROQUES, P et VALLEE F, op.cit
P14.
[24]
La schématisation du processus de développement
correspond alors à un Y. Les deux perspectives se rejoignant lors de la
phase de conception préliminaire.
Figure 3 : Processus de développement
2TUP
La branche fonctionnelle contient :
la capture des besoins et de leurs analyses. Les résultats de l'analyse
sont indépendantes des technologies utilisés.
La branche technique contient : la
capture des besoins techniques et de la conception générique.
L'architecture technique construit le squelette du
système informatique indépendamment des besoins fonctionnels.
Les deux branches sont ensuite fusionnées en une seule
branche qui prend en charge la conception préliminaire (cartographie des
composants à développer), conception détaillée
(comment réaliser chaque composant), codage (production des composants),
tests et étapes de validation des fonctions
développées.
2.4. Généralités sur le langage
UML
UML (Unified Modeling Language) est un langage formel et
normalisé en termes de modélisation objet. Son
indépendance par rapport aux langages de programmation, aux domaines de
l'application et aux processus, son caractère polyvalent et sa souplesse
ont fait de lui un langage universel. En plus UML est essentiellement un
support de communication, qui facilite la représentation et la
compréhension de
[25]
solution objet. Sa notation graphique permet d'exprimer
visuellement une solution objet, ce qui facilite la comparaison et
l'évaluation des solutions. L'aspect de sa notation, limite
l'ambigüité et les incompréhensions.
UML fournit un moyen astucieux permettant de
représenter diverses projections d'une même représentation
grâce aux vues.
Une vue est constituée d'un ou plusieurs diagrammes. On
distingue deux types de vues:
La vue statique, permettant de
représenter le système physiquement :
Diagrammes de classes: représentent des collections
d'éléments de modélisation statiques (classes,
paquetages...), qui montrent la structure d'un modèle.
Diagrammes d'objets: ces diagrammes montrent des objets
(instances classes dans un état particulier) et des liens (relations
sémantiques) entre objets.
Diagrammes de composants: permettent de décrire
l'architecture physique statique d'une application en termes de modules :
fichiers sources, librairie exécutables, etc.
Diagrammes de déploiement: montrent la disposition
physique du matériel qui compose le système et la
répartition des composants sur ce matériel.
La vue dynamique, montrant le fonctionnement
du système :
Diagrammes de collaboration: montrent des interactions entre
objet (instances de classes et acteurs).
Diagrammes de cas d'utilisation: identifient les utilisateurs
du système (acteurs) et leurs interactions avec le système.
Diagrammes de séquence: permettent de
représenter des collaborations eu objets selon un point de vue temporel,
on y met l'accent sur la chronologie (envois de messages).
Diagrammes d'états-transitions: permettent de
décrire les changements d'états d'un objet ou d'un composant, en
réponse aux interactions avec d'autres objets/composants ou avec des
acteurs.
Diagrammes d'activités: (une variante des diagrammes
d'états-transitions) servent à représenter graphiquement
le comportement d'une méthode ou déroulement d'un cas
d'utilisation.
[26]
2.5. Le diagnostic de la fièvre typhoïde
2.5.1. Le diagnostic
Le diagnostic n'est rien d'autre que l'identification d'une
maladie par ses symptômes. Il permet de reconnaitre une maladie pour en
assurer la prise en charge appropriée. Le diagnostic est
l'élément essentiel de la décision médicale qui
relève de la compétence du médecin.
Ce concept remonte aux origines de la médecine. La
rationalité de la démarche diagnostique s'est enrichie au cours
des deux derniers siècles des apports de la science. Le schéma
selon lequel le diagnostic est issu du recueil et de la hiérarchisation
des symptômes et des signes cliniques, confirmé et
précisé par les examens complémentaire doit être
gardé en mémoire comme un principe fondamental.
L'élaboration du diagnostic bénéficie de
nombreuses innovations. Elles concernent les moyens techniques disponibles
(biologie, imagerie) et les nouvelles méthodes pour tirer parti des
données (statistiques, algorithme).
Le développement des moyens de diagnostic impose des
nouvelles responsabilités aux médecins : renouvellement des
connaissances, exigeant une formation continue et efficace, bon usage des
moyens disponibles imposant l'évaluation des pratiques professionnelles.
La mise en oeuvre du diagnostic doit tenir compte de l'évolution de la
société.
2.5.2. La fièvre typhoïde
La fièvre typhoïde (du grec tuphos, torpeur) ou
typhus abdominal est une maladie infectieuse décrite en 1818 par Pierre
Bretonneau, causée par une bactérie de la famille
Entérobactérie, du genre des salmonelles, et dont les
espèces responsables sont: Salmonella enterica - typhi ou paratyphi A,
B, C -. Salmonella enterica typhi est
encore appelée bacille d'Eberth. C'est une maladie
bactérienne
transmissible strictement humaine. Elle est
provoquée par des salmonelles que l'on trouve dans le lait, la
nourriture ou l'eau contaminé.
La faisabilité opérationnelle s'intéresse
plus aux besoins non fonctionnels car elle décrit toutes les contraintes
possibles notamment
[27]
| 
