II- ConCeption du système
Une fois que nous avons achevé la partie « Analyse
des besoins » - l'étude qui nous a permis de décrire les
objectifs du système EcoPay, nous entamons l'étude
conceptuelle.
Il s'agit d'une étape cruciale dans la
réalisation d'une application donnée. Le futur d'un logiciel
dépend beaucoup de cette phase, elle nous permet d'éviter le
développement d'une application non satisfaisante. Concevoir un
système d'information n'est pas évident car il faut
réfléchir à l'ensemble de l'organisation que l'on doit
mettre en place. La phase de conception nécessite des méthodes
permettant de mettre en place un modèle sur lequel nous allons
s'appuyer. La modélisation consiste à créer une
représentation virtuelle d'une réalité de telle
façon à faire ressortir les points auxquels on
s'intéresse.
La phase de conception a pour objectif de s'accorder sur le
comment mais pas sur le quoi ; en d'autre terme, elle vise à trouver des
solutions informatiques et techniques pour mettre en oeuvre et construire le
système analysé au cours des phases précédentes.
Elle doit permettre d'élaborer les différentes couches du
système analysé et leurs interactions, d'abord au niveau plus
général puis à un niveau plus détaillé, en
tenant compte des contraintes informatiques et techniques : langage, base de
données, matériel....
Démarche adoptée :
Pour mener à bien le projet, nous avons choisi
d'utiliser le langage UML (Unified Modeling Language) qui est
considérée comme le standard en matière de
modélisation objet capable de résoudre certains problèmes
liés aux traitements.
Comme on l'a dit UML 2 possède treize diagrammes. Quant
à la catégorie dynamique à elle seule est associée
huit diagrammes. Dans notre application nous allons nous en servir de trois
seulement.
1- Diagramme De cas D'utilisation
Le but de ce diagramme est d'avoir une vision globale sur les
interfaces du futur logiciel. Ces diagrammes sont constitués d'un
ensemble d'acteurs qui agit sur des cas d'utilisation.
[8] L'objectif poursuivi par les cas
d'utilisation est de permettre de décrire, dans des documents lisibles
par tous, la finalité des interactions du système et de ses
utilisateurs.
1.1- IdentIfIcatIon des acteurs
Un acteur représente l'abstraction d'un rôle
joué par les entités externes (utilisateurs, dispositif
matériel ou autre système) qui interagissent avec le
système. Il a toujours le même comportement vis-à-vis d'une
interaction directe avec un cas d'utilisation.
- Cas d'utilisation pour un client simple
Figure 3: Diagramme des cas d'utilisation pour un client
simple
Use Cases Authentification
|
Commentaires
L'utilisateur envoie les informations requises pour ouvrir une
session.
|
Demande d'inscription
|
Le client se connecte au site pour saisie les informations
nécessaires pour la création de son porte-monnaie
électronique
|
Transférer l'argent
|
Il permet à un client d'effectuer un transfert de l'argent
d'un porte-monnaie à un autre
|
Modifier son password
|
Permet au client de changer son mot de passe pour l'accès
au système
|
Tableau 4: Explication des cas d'utilisation du client
simple
- Cas d'utilisation pour un client affaire
Figure 4: Diagramme des cas d'utilisation pour un client
affaire
Use Cases Commentaires
Authentification L'utilisateur envoie les
informations requises pour ouvrir
une session.
Demande d'inscription
|
Le client se connecte au site pour saisie les informations
nécessaires pour la création de son porte-monnaie
électronique
|
Transférer l'argent
|
Il permet à un client d'effectuer un transfert de l'argent
d'un porte-monnaie à un autre
|
Retrait physique argent
|
Permet au client d'entrer en possession de son argent
physiquement.
|
Régler un achat(ou paiement)
|
Régler la facture d'un achat effectué de son
porte-monnaie vers le porte-monnaie de son vendeur
|
Consulter
|
Permet au client de voir toutes les transactions
effectuées à un moment donné
|
Bloquer le porte-monnaie
|
Permet au client de suspendre toutes les opérations par
son porte-monnaie a un moment donné
|
Modifier son password
|
Permet au client de changer son mot de passe pour l'accès
au système
|
Tableau 5: Explication des cas d'utilisation du client
affaire
- Cas d'utilisation pour un DAA
Figure 5: Diagramme des cas d'utilisation pour un
Distributeur DAA
- Cas d'utilisation pour un chef agence
-
Figure 6: Diagramme des cas d'utilisation pour un chef
d'agence
Use Cases Commentaires
Authentification L'utilisateur envoie les
informations requises pour ouvrir une
session.
Gestion porte-monnaie Permet au chef d'agence de
valider un porte-monnaie, de le débiter,
de le créditer, de le bloquer et de le débloquer
Consulter (reporting) Permet au chef d'agence de
consulter toutes les transactions
(input/output) effectuées au sein de son agence
Archiver les données
|
Permet au chef d'agence de stocker les informations concernant
les différentes transactions (input/output) de son agence.
|
Tableau 6: Explication des cas d'utilisation du chef
d'agence
- Cas d'utilisation pour un DPA
- Cas d'utilisation pour un Banque
Figure 8: Diagramme des cas d'utilisation pour une
banque
Use Cases Authentification
|
Commentaires
L'utilisateur envoie les informations requises pour ouvrir une
session.
|
Demande de création
|
Permet à la banque de faire une demande pour faire partir
du réseau
|
Consulter (reporting)
|
Permet à la banque de consulter toutes les transactions
(input/output) effectuées au sein de toutes les agences appartenant
à sa banque
|
Archiver les données
|
Permet a la banque de stocker les informations concernant les
différentes transactions (input/output) de toutes les agences
appartenant à sa banque.
|
Gestion des agences
|
Il permet à la banque de créer une agence, de la
désactivée et de la activée
|
Tableau 7: Explication des cas d'utilisation d'une
banque
- Cas d'utilisation pour un administrateur
système
-
Figure 9: Diagramme des cas d'utilisation pour un
administrateur
Use Cases Commentaires
Authentification
|
|
L'utilisateur envoie les informations requises pour ouvrir une
session.
|
Demande de création
|
Permet à la banque de faire une demande pour faire partir
du réseau
|
Consulter (reporting)
|
Permet à la banque de consulter toutes les transactions
(input/output) effectuées au sein de toutes les agences appartenant
à sa banque
|
Archiver les données
|
Permet au chef d'agence de stocker les informations concernant
les différentes transactions (input/output) de toutes les agences
appartenant à sa banque.
|
Tableau 8: Explication des cas d'utilisation d'un
administrateur banque
1.2- Vue usage (description de quelque cas
d'utilisation) - Acteur: Client simple
Cas d'utilisation : Demande d'inscription
Description de Cas d'utilisation Pré condition:
· Distributeur connecté a EcoPay
a) Scenario nominal:
· Le distributeur DAA ou DPA saisi les informations du
client dans l'interface qui lui est fourni
· Le système crée le compte PME avec les
infos fournies
b) Le système renvoie une information
par SMS et par e-mail au client lui disant que son compte a été
créé avec succès avec son login et son mot de passe.
Post condition
· Son compte est crée en attendant la validation
Schéma du scenario
Cas d'utilisation: Transfert d'argent
Figure 11: Description du cas d'utilisation transfert
d'argent
Pré condition :
· Authentification
Scenario nominal
· Saisie des informations concernant le transfert
· Validation du transfert
· Confirmation du transfert (cas des interfaces)
· Notification par SMS
Exception
· Le compte n'est pas assez fourni
· Informations erronées
Cas d'utilisation : Retrait argent
Figure 12: Description du cas d'utilisation retrait
d'agent
Pré condition :
· Authentification (distributeur) Scenario
nominal
· Scenario des infos du retrait
· Validation du retrait (code pin)
· Confirmation du retrait
· Notification du client par SMS Exception
· Le compte n'est pas assez fourni
· Informations erronées
- Acteur: Administrateur Banque
Cas d'utilisation: Paramétrage
Créer Banque
Figure 13: Créer banque
Pré condition :
· Authentification (administrateur Bank)
Scenario nominal:
· Saisi les informations concernant une Bank
· Créer l'entité Bank
|