La modélisation fonctionnelle en UML - WikiMemoires

La modélisation fonctionnelle en UML


La modélisation fonctionnelle en UML
Chap. III Analyse des besoins et modélisation en UML
«On fait la science avec de faits, comme on fait une maison avec des pierres : mais une accumulation de faits n’est pas plus une science qu’un tas de pierres n’est une maison» [Henri Poincaré]

III.0 Introduction

L’étape de l’analyse des besoins et de la modélisation est la deuxième phase de cycle de vie du Processus Unifié et l’une des étapes les plus importantes à considérer; en effet si les besoins sont mal spécifiés et exprimés, ou mal analysés, toute la suite devra être refaite, d’où l’importance accordée à cette activité.
Notre objectif dans cette étape est donc d’exprimer les besoins attendus du futur système à développer.

III.1 Analyse fonctionnelle

III.1.1 Définition de besoins de système informatique

III.1.1.1 Spécification des besoins des utilisateurs

Ce système doit permettre d’initialiser une demande d’analyse, de produire et établir une facture et de suivre le prélèvement jusqu’à la fin du processus de l’analyse d’un examen au labo et en fin donner un résultat au bénéficiaire après un contrôle et une validation du résultat par le directeur technique.
Ce système de gestion des clients doit permettre d’automatiser les actions métiers suivantes :

  • 1) Pour le réceptionniste nous avons : Rechercher une analyse; Instruire une analyse; Saisir une facture; Enregistrer le bénéficiaire et/ou la facture; Modifier une facture; Lancer l’impression d’une facture; Créer le bon de paillasse; Produire le résultat après analyse.
  • 2) Pour le préleveur : Enregistrer prélèvement; Ajouter ou attribuer la numérotation.
  • 3) Pour le laborantin : Saisir, Enregistrer le résultat; Instruire l’antibiogramme.
  • 4) Pour le directeur : Rechercher, Contrôler, valider le résultat; Mettre à jour catalogue analyse et résultat.
Cas d’utilisation

A. Demander l’analyse est effectuée par le Bénéficiaire qui doit s’identifier via le bon d’analyse et/ou le bon de soins médicaux;
B. Gérer demande analyse par le réceptionniste en inscrivant le client et en l’enregistrant;
C. Traiter une facture (réceptionniste) les opérations sont les suivantes : saisir, afficher, enregistrer, stocker et/ou imprimer facture, relancer facture;
D. Traiter le bon d’analyse en prélevant l’échantillon (enregistrer, modifier, attribuer un numéro….);
E. Traiter analyse en l’examinant, l’identifiant et produire un résultat;
F. Traiter et le gérer résultat (contrôler, valider, enregistrer, envoyer, afficher, modifier).
Pour traiter une facture d’une analyse et donner le résultat d’un prélèvement, il faut maintenir à jour le système qui doit proposer une fonctionnalité de base de consultation pour prendre en charge la gestion informatisée d’un laboratoire d’analyses de biologie médicale qui s’impose naturellement par sa technologie, sa convivialité et son potentiel fonctionnel.
Les opérations du système informatisé sont : créer, supprimer, modifier, ajouter (CRUD= create, remove, update, delete).

SYSTEME
Opérations Modifier (rechercher, afficher, sélectionner) Créer (saisir, ajouter, valider) Supprimer (rechercher, sélectionner, valider) Update (Mis à jour, ajouter, supprimer) Ajouter (enregistrer, stocker)

Tableau 11 : opération du système

III.2 Modélisation métier

III.2.1 Présentation des acteurs

Cette présentation est détaillée dans le chapitre précèdent à la page 25, sauf que ici, nous prenons soins de citer seulement les acteurs qui sont entre autre le client qui est le bénéficiaire, le réceptionniste, le préleveur, Le bio-technologiste(le laborantin).

III.3 Modélisation en UML

III.3.1 Modélisation fonctionnelle

A.1 Diagramme de cas d’utilisation

Modélisation en UML
Selon UML les diagrammes de cas d’utilisation offre un premier pas pour comprendre les interactions entre le système et ses différents acteurs.
Cas d’utilisation backoffice/chargé clientèle pour la facturation et le résultat du labo-médical et le Front office concerne la demande de l’analyse par le bénéficiaire.
Ce diagramme ci-haut présente le cas d’utilisation de deux profils d’utilisateurs de notre système.

Description de cas d’utilisation

