L’application de base de données gestion des clients

L’application de base de données gestion des clients

Conception, développement et réalisation de l’application – Chap. IV

«Le commencement de toutes les sciences, c’est l’étonnement de ce que les choses sont ce qu’elles sont» [Aristote]

IV.0 Introduction

Dans la démarche de Processus Unifié, la phase de conception suit immédiatement la phase d’Analyse, par ailleurs la conception de logiciel est un art qui nécessite de l’expérience, et elle consiste à traduire les besoins en spécifiant comment l’application pourra les satisfaire avant de procéder à sa réalisation.

En effet, dans ce chapitre nous essayons d’étendre la représentation des diagrammes effectués au niveau de l’analyse en y intégrant les aspects techniques plus proches des préoccupations physiques et c’est avec l’Entreprise Architect.

Voici l’image d’une EA

A ce stade du processus, les cas d’utilisation sont terminés, le problème a été d’analyser en profondeur; nous avons défini une conception mieux appropriée aux besoins de l’application.

Nous pouvons alors entreprendre la dernière activité du Processus Unifié qu’est de même composé de deux parties (implémentation et test), ayant comme objectif d’aboutir à un produit final, exploitable par les utilisateurs.

Dans cette phase nous allons présenter l’environnement de développement que nous avons utilisé, l’architecture matérielle mise en place, implémenter tous les cas d’utilisation, et enfin les tester

Pour réaliser notre application, nous avons utilisé le langage de programmation C# dédié à la création des formulaires, interfaces utilisateurs et les états des sorties, celui-ci nous l’avons manipulé dans un environnement de développement, qui est largement compatible avec SQL/SERVER.

IV.2 Les outils des développements

IV.2 .1 Sql/Server

SQL/Server est un système de gestion de base de données (SGBD).

Selon le type d’application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde, autant par le grand public (applications de BD principalement) que par des professionnels, en concurrence avec Oracle et MySQL.

SQL/Server est un serveur de bases de données relationnelles SQL développé dans un souci de performances élevées en lecture, ce qui signifie qu’il est davantage orienté vers le service de données déjà en place que vers celui de mises à jour fréquentes et fortement sécurisées.

Il est multithread et multi-utilisateur.

Microsoft SQL Server: édité par Microsoft, on l’utilise souvent en combinaison avec ASP .NET, bien qu’on puisse l’utiliser avec n’importe quel autre langage. Il est payant, mais il existe des versions gratuites limitées.

IV.2.2 Quelques concurrents de SQL server

Oracle

C’est le SGBD le plus célèbre, le plus complet et le plus puissant. Il est malheureusement payant (et cher), ce qui le réserve plutôt aux entreprises qui l’utilisent déjà massivement.

Il existe cependant des versions gratuites d’oracle notamment pour ceux qui veulent apprendre à s’en servir.

PostgreSQL

Il s’agit d’un SGBD libre et gratuit comme MySQL, qui propose des fonctionnalités plus avancées.

Parfois comparé à Oracle, il lui reste cependant du chemin à parcourir. Il dispose d’une communauté un peu moins importante que MySQL et Oracle. Le Site du Zéro utilise PostgreSQL.

SQLite

Le SGBD le plus simple et le plus petit. Il est libre et gratuit mais dispose de très peu de fonctionnalités (ce qui suffit parfois).

Son gros avantage est d’être très léger.

MySQL est un système de gestion de base de données (SGBD). Il est orienté vers l’application web. MySQL fait partie du quatuor LAMP: Linux, Apache, MySQL, PHP. Il appartient également à ses variantes WAMP (Windows) et MAMP (Mac).

IV.2.3 Le langage C#

C’est un langage de programmation orienté objet qui permet de réaliser des applications des BD plus performants et consistants avec une qualité et une grande fiabilité.

Ce Langage de programmation est développé par Visual Studio, inspiré de C++. Il peut s’adapter à n’importe quel ordinateur.

Les programmes C# peuvent être appelés depuis des documents XML ou de manière autonome. Lorsqu’ils s’exécutent à partir d’un formulaire on les appelle ASP .NET et DOT NET.

IV.3 Implémentation de la base de données

