|
Conception et réalisation d’un système d’information informatisé pour la gestion des transferts de fonds dans une agencepar Gédéon KOLE Université de MBANDAKA - Graduat 2020 |
1.4.2. Système de gestion
des bases des données (SGBD)
Définition et rôle des SGBD : le système de gestion de fichiers classiques est un logiciel qui permet d'élaborer et de préciser un certain nombre des fonctions associées aux données continues dans les fichiers : définition, création, organisation et accès des fichiers, recouvrement et manipulation des données, etc. Le SGBD n'est en réalité qu'une extension de système de gestion des fichiers classiques, auquel on ajoute certains éléments permettant une déconnection complète des bases des données des programmes à savoir : Ø Un langage de définition et de description des données : il a pour rôle de les définir, les structurer, les formater et les organiser sur le support ; Ø Un langage de commande ou de manipulation des données : il a pour rôle d'accéder aux données, les lire, les écrire et de procéder à des ajouts ou des suppressions ; Ø Un mécanisme de protection ou de sécurité des données : § Au niveau des accès pour celui soit sélectif ; § Au niveau de la logique, pour régler les conflits (lorsque deux utilisateurs au moins veulent modifier la même donnée) ; § Au niveau de l'intégrité, pour rendre la base des données invulnérables aux problèmes extérieurs (arrêt anormal du disque, etc.) ; c'est-à-dire pour permettre de toujours pouvoir restaurer la base des données dans un état connu et de relancer ainsi les programmes depuis le moment de l'incident. Quelques exemples de SGBD : la première génération des SGBD était basée sur le modèle hiérarchique, puis sur le modèle en réseau. La deuxième génération des SGBDR est apparue en 1970 et st fondée sur le modèle relationnel. Ce sont les SGBD les plus utilisés actuellement. Ils utilisent un langage d'interrogation des données normalisées appelé SQL (StructuredQueryLanguage). Il existe actuellement plusieurs centaines de SGBDR dont : Oracle, Accès, Informix, DB2, Paradox, Dbase, Interbase, etc. 1.5. NOTIONS SUR LA METHODE MERISE1.5.1 Historique de la méthodeLa méthode Merise est formellement née en
1979. Les recherches de base (modélisations), sous contrat de l'INRIA, se développèrent de 74 à 81, à Aix-en-Provence, au sein d'une équipe Administration-Université animée par H. Tardieu. Dans le cadre du projet Merise proprement dit, des experts des SSII et de l'Administration, validèrent les modélisations et développèrent la partie mise en oeuvre (démarche et organisation). Ils contribuèrent fortement au passage d'une formulation "universitaire" à une présentation "pratique". Merise ne se voulait pas a priori une méthode complète, ficelée, prête à l'emploi, mais un "tronc commun" méthodologique sur lequel chacun pourrait se greffer pour développer ses propres variétés. D'où le nom de Merise ! Le merisier (les pépiniéristes le savent bien) est l'arbre idéal pour porter des greffes! 1.5.2. DéfinitionMERISE est une méthode de conception qui fait une approche systémique, c'est-à-dire une approche qui repose sur la théorie des systèmes. Grâce à elle, le concepteur a la possibilité de représenter le réel perçu. De l'aveu même d'un de ces fondateurs, le nom Merise vient de l'analogie faite avec le merisier qui ne peut porter des bons fruits que si lui branche de cerisier. D'abord amer et sucré par après, MERISE est au début difficile et excellent après sa maîtrise. Elle est en ceci une greffe réussite d'une méthode informatique sur les entreprises (français en particulier et autres en général) : M : Méthodes ; E : d'Etude ; R : Réalisation ; I : Informatique ; S : Systèmes E : Evolués ou Entreprise MERISE est le rassemblement des idées sans effort. MERISE n'est pas une méthode originale parce qu'elle a emprunté à beaucoup des méthodes et approches. Enfin, Merise suit une démarche hiérarchique, c'est-à-dire une démarche par niveau et cela de par ses trois cycles, notamment : le cycle de vie, le cycle d'abstraction et le cycle de décision. 1.5.2. Caractéristiques de MERISE1.5.2.1. Approche systémiqueMerise est avant tout une méthode de conception, de développement et de réalisation des projets informatiques. A cet égard, elle adopte une vision globale ou systémique de la question traitée, à l'opposé de l'approche analytique qui caractérisait les modèles antérieurs. L'approche analytique consiste à sélectionner un domaine sans tenir compte des interactions des autres domaines ou projets. Elle a pour conséquences : la redondance nuisible, le manque de standardisation des méthodes, la dépendance logique entre fichiers et applications créées. Par contre, l'approche systémique consiste à étudier un domaine en tenant compte des interactions avec d'autres domaines ou projets. Ce qui annule les inconvénients de l'approche analytique évoqués ci-dessus. Ainsi donc, plus qu'une méthode d'analyse, Merise est avant tout une méthode ou plus exactement une démarche de construction des systèmes d'information. 1.5.2.2. Séparation entre l'étude des données et celle des traitementsLa méthode Merise est basée sur la séparation des données et traitements à effectuer. Elle aboutit ainsi à l'élaboration de plusieurs modèles correspondantes (MCD, MOD, MLD, d'une part, et MCT, MOT, MPD, d'autre part). Dans un premier temps, au cours de l'étape conceptuelle, l'étude des données et des traitements sont menées de front et s'ignorent l'une par rapport à l'autre puisque conduites indépendamment l'une de l'autre. Selon une méthode issue de l'approche « bases des données », l'étude des données consiste d'abord à modéliser le réel perçu, sans préjuger des traitements qui seront faits. Parallèlement à cette étude des données, celle des traitements va consister à abstraire le réel existant pour pouvoir arriver à une formalisation conceptuelle des processus, sans tenir compte de l'outil informatique. Dans un deuxième temps, lors de la validation des modèles conceptuels au cours de l'étape organisationnelle, le réel perçu et les procédures désirés sont mis en accord et sont étudiés conjointement, avec en toile de fonds, la possibilité d'utiliser l'outil informatique. En fait, la démarche de Merise se fait selon trois axes qui constituent ce qu'on appelle les trois cycles de Merise. 1.5.3. Cycles de la méthode MERISE1.5.3.1. Cycle de vie du système d'informationLe cycle de vie du système d'information rappelle quelque peu les étapes des êtres vivants à savoir la conception, la gestation, la naissance, l'évolution, la mort, puis la renaissance. Dans le cas de système d'information, qui est un système « vivant », on retient les trois étapes suivantes à savoir la conception, la réalisation et la maintenance, les deux premières étant à leur découpées sous-étapes, telles que présentées dans le tableau suivant : Tableau N°2 : Cycle de vie du système d'information
1.6.3.2. Cycle d'abstraction dans la conception du système d'informationSur le plan du raisonnement, Merise prévoit quatre niveaux d'abstraction lors de la conception du projet dans le cadre de l'étude détaillée du projet : conceptuel, organisationnel, logique et physique. Les deux premiers niveaux sont adaptés à la conception du système d'information informatisée(SII). Par ailleurs, chaque niveau d'abstraction comprend deux volets : données et traitements. Enfin, chaque niveau est représenté par un modèle et chaque modèle par un formalisme utilisant des concepts adaptés : Tableau N°3 : Cycle d'abstraction du système d'information
1.6.3.3. Cycle de décisionDans chaque modèle, à chaque étape, des choix doivent être effectués tels que : vers quel projet veut-on aller ? Quels moyens veut-on affecter ? La mise en oeuvre de la méthode Merise se traduit en outre par une décision de choix permettant d'une part, de définir un système en harmonie avec les objectifs globaux de l'entreprise. Dans la pratique, le cycle de décision est intégré au cycle de vie. Cela se traduit par des résultats types à l'issue de chaque étape et par des décisions attendues comme le montre cette figure. Tableau N°4 : Cycle de décision
1.6.4. Définition des concepts et formalismes utilisés dans la méthode MERISE1.6.4.1. Concernant les donnéesL'étude des données recourt à un certain nombre de concepts dont il importe de préciser le contenu ainsi que les formalismes respectifs de représentation dans les modèles correspondants. Il s'agit des concepts objet, propriété, relation et contraintes.
Il existe deux sortes de propriétés à savoir :
Un identifiant est toujours souligné ou précédé du symbole dièse (#) pour faciliter son repérage. Exemple :
Exemple :
· Définition : Une relation entre deux ou plusieurs objets est une association perçue dans le réel entre ces entités. Elle est aussi considérée comme un lien verbal entre deux ou plusieurs objets et d'exprime généralement par un verbe à l'infinitif. A une relation, on peut accoler ou pas une ou plusieurs propriétés. · Nom de la relation Nom de la propriété Formalisme d'une relation · Dimension d'une relation : Selon qu'une relation permet d'associer entre 2, 3 ou de plus de manière générale, n objets, elle est dite binaire, ternaire ou n-aire. · Fonctionnalité d'une relation : On définit la fonctionnalité d'une relation par rapport à deux entités x et y. On distingue à cet effet les relations : 1°) 1 à 1 ou (1,1) : à toute occurrence de x et ne correspond qu'une occurrence de y ; 2°) 1 à plusieurs ou (1, n) : à toute occurrence de x correspond une ou plusieurs occurrences de y ; 3°) Zéro à 1 ou (0,1) : à toute occurrence de x correspond tout au plus une occurrence de y ; 4°) Zéro à n ou (0, n) : à toute occurrence de x correspond zéro ou plusieurs occurrences de y.
a. Contraintes de cardinalité La cardinalité est le nombre de fois que participe l'occurrence d'un objet dans une association. Dans la pratique, à chaque objet est associé un couple de valeur : une valeur minimale et une valeur maximale. La cardinalité par 1 ou n. Ainsi on a les combinaisons possibles suivantes : (0,1), (0, n), (1,1) ou (1, n). Les cardinalité (1,1) et (1, n) montrent une participation obligatoire, tandis que (0,1) et (0, n) montrent une participation facultative. b. Contraintes d'intégrité fonctionnelle (CIF) Il y a contrainte d'intégrité fonctionnelle lorsque deux objets dans une relation se présentent comme père et fils et que la connaissance du fils implique toujours celle du père ; en d'autres termes, si à un des objets est associé le couple de cardinalité (0,1) ou (1,1). Illustration ; contrainte d'intégrité fonctionnelle ou de type père et fils. Cardinalité minimale cardinalité maximale
L'enseignant est le père car il envoie à son fils (Matière) son identifiant. Mais le fils pointe vers le père. Illustration : contrainte de type non père et fils Cardinalité minimale cardinalité maximale
1.6.4.2. Concernant les traitementsPendant le traitement, il est question d'agencer chronologiquement les opérations suivant les événements qui les déclenchent dans un processus. On présente ci-après quelques concepts qu'il importe de définir avec leurs formalismes respectifs de représentation dans les modèles : opérations, processus ; événement, résultat, synchronisation.
Evénement Voir illustration concrète ci-dessus.
Voir illustration ci-dessous.
Les conditions booléennes sont les suivantes :ET (? ou n)OU (V ou U).
Illustration plus complète Evènement B Evènement A OU/ ET
Résultat A Résultat B
Evénement et résultat : Opération : a b OU/ ET OPERATION Synchronisation : c CHAPITRE II : ETUDE D'OPPORTUNITE2.1. PRESENTATION DU SYSTÈMEÉTUDIÉL'Agence GADI en sigle, ou Groupe d'Actions pour le Développement Intégré de Mbandaka est une entreprise privée appartenant à l'actuel Gouverneur de la province de l'Equateur, Monsieur BOLOKO BOLUMBU Dieudonné. L'Agence est également présente dans la ville de Kinshasa dans la Commune de Barumbu où se situe la Direction Nationale, dans les Communes de Masina et de Ngaba. Elle est également présente dans la ville de Kikwit.
2.1.1. Historique
L'histoire de l'Agence GADI remonte en 1997, lorsque son initiateur, Monsieur BOLOKO BOLUMBU Dieudonné, connu sous le nom de BOBO, vendeur de carburant à l'époque, s'est réuni avec ses amis de même profession pour défendre leurs intérêts sous une association dénommée « KADAFI ». Suite aux divergences de vision, chacun retira sa part pour évoluer indépendamment des autres. C'est ainsi que Monsieur BOLOKO ouvrira une maison de vente des produits pétroliers appelée « Entreprise BOBO » en 1997. Quelques années plus tard, l'Entreprise BOBO reçoit du gouvernement un appui de deux containers frigorifiques appelés chambre froide pour garder froids les vivres. Animé par le souci de porter sa contribution à la population, Monsieur BOLOKO profita de cet appui pour changer le statut de l'entreprise en une Organisation Non Gouvernementale dénommée Groupe d'Action pour le Développement Intégré, en sigle « GADI ».
2.1.2. Statut juridique
Le Groupe d'Action pour le Développement Intégré est reconnu de l'Etat Congolais par l'Arrêté Ministériel n°105/CAB/MIN/J/2009 du 14 juillet 2009 qui lui accorde une Personnalité Juridique. Administrativement, GADI est dirigé grâce à :
2.1.3. Objet socialConformément à ses statuts, GADI poursuit les objectifs ci-après :
Selon ses statuts, GADI est appelé à fonctionner sur toute l'étendue de la République Démocratique du Congo. Raison pour laquelle, en dehors de Mbandaka (la ville qui l'a vu naitre), GADI est présente notamment à Kikwit, et à Kinshasa dans trois communes, dont la Commune de Barumbu où se situe la Direction Nationale, dans les Communes de Masina et de Ngaba. 2.1.4. Situation géographiqueA Mbandaka où nous avons mené nos recherches, l'Agence GADI se situe sur l'avenue Du Congo, et a comme voisins à l'Est la Direction Provinciale de la 10ème Paroisse du CADELU, à l'Ouest le Marché de Bolodjwa, au Nord la résidence privée de l'actuel Gouverneur de Province de l'Equateur, et au Sud la Station ENGEN. 2.1.5. Structure organique et fonctionnement2.1.5.1. Structure organiqueEn rapport avec ses statuts, GADI un Conseil d'Administration présidé par un Président du Conseil d'Administration (PCA), une Présidence par un Président Directeur Général (PDG), une Direction Générale dirigée par le Directeur Général (DG), ainsi que quatreservices dont le Service de Transfert de Fonds, le Service de Caisse, Service de Fret, et le Service d'Affrètement. Signalons que le Directeur Général est assisté par un Chef d'Agence qui est le superviseur direct des services de l'Agence, ainsi que de deux autres services en charge de l'Administration de l'Agence (Service d'Administration et Personnel et le Service d'Audit et Comptabilité). 2.1.5.2. FonctionnementLe fonctionnement de GADI est basé sur ses statuts de l'ONG vis-à-vis de l'Etat, et de règlement intérieur pour les réalisations avec les travailleurs. Ainsi le fonctionnement de GADI part de ses activités et repartit dans ses principaux services :
PRESIDENCE/DIRECTION GENERALE DIRECTION GENERALE SERVICE TECHINQUE ET MAINTENANCE SECRETARIAT DE DIRECTION CHEF D'AGENCE SERVICE D'ADMINISTRATION ET PERSONNEL AUDIT ET COMPTABILITE SERVICE DE TRANSFERT DE FONDS CAISSES SERVICE FRET SERVICE D'AFFRETEMENT
2.1.6. ORGANIGRAMME DE L'ENTREPRISE
Figure n°3 : Organigramme général du Groupe d'Action pour le Développement Intégré 2.2. DIAGNOSTIC DE L'EXISTANTDans le cadre de ce travail, nous nous sommes focalisés sur le service de transfert de fonds pour rendre lucide nos recherches. 2.2.1. Analyse de l'existantChef d'Agence Chef de Service Caissière 1 Chargé des Dépôts Caissière 2 Chargé des Retraits Dans cette partie nous allons essayer d'expliquer les éléments que nous avions trouvé qui facilite le travail dudit service.
2.2.1.1. Organigramme du service concerné
Figure n°4 : Organigramme du service de Transfert de Fonds 2.2.1.2. Etude des postes de travail concernés2.2.1.2.1. Recensement des postes de travailCommele montre l'organigramme ci-haut, le service dispose de 3 postes dont le Chef de Service, et deux caissières préposés à la gestion des transactions.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Date : |
|||||
|
Code |
Expéditeur |
Bénéficiaire |
Montant |
% |
Obs |
2°) Fiche de payement : cette fiche renseigne toutes les sorties ou retrait. Elle est tenue par l'agent de caisse n°2.
Tableau N°6 : Fiche de Payement
|
Date : |
|||||
|
Code |
Expéditeur |
Bénéficiaire |
Montant |
Signature |
Obs |
3°) Fiche de transfert de fonds : ici se trouve toutes les informations ayant rapport avec les dépôts d'argents pour demande de transfert. C'est l'agent de caisse n°1 qui la tient. Elle est remplie selon le modèle ici-bas :
Tableau N°7 : Fiche de Transfert de Fonds
|
Date : |
|||||
|
Code |
Expéditeur |
Bénéficiaire |
Montant |
% |
Obs |
4°) Journal de caisse : c'est un registre qui facilite à la centralisation globale journalière des transactions (Dépôt et/ou Retrait). Ce registre est tenu par le Chef de Service de Transfert de fonds et lui permet de centraliser les opérations effectuées par les deux agents de la caisse. A la fin de chaque fin du mois, le Chef de Service fait le rapport et fait la somme de pourcentage reçu par l'agence.
On y trouve dans ces rubriques :
Tableau N°8 : Journal de Caisse
|
Date |
Motif |
Expédié |
Reçu |
Solde |
Dans cette partie, nous allons essayer de décrire le schéma de circulation d'informations dans le service de transfert de fonds.
Cai1
F4
F2
Ch. Serv
F1
Cli
F3
F5
Cai2
Figure n°5 : Diagramme de flux d'information
Cli : Client
Ch. Serv : Chef de Service de Transfert
Cai1 : Caissier n°1
Cai2 : Caissier n°2
2.2.1.4.3. Commentaires
F1 : Le client se présente auprès du Chef de Service de transfert de fonds
F2, F3 : Le Chef de Service l'oriente chez l'une des caissières selon le type de la transaction
F4 : La Caissière 1 livre l'argent au client (bénéficiaire)
F5 : La Caissière 2 reçoit l'argent à transférer auprès du Client (expéditeur)
Le tableau ci-dessous décrit notre projet et les ressources humaines que nous avons trouvées.
Tableau N°9 : Moyens Humains
|
Projet : Gestion des transferts de fonds |
Analyse effectuée par : Gédéon KOLE NGBOKI |
Date : 02/05/2019 |
||||||
|
N° |
Poste |
Effectif |
Niveau d'étude |
Ancienneté |
Obs |
|||
|
Désignation |
Code |
|||||||
|
1 |
Chef de Service |
CServ |
1 |
L2 Eco Dév |
6 ans |
OK |
||
|
2 |
Caissière |
CAI |
2 |
D6 CA |
19 ans |
OK |
||
|
D6 CA |
14 ans |
OK |
||||||
Comme l'on peut remarquer dans ce tableau, le service comprend 3 agents et bien entendu, sous la direction du Chef d'Agence.
a. Matériels
Le tableau ci-dessous montre les matériels que le service utilise.
Tableau N°10 : Moyens Matériels
|
N° |
Désignation |
Affectation |
Année d'acquisition |
Etat |
|
01 |
Calculatrice |
Caissière 1 |
2018 |
Bon état |
|
02 |
Calculatrice |
Caissière 2 |
2019 |
Bon état |
|
03 |
Calculatrice |
Chef de Service |
2016 |
Vétuste |
b. Matériels Informatique
Le tableau ici-bas renseigne sur le matériel informatique utilisé.
Tableau N°11 : Matériels Informatique
|
N° |
Désignation |
Année d'acquisition |
Caractéristiques |
Etat |
Obs |
|
01 |
Ordinateur, Acer, Lap Top |
2017 |
Processeur : Intel, 1.4GB Ram : 4GB Disque Dur : 500GB Système d'exploitation : Windows 10 Anti-virus : Smadav2018 12.2 |
Bon Etat |
Mise à jour de l'anti-virus envisageable |
Le service de transfert de fonds de l'Agence GADI a une bonne organisation, vu que le nombre de personnels n'est pas excessif, mais aussi c'est un personnel de qualité.
Le service de transfert de fonds de l'agence GADI peut s'améliorer également en changeant quelques attributions pour encore murir leur département car jusque-là il y a certaines anomalies dues notamment à :
· La difficulté dans l'archivage ;
· La lenteur des opérations ;
· Une communication pas forcément fiable ; ...
Au regard de tout ce que nous avions trouvé comme existant dans ce service, nous leurs proposons une solution informatique qui présente les avantages suivants :
· La sécurité des transactions ;
· Le non répudiation ;
· Le gain de temps dans les opérations ;
· La sauvegarde électronique ;
· Le partage ;
· Une gestion rationnelle
Mais étant une oeuvre humaine, la solution informatique peut également présenter les inconvénients tels que :
· Le Coût d'acquisition des matériels ;
· Le coût de la formation des personnels ;
· Le licenciement de certains agents ; etc.
Dans la présentation et la description d'un système d'information organisé, l'accent est mis aisément sur l'aspect organisationnel et non sur l'aspect technique. La mise en oeuvre du SIO se réalisera en 2 étapes : étape conceptuelle et organisationnelle.
Au cours de cette étape, nous tenterons de résoudre les problèmes de représentation des données et des opérations qui s'y rapportent, répondant à la question « quoi ». A cette question, nous devons répondre aussi pour les données que pour les traitements. Ainsi, deux questions vont caractérisés ces étapes :
§ Que représenter ?
§ Comment représenter ?
La description conceptuelle permet de représenter la finalité du système et sa raison d'être, en s'appuyant sur ses objectifs et réalités externes qui les contraignent.
Dans cette démarche, on devinera donc en premier lieu les invariantes statiques, c'est-à-dire les données et les invariantes dynamiques ou les traitements1(*). Les informations sont décrites à ce nouveau indépendamment de la manière dont elles seront réalisées. La démarche conceptuelle représente le « quoi » du système et ce sont donc les règles de gestion qui guident la construction de ces modèles qui sont :
- Modèle conceptuel des données ;
- Modèle conceptuel des traitements.
Pour la construction du MCD, beaucoup de méthodes ont été en mise en place, mais aucune ne donnent réellement satisfaction. On peut, cependant, les repartir en deux catégories :
Ø Modélisation directe : elle consiste à identifier à partir d'une description exprimée en langage naturel, les entités et les associations en appliquant des règles suivantes :
ï Les objets deviennent des entités ;
ï Les verbes deviennent des associations.
Le modèle obtenu par cette méthode est très loin de la représentation optimale et il sera nécessaire d'appliquer une phase d'invalidation et de normalisation (élimination des situations qui induisent des redondances) pour aboutir à une solution satisfaisante.
Ø Modélisation par analyse de dépendance fonctionnelle : cette méthode consiste à identifier en premier lieu toutes les propriétés du système d'information à analyser. Cette étape aboutit au dictionnaire qui ne contient ni synonymie, ni polysémie, ni données calculées. Pour faciliter la conception ultérieure de la base de données, il est recommandé de définir pour chaque donnée au dictionnaire son domaine.
Le domaine d'une donnée est l'ensemble des valeurs que peut prendre cette donnée. Il peut être :
ï Etendu : il correspond alors au type d'une donnée : numérique, alphabétique, alphanumérique... ;
ï Restreint : on l'exprime alors au moyen d'une liste ou d'un intervalle.
La seconde étape réside dans la recherche de dépendance fonctionnelle entre les propriétés recensées à la 1ière étape.
La modélisation conceptuelle des données s'appuie sur l'ensemble des données manipulées par l'organisation étudiée et sur ses règles de gestion. Les données étant la représentation des propriétés définissant les réalités de l'entreprise et les règles de gestion définissant le rapport entre ces propriétés, le modèle conceptuel des données décrit la sémantique, c'est-à-dire le sens attaché à ses rapports2(*).
Une règle de gestion est la traduction conceptuelle des objectifs choisis et des contraintes acceptées par l'entreprise3(*). En effet, les règles de gestion sont associées à la conception et décrivent ainsi les actions qui doivent être accomplies. Leur origine est soit externe à l'entreprise. D'une manière générale, il existe deux types des règles de gestion :
La règle de gestion est dite d'action quand elle décrit les actions sémantiques à accomplir ;
Elle est dite de calcul quand elle écrit la manière dont ces règles seront accomplies.
En ce qui concerne notre étude, nous avions retenu les règles de gestion suivantes :
R1 : Un clientest reçu par un et un seul agent ; Un agent reçoit un ou plusieurs clients.
R2 : Un client effectue au moins une transaction ; une transaction est effectuée par un et un seul client.
R3 : Un client est abonné dans une agence ; une agence a au moins un client.
R4 : Un agent a un et un seul grade ; un grade appartient à un ou plusieurs agents.
R5 : Un agent occupe une et une seule fonction ; une fonction est occupée par un et un seul agent.
R6 : Un agent est engagé à une et une seule agence ; une agence engage un ou plusieurs agents.
R7 : Une agence gère au moins une transaction ; une transaction est gérée par une et une seule agence.
Un objet est défini comme une entité abstraite ou concrète ayant une existence autonome en dehors de l'application et présentant un certain intérêt dans le domaine de gestion.4(*)
a.Recensement des objets
Après une profonde analyse, les objets recensés sont les suivants :
Ø Agence ;
Ø Agent ;
Ø Clients ;
Ø Fonction ;
Ø Grade ;
Ø Transaction.
b. Description des objets
Le tableau ci-après décrit les différents objets recensés.
Tableau N°12 : Description des Objets
|
N° |
Objet |
Propriétés |
|||||
|
Désignation |
Nom Symbolique |
Désignation |
Nom symbolique |
Type |
Taille |
Id |
|
|
1 |
Client |
Cli |
Code Client |
CodeCli |
A |
4 |
# |
|
Noms |
NomCli |
A |
30 |
||||
|
Adresse |
AdrCli |
A |
50 |
||||
|
Téléphone |
TélCli |
N |
13 |
||||
|
2 |
Agent |
Ag |
Matricule |
MatrAg |
A |
4 |
# |
|
Noms |
NomAg |
A |
30 |
||||
|
Sexe |
SexAg |
A |
1 |
||||
|
Grade |
GradAg |
A |
4 |
||||
|
Fonction |
FonctAg |
A |
6 |
||||
|
Adresse |
AdrAg |
A |
50 |
||||
|
Téléphone |
TelAg |
N |
13 |
||||
|
3 |
Grade |
GradAg |
Code |
CodGr |
A |
4 |
# |
|
Titre |
TitrGr |
A |
30 |
||||
|
4 |
Fonction |
FonctAg |
Code |
CodFo |
A |
4 |
# |
|
Titre |
TitrFo |
A |
30 |
||||
|
5 |
Agence |
Agc |
Code |
CodAgc |
A |
4 |
# |
|
Noms |
NomAgc |
A |
30 |
||||
|
Adresse |
AdrAgc |
A |
50 |
||||
|
Téléphone |
TelCAgc |
N |
13 |
||||
|
|
MailAgc |
A |
20 |
||||
|
6 |
Transaction |
Tr |
Code |
CodTr |
A |
4 |
# |
|
Noms destinataire |
NomDest |
A |
30 |
||||
|
Adresse destinataire |
AdrDest |
A |
50 |
||||
|
Téléphone |
TelDest |
A |
13 |
||||
|
Montant |
Mont |
N |
9 |
||||
|
Pourcentage |
Pourc |
N |
6 |
||||
|
Date et Heure envoi |
DatHeur |
D |
16 |
||||
Une relation est une association entre un ou plusieurs objets du modèle. Une relation est un lien verbal représenté par un verbe à l'infinitif et unissant un ou plusieurs objets.
a. Recensement des relations
Nous avons recensé les relations suivantes :
Ø Abonner ;
Ø Avoir ;
Ø Effectuer ;
Ø Engager ;
Ø Gérer ;
Ø Occuper ;
Ø Recevoir.
b. Description des relations
Le tableau ci-dessous décrit les différentes relations retenues et les objets associés. Il donne également la dimension de chaque relation.
Tableau N°13 : Description des relations
|
N° |
Relation |
Objets |
Dimension |
|
|
Père |
Fils |
|||
|
01 |
Abonner |
Agence |
Client |
2 |
|
02 |
Avoir |
Agent ; Grade |
2 |
|
|
03 |
Effectuer |
Client |
Transaction |
2 |
|
04 |
Engager |
- |
Agence ; Agent |
2 |
|
05 |
Gérer |
Agence |
Transaction |
2 |
|
06 |
Occuper |
Agent ; Fonction |
2 |
|
|
07 |
Recevoir |
Agent |
Client |
2 |
Une cardinalité d'une entité représente le nombre de fois minimum de participation d'une occurrence d'un objet dans une relation. Les règles de gestion permettent de donner une précision dans la détermination des cardinalités entre objet en relation.
Les principales cardinalités sont :
0,1 : au plus une participation ;
1,1 : une et une seule participation ;
0,n : zéro ou plusieurs participations ;
1,n : une ou plusieurs participations.
En ce qui concerne la présente étude, les cardinalités ci-dessous ont été retenues.
Tableau N°14 : Détermination des cardinalités
|
N° |
Relation |
Objets |
Dimension |
Cardinalité |
|
|
Père |
Fils |
||||
|
01 |
Abonner |
Agence |
Client |
2 |
1,n - 1,1 |
|
02 |
Avoir |
Agent ; Grade |
2 |
1,1 - 1,1 |
|
|
03 |
Effectuer |
Client |
Transaction |
2 |
1,n - 1,1 |
|
04 |
Engager |
- |
Agence ; Agent |
2 |
1,1 - 1,1 |
|
05 |
Gérer |
Agence |
Transaction |
2 |
1,n - 1,1 |
|
06 |
Occuper |
Agent ; Fonction |
2 |
1,1 - 1,1 |
|
|
07 |
Recevoir |
Agent |
Client |
2 |
1,n - 1,1 |
Elle se définit dans une relation par laquelle il existe d'une part, un objet père et d'autre part un objet fils. Dans ce genre de relation, l'objet père cède sa clé à l'objet fils.
Tableau N°15 : Détermination des contraintes d'intégrité fonctionnelle
|
N° |
Relation |
Objets |
Dimension |
Cardinalité |
C.I.F |
|
|
Père |
Fils |
|||||
|
01 |
Abonner |
Agence |
Client |
2 |
1,n - 1,1 |
OUI |
|
02 |
Avoir |
Agent ; Grade |
2 |
1,1 - 1,1 |
NON |
|
|
03 |
Effectuer |
Client |
Transaction |
2 |
1,n - 1,1 |
OUI |
|
04 |
Engager |
Agence ; Agent |
2 |
1,1 - 1,1 |
NON |
|
|
05 |
Gérer |
Agence |
Transaction |
2 |
1,n - 1,1 |
OUI |
|
06 |
Occuper |
Agent ; Fonction |
2 |
1,1 - 1,1 |
NON |
|
|
07 |
Recevoir |
Agent |
Client |
2 |
1, - 1,1 |
OUI |
1,n
1,1
1,1
1,n
1,1
1,1
1,n
1,n
1,1
Engager
1,n
|
TRANSACTION |
|
#CodTr NomDest AdrDest TelDest Mont Pourc DatHeur |
1,1
Gérer
1,n
|
FONCTION |
|
#CodFo TitrFo |
1,1
|
AGENCE |
|
#CodAgc NomAgc AdrAgc TelAgc MailAgc |
Abonner
|
AGENT |
|
#MatrAg NomAg SexAg GradAg FonctAg AdresAg TelAg |
|
CLIENT |
|
#NumCli NomCli AdrCli TelCli |
Recevoir
|
GRADE |
|
#CodeGr TitrGr |
Occuper
Avoir
1,1
Effectuer
Figure n°6 : Modèle Conceptuel de Données
Comme pour le MCD, il n'existe pas de méthodes algorithmiques permettant d'aboutir à un MCT. Si la présentation de ces concepts peut, en effet, être entièrement formalisée et explicitée, leur assemblage pour résoudre un problème donné exige des qualités d'analyse et de réflexion.
Le MCT exprime ce qu'il faut faire mais n'indique pas qui doit faire, ni quand, ni où (concepts organisationnels), ni comment le faire (concepts opérationnels). Le traitement n'est en fait que la traduction des règles de gestion.
§ Evénement : c'est le compte rendu du système d'information, il matérialise un fait qui, en se produisant, doit déclencher une réaction du système ;
§ Synchronisation : la synchronisation d'une opération est composée de deux éléments :
· D'une par la liste des événements (internes ou externes) qui doivent être arrivés avant de déclencher l'opération ;
· Et d'autre par la règle d'émission sous forme d'une proposition logique qui précise de quelle manière les événements participent au déclenchement de l'opération.
Le cycle de vie d'une synchronisation peut être représenté ainsi :
La règle est vérifiée
Attente de l'arrivée des événements contributifs
ATTENTE ACTIVABLEACTIVEE
Remarque : on parle de fonctionnement asynchrone lorsque les états ACTIVABLE et ACTIVE ne font qu'un.
§ Opération : elle est la réponse à l'arrivée d'un événement ou plus qui déclenche un ensemble de traitements ;
§ Résultat : est un type de message à produire après avoir exécuté les différents événements.
b
a
b
a
Présentation du client chez le réceptionniste
Vérification demande
OK
KO
Client orienté à la caisse
Le Client est rentré
a et b
Enregistrement de la transaction
OK
KO
Attribution du code ou retrait d'argent
Annulation de la transaction
a et b
Confirmation du caissier
OK
Toujours
Signature ou retrait du code
Sortie du client
Rapport au Chef de Service
a et b
Le réceptionniste reçoit le client
Pourcentage versé
Figure n°7 : Modèle Conceptuel des Traitements
L'étape organisationnelle propose la représentation d'un système d'information organisée qui répond aux questions suivantes :
§ Qui ? détermine la nature du traitement ;
§ Quand ? précise le temps ou la périodicité du traitement ;
§ Où ? pour connaître le lieu où s'effectue le traitement.
Les méthodes associées à ce niveau de description sont les modèles organisationnels des données et des traitements.
Cette modélisation exprime le formalisme entité relation des informations qui seront mémorisé informatiquement compte tenu du volume de la répartition et de l'accessibilité, sans tenir compte de condition de structuration de stockage et de performance liées à la technologie de mémorisation informatique utilisée5(*).
Le MOD est élaboré à partir du MCD et cette étape concerne l'organisation à mettre en place.
L'obtention du MOD est le résultat des règles de passage qui sont au nombre des deux :
· La suppression de tous les objets et relation du MCD qui ne seront pas mémorisés informatiquement pour des raisons suivantes :
- Si l'objet ne présente pas l'intérêt pour notre application,
- Si l'objet ou la relation est techniquement impossible d'être informatisé ;
· Créer au besoin d'autres objets et relations qui doivent être mémorisé informatiquement. C'est qu'on appelle MOD global.
Le MOD a pour but de déterminer exactement quelles sont les informations à informatiser, c'est-à-dire de distinguer les données à informatiser. Il est dit global quand les objets sont placés dans le même poste de travail.
Le MCD précédemment représenté équivaut au MOD global, car il n'y a pas eu de suppression des objets, d'où le MCD=MOD global.
1,n
1,1
1,1
1,n
1,1
1,1
1,n
1,n
1,1
Engager
1,n
|
TRANSACTION |
|
#CodTr NomDest AdrDest TelDest Mont Pourc DatHeur |
1,1
Gérer
1,n
|
FONCTION |
|
#CodFo TitrFo |
1,1
|
AGENCE |
|
#CodAgc NomAgc AdrAgc TelAgc MailAgc |
Abonner
|
AGENT |
|
#MatrAg NomAg SexAg GradAg FonctAg AdresAg TelAg |
|
CLIENT |
|
#NumCli NomCli AdrCli TelCli |
Recevoir
|
GRADE |
|
#CodeGr TitrGr |
Occuper
Avoir
1,1
Effectuer
Figure n°8 : Modèle Organisationnel de Données
Le MOT décrit le fonctionnement du domaine en précisant les ressources humaines et matérielles mobilisées ainsi que l'organisation de ses ressources dans le temps et dans l'espace. Il s'attache à décrire le système d'information en répondant aux questions Qui ? Où ? Quand ? Tout en indiquant les notions de responsabilités (poste de travail) et de nature des traitements (manuel ou automatique).
A. Nature de la tâche
La nature de la tâche décrit le genre de traitement qui se fera à la tâche imposée par la gestion concernée, c'est-à-dire qui doit intervenir et comment y parvenir. Cette opération peut être :
· Un traitement manuel TM, si c'est l'homme qui réalise la tâche ;
· Un traitement informatisé (TI ou TA) quand il s'agit de la machine qui réalise la tâche. Dans cette catégorie de traitements, nous nous intéressons au délai de réponse qui peut être :
- Immédiat (I), c'est-à-dire le traitement qui se fait en temps réel(TR),
- Par Lot (L), c'est-à-dire le traitement différé ou par lot.
B. Déroulement de la tâche
On détermine ici le moment où la tâche sera exécutée de la tâche ou l'endroit sera exécutée la tâche.
C. Poste de travail
Le poste de travail est le lieu d'exécution de la tâche ou l'endroit où sera exécutée la tâche.
A ce niveau, le domaine reste le même, le processus devient la procédure fonctionnelle ou organisationnelle, l'opération devient la tâche et l'événement reste le même.
Tableau n°16 : Modèle Organisationnel de Traitement
|
Timing |
Tâches exécutées |
Nature du traitement |
Postede travail |
b
a
b
a
Présentation du client chez le réceptionniste
Vérification demande
OK
KO
Client orienté à la caisse
Le Client est rentré
a et b
Enregistrement de la transaction
OK
KO
Attribution du code ou retrait d'argent
Annulation de la transaction
a et b
Confirmation du caissier
OK
Toujours
Signature ou retrait du code
Sortie du client
Rapport au Chef de Service
a et b
Le réceptionniste reçoit le client
Pourcentage versé
08h00' à 16h00'
|
08h00' à 16h00' 08h00' à 16h00' 08h00' à 16h00' |
TM TM TA TM TA/TR |
RECEPT RECEPT CAI CAI CSERV |
La seconde étape est celle du système d'information informatisé (SII), il est du ressort de l'équipe informatique. Cette partie ne prend en compte que la solution informatique. Elle comprend deux niveaux, à savoir :
Le niveau logique ;
Le niveau physique.
Ces deux niveaux gèrent les problèmes de présentation et de répartition des stockages.
« Comment » est la question posée à cette étape pour déterminer les moyens et ressources informatiques techniques précises. Elle exprime la forme que doit prendre l'outil informatique pour être adapté à l'utilisateur, à son poste de travail et cela se fait indépendamment du langage de programmation et du système de gestion de base de données.
Cette étape permet aussi de décrire le schéma de la base de données, la répartition de données sur les unités de stockage, le volume par unité de stockage6(*).
Voici les vocabulaires spécifiques du MLD :
· Les tables ;
· Les clés primaires ;
· Les clés secondaires ;
· Les attributs.
Pour passer du MOD global au MLD brut, les règles sont les suivantes :
· Les objets deviennent les tables ;
· Les identifiants deviennent des clés primaires ;
· Les propriétés deviennent des attributs ;
· Les relations du type père fils disparaissent mais la sémantique reste, les fils pointe le père et celui-ci lui envoi sa clé primaire qui devient automatiquement clé secondaire ou étrangère ;
· Les autres relations du type père-père (CIF) génère une nouvelle table ayant les deux clés des objets originels, on parle alors de la « concaténation des clés » des tables qu'elle relie.
· Dans les relations du type fils-fils, un des objets cède sa clé à un autre comme clé étrangère.
|
TRANSACTION |
|
|
#CodTr #CodAg #NumCli NomDest AdrDest TelDest Mont Pourc DatHeur |
|
|
FONCTION |
|
|
#CodFo TitrFo |
|
|
AGENCE |
|
|
#CodAgc NomAgc AdrAgc TelAgc MailAgc |
|
|
AGENT |
|
|
#MatrAg #CodAgc #CodGr #CodFo NomAg SexAg GradAg FonctAg AdresAg TelAg |
|
|
CLIENT |
|
|
#NumCli #CodAgc #MatrAg NomCli AdrCli TelCli |
|
|
GRADE |
|
|
#CodGr TitrGr |
Figure n°9 : Modèle Logique de Données Brut
En principe, il existe cinq formes normales, mais les deux dernières sont réservées pour l'optimisation de la base de données. Pour passer du MLD brut au MLD validé nous avons trois règles de normalisation qui sont :
- La première forme normale :
Une table est en première forme normale si elle possède une clé primaire et si ses attributs sont élémentaires c'est-à-dire non décomposable ;
- La deuxième forme normale :
Une table est en deuxième forme normale si étant déjà en première forme normale, ses attributs sont en dépendance fonctionnelle avec la clé primaire ;
- La troisième forme normale :
Une table en troisième forme normale si étant déjà en deuxième forme normale, ses attributs sont en dépendance fonctionnelle directe avec la clé transitivement via un autre attribut.
|
TRANSACTION |
|
|
#CodTr #CodAg #NumCli NomDest AdrDest TelDest Mont Pourc DatHeur |
|
|
FONCTION |
|
|
#CodFo TitrFo |
|
|
AGENCE |
|
|
#CodAgc NomAgc AdrAgc TelAgc MailAgc |
|
|
AGENT |
|
|
#MatrAg #CodAgc #CodGr #CodFo NomAg SexAg GradAg FonctAg AdresAg TelAg |
|
|
CLIENT |
|
|
#NumCli #CodAgc #MatrAg NomCli AdrCli TelCli |
|
|
GRADE |
|
|
#CodGr TitrGr |
Figure n°10 : Modèle Logique de Données Valide
T_Agence : {#CodAgc :Texte [4] ; NomAgc : Texte [30] ; AdrAgc : Texte [50] ; TelAgc : Texte [13] ; MailAgc : Texte [20]}
T_Agent : {#MatrAg : Texte [4] ; #CodAgc : Texte [4] ;#CodGr : Texte [4] ; #CodFo : Texte [4] ; NomAg : Texte [30] ; SexAg : Texte [1] ; GradAg : Texte [6] ; FonctAg : Texte [6] ; AdresAg : Texte [50] ; TelAg : Texte [13]}
T_Grade : {#CodGr : Texte [4] ; TitrGr : Texte [30]}
T_Fonction : {#CodFo : Texte [4] ; TitrFo : Texte [30]}
T_Client : {#NumCli : Texte [4] ; #CodAgc : Texte [4] ; #MatrAg : Texte [4] ; NomCli : Texte [30] ; AdrCli : Texte [50] ; TelCli : Texte [13]}
T_Transaction : {#CodTr : Texte [4] ; #CodAg : Texte [4] ; #NumCli : Texte [4] ; NomDest : Texte [30] ; AdrDest : Texte [50] ; TelDest : Texte [13] ; Mont : Texte [9] ; Pourc : Texte [6] ; DatHeur : Texte [16]}
A. Composition hardware
La composition physique est la partie physique ou matérielle de l'ordinateur. Il est question de présenter les caractéristiques matérielles à utiliser dans le nouveau système d'information.
A cet effet, l'agence aurait besoin des équipements ci-après.
Tableau n°17 : Composition Hardware du Nouveau Système
|
N° |
Matériels |
Nombre |
|
1. |
Serveur |
1 |
|
2. |
Clients |
2 |
|
3. |
Onduleur 8 kVa |
1 |
|
4. |
Onduleur 1500 Va |
2 |
|
5. |
Imprimante HP LaserJet |
2 |
|
6. |
Stabilisateur |
2 |
v Poste client
§ Micro-ordinateur
- Processeur : Intel (R) Core TM i5-2370M CPU@4GHz
- RAM : 4.00 Go
- Disque dur : 500 GO
- Lecteur DVD RW
- Ecran plat 17"
- Clavier AZERTY 105 touches Windows + Tapis
- Souris standard USB
§ Stabilisateur 1.500 VA
§ Onduleur : 1.500 VA
§ Imprimante : HP DeskJet 2130
B. Caractéristiques logicielles
Sur le plan logiciel, il y a ce qui suit :
v Système d'exploitation :
- Pour le serveur : Windows Server 2010 ;
- Pour les clients : Windows 10 ;
v Logiciel d'application : Microsoft office 2010.
v Antivirus : Norton 360 (2018).
Ø Unité logique de traitement (ULT) : nous permet de créer notre base de données, c'est la tâche ou portion de tâche organisée qui est exécutée d'une manière automatique par une machine logique ;
Ø Interface : c'est la masque de saisie qui nous permet de saisir les informations et dialoguer avec l'utilisateur ;
Ø Menu : nous permet de choisir les différents fichiers dans lesquels nous travaillons ;
Ø Site : c'est l'endroit où sont groupées les machines logiques ;
Ø Le model logique de traitement (MLT) est un ensemble de modèle et schéma permettant de décrire le traitement d'une application.7(*)
Les procédures logiques se transforment en unité logique de traitement. Nous pouvons construire le MLT à partir de :
Ø La dénomination des tâches du MOT ;
Ø La recherche de réutilisation des ULT (des procédures) ;
Ø La conception des unités logiques de traitement au tour des données.
Ainsi donc, en ce qui concerne les représentations du MLT, il faut d'abord commencer par un début et terminer par une fin, puis la conception des différentes interfaces du traitement.
Début GADITRANSF
GADI Transfert
|
Connexion |
|
|
- Nom utilisateur - Mot de passe |
|
|
Connexion |
Quitter |
Fin GADITRANSF
|
ULT 03 |
Administrateur |
Agents
Clients
Fonction
Grade
Utilisateur
A Propos
Déconnexion
Transactions
|
ULT 04 |
Transactions |
Envoi
Retrait
A Propos
Déconnexion
Figure n°11 : Modèle Logique de Traitement
A. But
L'objet de l'étape physique est de présenter le stockage de données dans des supports d'enregistrements, c'est-à-dire de la base de données dans les mémoires de données physiques des fichiers à stocker en fonction du logiciel système de gestion de base de données utilisées.8(*)
C. Contenu
Les objets du modèle physique de données sont des tables qui deviennent à cette étape des fichiers.
Les vocabulaires spécifiques retenus pour le MPD sont :
- Les fichiers qui sont rien d'autre que les tables ;
- Les index qui sont des clés d'accès.
Pour passer du MLD au MPD les règles ci-après doivent être appliquées :
- Les tables deviennent des fichiers ;
- Les attributs deviennent les champs ;
- Les clés primaires deviennent des index sans doublons.
a. Table Agence
Image n°1 : Interface Table Agence
b. Table Agent
Image n°2 : Interface Table Agent
c. Client
Image n°3 : Interface Table Client
d. Table Fonction
Image n°4 : Interface Table Fonction
e. Table Grade
Image n°5 : Interface Table Grade
f. Table Transaction
Image n°6 : Interface Table Transaction
Il n'existe pas des règles de passage du MLT au MPT pour la réalisation du MLT. Il n'existe que de spécification technique du différent module défini au niveau du modèle logique de traitement. C'est ce que nous appelons la transaction clavier. Les unités de traitements deviennent des phases.
LOGO
CONNECTION
TRANSACTIONS
PANNEAU D'ADMINISTRATION
Agents
Clients
Fonction
Grade
Utilisateur
A Propos
Déconnexion
Transactions
Envoi
Retrait
A Propos
Déconnexion
Figure n°12 : Modèle Physique de Traitement
Notre choix a été porté sur le système de gestion de base de données (SGBD) HyperFileSQL. HyperFileSQL fait partie intégrante de l'Atelier de Génie Logiciel WinDev. Le fichier de données porte l'extension. FIC, tandis que le fichier des index a l'extension .ndx.
Ce SGBD permet de décrire et de manipuler les données sous forme de tables dans une base de données.
Les opérations sur la base de données sont suivantes :
Ø La création de la base de données ;
Ø La description des structures de différentes tables et la définition des relations entre les tables. C'est à partir de cette définition que sont mises en place les contraintes d'intégrité de domaine, de clé, de référence ;
Ø La manipulation des données en accédant à la base.
La programmation est le fait d'écrire une suite d'instructions fournies à un ordinateur pour lui permettre d'exécuter une tâche9(*). C'est donc un ensemble de méthodes et techniques qui permettent de formaliser, sous-forme d'algorithme, un raisonnement qui sera traduit dans un langage de programmation dont l'exécution apporte une solution satisfaisante.
Nous avons utilisé la programmation orientée objet qui consiste à modéliser informatiquement un ensemble d'éléments d'une partie du monde réel (que l'on appelle domaine) en un ensemble d'entités informatiques. Ces entités informatiques regroupent les principales caractéristiques des éléments du monde réel (taille, la couleur, ...).
Il existe plusieurs langages de programmation parmi lesquels nous pouvons citer : Pascal, Java, Visual basic, Delphi, WinDev, C, C++, C#, etc. Chaque langage est utilisé selon le besoin et sa facilité à l'utilisation.
En ce qui concerne notre travail, nous avons porté le choix sur l'Atelier de Génie Logiciel (AGL) WINDEV 25. Cette plate-forme de développement présente un avantage manifeste, celui d'élaborer des interfaces graphiques de façon plus simple, facile et surtout de manière moins complexe.
Comme dit dans la section précédente, nous sommes très séduites par l'AGL WINDEV 25 pour plusieurs raisons dont :
- Le gain de temps du fait de la génération automatique des interfaces se rapportant aux fichiers grâce à son système RAD (Rapid Application Development = système de Développement Rapide des Applications) ;
- La facilité d'utilisation, car son code peut être écrit en français avec la possibilité d'être converti en anglais ;
- La convivialité de ses fenêtres ;
- Les animations et les gabarits qui plaisent à la vue ;
- La possibilité d'utiliser un SGBD y incorporé : HyperFileSQL ou un autre SGBD tels que DB2, Access, SQLServer, SQLAzure, Oracle, DBase 3+, DBase 4, ProstgreSQL, etc.
Image n°7 : Interface Connexion
Image n°8 : Interface Administrateur
Image n°9 : Interface Utilisateur
Image n°10 : Interface Envoi
Image n°11 : Interface Retrait
Image n°12 : Interface A Propos
SI SAI_UserName="Gédéon" ET SAI_MotDePasse="Kole" ALORS
Ouvre(FEN_useradmin)
SINON
HRecherchePremier(TAdmin,User,SAI_UserName)
SI HTrouve(TAdmin) = Vrai ALORS
Utilise(FEN_Admin)
SINON
HRecherchePremier(TUtilisateur,UserName,SAI_UserName)
SI HTrouve(TUtilisateur) = Vrai ALORS
Utilise(FEN_Espase_Utilisateur)
SINON
Info("Vos informations ne sont pas correctes")
FIN
FIN
FIN
SI TableSelect(TABLE_TUtilisateur) = -1 ALORS RETOUR
SELON Dialogue("Êtes-vous sûr de vouloir supprimer l'enregistrement ?")
CAS 1
TableSupprime(TABLE_TUtilisateur)
TableAffiche(TABLE_TUtilisateur, taCourantPremier)
CAS 2
FIN
EcranVersFichier()
HEnregistre(TTransaction)
HRechercheDernier(TClient,NumCli,"",hRespecteFiltre)
SI HTrouve(TClient)=Vrai ALORS
TClient.NumCli++
FIN
TClient.NomCli=SAI_NomCli
TClient.AdrCli=SAI_AdrCli
TClient.TelCli=SAI_TelCli
HEnregistre(TClient)
SELON Dialogue("Envoi effectué avec succès. Voulez-vous imprimer les détails de l'envoi?")
CAS 1
iAperçu()
iInitRequêteEtat(ETAT_Details_TTransaction, TTransaction.CodeTr)
iImprimeEtat(ETAT_Details_TTransaction)
CAS 2
FIN
RAZ()
DonneFocus(SAI_NomCli)
HOuvre(TTransaction)
BTN_retrait..Grisé = Vrai
HLitRecherchePremier(TTransaction,CodeTr,SAI_CodeRetrait)
SI HTrouve(TTransaction) = Vrai ALORS
SC_Fiche.SAI_NomCli = TTransaction.NomCli
SC_Fiche.SAI_AdrCli = TTransaction.AdrCli
SC_Fiche.SAI_TelCli = TTransaction.TelCli
SC_Fiche.SAI_Montant = TTransaction.Montant
SC_Fiche.SAI_Pourc = TTransaction.Pourc
SC_Fiche.SAI_DateHeure = TTransaction.DateHeure
SC_Fiche.SAI_NomDest = TTransaction.NomDest
SC_Fiche.SAI_AdrDest = TTransaction.AdrDest
SC_Fiche.SAI_TelDest = TTransaction.TelDest
SC_Fiche.SAI_CodAgc = TTransaction.CodAgc
BTN_retrait..Grisé = Faux
SINON
Info("Ce code n'est pas attribué")
FIN
HLitRecherchePremier(TTransaction,CodeTr,SAI_CodeRetrait)
SI HTrouve(TTransaction) = Vrai ALORS
SI TTransaction.flag = True ALORS
Info ("Ce transfert a été déjà payé.")
SINON
SC_Fiche.SAI_NomCli = TTransaction.NomCli
SC_Fiche.SAI_AdrCli = TTransaction.AdrCli
SC_Fiche.SAI_TelCli = TTransaction.TelCli
SC_Fiche.SAI_Montant = TTransaction.Montant
SC_Fiche.SAI_Pourc = TTransaction.Pourc
SC_Fiche.SAI_DateHeure = TTransaction.DateHeure
TTransaction.NomDest = SC_Fiche.SAI_NomDest
TTransaction.AdrDest = SC_Fiche.SAI_AdrDest
TTransaction.TelDest = SC_Fiche.SAI_TelDest
TTransaction.CodAgc = SC_Fiche.SAI_CodAgc
TTransaction.flag = Vrai
HModifie(TTransaction)
SELON Dialogue("Retrait effectué avec succès. Voulez-vous imprimer les détails du retrait?")
CAS 1
iAperçu()
iInitRequêteEtat(ETAT_Details_TTransaction, TTransaction.CodeTr)
iImprimeEtat(ETAT_Details_TTransaction)
CAS 2
FIN
RAZ()
DonneFocus(SAI_CodeRetrait)
BTN_retrait..Grisé = Faux
FIN
FIN
Image n°13 : Interface Etat Liste des Transactions
Image n°14 : Interface Etat Détail d'un Transfert
Notre étude intitulé « Conception et réalisation d'un système d'information informatisé pour la gestion des transferts de fonds dans une agence », Cas de l'Agence GADI/Mbandaka est arrivée à terme.
Ce travail cadre avec le besoin de moderniser la gestion des transferts de fonds au sein de l'Agence GADI de Mbandaka. En effet, ledit service se retrouve souventbuté au problème d'archivage, et de rapidité, pour ne citer que cela, des difficultés liés au traitement manuel dont l'agence recours.
Pour avoir des informations fiables sur le suivi des transferts de fonds, nous avons mis en place, par l'entremise de ce travail, une application capable d'assurer une gestion fiable et optimale des transferts de fonds au sein de l'agence GADI de Mbandaka, laquelle nous recommandons à l'agence d'adopter.
Excepté l'introduction et la conclusion, notre travail comporte quatre chapitres dont le premier est intitulé « APPROCHE THEORIQUE» où nous avons parlé de concepts informatiques de base et des notions sur la méthode MERISE.
Dans le deuxième chapitre intitulé « ETUDE D'OPPORTUNITE», nous avons présenté sommairement l'Agence GADI et posé le diagnostic de l'existant.
Le troisième chapitre est consacré à la « CONCEPTION DU NOUVEAU SYSTEME ». A l'aide de la méthode MERISE, nous avons conçu, tour à tour, le système d'informations organisées et le système d'information informatisé.
Dans le quatrième chapitre, une place a été réservée à l'implémentation ou la mise en oeuvre notre solution informatique. Pour ce faire, nous avons utilisé HFSQL comme système de gestion de base de données et WinDev pour écrire le programme.
Nous pensons, à travers cette étude, avoir atteint notre objectif, et nous affirmons les hypothèses que nous avions émises à l'introduction du présent travail. Le nouveau système mis en place présente des avantages parmi lesquels nous pouvons citer le gain de temps, la fiabilité des données, l'intégrité des données, le partage d'une seule base de données par plusieurs utilisateurs, etc. Ce qui permettra à l'Agence d'assurer une gestion efficiente.
A. Ouvrages
1. BORDAS, Science et Pratique de l'information, Agence d'Arc, Paris, 1986.
2. DANIEL M, Base données Méthodes pratique et mini-ordinateur, Ed. Bordeaux, Paris 1985.
3. DEBRAUWER L.T, UML2 Maîtrise la conception avec les design patterns coffret 2 livres, Eni, Paris, 2014.
4. GABAY J., GABAY D., UML2 Analyse et conception, collection Infopro, Dunod, Paris, 2008.
5. GERVAIS L., Apprendre la programmation orientée Objet, Eni, Paris, 2014.
6. GROUPILLE P. J. et ROUSSE J. M., Analyse informatique, Paris, éd Masson, 1993
7. MVIBUDULU K., & KONKEFIE I., Technique des bases de données, Ed. CRIGED/LA MANNE, Kinshasa 2012,
8. PC SOFT, Auto Formation WinDev17, version 17(2)-1211.
9. OBRIEN J., Les systèmes d'information de gestion, éd du Renouveau pédagogique, Montréal, 1995
10. TARDIEU H, NANCI D et PASCOT D., Conception d'un système d'information, Paris, éd d'organisation, 1985.
B. Dictionnaires
1. 36 Dictionnaires et Recueils de Correspondance, MediaDICO, Copyright (c) 1999-2005, L'@venture Multimédia, version électronique.
2. Jargon Informatique, version 1.3.6, avril 2006
3. Microsoft® Encarta® 2009 (c) 1993-2008, Microsoft Corporation.
C. Notes de cours
1. ISAKATONGA L. Justin, « Gestion d'un Centre de Traitement Informatique », inédit, G3 INFO, Université de Mbandaka, Mbandaka, 2019-2020.
2. ISAKATONGA L. Justin, « Techniques de Base de Données », inédit, G2 INFO, Université de Mbandaka, Mbandaka, 2018-2019.
3. MUTONI T. Macaire, « Initiation au Langage WinDev17 », inédit, G2 INFO, Université de Mbandaka, Mbandaka, 2018-2019.
D. Webographie
0.3. Choix Et Intérêt Du Sujet 2
0.4. Méthodes et techniques utilisées 2
0.7. Difficultés rencontrées 3
CHAPITRE I : APPROCHE THEORIQUE 4
1.1.3. Caractéristiques d'un système 5
1.2.2. Rôle d'un système d'information 6
1.2.3. Typologie des systèmes d'information 6
1.3.2. Qualités d'un système informatique 7
1.3.3. Typologie des systèmes informatiques 7
1.4. BASES DES DONNEES ET SYSTEME DE GESTION DES BASES DES DONNEES 8
1.4.2. Système de gestion des bases des données (SGBD) 12
1.5. NOTIONS SUR LA METHODE MERISE 13
1.5.1 Historique de la méthode 13
1.5.2. Caractéristiques de MERISE 14
1.5.3. Cycles de la méthode MERISE 16
1.6.4. Définition des concepts et formalismes utilisés dans la méthode MERISE 18
CHAPITRE II : ETUDE D'OPPORTUNITE 24
2.1. PRESENTATION DU SYSTÈME ÉTUDIÉ 24
2.1.4. Situation géographique 25
2.1.5. Structure organique et fonctionnement 25
2.1.6. ORGANIGRAMME DE L'ENTREPRISE 27
2.2. DIAGNOSTIC DE L'EXISTANT 28
2.2.1. Analyse de l'existant 28
2.2.2. Critique de l'existant 33
2.2.3. Propositions et choix de la solution 33
CHAPITRE III : CONCEPTION DU NOUVEAU SYSTEME 35
3.1. SYSTEME D'INFORMATION ORGANISE (SIO) 35
3.1.1. Objet et contenu du SIO 35
3.1.3. Etape organisationnelle 46
3.2. SYSTEME D'INFORMATION INFORMATISE (SII) 51
3.2.1. Objet et contenue du SII 51
Chapitre IV : RÉALISATION DU NOUVEAU SYSTÈME 65
4.1. OUTILS DE MISE EN OEUVRE DE LA SOLUTION INFORMATIQUE 65
4.1.1. Système de gestion de bases de données utilisé 65
4.1.2. Langage de programmation utilisé 65
4.2. PRESENTATION DES RESULTATS 67
4.2.1. Présentation de quelques interfaces d'entrée 67
4.2.2. Présentation d'un extrait du code 70
4.2.3. Présentation de quelques états 72
* 1 DOMINIQUE N., BERNARD E., Ingénierie de système d'information merise deuxième génération, Cydex, Paris, 1998. p. 542.
* 2 NACI D. et ESPINACE B., op. cit., p. 68.
* 3 COLLEGE A., HUGUES J, LA ROCHE B, Merise, Méthode de conception, Ed. Bordons, Paris, 1987, p.15.
* 4 DIONSI D., L'essentiel sur MERISE, Ed. Eryolles, Paris, 1994, p. 24.
* 5 NANCI D., ESPINASSE B., Mérise 2ème génération dernière, Ed. Eyrolles, p.184.
* 6 KABASELE ; « Notes de cours de Technique de Base de données »,G3 info, ISP/Gombe, Kinshasa, 2012-2013.
* 7 POMET G., TAUCHE, Merise et Technique Merise avancée, éd. D'organisation, Paris, 1999.
* 8 KABASELE, op. cit.
* 936 Dictionnaires et Recueils de Correspondance, op. Cit.