Pourquoi faire est la grande question ici. A ce niveau, les scénarios sont indispensables, car seuls permettent de communiquer facilement et précisément avec les utilisateurs. Ils sont l’occasion d’identifier le contexte d’exécution de l’un ou l’autre des enchainements.
Sommaire d’identification (titre, but, résumé, acteur);
Description de l’enchaînement (précondition, post-condition, scénario nominal, scénario alternatif).

  • Titre : cas d’utilisation concerné;
  • But : l’objectif de ce cas d’utilisation dans le système;
  • Résumé : c’est le résumé du contexte textuel;
  • Précondition : ce sont les conditions nécessaires pour déclencher les enchainements.
  • Post-condition : représente l’événement futur;
  • Scénario nominal : représente les événements produits par l’acteur et le système de la façon sans échec (sans erreur);
  • Scénario alternatif : représente les événements après les erreurs produites par l’acteur et le système.
1. Description textuelle pour le cas d’utilisation gestion de demande d’analyse (réceptionniste)
Sommaire d’identification
Titre : Gestion demande Analyse
But : Permette au réceptionniste de rechercher et répertorier l’analyse et gérer le bon d’analyse et le bon de soins médicaux.
Résume : Gérer une liste d’analyse biologique disponible, renseigner le prix. (Modification, Affichage, l’Ajout, Suppression, Recherché)
Acteurs : Réceptionniste.
Description de l’enchaînement
Pré condition : Présence d’un Bénéficiaire
2. Description textuelle pour le cas d’utilisation gestion facturation (réceptionniste)
Sommaire d’identification
Titre : Traiter facture.
But : Permette au réceptionniste de gérer et d’élaborer une facture.
Résume : Gérer et établir une facture. (Modification, Affichage, l’Ajout, Suppression)
Acteurs : réceptionniste.
Description de l’enchaînement
Pré condition : Présence d’un bénéficiaire Accès autorisé
Post condition: une nouvelle facture sera enregistrée et/ou élaborer.
Scénario nominal :
1. Le réceptionniste choisit «Gestion des factures».
2. Le réceptionniste saisit une facture.
3. le système effectue un contrôle sur les champs obligatoires.
4. Le système vérifie que tous les champs obligatoires sont complets.
5. système effectue un contrôle sur les champs saisis.
6. Le système vérifie que tous les champs obligatoires sont complets.
7. Le système enregistre les informations d’une facture.
8. Le système affiche un message de confirmation.
9. Le réceptionniste lance l’impression.
10. Le système imprime une facture.
Scénario alternatif
1 : Erreur de saisie
Le système affiche une erreur saisie, le scénario reprend au point 1 2 : nature des champs saisie incorrecte
La modification est obligatoire
3. Description textuelle pour le cas d’utilisation gestion de l’échantillon (préleveur)

Sommaire d’identification

Sommaire d’identification
Titre : Gestion de l’échantillon
But : Permette au préleveur d’enregistrer l’échantillon.
Résume : Gérer l’échantillon d’analyse biologique prélevé. (Enregistrer, Modification, Affichage, l’Ajout, Suppression)
Acteurs : préleveur.
Description de l’enchaînement
Pré condition : Présence d’un Bénéficiaire Accès autorisé
Post condition: un nouvel échantillon d’analyse sera enregistré.
Scénario nominal :
1. Le préleveur saisit le login et le mot de passe.
2. Le système vérifie le login et le mot de passe.
3. Le système affiche le menu du préleveur.
4. Le préleveur choisit «Gestion des échantillons ».
5. Le système effectue une recherche.
6. Le système affiche un formulaire d’enregistrement.
7. Le préleveur saisit les informations.
8. Le système effectue un contrôle sur les champs obligatoires.
9. Le système effectue un contrôle sur les champs saisis.
10. Le système vérifie que tous les champs obligatoires sont complets.
11. Le système enregistre les informations.
Le système affiche un message de confirmation
.Scénario alternatif : Erreur d’identification.
Le système affiche une erreur d’identification.
Le scénario reprend au point 1 : nature des champs saisie incorrecte.
L’enchaînement démarre au point 8.
8. Le système signale une erreur des champs saisis.
3 : Champs obligatoires vides. L’enchaînement démarre au point 8
9. Le système signale l’existence des champs obligatoires vide.
11. Le système réaffiche le formulaire déjà remplis.
Le scénario reprend au point 5.

4. Description textuelle pour le cas d’utilisation Traiter le résultat (Bio technicien)