Pour implémenter notre base des données « Gestion des Clients d’Ami-Labo », nous avons utilisé l’environnement de création de base des données Microsoft SQL Server Management Studio et le système de gestion de base des données SQL Server.

L’image ci- dessous présente notre Dbo.

Diagramme base de données :

Dans ce qui suit, nous allons présenter quelques interfaces de notre application de base de données Gestion des Clients Ami-labo où nous faisons la gestion de la facturation et le résultat.

IV.4.1 Interface d’accueil

Cette page offre un aperçu de l’application. On retrouve l’interface d’authentification permettant aux différents utilisateurs d’accéder à leurs sessions.

IV.4.2 Interface d’administration

Celle-ci permet à l’administrateur d’avoir un contrôle total sur l’application, lui permettant ainsi d’accéder à toutes ses fonctionnalités.

IV.4.3 Interface gestion des Examens réalisés (état de sortie)

Cette interface permet au superviseur de gérer et prendre une décision de santé publique.

IV.4.4 Interface édition facture

Cette interface permet au réceptionniste d’éditer une facture pour un bénéficiaire bien spécifique.

IV.5 Architecture matérielle mise en place

L’architecture que nous allons utiliser est l’architecture Client/serveur. L’application de base de données sera hébergée dans un serveur intranet situé dans le LPSP Ami-Labo/Goma.

L’architecture adoptée est comme suite:

Perspective

Nous souhaitons mettre en place une application serveur faisant un bon usage entre les utilisateurs du serveur intranet et le serveur de base de données afin de filtrer les différentes requêtes acheminées à travers la liaison, émanant des différents ordinateurs clients connectés au serveur dans le souci de mieux sécuriser le serveur de base de données.

Pour cela, nous proposons une application serveur bien connu dans le domaine des bases de données qu’est SQL Server.

Conclusion générale

Le professeur Dominique MWEZE écrivait qu’ « en Informatique, on ne conclut pas, puisqu’on est tout le temps en deçà du temps, branché sur le futur à la recherche de ce qui n’est pas encore, de ce qui pourrait être, de ce qu’on pourrait « faire être »44 . Il avait parfaitement raison.

44 MWEZE, Chirhulwire, Op. Cita. p. 229, Cité par KAZEGE CIZUNGU Modeste, Informatique Générale, éd. MEDIASPAUL Kinshasa(RDC). 2008, p.274.

Avec l’évolution croissante de la science en générale, de l’informatique en particulier, nul ne peut se dire qu’il est à la page.

L’Informatique induit toujours un constant apprentissage, quelque degré de compétence qu’on ait atteint.

C’est pourquoi, ce travail qui est une série d’autres travails dans le domaine de conception des systèmes d’information se contentera, en guise de conclusion, d’une observation de l’évolution au cours de l’élaboration de ce mémoire.

La phase de conception du projet a duré plus que nous l’avions prévue. En effet, il nous a fallu un mois et demi pour analyser le contexte auquel s’attache notre travail, et concevoir le futur système. La tâche qui nous a embarrassés le plus, consiste notamment dans l’application conforme du cycle de vie du Processus Unifié.

En fait, la liberté que nous a accordée ce processus, (un processus générique), s’est convertie en une lourde responsabilité : la responsabilité d’accomplir les bons choix.

La spécification des besoins a duré un mois. Pendant cette période, il nous était demandé d’assimiler le contexte du travail à accomplir. Accompagnés par l’un de chef du laboratoire, le LPSP Ami-Labo nous a permis d’explorer et d’approfondir la compréhension du domaine d’étude.

Nous avons réussi à dégager les lacunes du système actuel et suggérer des solutions afin d’y remédier. Nous avons opté pour l’architecture réseau Client/serveur qui est adéquate aux exigences de l’entreprise.

La phase d’analyse a duré un mois, au cours de cette période, nous avons essayé de structurer et définir les besoins attendus du futur système. Il s’agissait de formuler, d’affiner et d’analyser la plupart des cas d’utilisation via les diagrammes d’UML.

Il faut noter que le dégagement des grandes fonctionnalités du système n’a pas suffi pour aborder la phase de conception, il fallait dégager plus de besoins.

