Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des travaux informatique.

REPUBLIQUE TOGOLAISE
---------------------------
Travail - Liberté - Patrie
Institut Africain d’Informatique – Représentation
du TOGO (IAI-TOGO)
Tel : 22 20 47 00
E-mail : iaitogo@iai-togo.com / iaitogo@yahoo.fr
Site Web : www.iai-togo.com
07 BP 12456 Lomé 07, TOGO
Médiasoft
Sagbado
Tel : 22 20 17 29 / 99 47 06 39
E-mail :mediasofthome@yahoo.fr
Site web : www.mediasofthome.com
BP : 1331 Lomé-TOGO
PROJET DE FIN D’ETUDES POUR L’OBTENTION DU DIPLOME
D’INGENIEUR DES TRAVAUX INFORMATIQUES
OPTION : GENIE LOGICIEL
MISE EN PLACE DES MODULES DE
GESTION DE LA CAISSE ET DE
L’EPARGNE POUR UNE APPLICATION
DE MICROFINANCE
Période : Du 26 Juin 2017 au 22 Septembre 2017
Rédigé et soutenu par :
AGOTSI Komi Gédéon Cyrille
Etudiant en troisième année
Année universitaire : 2016-2017
SUPERVISEUR
M.DAVON Essè
Enseignant à l’IAI-TOGO
MAITRE DE STAGE
M. ABOLO-SEWOVI Komi R.
Consultant en informatique
MINISTERE DE LA PLANIFICATION
DU DEVELOPPEMENT

Mise en place des modules de gestion de la caisse et de l’épargne pour une application de microfinance Dédicace
Rédigé par AGOTSI Komi Gédéon Cyrille
i
DEDICACES
A mon père AGOTSI Tadogbè et à ma mère SOVON Afi Mawunyo
Je ne saurais exprimer l’immense amour que je vous porte, ni le
sentiment de profonde gratitude que je ressens pour tous les efforts et
les sacrifices que vous n’avez jamais cessé de consentir pour mon
instruction.
C’est à travers vos critiques que je m’améliore chaque jour. J’espère
avoir répondu à vos attentes.
A ma sœur Ruth et mes frères Dom et Gildas
Veuillez accepter l’expression de ma profonde gratitude pour vos
encouragements et affections.
Aux autres membres de ma famille
Merci pour tous vos conseils, soutiens, prières et toute l’attention que
vous m’avez toujours accordée.
A mes amis, camarades
Vous m’avez incité à viser loin, je vous en suis reconnaissant.

Mise en place des modules de gestion de la caisse et de l’épargne pour une application de microfinance Remerciements
ii
REMERCIEMENTS
Nous remercions d’abord Dieu le Tout puissant.
Nous tenons ensuite à exprimer nos sincères gratitudes et remerciements, au terme
de ce travail :
 A M. AGBETI Kodjo, Représentant résident de l’IAI-TOGO pour les efforts qu’il
ne cesse de déployer pour cet institut ;
 A M. AGBAHE Yaovi, le Directeur de Médiasoft pour nous avoir accepté et mis
à notre disposition les moyens logistiques et administratifs nécessaires pour le
succès de ce projet ;
 A M. ABOLO-SEWOVI Komi R., Ingénieur informaticien, Consultant à
Médiasoft, Enseignant à l’UCAO-UUT pour sa sympathie, sa disponibilité à
répondre à nos inquiétudes et sa rigueur dans le suivi de ce projet ;
 A M. DAVON Essè, Enseignant à l’IAI-TOGO pour ses remarques, ses critiques
qui ont contribué à la réussite du projet ;
 A M. AMEYIKPO Kossi Nicolas, Directeur des études à l’IAI-TOGO, pour
l’encadrement fourni afin que notre formation soit complète ;
 Au corps professoral de l’IAI-TOGO pour la qualité de la formation ;
 A mes camarades de la promotion 2014 – 2017 pour l’esprit de compétition qui
a marqué notre promotion en particulier M. ADEGNYON kofi Isidore;
 A tous ceux qui ont participé de près et de loin à la réalisation de ce travail.

Mise en place des modules de gestion de la caisse et de l’épargne pour une application de microfinance Avant-propos
iii
AVANT-PROPOS
L’Institut Africain d’Informatique (IAI) est une institution régionale, créée en 1971 à
Fort-Lamy, actuelle N’Djamena, capitale de la République de Tchad par onze (11) pays
africains à savoir le Bénin, le Burkina Faso, le Cameroun, la Côte d’Ivoire, la
Centrafrique, la République du Congo, le Gabon, le Niger, le Sénégal, le Tchad et le
Togo. Son siège se trouve à Libreville au Gabon. L’IAI forme des Ingénieurs
Informaticiens à Libreville et des Ingénieurs des Travaux Informatiques dans ses
représentations.
L’IAI-TOGO est ouvert depuis 2002 et forme en trois (3) ans des Ingénieurs des
Travaux Informatiques dans deux filières : Génie Logiciel (GL) et Système & Réseaux
(SR). Il intègre à la fin de cette formation, un stage de trois (03) mois en entreprise
pour l’obtention du diplôme d’ingénieur des travaux informatiques. L’objectif de ce
stage est de permettre aux étudiants de mettre en pratique les connaissances
acquises au cours de la formation, afin de devenir des ingénieurs efficaces et qualifiés
sur le marché de l’emploi.
Dans cet ordre d’idées, notre stage a été effectué dans les locaux du cabinet
Médiasoft.

Mise en place des modules de gestion de la caisse et de l’épargne pour une application de microfinance Résumé
iv
RESUME
Ce mémoire est le résultat du stage de fin de formation effectué au sien de Médiasoft
dans le but d’être attitré Ingénieur des travaux informatiques.
Pendant notre stage, nous avons eu à mettre en place deux modules ms-epargne et
ms-caisse dont le premier module pour la gestion de l’épargne et le second pour la
gestion de la caisse.
Le premier module permettra de paramétrer les produits épargnes et de créer les
comptes membres, le second module permettra de gérer les opérations de caisses.
Ces modules multilingues, multidevises, seront réutilisés dans d’autres applications
développées par Médiasoft. Ils faciliteront dorénavant le travail aux développeurs qui
n’auront plus à développer à chaque fois qu’ils voudront gérer l’épargne et la caisse,
mais juste intégrer nos modules. Toutes ces fonctionnalités ont été regroupées dans
le thème : « La mise en place des modules de gestion de la l’épargne et la caisse
pour une application de microfiance ».
Les objectifs de ce système sont multiples mais peuvent être résumé en une seule
phrase : la gestion modulaires des activités de création des comptes épargne et des
opérations relatives à la caisse dans une microfinance
Ce mémoire relatera sommairement les étapes qui ont conduit à la mise en place de
ce système.

Mise en place des modules de gestion de la caisse et de l’épargne pour une application de microfinance Abstract
v
ABSTRACT
This dissertation is the result of the end-of-training internship at Mediaasoft with the
aim of being a Computer Engineer.
During our internship, we had to set up two modules ms-epargne and ms-caisse
including the first module for the management of savings and the second for the
management of the fund.
The first module will be used to configure the savings products and create the member
accounts. The second module will manage the caisse operations. These multilingual,
multi-currency modules will be reused in other applications developed by Médiasoft.
They will now facilitate work for developers who will no longer have to develop each
time they want to manage savings and cash, but just integrate our modules. All these
features have been grouped into the theme: "Setting up the savings management
modules and the fund for a microfiance application".
The objectives of this system are multiple but can be summarized in a single sentence:
the modular management of the activities of creation of savings accounts and
operations related to the fund in a microfinance
This dissertation will briefly summarize the steps that led to the establishment of this
system.

Mise en place des modules de gestion de la caisse et de l’épargne pour une application de microfinance Sommaire
vi
SOMMAIRE
DEDICACES.................................................................................................................i
REMERCIEMENTS .................................................................................................... iii
AVANT-PROPOS....................................................................................................... 1
RESUME .................................................................................................................... 1
ABSTRACT ................................................................................................................ 1
INTRODUCTION GENERAL...................................................................................... 1
LISTE DES PARTICIPANTS AU PROJET ................................................................. 2
LISTE DES TABLEAUX.............................................................................................. 3
LISTE DES FIGURES ................................................................................................ 4
GLOSSAIRE............................................................................................................... 6
PARTIE 1 : CAHIERS DE CHARGES …………………………………………………….7
INTRODUCTION ........................................................................................................ 8
1. PRĖSENTATIONS ................................................................................................. 9
2. THEME DE STAGE.............................................................................................. 14
3. ĖTUDE DE L’EXISTANT ...................................................................................... 17
4. CRITIQUES DE L’EXISTANT............................................................................... 19
5. PROPOSITIONS DE SOLUTIONS....................................................................... 21
6. CHOIX DE SOLUTIONS....................................................................................... 26
7. PLANNIG PRĖVISIONNEL DE RĖALISATION.................................................... 28
CONCLUSION.......................................................................................................... 30
PARTIE 2 : ANALYSE ET CONCEPTION……………………………………………….32
INTRODUCTION ...................................................................................................... 33
1. PRESENTATION DE LA METHODE D’ANALYSE.............................................. 34
2. PRESENTATION DE L’OUTIL DE MODELISATION........................................... 38
3. ETUDE DETAILLE DE LA SOLUTION................................................................. 40
CONCLUSION.......................................................................................................... 96
PARTIE 3 : REALISATION ET MISE ENŒUVRE………….…………………………..96
INTRODUCTION ...................................................................................................... 98
1. MISE EN ŒUVRE ................................................................................................ 99
2. PRESENTATION DE L’APPLICATION .............................................................. 110
3. PLANNING DE REALISATION........................................................................... 129
PARTIE 4 : GUIDE D'EXPLOITATION ………………………….……………………..129
INTRODUCTION .................................................................................................... 132

