Conception d'une application web de gestion des équipements et materiels dans un réseau de sante

Enseignement Superieur et Universitaire

INSTITUT SUPtRIEUR DE STATISTIQUE

Departement d'Informatique de Gestion

B.P. 2471
LUBUMBASHI

CONCEPTION D~UNE APPLICATION WEB DE GESTION DES MATERIELS ET

EOUIPEMENTS DANS UN RESEAU DE SANTE

(Cas du District de Sante de Lubumbashi)

Par : NYAM I NYATE Ruphin

Travail presents et defendu en vue de I'obtention du grade de Licencie en Informatique de Gestion

Option : Conception des Systèm es d'Informations

Juillet 2010

`'Je viens de quelque part et je vais désormais quelque part
et J'ai reçu le pouvoir de choisir ma réponse pour produire un
impact positif.»

`'Ce n'est pas ce qui nous arrive qui nous affecte mais c'est notre réaction à ce qui nous arrive qui fait la différence entre la mentalité de gagnants et de perdants :

· Le gagnant se voit comme étant la cause pour ce qui lui arrive ;

· Le perdant cherche quelqu'un à blâmer pour ce qui lui arrive!

· Le gagnant se concentre sur la solution ;

· Le perdant se concentre sur le problème ;

· Le gagnant se concentre sur le futur ;

· Le perdant se concentre sur le passé ;

· Le gagnant se demande qu'est-ce qui peut être fait ?

· Le perdant se demande qui faudrait-il accuser».

« Toute chose concourt au bien de ceux qui aiment Dieu et
sont appelés selon son dessein » Romain 8 :22

Épigraphe

Dédicaces