Il nous a fallu interroger les différents acteurs du système d’information du laboratoire pour enrichir notre diagramme de cas d’utilisation. Et là nous étions confrontés à un problème délicat : la dissimulation de l’information. La solution réside dans le Processus Unifié, et consiste au prototypage.

Il fallait donc construire des interfaces prototypes et les présenter aux différents acteurs.

Les éléments à livrer au terme de la phase d’analyse (acteurs, besoins fonctionnels, besoins non fonctionnels) étant déterminés, nous pouvions passer à la phase suivante.

Ensuite nous avons entamé la phase de conception. Dans cette phase, nous avions déjà un modèle final des cas d’utilisation.

Il s’agissait alors d’étendre la représentation effectuée au niveau de l’analyse en y intégrant les aspects techniques les plus proches des préoccupations physiques.

L’élément principal à livrer au terme de cette phase est le diagramme de classe.

Enfin, nous étions arrivés à la dernière phase du Processus Unifié, où il s’agissait d’implémenter et tester les cas d’utilisation conçus. La version exécutable du système est l’élément principal à livrer à l’issu de cette étape.

L’application que nous avons développée est dédiée spécialement à la facturation et au résultat après analyse de l’échantillon du laboratoire LPSP Ami-Labo/Goma. Nous souhaitons que celle-là soit étendue afin de toucher les différents laboratoires de la ville, de la province et du pays.

L’étude menée au sein de cette structure a pour objectif de:

• Mettre en place une base de données client;

– La liste des examens disponibles;

– Les factures des clients;

– Les résultats suivant les bénéficiaires réceptionnés et dont la prise de sang et/ou liquide, des intrants;

– Faire le rapport statistique de type d’examen.

Modéliser la gestion de la base de données afin de permettre : La gestion des bénéficiaires, nouveaux clients et la facturation;

D’effectuer les statistiques utiles aux rapports par type d’examen; La gestion des résultats des tests et des références.

Nous souhaitons ainsi que l’application développée sera utile, aussi utile aux utilisateurs et qu’elle fut intéressante pour nous.

En fait, à la fin de la réalisation de ce mémoire, nous avons accumulé une masse importante de connaissances aussi bien sur le plan théorique que sur le plan pratique, et nous estimons qu’elle nous sera très utile à l’avenir, dans nos études ultérieures.

Le rationalisme moderne prend soin de nous avertir que, dans le monde de la métaphysique comme en Informatique, nous sommes comme de malheureux navigateurs sur un océan sans limites connues et dans un frêle esquif dépourvu de voiles, de rames et de gouvernail.

Pour nous diriger sur cet océan, nous avons impérieusement besoin d’un guide qui nous montrera la route à suivre et nous donnera la force d’atteindre le but.

Les laboratoires vivent dans un environnement de plus en plus complexe de par la diversité des tutelles et la diversification de leurs ressources, tout en étant confrontés à une compétition scientifique croissante.

L’assemblage historique de services et de moyens informatiques ne suffit plus. Ils doivent pouvoir s’appuyer sur un véritable système d’information, servi par des moyens informatiques adéquats en puissance et en pertinence. Définir, spécifier et réaliser un tel système est un très vaste chantier.

Notre contribution consiste en une proposition d’une méthode pragmatique de spécification et de chiffrage des services en réponse aux besoins des utilisateurs d’un laboratoire d’analyse biologique.

Cette étude s’est largement inspirée, sans les nommer car peu connus dans nos contextes des recherches, des concepts d’urbanisation des systèmes d’information.

Pour continuer dans ce sens, il resterait au responsable du système d’information à produire des cartographies: celles des infrastructures, des applicatifs, des métiers et des processus pour ensuite améliorer cet ensemble.

Glossaire

-A-

Adresse (@) IP : Une adresse IP (avec IP pour Internet Protocol) est le numéro qui identifie chaque ordinateur connecté à Internet, ou plus généralement et précisément, l’interface avec le réseau de tout matériel informatique (routeur, imprimante) connecté à un réseau informatique utilisant l’Internet Protocol.