Rédigé par AGOTSI Komi Gédéon Cyrille vii
1. CONFIGURATION LOGICIELLE ET MATERIELLE........................................... 133
2. DEPLOIEMENT ET SUIVI.................................................................................. 138
CONCLUSION........................................................................................................ 142
PARTIE 5: GUIDE D'UTILISATION …………………………………………………….142
INTRODUCTION .................................................................................................... 144
1. PRESENTATION DE L’APPLICATION .............................................................. 145
2. MAINTENANCE ................................................................................................. 152
CONCLUSION........................................................................................................ 153
CONCLUSION GENERALE ................................................................................... 154
BIBLIOGRAPHIE.................................................................................................... 155
TABLES DES MATIERES ...................................................................................... 157

Mise en place des modules de gestion de la caisse et de l’épargne pour une application de microfinance
Rédigé par AGOTSI Komi Gédéon Cyrille 1
Introduction
général
INTRODUCTION GENERAL
La société actuelle est un ensemble d’organisations caractérisées par l’esprit de
compétitivité et la tendance vers l’émergence sous tous ses aspects. La population de
plus en plus importante, il est judicieux d’avoir les moyens appropriés pour satisfaire
avec efficacité et en un temps record les besoins sans cesse grandissants. On assiste
alors à la gestion de l’information en grande masse. Chaque structure qui désire offrir
ses produits ou services à la population doit user des moyens efficaces afin
d’améliorer son mécanisme de prise de décisions critiques dans les domaines
opérationnels et stratégiques, ses performances financières et de répondre mieux aux
besoins de sa clientèle dans le but de défier la concurrence. Comment gérer avec
efficacité et sans ambiguïté, les besoins d’une telle population? Faces à ce défi majeur,
aucune organisation ne reste indifférente aux prouesses de la technologie.
Par conséquent, dans le cadre du cycle d’Ingénieur des Travaux Informatiques,
l’Institut Africain d’Informatique représentation du TOGO (IAI-TOGO) a mis en place,
pour les étudiants de troisième (3ème) année, un stage pratique de trois (03) mois en
entreprise. Son objectif est la mise en pratique des connaissances en analyse et
programmation acquises durant notre formation en réalisant un projet concret, qui
devra fournir une application fiable et prête à l’emploi.
Dans le cadre de mon stage de fin de formation effectué à Médiasoft du 26 Juin au 22
Septembre 2017, ce projet m’a donc été confié.
Ma mission était de développer deux modules dont le premier pour la gestion de
l’épargne et le second pour la gestion de la caisse multilingue, multidevise, sécurisé
,générique qui sera réutilisé dans d’autres applications de microfinance développées
par Médiasoft, d’où le thème de mon stage : MISE EN PLACE DES MODULES DE
GESTION DE LA CAISSE ET DE L’EPARGNE POUR UNE APPLICATION DE
MICROFINANCE.
Ce document sera donc constitué de cinq (05) parties à savoir : le cahier des charges,
l’analyse et la conception, la réalisation et mise en œuvre, l’exploitation et l’utilisation.

Liste des
participants
2
LISTE DES PARTICIPANTS AU PROJET
Tableau 1 : liste des participants au projet
Intervenants Fonctions Rôles
AGOTSI Komi Gédéon Cyrille
Etudiant en 3ème année
Génie Logiciel / IAI-TOGO
Réalisateur
M. ABOLO-SEWOVI Komi R.
Consultant à Médiasoft Maître de stage
M. DAVON Essè Enseignant à l’IAI-TOGO Superviseur IAI-TOGO

Liste des
tableaux
3
LISTE DES TABLEAUX
Tableaux Pages
Tableau 1 : liste des participants au projet ............................................................................................. 2
Tableau 2 : Glossaire ............................................................................................................................... 6
Tableau 3 : Coût matériel...................................................................................................................... 23
Tableau 4 : Coût logiciel ........................................................................................................................ 24
Tableau 5 : Coût humain ....................................................................................................................... 25
Tableau 6 : Coût total............................................................................................................................ 25
Tableau 7 : Planning prévisionnel de réalisation du projet................................................................... 28
Tableau 8 : Cas d'utilisation du système ............................................................................................... 43
Tableau 9 : Structuration de cas d'utilisation en package..................................................................... 46
Tableau 10 : Description de la classe « Produit ».................................................................................. 93
Tableau 11 : Description de la classe « ProduitEpargne » .................................................................... 93
Tableau 12 : Description de la classe « ParametreDat »....................................................................... 94
Tableau 13 : Description de la classe « Guichet »................................................................................. 94
Tableau 14 : Description de la classe « Devise »................................................................................... 95
Tableau 15 : Description de la classe « JourneeOuverte ».................................................................... 95
Tableau 16 : Planning de réalisation de l’application.......................................................................... 129
Tableau 18 : Configurations matérielle requise .................................................................................. 133
Tableau 19 : Configuration logicielle................................................................................................... 134
Tableau 20 : Cahier des évènements .................................................................................................. 141
Tableau 21 : Maintenance des erreurs courantes............................................................................... 152

Liste des
figures
4
LISTE DES FIGURES
Figures Pages
Figure 1 : Organigramme de Médiasoft ................................................................................................ 12
Figure 2 : Plan de localisation de Médiasoft ......................................................................................... 13
Figure 3 : Diagramme de dépendance entre modules.......................................................................... 26
Figure 4 : Diagramme de Gantt du projet ............................................................................................. 29
Figure 5 : Logo UML............................................................................................................................... 35
Figure 6 : Processus de développement en Y........................................................................................ 37
Figure 7 : Logo PowerAMC.................................................................................................................... 38
Figure 8 : Diagramme de contexte statique du système ms-epargne-caisse ....................................... 42
Figure 9: Figure illustrant un diagramme de cas d'utilisation............................................................... 46
Figure 10 : Diagramme de cas d'utilisation « Gestion de la sécurité » ................................................. 47
Figure 11 : Diagramme de cas d'utilisation « Paramétrage produits financiers » ................................ 48
Figure 12 : Diagramme de cas d'utilisation « Gestion des contrats »................................................... 48
Figure 13 : Diagramme de cas d'utilisation « Gérer comptes membres»............................................. 49
Figure 14 : Diagramme de cas d'utilisation « Gestion guichets» ......................................................... 49
Figure 15 : Diagramme de cas d'utilisation « Gestions de la caisse»................................................... 50
Figure 16 : Diagramme de cas d'utilisation « Paramétrage »............................................................... 50
Figure 17 : Diagramme de cas d'utilisation « Gestion des transferts »................................................. 51
Figure 18 : Diagramme de cas d'utilisation « Communs aux acteurs »................................................. 52
Figure 19 : Diagramme d'activités « s'authentifier » ........................................................................... 64
Figure 20 : Diagramme d'activités « Gérer produit épargne».............................................................. 65
Figure 21 : Diagramme d'activités «Mettre à jour taux de change d’une devise ».............................. 66
Figure 22 : Diagramme d'activités « Affecter utilisateur à un guichet ».............................................. 67
Figure 23 : Diagramme de séquences « s’authentifier »....................................................................... 68
Figure 24 : Diagramme de séquences «Gérer produit épargne »......................................................... 69
Figure 25 : Diagramme de séquences « Mettre à jour taux de change d’une devise »........................ 70
Figure 26 : Diagramme de séquences du cas d’utilisation «Effectuer retrait » ................................... 71
Figure 27 : Diagramme d'états « EmployeGuichet »............................................................................ 72
Figure 28 : Diagramme d’états « Contrat »........................................................................................... 73
Figure 29 : Diagramme de classes participantes des cas d’utilisation « Gérer compte épargne et gérer
compte part sociale»............................................................................................................................. 74
Figure 30 : Diagramme de classes participantes du cas d’utilisation « Gérer contrats » ..................... 74
Figure 31 : Diagramme de packages du système ms-epargne-caisse................................................... 76
Figure 32 : Modèle de spécification logicielle du système.................................................................... 79
Figure 33 : Diagramme de déploiement................................................................................................ 81
Figure 34 : Diagramme de composants................................................................................................. 82
Figure 35 : Diagramme de classe du package sécurité......................................................................... 84
Figure 36 : Diagramme de clase du package paramétrage ................................................................... 84
Figure 37 : Diagramme de classe du package paramétrage des produits financiers............................ 85
Figure 38 : Diagramme de classe du package gestion des comptes membres .................................... 86
Figure 39 : Diagramme de classe du package gestion des contrats...................................................... 87
Figure 40 : Diagramme de classe du package gestion des guichets...................................................... 88
Figure 41 : Diagramme de classe du package gestion de la caisse....................................................... 89
Figure 42 : Diagramme de classe du package gestions des transferts.................................................. 90
Figure 43 : Diagramme de classe global du système............................................................................. 92

