WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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é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»
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)12. 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

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

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.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]
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

1 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.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 :

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

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 :

· 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

(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
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é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).


· 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)

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 :

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 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 :

· 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)

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>>
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

précédent sommaire suivant