Adresse (@) MAC : En réseau informatique une adresse MAC (Media Access

Control address) est un identifiant physique stocké dans une carte réseau ou une interface réseau similaire et utilisé pour attribuer mondialement une adresse unique au niveau de la couche de liaison (couche 2 du modèle OSI). C’est la partie inférieure de celle-ci (sous- couche d’accès au média – Media Access Control) qui s’occupe d’insérer et de traiter ces adresses au sein des trames transmises.

Elle est parfois appelée adresse Ethernet, UAA (Universally Administered Address), BIA (Burned-In Address), MAC-48 ou EUI-48.

Application : Les applications sont les outils qui nous permettent de tout faire sur un ordinateur. Les traitements de texte, les tableurs, les navigateurs Web sont des applications (synonymes : Logiciel et Programme).

-B-

Bon de paillasse : Le bon de paillasse est le document écrit adressé par la personne publique bénéficiaire de l’analyse au LPSP Ami-Labo; il précise et renseigne l’échantillon lors du prélèvement.

-E-

Encapsulation : En programmation orientée objet, l’encapsulation est l’idée de protéger l’information contenue dans un objet et de ne proposer que des méthodes de manipulation de cet objet.

-F-

Fiche de résultat : Une fiche de résultat est une feuille qui permet de tenir à jour un état des résultats. Elle permet de décrire un microbe après analyse. La fiche de résultat retrace l’historique de l’échantillon pour une analyse et même référence.

Flot : Motif d’ornementation formé d’enroulements se reliant de façon continue. Appelé également flots-grecs, cet ornement est obtenu par la répétition d’une courbe en S couchée, terminée à l’une de ses extrémités par une volute d’où part la courbe suivante. On reconnaît une dizaine de flots définis par l’exécution du dessin, ils sont couramment dénommés :

FTP : le File Transfer Protocol (protocole de transfert de fichiers), un protocole de communication dédié à l’échange de fichiers informatique sur un réseau TCP/IP.

-H-

HTTP : [protocole] HyperText Transfer Protocol .Protocole de transmission dédié aux clients et aux serveurs du web. Facile à implanter car à un transfert de données est associé une connexion, il devient lourdingue, car il multiplie ainsi les connexions.

-I-

Instanciation: En programmation orientée objet, on appelle instance d’une classe, un objet avec un comportement et un état, tous deux définis par la classe. Dans ce contexte, instance est un anglicisme, qui signifie « cas >>, « exemple >>.

-P-

POO: La programmation orientée objet (POO), ou programmation par objet. C’est

un paradigme de programmation informatique qui consiste en la définition et l’interaction de briques logicielles appelées objets, un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une personne ou encore une page d’un livre.

Il possède une structure interne et un comportement, et il sait communiquer avec ses pairs. Il s’agit donc de représenter ces objets et leurs relations; la communication entre les objets via leur relation permet de réaliser les fonctionnalités attendues, de résoudre le ou les problèmes.

-S-

Standardisation : L’entreprise qui applique une politique de standardisation de son produit offre une version unique d’un produit (le produit vendu sur le marché domestique) sur l’ensemble de ses marchés étrangers.

SMTP : Serveur SMTP signifie « Serveur Simple Mail Transfert Protocol >> et se traduit par « protocole simple de transfert de courrier >> en français.

Un serveur SMTP est un serveur de courrier. Il gère le transfert du courrier électronique vers les différents serveurs de messagerie électronique. De plus, il permet l’envoi de mail à partir des ordinateurs clients. C’est pourquoi, il est utile de spécifier un serveur pop et un serveur SMTP lors de la configuration du logiciel du mail.

SMTP n’a pas pour but de récupérer à distance des mails arrivés dans une boite mail.

-T-

TCP/IP : Définition du mot TCP IP, Ensemble de deux protocoles qui permettent la gestion des flux d’informations sur Internet.

Bibliographie

I. Ouvrages

Ivar Jackobson, Grady Boosh, James Rambaugh, Le processus unifié de développement logiciel, Editions Eyrolles, 1999.

Ivar Jackobson, Manus Cristerson, Patrick Jonsson, Gunar Overgaard, Le génie logiciel orienté objet, Editions Addison Wesley, 2000.