Liste des
figures
5
Figure 44 : Logo PostgreSQL................................................................................................................ 100
Figure 45 : Logo de Maven.................................................................................................................. 101
Figure 46 : Logo d’IReport ................................................................................................................... 101
Figure 47 : Logo d’Apache Shiro.......................................................................................................... 102
Figure 48 : Logo de Glassfish............................................................................................................... 102
Figure 49 : Logo de Java EE.................................................................................................................. 103
Figure 50 : Logo d’EclipseLink.............................................................................................................. 103
Figure 51 : Logo primefaces ................................................................................................................ 104
Figure 52 : Logo de Log4j..................................................................................................................... 105
Figure 53 : Architecture matérielle des modules................................................................................ 106
Figure 54 : Architecture logicielle........................................................................................................ 107
Figure 55 : Maquette de chaque module............................................................................................ 111
Figure 56 : Contenu du fichier glassfish.xml du module ms-epargne................................................. 115
Figure 57 : Contenu du fichier de persistance.xml du module ms-epargne ....................................... 115
Figure 58 : Contenu du fichier de persistance.xml (suite) du module ms-epargne............................ 116
Figure 59 : Contenu du fichier de persistance.xml (Fin) du module ms-epargne............................... 116
Figure 60 : Interface de paramétrage de produit épargne ................................................................. 118
Figure 61 : Interface de création de compte épargne......................................................................... 119
Figure 62 : Interface de mise en place d'un dépôt à terme ................................................................ 120
Figure 63 : Page d’affectation utilisateur............................................................................................ 122
Figure 64 : Listes des comptes inactifs................................................................................................ 127
Figure 65 : reçu d'opération de dépôt................................................................................................. 128
Figure 66 : Diagramme de Gantt de réalisation de l'application......................................................... 130
Figure 67 : Interface d'installation de PostgreSQL 9.5.3 ..................................................................... 135
Figure 68 : Interface d'administration de PostgreSQL 9.5.3 ............................................................... 135
Figure 69 : Interface de démarrage de glassfish 4.1.1 ........................................................................ 137
Figure 70 : Interface d'administration de Glassfish 4.1.1.................................................................... 137
Figure 71 : menu application de glassfish ........................................................................................... 138
Figure 72 : Interface des applications développées............................................................................ 139
Figure 73 : Interface de déploiement d'application............................................................................ 139
Figure 74 : Logo de Bonobo server...................................................................................................... 141
Figure 75 : Fenêtre de connexion pour le module épargne................................................................ 145
Figure 76 : Bouton de déconnexion .................................................................................................... 149
Figure 77 : Bouton ajouter .................................................................................................................. 149
Figure 78 : Bouton langue ................................................................................................................... 149
Figure 79 : bouton modifier, enregistrer et annuler........................................................................... 149

6
GLOSSAIRE
Tableau 2 : Glossaire
ACRONYMES DEFINITIONS
IAI Institut Africain d’Informatique
SFD Système financier décentralisé
UML Unified Modeling Language
EDI Environnement de Développement Intégré
SGBD Système de Gestion de Bases Données
POO Programmation Orientée Objet
SE Système d’Exploitation

6
PARTIE 1
CAHIER DES CHARGES

Cahier des
charges
8
INTRODUCTION
Le cahier des charges est le document de référence lors d’un projet. Il permet de
formaliser les besoins techniques et fonctionnels en détaillant au mieux les
fonctionnalités et les contraintes auxquels devra répondre le logiciel final.
Il permet donc d’expliciter les besoins aux différentes parties prenantes du projet et
donc de s’assurer que ceux-ci sont d’accord sur les spécificités des objectifs et
résultats attendus du projet.
Le cahier de charges servira de base dans la définition des spécifications et dans la
conception de l’application à réaliser. Par ailleurs, il fera objet de référence lors de
l’évaluation du produit fini. Les grandes lignes de ce premier document porteront sur
la présentation du contexte de stage, le thème de stage, l’étude de l’existant, la critique
de l’existant, les propositions de solutions, le choix de solution et le planning
prévisionnel de réalisation.

Cahier des
charges
9
CHAPITRE 1
PRĖSENTATIONS
1.1. BREVE PRĖSENTATION DE L’IAI-TOGO
En application de la décision du conseil d’administration de décentraliser l’Institut
Africain d’Informatique, la Représentation du Togo (IAI-TOGO) a ouvert ses portes le
24 octobre 2002. L’accord d’établissement entre la République Togolaise et l’Institut
Africain d’Informatique a été signé le 12 mai 2006. Sous la Tutelle du ministère de la
planification du développement, L’IAI-TOGO propose actuellement le cycle ingénieur
des travaux informatiques dans deux filières : Génie logiciel et Système Réseaux. Au
terme de cette formation les diplômés peuvent poursuivre leurs études supérieures au
siège au GABON ou dans les universités occidentales ou asiatiques (UTBM en France,
Université-Laval du Québec au CANADA, etc.) ou dernièrement avec le master
international en informatique lancé au Togo par IAI-TOGO en partenariat avec
l’Université de Lomé et l’UTBM en France.
L’IAI-TOGO est situé à Lomé dans l’immeuble du CENETI au quartier Nyekonakpoè.
1.2. PRESENTATION DU « CENTRE D’ACCEUIL »
Pour notre étude, le cabinet Médiasoft nous a servi de cadre de recherche. Pour ce
faire, il nous revient d’étudier le statut, les missions, les activités, les réalisations,
l’organigramme, le parc informatique et le plan de localisation dudit centre.
1.2.1. Statut
Opérateur économique N° 1000211052, Médiasoft est créé en Septembre
2003 de la rencontre de professionnels ayant en commun la passion des
projets informatiques et ayant choisi d’investir dans les domaines de
l’expertise pédagogique et technique pour être au cœur des changements

Cahier des
charges
10
et des nouveautés informatiques dans un monde technologique en
constante évolution.
Médiasoft était un établissement informatique spécialisé dans le
développement de logiciels de gestion, dans la création de sites web et
fourniture de matériels et consommables informatiques.
Depuis 2012, Médiasoft devient une société de Consulting et Intégration de systèmes,
de Développement d’applications, de Formation et de conseil professionnel réunissant
plusieurs compétences sous une même entité commerciale afin de focaliser
principalement son activité sur le développement et la mise en œuvre de système
d’information intern et /intranet.
1.2.2. Mission
 Effectuer permanemment des recherches pour anticiper les attentes du client ;
 Rechercher l’excellence ;
 Localiser les besoins et y apporter des solutions informatiques;
 Doter les entreprises de logiciels performants et qui répondent aux règles de
gestion de ces structures et surtout à prix raisonnables.
1.2.3. Activités
Les activités de Médiasoft se résument en :
 La conception et le développement d’application informatiques de gestion ;
 La conception de sites web ;
 La distribution de matériels et consommables informatiques ;
 Le câblage et intégration de réseaux informatique ;
 La formation et l’audit informatique ;
 Maintenance.

Cahier des
charges
11
1.2.4. Quelques réalisations
 MICROFINA : Standard et WEB, Gestion des institutions de Microfinance ;
 HOSTO : Application de gestion des hôpitaux ;
 GESCOM : Gestion commerciale ;
 MICROFINA Immo : Gestion et comptabilisation des immobilisations ;
 PAIE-RH : Gestion des ressources humaines et de la paie ;
 SMS BANKING : Plateforme d’interopérabilité financière via SMS ;
 MOP Manager : Logiciel de gestion de la main d’œuvre portuaire ;
 Caisse Mobile : Utilitaire de caisse, à travers les smartphones et les
tablettes ;
1.2.5. Organigramme
Médiasoft dispose d’un personnel très dynamique qui est au cœur de
toutes ses activités et qui se compose comme suit :
 La Direction : le Directeur Général assisté par une assistante de Direction ;
 Le Service Génie Logiciel : composé de onze (11) Ingénieurs développeurs
dont le Chef Projet ;
 Le Service Marketing et Support : composé de sept (07) personnes ;
 Le Service Comptabilité : composé d’une (01) personne ;
 Le Service Maintenance et Réseau : composé de deux (02) techniciens;
 Le Service Distribution: composé de deux (02) personnes.
Ainsi l’organigramme de Médiasoft se présente comme suit :

Cahier des
charges
12
Figure 1 : Organigramme de Médiasoft
1.2.6. Le service d’accueil
Afin de nous permettre de mener à bien notre travail Médiasoft nous a offert pour cadre
de stage le service Génie Logiciel. Ce service constitue l'un des plus importants
services car il est le pilier de la conception, du développement des applications
informatiques et sites web. Il regroupe en son sein deux subdivisions à savoir :
 Développeurs JAVA & Android ;
 Développeurs DELPHI, PHP,… ;
Il a pour attributions :
 La conception et développement d’applications informatiques de gestion ;
 La conception de sites web ;
 La maintenance et l’évolution des applications développées ;
 L’assistance technique et intervention aux niveaux des clients.
Directeur
Général
Service
Marketing &
Supports
Service Génie
Logiciel
Développeurs
JAVA &
ANDROÏD
Développeurs
(Delphi, PHP, ...)
Service
Comptabilité
Service
Maintenance
Service
Distribution
Assistante de
Direction

Cahier des
charges
13
1.2.7. Plan de localisation
Autrefois située sur la rue Radio Bonne Nouvelle (Cassablanca), elle se
localise aujourd’hui dans le quartier Sagbado, à côté de la maison du chef canton ou
de l’Ecole Primaire Publique d’Aflao Sagbado. Ses contacts sont donnés ci-dessous :
BP : 13331 Lomé-Togo
Téléphone : (+228) 22 20 17 29/99 47 06 39
Email : mediasofthome@yahoo.fr
Figure 2 : Plan de localisation de Médiasoft