a ma m1(e "Claudine NG OM O " et mon p1(e "Norbert NYATE" en temoignage de few( affection, few(6 6ac(ifice6 et de few(6 p(iciewx con6eit6 qwi m'ont condwit lc ea (aw66ite dan6 me6 etwde6 ;

a me6 P(1(e6 et 6Ew(6 "John LELE ", "M INENGE M G", ~'Eveline KINDA" et "M APITSHI" en few( 6owhaitant ea (aw66ite dan6 few(6 etwde6 et dan6 few(6 Uie6,

a me6 t(16 che(6 Oncte6 : D(. Theophile NEM W ANDJARE et Prospere BUSHAKE pow( towte affection temoignee enoe(6 moi. le fe(ai6 de mon miewx pow( (e6te( wn 6wjet de ~ie(te lc 0o6 vewx auec ~'e6poi( de ne jamai6 Mow6 deceloi(.

a toi Angel Leome ma &e(~ine pow( not(e amow( et ea patience, ea ~idetite temoigne 6an6 ce66e ; tw a6 comb& me6 uide6 emotionnet6 comme etant pa(tenai(e dw chemin de ea cie, t(owve ici mon affection.

CZ me6 )ow6in6 et eow6ine6. Vow6 occwpez de6o(mai6 wne peace pa(ticwti1(e dan6 mon c~w(. le Mow6 d'die ce t(a aie en Mow6 6owhaitant wn a eni( (adiewx, peein de (onhew( et de 6wcc16.

Et lc tow6 cewx qwe j'aime et qwi m'aiment.

le dedie ce t(await

aualit-p~~p"

Ce travail a été réalisé dans le cadre de projet de fin d'études a l'Institut Supérieur de

Statistique de Lubumbashi, en collaboration avec le District de Santé de Lubumbashi pour l'obtention du diplôm e de Licence en Conception des Systèmes d'Inform ations.

Le chem in de l'inconnu est toujours pénible , m ais c'est au pris du sacrifice qu'on y parvient , et cela ne dépend ni de la volonté de celui qui veut, ni de celui qui court, m ais tout dépend de la volonté d'EL-SHADAI (Dieu de toute suffisance : Genese 17 :1-3) , car nom breux ont essayé m ais n'ont pas triom phé ! Donc rien de sorcier pour en devenir le chef d'orchestre.

Et c'est en aveu du succes de ce long et pénible voyage plein de m éandres que m es

fervents m ercis se vouent , a M r. Le Chef de Travaux Leon M USHIND O BUCICI, pour sa serviabilité et ses hautes qualités morales, pour son soutien et ses conseils avisés.

Je tiens égalem ent a présenter m es sinceres rem erciem ents a M r. BULA Lucide pour ses précieuses rem arques qui ont conduit ce travail a sa fin, sa m odestie et sa sym pathie , pour ses

Com pétences et ses directives fructueuses qu'il n'a cessé de m e prodiguer tout au long de ce projet , qu'il soit avisé ici de m es sinceres m ercis.

J' adresse m a profonde gratitude a M r. Jacques M UNDA, Chef de Travaux a l'Institut Supérieur de Statistique , qui n'a épargné aucun effort pour le bon déroulem ent de ce travail. Sa disponibilité , ses rem arques et ses conseils ont été pour m oi d'un grand apport.

J'adresse aussi m a plus vive reconnaissance a tous m es enseignants de l'ISS Lubumbashi pour la formation qu'ils m 'ont donnée ainsi qu'aux m em bres de jury qui ont accepté de juger ce m odeste travail.

A m es Cousins, Cousines , neveux , nieces, je suis pour vous une preuve de vie apres de sévices , rassurez vous que l'avenir proche pour notre fam ille.

Quelle ingratitude de notre part si on passait ce moment sans reconnaitre les sacrifices de la fam ille Dr. Théophile , en particulier M aman Lydie qui n'a épargné aucun effort, de pres ou de loin, pour m e perm ettre d'accom plir mon travail et j'espere que ca sera le bon départ pour le reste de génération , que Dieu vous bénisse pour votre bonne maniere de sem er.

Je rem ercie la fam ille GABY et M OBI, pour m 'avoir secouru pendant les moments difficiles sincerement Que mon Dieu vous com ble de grace et prolonge vos jours ici bas.

A m es Freres et Sc eurs Toussaint NYAM I, Sa m ajesté Luc BIPULA, Freddy NGWAM A Pascal IYOL O, Rose, M erda, Florence pour votre contribution utile dans m a vie.

A tous les Freres, Sc eurs , et hom m es de Dieu de l'église M ADA qui par une prière l'c euvre est parvenue a se m atérialiser. Que mon Dieu vous bénisse et qu'il soutienne son c euvre et amene M ADA a son standard divin.

Je dis merci a la Fam ille Dief NGWAKOY O et Lycky BI ONG O pour leurs précieux conseils.

A m es com pagnons de lutte >' Jean Dido YAV M UCHAIL, Lucien KITENTE, Sophie TSHINJI, Bertin LOBO MINGA, Pyspa BUKASA, M UZOWA MICHEL, ERIC KAMBALE, Patient M UTOBE 4' pour la franche collaboration, trouvez ici notre expression d'affection , que Dieu vous bénisse et rendez-vous au som m et.

Nous profitons de cette occasion tém oigné notre reconnaissance a M r. NSUM BU Mathieu pour sa contribution utile lors de l'im pression et la polycopie de cette c euvre que l'éternel Dieu se souvient de vous.

A tous les am is du Zero et en particulier a M r. NEBRA Mateo le patron du site, M r. Cysboy, pour les compétences et les formations, publiques conseils dans le dom aine inform atique en ligne qui ont fait de nous des héros a la place de zeros.

A tous les am is et connaissances Didier KISANGA, Gilbert ISSABA, Blaise IBANDJI qui ont contribue d'une maniere ou d'une autre a la realisation de ce travail.

Introduction Générale

0. Generalites.

Notre évolution, depuis nos origines, tend à nous affranchir de nos contraintes. La révolution industrielle, il y a environ 150 ans, a permis à l'homme de ne plus fonder ses relations avec le monde uniquement sur sa propre force physique. La maîtrise des énergies issues par exemple de la vapeur a permis d'abandonner les faibles et capricieuses forces animales. Dès qu'il fut débarrassé de la partie la plus pénible de son labeur, l'homme pu se consacrer à diverses réflexions et les conséquences plus au moins directes de la révolution industrielle furent les émergences de la démocratie, de l'opinion publique, de l'individualisme et de l'idée que nous avons actuellement de la démocratie.¹

Depuis l'apparition de l'informatique et son introduction dans le monde économique, les entreprises et les entités publiques aspirent à optimiser et à rendre fiable la gestion de leur structure interne.

Le District de Santé de Lubumbashi possède plus de dix (10) Zones de santés possédant chacune de dispositifs médicaux, matériels de bureaux, équipements qu'il est difficile de gérer en continu. Et avec l'application de l'art 5, §1^er de loi du 21 Décembre 1998 portant création de la « Coopération Technique Belge », la CTB se voit, notamment, confier la responsabilité exclusive sur le terrain des initiatives prises dans les cadres de coopération bilatérale directe et de l'engagement de personnel, de moyen pour la mise en oeuvre des projets et de programmes, de la coopération financière, de l'appui aux micro entreprises, de bourses et de stages, la situation s`est davantage compliquée et la tâche de gestion est devenue plus complexe.

La mondialisation et l'accroissement des échanges et des communications provoquent une poussée sans précédent pour l'adoption de normes visant l'assurance et l'amélioration de la qualité. Alors que l'industrie et le secteur privé adoptent le plus en plus la normalisation, le monde médical est encore réticent et associe souvent la normalisation à la lourdeur administrative certaine et paperasse.²

Il importe que l'information soit considérée comme une ressource majeure et essentielle à la gestion d'un parc matériel et équipement ou des dispositifs médicaux, car elle influe directement à la prise de décision de managers, tout comme sur la performance administrative de l'ensemble de l'organisation.

¹ L. Fieux, Dunod : L'inform atisation : une &tape pour l'humanite, PP. 9-18.

² Global Medical Device Nomenclature : http : //w ww .gm dn.info/

1.

Problématique

La problématique est une construction conceptuelle thématique mettant en relation un certains nombre de problèmes et des questions qui dépendent les uns les autres.³

Le District de santé de Lubumbashi utilise certains matériels ou équipements sans en être propriétaire durant la vie du projet, c'est pour dire qu'à une date fixe le propriétaire récupère ses biens. C'est pourquoi le coût d'utilisation, les amortissements et les affectations de ses biens nous importent à ce stade.

Il n'existe aucun moment sans que l'on apprenne qu'il connaît des difficultés sur sa gestion des équipements, des matériels ou des dispositifs médicaux financés par le gouvernement ou par un partenaire étranger ou local, ONGD ou un achat interne..., qui mettent en cause son bon fonctionnement, de telle manière qu'un patient poursuit un hôpital à causes des effets graves causés par certains équipements défectueux, et l'hôpital en son tour tente de poursuivre le réparateur, mais l'appareil ne possède pas de numéro de série ni d'inventaire. L'établissement ne peut donc prouver que l'équipement en cause est celui réparé par la firme en question. Tel partenaire mécontent de la mauvaise gestion (vol, destruction, vente, pertes, mauvais entretient...) des équipements à la fin du projet dont la responsabilité lui revenait.

Dans ce travail, nous nous focalisons sur un examen de savoir :

comment le District de Santé de Lubumbashi procède pour organiser la gestion de son parc matériel et équipements ?

la procédure en place a-t-elle permis d'atteindre les objectifs ?

que doit-il faire pour normaliser une gestion efficace de son parc matériel et équipement, en assurant les échanges et la qualité de soin, satisfaire aux demandes d'inventaires détaillés et certifiés en un temps exempté entre les partenaires, les patients victimes de dégâts matériels ?

2. Hypothése

L'hypothèse est une opinion qui devient crédible lorsqu'on aura répondu positivement à une analyse minutieuse. Elle est l'idée directrice d'une tentative d'explication d'un fait par

le quel est formulé au débit de la recherche, souvent destiné à être infirmer ou confirmer après vérification.⁴

Ainsi de notre part, supposons qu'il faudrait installer un système informatique capable de rendre accessible et rapide à l'information, la consulter, la modifier, la diffuser et la relier à d'autre document c'est à dire bien contrôler les interactions observées ou anticipées intervenant dans les différentes structures tant internes qu'externes.

Le projet que nous proposons nous permettra de faciliter la gestion des matériels, à travers la conception d'une application web avec une méthode que nous allons présenter.

Le système issu de cette analyse aura à remplir les fonctionnalités et répondre aux questions récurrentes :

> La saisie des informations concernant un matériel, un équipement ou un dispositif médical présent sur le District.

> Quel équipement, matériels ou dispositif médicale a été confié à un salarié, à une structure.

> Quel a été le temps d'utilisation d'un équipement pendant l'année.

> L'échange ou le partage des informations ente les travailleurs du métier participant à cette gestion du parc, (l'agent d'exécution et les partenaires, les différentes structures).

> La mis à jour des informations concernant un équipement ;

> Inventaire par type de matériel ;

> Inventaire par mission (programme, site, chantier, unité de soin etc.;

> Inventaire par bailleur ou contrat de financement.

> Inventaire du matériel importé au pays et ayant bénéficié d'une exonération de taxe.

> Rapport mensuel des matériels (courses de service, courses divers, consommations (fuel, réparation, entretien), kilométrages (finals, départs);

> Les matériels en intervention ;

> L'établissement l'envoi des différents rapports liés à cette gestion du parc matériel et équipement.

4

ALPHA ONE N'SULU : Methode de Recherche en Science Inform atique , Cours Inedit G2 Info ISC-ILEBO 2006- 2007

3.

Choix Et Inter~t Du Sujet

Le choix de notre sujet intitulé « La Conception d'une application Web de Gestion de matériels et équipements dans un réseau de Santé (District de Lubumbashi) s'inscrit dans le cadre de recherche en informatique de gestion.

La préoccupation majeure qui nous a propulsés est de combattre la lourdeur sur la gestion de parc en y introduisant les avantages d'une gestion informatisée.

Le District de Santé de Lubumbashi en tant qu'intermédiaire d'une part entre la Division Provinciale de la Santé, la Province et les structures de santé (zones de santés, Centres de santé de Références), et d'autre part garant entre les financeurs et les structures de santé est impérativement censée connaître pour chaque équipement, outil, matériel financé ou acheté au fonds propres les multiples contraintes et aspects (contractuels, économiques, juridiques et temporel) afin de satisfaire les parties dont il joue le rôle d'intermédiaire.

En plus le District de Santé de Lubumbashi doit : affecter les matériels à de zones et Centres de santé, dont il doit préalablement identifier et en faire le suivi pour se rendre compte de (s) entretiens, usages, vol, destruction, aliénation, dégâts.... Il est le responsable des approvisionnements (en consommables, équipements), des affectations, des inventaires des matériels par site géographique, projet, structure, une unité de soin et en suite dresser un rapport périodique aux Financeurs (partenaires), aux instances compétentes à un temps exempté.

4. Delimitation Du Sujet

La délimitation spatiale concernera l'informatisation des tâches ou des opérations de la direction logistique de District de Santé de Lubumbashi.

En outre notre étude s'est déroulée dans un concept très limité du point de vue temps, donc la période allant de 2008 à 2010 étant donné que la gestion du parc matériel se synchronise avec le moment présent, telle qu'elle s'opère actuellement.

5. Methodes Et Techniques De Recherche

Pour l'élaboration de tout travail qui se veut être scientifique, on doit avoir une méthode et des techniques.

5.1 Methode

Selon le Disco Encarta, le mot `' Méthode» signifie un ensemble des principes théoriques et pratiques sur lesquels se fondent l'application ou l'enseignement d`un art ou d'une science.⁵

Nous avons opté pour une méthode analytique. Nous sommes partis du principe que le site web de gestion des matériels et équipements du District de Santé de Lubumbashi peut aussi bien être utilisés par d'autres sociétés ayant une chaîne logistique ou un parc matériel et équipements chargés d'affaires.

5 .2 Technique

La technique est un moyen qui permet au chercheur d'acquérir les informations de sa recherche et les utiliser pour arriver à expliquer son objet d'étude.

La méthode seule ne suffit pas pour atteindre le but, il faut toujours l'adjoindre aux techniques. C'est pourquoi dans le cadre de notre travail nous avons les techniques suivantes :

a. L'interview libre

L'interview libre est un procédé au cours du quelle le premier (inter viveur), pose des nombreuses questions, non structurée à l'avance ; c'est à dire une interrogation orale d'une personne à une autre.⁶

Elle nous aidé de bien avoir les informations au sein du District de Santé de Lubumbashi, plus précisément au département de logistique en posant de questions aux travailleurs du métier, et aux différents entretiens pour une vue claire et nette sur notre domaine d'étude.

b. Technique documentaire

Elle nous a permis à l'assemblage des notes relatives au sujet et de documents ainsi que des ouvrages nécessaires afin de mieux cerner le contour de notre travail.

5
·

Disco Encarta 2009.

⁶ C.T. Paulin NDJONDO : Initiation a la recherche scientifique , Cours inédit ISC-Ilebo 2007-2008

6. Presentation Sommaire Du Travail

Abstraction faite à l'introduction et la conclusion générale, notre travail comportera Trois chapitres :

Chapitre I : ANALYSE DU METIER.

Section I : Présentation du district de sante de Lubumbashi et de la démarche informatique
XP

Cette section fera l'objet d'une présentation du District de Santé de Lubumbashi c'est à dire son histoire et sa cartographie, son objectifs social, son organigramme et la démarche informatique (XP) c'est-à-dire les définitions des différents concepts utilisés dans ce document, que nous ferons routes ensemble afin d'amener notre projet à apocalypse.

Section II : Analyse du métier

C'est ici que nous allons appliquer la méthode XP au problème de la Gestion des Matériels et Equipements en respectant les phases suivantes :

ü 1 : l'Etude préliminaire

Etude préliminaire ou (pré-étude) est la toute première étape de notre processus de développement. Elle survient à la suite d'une décision de démarrage de projet, et consiste à effectuer un premier repérage des besoins fonctionnels et opérationnels, en considérant le système comme une boite noire, afin d'étudier sa place dans le système métier plus global de l'entreprise.

ü 2 : Capture de besoins fonctionnels

Cette section traite du rôle que tient UML pour compléter la capture des besoins fonctionnels ébauchés durant l'étude préliminaire. La technique des cas d'utilisation est la pierre angulaire de cette étape. Elle nous permettra de préciser l'étude du contexte fonctionnel du système, en décrivant les différentes façons qu'auront les acteurs d'utiliser le futur système.⁷

Chapitre II. Analyse du Systeme Informatique

ü 1. Recueil de besoins du Système Informatique

Identifie les besoins du système informatique capable d'aboutir à une solution informatique.

⁷ Pascal Rogues : UM L en action, écl. Eyrolles , 2003 P. 59-61.

ü 2. Identification des Classes Participantes

ü 3 Découpage catégorie

ü 4. Développement du modèle statique

Elle décrit et illustre le travail d'analyse détaillée de la structure de classes.

ü 6 Développement du Modèle dynamique.

À ce niveau nous ressortirons les classes réactives.

Chapitre III : CONCEPTION DE L'APPLICATI ON

ü 1 : Conception détaillée.

ü 2 : La Persistance

Elle illustre la modélisation des solutions en appliquant les différents design patterns (patrons de conception), suivant les couches que l'on désire réaliser.

ü 3 : Architecture de l'Application

ü 4 : Architecture Matériel

ü 5 Déploiement du Système

ü 6 : Le Design Patterns

Il nous aidera à constituer un petit ensemble de classes aptes à offrir une solution la plus efficace à un problème qui donnera le Design Patterns « MVC » du modèle vue contrôleur.

ü 6 : Codage C'est à ce niveau que se transformera notre modèle objet en code.

C HAPITRE I : ANALYSE DU METIER

Section I : presentation du district de sante de Lubumbashi et de la
demarche inform atique XP.

I.1. Présentation du District de Santé de Lubumbashi.

1.1.1 : Situation Geographique

Au niveau intermédiaire du Ministère de la Santé à l'instar de la Division Provinciale de la Santé, le District de Santé de Lubumbashi est situé dans la ville portant le même nom c'est à dire sa sphère s'étend selon la juridiction de la ville, la quelle ville est enclavée dans le territoire de Kipushi au Sud et est subdivisée en sept (7) Communes administratives.

Ses bureaux sont situé au 2^èm étage du Bâtiment de l'Hôtel de ville de Lubumbashi, précisément au croisement des avenues Tabora et Lomani.

Le District sanitaire de Lubumbashi est limité au Nord, au Sud et à l'Est par le District du Haut Katanga, et à l'Ouest celui de Likasi. Il compte une population de 1.404.272 habitants répartis sur Onze (11) Zones de Santé d'une superficie estimée à 385 Km².

1.1.2. Apercu historique.

Étant donné que la position du District de Santé est fonction de l'entité Ville de Lubumbashi, son histoire est embarquée avec les limités de la ville de Lubumbashi.

a. Avant l'Indépendance.

La ville de Lubumbashi, jadis Élisabethville fut fondée en 1910 lorsque les colonisateurs choisirent le plateau et la bourgade qui domine la rivière Lubumbashi et au moment de l'entrée du rail venant du Sud. C'est toujours en 1910 que le siège fut transféré à côté de la Mine de l'Etoile à la Ruashi et deviendra le Chef lieu de la Province du Katanga.

C'est par l'ordonnance loi n° 298/AIMO du 25 Juin 1945 que Lubumbashi obtiendra le statut de ville. (2^ème Ville après Léopoldville).

b. Après Indépendance.

Sur le plan politique, la ville de Lubumbashi qui est le chef lieu de la Province du Katanga n'a pas changé de statut sauf qu'elle continue à dépendre du pouvoir central.

Le premier Maire fut Monsieur MWEPU Boniface de 1960 - 1964. L'actuel Maire est le vingt-cinquième depuis l'accession du pays à l'indépendance.

Il convient donc de revenir dire que le District de Santé de Lubumbashi est ceinturé par la Commune Annexe, elle même encastrée dans tous les points par le territoire de Kipushi.

Ainsi, l'histoire de la ville de Lubumbashi est liée à celle du District de Santé de Lubumbashi.

1.1.3. Organigramme du District de Santé de Lubumbashi.

M édecin Chef de
District

Chef de la
l^ere Cellule

Chef de la 2eme Cellule

Pharmacien du District

Chef de la 3eme Cellule

Superviseur
Nutrition

Chef de la 4eme
Cellule

		Comptable

Chef du
Personnel

Technicien de
Développement

Technicien
d'assainissemen

Source : Secrétariat District

Secrétaria

Loeisticien

Informatique

Superviseur
L - TBC

M édecin
chef

1.1.4. Structure.

6. _La Jère Cellule : Coordonne les activités liées à la gestion de ressources humaines, matérielles et financière du réseau sanitaire.

6. La 2^ème Cellule : Coordonne les activités liées à la qualité des soins. C'est dans ce

cadre que l'inspection des établissements des soins et pharmaceutique est faite.

4. La 3^6me Cellule : Coordonne les activités liées à l'animation sanitaire, l'hygiène, la nutrition et le développement.

6* La 4^6me Cellule : Chargée de la Coordination des activités pédagogiques des ITM/IEM de la place.

1.2 Présentation de la dém arche inform atique XP

Le processus que nous avons opté de suivre pour le développement d'applications web se situe à mi-chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et les méthodes agiles en vogue actuellement, telles que XP (eXtrême Programming). Il s'inspire également des bonnes pratiques prônées par les tenants de la modélisation agile (Agile Modeling).

1.2.1 : le processus unifie

La complexité croissante des systèmes informatiques a conduit les concepteurs à s'intéresser aux méthodes de développement. Ces dernières ont toujours essayé d'apporter un contrôle continu sur un projet tout au long de son processus de vue.

Bien que des méthodes de développement existent depuis 30 ans (Merise, SADT), nous ne pouvons constater aujourd'hui l'existence d'une règle qui soit à la fois formelles et commune à toutes les cultures.

Le Processus Unifié (PU ou UP en anglais pour Unified Process) est une méthode de développement logiciel construite sur UML ; elle est itérative et incrémentale, centrée sur l'architecture, conduite par les cas d'utilisation et pilotée par les risques.

· Itérative et incrémentale : la méthode est dite itérative dans le sens où elle permet de faire des itérations lors de différentes phases, ceci garantit que le modèle construit à chaque phase ou étape soit affiné et amélioré. Chaque itération peut servir d'ajouter de nouveaux incréments.

· Conduite par les cas d'utilisation : elle est orientée utilisateur pour répondre aux besoins de ce dernier.

· Centrée sur l'architecture : tout système complexe doit être décomposé en parties modulaires afin de permettre une maintenance et une évolution facilité c'est-à-dire les grandes mailles, l'architecture de type qui sera retenu pour le développement, l'implémentation et en suite le déploiement du système⁸.

· Pilotée par les risques : en définissant les priorités pour chaque fonctionnalité, on peut minimiser les risques d'échec du projet.

⁸ Joseph Gabay, David Gabay : UM L 2 Anayse et Conception, ed. Dunod, Paris, 2008 ISBN 978-2-10-053567-5, pp

113 - 115

UP répète un certain nombre de fois une série de cycle qui s'articulent sur 4 phases :

1. Préétude (Inception) ou Analyse de besoins : c'est à ce niveau qu'on évalue l'un petit plus à ajoutée du développement et la capacité technique à le réaliser (étude de faisabilité). L'analyse de besoins donne une vue du projet comme un produit fini et surtout elle fait face aux questions suivante :

Que va faire le système ? par rapport aux utilisateurs principaux, quel service va-t-il rendre ?

Quelle va être l'architecture générale (cible) de ce système ?

Quels vont être : les délais, les coûts, les ressources, les moyens à déployer.

2. Elaboration : c'est ici que sera confirmée la concordance parfaite du système aux besoins des utilisateurs et à livrer l'architecture de base ou stable⁹.

3. Construction : sert à livrer progressivement toutes les fonctions du système c'est-àdire l'architecture de référence se métamorphose en un produit complet ayant tous les cas d'utilisations mis en place.

4. Transition : déployer le système sur des sites opérationnels, et le produit étant en version beta, d'autres erreurs peuvent être détectées par les utilisateurs d'où le nécessité d'une formation, la mise en place de l'assistance et correction d'erreurs.

Le résultat de chacune d'itérations de phase précédentes, est un système testé, intégré et exécutable. L'approche itérative est fondée sur la croissance et l'affinement successifs d'un système par le biais d'itérations multiples. Le système croît avec le temps de façon incrémentale, itération par intention, et c'est pourquoi l'acronyme de méthode itérative et incrémentale. Il s'agit là d'un principe primordial et la devise même du Processus Unifié.

Toutes ces activités du processus de développement sont définies par six (6) disciplines qui décrivent la capture des besoins, la modélisation métier, l'analyse et la conception, l'implémentation, et en fin le test de déploiement.

Signalons aussi que ces différentes étapes peuvent se dérouler à travers plusieurs

phases.

Le processus unifié doit donc être compris comme une trame commune des meilleures pratiques de développement.

Par ailleurs des méthodes séquentielles comme celles se basant sur le cycle en V, ont vite révélé leur limite dans un environnement régi par des changements réguliers, impliquant un quasi impossibilité de revenir en arrière, et de ce fait laissant une très petite marge d'erreur.

⁹1.Gabay, D.Gabay : Op.Cit. pp. 115 - 116

Avec l'innovation de l'orienté objet, des nouvelles méthodes sont apparues et différentes notations ont étés établies. UML a ouvert la porte de l'unification en fusionnant ces notations et en apportant précision et rigueur à la définition des concepts introduits.

Ce pendant nous retrouvons devant l'embarras de choix devant le nombre de méthodes disponibles, les questions que se poser souvent le chef du projet lors du démarrage sont :

· Comment vais-je organiser les équipes de développement ;

· Quelles tâches attribuer à qui ;

· Quel temps faudrait-il pour livrer le produit ;

· Comment faire participer le client au développement afin de capter les besoins de celui-ci ;

· Comment éviter des dérives et de mauvaises estimations qui vont allonger les coûts et le temps de développement.

· Comment vais-je procéder pour que le produit soit évolutif et facilement maintenable.

Ainsi nous pouvons citer à ce propos les méthodes objet suivantes : 2TUP, RUP, XP, AUP et OpenUP.

Notre choix est orienté vers la méthode XP, du fait de son approche nouvelle et originale.

Notre projet est basé sur un processus de développement bien défini qui prend sa source de la détermination de besoins fonctionnels attendus du système jusqu'à la conception et le codage final.

1.2.2 : le processus xp

L'UP est une trame de meilleures pratiques de développement, il doit être utilisé comme un guide pour réaliser un projet et non comme l'arme ultime et universelle de développement. Ainsi nous optons pour XP dans le cadre ce travail vu son agilité et ses souples principes.

L'eXtreme Programming (XP) est un ensemble de pratiques qui couvre une grande partie des activités de la réalisation d'un logiciel, de la programmation proprement dite à la planification du projet, en passant par l'organisation de l'équipe de développement et les échanges avec le client.¹⁰

¹⁰ Pascal Rocques : les cahiers du program m eur, eme ed. Eyrolles , 2002 , 2007 , 2008 pp. 11 - 12

Le XP a été mis en oeuvre pour la première fois en 1996 sur le projet C3, Chrysler Compréhensive Compensation System. Les pères de la méthode, Ward Cunningham et Kent

Beck définissent eXtrême Programming comme « une méthode basée sur des pratiques ^quisont autant des boutons de contrôle poussés.

L'eXtrême Programming (XP) est une méthodologie légère qui met l'accent sur l'activité de programmation et qui s'appuie sur les valeurs suivantes : communication, simplicité, feedback et le courage. Elle est bien adaptée pour des projets de taille moyenne où le contexte (besoins des utilisateurs, technologies informatiques) évolue en permanence.

1. Communication :

L'absence de la communication est certainement l'un de défaut les plus grave qui mettent en péril un projet. Les pratiques de XP tendent à rendre la communication omniprésente entre tous les intervenants.

Toutes ces pratiques ont pour but de permettre à chacun de se poser de bonnes questions et de partager l'information.

2. Simplicité :

XP encourage toujours de développer un système simple qu'on aura engagé de nouveau frais plus tard pour ajouter de nouvelles fonctionnalités supplémentaires donc de s'orienter vers la solution la plus simple qui puisse satisfaire les besoins du client ; plutôt que de concevoir dés le départ un système très compliqué dont on risque de n'avoir plus besoin dans un avenir proche.

3. Feedback :

Le retour est immédiat pour les développeurs grâce aux tests unitaires. Pour les clients le retour se fait à l'échelle de quelques jours grâce aux tests fonctionnels qui leur permettent d'avoir une vision globale du système.

Le feedback est indispensable pour que le projet puisse accueillir le changement.

4. Courage :

Pour mener à bien un projet XP, le client doit avoir du courage de donner un ordre de priorité à ses exigences, de reconnaître que certains de ses besoins ne sont pas toujours bien clairs. De son côté, le développeur doit avoir le courage de modifier l'architecture même si le développement a suffisamment avancé, de jeter du code existant et d'accepter qu'il est parfois plus rapide et efficace de réécrire une portion de code à partir du zéro plutôt que de bricoler un code existant.

1.2.3 : Un processus de rnodélisation avec UM L

Le processus XP s'appuie sur UML tout au long du cycle de developpement, car les differents diagrammes de ce dernier permettent de part leur facilite et clarte, de bien modeliser le système à chaque etape.

« Unified Modeling Language » : UML se definit comme un langage de modelisation graphique et textuel destine à comprendre et decrire des besoins, specifier, concevoir des solutions et communiquer des points de vue. (Pitman, 2006)

UML s'articule autour de treize types de diagrammes, chacun d'eux etant dedie à la representation des concepts particuliers d'un système logiciel. Ces types de diagrammes sont repartis en deux groupes : structurels et les diagrammes comportementaux.

Six diagrammes structurels

ü Diagramme de classes : Il montre les briques de base statiques : classes, associations, interfaces, attributs, operations, generalisations, etc.

ü Diagramme d'objets : Il montre les instances des elements structurels et leurs liens à l'execution.

ü Diagramme de packages : Il montre l'organisation logique du modèle et les relations entre packages.

ü Diagramme de structure composite : Il montre l'organisation interne d'un element statique complexe.

ü Diagramme de composants : Il montre des structures complexes, avec leurs interfaces fournies et requises.

ü Diagramme de déploiement : Il montre le deploiement physique des « artefacts » sur les ressources materielles.

Sept Diagrammes comportementaux

ü Diagramme de cas d'utilisation : Il montre les interactions fonctionnelles entre les acteurs et le système à l'etude.

ü Diagramme de vue d'ensemble des interactions : Il fusionne les diagrammes d'activite et de sequence pour combiner des fragments d'interaction avec des decisions et des flots.

ü Diagramme de séquence : Il montre la sequence verticale des messages passes entre objets au sein d'une interaction.

v' Diagramme de communication : Il montre la communication entre objets dans le plan au sein d'une interaction.

v' Diagramme de temps : Il fusionne les diagrammes d'états et de séquence pour montrer l'évolution de l'état d'un objet au cours du temps.

v' Diagramme d'activité : Il montre l'enchaînement des actions et décisions au sein d'une activité.

v' Diagramme d'états : Il montre les différents états et transitions possibles des objets d'une classe.

Quelques uns seront utilisés tout au long de notre projet vue l'agilité de notre démarche adoptée.

Section II. ANALYSE DU METIER.

1 : Etude Preliminaire.

L'etude preliminaire (ou Pre-etude est la toute première etape du processus XP. Elle consiste à effectuer un premier reperage des besoins fonctionnels et operationnels, en considerant le système comme une boite noir et cela en utilisant principalement le texte, ou diagramme très elementaires. Cette etude prepare aussi les activites plus formelles de capture des besoins fonctionnels et capture techniques.

1.1. Presentation du projet a realiser.

Cette application permettra de mieux gerer les equipements et materiels en general.

Elle doit permettre aussi le suivi des equipements depuis leurs affectation à une structure donnee ou à un chantier jusqu'à sa mise hors usage, l'information, la reliee à des concernes à un temps exempte.

1.2 : Choix Techniques.

Voici les choix techniques qui ont etes adopte pour ce projet :

· Modelisation avec UML ;

· Adoption d'une architecture en 3 couches ;

· PHP pour la programmation des parties dynamiques de notre application;

· MySQL pour le stockage et la gestion de donnees.

· XHTML/CSS pour le rendu de nos pages ou formulaires.

11.2 Recueil des besoins fonctionnels.

Nous avons effectue plusieurs recherches pour identifier au mieux les besoins de notre application web, et ceci afin de repondre aux attentes des utilisateurs.

Nous sommes descendus sur terrain chercher les informations au sein du District de Sante de Lubumbashi plus precisement à la première cellule oil siège l'administration generale des ressources. Cette phase correspond à une recherche sur le terrain pour bien definir le cadre de notre système c'est le perimètre du système.

· Organisation des structures de sante.

Un District de sante se compose de plusieurs Structures (Zones de Sante de References, Centre de Sante de References et autres...), dont chacune est chapeaute par un Medecin Chef de Zone (MCZ), Infirmier Titulaire(IT), dans le cadre specifique d'un Intendant de logistique (logisticien) charge du parc materiel de la Zone de sante et en fait un rapport periodique à l'instance superieure.

23

Chacun d'Intendant voit le cycle de vie ses equipements et materiels sous 2 aspects :

· Le premier aspect consiste à voir le materiel ou l'equipement après sa sortie de l'entrepôt (achat, don...) voir sa ligne de vie durant son integration. Il peut presenter un etat dangereux aux patients et voir même aux travailleurs du metier c'est à l'etat dangereux et devient hors usage.

· Et le second aspect consiste à voir l'equipement en plein utilisation comme etant budgetivore en depense de la structure sanitaire.

n Acquisition des materiels :

La plupart des materiels sont finances par le gouvernement soit une ONGD ou encore les bailleurs de fonds qui renforcent le système de sante et qui en retour attendent un rapport en temps reel et dans certains cas procèdent à l'evaluation de programmes finances, connaître l'etat de besoin de zone de sante, la main mise sur certains equipements (vehicule, radio, etc.) à la fin du projet.

L'intendant gère certains materiels qui n'appartiennent pas à la zone de sante et dont la charge financière revient aux bailleurs de fonds.

n Suivi et effectivite de financement :

Le partenaire est cense connaître l'avancement du projet, les etats de materiels et les charges financières, il est le seul qui peut : aliene, faire un don d'un quelconque du materiel qu'il est bailleur.

L'intendant se trouve dans la jungle donc un sur ordre provenant de plus d'un partenaire qui appuient la zone et chacun ayant droit sur les materiels semblables, le rapport à envoyer et l'inventaire en rendre compte pèse sur celui.

Face à ce cahier des charges, nous nous sommes fixe les objectifs de concevoir une application web qui permettre le prepose (Intendant, Logisticien, bailleur, partenaire...) de faire simple et tout contrôler à partir de son post de travail à tout moment et à tout endroit.

2.1 Identification des acteurs

Nous allons cibler les acteurs susceptibles d'interagir avec le system, mais avant un petit éclaircissement sur le concept acteur.

Definition : un acteur représente l'abstraction du rôle joué par les entités externes (utilisateur, dispositif matériel ou autre système) qui interagissent (envoient des événements) directement avec le système étudié¹¹.

Ces acteurs permettent de cerner l'interface que le système va devoir offrir à son environnement.

" Laurent AUDIBERT : http ://www-lipn.univ-paris13.fr/ audibert/pages/enseignement/cours.htm

Les acteurs identifiés dans un premier temps sont :

Logisticien : est le gérant central au niveau du District de santé, qui gère le parc matériel et d'équipement, il identifie, affecte et fait suivi du matériel ou d'équipement et aussi de son approvisionnement.

Intendant : est une personne qui s'occupe de la logistique dans une structure et établi un inventaire de patrimoine d'une structure sanitaire, il précise l'état actuel du matériel.

BTD : le BTD (Bureau Technique de District) est une équipe cadre émet des stratégies de renforcement, arbitre les moyens financés par le partenaire, le gouvernement ou un achat interne.

Partenaire : est une personne morale ou physique qui renforce le de District de santé en moyens (matériel, équipements, financier) et il peut consulter la répartition des matériels et équipements entre les structures, services, sites, programme, etc. il peut également consulter les entretiens, maintenance, usage de bien don la responsabilité lui revient.

*

1

Administrateur

«Actor»
BTD

SGMERS

1

1

Logsticien

*

Partenaire

Intendant Diagramme de Contexte du SGMERS.DL

Le périmètre du systeme (schéma du contexte du domaine) étant définit c'est-à-dire le positionnement du système en étude de l'ensemble des processus de l'entreprise (District), il ne nous reste qu'à définir les processus métier concernés par notre système en développement et à monter les grandes activités dans le diagramme d'activités.

Diagramme d'activité du processus Métier

LOGISTICIEN

PARTENAIRE

BTD

INTENDANT

Matériel reçus et identifié
[attente d'affectation]

:Etat Besoin
[Attente d'instruction]

[Materiel reparti]

[Réalisation suivi]

Etablir etat besoin

Affectataion
Matériels &
ewuipements

Suivi Matériel

Idententifier
Matériel

[Etat Besoin Evaluée]

Evaluer Faisabilité

[Proposition Ajustée]

[Materiels Alloués]

[Rapport suivi]

Apporter Appui

[Accord]

[Refus]

Send

Organiser les instructions

[Stratégie Organisée]

Instruire Etat Besoin

: Etat Besoin
[Attente d'évaluation]

[Moyen consolidée]

[Appui proposé]

[Matériels arbitrés]

Consolider proposition

[Rapport Suivi]

Arbitrer

:Materiel reçus
[Attende de mis en service]

Mettre a jour Patrimoine

Recevoir Matériel

Mis en service

[Etat du Materiel]

Diagramme d'activité du domaine

26

Identifier liste Materiels
reçus en donnation

[Materiel recu en don]

LOGISTICIEN

Affectation Finale Fin projet

Consulter Effectivite

Matériel & Equipement
Retiré, Offerts

[ Réasation du Projet ]

PARTENAIRE

[Rapport Affecttion finales]

Administrer Donation

BTD

[Materile & equipement reçus]

Recevoir don

INTENDANT

Diagramme d'activité du processus Métier g Fin projet D

2.2 Identification des cas d'utilisation

Le système ayant été ceinturé par rapport au processus du District, il est maintenant question de savoir ce que doit faire le système d'un point de vue métier. Cette activité va aboutir à la définition des cas d'utilisation métier et de leur description générale.

L'identification des cas d'utilisation une première fois, nous donne un aperçu des fonctionnalités futures que doit implémenter le système.

Ce pendant, il nous faut plusieurs itérations pour constituer des cas d'utilisations complets. D'autre cas d'utilisation vont apparaître au fur à mesure de la description de ceuxlà, et l'avancement dans le « recueil des besoins fonctionnels ».

Pour constituer les cas d'utilisation, nous allons considérer l'intention fonctionnelle de l'acteur par rapport au système dans le cadre de l'émission ou de la réception de chaque message. En regroupant cependant ces intentions fonctionnelles en unité cohérentes on obtient les cas d'utilisations.

Cas d'utilisation	Acteurs principaux Secondaires	Messages émis/reçu par les acteurs
Identifier les matériels	Logisticien	Emet : Créer/modifier/annuler une fiche
		d'identité du matériel. Reçoit : la fiche d'identification du
		matériel actualisée
Affecter les matériels	Logisticien	Emet : créer/modifier/supprimer une
		répartition matérielle. Gérer les contraintes liées à une affectation définitive du matériel, affecter les documents, fiches techniques aux intendants, dresse le calendrier. Options : Permuter, déclasser matériels. Reçoit : liste de matériels présents dans la
		mission, les contraintes d'affectation définitive de chaque matériel.
	Partenaire	Reçoit : Consulter les répartitions
		matérielles dans le projet.
	Logisticien	Recoil : liste de matériel sous sa
		responsabiité, les documents administratifs, documents techniques.
Mettre à jour patrimoine	Intendant	Emet : Ajout/Retrait matériel, Suivi usage
		et entretien, temps d'utiisation, créer rapport patrimoine, Sélectionner équipement/son état/sa localisation. Créer une catégorie matérielle. Reçoit : Fiche matériel actualise.
	Logisticien	Reçoit : Consulter les rapports patrimoine.
Apporter Appui	Partenaire	Emet : création, modification, annulation
		proposition moyen, signer accord, allouer moyens.
	BTD	Reçoit : proposition financements.
Etablir état de besoin	Logisticien	Emet : Crée son état de besoins,
		modification/suppression/Ajout d'état de besoin d'une catégorie. Reçoit : liste de matériels et leurs spécifications techniques.
	Partenaire	Reçoit : consulter état de besoin du
		District.
Consulter effectivité	Partenaire	Emet : évaluer réalisation projet, consulter
		entretien, usage équipement, Créer affectation finale, modifier/ ajout/ annuler financement. Reçoit : liste des matériels et équipements,
		factures d'entretiens.
	Logisticien	Reçoit : liste de matériels retirés offert
		comme don.
	BTD	Reçoit : liste de matériels retirés, offert
		comme don.

2.2.1 Diagram m e de cas d'utilisation :

SGMERS

Etablir etat de besoin

BTD

Apporter appui

Indentifier les materiels

Logisticien

Affecter les materieles

Partenaire

Consulter effectivité

Intendant

Mettre a jour Patrimoine

Le processus de développement avec UML étant itératif, ce premier tableau n'est pas définitif car il se peut qu'il change au fuir à mesure de l'avancement du projet.

2.2.2 : Etude de Relations de Cas d'utilisation :

Ainsi pour améliorer le contenu informatif du diagramme de cas d'utilisation, nous appliquons les conventions suivantes :

> Par défaut, le rôle d'un acteur est « principal », si ce n'est pas le cas, il sera indiquer
explicitement que le rôle est « secondaire », sur l'association, du coté de l'acteur.

> Si un acteur a pour rôle unique de consommer les informations du système, sans modifier l'état de celui-ci au niveau du métier, une flèche orientée vers l'acteur sur son association avec le cas d'utilisation justifiera cette particularité.

> Si un acteur à pour rôle unique de fournir les informations au système sans recevoir, représentez cette association en ajoutant une flèche vers le cas d'utilisation.

UML est dépourvu d'un modèle standard pour distinguer graphiquement ces cas. Mais avec les conventions ci hautes répertoriées, notre diagramme devient :

Logisticien

Partenaire

Intendant

«extend*

«Acror»
BTD

SGMERS

Indentifier les materiels

Consulter effectivité

«extend*

Affecter les materieles

«extend*

Apporter appui

«include*

Etablir etat de besoin

Mettre à jour patrimoine

Employé

2.2.3 Structure en Package

Cette phase va permettre de structurer les cas d'utilisations en groupe fortement cohérents, ceci afin de préparer le terrain pour la future phase qui le « découpage en catégorie ».

Un package par définition représente un espace de nommage qui peut contenir

1. Des éléments du modèle.

2. Des digrammes qui représentent les éléments du modèle.

3. D'autres packages.

La structuration des cas d'utilisation se fait par domaine d'expertise métier c'est-à-dire les éléments contenus dans un package doivent représenter un ensemble fortement cohérent et ayant même niveau sémantique.

Diagramme de Package

Partenaire

+ partenaire«actor* + BTD «actor*

+ cu: Consulter effectivité + cu : Apporter appui

Patrimoine

+ Intendant «actor*
+ logisticien«actor*

+ cu :Mettre a jour patrimoine + cu : Identifier Materiel

+ cu : Affecter materiel

+ cu: Etablir etat de besoin

Structure en package de cas d'utilisation

30

2.2.4 : Classem ent des cas d'utilisation : Iterations

L'UP est piloté par les risques : les causes majeures d'échec d'un projet logiciel sont : l'incapacité du système à répondre aux exigences opérationnelles (défaillance de l'architecture technique du système) et l'inadéquation du système de répondre aux attentes des utilisateurs (non respect des exigences fonctionnelles)¹². Pour contrôler toutes causes, nous listons sur un tableau de risques et priorités de cas d'utilisation de notre système.

Cas d'utilisation	Priorité	Risques	Itération
Identifier le matériel	Moyenne	Moyen	4
Affecter le matériel	Haute	Moyen	5
Mettre à jour patrimoine	Haute	Haut	1
Etablir Etat de besoin	Haut	Haut	2
Apporter Appui	Haut	Moyen	3
Consulter effectivité	Moyenne	Basse	6

Tableau des risques et priorités de cas d'utilisations

2.2.5 : Description d~taill~e de cas d'utilisation

Nous donnons ci-dessous la description textuelle détaillée des cas d'utilisation qui nous importe. Il nous nécessaire d'utiliser le style préconisé par A. Cockburn dans son récent ouvrages de référence : « Rédiger les cas d'utilisation efficaces », Eyrolles, 2001.

1. Mettre à jour patrimoine Sommaire d'Identification Titre : Mettre à jour patrimoine

But : permettre l'Intendant d'avoir une vue globale de l'ensemble du matériel sous sa responsabilité.

Résumé : L'Intendant met à jour un inventaire complet du matériel présent sur la mission, ajout, met hors usage les matériels présentant un danger.

Acteur concerné : Intendant (principal) Logisticien (secondaire), Partenaire (secondaire).

Pré-condition :

L'ancienne fiche du patrimoine disponible

¹² Pascal Rocques Franck Vallee : UM L en Action, ed. Eyrolles , ISBN 2-212-09127-3

31

Post-Condition

Fichier patrimoine mis à jour.

Enchainement nominal

1. Construire inventaire

2. Le système affiche les différentes d'inventaire

3. Il choisit le type du matériel et vérifier sa validité par rapport au temps d'usage

4. L'intendant vérifie le les coûts liés à chaque matériel (entretien, déplacement, dépenses).

5. Le système génère l'inventaire sur le tableau récapitulatif

6. L'intendant peut introduire un nouveau matériel

7. Le système averti le logisticien de la nomenclature

8. L'intendant valide l'ajout du patrimoine

Enchainement Alternatif

1. Ajout d'un nouveau matériel : l'Intendant peut ajouter un nouveau matériel sur la liste de patrimoine avant l'inventaire et dans ce cas le système affiche la fiche des matériels et lui invite de valider la mis à jour.

2. Supprimer un matériel : l'Intendant peut retirer un matériel de la liste de patrimoine en signalant la mention (« Hors usage ») et le système demande à l'Intendant d'actualiser la liste.

3. En cas d'un numéro déjà attribué à un autre matériel dans la zone, un message d'erreur est affiché sur l'écran de l'intendant lui avertissant [nomenclature existe déjà]. Extensions :

1.a : le matériel ou l'équipement n'existe pas.

1. le système réaffiche la fiche de tous les matériels et en indiquant les erreurs détectées.

2. l'Intendant acte le fait, corrige les erreurs et le cas d'utilisation reprend l'étape 1 du scénario nominal.

2-3a : le temps d'utilisation expiré.

1. Le système affiche la fiche d'utilisation du matériel ou de l'équipement.

2. L'Intendant procède au retrait du matériel ou de la mise hors usage avec mention (« non adapté au besoin »).

Diagramme de séquences Système (le système vue comme une boîte noire)

: Intendant

Loop

loop

sd:system

_Opt

Fiche d'inventaire de choix affiché

Opt pt

Formulaire de saisi affiché
SaisiMatériel()

Fiche de matériel encours
Mis a jour ficheir

VérifierUsagemateriel()

Choix type Inventaire()

carnet de route affiché
choix materiel()

Carnet entretien liste

RecencerMateriel()

Inventaire listé

Validation()

Ajouter()

MettreHorsUsage()

[Ancienne fiche disponible]

[Rapport actualisé]

: SGMERS

Diagramme de séquences système cu : Mettre à jour patrimoine

2. Établir état de besoin Sommaire d'identification :

Titre : Etablir état de besoin

But : Demander l'aide des moyens qui empêchent le bon déroulement des structures de santé c'est-à-dire bénéficier de l'appui technique et logistique du niveau intermédiaire.

Résume : Rédiger un état de besoin détaillé de toutes les structures sanitaire du District à remettre au BTD pour planifier le budget.

Acteurs : Logisticien (principal) BTD (secondaire).

Description des enchainements :

Pré conditions :

Il existe au moins rapport de patrimoines d'une structure ;

Scenario nominal :

1. Le logisticien consolide tous les rapports de patrimoines de toutes les structures.

2. Le logisticien consulte les spécifications et offres techniques des fournitures, équipements et matériels.

3. Le logisticien renseigne le nombre des dispositifs et équipements médicaux, machine de bureau nécessitant un appui technique et logistique.

4. Le système vérifie la présence et la conformité des données obligatoires et instruit l'état de besoin.

5. Le logisticien procède à la validation de son état de besoin.

Extensions

3-4a. En cas ou les informations concernant toutes les structures sanitaires sont incomplètes.

1. Le système affiche un message d'erreur au logisticien (« les informations incomplètes ») et lui propose de revenir à l'expression de besoin des toutes les structures.

4a. le logisticien modifie la quantité de chacun des équipements et matériels en consultant les exigences ou supprime un dispositif.

1. Le logisticien revalide son état de besoin demande au système d'évaluer

2. Le système évalue l'état de besoin et le cas d'utilisation reprend à l'étape 5 du scénario nominal.

4b. le logisticien exprime un nouvel état de besoin, dans ce cas le cas d'utilisation reprend à l'étape 1 du scénario nominal.

4c. l'aide proposée ne correspond pas aux spécifications techniques et logistiques.

1. Le système consolide la proposition d'aide (voir le cas d'utilisation correspondant) et le cas d'utilisation reprend l'étape 2 du scénario nominal.

2. Post-condition :

3. Un état de besoin disponible.

Exigences non fonctionnelles.

L'Etat de besoin du logisticien est sauvegarder et ne peut être modifié pendant la consultation du visiteur et cela durant sa connexion sur le site web.

Voici Le diagramme de séquence système d'un scénario représentatif :

Dans ce cas notre système est vu comme une boîte noire.

sd : cu Etablir etat besoin

: Logisticien

Exigences techniques et logistiqueslistées

Opt

Opt

Opt

Consolider rapport structure ()
Rapport de structure ^listéConsulter specification d'offres ()

Renseigner spécifications()
L'état de besoin encours

Rediger état ()
Fiche détaillée de besoin

Modifier Quantité()

Supprimer équipement()
Annuler état()

Mis à jour état de besoin

[Rapport inventaire]

[Etat de besoin ]

: SGMERS

Diagramme de séquence Système

3. Apporter Appui

Sommaire d'identification :

Titre : Apporter appui.

But : renforcer le système de santé.

Résumé : apporter les moyens matériels et équipements logistiques, financiers au District de santé pour lui permettre de couvrir l'ensemble de la population par les structures.

Acteur déclencheur : Partenaire (principal) BTD (secondaire).

Description des enchaînements :

Pré-condition :

1. Au moins un état de besoin est disponible.

Enchaînement Nominal

1. Le partenaire consulte l'état de besoin du District de santé.

2. Le partenaire demande de signer un accord.

3. Le partenaire évalue la faisabilité et propose le moyens (matériels, équipement, financier etc. ...).

4. Le système informe le BTD de la proposition de moyens et averti le partenaire des exigences techniques de l'appui.

5. Le BTD analyse la proposition d'appuie et ajuste la proposition selon les exigences techniques.

6. Le partenaire signe son accord et alloue le moyen au District selon les exigences techniques et date fixés.

7. Le système averti le logisticien que les moyens ont étés mis à sa disposition. Extensions :

2-3a : les moyens non adaptés au besoin.

1. Le système averti le partenaire que les moyens proposés ne correspondent pas aux besoins et lui invite de réconsulter l'état de besoin et les exigences techniques. Le cas d'utilisation reprend l'étape 1 du scénario nominal.

2. Le partenaire propose le financement ou modifie la proposition en y joutant les moyens répondant aux spécifications demandées.

Flux alternatifs :

1. Modifier le financement.

Le partenaire peut modifier son avis avant le démarrage du projet ou programme. Dans ce cas le système averti le BTD de la modification de la date de livraison des biens.

2. Annuler le financement.

Le partenaire peut annuler son accord de partenariat à tout moment si les exigences ou la faisabilité ne correspond pas à ses moyens. Dans ce cas le système informe le BTD de l'annulation du contrat.

Post-condition :

Accord signé et solution réalisée.

Diagramme de séquences Système du scénario nominal.

sd : Diagramme séquence CU apporter appui

Sd: Diagramme de séquence Système (cu : ApporterAppui)

: Partenaire

Opt

Opt

opt

ConsulterExigences()
EtaBesoin afficher
SignerAccord()

ExigencesTechniques lister

ModiferFinancement()

PropositionAjustée
AllouerMoyens

Mis a jour Contrat

Accord en cours

AnnulerContrat()

FinancerProjet()

SignerAccord()

PropositionFinancement

[partenaire connecté]

[Appui proposé]

etat besoin dispo

: SGMERS

4 Identifier les matériels Sommaire d'identification :

Titre : Identifier les matériels

But : Normaliser la nomenclature.

Résume : un dossier contenant une fiche d'identification du matériel dès sa réception, et d'éventuels documents accompagnant le matériel ou l'équipement.

Acteurs : Logisticien (principal).

Date de Création : 21/01/2010.

Extensions :

Ce cas d'utilisation commence quand le Logisticien demande au système de créer une nouvelle identification ou une Nomenclature.

1. Le Logisticien fournit un numéro d'identification ou une référence du matériel, Marque, modèle, année, n° de série, exigences techniques, N° de commande, Date d'arrivée, Fournisseur, Fabricant, Garantie, valeur d'origine, Financeur, conditions d'importations.

2. Le système lui affiche tous les cordonnés concernant le matériel en cours d'identification.

3. Le logisticien tien le bon de livraison et vérifie la conformité de livraison ou d'installation et passe à un test de mise en fonction.

4. Le logisticien valide une identification en création.

Le logisticien peut modifier une fiche d'identification du matériel avant son affectation à une mission, un site, département ou à un programme. Toute modification d'une fiche d'identification validée entraine son invalidation, pour ce faire le logisticien doit la validé de nouveau avant son affectation.

Pré conditions :

1. Il existe au moins un nouveau matériel ou équipement.

2. Il existe au moins une documentation accompagnant le matériel. Enchainement nominaux :

1-2a : le numéro fournit existe déjà.

1. Le système lui affiche un message d'erreur (« Le numéro est déjà attribué à un autre matériel ») et le cas d'utilisation reprend l'étape 1 du scénario nominal.

2a : le logisticien modifie la fiche d'identification ou la supprimer.

1. Le logisticien la fiche d'identification du matériel.

2. Le système met à jour la fiche d'identification du matériel.

3a. test du matériel échoué.

1. Le système averti le logisticien du mauvais état du matériel et lui invite de revérifier les spécifications techniques du matériel (notice) avant la réclamation (voir Etablir état de besoin) le cas d'utilisation reprend à l'étape 3 du scénario nominal.

Flux Alternatifs :

Le Logisticien change un Référence du matériel, ou affecte un nouveau numéro d'identification.

2. Modifier une fiche d'identification validée

3. Annuler une identification

1. Modifier une fiche d'Identification en construction :

Description des enchainements :

38

Le logisticien annule ou supprime une fiche d'identification non validée ou une fiche d'identification validée au moins 1 heures son affectation au dépôt.

Ce cas d'utilisation se termine lorsque le logisticien a :

· Amené le matériel à avoir une Nomenclature unique dans une mission, dans un site géographique, une unité de soin, département...

Post conditions :

Le matériel est identifié et la fiche d'identification validée convient aux principes pour tous les matériels présents sur la mission.

Dossier physique crée avec un numéro d'inventaire.

Ce cas d'utilisation se termine lorsque le logisticien valide une fiche d'identification.

Diagramme de séquences système.

Ce diagramme va nous permettre de représenter les interactions entre les objets métier en indiquant la chronologie des échanges.

Nous démontrerons « la ligne de vie » c'est-à-dire l'ensemble d'opérations exécutées par un objet.¹³ Un message reçu par un objet déclenche l'exécution d'une opération.

¹³ Joseph GABAY et David GABAY : UM L2 Analyse et Conception, ed Dunod , Paris 2008 , PP 91-93.

sd: cu IdentifierMatériel

: Logisticien

^altEtattest[TestFonctionnement = OK]
AutoriserIndentification() [TestFonctionnement = Non] RefuserIdentification()

opt

opt

opt

Fiche d'identification mis à jour

Fiche d'identification en cours

Fiche d'identification afficher

Fiche technique afficher Notice d'utilisation afficher

SaisiInformationMatériel()

AnnulerIdentification()

ValiderIdentification()

CréerIdentification()

ModifierFiche()
SupprimerFiche()

TesterFonctionnement()

[materiel et document technique]

:SGMERS

[Fiche identification]

Titre : Affecter le matériel

But : repartir le matériel présent sur la mission de façon optimale.

Résumé : Affecter le matériel ou équipement à un programme, un site ou à une mission Créer, Modifier, Supprimer, Annuler une affectation.

Acteurs : logisticien (principal), partenaire (secondaire)

sd: identification matériel

5 Affecter le matériel :

Sommaire d'identification :

Pré condition :

1 Un matériel disponible

Enchainement nominaux

Ce cas d'utilisation commence lorsque le logisticien demande au système de créer une

nouvelle affectation d'équipement.

Extensions :

2-3a. les exigences du matériel ne correspondant pas aux conditions techniques de la structure bénéficiaire.

1. Le système averti le logisticien de l'état du structure (par ex. pas d'électricité, pas de local) et le cas d'utilisation reprend l'étape 1 du scénario nominal.

3a. le logisticien Modifie la structure ou sélectionne un autre matériel.

1. Le logisticien revalide l'affectation et le cas d'utilisation reprend l'étape 6 du scénario nominal.

2. Le système met à jour l'affectation et informe l'employé dont revient la responsabilité l'affectation finale du matériel.

3b. dépassement quantité.

1. Le système averti le logisticien que le nombre de même matériel dépasse la capacité d'accueil de la structure bénéficiaire.

3c. l'employer non qualifié

1. Le système averti le logisticien que (« l'employé n'est pas qualifié »), lui invite de choisir un employé qualifié ou de le recycler et le cas d'utilisation reprend l'étape 3 du scénario nominal.

1a. quantité matériel insuffisante.

4. Le logisticien rattache les fiches techniques, les pièces et accessoires au matériel c'està-dire les documents techniques (manuel d'utilisation et de dépannage, assurances, recommandation) pour sa bonne utilisation. Il confectionne ensuite les étiquètes de sécurité pour l'utilisation du matériel.

1. Le logisticien sélectionne un matériel obligatoirement le rattaché à sa Fiche d'identification et tous les accessoires possibles du matériel.

2. Le système averti le logisticien des exigences techniques du matériels (puissance, énergie, consommation, exigences techniques) et de la quantité disponible au dépôt.

5. Rattacher les contraintes. Le système prévient l'employer de l'affectation finale de ces matériels en fin de projet selon les contraintes : bailleurs, conditions d'importations.

6. Le logisticien valide une affectation.

3. Le logisticien renseigne le nom de la structure bénéficiaire, motif, la quantité, le Matricule de l'employé de l'organisation recevant le matériel et la date d'affectation et la durée). Il spécifie le projet, site ou la mission bénéficiaire du matériel.

Description des enchainements :

Ce cas d'utilisation se termine lorsque le logisticien a :

· Validée l'affectation,

· Ou bien annule l'affectation. Pré-conditions :

Diminution des matériels au dépôt

Exigences non fonctionnelles : Aucune

Enchaînement Alternatifs

2. Supprimer une affectation : Le logisticien peut supprimer une affectation si les équipements ne sont pas adaptés aux besoins.

4. Annuler une affectation : Le logisticien annule une affectation non encore validée ou validée si celle-ci n'a aucun équipement n'est à la période d'utilisation ou exigences techniques non adaptées au site destinataire.

1. Le système averti le logisticien que (« Quantité insuffisante au dépôt !») lui invite de
choisir un autre matériel et le cas d'utilisation reprend l'étape 1 du scénario nominal.

1. Modifier une affectation en construction ou validée: Le logisticien peut modifier une affectation en cours du projet, permuter les équipements d'un site à un autre.

Description UML (Diagramme de séquence système)

s d : affectation m a t é r i e l

: lo g is tic ie n

a lt E t a t S o c k [ E t a t s t o c k = s u f f i s a n t ]

A u tor is a t io n Affectation

[ E t a t s t o c k = In s u f f is a n t ]

Opt

Opt Opt

R e f u s e r A f f e c t a t io n

E x ig e n c e s Tech n iq u e s lister
S a is ir C o r d o n n é s ( )

S t r u c t u r e B é n é fic ia ir A ffic her
E m lp o y e R e s p o n s a b le lis t é

R attach e r F ic h e Tech n iq u e s ( )

R a t t a c h e r A c c e s o ir e s ( )

C r é e r A ffe c t a t io n ( )

Fiche a ffe c t a t io n e n c o u r s

Fiche m a t é r ie l a ffic h e r
C h o ix M a t e r ie l( )

C o n t a in t e s B a ille u r s ( )

S u p p r m ie r A ffe c t a t io n ( )

M is a jo u r A ffe c t a t io n
A ffe c t e r M a t é r ie l( )

A n n u le r A ffe c t a t io n ( )

M o d ifie r A ffe c t a t io n ( )

[ m a t é r i e l d i s p o n i b l e ]

: S G M E R S

s d : D ia g r a m m e d e séquences s y s t è m e : A f f e t a t io n d e matériel

6 Consulter Effectivité Sommaire d'identification Titre : Consulter Effectivité

But : mettre à la disposition du partenaire un ensemble des tableaux d'affectation et de suivi des matériels, équipements dans les structures.

Acteurs concerné : Partenaire (bailleurs).

Pré-conditions :

- Le partenaire est ^authentifiéScénario nominal (pour chaque structure)

- 1 Consulter avancement du projet.

- 2 le système affiche la liste de tableau de suivi et d'affection.

- 3 Consulter l'utilisation des moyens alloués

- 4 le partenaire saisie les informations d'une structure souhaitée.

- 5 le système affiche les activités réalisées par structure (zone de santé)

- 6 Consulter les charges liées au fonctionnement du projet.

- 7 Affectation finale du matériel (changement de propriété). Extensions :

4a : Erreurs de saisie.

1. Le système affiche la liste de toutes les structures et lui invite de sélectionner une autre structure pour voir les travaux accomplis et le cas d'utilisation reprend l'étape 4 du scénario nominal.

2. le partenaire corrige ré-sélection la structure et le système affiche le tableau de suivi. Flux Alternatifs :

1. Retirer le matériel

Le partenaire peut retirer le matériel ou équipement si la fin du projet et cela par respect du Protocol d'accord.

2. Faire un don

Le partenaire peut initialiser l'affectation finale de l'équipement à la fin du contrat et dans ce cas une Attestation d'affectation finale accompagnée d'un certificat de donation est établie pour en attester.

Diagramme de séquences système.

: P artean ire

sd :system

alt p ro p rie ta ire

Dem an d erTab leau S u ivi (nom structure)

F aireD on ()

C ertificat d e donation liste
S aisirE q u ip em en t()

C on train tes d 'A ffectation finale liste Valid erD on ()

Fiche d e m até riel lité pour le ch ois

[C on train tes = O K ]

R etirerE q u ip em en t()

C on train te d 'affectation affich ées

C h oisirU n Tab leau S u ivi()

Dem an d eU sag eB ien s()

Carnet d 'en tretien listé

[P rop rietaire = false]

R etrait au torisé

R etrait refus é

C h oisE q u ip em en t()

S G M R S

Diagram m e d e sé q u en ce S ytè m e Consulter l'effectiviter

2.2.6 : Modele du domaine.

Le diagramme de classe représente le concept le plus important dans un développement orienté objet. Il permet pendant l'analyse fonctionnelle de représenter les concepts connus des utilisateurs.

A ce niveau, il nous est impératif de procéder à l'identification des concepts du domaine ; plutôt que d'aller aveuglement et nous heurter à la raille du problème à résoudre. Nous prendrons cas d'utilisation un par un et nous poser chacun la question suivante : quels sont les concepts métier qui participent à ce cas d'utilisation ? Afin de construire notre modèle du domaine (classe du domaine).

- i-specifications

- i-intitu le

- i-specif proposees

- i-note comite

- i-statut

-i-service

-i-raison socia le

-i-num

- i-date

Rapport

Exigences

BTD

¹ etab li

*

-i-nom -i-service

- i-adresse

- i-matricu

Inventaire

Intendant

rea lise

1..*

1..*

contien

concerne

*

*

Logisticien

Etat_besoin

*

1

- nom

- adresse

- service

- matricu le

Employé

1

CarnetEntrtien

-i-numero

- i-date

FichedeStock

-i-numero

- i-libe lle

- i-/qte

etab li

1

*

- i-reference

- i-libe lle

Depsense

etab li

1

*

-i-Responsab le

Fic heIdentification

-i-Num -i-ref

travail dans

contien

1

donne lieu

1

rea lise par

1..*

contient

concerne

concerne

1..*

Piece3ustificatif

-i-numero -i-date

1

1..*

*

*

1

1

-i-nom -i-marque

- i-serie

materiel

-i-numero -i-nom

- i-adresse

Entrepot

Strucuture

-i-nom

- i-adresse

etre stocker 1

1..*

*

est lie a

Affectation

-i-num_aff

- i-date

- i-/qte

1

accompagne

1

1

CarnetRoutier

-i-dep ladement

- i-motif

- i-destination

- i-kmdeprat -i-kmarrivee

- i-qtecarburant -i-prix

1..* *

organise

Documentation

1..*

-i-nom -i-numero

Piece

-i-num

-i-date ouverure -i-date depoui llement

Financement

-code_prog -i-date_debut -i-date_fin

Programme

BonLivraison

-i-numero

- i-date

donne lieu

-i-numero

- i-Intitulr

- i-periode

- i-lots -i-devises -i-type

- i-origine

O..*

Accord

1..*

Notice

*

rea lise

1..* 1

signer

emet

1..*

AttestationDonnation

1

1..*

*

Partenaire

-i-nom

- i-adresse

- i-mai l

- i-nationa lite

Fournisseur

-i-nom -i-penom

- i-adresse

- i-mai l

*

*

etab li

*

emet

46

C HAPITRE II : ANALYSE DU SYSTÈM E INFORM ATIQUE

L'analyse nous donne les activités du micro processus (niveau d'abstraction constant). A chaque niveau d'abstraction, un micro processus régit la construction des modèles. UML ne régit pas les activités du micro processus, c'est le principe d'abstraction qui permet l'élaboration itérative et incrémentale des modèles.

11.1 Recueil de besoin du Systeme Informatique.

L'entrée de l'analyse à ce niveau, est la modélisation des éléments et mécanismes principaux du système Informatique. Les éléments du métier (acteurs, cas d'utilisation...) liés au métier de l'entreprise, sont indispensables à la mission du système informatique, ils gagnent à être réutilisés.

II. 1.1 Identification des acteurs du Systeme Inform atique

Un acteur est un utilisateur type qui a toujours le même comportement d'un cas d'utilisation.¹⁴

La question majeure à ce niveau est de savoir qui devient les acteurs identifiés au niveau du métier par rapport au Système Informatique. Nous partons avec le principe que tout travailleur d'interface du système métier devient l'acteur du cas d'utilisation au Système Informatique.

Les « acteurs » du système informatiques identifiés sont :

o Partenaire : un partenaire peut consulter ses financements, consulter ses états de besoins lui adressés par le District, voir les réalisations des différents projets ou programmes dont il est financeur, créer des dons et de financements virtuel.

o Logisticien : le Logisticien établit les états de besoins de zones de santé, il identifie tout matériel présent au District et affecte les matériels et équipements aux structures sanitaires.

o Intendant : l'Intendant crée un nouveau matériel, supprime, et la modifie selon le
besoin de la structure et réalise l'inventaire puis publie les besoins de la structure.

o Administrateur : l'administrateur crée les profils utilisateurs et attribue les droits d'accès.

o Visiteur : le Visiteur crée son compte pour la première fois sur le système

¹⁴ David Gabay, J.Gebay : OpCit , page 62

SYSTEME

Logisricien Administrateur

SGMERS

Intendant

Diagramme de contexte du Système

Partenaire

11.1.2 Identification des messages

On va detailler les differents messages qu'echange le système avec l'exterieur.

Definition : un « Message » représente spécifie la communication unidirectionnelle entre les objets qui transportent de l'information avec l'intension de déclencher une activité chez le récepteur.

Le système emet les messages suivants :

· L'etat d'un materiel

· La fiche de tous les materiels par structure, par programme par site geographique

· La liste de tous les programmes finances

· La date de fin de l'accord lie au projet (expiration du contrat)

· La liste de tous les materiels reçus comme don

· La liste de partenaire ayant appuye le District (Structure, programme,...)

· La duree d'utilisation d'un materiel ou equipement

· Le coût lie à chaque materiel

· La liste de materiels presentant un danger (à mettre hors usage)

· La fiche de tous les materiels affectes à une structure.

· La liste de structures ayant reçus d'appui, d'aide ou des dons pendant une periode donnee.

· L'affectation finale de chaque matériel à la fin du projet (programme) Le système reçoit les messages suivant :

· Les créations, modifications, suppressions des fiches de matériels, d'affectations/par structure

· Les créations des certificats de donation par structure

· Les créations, modifications, suppressions des accords par programme de financement

· Les créations des fiches de financement par partenaire ou bailleur des fonds

· Les créations, modifications des droits d'utilisateur

· La création, modification des états de besoins

· La création des rapports de patrimoines/structure

· Les créations, modifications des comptes de partenariat

II.1.3 Identification des cas d'utilisation du Systèm e Inform atique.

Les « Cas d'utilisation » garantissent la cohérence du processus de développement du système, et permettent de représenter le fonctionnement du Système vis-à-vis des utilisateurs, c'est-à-dire une vie du système dans son environnement extérieur.

La technique de cas d'utilisation est la pierre angulaire de cette étape, elle va nous permettre de préciser l'étude du contexte, en décrivant les différentes actions qu'auront les acteurs d'utiliser le système.

La vision du métier étant différente de celle du système informatique, il nous est impératif de préciser les fonctionnalités du système informatique pour enfin aboutir à une solution purement informatique.

P a rte n a ire

A d m in is tra te u r

(⁷ )

(8 )

V is ite u r

G e re r le P ro fil

« e xte n d »

S G M E R S

In d e n tifie r le materiel

(4 ) « e xte n d » ( 5 )

A ffe c te r le materiel

E ta b lir e ta t d e b e s o in

« e x te n d »

A p p o rte r a p p u i

L o g is tic ie n

« in c lu d e »

( 2 ) « in c lu d e »

(³ )

S 'a u th e n tifie r

« include »

« in c lu d e »

Intendant

M e ttre A Jour
P a trim o in e

Consulter e ffe c tiv ité

(6 )

(1 )

C r e e r Com p te

Voici les fonctionnalités du système retenues :

1. << Mettre à jour Patrimoine » (Intendant)

o Intention : Mettre à jour le patrimoine d'une structure sanitaire nécessaire à ressortir les matériels et équipements amortis ou présentant un danger, les usages, les coûts liés à chaque matériel.

o Actions : créer un nouveau matériel (remplacement des équipements ou matériels, identifier son financeur et tout les contraintes liés), mettre hors usage ou supprimer les matériels à mauvais état (enlever du service un matériel présentant un danger aux malades, personnel...).

2. << Établir État de besoin » (Logisticien)

o Intention : créer un état de besoin du District de santé selon les rapports de structures sanitaire capable à détailler les difficultés de zones et centres de santé.

o Actions : créer un nouveau état de besoin (regroupement de besoins de toutes les structures sanitaires, préciser les spécifications de chaque besoin), modifier ou annuler un état de besoin existant.

3. << Apporter appui » (Partenaire)

o Intention : Financer le District de santé (donner les équipements médicaux, matériels de bureau, véhicules de transports, médicament,...) afin de permettre aux structures sanitaires de couvrir la population avec des soins.

o Actions : Signer un accord (selon le besoin exprimé, proposé le temps, le lot), créer un financer (listé les matériels et équipements), modifier ou annuler un accord existant.

4. << Identifier le Matériel » (Logisticien)

o Intention : Normaliser la nomenclature de l'équipement reçu afin d'avoir une référence unique au district.

o Actions : créer une fiche d'identification (attribué un numéro au nouveau matériel, le nom du financeur, condition d'importation, programme destiné,...), modifier ou annuler une identification existante.

5. << Affecter le matériel » (Logisticien)

o Intention : Repartir les matériels et équipements reçus en don ou achat interne entre les structures sanitaires.

o Actions : Créer une nouvelle affectation (matériel, accessoires, documents techniques), modifier ou annuler une affectation existante.

50

6. « Consulter effectivité » (Partenaire)

o Intention : se rendre compte de l'état du programme financé, de biens et équipements dont la responsabilité lui revient.

o Actions : Consulter les réalisations (la répartition de bien entre les structures, les charges liées à l'existence du matériel), retirer ou faire de dons à la fin du projet.

7. « Créer Compte » (Visiteur)

o Intention : Devenir un partenaire ou bailleur des fonds reconnu au District à qui on peut soumettre un problème, un besoin urgent.

o Actions : S'inscrire (décliner toute son identité), désabonné ou supprimer son compte

8. « Gérer le profils » (Administrateur)

o Intention : limiter les accès au système par les personnes mal intentionné

o Actions : créer des droits d'accès (nom et mot de passe utilisateur), modifier ou supprimer (désactiver) un compte utilisateur existant.

11.2 Realisation de Cas d'utilisation : Analyse 2.1 Identification des classes Candidates

Cette phase prépare l'étape la modélisation Orientée Objet en nous aidant à trouver les classes participantes du future modèle statique. Ces classes n'ont pas pour objectif d'être complètes. Ils servent uniquement à la découverte des classes du modèle d'analyse.

L'objectif ici est de filtrer nos classes redondantes, trop spécifiques ou vagues, qui ne représentent qu'une opération ou un attribut venant du modèle du domaine.

Nous distinguons trois (3) types de classes d'analyses (comme proposé par I. Jacobson) :

- Les « dialogues » qui représentent les moyens d'interaction avec le système.

- Les « Contrôles» qui contiennent la logique applicative.

- Les « Entités» qui sont les objets du métier.

Pour compléter ce travail d'identification, nous allons ajouter les attributs et les méthodes dans les classes d'analyse ainsi que les associations entre elles.

Diagramme de Classe Participante du Cas d'utilisation « Mettre à jour Patrimoine » est donné ci-dessous (l'acteur est relié au Dialogue qui est relié au Contrôle, lui-même relié aux entités).

Les classes candidates sont tirées de la description textuelle du cas d'utilisation et des diagrammes dynamiques représentant celui-ci :

:Intendant

reference : input marque : input model : input

serie : input datefabrication :input garantie : input

+ creerMateriel()

+ modofierMateriel() +supprimerMateriel() +AfficherCout()

EcranMateriel

+creerMateriel()

+ MofierMateriel() +supprimer() +calculerCout() +CalculerTemps usage

ControlMateriel

Partenaire

CarnetEntretient

Depense

*

CarnetRoutier

1..*

1...*

Fournisseur

1

Materiel

1

* 1...*

Programme

*

1

Piece

Digramme de classe Participantes du Cas d'utilisation (« Établir État de Besoin »).

Les classes candidates sont tirées de la description textuelle du cas d'utilisation et des diagrammes dynamiques représentant celui-ci :

EcranEtatBesoin

intitule : input specificaion : input quantite : input

appel d'offre : input

+ Créer()

+ Supprimer() + Modifier()

+ Envoyer()

Diagramme de Classes Participantes (Gas d'utilisation Apporter Appui)

ControlFinancement

modifierQuantite() SupprimerMateriel() EtablirExigences() initialiserFinancement()

EtatBesoin

Accord

donne lieu

Financement

Materiel

1

1..*

1..*

1..*

1..*

Piece

1..*

1

Diagramme des classes Participant ( cu : Apporter Appui)

Diagramme des Classes Participante (Gas d'utilisation Identifier Matériel)

Les classes candidates sont tirées de la description textuelle du cas d'utilisation et des diagrammes dynamiques représentant celui-ci :

: Partenaire

GestionFinancement

Date financement type marche

quntite

modifierFinancement() SupprimerMatériel() annulerFinancement() demanderExigences() Financer()

ControleurEtatBesoin

+ Modifier()

+ Supprimer()

+ Creer()

+ DemanderRapport()

EtatBesoin

Rapport

1..*

1

1..*

Piece

^Materi

1..*

:Logisticien

Exigences

GestionFicheIdentification

creerIdentification() modifierIdentification() annuler()

valider()

ControlFicheIdenificatio

Creer() Modifier() Supprimer()

Bon_Livrais

1

Cocerne

Fiche_Identification

attacher

1..*

Materiel

Notice

1

Concerne

1

1

1..*

1

1..*

1..*

Partenaire

Piece

Fiche Stock

1

Entrepot

: Logisticien

Digramme des classes Participantes (cu : Identifier Materiel)

Diagramme des classes Participantes (Cas d'utilisation Affecter Matériels)

Les classes candidates sont tirées de la description textuelle du cas d'utilisation et des diagrammes dynamiques représentant celui-ci :

: Logisticien

Date quatite durree lieu

CreerAffectation() ModifierAffectation() DesAffecter() Valider()

GestionAffectation

Notice

CanetEntretien

ControlAffectation

CreerAffectation() ModifierAffectation() Supprimer()

Document

CanetRoutier

attacher

Structure

1..*

1

1

Affectation

1..*

Materiel

destnier

FicheIdentification

1

1

1..*

destiner 1..*

1..*

1..*

..* 1

Gerer

1..*

Piece

Programme

Responsable

Diagrmme des Classes Participantes (cu : Affecter Les Matériels)

Diagramme des Classes Participante du Cas d'Utilisation « Consulter Effectivité ».

Les classes candidates sont tirées de la description textuelle du cas d'utilisation et des diagrammes dynamiques représentant celui-ci :

: Partenaire

EcranEffectivité

RetirerM atériel()

Dem anderRealisation() AffectationFinale() RenuvellerContrat()

ControlEffectivite

Supprim erM ateriel() EtablirEffectivite() FaireUnDon() CreerNouveau() EtablirCharges()

PieceJustificative

AttestationDonation

CarnetE ntretien

Financem ent

Depense

1..*

1 1..*

1

1

Concerne

1..*

1..*

Matériel

CatnetRoutier

Affectation

1..*

Piece

Diagramme des Classes Participantes (CU : Consulter Effectivité)

3. Découpage en catégorie

Pour passer à l'analyse Orientée objets, il faut se baser sur les principes de l'Approche Orientée Objet, notamment celle de l'Encapsulation. A cet effet, il faut passer d'une structuration fonctionnelle via les cas d'utilisations à une structuration Objet via les classes et les catégories.

Définition : une Catégorie est un regroupement logique des classes à forte cohérence interne et faible couplage externe.

Le découpage de notre projet en catégorie à donné le résultat suivant :

Materiel « Category»
+ Fiche_Identification + Affectation + Materiel + Piece + Notice + CarnetEntretien +CarnetRoutier +Depense +BonLivraison			Financement « Category»

+ Partenaire + Financement + Accord +AttestationDontion

Besoins

«

Category»

+ EtatBesoin + Exigence +Inventaire + Rapport + Entrepot + Fiche de stock Structure		Fourniseur « Category»

+ Fournisseur

« Category»

+ Structure + Programme +Service + Intendant + Logisticien +Responable

« im port»

« im port»

« im port»

+ F ich e_Id en tificatio n + Affectation

+ Materiel

+ Notice

+ Piece

+ C arn etR o u tier

+ D ep en se

+ C arn etE n tretien

+ B o n L ivraiso n

« im port»

« im port»

Diagramme de Package d'Analyse

Ce diagramme va représenter les différentes dépendances entre les packages d'analyse :

	Materiel « C ategory»			B esoins « C ateg ory»
F ourniseur « C ategory»

+ F o u rn isseu r

+ E tatB eso in

+ Exigence

+ Rapport

+ E n rep o t

+ F ich eS to ck

+ In ven taire

Structure « C ategory»

+ Structure + Programme +Service + Intendant + L o g isticien + R esp o n ab le

F inancem ent

« C ategory»

+ P arten aire

+ F in an cem en t

+ A ttestatio n D o n atio n +Accord

Financement

«Category»

Partenaire

Financements

Accords

signe

«import»

Exigences

contenir

*

«Category»

EtatBesoin

Besoins

«import»

1

travailler dans

1..*

«Ctategory»

Logisticien

Structure

Structures

4. Developpement du Modele Statique

Cette étape va nous permettre de réorganiser les diagrammes de classes Participantes sommairement établis, par rapport au découpage en catégorie, les compléter et optimiser.

Classe «Affectation 0 Catégorie Matériel

Responsable

«Category»

Programme

se trouver^*

Structures

Structure

travailler dans

1..*

1

«import»

Pieces

contenir

1..*

Affectation

«Category»

Materiel

1..*

Materiels

Notices

1..*

«import»

«import»

«Category»

Fiche Stock

CertificatDonation

«Category»

Financements

Besoins

Classe « Etat Besoin 0 Catégorie Besoin

Fic heStock

Inventaire

Structure

travailler

<<Category>>

<<Category>>

Intendant

1

Structures

1..*

1

Besoin

*

Entrepot

Progamme

Ficheldentification

Affectation

<<Category>>

Materiels

Materiel

Piece

Notice

Classe « Matériel 0 Catégorie Matériel

Fic heldentification

CarnetEntretien

concerne

1

<<category>>

1..*

Materiels

Notice

detai ller

Materiel

concerne

BonLivraison

1..*

1

1..*

Piece

<<import>>

<<import>>

<<category>>

Programme

Structure

<<category>>

Fourniseeurs

Fournisseur

Classe « Fiche Identification 0

Accord

signer

1..*

Partenaire

<<Category>>

1 1..*

donne lieu

Partenaires

Financements

realise

1

*

<<import>>

Fic he_identification

Fournisseur

<<Category>>

Fournisseurs

<<import>>

<<Category>>

Materiels

Bon_livraison

<<import>>

Responsable

<<Categiry>> Programmes

mobilise

1

1..*

Classe « Matériel 0

- numero

- date

- numero

- qte

- date

+afficherFournisseur()

Fic heIdnetification

- duree

- date

- destination

+getdateretour()

BonLivraison

Affectation

- reference

- libe lle

+Operation1()

Depende

concerner

1

- langue

Notice

1

est lieu

1

1..*

1..* 1..*

donne lieu

*

1..*

1..*

1

- marque

- mode le

- serie

- datefabrication

- garantie +fabricant

- numer

- date

- montant

Piecelustificative

+afficher()

Materiel

- numero

- designation +affichermaterie

Piece

1

concerne

Concerne

concerne

1..*

1

1

- dep lacement

- motif

- destination

- mkdepart

- kmarrive

- carburant

- prix

- date

+afficher()

CarnetRoutier

- numero

- libe lle

- kmapresentretien

- date

CarnetEntretien

Catégorie « Matériel »

5. Developpement du Modele Dynam ique

Le modèle dynamique constitue l'étape importante de l'analyse. Il s'agit d'une activité fortement couplée avec la modélisation statique.

1.1.1 Identification des scenarios :

Les cas d'utilisation recensés au chapitre précédant décrivaient chacun un ensemble des scénarios. Ces scénarios décrivaient à leur tour une exécution particulière d'un cas d'utilisation du débit à la fin c'est-à-dire un ensemble des enchainements nominaux et alternatifs.

Suivant les itérations définies précédemment dans l'analyse du métier, dans ce chapitre nous allons nous intéressé à la réalisation de ces cas s'utilisation dans le Système Informatique c'est-à-dire avec une vision informatique.

Il faut signaler tous les scénarios possibles ne peuvent être énumérés et décrits du fait qu'ils en existent beaucoup. C'est pour cette raison que nous allons nous intéressé qu'à ceux pertinents.

1° Cas d'utilisation « Mettre à jour Patrimoine » a. Contrat d'Opération Système

Matériel : (Créer, Modifier, Supprimer).

· Créer Matériel :

- Créer Partenaire ;

- Créer Fournisseur ;

- Créer Carnet Entretien

- Créer Carnet Routier

- Créer Pièce

- Créer Notice.

Spécifications :

> Nom : Créer Matériel

> Responsabilité : Créer un nouveau matériel d'après les descriptions fournies sur la documentation, selon les contraintes liées au partenaire, et l'affecté à une zone de santé.

> Référence : Cas d'utilisation Mettre à jour le patrimoine.

> Pré conditions :

- L'ancienne fiche de patrimoine [sinon créer] ;

- Un Carnet Entretien matériel existe [sinon créer];

- Il existe un Carnet Routier [sinon créer] ;

- Une Notice d'utilisation existe [sinon créer] ;

- Un partenaire (origine) financeur existe [sinon créer] ;

- L'intendant soit connecté sur le réseau ;

- Un fournisseur du matériel existe [sinon créer];

- Une structure (zone de santé, centre de santé, programme) existe ;

> Post conditions :

- Une instance du matériel m est créée avec ses attributs (référence, marque, série, garantie, model, date fabrication).

- Un objet pièce est crée avec ses attributs (numéro, nom)

- Un objet fournisseur f est créé avec ses attributs (nom, adresse, téléphone).

- Un objet partenaire p est crée avec ses attributs (nom, adresse, nationalité, émail).

- Une instance c du carnet de suivi matériel est créé avec ses attributs.

- Une instance de la Notice n est créée avec son contenu

- m est relié à un partenaire

- m est relié à un fournisseur

- m est relié à programme (service).

- c est relié à un matériel

- n est attaché à un matériel

Description UML (Créer Matériel)

Par rapport aux diagrammes de séquences établies au niveau supérieur, nous allons ici remplacer le système vu comme boîte noire par un ensemble d'objets collaborant. C'est ainsi que nous utiliserons dans le diagramme suivant trois (3) types de classes (Dialogues, Contrôles et les Entités). Le principe dans ce genre de Diagrammes est que les Objets communiquent en s'envoyant des Messages qui invoquent des opérations (ou méthodes) sur les objets récepteur.

SD:Créer Matériel

: Intendant

opt: erreur saisimateriel

Saisir (reference, marque, serie, fabricant, date, garantie) Initialiser(ref, marque, model, fab.garantie, date.)

CreerMateriel()

Afficher erreur

EcranGeneral : EcranMateriel ContoleurMatériel m : Materiel

activer()

Erreur de saisi

controle saisi()

Confirmation

create()

Partenaire p trouve

get(f)
Fournisseur f trouve

get(p)

get(pg)
Programme Concené pg

ps: Piece

Create()

p : Partenairel

get(n)
Notice concernée trouve

f : Fournisseur

get(c)

CarnetEntretien

pg :Programme

c : Carnet

n : Notice

Diagramme de sequence System ( Opération Systeme : Créer Marériel)

Pour illustration un diagramme de collaboration correspondant est également donné ciaprès. Notez que l'utilisation de la notation graphique UML permettant de représenter une collection d'objets (multi objets « les créations de matériel »), ainsi que la numérotation décimale des messages indiquant leur imbrication.

Digramme de communication d' l'Opération Système : Créer Matériel

:Intendant :EcranGeneral

2. Initialiser(ref, nom, mar, fab, gar )

1. Creer Materiel

4. init(n°, nom)

:EcranPieces

:EcranMateriel

3.1.activer()

1.1.activer()

2.1 Initialiser(ref, nom, mar, fab, gar)

:ControleurMateriel

2.1.1 create(ref,nom, mar,fab, gar)

n : Notice

ps:Piece

f:Fournisseur

p:Partenaire

m:Materiel

pg:Programme

c : CarnetEntretien

cr:CarnetRoutier

. Modifier Matériel : nous prenons le cas où l'intendant veut modifier un matériel dans une zone de santé et cela revient à dire l'intendant doit :

- Modifier Partenaire ;

- Modifier Fournisseur ; - Modifier Pièce

- Modifier Notice ;

Spécifications :

> Nom : Modifier Matériel

> Responsabilité : Modifier un matériel d'après les informations (exigences) fournies par le partenaire, le responsable (employé) de ce par cet de l'usage du matériel.

> Référence : Cas d'utilisation Mettre à jour le patrimoine.

> Pré conditions :

- L'ancienne fiche de patrimoine [sinon créer] ; - Un Carnet suivi matériel [sinon créer];

- Un partenaire (origine) financeur existe [sinon créer] ; - L'intendant soit connecté sur le réseau ;

- Un fournisseur du matériel existe [sinon créer];

- Une structure (zone de santé, centre de santé, programme) existe ;

> Post conditions :

- Un objet matériel m est modifier avec ses nouvelles attributs

(référence, marque, série, garantie, model, date fabrication). - Un objet Pièce ps est modifié avec ses nouveaux attributs.

Digramme de Séquences Système (Op. Modifier Matériel)

En considérant un scénario dans lequel l'intendant modifie un matériel ou un équipement sélectionné, puis demande une mise à jour du patrimoine. Le contrôle reçoit une collection d'attributs passé en paramètre et le passe à l'entité Matériel.

: Intendant

opt modif

ContoleurMatériel m : Materiel

: EcranMateriel

EcranGeneral

ModifierMateriel()

Modifer (materiel)

Affichage erreur

activer()

Initialiser(materiel)

Affichage erreur

set(materiel)

controle saisi()

n : Notice

Set()

Set()

ps : Piece

Diagramme de sequence System (Opération Systeme : Modifer Materiel)

Supprimer Matériel : imaginons l'intendant devant un matériel présentant un danger aux malades et aux personnels soignants, il est obligé de le mettre hors usage.

· Supprimer Partenaire

· Supprimer Fournisseur

· Supprimer Programme

· Supprimer Pièce

Spécifications :

> Nom : Supprimer Matériel

> Responsabilité : Supprimer un Matériel (Mettre hors usage) tout matériels présentant un danger ou non adapté aux besoins selon les informations fournies pour le carnet de suivi d'usage et de la garantie.

> Référence : Cas d'utilisation Mettre à jour le patrimoine.

> Pré conditions :

- Un Carnet suivi matériel ;

- L'intendant soit connecté sur le réseau ;

> Post conditions :

- Un objet matériel m est supprimer avec toutes ses attributs (référence, marque, série, garantie, model, date fabrication).

Digramme d'Interaction (Op. Supprimer Matériel)

Pour terminer la Mise à jour du patrimoine, considérons enfin un scénario dans lequel l'intendant supprime explicitement un matériel du de la fiche du matériel puis la vide totalement.

:Intendant :EcranGeneral

1. Supprimer Materiel

2. Destroy (reference )

:EcranMateriel

1.1.activer()

2.1 Delete(reference)

:ControleurMateriel

2.1.1 Destroy t(reference)

ps : Piece p:Partenaire

f:Fournisseur

m:Materiel

pg:Programme

Digramme de Classe de Conception Préliminaire

En partant du modèle du domaine et des classes participantes, nous allons affiner et compléter le diagramme de classes.

Pour cela nous utiliserons les diagrammes d'interactions que nous venons de réaliser

pour :

v' Ajouter ou préciser les opérations dans les classes (un message ne peut être reçu par un objet que si sa classe a déclaré l'opération publique correspondante).

v' _~Ajouter des types aux attributs et aux paramètres et retours des opérations.

v' Affiner les relations entre classes : associations (avec indication de navigabilité), généralisations ou dépendances.

Diagramme de classes de conception préliminaire

marque model

annee fabrication serie

garantie designation

+Initialiser(ref, marque, serie, datefabrication, fab) + modofierMateriel(reference) +supprimerMateriel()

EcranMateriel

+ CreerMateriel(ref, marque, serie, model, datefabrication, garantie) + MofierMateriel(ref, marque, serie, model, datefabrication, garantie) + Supprimer( ref )

+ Valider()

ControlMateriel

«parametre»

- nom : string

- prenom : string - adresse : string - telephone : string

+getFournisseur() : string

- designation : string - date debit : Date - durée : int

+getDateFin() : Date

Fournisseur

«parametre»

Programme

«parametre»

1..*

- kmdepart - kmarrivee

+getEtatMateriel() : String +getEtat()

- nom : string

- prenom : string - adresse : string - telephone : string

+getPartenaire () : string

CarnetRoutier

Partenaire

ordered

*

1..*

1..*

1

+ creer() : void

+ supprimer() : void

+ modifierPiece : void valider() : void

- reference :string - marque: string - serie : string

- date fabrication - garantie : time - fabricatnt : string - model : string

Materiel

- N° : int

- etat : string

+getEtatMateriel() : String

1..*

CarnetEntretien

1..*

ordered

Piece
numero : int
nom : String

1..*

2° Cas d'utilisation « Etablir Etat de Besoin ».

Parmi tous les scénarios possibles du cas d'utilisation « Etablir Etat de Besoin » (EB), nous avons choisi les suivants :

Qr Scénarios Nominaux :

· EB_N1 : Créer un nouveau État de Besoin Qr Scénarios Alternatifs :

· EB_A1 : Modifier un État de besoin par ajout d'un matériel (pièce, accessoires)

· EB_A2 : Modifier un État de Besoin pour enlèvement d'un matériel

66

~ Scénarios d'exceptions :

· EB_E1 :

Description détaillée des scénarios

~ Scénarios nominaux :

EB_1 : Créer un Nouvel État de Besoin

Le Logisticien donne un nom/mot de passe d'identification.

Il choisit un État de besoin il y inscrit les exigences de chaque matériel ou spécifications, la quantité spécifie la date d'appel d'offre.

Le Logisticien sélection les matériels et équipements faisant partis de l'État de Besoin Le Logisticien choisit un partenaire à soumettre l'État de Besoin.

Pour décrire ces scénarios nous allons intervenir les instances suivantes : - Un acteur Logisticien

- Un État de Besoin en cours de création.

- Un multi-objet représentant l'ensemble des instances de partenaire à qui sera adressé l'État de Besoin.

- Un multi-objet représentant l'ensemble des instances de Matériel de Matériel qui vont être rattaché au nouvel État de besoin.

- Un multi-objet représentant l'ensemble des instances d'Exigence de Matériel qui vont être rattaché au nouvel État de besoin.

- Un multi-objet représentant l'ensemble des instances de Rapport d'inventaire de structure qui vont être rattaché au nouvel État de besoin.

Diagramme de séquence de conception préliminaire « Créer un état de besoin » est également donné ci après

Logisticien tatbESOIN

EcranEtatBesoin CtrlEtatBesoin eb:E

Formulaire Etat Besoin

CreerEtatBesoin()

CreerEtatBesoin()

Formulaire etat besoin affiché

CtrlRapport

SelectionRapport() SelectionnerRapport getRapport()

Rapport

Liste de Rapport trai

Loop

CtrlMateriel

SelectionerMateriel()

Get

Materiel()

SelectionMateriel()

Materiel sélectionné Materiel

getBdgence()

Exigences

CtrlExigence

SelectionnerExigence() SelectionExigence() Exigences Materiels listées

CtrlPartenaire

SelectionerPartenaire() Partenaire() getParteanire()

Palenaire

é]

Eccepti

dgence, parteanie)

create(materiel,exigne, partenaire)

Control saisi

	Loop [Pour chaque partenaire sélection n
	Rattacher(materiel, ed	gence, Partenaire)
	opt erreur Etat besoin
		Erreur
	Erreur Saisi Etat

Diagramme de séquences du scénario « créer un nouvel Etat de besoin »

· EB_A1 : Modifier un État de Besoin par ajout d'un matériel

Le Logisticien donne un nom/mot de passe d'identification

Il sélectionne un Etat de Besoin

Il ajoute un matériel avec ses accessoires Le Logisticien valide son Etat de besoin. Pour décrire ces scénarios nous ferons appel aux instances suivantes :

- Un acteur Logisticien

- Un Etat de Besoin crée en cours du scénario

- Un objet matériel qui va être ajouté à l'Etat de Besoin.

Exception1

: Logisticien eb:EtatbESOIN

EcranEtatBesoin CtrlEtatBesoin

Formulaire Etat Besoin

Liste des Etats de Besoins

SelectionerEtatBesoin()

Exigences du Matérie

Ajouterr(materiel, exigence,)

opt erreur Modification

SelectionerMateriel() CtrlMateriel

SelectionMateriel() GetMateriel()

Materiel

Erreur Saisi Materiel

AttacherExigenc()

AjouterMateriel() Ajout()

Liste de Materiel

SelectionExigence()

Ajouter(materiel, exigence)

Selection() get()

Etat besoin

message

Erreur

set (materiel,exigne,)

Control saisi

message

getExigence()

message

CtrlExigence

Affecter les spécifications
au matériel ajouté

Ajout d'un materiel
à l'Etat de Besoin

Diagramme de séquences du scénario « Modifier un Etat par ajout d'un materiel »

EB_A2 : Modifier un Etat de Besoin Pour enlèvement d'un matériel

Le Logisticien donne un nom/ et mot de passe

Il sélection un matériel

Il enlève la matériel de la l'Etat de besoins

Le Logisticien valide en suite l'Etat de besoin

Pour décrire ce scénario nous allons faire intervenir les instances suivantes :

· Un acteur Logisticien

· Um matériel qui va être désaffecté

· Un Etat de besoin Crée en cour du scénario

getMateriel()

Liste materiel

ajoutMateriel()

Add(materiel)

En cas d'ajout matéreil

afficher

: Logisticien

AjouterMateriel (materiel)

Confirmation

EcranBesoin

Selectionner()

Liste de materiel ajouté

ContolBesoin

:eb EtatBesoin

ContoleurMatériel

getMateriel()

Selectionner()

getMateriel()
Afficher

Liste Materiel dans l'Etat Besoin

Select(materiel)

Select()

Afficher

Enlever(materiel) Destroy(materiel)

En cas d'enlèvement matéreil
de l'Eat de Besoin

Maeriel enleve
EnleverMateriel(materiel)

Diagramme de sequence System (Opération Systeme : Enlever Materiel)

Diagramme de Classe de Conception Préliminaire (Opérations : Créer État Besoin, Modifier État Besoin)

En partant du modèle du domaine et des classes participantes, nous allons affiner et compléter le diagramme de classes. Les diagrammes d'interactions que nous venons de réaliser vont nous permettre à :

· _~Ajouter ou préciser les opérations dans les classes (un message ne peut être reçu par un objet que si sa classe a déclaré l'opération publique correspondante).

· Ajouter des types aux attributs et aux paramètres et retours des opérations.

· Affiner les relations entre classes : associations (avec indication de navigabilité), généralisations ou dépendances.

Ecran_Etat_Besoin

intitule

type marcher date appel

/Quantiite

:Logisticien

+creer() +Modifier() +enlever() +envoyer()

ControlEtatBesoin

+initialiser(intitule : String, typeMarche : String, reference : materiel, Specification : Exigence, DateAppel : Date, partenaire : p) +Mofier() +envoyer(partenaire ): partenaire +enlever(materiel ) : materiel

Partenaire

«parametre»

1

EtatBesoin

«parametre»

getPartenaire(): partenaire

ControlPartenaire

«parametre»

-nom

-prenom

-nationalite -adresse

-email

*

ControlExigence

getExigence() exigence

+valider(partenaire) +valider(exigence)

Materiel

-intitule

-typemarcher -dateappel

1..*

ControlMateriel

+getMateriel(): materiel

{ordered}

1..*

Exigence

-specificationminimale -reference note -specificationpropose

-reference -marque -serie -modele -datefabrication -garantie

Diagramme de Classe de conception préliminaire (Opération Systèmes : CreerEtatBesoin, Modifier)

3° Cas d'utiisation « APPORTER APPUI »

De tous les scénarios possibles du cas d'utilisation «Apporter Appui » (AP), le contrat d'Opérations Systèmes est établi comme suit :

Financement : AP_1 : Créer Financement -- > {créer Accord, Créer Exigences, créer État de Besoin}

AP_1 : Créer Financement

Référence : Cu : Apporter Appui

Pré-conditions

· Le partenaire est authentifié

· Au moins un état de Besoin est disponible [sinon créer]

· Un accord préalablement signé existe [sinon créer]

Post-Conditions :

· une instance du financement f est crée avec ses attributs (date d'ouverture, date

dépouillement)

· un objet accord est crée avec ses attributs (lots, devise, type marché, lieu livraison,

origine

· un objet partenaire p est attaché à un financement

Scénario nominal

· le partenaire consulte un État de besoin et d'éventuelles exigences

· il propose une spécification

· le partenaire signe un accord de partenariat

· il valide son financement

Pour décrire ce scénario, nous allons faire intervenir les objets suivants : - un acteur partenaire

- un objet Financement en cours de scénario

- un objet accord en qui donnera lieu au financement

- un objet matériel qui sera financé

Diagramme d'interaction du scénario nominal « Créer Financement ».

f:Fincancement

:Partenaire

ControlFinancement

:EcranFinancement

Liste des Etats de Besoins

SelectionnerEtatbesoin()

SelectionEtatbesoin()

ControlEtatBesoin

getEtatBesoin()

afficher

Etat de besoin afficher

SignerAccord()

SoliciterAppui()

: ControlExigence

getExigence()

Afficher

Liste des exigences
Finanancer()

financer()

ControlMateriel

getmateriel()

Afficher

Materiel listé

SaisiFinancement ()

initialiser()

create()

Accord de Financement listé

En cas de financement

opt

alt accord

ModifierAccord()

[ Accord = OK]

Modifier()

Afficher

Control loi

set()

Modifcation Accord Autorisé
[ Accord = NO]

En cas de la Mofication du financement

Modifcation non autorisée

message

ValiderFinancer()

Valider

Fiancement validé

Diagramme de sequence du système (Operation créer financement)

2.2.1 creerAccord() EcranFinancement 2.1Erreur

ControleurFinancement

Partenaire

:

2.Initialiser(DateO, DateD)

EcranAccord

initialiser(l, d, t, l, o)

1. CreerFinancement()

2.2.2: nitialiser(l, d, t, l, o)

2.1.1 Pas d'accord

EcranGeneral

2.1 initialiser(dateO, DateD)

1.1 acriver()

2.2.2.1 ErreurSaisi

ControleurAccord

ControleurMateriel

add(a)

2.2.3 Create(DateO, DateD, ref, partnaire, exigence, accord )

a:Accord

f:Fincancement

m : Materiel

e:Exigence

Diagramme de Communication (Creer Financement)

4° Cas d'utilisation : « Identifier le Matériel »

a) Contrat d'Opération Système « Créer-Identification ».

Fiche-Identification : Créer-Identification = (identifier fournisseur, identifier partenaire)

Spécification :

- Nom : Créer Identification

- Responsabilité : créer une nomenclature (identifiant) unique d'un nouveau matériel selon les informations fournies par le fournisseur et le financeur et cela pour tous les matériels présents au District peu importe l'emplacement.

- Référence : Cas d'utilisation « Identifier Matériel ».

- Pré-condition :

> le Logisticien est authentifié et connecté sur le réseau

> au moins un nouveau matériel existe

> il existe un moins un document accompagnant le nouveau matériel > le financeur existe déjà dans la base

- Post-condition :

> Une instance de la Fiche d'identification fi est créée avec ses attributs. > Un objet matériel m est crée avec ses attributs

> m est relié à un financeur (partenaire)

> m est relié à un fournisseur avec ses attributs.

Scénario nominal

· Le Logisticien saisi le nouveau du matériel

· Il attribue un numéro au nouveau matériel

· Il valide l'identification

Flux alternatifs :

· E1 : le numéro déjà attribué ou existe déjà

· Informations concernant le nouveau matériel sont incomplètes

Diagramme de séquence système de l'Opération système « Créer Identification »

Exception 1

Exception 2

: Logisticien fi:FicheIdentification

EcranIdentification CtrlIdentification

Formulaire Identification

saisimateriel()

Opt : Erreur

info incomplete

Op : Erreur

Fournisseur du Matériel

SelectionPartenaire()

selectFournisseur() Selectionfourn()

valideidentfication()

Fiche identification

Partenaire trouvé

Saisinumero()

Erreur numero

initialisermateriel()

selectparteanire()

intidentification() create()

saisinuero()

afficher

afficher

afficher

afficher

getfourn()

getPartenaire

Control numéro

CtrlFournisseur

CtrlParenaire

Rechcerche du fournisseur
du matériel dans la base

Rechcerche du financuer
du matériel base
du matéiel

Ajout d'une nouvelle
identfication

Diagramme de séquences du scénario « Créer une identification du matériel »

Diagramme des classes de conception préliminaire « Créer Identification >>.

Diagramme de classe de Conception Préliminaire

: Logisticien

initi(numéro, te, ad marque, model, part : partenaire, fourn : fournisseur) valider()

init(numero, date) identifier() valider()

numéro

EcranIdentfication

ControlIdentfication

«parametre»

«parametre»

-nom -adresse -telephone

f: Fournisseur

-nom : -prenom: -adresse: -nationaite -adresse mail :

p Partenaire

vialiderparteanire() validerfourni()

-numero - date

fi:FicheIdentification

reference marque

model

serie datefabrication garantie fabricant

afficherEtat() getdateEpiration() getTempsUsage()

m Materiel

{ordered}

5° Cas d'utiisation : « Affecter le Matériels » (AF)

Parmi tous les scénarios possibles du cas d'utilisation « Affecter matériel >> (AF) nous avons retenus les suivants :

Scénario Nominal :

· AF_N1 : Créer une nouvelle Affectation

· AF_N2 : Affecter le matériel à une Structure

Scénario Alternatif :

· AF_A1 : Modifier une affectation pour une structure (zone de santé, centre de santé...)

· AF_A2 : Modifier une affectation par permutation pour libérer d'espace dans une structure.

Scénario d'exception :

· AF_E1 :

· AF_E2 :

Description détaillée des enchainements : Créer un Nouvelle Affectation :

Pré condition :

1. Il existe au moins un matériel disponible avec sa notice d'utilisation

2. Au moins une structure existe dans la base

3. Au moins un Responsable existe dans la structure bénéficiaire

4. Le Logisticien est connecté au réseau

· Le Logisticien donne un nom/mot de passe d'identification

· Il choisit une structure

· Il sélectionne un matériel

· Il crée l'affectation

Post condition

1. Une instance de l'affectation af est crée avec ses attributs (date-

affectation, date-retour, quantité)

2. af est relié à un objet matériel

3. af est relié à un objet Responsable

4. af est relié à un objet Structure

Pour décrire ces scénarios nous allons faire appel aux objets suivants :

· un acteur Logisticien

· un objet affectation en cours de création

· un objet Structure à qui sera destinée l'affectation

· un objet matériel qui sera affecté

Diagramme de séquences de conception préliminaire du scénario « Créer une nouvelle Affectation »

Exception1:
informations
incomplète

af:Affectation

:Lgisticien EcranAffectation : CtrlAffectation

CreerAffectation()

opt ereur

opt

loop

lste de materiel par strucure

CtrlStructure

SelectionStructure(st) selectStructure(st) getStr(st)

Strucure séléctionnée SelectionMateriel(m)

Formulaire sai affiché

Modification reussit

selectionstructure()

selectionmateriel()

Saisiaffectation()

Erreur saisi

Matériel trouvé

Modifier() modification()

Selectmateriel(m) getmateriel(m)^CtrlMateriel

selection()

afficher

init()

control saisi

getquantite(m)

Control saisi

Set()

create()

Encas d'une modification
de l'affectation à une
structure

Encas d'une nouvelle
affectation à une
structure

CtrlStock

:Logisticien :EcranGeneral

2. init ( dateaff,dateret, qter )

1. Créer Affectation()

:EcranAffectation

1.1.activer()

2.1 init(dateaff,dateret, qte)

:ControleurAffectation

2.1.1 Create(dateaff,dateret, qte)

r :Responsable

p :Programme

af:Affectation

s :Structure

m:Materiel

Diagramme de collaboration correspondant :

6° Cas d'utiisation : << Consulter Effectivité » (CE).

Parmi tous les scénarios possibles du cas d'utilisation Consulter Effectivité (CE) nous avons retenus seulement ceux-ci-dessous :

o CE_N1 : Retirer matériel (équipement) o CE_N2 : Créer affectation finale. Spécifications

· Nom : Retirer matériel

· Responsabilité : le Partenaire effectue u retrait des matériels à la fin du projet selon les informations inscrites sur la fiche d'identification du matériel, et peut faire un don à une structure ou à des tiers cela moyennant un certificat de donation.

· Référence : Cas d'utilisation << Consulter Effectivité »

Pré condition

· Il existe au moins une fiche d'identification disponible

Description des enchainements

Le Partenaire donne un nom/et un mot de passe pour l'identification

Il sélectionne les matériels ou équipements dont il veut récupérer à la fin du projet

Il valide son retrait près avoir vérifié son s'il est propriétaire ou pas.

Le Partenaire saisi les informations obligatoires (désignation, quantité, valeur, date de donation, signature du donateur, signature bénéficiaire) pour les fournitures matériels et équipements directement affectés au projet (construction, équipement d'un dispensaire, etc.)

Il crée le certificat de donation en validant ces informations. Post condition

· Une instance du Certificat c est crée avec ses attributs (désignation, quantité, valeurs, date)

· Un objet matériel est crée avec son nouveau propriétaire

: Partenaire EcranEffectivite CtrlEffectivite

Effectivite() effectivite()

Repartition des fourniture

Afficher

getAffectation()

CtrlAffectation

getDepense()

CtrlDepanse

tification

à la fin du projet la fiche
d'identification doit nous
renseigner si le financeur
peut disposer le materiel
ou pas

alt

proprietaire Retirermateriel()	Retirer() getProprietaire()
	Afficher

SelectionMateriel()

Label

CtrlMateriel

m: Materiel

Retrait du materiel par le financeur entraine

la suppression de ces materiel de la liste

de patrimoine

validerretrait()

validate()

Liste de matériel récupéré

afficher

Setmateriel(m) Destroy()

opt

CreerAffectationfinale()

Fiche identification

creeraffdef()
afficher

CtrlFicheIdentification getIdentificationmateriel()

Certificat de donation

Saisidon()

Initdon() c: Certificat

Create()

en cas d'un don offert par

un partenaire, il doit établir

un certificat de donation attestant l'acte

Diagramme de séquences du scénario « Créer une Affecation finale »

selectmateriel()

getmateriel()

Matériel trouvé

7° Cas d'utilisation « Créer Compte » Specifications :

Nom : Créer son Compte

Responsabilité : créer un compte si c'est pour la première fois afin d'avoir les droits d'accès et cela après la lecture des exigences de l'accord du District de santé de Lubumbashi.

Pré-condition :

- Le visiteur est connecté au réseau

Scénario nominal

Cette opération commence quand le partenaire lance la page d'accueil. Le visiteur choisit son nom, son de passe et décline toutes son identité Le visiteur valide son compte

Cette opération se termine lorsque le Visiteur valide son compte en construction.

Exception

Diagramme de séquence système inform atique "Creer son Compte"

Visiteur Ecran General CtrlInscription c:Com pte

S'inscrire()

opt erreur

Ce Compte existe deja

Formulaire d'inscription

SaisiIdentification() initidentification()

ValiderCom pte()

Erreur saisi
Félicitation

valider()

afficher

Control saisi

create()

Diagram m e de classes de conception (Créer com pte)

:Visiteur

nom

prenom adresse mail

siege social nationalite

creer() modifier()

Ecran_Inscription

creer()

modifier() demanderetat() demanderCategorie()

CtrlCompte

afficherEtat() creer() modifier() valider()

-nom_cpt :string -adresse : string -email : string -passwd :string -boitepostal : string

c:Compte

8° Cas d'utilisation « Gérer les Profiles »

Descriptions des ENCHAÎNEMENTS:

Pré-conditions : Aucunes.

Scénario nominal :

Ce cas d'utilisation commence lorsque l'administrateur lance l'application. Enchaînement (a) :

Créer un profil en construction L'administrateur choisit un nom / mot de passe pour le compte.

Il choisit le type de ce compte.

Ce cas d'utilisation se termine lorsque l'Administrateur a validé un profil en construction.

Administrateur : Ecran Compter : ControlCompte : CompteUtilisateur

opt

opt

opt _{ErreurSaisi(login,} pwd)

Compte creer
ModiferCompte(login)

Supprimer(login)

donner incorecte

Validercompte()

supprimer(login)

saisi(login, pwd)

modiffier(login)

afficher

Create(login, pwd)

Destroy(login)

Control login

set(login)

getemployer(login)

message

save
save

: ControlEmployer

Enregistrer

Diagramme de séquence de conception (Operation Céer/Modifier/Spprimer Compte Utilisateur)

C HAPITRE III : CONCEPTION DE L'APPLICATION

1. Conception Detainee

Qui vient juste après une activite qui s'inscrit dans l'organisation definie par la conception preliminaire. Nous allons construire des classes, les vues IHM, les interfaces et les tables qui vont donner une image « prête à coder ». Le modèle logique y est egalement important à ce niveau.

Pour ce faire, nous allons maintenant incorporer dans nos diagrammes le choix d'architecture et les choix technologiques qui vont modifier les classes de conception preliminaire vues au chapitre precedent, les preciser, ajouter de nouvelles classes plus techniques, etc.

N'oublions pas que l'objectif principal du modèle de conception detaillee est de pouvoir être traduit directement en code ; ainsi l'implementation des 3 types de classes d'analyse sera realisee comme suit :

· Le « dialogue » est realise par les pages XHTML et du css pour le rendu : l'idee est egalement d'inserer des instructions de script dans des pages XHTML (le langage peut être PHP). Les pages XHTML peuvent contenir des WebForms, espèces de TagLibs qui genèrent des vues en HTML et qui permettent egalement de placer des contraintes (composant validators) sur les champs de saisie utilisateur. Ces contraintes sont verifiees côte serveur par defaut, mais un module JavaScript permet de prevalider le tout côte client à condition d'utiliser Internet Explorer.

· ,le « contrôle » est implemente soit par des classes associees à PHP (classes
CodeBehind), soit par des classes supplementaires deployees dans l'application web.

· Les entites seront implementees par les classes PHP ensemble avec des objets de Mapping/relationnels constituant une passerelle vers le SGBDR choisit.

Le diagramme des classes de conception détaillée est ci après donne pour l'operation système « Créer Un Nouveau matériel »

· Diagramme des classes de conception détaillées de l'Opération système « Créer un nouveau Matériel »

+activier()

+saisir($ref, $maq, $mod, $serie, $dtefa, $gar, $fab)

Ecran_General

+CreerMaterie l()

+methode: string = "POST" +reference: input +marque: input

+mode le: input +serie: input

+datefab: input +garantie: input +fabricant: input

+submit() +reset()

«pagephp»

«noeudHTML»
form

EcranMateriel

«pagephp»

+load() +refresh()

«pagephp»

PageWeb

+creer($reference, $marque, $serie, $datefab, $garantie, $fabricant, $part) +retirer(Partenaire: partenaire)

+affecter(Structure: s, Programme: p)

+supprimer()

action

+execute(bound$va lues)

PDOStatement

«php lib»

«pagephp»
EcranTraitement

« loca l»

ControlMateriel

«phpclass»

«local»

$SQLcommandes

«phplib»
PDO

« loca l»

- $reference

- $marque

- $mode le

- $serie

- $datefabrication

- $garantier

- $fabricant

+ajouter()

+retirer(Partenaire: partenaire) +affecter(Structure: structure) +Supprimer()

+getduree() +getEtat()

«phpclass»

Materiel

« loca l»

- $numero

- designation

«phpc lass»
Pieces

O..*

1..*

«parametre»

1

«parametre»

- $nom

- prenom

- adresse

- nationa lite

- email

+getnom()

«classphp»
Parteanire

-$nom -$adresse

«phpclass»
Structure

1

Diagramme des Classes de conceptions détaillées Opération Système « Créer Nouveau Matériel ».

EcranG eneral EcM ateriel : :Form : EcranT raitem ent

Logisticien CtrlMateriel m :Materiel

: $bdd:PDO

:$cmsql:PDOStatement

CreerMateriel()

activer()

build()

Ecran Materiel afficher

input(reference, m arque, m odele, serie, datefab, garantie, fabricant, num ero, libelle)

Subm it()

load($POST)

Create()

CtrlExigence get(exigence)

CtrlPartenaire

CtrlStructure

get(partenaire)

get(structure)

CreerMateriel($_POST[ ])

create()

set()

create()

p : Piece

set()

save()

create()

prepareStatem ent()

executeStatem ent()

true

Felicitation

Diagramme de sequence de cnception détaillée(Creer Materiel)

Diagramme des classes de conception détaillée (Opération Système : Créer État de Besoin)

+intitu le: input

+method: string = "POST" +periode: input

+lots: input

+devise: input

+type marcher: input +adresse livraison: input

+ langue d'offre: input +origine: input

+submit() +reset()

+activer()

+saisi($dateo, $datedep) +creeraccord()

EcranFinancement

«pagephp»

form_

«pagephp»

Accod

+date ouverture: input +methode: string = "POST" +date depouillement: input

+submit() +reset()

action

«noeudHTML»

«php lib»

«pagephp»

Traitement

form

PDO

$sq lconnexion

action

oca

-$dateoverture -$datedepouillment

+creer() +modifier() +envoyer() +ajouter() +getdurre()

«classphp»
Financement

+creerfin($dto, $dtedep, $saccord) +envoyer($responsb le: Responsb le) +modifier()

+ajouter($accord)

ControlFinancement

loca

«classphp»

«paramettre»

oca

-$intitu le -$periode -$ lots

-$devise -$typemarche -$adresse livraison -$ langue_offre -$origine

+getperiode()

«classphp»
Accord

-$speicificationminima le -reference note

«classphp»

-$dateappe -$intitu le

-$reference -$marque -$model

-$serie -$datefab -$garantie

+setexigences()

«classphp»
EtatBesoin

«classphp»
Materiel

Exigence

+_&&construct() +prepareStatement($q l: string)

oca

+execute($boundva lues: void)

«phplib»

PDO

«phplib»

PDOStatement

«pagephp»
Ecran_ Affectation

$

$commande sq l $connectionsq

«classphp»
Affestation

«classphp»
Programme

- $code

- $ libe lle

- $datedebit

- datefin

*

+getprogramme()

1

* 1

+date affectation: input +method: string = "POST" +date retour: input +quantite affecte: imput

+submit() +reset()

action

- nom

- adresse

+getnom() +afficherservice()

1..*

1

«paramettre»

loca

+getduree() +creer() +modifier() +va lider() +geta ll()

«pagephp»
Traitement

oca

«classphp»
Structure

- $date

- $dateretour

- $quantite

«parametre»

«classphp»
Responsable

- $matricu le

- $nom

- $prenom

- $fonction

- $adresse

- $emai l

+getreponsab le()

«classphp»

ControlAffectation
+initia liser($dateaff, $dteret, $qte, $materie l, $responsab le, $programme, $structure) +ajouter($materie l: materiel, $structure: structure, $programme) +en lever($materie l) +modifier() +ca lcu lerTemps()
	«paramettre»

· Diagramme des classes de conception détaillées de l'Opération système « Consulter Effectivité»

89

1.1. Conception de la persistance

a. La dérivation du « Modèle Métier » en Modèle logique des données.

La modélisation Relationnelle est la concrétisation d'une modélisation de classes¹⁵. Le modèle des classes est un outil pour la conception et le modèle relationnel est un outil pour la réalisation du système.

Le modèle « métier » définit dans le premier chapitre incorporait ce que les méthodes antérieurs nommaient `'Modèle Conceptuel de Données `' « MCD ». Les possibilités d'expressions d'un modèle UML obligent à compléter les règes de passage du modèle objet vers le modèle logique de données (MLD).

La conception du MLD prend entrée :

· Le modèle sémantique (essentiellement les objets du métier)

· Dans le modèle pragmatique (les objets de nature organisationnelle ou administrative) ;

Modèle (Design) Logique Relationnel (Affecter le Matériel, Identifier le Matériel)

1

matricule :varchar(10) nom : char(25) prenom : char(20) fonction : char(20) adresse : char(30) email : char(30)

1

numero char(5)(PK) designation varchar(20) adresse varchar(30)

1..*

«Table»
Employe

codestr : char(5) designation : char(20) adresse : char(30) service : char(25)

«Table»
Entrepot

«Table»
Structure

1

1

1..*

*

numAff : char(4) (PK) libelle

date : Date

duree : int

qte : int

codepr char(5)(PK) libelle char(30) datedebit : date datefin date

duree int

1..*

«Table»
Affectation

«Table»
Programme

1

1..*

numero int auto deplacement : char(20) motif char(30) destination char(25) Kmdepart int

Kmarrive : int qtecarburant : float

prix int

date : Date

refrence : char (5)(PK) marque:char(20) modele : char(20) serie:char(10)

datefab : Date garantie:int fabricant:char(25) condImport: char(25) valeur : char(20) remarque : text

1..*

«Table»
CarnetRoutier

«Table»
Materiel

1..*

1

numero designation

«Table»
Piece

1..*

1 entree varchar(5) sortie varchar(5) quantire : int date : Date numero int

«Table»
FicheStock

numf : char(5) nom : char(20) prenom : char(20) adesse : char(30) Tel : int

numBon char(10) Quantite : int datlivraison : date

«Table»
Fournisseur

«Table»
BonLivraison

1

1..*

1..* 1

Design Logique de données (Apporter Appui, Établir État besoin)

*

1

1

1..*

«Table»
EtatBesoins

refenote char(5)pk intitule : char(25) dateAppel Date

qte : int

1

«Table»
Materiel

refrence : char (5)PK marque:char(20) modele : char(20) serie:char(10)

datefab : Date garantie:int fabricant:char(25) condImport: char(25) puissance char(25) energie char(10) consommation char(15)

1

1

«Table»
CarnetEntretien

numEnt : int(PK) entretien : char(20) nvellepiec chat(5) datEnt Date

KmapEnt : int

1..*

1..*

«Table»
Financement

intitule : char(20)PK dateOv : date dateDep : date qte : int

1..*

«Table»
Accord

numAc : char(10)PK typemarcher:text devise : char(10) lot : char(10) debuttravaux : date fintravaux : date langueoff : char(15) adresseliv : char(30) origine : char(20) accepte boolean

*

1..*

«Table»
CarnetRoutier

numero int auto(PK) deplacement : char(20) motif char(30) destination char(25) Kmdepart int

1..*

Kmarrive : int qtecarburant : float prix int

date : Date

«Table»
AttestationDonation

designation : char(25) quantite : int valeur : char(20) date : Date

«Table»
Employer

1 matAgent :char(10) PK nom : char(25)

prenom : char(20) fonction : char(20) adresse : char(30) email : char(30)

1

«Table»
Partenaire

codepart:char(5) nom : char(25) prenom : char(20) nationalite : char(25) adresse : char(30) email : char(30) Tel:int

Le modèle de classe fait abstraction des technologies mais avec le MLD, les choix techniques commencent à poindre c'est-à-dire prendre en compte le style de SGBDR.

1.1.1. Les Principes de derivation de rnodèle des classes en M LD sont :

La question qu'on se pose à ce niveau est `'pourquoi ne pas générer le modèle physique de Données, dernier stade de la chaine ? Et la réponse est « Parce que de nombreuses décisions sur le modèle peuvent être prises au niveau logique. D'où le MLD est un produit indispensable pour traiter les thèmes comme l'historisation ou l'intégrité des données, qui ont pu être délaissées par le modèle sémantique (modèle de classes). C'est pour cela nous tiendrons compte de :

r2^- Information d'ordre logique :

· La persistance désirée pour la classe ou l'attribut

· Les noms à données aux tables

· L'option pour la transformation de l'héritage

· La demande de générer automatiquement l'identifiant.

o L'Identifiant : la génération du MLD ne fonctionne que si chaque classe comporte un identifiant, à l'absence de l'identifiant, les connexions entre tables par (Foreign Key) ne peuvent être construite. Pour déterminer l'identifiant, il y a deux façons d'y prendre :

1. La classe peut contenir un ou des attributs identifiants. Ce sont des propriétés naturelles de la classe qui prennent une valeur distinctive sur chaque objet. On élimine, bien

sûr, les attributs artificiels qui auraient pu être créés pour identifier les objets. Ils n'ont pas leur place dans le modèle sémantique.

2. Lorsque la classe n'a pas de propriété naturellement identifiant, le modélisateur demande, par annotation, la génération automatique d'un identifiant. La colonne résultante sera ensuite définie par le concepteur, sur le MLD.

o Les Classes imbriquées : Il est donc nécessaire de supprimer les imbrications du modèle sémantique ou, si cette commodité est maintenue, de préciser la dérivation à adopter dans ce cas.

o Les Contraintes de Noms : les Noms doivent être conforme au standard SQL c'est-à-dire on s'interdit aux les mots réservés.

o L'Héritage : l'héritage présent dans le modèle des classes doit être mis à plats dans les tables selon les options suivantes : Une table par classe, Une seule table ou une table par classe concrète.

o Les associations : une association représente une relation sémantique durable entre deux classes.

o Les agrégations : l'agrégation n'est rien d'autre qu'une association. Elle ne réclame pas une transformation particulière.

o Les compositions : la composition exprime une contrainte forte : la dépendance du composant à l'égard de la classe propriétaire. A ce niveau nous allons absorber les informations du composant correspondant au propriétaire. La condition à vérifier reste la cardinalité de l'association du coté du composant.

o Les attributs ou associations dérivés : les attributs calculés sont à exclure du MLD.

1.1.2 Limite du M odèle Logique de Donnees

Le modèle de données ne saurait assumer tout ce qu'exprime le modèle « métier », sans même parler des opérations. En effet, l'association entre classes montre un comportement dynamique qui échappe au MLD.

Si deux instances sont reliées par un lien d'association et que l'une d'entre elles est supprimée, alors le lien aussi disparaît. Il faut en tirer les conséquences sur la base de données. C'est le genre de comportement que l'on peut confier aux SGBD actuels. On peut aussi préférer l'inscrire dans les services. Cette dernière solution est plus souple et permet de vérifier d'éventuelles contraintes.

Schéma Relationnel de la Base de Données des entités prioritaires

Qr Partenaire (codepart, nom, prénom, nationalité, adresse email) Primary Key codepatenaire

r2^- Fournisseur (numf, nom, prénom, adresse, contact) Primary Key numf

Qr Structure (code-str, désignation, adresse) Primary Key code-str

r2^- Employé (mat_Agent, nom, prénom, fonction, adresse, email, code-structure#)

Primary Key mat_agent

Foreign Key code_str REFERENCES Structure (code_str)

~ Programme (code-prog, désignation, date-début, date-fin, code-str) Pimary Key code_prog

Foreign Key code_str REFERENCES Structure (code_part)

~ Matériel (référence, marque, modèle, série, date-fabrication, garantie, fabricant, code partenaire, code programme, condition d'importation)

Primary Key reference

Foreign Key code_part REFERENCES Partenaire (code_part) Foreign Key code_prog REFERENCES Programme (code_prog)

~ Accord (num Accord, type Marché, devise, lots, début-travaux, fin-travaux, adresse- livraison, langue-offre, origine, code-part, mat_Agent, accepter)

Primary Key num_Accord

Foreign Key code_part REFERENCES Partenaire (code_part)

Foreign Key mat_agent REFERENCES Employer (mat_agent)

~ Financement (num_Accord, refenote, code_prog, date-ouverture, datedépouillement, quantité)

Primary Key num_accord_reference

Foreign Key reference REFERENCES Matériel (reference) Foreign Key num_accord REFERENCES Accord (num_accord) Foreign Key code_prog REFERENCES Programme (code_prog)

r État de Besoin (refenote, intitule, référence, Date Appel, Quantité) Primary Key refenote

Foreign Key reference REFERENCES Materiel (reference)

~ Carnet Routier (num_c, déplacement, motif, destination, km départ, km arrivée, référence, matricule-Agent, qté-carburant, prix, date)

Primary Key num_c

Foreign Key reference REFERENCES Materiel (reference)

Foreign Key mat_agent REFERENCES employer (mat_agent)

~ Pièce (num-p, désignation, référence)

Primary Key num_p

Foreign Key reference REFERENCES materiel (reference)

~ Carnet Entretien (num_ent, référence, entretien, nouvelle-pièce, num-p, date, km-

après-entretien)

Primary Key num_ent

Foreign Key num_p REFERENCES Piece (num_p)

Foreign Key reference REFERENCES Materiel (reference)

~ Pièce Justificative (numj, num-ent, description, montant, date) Primary Key numj

Foreign Key num_ent REFERENCES CarnetEntretien (num_ent)

r^2- Affectation (numAf, reference, code-prog, code-str, mat_Agent, Date, durée, codesv, quantité)

Primary Key numaf

Foreign Key reference REFERENCES Materiel (reference)

Foreign Key code_prog REFERENCES Programme (code_prog)

Foreign Key code_str REFERENCES Structure (code_str)

Foreign Key mat_agent REFERENCES Employer (mat_agent)

Foreign Key code_sv REFERENCES Service (code_sv)

Qr Entrepôt (num-entpot, désignation, adresse, reference, mat_Agent) Primary Key num_entrepot

Foreign Key mat_agent REFERENCES Employer (mat_agent) Foreign Key reference REFERENCES Materiel (reference)

r^2- Fiche Stock (reference, num_entrepot, entrée, sortie, quantité, date) Primary Key referenc_num_entrepot

Foreign Key reference REFERENCES Materiel (reference)

Foreign Key num_entrepot REFERENCES Entrepot (num_entrepot)

Qr Service (num_sv, libelle, code_str)

Primary Key num_sv

Foreign Key code_str REFERENCES Structure (code_str)

1.2. Architecture de l'Application

La technologie orientée objet requiert une architecture, laquelle organise les interactions entre les objets. Souvent ces objets sont regroupés en classes, les classes en domaines et ces domaines en couches qui permettent de représenter l'architecture de l'application.

Ainsi construire une architecture en couche est un critère de qualité dans le cadre d'un développement Objet. Il ne nous reste qu'à déterminer le nombre des couches et leur contenu.

Architecture 3-Tiers :

Pour avoir une architecture robuste, modulable et facile à évolué, il nous est indispensable d'utiliser le principe de « Couche ».

Nous allons donc repartir nos couches de la manière suivante : o Présentation

o Métier

o DAO

<<Layer>>
Presentation

Usage

Usage

<<Layer>>
LogiqUe App licative

		Usage

<<Layer>>
DAO

<<Layer>>
BDD

Architecture 3 - tiers

1.2.1 Les Composants du Systeme

Les diagrammes des composants tombent sous la catégorie des diagrammes d'implémentation, un genre de diagramme qui modélise l'implémentation et le déploiement du système.

Iavigateur

SGBD

<<interface>>

Socket MySQL

+Protoco le = "TCP" +Port = 3306

Serveur Web

Site web

+Protoco le = "HTTP" +Port = 20

+Protoco le = " HTTP" +Port = 21

<<interface>>

Socket de reception

<<interface>>

Socket d'érnission

Un composant représente une entité logicielle d'un système. (fichier de code source, programmes, documents, fichiers de ressource .etc.). Un composant est représenté par une boîte rectangulaire, avec deux rectangles dépassant du côté gauche.

1.2.2. Déploiernent du Systèrne.

Le diagramme de deploiement modelise les composants materiels utilises pour implementer un système et l'association entre ces composants. Des composants peuvent apparaître egalement sur un diagramme de deploiement pour montrer le lieu geographique leur deploiement

Ainsi nous pouvons dessiner des cubes tridimensionnels « Noeud » representant un ensemble d'elements materiels du système.

P C L o g isticien

nom :M ozila F irefox

«A rtefact»
N avig ateu r

TCP/IP

«A rtefact» N avig ateu r

nom :M ozila F irefox

P C Intendant

TCP/IP

H eb erg eu r

«artefact»
w eb S erver

nom : A ppache

version Apache/2.2.14 (W in32) P H P /5.3.2 Version du client M yS Q L: m ysqlnd 5.0.7-dev Extension P H P : m ysql

«artefact»
D B S erver

nom : M yS Q L

Version : 5.1.43-com m unity-log version protocol : 10

S erv eur: IP via TCP/IP

*

TCP/IP

TCP/IP

*

P C L o g isticien

nom :M ozila F irefox

«A rtefact»
N avig ateu r

nom :M ozila F irefox

«A rtefact»
N avig ateu r

In tern au te

D iagram m e de D époilem ent du S ystèm e

1.3. Architecture M atérielle m ise en place

L'architecture que nous allons utiliser est l'architecture Client-serveur.

Le client ici represente le navigateur sur un PC qui emet des requêtes http vers le serveur cible et ce dernier reçoit les elements de la requête et les interprète puis renvoi la page demandee en emettant une reponse http au format html. Par defaut le serveur ne manipule que des fichiers html, donc des pages web statiques. Afin que le serveur sache interpreter le code dans des pages web, nous allons devoir installer un « environnement ». Les pages à interpretees ont d'extensions :

· .PHP : page contenant du code PHP. ;

· .aspx : page contenant du code Net.

· jsp : page contenant du code java.

Pour notre cas l'environnement choisit est PHP d'oil l'illustration ci-dessous :

De ce schéma, nous remarquons que l'environnement est de grande importance pour dynamiser les données des requêtes formulées par le client. Le serveur utilise toujours PHP en lui passant des messages pour les actions inconnues à lui et PHP se rend compte qu'il a besoin de MySQL (SGBD) pour d'autre actions par exemple la sauvegarde des informations du client, ... et ce dernier le fait puis lui restitue le résultat PHP remet au serveur et enfin le client se retrouve devant une page dynamique.

1.4. LE DESIGN PATTERN

Le Design Pattern « MVC » : L'architecture Modèle Vue Contrôleur (MVC) est une méthode de conception pour le développement d'applications logicielles qui sépare le modèle de données, l'interface utilisateur et la logique de contrôle. Ce modèle d'architecture impose la séparation entre les données, les traitements et la présentation, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la vue et le contrôleur :

1.5. CODAGE

L'Application « Espace Matériel »

1.5.1 Structure Générale de l'Application

L'application est découpée en 3 couches distinctes, Présentation, Métier et DAO.

r2^- La couche « Présentation » est chargée de tout ce qui est affichage.

r2^- La couche « Métier » est la logique métier de l'application, elle est le coeur et c'est
elle qui définit toutes les règles régissantes au fonctionnement de l'application.

r2^- La couche « DAO » est l'intermédiaire entre les autres couches et la Base de données.

La Couche Présentation

1. L'Écran Général de « l'Espace Matériel & Équipement »

Écran Accueil du « Logisticien »

Écran Accueil du partenaire

Diagramme d'activité de Navigation

Ce diagramme représente ainsi un ajout important dans l'arsenal des outils de modélisation du concepteur d'application web, puisqu'il fournit la possibilité de décrire précisément et exhaustivement les aspects dynamiques de l'interface utilisateur. La navigation du partenaire est ci après donnée :

www .d istrictslshi.cd

« page »
Page d 'A ccue il

« exception »
N um e ro deja
a ttrib u é

[N um éro d 'identification
déja attribué à un autre
m atériel]

« page »
E cran _Ide ntification

« action »
Identifier

«page »
Fiche d 'id en tifica tio n

« V alid e r»
Identification

« fram e »
Identification

« page »
Pieces e t A ccoire s

«con ne ctor»
Identification

Diagram m e de Navigation du logisticien (Identifier un nouveau matériel)

Diagramme de Navigation correspondant est également donné ci après :

[Proposition ne repond
pas aux spécifications]

"action »
Financer

"page»
E cran Financem ent

"action»
Signer Accord

"page »
Accord de financem ent

www.districtslshi.cd

"page»
Page d'A ccueil

"exception »
spécification
non resptées

"fram e»
Financem ent

"page»
Etat besoin et Exigences
du financem ent

" Valider»
Finanacem ent

"connector»
Financem ent

Diagram m e de Navigation

Ecran Affectation Finale (Don)

Diagramme de Navigation correspondant est également donné ci après :

[il n'est pas
proprietaire]

« ac tio n»
Realisation

w w w .districtslshi.cd

«p age »
Page d 'A cc ue il

« E xc ep tio n»

P arte na ire non prop rie ta ire

«a ction »
R etire r m a té rie l

«p age »
E cra n E ffectivité

«a ction »
V a lid er R e trait

«page »
Fiche d 'id en tifica tio n

«p age »
Affectation

« p age »
D e pen se

[s i le F inanc eur

est proprietaire

«Actiond»u materiel]é Faire un Don

« A c tio n»
S u pp rim e r materiel retité

« p age »
Justifica tif

«page »
Attestation d e Donation

«c on ne ctor»
Affectation Finale

Diagram m e de Navigation (consulter effectiv ité)

La Couche Métier de l'Application aEspace M atériel & équipement D.

L'entité Matériel de la couche Métier

CONCLUSION GENERALE

La Gestion des Équipements constituant un Système d'Information de Gestion des Actifs du Réseau de la Santé et des Services Sociaux (SIGARSSS) a un atout important pour les établissements sanitaires voulant atteindre leurs objectifs avec efficacité (les échanges des informations appropriées, améliorée les processus, et assurer la qualité de soins.

C'est dans cette optique que s'inscrit notre projet de fin d'études dans le quel il nous a été confié la charge de concevoir et réaliser une « Application Web de Gestion des Équipements dans un Réseau de Santé » ; cette Application ayant pour objectif non seulement d'inventorier les dispositifs médicaux dans les différentes structures sanitaires mais aussi la Normalisation de la nomenclature des équipements, l'établissement de la procédure de la mise en service, les affectations finales pour les équipements financés par contrat.

Après avoir fixé les spécifications, nous avons procédé à la conception de l'architecture ainsi que des composants prioritaires de l'application sur la plate forme appropriée en utilisant la technologie la plus fiable et performante sur le marché.

Nous avons aussi implémenté la solution conçue ainsi que ses tests (unitaire, intégration et architecturale) et validations. Les performances lors de cette phase dénotent une bonne exploitation des technologies à notre disposition.

Notre projet se situe en mi-chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et la méthode Agile XP (eXtreme Programming), une approche minimaliste qui fait le tour d'horizon centrée sur le code. Ainsi nous pensons que XP pourra être utilisé dans les projets moyens a grande envergure ne voulant pas tôt concevoir un système très compliqué au départ ou très budgétivore dont on risque de n'avoir pas besoin dans un future proche.

L'élaboration de ce projet nous a permis d'approfondir les concepts à la pointe de la technologie et de tendances actuelles dans le monde professionnel. Une recherche profonde à été indispensable pour essayer de comprendre ces différents concepts. Nous pouvons à ce propos citer l'excellent livre traitant ce sujet qui s'appelle : Développer une application web avec UML 2 aux éditions Eyrolles. Nous a également permis d'enrichir nos connaissances dans les divers domaines comme : l'Orienté Objet, UML, XP, le langage PHP, les objets de connexion (API) comme PDO.

Nous espérons que la lecture de ce mémoire a été agréable et devient votre tasse de

BIBLIOGRAP HIE

I . OUVRAGES

1. Jacques GUYOT : Conception et Réalisation des Bases de Données : de UML à SQL, éd. Système d'Information, 2002, ISBN2-940105-112-X, p/a Gille Falques, 25 chemin de la Californie cb-1222 Vesenaz pp 81.

2. Josephe Gabay, David Gabay : UML2 Analyse et Conception, éd. Dunod Paris 2008

3. L. Fieux : L'informatisation : Une étape Pour l'Humanité, éd. Dunod 1993

4. Pascal Rocques : Le Cahier du Programmeur, 4^ème éd. EYrolles, 2002, 2007, 2008

5. Rocques, P., & Vallée, F. (2004). UML 2 En Action (De l'analyse des besoins à la conception J2EE). Eyrolles.

6. Roques, P. (2006). UML 2 en pratique. Eyrolles.

7. SIMON NORA ALAIN MINC : Informatisation de la société, éd. Paris, 20/Décembre 1976

II. Dictionnaires

1. DISCO ENCARTA 2009

III. NETOGRAPHIE

> www.phpdebutant.org;

> www.merise.developpez.com

> www.mysql.com

> www.siteduzero.com

> Wikipedia. (s.d.). Récupéré sur Wikipedia: http://fr.wikipedia.org/

> Business -Interactif- www.businessinteractif.fr

> www.eyrolles.com

> http://www.dotnetguru.org (Premier article sur la demarche agile au service du e-business)

TABLE DE MATIERE

EPIGRAPHE I

DEDICACES S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S .II

AVANT-PROPOS S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S III

Introduction Générale 1

0. Generalites 7

1. Problem atique 8

2. Hypothese 8

3. Choix Et Interet Du Sujet ........................................................................................................... 10

4. Delimitation Du Sujet ................................................................................................................ 10

5. M ethodes Et Techniques De Recherche.................................................................................... 10

5.1 M ethode .................................................................................................................................. 11
5 .2 Technique ............................................................................................................................... 11

6. Presentation Som m aire Du Travail ........................................................................................ 12

Section I : Présentation du district de sante de Lubumbashi et de la démarche informatique XP
12

C HAPITRE I : ANALYSE DU METIER 14

Section I: presentation du district de sante de Lubumbashi et de la dem arche inform atique XP. 14

I.1. Presentation du District de Sante de Lubumbashi. 14

a. Avant l'Indépendance. 14

b. Après Indépendance. 14

I.2 Presentation de la dem arche inform atique XP 16

Section II. ANALYSE DU METIER. 22

1 : Etude Prelim inaire. 22

II.2 Recueil des besoins fonctionnels. 22

C HAPITRE II : ANALYSE DU SYSTÈM E INFORM ATIQUE 46

II.1 Recueil de besoin du Systeme Inform atique. 46

II. 1.1 Identification des acteurs du Systeme Inform atique 46

II.1.2 Identification des messages 47

II.1.3 Identification des cas d'utilisation du Systeme Inform atique. 48

II.2 Réalisation de Cas d'utilisation
· Analyse 50

2.1 Identification des classes Candidates 50

3. Découpage en catégorie 55

4. Développem ent du Modele Statique 56

5. Développem ent du Modele Dynam ique 59

1.1.1 Identification des scénarios
· 59

C HAPITRE III : CONCEPTION DE L5APPLICATION 82

1. Conception Détaillée 82

1.1. Conception de la persistance 89

1.2. Architecture de l'Application 93

1.3. Architecture M atérielle m ise en place 95

1.4. LE DESIGN PATTERN 96

1.5. CODAGE 96

1.5.1 Structure Générale de l'Application 96

CONCLUSION GENERALE 102

BIBLIOGRAP HIE 103

I . OUVRAGES 103

III. NETOGRAPHIE 103

ANNEXE

1. Administration du Système

Le webmestre (ou webmaster) doit veiller au bon fonctionnement du site Web dont il a la charge. Cela recouvre l'installation du serveur Web et sa configuration. Celle-ci dépend fortement de la nature du site : est-il composé uniquement de pages statiques ou contient-il des pages dynamiques (pages construites par des programmes) ? Quel est le nombre moyen de pages consultées par jour ? Est-ce qu'il contient de l'information sensible qu'il faut sécuriser ?

En fonction des réponses à ces questions, la configuration du serveur va être différente. S'il faut assurer des fonctions de sécurité élevées, il est nécessaire d'ajouter des modules supportant des protocoles sécurisés, comme SSL (Secure Socket Layer). En outre, si le site contient des pages dynamiques, il convient d'autoriser l'exécution de programmes et d'installer des modules permettant l'accès aux bases de données. Enfin, si le nombre de pages consultées est important, il faut lancer plusieurs exemplaires du serveur, de manière qu'ils puissent traiter des requêtes en parallèle.

Pour s'y prendre, voici comment nous avons instruit le serveur de se comporter comme suite :

La configuration doit être adaptée de façon continue à l'utilisation du site. Pour ce faire, le webmestre analyse les fichiers de journalisation des accès, ce qui lui permet de connaître la charge du serveur, la répartition des accès dans le temps, le domaine de provenance des requêtes clients, ainsi que les erreurs d'accès (pages demandées sur le serveur qui n'existent pas ou pour lesquelles le mécanisme d'autorisation a refusé l'accès).

Écran Authentification des Utilisateurs du Systèmes

État de Besoin généré par le Système pour un partenaire

Copyright Ruphin NYAMI . Tous droits réservés. Toute reproduction, même partielle, par quelque procédé et par qui que
ce soit, est interdite sans autorisation écrite préalable de l'éditeur.

Contact Tél [phone]
[phone]
Email : [e-mail]

Nom du document : M em oire_Ruphin3 (Répare).doc

Repertoire : D:\Docum ents and Settings\RUPHIN NYAM I\M es documents

Modele : D:\Docum ents and Settings\RUPHIN NYAM I\Application

Data\M icrosoft\Tem plates\Norm al.dotm

Titre :

Sujet :

Auteur :	ruphin
Mots cles :
Com m entaires :
Date de creation :	23/06/2010	06:20:00
N^° de revision :	42
Dernier enregistr. le :	04/01/1980	08:00:00

Dernier enregistrem ent par : ruphin

Temps total d'édition : 32 079 303 Minutes Dernière impression sur : 13/07/2010 08:06:00
Tel qu'à la dernière impression

Nombre de pages : 109

Nombre de mots : 18 131 (approx.)

Nombre de caracteres : 99 724 (approx.)