F. Juliard UML Unified Method Language, Journal Université de Bretagne Sud UFR SSI-IUP Vannes, 2001-2002.

Joseph Gabay et David Gabay, Mise en oeuvre guidée avec études de cas, édition Dunod, Paris 2008.

KAZEGE CIZUNGU Modeste, Informatique générale, de la théorie à la pratique, médiasPAUL, 2008, Kinshasa-RDC.

Laurent AUDIBERT, `UML 2′, Institut Universitaire de Technologie de Villetaneuse – Département Informatique, Édition 2007-2008.

M. Grawtz, Méthodes des sciences sociales, précis d’alloz, 9e Ed Paris 1993.

Nathalie Lopez, Jorge Migueis et Emmanuel Pichon, Intégrer UML dans vos projets, Editions Eyrolles, 2000.

Pascal ROQUES, UML 2 par la pratique étude de cas et exercices corrigés, ÉDITIONS EYROLLES, Septembre 2006.

II Notes de cours

1. Ass. BALAGIZI Olivier, Cours de Génie logiciel, inédit L2, ISC/Goma, 2012-2013.

2. Jac MUNDA, Cours d’analyse des organisations, inédit L1 ISC/Goma, 2011-2012.

3. Teddy KAVETA, Cours de Méthodes de Conduite des Projets Informatiques L2 Informatique de Gestion, inédit, ISC/Goma, 2012-2013.

4. SALUMU MULENDA, Cours de recherche opérationnelle, L1 Informatique de Gestion, inédit, ISC/Goma, 2011-2012.

III Webographie

www.commentcamarche.com/initiation/concept.html

Table des matières

0. Introduction générale 1

0.1 Etat de la question 2

0.2 Problématique 2

0.3 Hypothèse 4

0.4 Objectif du travail 4

0.5 Choix et intérêt du sujet 5

0.6 Méthodes et techniques utilisées 5

0.6.1 Méthodes 5

0.6.2 Techniques 6

0.7 Délimitation du sujet 6

0.7.1. Délimitation dans le temps 6

0.7.2. Délimitation spatiale 6

0.8. Subdivision du travail 7

0.9 Difficultés rencontrées 7

Chap. I : Généralités et plan prévisionnel de la réalisation du projet 8

i.0. Introduction 8

i.1. Les processus unifiés et UML 8

i.3 Réseau informatique 15

i.ii Planning prévisionnel de réalisation du projet 19

i.ii.1 Cadre de travail du projet 19

i.ii.2 Intitule du projet 19

i.ii.3 Définition des objectifs 19

i.ii.4 formation de groupe de travail 20

i.ii.5 Choix des techniques 22

i.ii.6 Avantage de la théorie d’ordonnancement 22

i.ii.7 Calendrier de réalisation du projet 26

Chap. II. Spécification des besoins et étude préalable 27

ii.1 Présentation de l’entreprise 27

ii.2 Contexte du système et analyse du système d’information existant 32

ii.2.4 Etude de circuit de l’information 36

ii.2.5 37

ii.2.6 Critique de l’existant 39

ii.2.7 40

Chap. III Analyse des besoins et modélisation en UML 43

iii.0 Introduction 43

iii.1 Analyse fonctionnelle 43

iii.1.1 43

iii.2 Modélisation métier 44

iii.2.1 44

iii.3 Modélisation en UML 44

iii.3.1 Modélisation fonctionnelle 44

Modélisation dynamique 52

Modélisation statique 56

Chap. IV conception, développement et réalisation de l’application

iv.0 introduction 58

iv.1 l’environnement de développement de l’application 58

iv.2 les outils des développements 59

iv.2 .1 SQL/server 59

iv.2.2 quelques concurrents de SQL server 59

iv.2.3 le langage C# 59

iv.3 Implémentation de la base de données 59

iv.4 interfaces de l’application 60

iv.4.1 interface d’accueil 60

iv.4.2 interface d’administration 61

iv.4.3 interface gestion des sessions 61

iv.4.4 interface édition facture 61

iv.5 architecture matérielle mise en place 62

Conclusion générale