Cahier des
charges
14
CHAPITRE 2
THEME DE STAGE
2.1. PRESENTATION DU SUJET
L’approche modulaire d’un projet informatique permet au logiciel d’avoir une meilleure
lisibilité et d’être facile à maintenir. Les développeurs au lieu de créer une application
monolithique se servent de brique réutilisable, pratique pour le travail en équipe.
Médiasoft conscient de la taille grandissante, de la complexité à gérer et à maintenir
son logiciel monolithique Microfina, a voulu faire un découpage de celui-ci en
modules réutilisables et intégrables. Il nous a donc été confié le développement de
deux des modules prévus. D’où notre thème de stage un « La mise en place des
modules de gestion de la caisse et de l’épargne pour une application de
microfinance».
2.2. PROBLEMATIQUE DU SUJET
Conscient de l’enjeu de l'automatisation des SFD, Médiasoft, éditeur de logiciel avait
conçu un logiciel adapté aux besoins des SFD ( gestion de la caisse, de l’épargne, du
crédit, etc…) qui a été développé en Delphi en premier puis une refonte a été faite en
J2EE destinée à remplacer la version antérieure à terme afin de satisfaire les besoins
pressants des clients et d’en profiter des avantages qu’offre une application J2EE.
Il se fait d’une part que lors de la refonte, une approche de conception modulaire,
générique et adaptable aux besoins spécifiques des SFD n’a pas été adoptée
permettant ainsi la réutilisation dans l’implémentation des fonctionnalités de caisse et
de l’épargne dans d’autres applications développées par Médiasoft comme la gestion
des hôpitaux, des écoles favorisant l’amélioration du code et permettant le
déploiement en modules selon les besoins des SFD.
D’autre part l’expansion et la commercialisation du logiciel est limitée par les
contraintes de langues, de devises, de réglementations bancaire et comptable et des

Cahier des
charges
15
besoins spécifiques à la politique de gestion des clients comme des exigences
fonctionnelles non prévu dans le logiciel de départ et des particularités des produits
financiers.
Ainsi Médiasoft dans la quête de fournir à ses client un logiciel paramétrable,
d’améliorer le développement interne de ses produits, de commercialiser son logiciel
sans barrière s’intéresse aux préoccupations suivantes :
 Comment rendre générique l’application adaptable aux besoins spécifiques des
SFD ?
 Comment faciliter la réutilisabilité du code ?
 Comment étendre la commercialisation de Microfina sans contrainte de langues
et ou de devises ?
 Comment faciliter le déploiement en module selon les besoins des SFD ?
C’est pour répondre à ces préoccupations que le cabinet Médiasoft nous a confié la
mission d’étudier les difficultés du système existant et de proposer des solutions
informatiques afin de combler les différentes aspirations
2.3. INTERET DU SUJET
2.3.1. Objectifs
Le projet a principalement pour objectif de développer en premier un module pour la
gestion de l’épargne et ensuite un autre module de gestion de la caisse, multilingues,
multidevises réutilisable et intégrable dans d’autres applications notamment Microfina.
Dans la perspective de satisfaire l’objectif principal, nous avons décelés ces objectifs
spécifiques :
 De mettre en sécurité les données traitées ;
 De paramétrer en fonction des devises les produits épargnes ;
 De gérer les contrats DAT
 De gérer les guichets;

Cahier des
charges
16
 D’internationaliser l’application ;
 Gérer les comptes des membres du SFD;
 Tenir une comptabilité des opérations (la comptabilisation des opérations
de caisse, des mouvements des comptes de gestions) ;
 Gérer les opérations de caisse ;
 Gérer les transferts de caisse vers caisse;
 De générer automatiquement des états ;
 Gérer les droits et accès des utilisateurs ainsi que la journalisation des
opérations qu’ils effectuent ;
 Sauvegarder et restaurer les données suite à un sinistre.
2.3.2. Résultats attendus
Les résultats attendus sont :
 Des modules réutilisables et intégrables dans d’autres applications
développées ;
 Des modules déployés selon les besoins spécifiques des SFD ;
 La commercialisation du logiciel dans d’autres pays réalisée ;
 La qualité de communication des résultats améliorés (états et indicateurs
permettant de mieux orienter les décisions de gestion et de mieux maitriser les
risques encourues par le SFD);
 Une bonne diffusion de l’information aux clients effectuée (les clients des SFD
pourront suivre l’état de leur compte depuis un téléphone portable) ;
 Un gain de temps considérable effectué : l’automatisation du traitement des
données éliminera de facto des tâches comme les transcriptions manuelles ou
les saisies multiples d’une même donnée et permet ainsi des calculs rapides et
fréquents.

Cahier des
charges
17
CHAPITRE 3
ĖTUDE DE L’EXISTANT
Afin d’atteindre les objectifs spécifiques visés par le présent projet nous avons menés
des études qui nous ont permis d’avoir une idée réelle sur la manière dont les SFD
gèrent l’épargne et la caisse. Nous nous sommes basés sur les interviews des
développeurs de Médiasoft, des comptables et des agents des SFD pour rédiger cette
partie. Ainsi nous allons présenter le processus de traitement des opérations de
caisse et la gestion de l’épargne dans les SFD avec l’application existante Microfina.
3.1. PRESENTATION DES PROCESSUS
3.1.1. Gestion des produit épargnes
Une étape de paramétrage des produits épargnes permettant de spécifier les comptes
comptables et les différents frais liés aux produits est requis pour la création des
comptes aux clients qui peuvent être un compte part sociale ou un compte épargne
(dépôt à terme, dépôt a vue) permettant ainsi. Après avoir créé le compte le client
peut consulter son relevé de compte ou toutefois résilier son adhésion. Le client peut
également créer des comptes DAT qui sont des placements financiers à court ou
moyen terme, rémunérés et sécurisés.
3.1.2.A la caisse
Plusieurs opérations sont effectuées à la caisse telles que le payement de frais
d’adhésion, les opérations d’encaissement et décaissement de fonds suivant qu’elle
soit un dépôt, un retrait et d’autre opération divers. Ces opérations sont transcrites
dans un journal de caisse .A la fin de la journée comptable préalablement ouverte
s’effectue le billetage de caisse.

Cahier des
charges
18
3.1.2.1. Retrait d’épargne
On distingue plusieurs formes de décaissement. Ici, nous prenons en guise d'exemple
le retrait d'épargne. Il suit les mêmes procédures que les opérations d'encaissement à
la différence qu'il est enregistré sur une fiche de retrait et exige certaines vérifications.
D'abord la conformité de la photo du titulaire du compte avec celle de l'opérant ou la
procuration car seul le titulaire du compte ou un mandataire à qui le titulaire du compte
a donné une procuration peut faire des retraits. Ensuite, il est vérifié si le client a un
avoir lui permettant de faire le retrait. Enfin, l'agent procède au décaissement au profit
du client.
Rappelons des frais de tenue de compte sont prélevés sur le compte épargne.
3.1.2.2. Opérations d’encaissement
Le client qui désire faire un versement sur son compte se présente au guichet avec
son livret d'épargne et la somme qu'il souhaite verser. Il remet en premier lieu le livret
à l'agent du guichet. Ce dernier, à l'aide du numéro attribué au client et mentionné sur
le livret, identifie le compte sur le logiciel et ensuite prend des mains du client la somme
à verser. Ainsi la somme reçue est mentionnée aussi bien dans le livret que sur le
logiciel après contrôle avec le détecteur de faux billets. Enfin, un reçu est délivré au
client dont la souche sera envoyée à la comptabilité pour vérification.
3.1.2.3. Autres opérations
A part le dépôt, il y a aussi l’adhésion, le décaissement et l’encaissement de crédit et
des opérations divers (payements des factures fournisseurs, etc …).
Ces opérations effectuées à la caisse seront transcrites automatiquement dans un
journal de caisse, ceci permettra au comptable de faire un suivi des opérations et
d’éditer les relevés de compte des clients.

Cahier des
charges
19
CHAPITRE 4
CRITIQUES DE L’EXISTANT
4.1. LES POINTS FORTS
La gestion de l’épargne et de la caisse effectuée avec l’application décrite
précédemment montre bien les forces de cette dernières. Les règles de gestion sont
bien définies, les accès et droits sont sous contrôle. Les données sont protégées car
l’accès est soumis à un compte d’utilisateur et un mot de passe.
4.2. LES POINTS FAIBLES
4.2.1. Aspect généricité
Les clients, d’un SFD à l’autre, ont certains besoins spécifiques ; la conception initiale
rend difficile la prise en compte de ces spécificités de façon générique (dans la même
version); on se retrouve avec des versions différentes du même logiciel d’un SFD à
un autre. Ce qui rend la maintenance complexe.
4.2.2. Aspect réutilisabilité
Certaines fonctionnalités disponibles dans Microfina comme la caisse, la comptabilité,
la gestion des ressources humaines sont demandées dans d’autres applications
développées par Médiasoft, comme E-cole (gestion d’école), Hosto (gestion d’hôpital).
Mais puisque Microfina n’est pas découpé en modules, ces fonctionnalités déjà
existantes sont redéveloppées.

Cahier des
charges
20
4.2.4. Aspect modulaire
L’application étant monolithique oblige les clients exprimant le besoin de s’acquérir de
certaines fonctionnalités comme la caisse, l’épargne à payer le tout incluant d’autres
fonctionnalités comme la gestion des ressources humaines ; ce qui décourage certains
clients.
Le non découpage en modules fait qu’une modification du code a des répercussions
importantes sur le reste de l’application. La régression de code est très élevée.
4.2.5.Aspect fonctionnalités
L’expansion et la commercialisation du logiciel est limitée par les contraintes de
langues, de devises et de règlementations bancaires non prévues dans la conception
initiale.
L’application existante n’intègre pas des fonctionnalités permettant aux membres des
SFD de pouvoir suivre l’état de leur compte.

Cahier des
charges
21
CHAPITRE 5
PROPOSITIONS DE SOLUTIONS
5.1. EVALUATIONS TECHNIQUES DES SOLUTIONS
Pour répondre aux objectifs décrits plus haut, nous proposons trois (2) solutions.
5.1.1. Première solution : La maintenance de l’application existante
en intégrant les nouvelles fonctionnalités.
5.1.1.1. Description
Notre première solution consiste à maintenir l’application existante afin qu’elle soit
conforme aux exigences. Cette maintenance doit être à la fois curative et évolutive.
 Maintenance curative
