|
Conception d'une application web de gestion des équipements et materiels dans un réseau de sante( Télécharger le fichier original )par Ruphin Ruphin NYAMI Institut supérieur de statistiques - Licence 2010 |
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 :
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é11. 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» 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
Matériel reçus et
identifié :Etat Besoin [Materiel reparti] [Réalisation suivi] Etablir etat besoin Affectataion Suivi Matériel Idententifier [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 [Moyen consolidée] [Appui proposé] [Matériels arbitrés] Consolider proposition [Rapport Suivi] Arbitrer :Materiel reçus Mettre a jour Patrimoine Recevoir Matériel Mis en service [Etat du Materiel] Diagramme d'activité du domaine 26
Identifier liste Materiels [Materiel recu en don] LOGISTICIEN Affectation Finale Fin projet Consulter Effectivite Matériel & Equipement [ 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.
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 :
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» 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
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* + 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)12. Pour contrôler toutes causes, nous listons sur un tableau de risques et priorités de cas d'utilisation de notre système.
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 12 Pascal Rocques Franck Vallee : UM L en Action, ed. Eyrolles , ISBN 2-212-09127-3 31 Post-Condition Fichier patrimoine mis à jour. Enchainement nominal
Enchainement Alternatif
1.a : le matériel ou l'équipement n'existe pas.
2-3a : le temps d'utilisation expiré.
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é Fiche de matériel encours VérifierUsagemateriel() Choix type Inventaire() carnet de route affiché 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 :
Description des enchainements : Pré conditions : Il existe au moins rapport de patrimoines d'une structure ;
Scenario nominal :
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.
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 () Renseigner spécifications() Rediger état () Modifier Quantité() Supprimer équipement() Mis à jour état de besoin [Rapport inventaire] [Etat de besoin ] : SGMERS Diagramme de séquence Système 3. Apporter Appui Sommaire d'identification :
Description des enchaînements : Pré-condition : 1. Au moins un état de besoin est disponible.
Enchaînement Nominal
2-3a : les moyens non adaptés au besoin.
Flux alternatifs :
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() ExigencesTechniques lister ModiferFinancement() PropositionAjustée 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 :
Extensions : Ce cas d'utilisation commence quand le Logisticien demande au système de créer une nouvelle identification ou une Nomenclature.
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-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.
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 :
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.13 Un message reçu par un objet déclenche l'exécution d'une opération. 13 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] 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() 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.
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.
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 :
Diminution des matériels au dépôt Exigences non fonctionnelles : Aucune Enchaînement Alternatifs
1. Le système averti le logisticien que («
Quantité insuffisante au dépôt !») lui invite
de 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 t r u c t u r e B é n é fic ia ir A ffic
her 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 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 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.
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 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-service -i-raison socia le -i-num
Rapport Exigences BTD 1 etab li * -i-nom -i-service
Inventaire Intendant rea lise 1..* 1..* contien concerne * * Logisticien Etat_besoin * 1
Employé 1 CarnetEntrtien -i-numero
FichedeStock -i-numero
etab li 1 *
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
materiel -i-numero -i-nom
Entrepot Strucuture -i-nom
etre stocker 1 1..* * est lie a Affectation -i-num_aff
1 accompagne 1 1 CarnetRoutier -i-dep ladement
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
donne lieu -i-numero
O..* Accord 1..* Notice * rea lise 1..* 1 signer emet 1..* AttestationDonnation 1 1..* * Partenaire -i-nom
Fournisseur -i-nom -i-penom
* * etab li
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.14 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 :
14 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 :
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 (7 ) (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 » (3 ) S 'a u th e n tifie r « include » « in c lu d e » Intendant M e ttre A Jour Consulter e ffe c tiv ité (6 ) (1 ) C r e e r Com p te Voici les fonctionnalités du système retenues :
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)
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) :
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
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 :
« im port»
« im port»
Ce diagramme va représenter les différentes dépendances entre les packages d'analyse :
+ F o u rn isseu r
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
+afficherFournisseur() Fic heIdnetification
+getdateretour() BonLivraison Affectation
+Operation1() Depende concerner 1 - langue Notice 1 est lieu 1 1..* 1..* 1..* donne lieu * 1..* 1..* 1
Piecelustificative +afficher() Materiel
Piece 1 concerne Concerne concerne 1..* 1 1
+afficher() CarnetRoutier
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édent 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).
Spécifications :
> Pré conditions :
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) get(p) get(pg) ps: Piece Create() p : Partenairel get(n) 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.
66 ~ Scénarios d'exceptions :
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
Diagramme de séquences du scénario « créer un nouvel Etat de besoin »
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 :
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 Ajout d'un materiel 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 :
Description détaillée des enchainements : Créer un Nouvelle Affectation : Pré condition :
Post condition
Pour décrire ces scénarios nous allons faire appel aux objets suivants :
+ajouter() +retirer(Partenaire: partenaire) +affecter(Structure: structure) +Supprimer() +getduree() +getEtat() «phpclass» Materiel « loca l»
«phpc lass» O..* 1..* «parametre» 1 «parametre»
+getnom() «classphp» -$nom -$adresse «phpclass» 1
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» +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» -$speicificationminima le -reference note «classphp» -$dateappe -$intitu le -$reference -$marque -$model -$serie -$datefab -$garantie +setexigences() «classphp» «classphp» Exigence
+&&construct() +prepareStatement($q l: string) oca +execute($boundva lues: void) «phplib» PDO «phplib» PDOStatement «pagephp»
$ $commande sq l $connectionsq
«classphp»
«classphp»
* +getprogramme() 1
* 1 +date affectation: input +method: string = "POST" +date retour: input +quantite affecte: imput
action
+getnom() +afficherservice()
1..* 1 «paramettre» loca +getduree() +creer() +modifier() +va lider() +geta ll() «pagephp»
oca «classphp»
«parametre»
«classphp»
+getreponsab le() «classphp»
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 classes15. 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 :
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.
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)
r2- 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) r2- 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>>
Usage
<<Layer>>
<<Layer>>
<<Layer>> 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» TCP/IP
«A rtefact» N avig ateu r nom :M ozila F irefox P C Intendant TCP/IP H eb erg eu r «artefact» 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» 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» nom :M ozila F irefox «A rtefact» 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 :
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 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 » « exception » [N um éro d 'identification « page » « action » «page » « V alid e r» « fram e » « page » «con ne ctor» 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 "action » "page» "action» "page » www.districtslshi.cd "page» "exception » "fram e» "page» " Valider» "connector» Diagram m e de Navigation Ecran Affectation Finale (Don)
Diagramme de Navigation correspondant est également donné ci après :
[il n'est pas « ac tio n» w w w .districtslshi.cd «p age » « E xc ep tio n» P arte na ire non prop rie ta ire «a ction » «p age » «a ction » «page » «p age » « p age » [s i le F inanc eur est proprietaire «Actiond»u materiel]é Faire un Don « A c tio n» « p age » «page » «c on ne ctor» 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
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
