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é]
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
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 :
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 :
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 :
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 :
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 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
A.3 Diagramme d’Activité
Diagramme1 demander Analyse
Diagramme2 Prélever Echantillon
Diagramme3 Analyser Echantillon
Diagramme4 Donner Résultat
A.4 Diagramme de Communication
Modélisation statique
B.1 Diagramme de classe
B.3 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.