Il s’agit de faire la revue du code dont l’objectif est de trouver des bugs ou des
vulnérabilités potentielles ou de corriger des erreurs d’analyse et de conception afin
d'améliorer la qualité, la maintenabilité et la sécurité du logiciel.
 Maintenance évolutive
Il consiste à mettre à jour l’application existante en ajoutant les nouvelles
fonctionnalités et en détachant les modules épargne et caisse afin qu’il soit réutilisable.
5.1.1.2. Avantages
Le temps étant un facteur important dans la réalisation du projet, la mise en place
d’une telle solution nous offre des gains considérables de temps car cette solution
s’appuie déjà sur ce qui est existant.

Cahier des
charges
22
5.1.1.3. Inconvénients
Bien que cette solution nous offre des avantages en temps et en coût, elle n’est pas
optimale car elle ne respecte pas les spécifications du cahier des charges. Elle sera
difficile à mettre en œuvre car les codes ne sont pas commentés et pourra entrainer
la déviation de la logique métier de l’application.
5.1.2. Deuxième solution : Le développement de deux modules
dont le premier gèrera l’épargne et le second la caisse
5.1.1.4. Description
Elle consiste à développer deux modules dont le premier gèrera l’épargne et le second
la caisse pouvant être intégrer comme composant logiciel dans toutes autres
applications.
5.1.1.5. Avantages
Ce module générique sera réutilisable et pourrait ainsi être intégrer dans toutes autres
applications nécessitant l’implémentation des fonctionnalités de gestion de la caisse
et de l’épargne. Elle tiendra compte aussi des nouvelles exigences, des particularités
des clients et des remarques faites lors du suivi de l’application existante.
5.1.1.6. Inconvénient
Le désavantage réside dans le fait que le temps de réalisation pourrait s’avérer
considérable.
5.2. EVALUATIONS FINANCIERES DES SOLUTIONS
5.2.1. Première solution
La première solution est évaluée à 2.000.000. F CFA.
Cette évaluation financière vient du contrat de maintenance que Médiasoft a signé
avec les SFD, pour une mise-à-jour.

Cahier des
charges
23
5.2.2. Deuxième solution
La réalisation de tout le projet nécessite un budget afin de financer les tâches à
exécuter. Le coût estimatif est donc scindé en trois (3) parties : le coût matériel, le coût
logiciel et le coût humain.
5.2.2.1. Cout matériel
Ici, nous explorerons le coût des matériels nécessaires à la mise en place des deux
modules (réalisation et déploiement).
Tableau 3 : Coût matériel
DESIGNATION EXIGENCE SOURCE P.U
(FCFA)
QTE COUT
(FCFA)
Serveur de
base des
données
HP 280 G1 - Intel
Core i3-4160 4
Go – HDD 1To -
DVD SuperMulti
- HD Graphics
4400 - GigE -
http://www.generation-
net.com/Ordinateur-de-
Marque/HP/fiche-
3928085-HP-280-G1---
Intel-Core-i3-4160-4-Go-
--HDD-1-To----
N0D96EA.html
446.700 1 446.700
Serveur
d’applications
HP 280 G1 - Intel
Core i3-4160 4
Go - HDD 500 Go
- DVD SuperMulti
- HD Graphics
4400 – GigE
http://www.generation-
net.com/Ordinateur-de-
Marque/HP/fiche-
3928085-HP-280-G1---
Intel-Core-i3-4160-4-Go-
--HDD-500-Go----
N0D96EA.html
356.850 1 356.850
Disque de
sauvegarde
HP RDX 2To
http://www.misco.fr
/hpe-rdx-x-1-2-to-
support-de-
stockage/p280
0027.htm
206.400 1 206.400

Cahier des
charges
24
Onduleur Onduleur EX
2200 RT 2U
Netpack
https://www.materiel.net/
onduleur/eaton-ex-
2200-rt-2u-netpack-
65948.html
598.935 1 598.935
Obtention d’IP
mensuel
Obtention
d’adresse IP
publique à CAFE
Informatique
Café informatique 10.000 24 240.000
TOTAL
1.848.885
Ce cout matériel sera quantifié en fonction du nombre des modules.
5.2.2.2. Coût logiciel
Nous explorerons ici le coût des logiciels ou programmes nécessaires à la mise en
place du module épargne (réalisation et déploiement) ;
Tableau 4 : Coût logiciel
DESIGNATION SOURCE COUT
UNITAIRE
Estimation pour 500
clients pour une année à
raison d’un envoi de
message par mois.
COÛT
(F CFA)
(Cout unitaire * Nombre
client* 12)
API SMS Moozisms.com 4F/message 24.000 24.000
5.2.2.3. Coût humain
Ici, nous explorerons le coût qu’il faut pour faire travailler les ressources humaines
pour la réalisation et le déploiement des deux modules.

Cahier des
charges
25
Tableau 5 : Coût humain
QUALITE NBRE TÂCHES
COÛT
HORAIRE HEURES
SOURCES COÛT
(F CFA)
Analyste-
Programmeur 1
Conception et
développement
de la plateforme
5.000
720
(8 heures
* 60 jours)
http://www.lej
ustesalaire.co
m/salaire-par-
poste/salaires
-stagiaire-
informatique.
php
3.600.000
Formateur 1 Formations des
utilisateurs
10.000 (2 heures
* 10
séances)
http://www.leju
stesalaire.com/
salaire-par-
metier/formatin
/salaires-
Formateur-
Logiciel.php
200.000
3.800.000
5.2.2.4. Coût total
Tableau 6 : Coût total
DESIGNATION MONTANT (F CFA)
Coût matériel 1.848.885
Coût logiciel 24.000
Coût humain 3.800.000
TOTAL 5.672.885

Cahier des
charges
26
CHAPITRE 6
CHOIX DE SOLUTIONS
6.1. SOLUTION RETENUE
Après l’exposition de nos études et analyses, Médiasoft a retenu la deuxième solution.
Celle qui consiste à développer des modules qui répondra aux besoins spécifiques.
En effet, outre l’accord de maitre de stage et des raisons à savoir les résultats de
l’étude du cahier des charges, les contraintes de temps, la généricité et la réutilisabilité
, nous ont motivé à choisir cette solution.
6.2. ETUDE LA SOLUTION RETENUE
6.2.1.Spécification technique
Le diagramme d’interaction de nos modules avec les autres modules prévus dans
Microfina se présente ci-dessous.
Figure 3 : Diagramme de dépendance entre modules

Cahier des
charges
27
6.2.1.1. Description de quelques modules
 Comptabilité : Module de gestion de la comptabilité ;
 Stock : Module de gestion du stock, utilise le module comptabilité ;
 Immo : Module de gestion des immobilisations, utilise le module comptabilité ;
 Performance sociale : Module de gestion de la performance sociale, utilise
les modules crédit et épargne

Cahier des
charges
28
CHAPITRE 7
PLANNIG PRĖVISIONNEL DE RĖALISATION
Le planning prévisionnel de notre travail se présente comme suit :
Tableau 7 : Planning prévisionnel de réalisation du projet
N° Nom de la tâche Durée Début Fin
1 Période d'insertion 3 jours Lun 26/06/17 Mer 28/06/17
2 Collecte d'informations 6 jours Jeu 29/06/17 Jeu 06/07/17
3 Elaboration du cahier de charge 6 jours Ven 07/07/17 Ven 14/07/17
4
Conception du premier module
(ms-epargne)
8 jours Lun 17/07/17 Mer 26/07/17
5
Conception du second module
(ms-caisse)
8 jours Jeu 27/07/17 Lun 07/08/17
6
Réalisation du premier module
(ms-epargne)
20 jours Lun 31/07/17 Ven 25/08/17
7
Réalisation du second module
(ms-caisse)
18 jours Mar 08/08/17 Jeu 31/08/17
8 Premier déploiement et test 2 jours Ven 01/09/17 Lun 04/09/17
9 Corrections et amélioration 5 jours Mar 05/09/17 Lun 11/09/17
10 finalisation de l'application 2 jours Mar 12/09/17 Mer 13/09/17
11
Rédaction du guide d'exploitation
et d'utilisation
4 jours Mer 13/09/17 Lun 18/09/17
12 Rédaction du mémoire 63 jours Mar 27/06/17 Jeu 21/09/17

Cahier des
charges
29
Figure 4 : Diagramme de Gantt du projet

Cahier des
charges
30
CONCLUSION
En somme, ce cahier des charges illustre d’une façon générale le projet ainsi que les
ressources nécessaires pour sa réalisation. L’objectif du cahier des charges étant la
compréhension des besoins et l’énumération des spécifications, il a donc été atteint.
En effet à ce stade le projet est prêt à être réalisé. Dans la suite, nous allons donc
aborder la conception du système.

Rédigé par AGOTSI Komi Gédéon Cyrille 31
PARTIE 2
ANALYSE ET CONCEPTION

Analyse et
conception
33
INTRODUCTION
Ce dossier d’analyse et de conception qui fait suite au cahier de charges constitue la
seconde phase de notre travail. Il représente une étape indispensable dans la
réalisation d’un projet informatique. Il décrit le fonctionnement du système
d’information à travers des abstractions présentées sous forme de modèles.
Dans le présent dossier, nous présenterons dans un premier temps notre méthode
d’analyse, dans un second temps l’outil de modélisation puis suivra enfin l’étude
détaillée de la solution.

