|
Modélisation et implémentation d'un système d'information pour la gestion des abonnés en eau potable.( Télécharger le fichier original )par Dickembers Nzinga ISIPA/Matadi - Licence 2014 |
Chapitre V. CONCEPTION DU NOUVEAU SYSTEMELa conception d'un système d'information n'est pas évidente car il faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes permettant de mettre en place un modèle sur lequel on va s'appuyer. La modélisation consiste à créer une représentation virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on s'intéresse Section 1 : Présentation des diagrammes de conception
L'UML 2.0 comporte treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d'information. Ces diagrammes sont regroupés dans deux grands ensembles: 1. Les diagrammes structurels : Ces diagrammes, au nombre de six, ont vocation à représenter l'aspect statique d'un système (classes, objets, composants...). - Diagramme de classe : Ce diagramme représente la description statique du système en intégrant dans chaque classe la partie dédiée aux données et celle consacrée aux traitements. C'est le diagramme pivot de l'ensemble de la modélisation d'un système. - Diagramme d'objet - Le diagramme d'objet permet la représentation d'instances des classes et des liens entre instances. - Diagramme de composant (modifié dans UML 2) Celui-ci représente les différents constituants du logiciel au niveau de l'implémentation d'un système. - Diagramme de déploiement (modifié dans UML 2) : Ce diagramme décrit l'architecture technique d'un système avec une vue centrée sur la répartition des composants dans la configuration d'exploitation. NZINGA ANTOINE Dickembers Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 57 - Diagramme de paquetage (nouveau dans UML 2) - Ce diagramme donne une vue d'ensemble du système structuré en paquetage. Chaque paquetage représente un ensemble homogène d'éléments du système (classes, composants...). - Diagramme de structure composite (nouveau dans UML 2) : Ce diagramme permet de décrire la structure interne d'un ensemble complexe composé par exemple de classes ou d'objets et de composants techniques. Ce diagramme met aussi l'accent sur les liens entre les sous-ensembles qui collaborent. 2. Les diagrammes de comportement : Ces diagrammes représentent la partie dynamique d'un système réagissant aux événements et permettant de produire les résultats attendus par les utilisateurs. Il s'agit de : - Diagramme des cas d'utilisation : Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans l'analyse d'un système. - Diagramme d'état-transition (machine d'état) : Ce diagramme montre les différents états des objets en réaction aux événements. - Diagramme d'activités (modifié dans UML 2) : Ce diagramme donne une vision des enchaînements des activités propres à une opération ou à un cas d'utilisation. Il permet aussi de représenter les flots de contrôle et les flots de données. - Diagramme de séquence (modifié dans UML 2) : Ce diagramme permet de décrire les scénarios de chaque cas d'utilisation en mettant l'accent sur la chronologie des opérations en interaction avec les objets. - Diagramme de communication (anciennement appelé collaboration) : Ce diagramme est une autre représentation des scénarios des cas d'utilisation qui met plus l'accent sur les objets et les messages échangés. - Diagramme global d'interaction (nouveau dans UML 2) : Ce diagramme fournit une vue générale des interactions décrites dans le diagramme de séquence et des flots de contrôle décrits dans le diagramme d'activités. - Diagramme de temps (nouveau dans UML 2) : Ce diagramme permet de représenter les états et les interactions d'objets dans un contexte où le temps a une forte influence sur le comportement du système à gérer. NZINGA ANTOINE Dickembers Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 58 3. Présentation des diagrammes par rapport au système 3.1. Les Cas d'Utilisation (Use case) Un cas d'utilisation est une manière spécifique d'utiliser un système. C'est l'image d'une fonctionnalité du système, déclenchée en réponse à la stimulation d'un acteur externe. Les cas d'utilisation sont une technique de description du système étudié privilégiant le point de vue de l'utilisateur. Il s'agit de la solution UML pour représenter le modèle conceptuel. Les cas d'utilisation décrivent sous la forme d'actions et de réactions, le comportement d'un système du point de vue d'un utilisateur. Les cas d'utilisation servent à structurer les besoins des utilisateurs et les objectifs correspondants du système32. Un diagramme de cas d'utilisation capture le comportement d'un système, d'un sous-système, d'une classe ou d'un composant tel qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d'utilisation, ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d'une vision informatique33. Nous, nous sommes convaincu que cette étape n'est pas négligeable pour produire un logiciel conforme aux attentes des utilisateurs de notre système sous étude. Les use cases permettent de structurer les besoins des utilisateurs et les objectifs correspondants d'un système. Ils centrent l'expression des exigences du système sur ses utilisateurs : ils partent du principe que les objectifs du système sont tous motivés. Le diagramme de Cas d'Utilisation a pour objectif d'identifier les interactions entre les utilisateurs et le système. L'acteur : La première étape de modélisation consiste à définir le périmètre du système, à définir le contour de l'organisation et à le modéliser. Toute entité qui est en dehors de cette organisation et qui interagit avec elle est appelé acteur selon UML. Un acteur est un type stéréotypé représentant une abstraction qui réside juste en dehors du système à modéliser. Pour notre cas, nous avons ressorti les acteurs et leurs messages à savoir : - Chef de service raccordement ; Message : - enregistrement ; - Etablissement devis ; - Demande de constitution du dossier ; 32 DI GALLO Frédéric, Op.cit, p. . 33 Laurent Audibert, UML 2, http://laurent-audibert.developpez.com/Cours-UML, p. 29 (178) Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 59 - abonnés ; Message : - demande de raccordement ; - Dépôt du dossier ; - Souscription de la police d'abonnement ; - Paiement frais d'ouverture dossier ; - Paiement facture du devis ; - Constant de la défectuosité ; - Réception de la facture ; - Apurement de la facture. - Caissier ; Message : - Etablissement reçu ; - Etablissement de bordereau d'encaissement ; - Etablissement de bordereau de remise de fonds ; - Apurement facture ; - Enregistrement paiement. - Secrétaire du SRH Message : - Etablissement facture du devis - Chef du service réseau ; Message : - prospection du terrain ; - Exécution des travaux ; - Rapport journalier. - Chef d'agence : Message : - disposition d'intervention ; - Etablissement rapport. - Chargé du service de recouvrement : Message : - Etablissement liste des apurements ; - Etablissement tableau de suivi encaissement. - Agent recouvreur : Message : - Contrôle de la facture et établissement rapport. - Chargé du Service facturation : Message : - Etablissement de facturation de consommation d'eau; - Chargé de distribution facture : Message : - distribution de la facturation de consommation d'eau; b. Formalisme
NZINGA ANTOINE Dickembers Le cas d'utilisation NZINGA ANTOINE Dickembers Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 60 Diagramme de Cas Utilisation pour la Site Raccordement et Exploitation
Caissier(e) <<Include>> Demande de raccordement <<Include>> Depot du dossier <<Include>> <<Include>> Paiement frais d'ouverture du dossier Souscription de la police d'abonnement <<Include>> Paiement frais facture du devis Constant de la défectuosité <<Include>> <<Include>> Chef de Section Raccordement Enregistrement Client <<Include>> Etablissement devis <<Include>> <<Include>> Etablissement facture Secretaire du SRH Etablissement des recus Rapport journalier <<Include>> Prosfection du terrain Chef de Section Reoeau Execution des travaux <<Include>> <<Include>> Chef d'agence Disposition d'intervation <<Include>> Rapport Figure : 6 Diagramme de Cas d'utilisation pour la site raccordement et exploitation Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 61 Diagramme de Cas Utilisation(Use Cases) pour la facturation de consommation d'eau
Abonné Réception de la facture de consommation Distribution de la facture de consommation Etablissement facture de consommation <<Include>> <<Include>> Chargé de la distribution Chef de Service facturation NZINGA ANTOINE Dickembers Figure : 7 Diagramme de Cas d'utilisation pour la facturation de consommation d'eau Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 62 Diagramme de Cas Utilisation(Use Cases) pour le paiement de frais de consommation Figure : 8 Diagramme de Cas d'utilisation pour paiement frais de consommation d'eau
Abonné Possession de la facture de consommation Etablissement de bordereau d'encaissement Enregistrement sur le chiffrier visa <<Include>> <<Include>> <<Include>> Etablissement de bordereau de remise de fonds Acquit la facture de consommation Paiement de frais de consommation d'eau Demande de montant a payer <<Include>> <<Include>> <<Include>> Chef de Section visa Caissier(e) NZINGA ANTOINE Dickembers NZINGA ANTOINE Dickembers Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 63 Diagramme de Cas Utilisation(Use Cases) pour la site Recouvrement de fonds
Possession de la facture de consommation <<Include>> Paiement de frais de consommation d'eau <<Include>> Demande de montant a payer <<Include>> Enregistrement sur le chiffrier visa Chef de Section visa <<Include>> Abonné Figure : 5 Diagramme de Cas d'utilisation pour le recouvrement de fonds Acquit la facture de consommation <<Include>> Caissier(e) Etablissement de bordereau d'encaissement <<Include>> Etablissement de bordereau de remise de fonds Figure : 9 Diagramme de Cas d'utilisation pour le recouvrement NZINGA ANTOINE Dickembers Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 64 3.2. Le diagramme de classeLes diagrammes de classes représentent un ensemble de classes, d'interfaces et de collaborations, ainsi que leurs relations. Ce sont les diagrammes les plus fréquents dans la modélisation des systèmes à objets. Ils présentent la vue de conception statique d'un système. Les diagrammes de classes, (qui comprennent aussi les classes actives), présentent la vue de processus statique d'un système34. La classe est une description abstraite d'un ensemble d'objets, elle peut être vue comme la factorisation des éléments communs à un ensemble d'objets et décrit conceptuellement le domaine de définition d'un ensemble d'objets par35 :
- un objet est une instance de classe, - un lien est une instance de relation L'UML permet de définir trois types de stéréotypes pour les classes :
Dans un premier temps c'est à cette dernière catégorie de classes que nous allons nous intéresser. Le diagramme de classe va être un outil nous permettant de représenter le modèle du domaine. Le modèle du domaine saisit les éléments les plus importants pour comprendre le contexte du système : 34 Jean Bézivin, Op.cit, p. 40. 35 Laurent Audibert, Op.cit, p. 41. Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 65 - les objets métiers (mis en oeuvre dans une activité professionnelle tels que les commandes, les contrats..) ; - les concepts du domaine à modéliser dont le système doit garder une trace ; - les évènements s'étant produits ou devant se produire qui déclencheront un certain comportement des objets. Agrégation Il s'agit d'une relation entre deux classes, spécifiant que les objets d'une classe sont des composants de l'autre classe. L'agrégation permet donc d'assembler des objets de base, afin de construire des objets plus complexes. Un agrégat peut notamment (mais pas nécessairement) exprimer : ? qu'une classe (élément) fait partie d'une autre (l'agrégat), ? qu'un changement d'état d'une classe entraîne, un changement d'état d'une autre, ? qu'une action sur une classe, entraîne une action sur une autre. Composition La composition est une agrégation forte (agrégation par valeur)36. Les cycles de vie des éléments (les composants) et de l'agrégat sont liés : si l'agrégat est détruit (ou copié), ses composants le sont aussi. A un même moment, une instance de composant ne peut être liée qu'à un seul agrégat. L'héritage est un mécanisme de transmission des caractéristiques d'une classe (ses attributs et méthodes) vers une sous-classe. La spécialisation et la généralisation permettent de construire des hiérarchies de classes. L'héritage peut être simple ou multiple. L'héritage évite la duplication et encourage la réutilisation. Le polymorphisme représente la faculté d'une méthode à pouvoir s'appliquer à des objets de classes différentes. Le polymorphisme augmente la généricité, et donc la qualité, du code. NZINGA ANTOINE Dickembers 36 Laurent Audibert, Op.cit. Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 66 a. Diagramme de class pour l'exploitation et raccordement en eaupotable
Categorie - Id_Categorie - Libelle_categorie : int : String Demande_raccordement + Creer O+ Modifier O+ Supprimer O - Id_demande - Motif - Date_etablissement : int : String : Date 1..1 + Enregistrer O+ Analyser O+ Annuler O+ Envoyer O Appartient
- Matricule - Id_demande - Date_traiter - Observation Traiter : int : int : Date : String 1..*
Paiement - Id_paiement - Motif_paiement - Date_paiement - Montant - Model_paiement : int : String : Date : int : String + Payer O+ Suivant O+ Annuler O+ Envoyer O Concerne 1..1
Monnaie - Id_paiement - Libellé_paiement + Enregistrer O+ Mofier O+ Supprimer O : int : String
- Matricule - Etat_civil - Date_naissance - Date_agagement + Créer () + Supprimer O Agent : String : String : Date : Date
- Id_devis - Libellé_devis - Unité - Quantité - Prix + Enregistrer O+ Modifier O+ Supprimer O+ Calculer O+ Imprimer O + Supprimer O+ Modifier O+ Imprimer O Devis_materiel : int : String : String : int : int - Nom - Postnom - Prenom - Sexe - Adresse - Telephone - Photos + Créer () + Modifier O+ Supprimer O Personne : String : String : String : String : String : String : int : String Prendre en charge 1..*
Abonné - Id_Abonné - Profession : int : String 1..* Efectue + Créer () + Enregistrer O+ Modifier O+ Suivant O
Effectue 1..* 1..1 Correspond
- Id_branchement - Distance - Diametre - Longueur - Nature - Etat - Motif - Date_branchement + Créer () + Vérification () + Exécution () Branchement : int : String : String : String : String : String : String : Date NZINGA ANTOINE Dickembers Figure : 10 Diagramme de Class pour l'exploitation et raccordement Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 67 b. Diagramme de class pour la facturation de frais de consommation d'eau
- Id_abonné - Nom - Prénom - Sexe - Adresse - Profession - Telephone - Photos
Abonné : int : String : String : String : String : String : String : int : String Appartient 1..1 - Id_centre - Nom_centre
Centre : int : String 1..* Recouvre Dispose 0..* Compteur - Id_compteur - Marque - Redevance_compteur - Date_placement - Date_changemant + Créer () + Modifier () + Supprimer () : int : String : int : Date : Date Peut afficher 1..1 - Id_consommation - Index_precedent - Index_Nouveau - Date_prelevement
Consommation : int : int : int : Date Correspond 1..1 - Id_prix - Prix + + + Créer () Modifier () Supprimer () : int : int Prix - Id_agence - Nom_agence
Agence : int : String - Id_paiement - Code_facture - Date_paiement - Libellé_paiement - Montant
Paiement : int : int : Date : String : int 1..1 Depend Figure : 11 Diagramme de Class pour la facture de consommation NZINGA ANTOINE Dickembers Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 68 c. Diagramme de class pour paiement de frais de consommation d'eau
Enregistre Effectue 1..* - Id_paie - Code_facture - Date_paiement - Libelle_paiement - Montant + Créer ø+ Modifier () + Supprimer () Paiement_frais : int : String : Date : String : int - Nom - Prénom - Sexe - Adresse - Telephone - Photos Personne + Enregistrer () + Modifier () + Supprimer () + Imprimer () : String : String : String : String : String : int : String + Enregistrer () + Modifier () + Supprimer () + Imprimer () Id_abonné Profession Abonné : int : String + Enregistrer () + Modifier () + Supprimer () Matricule Etat_civil Date_naissance Date_engagement Agent : String : String : Date : Date 1..* Concerne 1..1
+ Créer ø+ Modifier () + Supprimer () : int : String Id_Monnaie Libelle Monnaie NZINGA ANTOINE Dickembers Figure : 12 Diagramme de Class pour paiement de frais de consommation NZINGA ANTOINE Dickembers Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 69 d. Diagramme de class pour le recouvrement de fonds 1..*
- Id_centre + Consulter () + Ajouter () + Supprimer () Agence Controle
Centre : int : String - Id_centre - Libellé_centre + Consulter () + Ajouter () + Supprimier () 1..1 Appartient - Id_abonné - Profession Abonné : int : String + Enregistrer () + Modifier () + Supprimer () + Imprimer () Organise 1..*
- Id_service + Créer () + Supprimer () + Consulter () Service 1..1 Travail 1..1 Occupe
: String : String : String : String : String : int : String - Nom - Prénom - Sexe - Adresse - Telephone - Photos Personne + Enregistrer () + Modifier () + Supprimer () + Imprimer ()
- Id_fonction + Créer () + Modifier () + Ajouter () Fonction
- Matricule - Etat_civil - Date_naissance - Date_engagement + Enregistrer () + Modifier () + Supprimer () Agent : String : String : Date : Date Enregistre 1..*
Paiement - Id_Monnaie - Num_facture - Date_paiement - Libelle_paiement - Montant : int : String : Date : String : int + Créer () + Modifier () + Supprimer () Figure : 13 Diagramme de Class pour recouvrement de
Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 70 e. Intégration des class Traiter Compteur : int : String : Date 1..* Categorie Personne Traite 1..* : String : String : String : String : String : String : int Fonction Rempli 0..* : int : String : int : Date : Date Id_fonction : int Dispose Appartient Id_abonne Etaciv 1..1 Abonne : int : String 1..1 Occupe Agent : int : String : Date : Date Prendre en charge Depend 1..* 1..1 Travail : int : String : String : int : int : int : String : Date : int : String : int Enregistre 1..1 Service 1..* Concerne Id_service : int 1..1 Appartient Correspond 1..1 Centre Monnaie 1..* Id_agence : int Id_monnaie : int Libellé_agence : String 1..* 1..1 1..* Branchement : int : String : String : String : String : String : String : Date Organise 1..* Agence Recouvre Id_centre : int - Id_compteur - Marque - Redevance_compteur - Date_placement - Date_changement + Créer () + Modifier () + Supprimer () + Afficher () + Créer () + Modifier () + Supprimer () + Calculer () + Imprimer () Devis_materiel Id_devis Libelle_devis Unité Quantité Prix + Créer () + Vérification () + Exécuter () Id_branchement Distance Diametre Longueur Nature Etat Motif Date_brachement + Créer () + Modifier () + Supprimer () + Imprimer () - Id_categorie : int - Libelle_categorie : String + Créer () + Supprimer () + Modifier () + Payer () + Annuler () + Envoyer () + Modifier () Paiement Id_paiement Motif Date_paiement Montant Mode_paiement Num_facture + Enregistrer () + Annuler () + Envoyer () + Analyser () Demande Id_demande Motif Date etablissement + Créer () + Ajouter () + Consulter () + Supprimer () + Créer () + Modifier () + Supprimer () Nom Postnom Prenom Sexe Adresse Mail Telephone - Libellé_centre : String + Créer () + Consulter () + Supprimer () + Ajouter () + Enregistrer () + Supprimer () + Modifier () Matricule Etat_civil Date_naissance Date_engagement - Libelle_monnaie : String + Energistrer () + Modifier () + Supprimer () + Enregistrer () + Modifier () + Observation () + Annuler () : String : int : Date : String - Libellé_fonction : String + Créer () + Modifier () + Supprimer () Matricule Id_demande Date_traiter Observation - Libellé_service : String + Créer () + Modifier () + Supprimer () Peut afficher 1..1 Consommation : int : int : int : Date Id_consommation Index_precedent Index_nouveau Date_prelevement + + + Créer () Modifier () Supprimer () Correspond 1..1 Prix Id_prix Prix : int : int + Créer () + Modifier () + Supprimer () NZINGA ANTOINE Dickembers Figure : 14 Intégration de class NZINGA ANTOINE Dickembers Modélisation et l'implémentation d'un système informatique pour la gestion des bonnes 71 |
|