Sommaire d’identification
Titre : Traiter le résultat
But : Permette au Bio technicien d’isoler, d’enrichir et d’identifier le microbe afin de prescrire l’antibiotique et regrouper l’information afin d’établir un résultat et par la suite le donner au bénéficiaire.
Résume : Le Bio technicien rempli un formulaire qui établit un résultat (Enregistrer, Modification, Affichage, l’Ajout, Suppression)
Acteurs : Bio technicien.
Description de l’enchaînement
Pré condition : Accès autorisé
Post condition: un nouvel résultat d’analyse sera enregistré.
Scénario nominal :
1. Le Bio technicien s’authentifie.
2. Le système vérifie le login et le mot de passe.
3. Le système affiche le menu du préleveur.
4. Le Bio technicien choisit «Gestion des résultats ».
5. Le système effectue une recherche.
6. Le système affiche un formulaire d’enregistrement.
7. Le Bio technicien saisit les informations.
8. Le système effectue un contrôle sur les champs obligatoires.
9. Le système effectue un contrôle sur les champs saisis.
10. Le système vérifie que tous les champs obligatoires sont complets.
11. Le système enregistre les informations.
12. Le système affiche un message de confirmation.
Scénario alternatif
1 : Erreur d’identification.
Le système affiche une erreur d’identification.
Le scénario reprend au point 1
2 : nature des champs saisie incorrecte.
L’enchaînement démarre au point 8.
8. Le système signale une erreur des champs saisis.
3 : Champs obligatoires vides.
L’enchaînement démarre au point 8
9. Le système signale l’existence des champs obligatoires vide.
11. Le système réaffiche le formulaire déjà remplis.
Le scénario reprend au point 5.

5. Description textuelle pour le cas d’utilisation gérer le résultat (réceptionniste)

Sommaire d’identification
Titre : Gérer le résultat
But : Permette au réceptionniste d’imprimer un résultat et par la suite le donner au bénéficiaire.
Résume : Le réceptionniste imprime un résultat (Enregistrer, Modification, Affichage, l’Ajout, Suppression)
Acteurs : réceptionniste.
Description de l’enchaînement
Pré condition : Accès autorisé
Post condition: un nouvel résultat d’analyse sera affiché et imprimé.
Scénario nominal :
1. Le réceptionniste s’authentifie.
2. Le système vérifie le login et le mot de passe.
3. Le système affiche le menu du réceptionniste.
4. Le réceptionniste choisit «Imprimer des résultats ».
5. Le système effectue une recherche.
6. Le système affiche un état de sortit du résultat.
7. Le réceptionniste lance l’impression.
8. Le système effectue l’impression.
9. Le système affiche un message de confirmation.
Scénario alternatif
1 : Erreur d’identification.
Le système affiche une erreur d’identification. Le scénario reprend au point 1
2 : nature des impressions non effectuées. L’enchaînement démarre au point 8.
8. Le système signale une erreur d’impression.
9. Le système signale l’existence de file d’attente
11. Le système réaffiche les tâches d’impression.
Le scénario reprend au point 6.

Le diagramme de déploiement
Le diagramme de déploiement ci-haut représente la répartition physique des micros ordinateurs clients connectés à un serveur intranet situé au niveau du LPSP AMI-LABO, et qu’est de même relié au serveur de base de données dont lequel nous souhaitons implémenter notre base de données Gestion de clients concernant la facturation et les résultats.

Modélisation dynamique

A.2 Diagramme de Séquence

Modélisation en UML - Diagramme de Séquence

A.3 Diagramme d’Activité
Diagramme1 demander Analyse

Modélisation en UML - Diagramme1 demander Analyse

Diagramme2 Prélever Echantillon

Diagramme2 Prélever Echantillon

Diagramme3 Analyser Echantillon

Modélisation en UML - Diagramme3 Analyser Echantillon

Diagramme4 Donner Résultat

Diagramme4 Donner Résultat

A.4 Diagramme de Communication

Modélisation en UML - Diagramme de Communication

Modélisation statique

B.1 Diagramme de classe

Diagramme de classe

B.3 Diagramme de deploiement

Modélisation en UML - Diagramme de deploiement
Le diagramme de déploiement ci-haut représente la répartition physique des micros ordinateurs clients connectés à un serveur intranet situé au niveau du LPSP AMI-LABO, et qu’est de même relié au serveur de base de données dont lequel nous souhaitons implémenter notre base de données Gestion de clients concernant la facturation et les résultats.


Abonnez-vous!
Inscrivez-vous gratuitement à la Newsletter et accédez à des milliers des mémoires de fin d’études !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Do NOT follow this link or you will be banned from the site!