Analyse et
conception
34
CHAPITRE 1
PRESENTATION DE LA METHODE D’ANALYSE
En conception de système, il existe plusieurs approches comme l’approche
fonctionnelle, l’approche objet etc. Dans la conception de la plateforme SYR, il a été
retenu l’utilisation d’une approche objet ; par conséquent avant la présentation des
outils utilisés pour la conception, il sera énuméré les raisons ayant poussé au choix
d’une approche objet.
1.1. JUSTIFICATION DU CHOIX D’UNE APPROCHE OBJET
L’approche objet désigne l’ensemble des méthodes et langages utilisés au cours du
cycle de vie du logiciel qui reposent sur la manipulation des objets. Nous en aurons
une vision :
 Externe définissant les actions qu’il sera possible de lui faire subir ;
 Interne dans laquelle seule, sa structure sera considérée.
Un logiciel est vu comme un ensemble d’objet qui coopère. Un autre concept qui est
très souvent lié à l’approche objet est celui de classe qui permet de regrouper les
propriétés communes des objets. C’est un modèle structurel d’objet à partir duquel il
est possible de fabriquer autant d’objets qu’il sera nécessaire. Ce concept est associé
à la notion de composants logiciels réutilisables facilitant la production des logiciels et
diminuant l’effort de tests. Cette approche intègre à la fois les aspects statiques et
dynamiques des logiciels. Elle favorise :
 la réutilisation des composants ;
 la stabilité dans le temps ;
 l’indépendance des données et des méthodes ;
 la construction par le couplage faible entre les composants ;

Analyse et
conception
35
L’aisance dans la maintenance des logiciels aidée par la facilité à circonscrire les
tâches à effectuer. L’approche objet pour pouvoir assurer ces tâches se base sur :
Un langage (pour s’exprimer clairement à l’aide des concepts objets) ;
Une démarche d’analyse et de conception objet ;
Pour implémenter l’approche objet, il a été retenu le langage UML couplée le
processus de développement 2TUP.
1.2. LE LANGAGE DE MODELISATION : UML 2.3
Langage de modélisation unifié, UML (Unified
Modeling Language) se définit comme un
langage de modélisation graphique et textuel
destiné à comprendre et décrire des besoins,
spécifier et documenter des systèmes, esquisser
des architectures logicielles, concevoir des
solutions et communiquer des points de vue.
Le langage UML s’articule autour de treize (13) diagrammes différents. Chacun d’eux
est dédié à la représentation d’un système logiciel suivant un point de vue particulier.
Par ailleurs, UML modélise le système suivant deux modes de représentation :
 Les diagrammes structurels ou statiques
 Les diagrammes d’interaction ou dynamiques
Ces deux représentations sont nécessaires et complémentaires pour schématiser la
façon dont est composé le système et comment ses composantes fonctionnent entre
elles.
Dans la modélisation des solutions informatiques, UML ne propose pas l’ordre qui doit
régir les diagrammes. C’est ainsi que les processus viennent appuyer le langage pour
parfaire l’approche objet.
Figure 5 : Logo UML

Analyse et
conception
36
1.3. PRESENTATION DU PROCESSUS 2TUP
Le 2TUP (2 Track Unified Process) est un processus de développement qui
implémente le Processus Unifié. Le Processus Unifié possède plusieurs traits
distinctifs :
 Il est construit sur UML ;
 Il est itératif et incrémental ;
 Il est centré sur l’architecture ;
 Il est conduit par les exigences de l’utilisateur ;
 Il est piloté par les risques.
Le processus 2TUP apporte une réponse aux contraintes de changement continuel
imposées aux systèmes d’information. En ce sens, il renforce le contrôle sur leurs
capacités d’évolution et de correction.
Le principe du 2TUP consiste à constater que toute évolution imposée au système
d’information peut se décomposer et se traiter parallèlement, suivant un axe
fonctionnel et un axe technique. A l’issue des évolutions du modèle fonctionnel et de
l’architecture technique, la réalisation du système consiste à fusionner les résultats
des deux (2) branches, ce qui donne la forme d’un processus de développement en
Y. La séparation initiale permet de capitaliser à la fois la connaissance métier (branche
gauche) et le savoir-faire technique (branche droite). Les étapes préconisées par le
2TUP lors du développement d’un système sont schématisées comme suit :

Analyse et
conception
37
Figure 6 : Processus de développement en Y

Analyse et
conception
38
CHAPITRE 2
PRESENTATION DE L’OUTIL DE MODELISATION
Dans la modélisation, on pouvait se contenter d'utiliser uniquement UML, mais sur
quels supports? De nos jours, on ne peut pas se contenter des dessins faits sur papier
ni au tableau; c’est là qu’intervient les logiciels de modélisation qui permettent la
réutilisabilité des modèles, leur portabilité (réalisées une fois et utilisables partout) etc.
Le logiciel de modélisation retenu pour la modélisation de notre module est :
PowerAMC.
2.1. ETHIQUE
PowerAMC est un environnement graphique
de modélisation d'entreprise très simple
d'emploi. Il a été créé par la société SDP sous
le nom de AMC*Designor, racheté par
PowerSoft qui lui-même a été racheté par
Sybase en 1995. PowerAMC prend en compte plusieurs outils de modélisation tels
qu’UML et MERISE.
2.1.1.Utilisation
PowerAMC permet d’effectuer les tâches suivantes :
 Modélisation intégrée via l'utilisation de méthodologies et de notation standards:
 Données (E/R, Merise) ;
 Métiers (BPMN, BPEL, ebXML) ;
 Application (UML).
 Génération automatique de code via des Template personnalisables :
 SQL (avec plus de 50 SGBD) ;
Figure 7 : Logo PowerAMC

Analyse et
conception
39
 Java ;
 NET.
 Fonctionnalités de reverse engineering pour documenter et mettre à jour des
systèmes existants ;
Une solution de référentiel d'entreprise avec des fonctionnalités de sécurité et de
gestion des versions très complètes pour permettre un développement multiutilisateur ;
 Fonctionnalités de génération et de gestion de rapports automatisés et
personnalisables.
, qui permet d'ajouter des règles, des commandes, des concepts et des attributs
Outre la possibilité de réaliser les tâches ci-dessus, PowerAMC offre un
environnement extensible aux méthodologies de modélisation et de codage.

Analyse et
conception
40
CHAPITRE 3
ETUDE DETAILLE DE LA SOLUTION
Dans ce chapitre, il sera question de représenter les différents diagrammes d’UML
conformément à la démarche 2TUP. Ainsi, nous modéliserons les diagrammes
statiques et dynamiques de deux modules tout en un suivant les trois (3) niveaux ci-
après:
 L’étude fonctionnelle ;
 L’étude technique ;
 La conception du système.’
Pour des raisons de clarté dans le développement, l’étude détaillée des deux modules
sera faite en un. Nous nommons ce système ms-epargne-caisse.
3.1. ETUDE FONCTIONNELLE
L’aspect fonctionnel de notre étude repose sur les trois (3) étapes suivantes :
 La capture des besoins fonctionnels ;
 L’analyse fonctionnelle dynamique ;
 L’analyse fonctionnelle statique.
3.1.1. Besoins fonctionnels
Nous allons donc :
 Définir le contexte général (métier, juridique, …) dans lequel le projet va être
réalisé ;
 Définir les acteurs qui vont interagir avec le système ;
 Définir les fonctionnalités attendues du système ;
 Décrire les différentes fonctionnalités.

Analyse et
conception
41
3.1.1.1. Acteur
Un acteur est une personne ou un système qui interagit avec le système
en échangeant des informations en entrée comme en sortie. Le diagramme des cas
d’utilisation d’UML distingue deux acteurs à savoir :
 Les acteurs principaux (qui modifient l’état du système ou qui
consultent cet état) ;
 Les acteurs secondaires, acteurs auxquels le système fait appel pour répondre
aux sollicitations d’un acteur principal).
 Acteur principale sont :
 L’administrateur ;
 Le caissier ;
 Le comptable ;
 La sécrétaire ;
 Le Chef d’agence.
 Acteur secondaire sont :
 Ms-adhésion : un module de gestion de l’adhésion des clients ;
 Ms-backup : un module de sauvegarde et restauration de base de données ;
 Moozisms : un api d’envoi de sms.
3.1.1.2. Diagramme de contexte statique
Le diagramme de contexte statique délimite le domaine d’étude en précisant ce qui est
à la charge du système et en identifiant l’environnement extérieur au système étudié
avec lequel ce dernier communique.
Ses composants sont :

Analyse et
conception
42
 Les acteurs externes : entités externes au système étudié interagissant avec
lui ;
 Un processus unique symbolisant le Système Information étudié
 Echange entre le système étudié et son environnement
Ce diagramme n’est pas officiellement désigné comme diagramme UML. Il ne fait
donc pas partie des diagrammes « officiels », mais il est utile pour la description du
domaine d’étude avant d’aborder les aspects plus fins.
Le Diagramme de contexte statique du système ms-epargne-caisse est présenté
ci-dessous :
Figure 8 : Diagramme de contexte statique du système ms-epargne-caisse
3.1.1.3. Cas d’utilisation
Un cas d’utilisation exprime le comportement du système en termes d’actions et
réactions face à un besoin d’un utilisateur. Notre étude nous a permis de déceler un
certain nombre de cas d’utilisation que nous avons résumé dans le tableau ci-dessous
:

Analyse et
conception
43
Tableau 8 : Cas d'utilisation du système
CAS D’UTILISATION ACTEURS
PRINCIPALES
ACTEURS
SECONDAIRES
S’authentifier Tout utilisateur
Néant
Gérer compte
utilisateur
Créer compte Administrateur
Modifier compte
Désactiver un compte
Supprimer compte
Consulter comptes
Mettre à jour son compte Tout utilisateur
Gérer rôle Créer rôle Administrateur
Attribuer permissions
Modifier rôle
Supprimer rôle
Consulter rôles
Gérer attributions de
rôles
Attribuer rôle Administrateur
Retirer rôle
Sauvegarder la base de données Administrateur ms-backup
Consulter journal des transactions Administrateur Néant
Gérer produits
épargnes
Créer produit épargne Comptable
Néant
Modifier produit épargne
Consulter produits épargne
Gérer produits part
sociale
Créer produit part sociale Comptable
Modifier produit part
sociale
Consulter produits part
sociale

Analyse et
conception
44
PRINCIPALES
ACTEURS
SECONDAIRES
Gérer comptes
épargnes
Créer compte épargne Caissier,
Secrétaire
ms-adhésion
Bloquer/Débloquer compte Comptable
Bloquer/Débloquer
montant
Consulter relevé de
compte
Caissier,
Comptable,
secrétaire
Gérer comptes part
sociale
Créer compte part sociale Cassier,
secrétaire
ms-adhésion
Clôturer compte part
sociale
Comptable Néant
Gérer contrats DAT
(dépôt à terme)
Mettre en place DAT comptable
ms-adhésion
Valider DAT
Rompre DAT
Recherches multicritères
DAT
Comptable,
Chef d’agence
Consulter rapports épargne Chef d’agence,
comptable
Néant
Gérer guichet
Créer guichet Comptable
ms-adhésion
Activer/Désactiver un
guichet
Ouvrir / fermer un guichet
Affecter / Retirer utilisateur
à un guichet
Gérer opérations de
caisses
Effectuer dépôt Caissier
ms-adhésion
Effectuer retrait
Adhérer client
Vendre part sociale
Retrait de part sociale Néant

Analyse et
conception
45
3.1.1.4. Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation est un diagramme UML utilisé pour donner une
vision globale du comportement fonctionnel d’un système logiciel. Dans un diagramme
de cas d’utilisation, les utilisateurs appelés acteurs interagissent avec les cas
d’utilisations comme le montre la figure suivante :
PRINCIPALES
ACTEURS
SECONDAIRES
Gérer opérations
diverses
Effectuer opérations
diverses
Caissier
Néant
Valider opérations diverses Comptable
Gérer transferts Enregistrer transferts
caisse vers caisse Caissier
Néant
Gérer billetage Enregistrer billetage Caissier
Valider billetage Comptable
Gérer devises Enregistrer une devise Comptable
Néant
Modifier devise
Mettre à jour taux de
change d’une devise
Paramétrer sous et billets Comptable Néant
Consulter rapports de caisse Chef d’agence,
comptable.
Néant
Envoyer des notifications comptable api sms

Analyse et
conception
46
Figure 9: Figure illustrant un diagramme de cas d'utilisation
Pour des raisons de clarté et de compréhension, nous avons scindé notre diagramme
de cas d’utilisation en différents lots ou modules en fonction des domaines fonctionnels
des cas d’utilisation: gestion de la sécurité, paramétrage des produits financiers,
gestion des comptes membres, gestion des contrats, gestion des guichets,
paramétrage, gestions de la caisse, gestions des transferts.
Ce tableau ci-dessous illustre les cas d’utilisations de chaque module
Tableau 9 : Structuration de cas d'utilisation en package
Modules Cas d’utilisations
Gestion de la sécurité  Gérer compte utilisateur
 Gérer rôle
 Gérer attributions de rôles
 Sauvegarder la base de données
 Consulter journal des
transactions
Paramétrage des produits financiers  Paramétrer produits épargnes
 Paramétrer produits part sociale
Gestion comptes membres  Gérer comptes épargnes
 Gérer comptes part sociale
 Consulter rapports épargne
Gestion des contrats  Gérer contrats DAT
Gestion des guichets  Gérer guichets

Analyse et
conception
47
Modules Cas d’utilisation
gestion de la caisse  Gérer opérations de caisses
 Gérer opérations diverses
 Gérer billetage
 Consulter rapports épargne
Gestion des transferts  Gérer transferts
Paramétrage  Gérer devises
 Gérer sous et billets
 Gestion de la sécurité
Figure 10 : Diagramme de cas d'utilisation « Gestion de la sécurité »

Analyse et
conception
48
 Paramétrage des produits financiers
Figure 11 : Diagramme de cas d'utilisation « Paramétrage produits financiers »
 Gestion des contrats
Figure 12 : Diagramme de cas d'utilisation « Gestion des contrats »

Analyse et
conception
49
 Gestion des comptes membres
Figure 13 : Diagramme de cas d'utilisation « Gérer comptes membres»
 Gestion des guichets
Figure 14 : Diagramme de cas d'utilisation « Gestion guichets»

Analyse et
conception
50
 Gestion de la caisse
Figure 15 : Diagramme de cas d'utilisation « Gestions de la caisse»
 Paramétrage
Figure 16 : Diagramme de cas d'utilisation « Paramétrage »

Analyse et
conception
51
 Gestion des transferts
Figure 17 : Diagramme de cas d'utilisation « Gestion des transferts »
 Cas d’utilisation communs aux acteurs

Analyse et
conception
52
Figure 18 : Diagramme de cas d'utilisation « Communs aux acteurs »
3.1.1.5. Description textuelle des cas d’utilisation
Un cas d’utilisation représente un ensemble de séquences d’interactions entre le
système et ses acteurs. Ainsi, la description de la dynamique du cas d’utilisation
consiste à recenser toutes les interactions de façon textuelle. Le cas d’utilisation doit
par ailleurs avoir un début et une fin clairement identifiés. Il doit préciser quand ont lieu
les interactions et quels sont les messages échangés. Il faut également préciser les
variantes possibles, telles que les différents cas nominaux, les cas alternatifs, les cas
d’erreurs ou d’exceptions, tout en essayant d’ordonner séquentiellement les
descriptions, afin d’améliorer leur lisibilité. Pour notre projet, chaque fiche de
description textuelle sera structurée de la façon suivante :
 Le sommaire d’indentification qui inclut le titre, le résumé, les acteurs, les
dates de création et de mise à jour, la version, le responsable.
 La description des enchainements (scénarii) qui décrit les pré conditions, le
scénario nominal, les scénarii alternatifs, les scénarii d’exceptions et les post

Analyse et
conception
53
conditions. Les fiches de description textuelle élaborées pour quelques cas
d’utilisation de notre projet sont les suivantes :
 Cas d’utilisation « S’authentifier »
Sommaire d’identification
Titre : S’authentifier
Résumé : Permet à tous les utilisateurs du système d’accéder aux
fonctionnalités du système auxquelles ils ont droit
Acteurs : Tout utilisateur
Date de création : 12/07/2017 Date de mise à jour
Version : 1.0 Responsable : Gédéon AGOTSI
Description des scénarii
Pré conditions
 Le système doit être fonctionnel ;
1. La page d'authentification est accessible ;
2. L’utilisateur doit avoir un compte d’utilisateur déjà créé.
Scénario nominal
1. Le système demande à l’utilisateur de saisir ses paramètres de connexion (son
login et son mot de passe) (E1) ;
2. L’utilisateur saisit puis valide les paramètres de connexion ;
3. Le système vérifie la validité des paramètres saisis par l’utilisateur (A1) (E2)
(E3) ;
4. Le système affiche le menu principal correspondant au profil de l’utilisateur.
Scénario alternatif
 A1 : Les paramètres d’identification sont incorrects moins de trois (3) fois
Ce scénario se déclenche lorsque l’utilisateur saisit des informations incorrectes la
1ère et la 2ème fois au point 2 du scénario nominal.
L’enchaînement A1 démarre au point 5
5. Le système affiche un message d’erreur qui informe l’utilisateur que
l’authentification a échoué ;
6. Le système enregistre dans le journal cette tentative de connexion.

Analyse et
conception
54
Les enchaînements reprennent au point 1 du scénario nominal.
Scénario d’exceptions
 E1 : L'utilisateur annule l'opération.
Ce scénario se déclenche lorsque l’utilisateur quitte la page d’authentification au point
1 du scénario nominal.
Le scénario nominal est interrompu.
 E2 : L’utilisateur est désactivé
Ce scénario se déclenche lorsque les paramètres saisis correspondent à ceux d’un
compte désactivé.
L’enchaînement E2 démarre au point 7
7. Le système affiche un message qui informe l’utilisateur que son compte est
inactif.
 E3 : Les paramètres d’identification sont incorrects la troisième fois.
Ce scénario se déclenche lorsque l’utilisateur saisit des informations incorrectes la
3ème fois au point 2 du scénario nominal.
8. Le système affiche un message qui informe l’utilisateur que l’authentification a
échoué ;
9. Le système désactive son compte ;
10.Le portail est verrouillé.
Post conditions
 Utilisateur authentifié ;
 Le journal des transactions est mis à jour.

Analyse et
conception
55
 Cas d’utilisation « Gérer produit épargne »
Titre : Gérer produit épargne
Résumé : Permet au comptable d’ajouter et de mettre à jour un
produit épargne.
Acteurs : Comptable
Pré conditions
 L’utilisateur est authentifié.
Scénario nominal
1. L’utilisateur accède à la page de la liste des produits épargnes ;
2. L’utilisateur choisit l’action à effectuer (A1) (A2);
3. Le système présente un formulaire à remplir (E1) ;
4. L’utilisateur remplit le formulaire et valide la saisie;
5. Le système contrôle les informations saisies par l’utilisateur (A3) (E2) ;
6. Le système enregistre le produit épargne, actualise la liste et renvoie un
message de succès à l’utilisateur.
 A1 : Nouvel enregistrement
L’utilisateur choisit l’action d’ajouter un produit en cliquant sur le bouton « Nouveau »
 A2 : Modification d’un enregistrement existant
L’utilisateur choisit l’action de modifier les informations d’un produit existant en
cliquant sur le bouton « Modifier »
 A3 : Les informations saisies sont incorrectes
Ce scénario se déclenche au point 5 du scénario nominal lorsque l’utilisateur saisit
des informations non conformes aux contraintes du système.

Analyse et
conception
56
7. Le système envoie un message invitant l’utilisateur à entrer des informations
correctes
Ce scénario se déclenche au point 3 du scénario nominal lorsque l’utilisateur quitte la
page.
 E2 : Le produit épargne existe déjà
Ce scénario se déclenche au point 5 lorsque les informations saisies (code, libellé)
par l’utilisateur lors de la création d’un nouveau produit épargne correspondent à ceux
d’un produit épargne existant.
8. Le système renvoie un message d’erreur ;
9. Le système présente à l’utilisateur le formulaire d’enregistrement d’un produit
épargne.
Post conditions
 Les informations relatives aux produits épargne sont actualisées
 Le système est près pour une nouvelle opération.
Cas d’utilisation «Créer guichet »
Titre : Créer guichet
Résumé : Permet au comptable d’enregistrer un nouveau guichet
Acteurs : Comptable (principale), ms-adhesion (secondaire)

Analyse et
conception
57
Pré conditions
Scénario nominal
1. L’utilisateur accède à la page de la liste des guichets et choisi d’ajouter un
guichet en cliquant sur le bouton « nouveau » ;
3. L’utilisateur remplit le formulaire et valide la saisie;
4. Le système contrôle les informations saisies par l’utilisateur (A1) (E2) ;
5. Le système enregistre le guichet, actualise la liste et renvoie un message de
succès à l’utilisateur.
correctes
Ce scénario se déclenche au point 2 du scénario nominal lorsque l’utilisateur quitte la
page.
 E2 : Le guichet existe déjà
Ce scénario se déclenche au point 4 lorsque les informations saisies (code) par
l’utilisateur correspondent à ceux d’un guichet existant.
7. Le système renvoie un message d’erreur ;
8. Le système présente à l’utilisateur le formulaire d’enregistrement d’un guichet

Analyse et
conception
58
Post conditions
 Le guichet est enregistré
 Cas d’utilisation « Affecter utilisateur à un guichet
Titre : Affecter utilisateur à un guichet
Résumé : Permet au comptable d’affecter un utilisateur à guichet
Pré conditions
 Le comptable est authentifié.
Scénario nominal
1. Le comptable accède à la page de la liste des utilisateurs actif ayant le rôle
guichet (E1).
2. Le comptable clique sur le bouton « Activer » de la ligne correspondante à
l’utilisateur ;
3. Ms-adhésion charge la liste des guichets.
4. Le comptable choisi le guichet et valide ;
5. Le système contrôle les informations saisies par l’utilisateur ;
6. Le système affecte l’utilisateur au guichet et renvoie un message de succès
 E1 : Le comptable annule l'opération.
Ce scénario se déclenche au point 1 du scénario nominal lorsque l’utilisateur quitte
la page.
Post conditions
 L’utilisateur est affecté

Analyse et
conception
59
 Cas d’utilisation « Rompre DAT »
Titre : Rompre DAT
Résumé : Permet au comptable de rompre un DAT
Pré conditions
Scénario nominal
1. L’utilisateur accède à la page de rupture de contrat (E1);
2. L’utilisateur recherche le numéro du contrat;
3. Ms-adhesion affiche les informations sur le client signataire du contrat, le
système affiche les informations sur le contrat ;
4. L’utilisateur valide la rupture du contrat ;
5. Le système désactive l’occurrence et renvoie un message de succès à
l’utilisateur.
la page.
Post conditions
 L’occurrence du contrat est désactivée
 Le journal des transaction est mis à jour.

Analyse et
conception
60
 Cas d’utilisation « Effectuer un retrait »
Titre : Effectuer un retrait
Résumé : Permet au caissier d’effectuer un retrait sur le compte d’un
membre.
Pré conditions
Scénario nominal
1. L’utilisateur accède à la page « opération » et choisit l’onglet effectuer retrait;
3. L’utilisateur saisie le numéro du membre;
4. Ms-adhésion recherche le numéro du client et retourne les informations sur le
membre (E2) ;
5. L’utilisateur choisit le compte du membre et renseigne le montant à retirer ;
6. L’utilisateur valide les informations;
7. Le système contrôle les informations saisies par l’utilisateur (A1) (E3) (E4);
8. Le système enregistre le retrait sur le compte du membre et affiche un
message de succès à l’utilisateur.
correctes

Analyse et
conception
61
la page.
 E2 : ms-adhésion ne renvoie aucun membre
Ce scénario se déclenche au point 3 du scénario nominal lorsque ms-adhésion ne
renvoie aucun membre correspondant à la recherche
 E3 : le compte du membre est bloqué
Ce scénario se déclenche au point 7 du scénario nominal lorsque le compte du
membre est bloqué
10.Le système envoie un message d’erreur
 E4 : le montant bloqué
Ce scénario se déclenche au point 7 du scénario nominal lorsque le montant sur le
compte du membre est bloqué
11.Le système envoie un message d’erreur
Post conditions
 Le retrait sur le compte du membre est enregistré

Analyse et
conception
62
 Cas d’utilisation « Envoyer des notifications »
Titre : Envoyer des notifications
Résumé : Permet au comptable de notifier les clients ayant souscrit
à ce service sur leur solde
Acteurs : Comptable (principale), moozisms (secondaire)
Pré conditions
 Le système doit être connecté à l’internet ;
Scénario nominal
1. L’utilisateur accède à la page d’envoie des notifications (E1);
2. Le système liste les clients à jour ;
3. L’utilisateur clique sur le bouton « Envoyer »
4. Le système se connecte au web service fourni par l’api de sms (E2) (E3);
5. Le système envoie un message informant l’utilisateur que les clients ont été
bien notifiés.
la page.
6. Le système envoie un message d’erreur
 E2 : Tentative de connexion échouée
Ce scénario se déclenche au point 4 du scénario nominal lorsque le système n’arrive
pas à connecter à l’api de sms
7. Le système envoie un message d’erreur ;

Analyse et
conception
63
 E3 : Délai de réponse du web service de l’api expiré
Ce scénario se déclenche au point 4 du scénario nominal lorsque le délai de réponse
du web service est expiré
8. Le système envoie un message d’erreur ;
Post conditions
 Les membres sont notifiés
 Le système est toujours fonctionnel
3.1.2.Analyse fonctionnelle dynamique
L’analyse fonctionnelle dynamique des cas d’utilisations de notre projet sera
composée de :
 Diagrammes d’activités
 Diagrammes de séquences
 Diagrammes d’états
3.1.2.1. Diagramme d’activités
Le diagramme d’activités est un diagramme comportemental, représentant les règles
d’enchainement d’évènements dans le système. Il permet d’une part de consolider la
spécification d’un cas d’utilisation et d’autre part de concevoir une méthode. Il se
présente comme un organigramme qui décrit les enchainements dans le déroulement
d’un cas d’utilisation ou d’un ensemble de cas d’utilisation. Une activité représente une
exécution d’un mécanisme, un déroulement d’étapes séquentielles. Le passage d’une
activité vers une autre est matérialisé par une transition. Les transitions sont
déclenchées par la fin d’une activité et provoquent le début immédiat d’une autre.

Analyse et
conception
64
Voici quelques diagrammes d’activités de notre projet :
 Diagramme d’activités du cas d’utilisation « s’authentifier »
Figure 19 : Diagramme d'activités « s'authentifier »

Analyse et
conception
65
 Diagramme d’activités du cas d’utilisation « Gérer produit épargne»
Figure 20 : Diagramme d'activités « Gérer produit épargne»

Analyse et
conception
66
 Diagramme d’activités du cas d’utilisation «Mettre à jour taux de change des
devises »
Figure 21 : Diagramme d'activités «Mettre à jour taux de change d’une devise »

Analyse et
conception
67
 Diagramme d’activités du cas d’utilisation «Affecter utilisateur à un guichet »
Figure 22 : Diagramme d'activités « Affecter utilisateur à un guichet »
3.1.2.2. Diagramme de séquences
Le diagramme de séquences est la représentation graphique des interactions entre
les acteurs d’un cas d’utilisation et le système selon un ordre chronologique. Ces
communications sont reconnues comme des messages. Il est difficile de représenter
toute la dynamique d’un système sur un seul diagramme. Aussi la dynamique globale
sera représentée par un ensemble de diagrammes de séquences, chacun étant
généralement lié à une sous fonction du système.
Voici quelques diagrammes de séquences de notre projet :

Analyse et
conception
68
 Diagramme de séquences du cas d’utilisation « s’authentifier »
Figure 23 : Diagramme de séquences « s’authentifier »

Analyse et
conception
69
 Diagramme de séquences du cas d’utilisation «Gérer produit épargne »
Figure 24 : Diagramme de séquences «Gérer produit épargne »

Analyse et
conception
70
 Diagramme de séquences du cas d’utilisation «Envoyer des notifications»
Figure 25 : Diagramme de séquences « Mettre à jour taux de change d’une devise »

Analyse et
conception
71
 Diagramme de séquences du cas d’utilisation «Effectuer retrait »
Figure 26 : Diagramme de séquences du cas d’utilisation «Effectuer retrait »

Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des travaux informatique.

Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des travaux informatique.

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des travaux informatique.

Semelhante a Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des travaux informatique. (20)

Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des travaux informatique.