DEDICACE
A ma famille
Trouvez en ce document la récolte de toutes vos
semences
REMERCIEMENTS
Il aurait été difficile de nous passer de
l'appui de nombreuses personnes à qui nous tenons à
donner toute notre reconnaissance :
_ Le Seigneur tout puissant qui nous a
donné la force au quotidien afin que nous puissions
achever notre travail ;
_ M. DERRICK FONTAH, Directeur
Général de BETTER PLANNING LTD qui en plus de
nous avoir accueilli dans son entreprise, n'a
ménagé aucun effort afin que ce projet aboutisse à
terme ;
_ M FOTSO VALERY, notre encadreur
académique qui malgré ses multiples occupations à
toujours répondu présent quand besoin
l'était ;
_ M. ASSONFACK HYPPOLITE notre maitre de
stage pour ses enseignements, critiques,
suggestions et son suivi sans faille ;
_ M. KEPGNIA GHISLAIN qui nous a
chaleureusement légué son savoir faire technologique ;
_ Dr TABOD CHARLES pour ses critiques et
suggestions ;
_ les enseignants de notre filière
pour les enseignements qu'ils nous ont apportés durant ces
trois
années ;
_ Mlle DJIFACK ADELEXIE et M. JIA
FABRICE qui ont pris la peine de relire ce travail pour
apporter quelques corrections orthographiques ;
_ le personnel de BETTER PLANNING LTD
(Franck, Emmanuel, Edmond, Félicité, Fred,
Marc...) pour leur chaleureux accueil ;
_ Mes voisins de la WHITE CITY avec qui nous
partageons notre quotidien ;
_ Tous mes camarades de la promotion (2006-2009)
du cycle de CS2I de l'ISTDI sans qui nous
n'aurions pu vaincre certains obstacles ;
_ Tous ceux qui de près ou de loin ont participé
et que j'aurais omis de mentionner explicitement
ici.
Une pensée affectueuse à tous les
membres de ma famille et amis pour leur assistance et soutien sans
faille.
SOMMAIRE
DEDICACE
i
REMERCIEMENTS
ii
SOMMAIRE
iii
DEFINITION DES SIGLES
v
LISTE DES FIGURES ET TABLEAUX
vi
INTRODUCTION
1
CHAPITRE I : CONTEXTE
3
I.1.1 Présentation et historique de
l'entreprise
3
I.1.2 Les activités de BETTER PLANNING
LTD
3
I.1.3 Présentation du service d'accueil
4
CHAPITRE II : PROBLEMATIQUE
5
I.2.1 Problématique
5
I.2.2 Intérêt et choix du sujet
6
CHAPITRE I : QUELQUES DATES HISTORIQUES ET
DEFINITIONS
8
II.1.1 Quelques dates historiques
8
II.1.2 Définitions
8
CHAPITRE II : LES DIFFÉRENTES
TECHNOLOGIES M-BANKING
10
II.2.1 LE STK-BANKING
10
II.2.1.1 Présentation générale
du SIM TOOLKIT
10
II.2.1.2 Description du STK-BANKING
10
II.2.1.3 Avantages du STK BANKING
13
II.2.1.4 Inconvénients du STK-BANKING
13
II.2.2 Le WAP-BANKING
13
II.2.2.1 Aperçu sur le protocole WAP
13
II.2.2.2 Approche conceptuelle du WAP-BANKING
14
II.2.2.3 Avantages du WAP-BANKING
17
II.2.2.4 Inconvénients du WAP-BANKING
17
II.2.3 Le SMS-BANKING
17
II.2.3.1 Présentation générale
du SMS
17
II.2.3.2 Qu'est ce que le SMS-BANKING
19
II.2.3.3 Architecture générale d'une
plate forme SMS-BANKING
19
II.2.3.4 Avantages du SMS-BANKING
20
II.2.3.5 Inconvénients du SMS-BANKING
21
II.2.4 Le M-BANKING au Cameroun
21
II.2.5 Comparaison entre le STK-BANKING , le
WAP-BANKING et le SMS-BANKING
21
CHAPITRE I : CHOIX TECHNOLOGIQUES
23
III.1.1 La passerelle SMS
24
III.1.2 La méthode UP
24
CHAPITRE II : ANALYSE
26
III.2.1 Expression des besoins
26
III.2.1.1 Les différents services qui seront
proposées aux clients
26
III.2.1.2 Gestion des clients
27
III.2.1.3 Gestion de la facturation
27
III.2.1.4 GESTION DES SM
27
III.2.1.5 Sécurité
28
III.2.1.6 Etats et statistiques
28
III.2.2 Analyse
28
III.2.2.1 Définition de quelques concepts
28
III.2.2.2 Principaux cas d'utilisation autour
desquels s'organise SMS BANKING
29
III.2.2.3 Description détaillée de
quelques cas d'utilisation
31
CHAPITRE III : CONCEPTION
49
III.3.1 Conception de la base de
données
49
III.3.2 Architecture détaillée de SMS
BANKING
50
III.3.2.1 Sous système CUSTOMER SMS
50
III.3.2.2 Le core SMSBANK
50
III.3.2.3 Sous système GATEWAY SMS
51
III.3.2.4 Sous système SI
BANK.
52
CHAPITRE IV : IMPLEMENTATION
54
III.4.1 La passerelle GMS/IP
54
III.4.1.1 rôle de KANNEL
54
III.4.1.2 Installation de KANNEL
54
III.4.1.3 configuration et administration de
KANNEL
55
III.4.2 Installation du modem GSM
56
III.4.3 Implémentation des modules du
système
56
III.4.3.1 Outils utilisés
56
III.4.3.2 Réalisation
57
III.4.3.3 Résultats
57
CONCLUSION
64
BIBLIOGRAPHIE ET WEBOGRAPHIE
I
ANNEXES
II
DEFINITION DES
SIGLES
|
|
|
ASP
|
Advanced Server Pages
|
|
BSC
|
base station controller
|
|
BTS
|
Base
Transceiver Station
|
|
CDMA
|
Code Division Multiple Access
|
|
CGI
|
Common Gateway Interface
|
|
GSM
|
Global System for Mobile Communications
|
|
HTML
|
HyperTex Markup Language
|
|
HTTP
|
HyperTex Transfer Protocol
|
|
IHM
|
Interface Homme-Machine
|
|
JSP
|
Java Server Pages
|
|
M-BANKING
|
Mobile Banking
|
|
MSC
|
(Mobile Service Switching Centre)
|
|
PHP
|
Personal Home Page
|
|
SGBC
|
Société Générale des Banques du
Cameroun
|
|
SGBD
|
Système de Gestion des Bases de Données
|
|
SIM
|
Subscriber Identity Module
|
|
STK
|
SIM Application Toolkit
|
|
SM
|
Short Message
|
|
SMS
|
Short Message Service
|
|
SMSC
|
Short Message Service Center
|
|
SQL
|
Structured Query Language
|
|
SVA
|
Servives à Valeur Ajoutée
|
|
IP
|
Internet Protocol
|
|
UML
|
Unified Modeling Language
|
|
UP
|
Unified Process
|
|
URL
|
Uniform Resource Locator
|
|
UMTS
|
Universal Mobile Telecommunications System
|
|
VLR
|
Visitor Location Register
|
|
VSAT
|
Very Small Aperture Terminal
|
|
WML
|
Wireless Markup Language
|
LISTE DES FIGURES ET
TABLEAUX
Figure 1 : Communication application SIM toolkit
application serveur
12
Figure 2 : Architecture composants STK-BANKING
12
Figure 3 : couches du protocole WAP
13
Figure 4 : Echange d'information lors dune
requête WAP
16
Figure 5 : Transmission d'un SM depuis un
terminal
18
Figure 6 : Transmission d'un SM du SMSC vers un
terminal destintaire
19
Figure 7 : Plate forme SMS BANKING avec
passerelle
20
Figure 8 : Plate forme SMS BANKING avec
passerelle
20
Figure 9 : Diagramme de cas d'utilisation des
services d'informations à la demande
31
Figure 10 : Diagramme de sequence du cas
d'utilisation « demande de solde »
34
Figure 11 : Diagramme de cas d'activité du
cas d'utilisation « demande de solde »
35
Figure 12 : Diagramme de sequence du cas
d'utilisation « demande de chéquier »
39
Figure 13 : Diagramme d'activité du cas
d'utilisation demande de chéquier
40
Figure 14 : Diagramme de séquence du cas
d'utilisation alerte credit compte
43
Figure 15 : Diagramme de d'activité du cas
d'utilisation alerte credit compte
44
Figure 16 : Diagramme de séquence du cas
d'utilisation alerte virement salaire
47
Figure 17 : Diagramme d'activité du cas
d'utilisation alerte virement salaire
48
Figure 18 : Diagramme de classe du
système
49
Figure 19 : Schéma du sous système
CUSTOMER SMS
50
Figure 20 : Schéma du sous système
GATEWAY SMS
52
Figure 21 : Schéma du sous système SI
BANK
53
Figure 22 : Lancement du BEARERBOX de kannel
58
Figure 23 : Utilisation de Javaservice pour la
création du service GATEWAYSMS1
58
Figure 24 : Le service GATEWAYSMS1 lancé
59
Figure 25 : Le service CORESMSBANK Lancé
59
Figure 26 : Interface générale de
SMS-BANKING
60
Figure 27 : Interface de visualisation des SM
émis par les clients
61
Figure 28 : Interface de visualisation des SM emis
en direction des clients
62
Figure 29 : Interface d'inscription des clients aux
services de notification évènementielle
62
Figure 30 : Interface d'incription des clients aux
services d'information à la demande
63
Figure 31 : Interface de visualisation du nombre
total des SM emis par le système aux clients durant une periode
63
Tableau 1 : Comparaison entre STK-BANKING,
WAP-BANKING et SMS-BANKING
22
INTRODUCTION
Depuis des milliers d'années, l'homme cherche à
améliorer ses moyens de communication et d'accès à
l'information. Au XXe siècle, les télécommunications
trouvent dans l'informatique un allié solide. Les progrès
technologiques récents ont permis l'apparition d'une grande
variété de nouveaux moyens permettant à un utilisateur
d'accéder et d'utiliser l'information qui l'intéresse en tout
lieu couvert par le réseau et à tout moment. L'accès au
contenu ne s'effectue plus exclusivement de la même façon ni par
les mêmes appareils qu'il y a quelques décennies. Ces nouveaux
appareils, fruits d'une véritable révolution technologique, ont
pour nom : assistants personnels, téléphones cellulaires,
smartphones, etc. Les téléphones mobiles aujourd'hui sont
allés au-delà de leur rôle primitif d'outils de
communication et ont progressé pour devenir une extension de la
personnalité de l'utilisateur. Nous assistons à une époque
où ce dernier n'achète plus cet appareil afin d'être non
seulement en contact avec d'autres personnes mais, d'exprimer lui -même
ses attitudes, sentiments, et intérêts. Les abonnés veulent
continuellement plus de leurs téléphones mobiles. Ils les
utilisent pour stocker leurs données, jouer, lire des articles de
presse, surfer sur internet, avoir un aperçu sur l'astrologie,
écouter de la musique et même recevoir leurs états
financiers. Il en découle que, les téléphones mobiles
regorgent des vaste fonctionnalités au-delà de la voix qui
doivent être explorées et exploitées. Dans ce sens, un boom
des services à valeur ajoutée parmi lesquels le M-BANKING a
été constaté un peu partout dans le monde, laissant en
rade d'autres technologies aussi avantageuses et, répondant
également aux attentes des utilisateurs. Cependant ces technologies ne
sont pas toujours mises en oeuvre partout où besoin en est, du fait soit
de l'inaccessibilité pour certains et pour d'autres du fait de la
méconnaissance de leur existence.
La suite de ce mémoire, sera constituée de
trois parties une première, le contexte et
problématique, décrira de manière
brève l'entreprise où nous avons fait notre stage
académique et présentera les motivations du choix de notre sujet.
Une deuxième partie, intitulé approche
théorique du M-BANKING présentera les
différentes technologies du M-BANKING avec leurs forces et
faiblesses. Réalisation de notre solution de SMS-BANKING
constituera la troisième partie, où nous exposerons
l'approche que nous proposons pour mettre en place une plate forme de
SMS-BANKING. Enfin nous terminerons notre mémoire par une conclusion,
une annexe et des références bibliographiques.
PARTIE I : CONTEXTE ET
PROBLEMATIQUE
Dans cette partie, nous présenterons de
façon générale l'entreprise qui nous a accueillis durant
notre stage puis, définirons le concept SMS BANKING
La résolution d'un problème passe sans
doute par sa compréhension. Cette partie énonce
clairement le problème tel que posé
à notre arrivée en entreprise, l'explique de
façon schématique et présente
les données à étudier
CHAPITRE I : CONTEXTE
I.1.1 Présentation et
historique de l'entreprise
Implanté sur le terrain depuis près de 10 ans
et résolument tournée vers les attentes et besoins des
entreprises, la société BETTER PLANNING LTD se
spécialise dans le développement des applications, la vente du
matériel et la fourniture des services informatiques. Le gain
étant la priorité dans les entreprises, BETTER PLANNING
LTD ne faillit pas à la tradition et aspire à une
croissance économique. D'où son objectif majeur qui est de
fournir des produits de qualités afin de se démarquer et
satisfaire les besoins de sa clientèle.
I.1.2 Les activités de
BETTER PLANNING LTD
BETTER PLANNING LTD s'est donnée pour
objectif majeur de fournir des produits de qualités afin de satisfaire
les besoins de sa clientèle. Son activité principale est le
développement de solutions logicielles destinées aux
entreprises. Comme solutions logicielles, nous pouvons citer:
§ GLOBAL BANK pour les
opérations bancaires;
§ SYSOFT PAYROLL pour la gestion des
salaires et des Ressources Humaines ;
§ MEDICAL pour la gestion
hospitalière;
§ CYBERCASH pour le transfert d'argent.
BETTER PLANNING LTD est également
spécialisé dans la prestation des services informatiques tels
que:
§ partenaire de distribution des produits RINGO ;
§ installation et la configuration des antennes
VSAT ;
§ développement des sites web ;
§ fourniture de matériel informatique et
maintenance après vente ;
§ fourniture des équipements
réseaux ;
§ formation en informatique ;
§ cyber café.
I.1.3 Présentation du
service d'accueil
Il s'agit ici du département
technique. Sa responsabilité principale est le
développement des logiciels. Il regroupe en son sein des
développeurs, des responsables de formation, une équipe de
maintenance et des stagiaires. Les employés y sont repartis en groupe de
travail suivant les projets en cours et sous la coordination du directeur
général. En bref, ce département est chargé :
§ du développement d'applications
informatiques ;
§ de l'assistance auprès des clients en cas de
difficulté d'exploitation ;
§ de la formation à l'utilisation des logiciels
qu'elle a développés.
CHAPITRE II : PROBLEMATIQUE
I.2.1
Problématique
Sur son site Internet la société MTN Cameroun
déclare qu'au 31 Décembre 2008, elle comptait près de 3
574 000 abonnés actifs, soit 62% de parts du marché camerounais.
D'après ces chiffres, nous estimons à 5 764 517
abonnés actifs sur le territoire national en cette date; ce qui
représente près du quart de la population nationale.
Comparé à la proportion de la population détentrice d'un
compte bancaire ou ayant droit aux services bancaires, ce nombre est largement
au dessus. Malgré ce boom technologique, sur environ une quarantaine
d'institutions financières (banques et coopératives bancaires)
que compte le Cameroun, moins d'une dizaine offre à leur
clientèle un service de banque à distance sur
téléphones mobiles.
Rendu à ce stade de l'observation, la
préoccupation de ce mémoire vise à faire une étude
du M-BANKING et implémenter une solution de banque à
distance.
I.2.2 Intérêt et
choix du sujet
Les services financiers sur mobile ont toutes les chances de
faire partie des applications les plus prisées sur
téléphone portable, rappelle l'entreprise ABI research. Elle
confirme qu'en 2013, ce ne sont pas moins de 500 millions de personnes qui
devraient être clientes de ce type de solutions. Notre défi
étant de faire du Cameroun un pays moderne. On ne peut être fort
que si on peut vivre dans un monde où la technologie n'est plus un
mythe. C'est dans cette optique que nous nous sommes assignés la
tâche d'étudier les techniques de banque à distance sur
téléphones mobiles et d'en déployer une afin d'apporter
notre pierre à la construction de l'édifice technologique
nationale et ainsi éclairer les uns et les autres sur ce sujet. C'est
également une occasion pour nous informer davantage sur le sujet et de
donner des armes technologiques aux banques, dans la mise sur pied de leur SVA.
Sur le plan technique, son principal atout est sa richesse. Ce projet nous
permettra de toucher le monde des télécommunications sans fil,
les réseaux informatiques, les protocoles de transport, les SGBD et les
langages de programmation sans oublier les systèmes d'exploitation.
PARTIE II :
APPROCHE THEORIQUE
DU M-BANKING
Dans cette présente partie, il sera question de poser des
bases théoriques relatives à notre sujet d'étude.
CHAPITRE I : QUELQUES DATES HISTORIQUES ET DEFINITIONS
II.1.1 Quelques dates
historiques
1876 : Invention du premier téléphone par
Alexander Graham Bell et Elisha Gray.
1885 : Apparition du téléphone sans fil,
sous la forme d'un radio phone.
18 janvier 1903 :
Guglielmo
Marconi envoie
un
message grâce à la télégraphie.
Années 1950 : Naissance du téléphone
mobile.
1976 : Mise sur pied de la première
génération de téléphonie mobile fonctionnant de
façon analogique AMPS (Advanced Mobile Phone System).
1982 : lancement des premiers services bancaires par
téléphone fixe
1984 : M. Matti Makkonen discute de l'idée de
créer un service de traitement de messages pour les
téléphones mobiles numériques, dans une pizzéria de
Copenhage, avec deux autres Finlandais, MM. Tiainen et Tapiola.
7 sep 1987 : Le réseau GSM voit effectivement vu
le jour suite à la signature de l'accord de développement du
réseau Global System for Mobile Communications (GSM).
1988 : L'ETSI, est fondé et est charge de
l'élaboration de normes communes en matière de
télécommunications.
1992 - le GSM va donner naissance à une
première expérience de SM.
3 décembre 1992 : L'ingénieur Neil Papworth
envoie le premier SM sur le réseau GSM de Vodafone en
Grande-Bretagne.
1997 : Lancement des premiers services bancaires par
message téléphonique de type SM par la banque Nordea..
1999 : Lancement des premiers services bancaires par
message téléphonique de type WAP.
II.1.2
Définitions
La banque à distance se définit comme
étant toute activité bancaire destinée à un client,
se déroulant à partir d'un point de service électronique
(téléphone, micro-ordinateur, téléviseur,
distributeur automatique de billets ou guichet automatique de banque) et
utilisant un système de télécommunication tel que le
réseau téléphonique, la télévision par
satellite, le minitel ou Internet. Le M-BANKING est donc une composante de la
banque à distance.
Le M-BANKING est un système basé sur le
réseau GSM permettant aux clients d'une banque d'accéder à
leurs comptes et à des informations générales (demande de
soldes, demande d'historique, demande de chéquier, etc.) sur les
produits et services bancaires via un téléphone mobil.
CHAPITRE II : LES DIFFÉRENTES TECHNOLOGIES
M-BANKING
Les principaux standards technologiques du M-BANKING
actuellement disponibles sont les suivants :
§ le STK-BANKING,
§ le WAP-BANKING,
§ le SMS-BANKING.
Nous tâcherons au travers des paragraphes suivants
d'effectuer un tour d'horizon des ces différentes technologies.
II.2.1 LE
STK-BANKING
I) II) II.2.1.1
Présentation générale du SIM TOOLKIT
La première génération de cartes SIM
appelées cartes Phase 1, insérées dans le
téléphone mobile, offrait à l'utilisateur des
fonctionnalités de base comme l'émission, la réception, le
transfert des appels ainsi que de la gestion de son répertoire. Cette
première génération disposait également des
fonctions de sécurité car chaque carte disposait de 1 kilooctet
de mémoire afin de stocker les informations relatives à
l'abonné associé (numéro d'appel, numéro
d'identifiant, type d'abonnement). Avec les cartes Phase 2 de 2ème
génération, la capacité de stockage de la carte SIM
atteint les 8 kilooctets. Les cartes SIM deviennent intelligentes et peuvent
utiliser le SMS du GSM. L'utilisateur accède alors à de nouveaux
services et à de nouvelles fonctionnalités telles que
l'identification de l'appelant, la mise en attente des appels et les
conversations à plusieurs. Enfin avec l'avènement des cartes
Phase 2+ de cette même génération, ce fut la naissance du
SIM toolkit, sa mémoire permet de stocker de 16 à 64 kilooctets
d'information. Ainsi, de petites applications (codées en langage Java,
ou applets Java.) peuvent y être stockées, transformant ainsi la
carte SIM en une plate-forme de services. Le téléphone devient un
terminal interactif capable d'héberger des applications intelligentes
dans la carte SIM et d'échanger des données avec un serveur
logiciel connecté à l'environnement de l'opérateur GSM.
II.2.1.2 Description du
STK-BANKING
L'augmentation des capacités de stockage de la carte
à puce a permis de faire évoluer fortement les
fonctionnalités du téléphone mobile ; permettant
ainsi aux opérateurs de téléphonie mobile d'offrir des
services à valeur ajoutée de plus en plus variés. D'un
point de vue plus commercial, l'avènement de la SIM Toolkit a
facilité le lancement des nouveaux SVA. Parmi ces services, Le
STK-BANKING est au coeur de la bataille que se livrent les opérateurs de
téléphonie mobile de part le monde.
Le STK-BANKING se définit comme étant un
service permettant aux clients d`un opérateur de
téléphonie mobile d'accéder aux informations de leurs
comptes bancaires via une application logée sur la carte SIM. La mise
sur pied d'un tel service nécessite que l'opérateur de
téléphonie signe des contrats avec diverses banques et travaille
en étroite collaboration avec celles afin de mettre sur pied les
différents composants de la plate forme.
Les principaux composants du STK-BANKING sont :
· un terminal mobile GSM, doté d'une carte SIM
toolkit dans laquelle est installée l'application cliente. Cette
application propose les différents services (demande de soldes, demande
d'historique, demande de chéquier, etc.) aux clients via une IHM et sous
forme de menu. Mais avant d'y accéder, l'utilisateur doit au
préalable s'authentifier. En général, les
paramètres d'authentification sont attribuer au client lors de son
abonnement au service Toutes les communications entre le terminal mobil et les
systèmes d'information de la banque se font via des messages courts
cryptés. La figure 1 représente une communication entre une
application cliente sur une carte SIM toolkit et son application distante.
· L'application serveur assurant la fonction de
passerelle entre le terminal mobile et les sources d'information (base de
données des différentes banques). Cette application effectue tous
les traitements sur la base de données de la banque et renvoie les
résultats au client. Elle(application serveur) peut être
hébergée soit chez les sources d'informations(banques) qui
souhaitent protéger leurs données clientèles
(numéros de comptes bancaires...) ou parce qu'elles sont reliées
à plusieurs opérateurs de téléphonie mobile; soit
chez les opérateurs qui souhaitent offrir des services
spécifiques à leurs abonnés dans des domaines applicatifs
trop variés pour placer une plate-forme chez chaque fournisseur
d'information ; soit chez un tiers hébergeur de l'opérateur.
Figure 1 : Communication
application SIM toolkit application serveur
· un support de communication entre l'application cliente
et le serveur : le SMS de l'opérateur de téléphonie permet
l'échange d'informations.
La figure 6 représente l'architecture
générale des différents composants d'une plate forme du
STK-BANKING.
Figure 2 : Architecture
composants STK-BANKING
II.2.1.3 Avantages du STK
BANKING
La sécurité est l'élément fort de
cette technologie. L'utilisation STK- BANKING se fait après s'être
authentifié. Toutes les informations sont cryptés par
l'application cliente avant d'être transmise par réseau GSM puis
sont décryptées au niveau de l'application serveur et vice-versa.
Le STK-BANKING est assez fiable car il est maîtrisé par les
opérateurs. Il est indépendant de la marque du
téléphone.
II.2.1.4
Inconvénients du STK-BANKING
Malgré ses forces, le STK-BANKING essuie néanmoins
quelques faiblesses :
§ après qu'une carte SIM soit livrée au
client il peut être difficile d'ajouter les applications ou encore de
modifier les fonctionnalités des applications existantes ;
§ la taille de la mémoire de la carte reste
réduite ; ce qui réduit les fonctionnalités à
allouer aux différentes applications.
II.2.1 II.2.2 Le
WAP-BANKING
II.2.2.1 Aperçu sur
le protocole WAP
Le protocole WAP est un
protocole de
communication permettant d'accéder à
internet à l'aide
d'un appareil de
transmission sans
fil ayant un écran de taille réduite, un processeur de faible
puissance et une autonomie limitée(un
téléphone
portable, un
assistant
personnel, etc.). Il redéfinit le protocole
HTTP, le
format des données
HTML et
l'interactivité obtenue par le langage
javascript.
Indépendant des architectures matérielles utilisées par
l'opérateur, il est utilisable sur des réseaux divers tels
que : GSM, CDMA, UTMS, TETRA...
Le protocole WAP est défini selon un modèle en 5
des couches. Chacune de ces couches définit une interface
vis-à-vis de la couche suivante.
La figure 3 représente les différentes couches
du protocole WAP.
Figure 3 : couches du
protocole WAP
· La couche WAE (Wireless Application
Environment)
La couche application du WAP définit l'environnement de
développement des applications sur les terminaux mobiles.
· La couche WSP (Wireless Session
Protocol)
La couche session est constituée de
deux protocoles :
- un
protocole
orienté connexion agissant au-dessus de la couche transaction
- un
protocole
non orienté connexion agissant au-dessus de la couche transport
· La couche WTP (Wireless Transaction
Protocol)
La couche de transaction gère le déroulement de
la transaction, elle définit donc la fiabilité du service. La
communication peut se faire de trois façons, c'est-à-dire :
- à sens unique avec acquittement
- à sens unique sans acquittement
- en
full
duplex avec acquittement
· La couche WTLS (Wireless Transport Layer
Security)
Les données circulant entre le terminal mobile et la
passerelle grâce à des réseaux sans fil, il est
nécessaire que les transactions soient sécurisées, c'est
ce que se propose de faire la couche sécurité. Celle-ci est
basée sur le standard SSL (Secure Socket
Layer) et permet :
- de crypter les échanges de données ;
- de garantir l'intégrité des données
(vérifier que celles-ci n'ont pas été
modifiées) ;
- d'authentifier les acteurs de l'échange.
· La couche WDP (Wireless Datagram
Protocol)
La couche WDP est à la base de la pile de protocoles
WAP, c'est elle qui est chargée de l'interface avec les protocoles de
transmission de données utilisés par les opérateurs de
télécoms.
II.2.2.2 Approche
conceptuelle du WAP-BANKING
Le WAP-BANKING se définit comme étant un
service permettant aux clients d`un opérateur de
téléphonie mobile d'accéder aux informations de leurs
comptes bancaires via une application logée sur un serveur web.
Tout comme pour le Web, les applications WAP sont
conçues dans une approche client - serveur. Le terminal mobile incorpore
un navigateur léger (l'équivalent d'Internet Explorer ou de
Netscape Navigator) qui communique avec un serveur WAP. Les ressources des
terminaux mobiles actuels étant limitées, le traitement des
données est principalement assuré côté serveur. Les
architectures WAP reposent sur quatre briques technologiques, chacune
étant nécessaire lors du transfert des données par le
protocole WAP. Ainsi pour la mise en oeuvre d'un service WAP-BANKING, nous
avons besoin de :
· un serveur Web et (ou) applicatif disposant de contenu
au format WAP (ou plus précisément WML). Ce serveur
héberge l'application permettant au client de faire ses
différentes demandes (demande de solde, demande d'historique, etc.) en
direction de la banque ;
· la passerelle ou serveur WAP : elle est
chargée de convertir les données reçues en paquets
conformes au protocole HTTP pour pouvoir dialoguer avec des serveurs Web et
vice-versa ;
· le réseau de l'opérateur ;
· l'utilisation par le client d'un terminal WAP c'est
à dire qui héberge un navigateur WAP. Le terminal n'a
d'utilité, vis à vis du WAP, que par l'existence de son
navigateur WAP. Le navigateur se charge en effet de décoder les
informations transmises par la passerelle WAP.
La figure 4 représente l'architecture
générale d'une application WAP
Figure 4 : Architecture générale
d'une application WAP
Le terminal mobile (un appareil mobile tel qu'un
téléphone supportant les fonctionnalités du WAP, un
assistant personnel, ou bien tout autre appareil capable de supporter cette
technologie) désirant obtenir des données, en provenance d'un
service WAP, doit dans un premier temps se connecter à une passerelle
à l'aide d'un numéro de téléphone, ou bien
grâce à un assistant de connexion. Lorsque le terminal mobile est
connecté à la passerelle, l'ensemble des transactions
effectuées par le mobile est envoyée par la passerelle au serveur
applicatif (serveur web) par une transmission de type
IP, sous
forme de requêtes proches du standard
HTTP.
Le serveur applicatif va renvoyer à la passerelle des documents au
format WML (le langage de formatage des documents affichables sur terminal
mobile), en fonction des requêtes du terminal mobile. Cela signifie que
le serveur peut utiliser les mêmes technologies qu'un serveur web pour
fournir ses données (accès à une
base de
données, exécution d'un script
CGI,
exécution de scripts
PHP ou
ASP, ou
bien de
servlets,
...). Une fois les données formatées, celles-ci sont
envoyées à la passerelle, qui va se charger de les transmettre au
terminal mobile.
La figure suivante explicite la
façon dont va avoir lieu un échange d'informations à
travers une application WAP lors d'une requête.
Figure 5 : Echange
d'information lors dune requête WAP
1. L'utilisateur appuie sur une touche de son
téléphone à laquelle correspond une URL
2. Une requête est envoyée à la passerelle
configurée, en utilisant le protocole WAP
3. La passerelle WAP crée une requête HTTP
conventionnelle pour l'URL demandée et la transmet au serveur Web
4. Cette requête HTTP est analysée par le serveur
Web. Si l'URL correspond à un fichier statique (html), le serveur Web va
chercher ce fichier et lui ajoute un entête HTTP. Si l'URL correspond
à un script CGI ou autres, dans ce cas, le serveur lance l'application
correspondante.
5. Le serveur Web retourne le jeu de cartes WML avec
l'entête HTTP ajouté, ou directement les données WML issues
du script.
6. La passerelle WAP vérifie l'entête HTTP et le
contenu WML, et code le tout dans une forme binaire. La passerelle crée
alors une réponse au format WAP qui est transmise au navigateur.
7. Le navigateur reçoit une réponse. Il
interprète le contenu WML et affiche la première carte du jeu de
carte.
II.2.2.3 Avantages du
WAP-BANKING
Le principal avantage du WAP est son interactivité,
permettant de concevoir de applications fortement structurées et
facilement modifiables. Il offre ainsi la possibilité de créer
des rubriques, mettre des informations en ligne, consultables à
l'initiative de l'utilisateur, à partir de son téléphone
mobile. Il permet également de protéger les informations
transmises entre le client et la banque.
II.2.2.4 Inconvénients du WAP-BANKING
Le WAP n'a pas jusqu'à présent connu le
succès commercial escompté. Ceci est du à :
§ la plupart des utilisateurs ne savent pas
déclencher une session WAP à partir de leur mobile ;
§ le WAP nécessite 30 à 40 secondes de
connexion et un nombre de « clicks » importants avant
d'accéder à l'information utile pour réaliser une
transaction ;
§ le WAP est synchrone, c'est-à-dire que vous
recevez immédiatement le résultat de votre requête. Si pour
une raison ou une autre, votre appareil mobil perd la connexion avec le
réseau de l'opérateur de téléphonie, vos n aurez
pas l'information escomptée même quand la connexion redeviendra
normale ;
§ tous les téléphones portables ne sont pas
compatibles WAP.
II.2.3 Le
SMS-BANKING
II.2.3.1
Présentation générale du SMS
Le service de messages courts
offert par le réseau GSM permet à un utilisateur de composer un
message textuel d'au plus 160 caractères (codés à l'aide
d'ASCII 7 bits sur 140 octets) à partir de son terminal et de l'envoyer
à un destinataire possédant un téléphone mobile ou
à une entité extérieure au réseau GSM
appelée SME (Short Message Entity). Un SME est l'application capable de
recevoir les SM.
Les messages émis sont soit transmis directement au
terminal destinataire du message (si celui-ci est allumé), soit
stockés dans le serveur de message courts (SMSC, pour SMS Center) par
lequel il transite. Les messages courts ne circulent pas dans les mêmes
canaux logiques que la voix ou les données si bien qu'il est possible
pour un utilisateur en communication téléphonique (avec un autre
correspondant) de recevoir des messages courts simultanément. Le SMS
nécessite la mise en place d'un ou plusieurs serveurs spécifiques
dans le réseau GSM. Le serveur de messages courts (SMSC) assure le
stockage (dans des bases de données), la distribution aux terminaux
destinataires (quand ceux-ci se sont manifestés dans le réseau
GSM auquel ils appartiennent) et le traitement des dates de validité des
SM. Les SMSC fonctionnent en "Store and Forward" c'est-à-dire qu'ils
envoient le SM au récepteur si et seulement si ce dernier est
opérationnel dans le réseau. Lorsque le SM est envoyé, il
passe successivement par les équipements BTS, BSC, MSC /VLR avant
d'être router vers le SMSC approprié. Si à ce niveau le SM
est bien reçu, un acquittement de bonne réception est
envoyé au MSC/VLR, qui à son tour l'envoi au mobile. La figure 6
illustre toute la littérature expliquant la transmission d'un SM depuis
un terminal.
Figure 6 : Transmission
d'un SM depuis un terminal
Lors de l'acheminement d'un SM, le SMSC envoie d'abord une
requête de localisation au HLR, qui l'indique le MSC/VLR où est
enregistré le terminal destinataire. S'il est accessible,
le SMSC lui délivre le message. Après avoir reçu
le SM, le mobile renvoi au SMSC un acquittement de réception par le
biais du MSC/VLR. La figure 7 modélise l'acheminement d'un SM vers un
terminal.
Figure 7 : Transmission d'un SM du SMSC vers un
terminal destintaire
II.2.3.2 Qu'est ce que le
SMS-BANKING
Le SMS BANKING est une application bancaire permettant aux
clients d'une banque ou coopérative bancaire de recevoir leur
état financier, d'effectuer des transactions financières ou
encore d'effectuer des demandes bancaires tels que : les demandes de
chéquiers, les demandes de soldes via leur téléphone
portable en utilisant le SMS de l'opérateur d'un opérateur de
téléphonie mobile.
II.2.3.3 Architecture
générale d'une plate forme SMS-BANKING
Il existe en général deux types d'architecture
pour mettre sur pied une plate forme de SMS BANKING. Mais, quelque soit
l'architecture choisit notons qu'il nous faudra toujours :
· les modems GSM qui permettent à la banque de se
connecter au réseau d'un opérateur de téléphonie en
utilisant les cartes SIM ;
· les téléphones portables que doivent
disposer les clients qui veulent s'abonner à ce service ;
· une application serveur comprenant toutes les
fonctionnalités du SMS BANKING et qui sera déployée au
niveau des serveurs de la banque
II.2.3.3.1 Architecture
utilisant une passerelle
Dans cette architecture les modems GSM
sont reliés sur une passerelle GSM/IP. Toutes les SM transitent par
elle. Elle reçoit les requêtes des clients et les redirigent vers
les serveurs de base de données de la banque. Ou encore transmet les
informations venant des serveurs en direction des clients. C'est cette
passerelle qui est chargée de gérer toutes les files d'attentes
des SM entrants et sortant dans le système.
Figure 8 : Plate forme
SMS BANKING avec passerelle
II.2.3.3.2 Architecture sans passerelle
Dans cette architecture, le modem GSM est directement
lié aux serveurs de base de données de la banque. Il faut
écrire un programme qui va relier notre modem GSM à la base de
données de la banque. L'une des difficultés ici est que le
développeur doit non seulement bien synchroniser les files d'attente des
SM sortant et entrant, mais aussi connaître parfaitement les commandes AT
afin de pouvoir communiquer aisément avec le modem GSM.
Figure 9 : Plate forme
SMS BANKING sans passerelle
II.2.3.4 Avantages du
SMS-BANKING
Les avantages du SMS-BANKING sont également ceux du SMS
de l'opérateur de téléphonie. Ils sont entre
autres :
§ les SM utilisant un canal de signalisation, ils sont
presque toujours transmis même lorsque le réseau mobile est
saturé par de nombreux appels. (exceptions: panne ou destruction du
réseau mobile ou en fin d'année lorsque de très nombreux
SM sont transmis simultanément) ;
§ le service est quasi-instantané : chaque envoi
est acheminé immédiatement au(x) destinataire(s)
sélectionné(s) ;
§ la réception et la lecture des SM sont
gratuites, ils n'induisent donc aucune charge financière pour le
récepteur, et peuvent être consultés malgré un
forfait épuisé ;
§ la communication, non intrusive, ne dérange pas
le récepteur qui peut consulter son SM à son moment
voulu ;
§ les SM sont compatibles sur tout type de
téléphone.
II.2.3.5
Inconvénients du SMS-BANKING
L'utilisation des SM n'est cependant pas dépourvue
d'inconvénients. La sécurité est le point faible du
SMS-BANKING. Tous les messages envoyés circulent en clair dans le
réseau de l'opérateur de téléphonie. Ainsi, toutes
les informations sniffées sont lisibles sans aucunes
difficultés.
II.2.4 Le M-BANKING au
Cameroun
Comme énoncé dans la partie
problématique, le M-BANKING au Cameroun est encore dans son état
embryonnaire. Les banques ou coopératives bancaires ont encore du mal
à s'enrôler de cette technologie. D'après nos
investigations aucune institution financière n'offre un service de
WAP-BANKING. Le SMS-BANKING qui est la technologie la plus en vue est la
panache de quelques banques. Nous avons entre autre la SGBC avec le service
MESSALIA, la BICEC avec son service BICEC info, ECOBANK et bien d'autres.
Quant au STK-BANKING, il est encore dans sa phase développement ;
une entreprise est présentement en laboratoire et travaille pour la mise
en oeuvre ce type de service. Il s'agit de l'opérateur de
téléphonie mobile MTN Cameroun qui lancera le service MTN mobile
money dans les prochains mois.
II.2.5 Comparaison entre le
STK-BANKING, le WAP-BANKING et le SMS-BANKING
Nous ferons cette comparaison grâce à un
tableau.
|
STK- BANKING
|
WAP- BANKING
|
SMS- BANKING
|
|
SECURISE
|
OUI
|
OUI
|
NON
|
|
DEPENDENCE AVEC L'OPERATEUR DE TELEPHONIE
|
OUI
|
NON
|
NON
|
|
ADAPTABLE A TOUS LES TELEPHONES MOBILES
|
OUI
|
NON
|
OUI
|
|
FACILEMENT UTILISABLE
|
OUI
|
NON
|
OUI
|
|
CAPACITE D'AJOUTER DES FONCTIONNALITES FACILEMENT
|
NON
|
OUI
|
OUI
|
Tableau 1 :
Comparaison entre STK-BANKING, WAP-BANKING et SMS-BANKING
Il ressort de ce tableau que le SMS-BANKING et le WAP-BANKING
sont les deux seules solutions que nous pouvons réaliser car, le
STK-BANKING est une technique qui ne dépend pas seulement de
l'éditeur de logiciel mais aussi de l'opérateur de
téléphonie ; étant donné que ce dernier est le
propriétaire de la carte SIM. Mais, étant donné les points
faibles du WAP-BANKING à savoir qu'il est non compatible à tous
les téléphones et la méconnaissance de cette technique par
le grand public, nous avons choisi d'implémenter le SMS BANKING.
PARTIE II : REALISATION DE
NOTRE SOLUTION DE SMS-BANKING
La partie précédente a consisté
à dégager la préoccupation principale de nos travaux et
les différentes questions qui s'y rattachent. Nous nous proposons dans
cette section de présenter la démarche adoptée pour
répondre à ces différentes questions.
Ce chapitre présente les résultats
auxquels nous avons abouti, suivi de commentaires. Il commence par un bref
rappel des objectifs initiaux, vient ensuite la présentation des
résultats obtenus à travers les différents
modules.
CHAPITRE I : CHOIX TECHNOLOGIQUES
Disposant d'une multitude de techniques et de technologies
pour mettre en oeuvre la plate forme SMS-BANKING, il a fallu au
préalable que nous choisissons celles avec lesquelles nous allons
implémenter la solution.
Un facteur apparaît primordial voire déterminant
pour une bonne implantation de l'application SMS-BANKING : la gestion des
files d'attentes des SM émis par les clients ou en direction des
clients. Notre système devra avoir moins de pertes et savoir
gérer les flux des SM. Les passerelles SMS étant conçues
avec ces caractéristiques, nous avons choisi d'implémenter une
solution utilisant une passerelle.
Afin de réaliser l'application, nous nous sommes
appuyés sur la méthode UP, méthode qui offre l'avantage de
bâtir un système de manière incrémentale et
itérative.
III.1.1 La passerelle SMS
Une passerelle SMS est un dispositif ou un service permettant
router les SM du réseau GSM vers un réseau quelconque (intranet
par exemple) ou vice versa. Elle gère les queues (files d'attente), les
droits d'accès, les journaux, les connexions aux modems, les rapports de
livraisons de SM etc....
III.1.2 La méthode
UP
Le processus unifié est un processus de
développement logiciel itératif, centré sur
l'architecture, piloté par des cas d'utilisation et orienté vers
la diminution des risques. C'est un patron de processus pouvant être
adaptée à une large classe de systèmes logiciels, à
différents domaines d'application, à différents types
d'entreprises, à différents niveaux de compétences et
à différentes tailles de l'entreprise.
§ UP est itératif: L'itération est une
répétition d'une séquence d'instructions ou d'une partie
de programme un nombre de fois fixé à l'avance ou tant qu'une
condition définie n'est pas remplie, dans le but de reprendre un
traitement sur des données différentes. Elle qualifie un
traitement ou une procédure qui exécute un groupe
d'opérations de façon répétitive jusqu'à ce
qu'une condition bien définie soit remplie.
§ UP est piloté par les cas d'utilisation
d'UML : Le but principal d'un système informatique est de
satisfaire les besoins du client. Le processus de développement sera
donc centré sur l'utilisateur. Les cas d'utilisation permettent
d'illustrer les besoins de l'utilisateur. Ils détectent puis
décrivent les besoins fonctionnels (du point de vue de l'utilisateur),
et leur ensemble constitue le modèle de cas d'utilisation qui dicte les
fonctionnalités complètes du système.
§ UP est centré sur l'architecture.
La méthode UP s'articule autour de quatre (04)
phases :
· L'analyse des besoins : donne une vue du projet
sous forme de produit fini. Cette phase porte sur les besoins principaux
· L'élaboration : cette phase reprend les
éléments de la phase d'analyse des besoins pour arriver à
une solution détaillée de la mise en oeuvre
· La construction : c'est le moment où on
construit le produit. L'architecture de référence se
métamorphose en produit complet.
· Transition : le produit est en version bêta,
un groupe d'utilisateurs essaie le produit et détecte les anomalies et
défaut.
Ces différentes phases s'organisent autour
d'activités. Les principales activités de la méthode UP
sont :
· l'expression des besoins : permet de
définir les différents besoins, tant fonctionnels que non
fonctionnel,
· l'analyse : permet d'accéder à une
compréhension des besoins et des exigences du client. Il s'agit de
livrer des spécifications pour permettre de choisir la conception de la
solution,
· la conception : permet d'acquérir une
compréhension approfondie des contraintes liées aux outils de
réalisation, à l'utilisation des composants et au système
d'exploitation,
· la mise en oeuvre : c'est le résultat de la
conception pour implanter le système sous forme de composants, c'est
-à-dire d'éléments prêt à l'emploi ;
· la validation : elle permet de vérifier et
de valider la mise en oeuvre.
CHAPITRE II : ANALYSE
III.2.1 Expression des
besoins
Pour la mise en oeuvre de notre solution SMS BANKING, il a
fallu que nous recensions les différentes fonctionnalités du
système.
III) III.2.1.1 Les
différents services qui seront proposées aux clients
III.2.1.1.1 Des services
d'information à la demande
Grâce à ces fonctionnalités les clients
peuvent à tout moment demander de recevoir des informations par SM sur
leur téléphone mobile. Pour cela le client envoie un SM contenant
un mot clé spécifique au service dont il veut avoir accès
auquel il ajoute un code personnel (code PIN) qui lui est attribué par
la banque. Ces différents services sont :
· demande de solde,
· demande historique (quatre dernières transactions
sur un compte),
· demande de chéquier,
· demande de virement.
Exemple: pour consulter son solde, il va simplement envoyer un
SM depuis son téléphone contenant :<code service
solde> <code personnel>. Comme exemple, nous pouvons avoir le SM
suivant : D12 A001
III.2.1.1.2 Des
services de notification évènementielle
Ces fonctionnalités permettent aux clients de recevoir
des informations sur leurs téléphones mobiles lorsqu'un
évènement se produit ou une condition est satisfaite. Nous aurons
entre autre :
· alerte par SM après virement d'un salaire,
· alerte par SM après un débit sur un compte,
· alerte par SM pour toutes les transactions
effectuées sur le compte,
· alerte par SM après crédit sur un compte,
· alertes/Information marketing (promotionnelles),
· alerte par SM après dépassement de seuil
minimal,
· alerte de virement spontané,
· alerte par SM après dépassement de seuil
maximal.
Exemple : après virement d'un salaire, un SM est
automatiquement envoyé au client pour l'en informer.
III.2.1.1.3 Des services de
notification périodique
Cette fonctionnalité permet aux clients de recevoir
périodiquement des informations concernant le solde de leurs comptes.
Les fréquences sont les suivantes :
· mensuelle : le client reçoit son solde tous
les 1 er du mois,
· hebdomadaire : le client reçoit son solde
chaque lundi,
· quotidienne : le client reçoit son solde tous
les jours.
III.2.1.2 Gestion des
clients
L'application SMS BANKING devra être capable de
gérer des milliers de numéro de compte, numéro de GSM,
services choisis (solde, alertes virements de salaire, alertes
dépôts, historiques...), paramétrage d'envoi de
l'information pour chaque client, seuils personnalisés,... Comme autres
fonctionnalités, nous aurons :
· importation automatique des comptes des clients
inscrits à SMS BANKING de la base de données bancaire vers la
base de données de SMS BANKING,
· activation et désactivation des comptes clients aux
différents services,
· possibilité de définir les règles de
diffusion des alertes,
· consultation en temps réel des comptes à
partir des options multicritères de recherche.
III.2.1.3 Gestion de la
facturation
SMS BANKING donnera à la banque ou la
coopérative bancaire la liberté de définir sa politique
tarifaire adéquate (facturation mensuelle ou facturation par SM
envoyé au client) et de paramétrer la facturation pour chaque
client.
III.2.1.4 GESTION DES
SM
L'application devra offrir la possibilité de :
· consulter à tout moment de tous les messages
reçus par le système,
· consulter à tout moment de tous les messages
émis par le système,
· rechercher tous les SM envoyés ou reçus par
un client,
· rechercher tous les SM reçu ou envoyé par
le système pendant une période,
· de rechercher les SM entrant et sortant par service.
III.2.1.5 Sécurité
Pour les besoins de sécurité, chaque client de
SMS BANKING doit avoir un code PIN personnel qu'il devra intégrer
à tous ses SM. De plus, en vue de renforcer la sécurité,
les SM ne sont traités que lorsque le numéro de
téléphone du client et le code pin sont justes.
III.2.1.6 Etats et
statistiques
Des états pourront être extraits de l'application et
imprimés ou enregistrés.
· possibilités de tirer des statistiques
individuelles sur les SM des clients,
· possibilités de tirer des statistiques sur les SM
pour une période donnée (SM envoyés, reçus) et les
grouper par service.
III.2.2 Analyse
III.2.2.1 Définition de quelques concepts
· Un cas d'utilisation représente l'image d'une
fonctionnalité du système. Il est déclenché par un
acteur, qui est une entité externe au système et nécessite
que ce dernier lui rende service. Il s'agit donc d'une représentation du
système tel que perçu par les différents utilisateurs.
· Un scénario de cas d'utilisation est le
déroulement d'un cas d'utilisation. Il permet d'échafauder toutes
les hypothèses relatives au cas d'utilisation. Il est
caractérisé par :
o une pré-condition : c'est la condition à
remplir avant que le scénario ne soit déclenché ;
o une post-condition : c'est la condition que doit
vérifier le système à la fin du scénario ;
o un résumé métier : qui
décrit de façon superficielle les principales étapes du
déroulement du cas d'utilisation ;
o le scénario nominal : qui représente le
déroulement du cas d'utilisation de la meilleure des façons
possibles, c'est-à-dire qu'aucun facteur ne nuit à son
déroulement ;
o le scénario alternatif : il s'agit du
déroulement d'un cas d'utilisation lorsqu'une erreur s'est produite
suite au non respect d'une contrainte.
· Un acteur représente un rôle joué
par une entité externe qui interagit directement avec le système
étudié. Cette entité externe peut être un
utilisateur humain, un dispositif matériel ou un autre système.
III.2.2.2 Principaux cas
d'utilisation autour desquels s'organise SMS BANKING
Nous allons présenter ici quelques cas d'utilisation et
les diagrammes de cas d'utilisation qui en d'écoulent.
Consultation du solde du compte : avec
son téléphone mobil, le client envoie un SM ayant un format
spécifique. Si toutes les conditions sont vérifiées, le
client reçoit en retour un SM dans lequel se trouve le solde de son
compte.
Consultation des 4 derniers historiques de compte
: ce cas d'utilisation permet au client de consulter les 4 derniers
historiques de son compte en utilisant son téléphone mobile. Un
SM avec cet historique lui est envoyé
Demande de chéquier : il s'agit ici
pour le client de faire la demande d'un nouveau chéquier en utilisant un
SM. Un premier SM lui est renvoyé pour confirmer que la demande a
été prise en compte. Un second SM lui est renvoyé lorsque
l'utilisateur confirme le traitement de cette demande.
Demande de virement vers un autre compte : ce
cas d'utilisation permet au client de faire la demande de transfert d'argent
vers un compte autre que le sien en utilisant un SM. Un premier SM lui est
renvoyé pour confirmer que la demande a été prise en
compte. Un second SM lui est renvoyé lorsque l'utilisateur confirme le
traitement de cette demande.
Alerte de débit sur un compte : ce cas
d'utilisation permet au système d'alerter le client lorsque son compte
est touché en débit. Un SM lui est envoyé avec le montant
débité.
Alerte de crédit sur un compte : ce
cas d'utilisation permet au système d'alerter le client lorsque son
compte est touché en crédit. Un SM lui est envoyé avec le
montant crédité.
Alerte de virement de salaire sur un compte :
il s'agit ici pour le système d'alerter le client lorsque son compte
est touché en débit. Un SM lui est envoyé avec le montant
viré.
Alerte périodique de solde d'un compte
: grâce à ce cas d'utilisation le système informe
le client quotidiennement, hebdomadairement ou mensuellement du solde de son
compte. Un SM lui est envoyé avec le montant du solde suivant la
périodicité qu'il a choisie.
Alerte de virement spontané sur un compte
: il s'agit ici pour le système d'alerter le client lorsqu'une
somme d'argent est virée sur son compte. Un SM lui est envoyé
avec le montant viré.
Alerte de dépassement de seuil minimal du solde
d'un compte : ce cas d'utilisation permet au système d'alerter
le client lorsque le solde de son compte est inférieure à un
montant minimal qu'il a choisit. Un SM lui est envoyé pour l'en
informer.
Alerte de dépassement de seuil maximal du solde
d'un compte : Ce cas d'utilisation permet au système d'alerter
le client lorsque le solde de son compte est supérieur à un
montant maximal qu'il a choisit. Un SM lui est envoyé pour l'en
informer.
Nous avons pour acteurs :
§ Client mobile : client muni de son
téléphone mobil
§ Utilisateur : personne qui se connecte à un
service spécifique de SMS BANKING avec des droits d'administration sur
ce service.
§ BANK SI (un acteur qui est n'est pas humain) : c est
la base de données de la banque et l'interface de synchronisation entre
elle et la base de données de SMS-BANKING
Les diagrammes des principaux cas d'utilisation sont :
Figure 10 : Diagramme de
cas d'utilisation des services d'informations à la
demande
III.2.2.3 Description
détaillée de quelques cas d'utilisation
Nous avons choisis de ne présenter ici que quelques
scénarii jugés importants. Certains cas d'utilisation sont pris
individuellement décris par les différents scenarii
jusqu'à la présentation des diagrammes de séquence et
d'activité correspondants.
Sommaire d'identification
Titre : Consultation de solde
Résumé : ce cas
d'utilisation permet au client de consulter le solde de son compte à
partir de son téléphone portable.
Acteurs : Client mobile
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication permettant l'envoi de SMS, Disposer d'un
téléphone
Post conditions : Un SMS possédant le solde
est renvoyé au client
Description des scénarios
- Scénario nominal
|
1. Le client formate un SMS et l'envoi au numéro de la
carte SIM présente dans le modem connecté à la passerelle
GSM/IP de la banque ou coopérative bancaire
|
|
2. Réception, vérification du format du SMS et
stockage du SMS dans la base de données de SMS BANKING par le
système.
|
|
3. Vérification du code PIN du client par le
système.
|
|
4. Vérification du numéro de
téléphone du client par le système.
|
|
5. Vérification effective de l'inscription du client au
service de consultation de solde par le système.
|
|
6. La vérification si le nombre maximal de SMS a
envoyé au client pour le mois en cours et pour le service de
consultation de solde est atteint par le système.
|
|
7. La récupération du solde du client par le
système.
|
|
8. Formatage du message à retourner au client par le
système.
|
|
9. Insertion dans la table d'historique des SMS par le
système.
|
|
10. Insertion du SMS à envoyer au client dans la table
des SMS sortants par le système.
|
|
11. Mis à jour du statut du SMS entrée (SMS
traité) par le système.
|
|
12. Incrémentation du compteur de SMS (ce compteur
permet de compter le nombre de SMS déjà envoyé au client
durant ce mois. Il est nécessaire pour la vérification du seuil
maximal) pour le service de consultation de solde.
|
|
13. Envoi du SMS avec solde au client par le
système.
|
|
14. Mis à jour du statut du SMS sortant (SMS
envoyé) par le système.
|
- Scénario alternatif
|
E1
|
Le système détecte des erreurs sur le
formatage du SMS. Le scénario E1 démarre au point 2. du
scénario nominal.
|
|
Le système enregistre le SMS avec une remarque :
« Mauvais SMS ». Dans ce cas, le scénario nominal s
arrête au point 2.
|
|
E2
|
Le système détecte que le code PIN du
client est incorrect. Le scénario E2 démarre au point 3. du
scénario nominal.
|
|
Le système met à jour la table des SMS
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 3
E3 Le système
détecte que le numéro de téléphone du client
est
incorrect. Le scénario E3 démarre
au point 4. du scénario nominal.
Le système met à jour la table des SMS
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 4
|
|
E4
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E4 démarre au point
5 du scénario nominal.
|
Le système met à jour la table des SMS entrant
avec pour remarque : « Client non inscrit au service
spécifié »
Dans ce cas, le scénario nominal s arrête au
point 5
|
E5
|
Le système détecte que le nombre
maximal de SMS du mois courant pour le service de consultation de solde est
atteint. Le scénario E5 démarre au point 6 du scénario
nominal.
|
Le système met à jour la table des SMS entrant
avec pour remarque : « Nombre maximal de SMS
atteint »
Dans ce cas, le scénario nominal s'arrête au
point 6
|
E6
|
Le système n'arrive pas à envoyer le
SMS. Le scénario E6 démarre au point 13 du scénario
nominal.
|
Le système met à jour la table des SMS sortant
avec un statut permettant d'identifier la source d'erreur. Le SMS sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
13.
Figure 11 : Diagramme de
sequence du cas d'utilisation « demande de
solde »
Figure 12 : Diagramme de
cas d'activité du cas d'utilisation « demande de
solde »
Sommaire d'identification
Titre : Demande de chéquier
Résumé : Ce cas
d'utilisation permet au client de faire une demande à partir
chéquier à partir de son téléphone portable.
Acteurs : Client mobile, utilisateur
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication permettant l'envoi de SMS, Disposer d'un
téléphone
Post conditions : deux SM sont envoyés au
client. Un pour l'informer que sa demande est bien arrivé et sera
traité puis un second pour l'en informer que sa demande de
chéquier est traité.
Description des scénarios
- Scénario nominal
|
1. Le client formate un SMS et l'envoi au numéro de la
carte SIM présente dans le modem connecté à la passerelle
GSM/IP de la banque ou coopérative bancaire
|
|
2. Réception, vérification du format du SMS et
stockage du SMS dans la base de données de SMS BANKING
|
|
3. Vérification du code PIN du client
|
|
4. Vérification du numéro de
téléphone du client
|
|
5. Vérification effective de l'inscription du client au
service de demande de chéquier
|
|
6. La vérification si le nombre maximal de SMS a
envoyé au client pour le mois en cours et pour le service de demande de
chéquier est atteint.
|
|
7. Insertion de la demande dans la table des transactions
|
|
8. Formatage du premier message à retourner au client
lui informant que sa demande sera traitée
|
|
9. Insertion dans la table d'historique des SMS
|
|
10. Insertion du SMS à envoyer au client dans la table
des SMS sortants
|
|
11. Mis à jour du statut du SMS entrée:SMS
traité
|
|
12. Incrémentation du compteur de SMS (ce compteur
permet de compter le nombre de SMS déjà envoyé au client
durant ce mois. Il est nécessaire pour la vérification du seuil
maximal) pour le service demande de chéquier. Le système extrait
le numéro de téléphone du récepteur
|
|
13. Envoi du premier SMS de confirmation de la demande
|
|
14. Mis à jour du statut du SMS sortant: SMS
envoyé
|
|
15. L'utilisateur confirme le traitement de la demande de
chéquier
|
|
16. Formatage du second message à retourner au client
lui informant que sa demande a été traitée
|
|
17. Insertion dans la table d'historique des SMS
|
|
18. Insertion du SMS à envoyer au client dans la table
des SMS sortants
|
|
19. Mis à jour du statut du SMS entrée: SMS
traité
|
|
20. Incrémentation du compteur de SMS pour le service
demande de chéquier
|
|
21. Envoi du second SMS de traitement de demande
effectué
|
|
22. Mis à jour du statut du SMS sortant: SMS
envoyé
|
- Scénario alternatif
|
E1
|
Le système détecte des erreurs sur le
formatage du SMS. Le scénario E1 démarre au point 2. du
scénario nominal.
|
|
Le système enregistre le SMS avec une remarque :
« Mauvais SMS ». Dans ce cas, le scénario nominal s
arrête au point 2.
|
|
E2
|
Le système détecte que le code PIN du
client est incorrect. Le scénario E2 démarre au point 3. du
scénario nominal.
|
|
Le système met à jour la table des SMS
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 3
E3 Le système
détecte que le numéro de téléphone du client
est
incorrect. Le scénario E3 démarre
au point 4. du scénario nominal.
Le système met à jour la table des SMS
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 4
|
|
E4
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E4 démarre au point
5 du scénario nominal.
|
Le système met à jour la table des SMS entrant
avec pour remarque : « Client non inscrit au service
spécifié »
Dans ce cas, le scénario nominal s arrête au
point 5
|
E5
|
Le système détecte que le nombre
maximal de SMS du mois courant pour le service de demande de chéquier
est atteint. Le scénario E5 démarre au point 6 du scénario
nominal.
|
Le système met à jour la table des SMS entrant
avec pour remarque : « Nombre maximal de SMS
atteint »
Dans ce cas, le scénario nominal s'arrête au
point 6
|
E6
|
Le système n'arrive pas à envoyer le
premier SMS. Le scénario E6 démarre au point 13 du
scénario nominal.
|
Le système met à jour la table des SMS sortant
avec un statut permettant d'identifier la source d'erreur. Le SMS sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
13.
|
E7
|
L'utilisateur donne un accord négatif à
la demande de chéquier. Le scénario E7 démarre au point
15 du scénario nominal.
|
Formatage du second message à retourner au client lui
informant que sa demande n'a pas été traitée avec la cause
du non traitement.
|
E8
|
Le système n'arrive pas à envoyer le
second SMS. Le scénario E6 démarre au point 21 du
scénario nominal.
|
Le système met à jour la table des SMS sortant
avec un statut permettant d'identifier la source d'erreur. Le SMS sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
21.
Figure 13 : Diagramme de
sequence du cas d'utilisation « demande de
chéquier »
Figure 14 : Diagramme
d'activité du cas d'utilisation demande de
chéquier
Sommaire d'identification
Titre : Alerte crédit compte
Résumé : Ce cas
d'utilisation permet d'envoyer un SM à un client lorsque son compte est
crédité.
Acteurs : Client + mobile, BANK SI
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication dans le modem de la banque permettant l'envoi du
SM, le réseau de l'opérateur de téléphonie doit
être opérationnel.
Post conditions : Un SM avec le montant
crédité est envoyé au client
Description des scénarios
- Scénario nominal
|
1. BANK SI met à jour ou effectue un nouvel
enregistrement dans la BD SMS-BANKING avec statut non traité
|
|
2. Le système récupération du nouvel
enregistrement
|
|
3. Le système vérifie si il s'agit d'un
crédit sur un compte
|
|
4. Le système vérifie si le client inscrit au
service « d'alerte en cas de crédit » sur le
compte
|
|
5. Le système vérifie si le nombre maximal de SM
a envoyé au client pour le mois en cours et pour le service d'alerte en
cas de crédit du compte est atteint
|
|
6. Le système formate le message à envoyer au
client avec montant crédité
|
|
7. Le système recherche le numéro de
téléphone du client
|
|
8. Le système insertion SM dans la table d'historique
des SM
|
|
9. Le système insert le SM à envoyer au client
dans la table des SM sortants avec statut (non envoyé)
|
|
10. Mis à jour du Statut de l'enregistrement
(traité)
|
|
11. Le système incrémente le compteur de SM (ce
compteur permet de compter le nombre de SM déjà envoyé au
client durant ce mois. Il est nécessaire pour la vérification du
seuil maximal) pour le service alerte en cas de crédit.
|
|
12. Le système envoie le SM « d'alerte de
crédit du compte » au client
|
|
13. Le système met à jour du statut du SM
sortant: SM envoyé
|
- Scénario alternatif
|
E1
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E1 démarre au point
4 du scénario nominal.
|
Le système met à jour cet enregistrement :
« Client non inscrit au service spécifié »
Dans ce cas, le scénario nominal s arrête au
point 4
|
E2
|
Le système détecte que le nombre
maximal de SM du mois courant pour le service d'alerte en cas de crédit
est atteint. Le scénario E2 démarre au point 5 du scénario
nominal.
|
Le système met à jour cet enregistrement :
« Nombre maximal de SM atteint »
Dans ce cas, le scénario nominal s'arrête au
point 5
|
E3
|
Le système n'arrive pas à envoyer le
SM. Le scénario E3 démarre au point 12 du scénario
nominal.
|
Le système met à jour la table des SM sortant
avec un statut permettant d'identifier la source d'erreur. Le SM sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
12.
Figure 15 : Diagramme de
séquence du cas d'utilisation « alerte credit
compte »
Figure 16 : Diagramme de d'activité du cas d'utilisation
alerte credit compte
Sommaire d'identification
Titre : Alerte virement salaire
Résumé : Ce cas
d'utilisation permet d'envoyer un SM à un client lorsque son salaire est
viré sur son compte.
Acteurs : Client mobile, BANK SI
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication dans le modem de la banque permettant l'envoi du
SM, le réseau de l'opérateur de téléphonie doit
être opérationnel.
Post conditions : Un SM avec le montant
viré est envoyé au client
Description des scénarios
- Scénario nominal
|
1. BANK SI met à jour ou effectue un nouvel
enregistrement dans la BD SMS-BANKING avec statut non traité
|
|
2. Le système récupération du nouvel
enregistrement
|
|
3. Le système vérifie si il s'agit d'un virement
salaire sur un compte
|
|
4. Le système vérifie si le client inscrit au
service « virement salaire » sur le compte
|
|
5. Le système vérifie si le nombre maximal de SM
a envoyé au client pour le mois en cours et pour le service d'alerte en
cas de débit du compte est atteint
|
|
6. Le système formate le message à envoyer au
client avec montant viré
|
|
7. Le système recherche le numéro de
téléphone du client
|
|
8. Le système insertion SM dans la table d'historique
des SM
|
|
9. Le système insert le SM à envoyer au client
dans la table des SM sortants avec statut (non envoyé)
|
|
10. Mis à jour du Statut de l'enregistrement
(traité)
|
|
11. Le système incrémente le compteur de SM (ce
compteur permet de compter le nombre de SM déjà envoyé au
client durant ce mois. Il est nécessaire pour la vérification du
seuil maximal) pour le service alerte en cas de virement salaire.
|
|
12. Le système envoie le SM « de virement
salaire » au client
|
|
13. Le système met à jour du statut du SM
sortant: SM envoyé
|
- Scénario alternatif
|
E1
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E1 démarre au point
4 du scénario nominal.
|
Le système met à jour cet enregistrement :
« Client non inscrit au service spécifié »
Dans ce cas, le scénario nominal s arrête au
point 4
|
E2
|
Le système détecte que le nombre
maximal de SM du mois courant pour le service d'alerte en cas de crédit
est atteint. Le scénario E2 démarre au point 5 du scénario
nominal.
|
Le système met à jour cet enregistrement :
« Nombre maximal de SM atteint »
Dans ce cas, le scénario nominal s'arrête au
point 5
|
E3
|
Le système n'arrive pas à envoyer le
SM. Le scénario E3 démarre au point 12 du scénario
nominal.
|
Le système met à jour la table des SM sortant
avec un statut permettant d'identifier la source d'erreur. Le SM sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
12
Figure 17 : Diagramme de
séquence du cas d'utilisation « alerte virement
salaire »
Figure 18 : Diagramme
d'activité du cas d'utilisation alerte virement salaire
CHAPITRE III : CONCEPTION
III.3.1 Conception de la
base de données
Grâce à l'outil de génie logiciel
win'design, nous avons dessiné le diagramme de classe figure 19 puis,
générer le MCD annexe 1 et le MLD annexe 2
Figure 19 : Diagramme de
classe du système
III.3.2 Architecture
détaillée de SMS BANKING
L'application SMS BANKING système est composée
de quatre sous-systèmes :
- sous système CUSTOMER SMS ;
- sous système GATEWAY SMS
- sous système CORE SMSBANK.
- sous système BANK SI;
III.3.2.1 Sous
système CUSTOMER SMS
Le sous système CUSTOMER SMS est composé
de :
- Un client muni d'un téléphone portable
et d'une carte SIM opérationnelle (constitue ce que nous avons
appelle client mobile)
- Le réseau GSM chargé de
transporter tous les SMS du client vers le système et du système
vers le client.
Figure 20 :
Schéma du sous système CUSTOMER SMS
III.3.2.2 Le core
SMSBANK
C'est SMS BANKING proprement dit. Il est composé de
plusieurs modules à savoir :
- Une base de données
- Un automate d'alertes, chargé de déclencher
l'envoi de SM d'alerte lorsqu'une condition d'envoi de SM est remplie (pour
envoyer, il enregistre juste les paramètres du SM dans une table de la
base de données. Le sous système GATEWAY SMS se chargera du
reste).
- Un Automate de transaction, chargé de traiter les SM
reçus, faire les requêtes SQL relatives aux demandes et
préparer le SM de réponse qui sera envoyé au client par le
sous système GATEWAY SMS.
Ces automates sont des applications écrites et
transformées en services Windows ou en démons linux.
- Une application d'administration permettant de gérer
les clients, les différents services de SMS BANKING et de produire les
rapports et statistiques. C'est la partie IHM de SMS BANKING. C'est depuis
cette interface que seront gérés les clients.
III.3.2.3 Sous
système GATEWAY SMS
Le sous système GATEWAY SMS est composé
de :
- Une passerelle GSM/IP
(PC+passerelle installé et configuré)
Chargée de l'envoi et de la réception des SM en
provenance et à destination du système.
- Un ou plusieurs modems GSM munis de cartes
SIM opérationnelles.
La puce et le modem GSM servent d'interface matérielle
entre le réseau de la banque et le réseau GSM d'un
opérateur local.
- Un serveur web.
Les SM reçus par KANNEL en provenance du réseau
GSM étant retransmis au réseau IP par le protocole HTTP, la
présence du serveur web est nécessaire pour exécuter les
requêtes HTTP.
- Une application écrite en un langage serveur
(PHP, JSP, ASP,....)
La présence de cette application est nécessaire
pour recevoir les SM, vérifier leur format et les enregistrer dans une
table de la base de données de donnée prévue à cet
effet. C'est cette application qui est exécutée au niveau du
serveur web.
- Une application HTTP/SQL
Tour les SM en provenance du sous-système CORE SMSBANK
devant être envoyés aux clients de la banque ou de la
coopérative bancaire sont enregistrés dans une table de la base
de données. D'où la nécessité de cette application
qui récupère ces SM en partance et les envois à KANNEL par
le biais du protocole HTTP. Notons que cette application ne nécessite
pas d'interface utilisateur. Elle sera écrite en java et
transformée en service Windows afin d'être lancée
automatiquement et tournée en arrière plan.
Figure 21 :
Schéma du sous système GATEWAY SMS
Une passerelle GSM/IP + Un ou plusieurs modems
GSM munis de cartes SIM opérationnelles + Un serveur
web + Une application écrite en un langage serveur (PHP, JSP, ASP,....)
forment ce que nous avons appelées GATEWAY SMS
1
Une passerelle GSM/IP + Un ou plusieurs modems
GSM munis de cartes SIM opérationnelles + Une
application HTTP/SQL forment ce que nous avons appelé
GATEWAY SMS 2
III.3.2.4 Sous
système SI BANK.
C'est le système d'information de la banque ou
coopérative bancaire. Il est composé de :
- La base de données de la
banque ou coopérative bancaire;
- L'interface de connexion pour la
synchronisation des données entre la base de données de la banque
ou coopérative bancaire et celle de SMS BANKING. Cette interface peut
être des déclencheurs ou une application, ou encore une
combinaison des deux, dépendant des deux bases de données.
Figure 22 :
Schéma du sous système SI BANK
CHAPITRE IV :
IMPLEMENTATION
III.4.1 La
passerelle GMS/IP
Il existe une multitude de passerelle GSM/IP offrant toutes
les mêmes services. On peut citer entre autre : OZEKI, NOWSMS,
KANNEL. Notre choix s'est portée vers cette dernière parce
qu'elle est open source et gratuite.
III.4.1.1 rôle de KANNEL
KANNEL est un logiciel libre servant de passerelle GSM/IP
fonctionnant sur la majorité des systèmes d'exploitation UNIX
parmi lesquels Linux.
Son implémentation comme passerelle SM consiste
à l'installer et le configurer de manière à recevoir des
requêtes d'envoi de SM par le protocole HTTP et les soumettre à
aux modems GSM auquel il est raccordé par le port série ou USB.
Aussi, de recevoir les SM à partir des modems sur lesquels il est
rattaché et interpréter ces SM en requête HTTP vers une URL
définie.
III.4.1.2 Installation de KANNEL
Ø Pré-requis pour l'installation de
KANNEL-1.4.1
un compilateur C (de préférence GNU gcc)
les librairies XML (libxml ou gnome-xml)
GNU bison
GNU autoconf
GNU make.
Ø Etapes de l'installation
· Nous avons téléchargé la source
sur le site de KANNEL
www.kannel.org et l'avons mis dans
le répertoire (/usr/local/src/KANNEL/gateway-1.4.1.tar.gz)
· Puis décompresser l'archive et exécuter
le script configure
#cd /usr/local/src/KANNEL
#tar xvzf gateway-1.4.1.tar.gz
#cd gateway-1.4.1
#./configure
§ Compiler avec la commande make
#make
# make bindir=/usr/KANNEL install
L'installation s'étant bien passée, les
fichiers suivant sont présent dans le répertoire
/usr/local/src/KANNEL :
· gw/bearerbox
· gw/smsbox
· gw/wapbox
Note : il y a des options possibles de
configuration ; pour avoir de l'aide sur ces options, faire :
#./configure --help
III.4.1.3 configuration et administration de
KANNEL
La configuration de KANNEL se fait dans un seul fichier aux
choix de l'utilisateur. Le fichier doit être structuré en groupes
suivant les fonctions à assigner à KANNEL.
Syntaxe :
§ chaque groupe comporte des variables, chaque variable
est définie sur une ligne ;
§ les groupes sont séparés par des lignes
vides.
Pour configurer KANNEL comme passerelle SMS/HTTP, les groupes
suivants ont été créés :
`core' qui est le noyau de KANNEL il contient
les variables nécessaires pour l'administration.
`smsc' qui contient les variables de
connexion aux SMSC ou aux modems.
`smsbox' qui gère les files d'envoi et
de réception de SM
`sendsms-user' qui contient les variables
d'un client HTTP
`sms-service' pour la réception des SM
venant de la SMSC ou du modem, servant à paramétrer un
service.
On peut avoir plusieurs groupes pour chaque type (sauf pour
`core').
Le fichier de configuration se trouve à l'annexe 3
III.4.2 Installation du modem
GSM
Le modem GSM utilisé un modem de marque FALCOM SWING
(car compatibles aux systèmes d'exploitation linux) (annexe 4). Il se
connecte sur les ports séries. Dans notre cas, nous l'avons
connecté sur le port série 1(ttyS0 sous linux) puis,
créé un lien symbolique vers le fichier
nommé modem utilisable lors de la configuration du fichier de
kannel. La commande a été la suivante :
# ln -s /dev/ttyS0 /dev/modem
III.4.3 Implémentation
des modules du système
III.4.3.1 Outils
utilisés
· APACHE TOMCAT 6.14
APACHE TOMCAT est un serveur web
fonctionnant sur la plupart des systèmes d'exploitation.
· MICROSOFT SQL
SERVER 2000
MICROSOFT SQL SERVER 2000 est un SGBD développé
et commercialisé par Microsoft, mais à l'origine par Sybase.
· JAVASERVICE
JAVASERVICE est une application permettant de transformer les
programmes java en service NT.
· NETBEANS 6.1
NETBEANS est un IDE pour le développement
d'applications java.
· VISUAL STUDIO 2008
VISUAL STUDIO 2008 est un IDE commercialisé par
Microsoft pour le développement des applications dot net (vb.net,
c#.net, ASP.net.....).
III.4.3.2
Réalisation
Lors de la réalisation, nous avons aussi interfacer
SMS-BANKING avec le logiciel bancaire GLOBAL BANK.
· Les interfaces de l'application on été
faites en vb.net, avec pour métier des dll écrites en C#
· Le client HTTP a été écrit en JSP.
Cette application sera chargée de recevoir les SM émis par les
clients, faire les vérifications et les insérer dans la base de
données. Il fait parti du sous système GATEWAY SMS 1.
· L'application HTTP/SQL du sous système GATEWAY
SMS 1 a été écrite en java et transformée en
service Windows grâce à javaservice. Deux de ses classes
principales se trouvent à l'annexe 5.
· Tous les automates du sous système core SMSBANK
ont été écrits en java et transformés en service
Windows grâce à javaservice.
· L'interface de synchronisation entre la base de
données de GLOBAL BANK et SMS-BANKING a été
implémentée grâce à des trigger de MICROSOFT SQL
SERVER 2000
III.4.3.3
Résultats
Tous les modules de notre système a été
implémentés. Nous présenterons quelques uns de ses
résultats sous forme de capture d'écran.
Figure 23 : Lancement du
BEARERBOX de kannel
Figure 24 : Utilisation
de Javaservice pour la création du service GATEWAYSMS1
Figure 25 : Le service
GATEWAYSMS1 lancé
Figure 26 : Le service
CORESMSBANK Lancé
Figure 27 : Interface
générale de SMS-BANKING
Figure 28 : Interface de visualisation du nombre
total des SM emis par le système aux clients durant une
periode
Figure 29 : Interface de
visualisation des SM émis par les clients
Figure 30 : Interface
d'incription des clients aux services d'information à la
demande
Figure 31 : Interface de
visualisation des SM emis en direction des clients
Figure 32 : Interface
d'inscription des clients aux services de notification
évènementielle
CONCLUSION
Arrivé au terme de ce travail
et sans prétendre avoir cerné
tous les contours possibles des technologies de
M-BANKING en général et du SMS-BANKING en particulier, nous
pouvons tout de même affirmer avoir atteint
les objectifs que nous nous étions fixés. Il était
question pour nous d'informer le grand public sur le M-BANKING et d'en mettre
sur pied une solution bénéfique aux institutions
financières. Nous avons dans les prémices de notre
travail, fait ressortir les différentes technologies dans le domaine du
M-BANKING ; effectué un tour d'horizon des structures
fonctionnelles et architecturales tout en expliquant les différents
concepts. Une étude comparative a permis de ressortir que malgré
sa faiblesse qu'est la sécurité, le SMS-BANKING est la solution
réaliste et avantageuse. Le STK-BANKING étant
généralement fait par les opérateurs de
téléphonie, le WAP-BANKING quant à lui voit ses limites
grâce au protocole WAP qui n'est pas compatible à tous les
téléphones mobiles. Une étude du marché nous a
permis de conclure que le M-BANKING est presque inexistant au Cameroun. Dans la
troisième partie, nous avons proposé une solution de SMS-BANKING.
Nous avons commencé par faire des choix technologiques, ensuite recenser
les différentes fonctionnalités du système puis, diviser
le système en sous systèmes afin de ressortir les
fonctionnalités de chaque bloc. Enfin, nous avons
implémenté la solution et l'interfacer avec un logiciel bancaire
existant.
Travaillant dans le domaine des nouvelles technologies, une
de nos grandes difficultés a été la rareté de
l'information car les applications SMS-BANKING sont des applications
propriétaires ; il fallu faire appel à nos aptitudes
scientifiques et techniques afin de résoudre certains problèmes.
Néanmoins, Nous avons essuyé quelques moments de doute, notamment
lors de l'implémentation des automates mais les réussites aidant,
ces moments de flottements ont vite été oubliés.
Nous tenons à souligner à quel point ce travail
a été motivant et passionnant. Son principal atout a
été sa richesse et son abstraction. Son implémentation
dans un établissement financier et la convoitise de certains ont
prouvé que nos efforts n'ont pas été vains.
Le travail scientifique n'étant jamais parfait,
l'application SMS-BANKING que nous avons déployée ne failli pas
à la règle. Comme la plupart des applications utilisant le SMS
d'un opérateur de téléphonie mobile, les informations ne
sont pas cryptées lors de leur acheminement. Il serait primordial de
songer à une technique de sécurité dans le futur.
BIBLIOGRAPHIE ET WEBOGRAPHIE
§ AKOA MBALLA Maurice, Mise en place d'un outil
de supervision et
d'analyse des incidents et messages spontanés
des équipements NSS dans
un réseau GSM, 5GTEL 2005 ENSP
§ NDEFFO TAKA William, Interférences radio
GSM : résolution du
problème d'interférence par la mise en
oeuvre d'un outil de gestion de 70 pages
fréquence, 5GTEL 2005 ENSP
Implémentation d'un portail SMS à base
du logiciel KANNEL
www.memoireonline.com/.../m_Implementation-dun-portail-SMS--base-du-logiciel-KANNEL3.htm
par Tchapo TANTE-GNANDI
§ Didier DONSEZ,
rangiroa.essi.fr/cours/internet/04-01-slides-wap-wml.pdf ,WAP Wireless
Application Protocol WML Wireless Markup Language.
§ Andreas Fink -Bruno Rodrigues, Kannel 1.3.2 User's
Guide Open Source WAP and SMS gateway
§ Tarun Dua, Kannel as an SMS Gateway
§ Dr. Nizar Zarka CONTROL & DATA TRANSFER VIA
SMS. medforist.ensias.ma/Contenus/.../papers/June25/20.pdf
§
http://www.math.sunysb.edu/~comech/tools/PCImodems.html
§ User Manual Falcom SWING GSM-Modem
www.topitech.com/file/Swing/Falcom_SWING_eng.pdf
http://www.mtn.cm/LoadedPortal
[Pascal roques1] Pascal Roques, UML 2 par la pratique, ISBN
:978-2-212-12322-7, 6ème édition, Eyrolles, Paris, 2002.
[Pascal roques2] Pascal Roques, Les Cahiers du Programmeur UML,
Eyrolles, Paris, 2002.
[Banque], <Banque>,http://fr.wikipedia.org/wiki/Banque, 11
mai 2009
SMS gateway http://en.wikipedia.org/wiki/SMS_gateway
SIM Application
Toolkithttp://en.wikipedia.org/wiki/SIM_Application_Toolkit
What is SIM Toolkit? http://www.cellular.co.za/sim_toolkit.htmWAP
- Le protocole http://www.commentcamarche.net/contents/wap/wapintro.php3
September 2005
sachin-shetty
SMS Banking
by Sachin
Shetty,http://palisade.plynt.com/issues/2005Sep/sms-banking/
Walter Carels
ICT Manager Electronic Banking Mobile banking (SMS and
WAP)
via My KBC
Le réseau GSM a fêté ses 20 ans !
Posté le 10 septembre 2007 à 17:48:56 CEST par
Pascal Thevenier
http://www.tt-hardware.com/modules.php?name=News&file=article&sid=10807
About Mobile Banking via WAP
http://kannel.org/download/1.3.2/userguide-1.3.2/userguide.html
Un marché en pleine expansion...
Marketing Direct N°69 - 01/11/2002 - Peggy Cardin
Description du WAP
http://www.lirmm.fr/~ajm/Cours/01-02/DESS_TNI/TER9/WAP/description/description.htm
http://info.bpiexpressonline.com/bpiprod/prodserv.nsf/Mobile+Banking/MobileBankingWAP?OpenDocument
Cédrick Fairon, Jean René Klein et Sébastien
Paumier, Le langage SMS. Étude d'un corpus informatisé à
partir de l'enquête 'Faites don de vos SMS à la science' , Presses
universitaires de Louvain, Louvain-la-Neuve. Cahiers du Cental, 3.1, 2006.
Le standard GSM
http://www.commentcamarche.net/contents/telephonie-mobile/gsm.php3
Short message service
http://fr.wikipedia.org/wiki/Short_message_service
SIM Toolkit http://bladox.com/devel-docs/gen_stk.html
http://jaaayyy.chez.com/html/Radiomobiles/stage/Carte
SIM et SIM Application Toolkit (SAT).htm
ANNEXES
Annexe 1 : Modèle conceptuel de données
de SMS-BANKING
Annexe 2 : Modèle logique de données de
SMS-BANKING
group = core
admin-port = 13000
admin-password = root
status-password = kokodi
#admin-deny-ip = "*.*.*.*"
admin-allow-ip = "127.0.0.1;192.168.100.*"
smsbox-port = 13003
box-allow-ip = "127.0.0.1;192.168.1.*"
log-file = "/tmp/kannel.log"
log-level = 1
access-log = "/tmp/access.log"
store-file = "/tmp/kannel1.log"
sms-incoming-queue-limit=-1
access-log-format="%t [from=%p] [to=%P] [msg=%b]"
unified-prefix = "+237,00237,0;+,00"
include = "/etc/kannel/modems.conf"
group = smsc
smsc-id = modem
smsc = at
modemtype = auto
device = /dev/modem
log-file = "/tmp/smsc.log"
speed = 9600
validityperiod = 167
group = smsbox
bearerbox-host = 192.168.100.116
sendsms-port = 10000
sendsms-chars = "0123456789"
global-sender = 75296068
log-file = "/tmp/smsbox.log"
access-log = "/tmp/access1.log"
log-level = 0
group = sendsms-user
username = root
password = kokodi
user-allow-ip = "192.168.100.*"
concatenation = true
group = sms-service
keyword = TRF
omit-empty=true
max-messages=0
catch-all = true
get-url =
"http://192.168.100.114:8080/InterSms/index.jsp?sender=%p&text=%a"
accept-x-kannel-headers=true
group = sms-service
keyword = default
omit-empty=true
max-messages=0
catch-all = true
get-url =
"http://192.168.100.114:8080/IncomingSms/index.jsp?sender=%p&text=%a"
accept-x-kannel-headers=true
group = sms-service
keyword = TIB
omit-empty=true
max-messages=0
catch-all = true
get-url =
"http://192.168.100.114:8080/InterBrIncSms/index.jsp?sender=%p&text=%a"
accept-x-kannel-headers=true
Annexe 3 : fichier de configuration de
kannel
Annexe 4 : Modem falcom swing
public int sendsms(String receip, String text, String
username, String passwd) throws Exception
{
Passerelle=getPasserelle();
text = text.replaceAll(" ", "+");
url = new
URL("http://"+Passerelle+":10000/cgi-bin/sendsms?username="+username+"&password="+passwd+"&to="+receip+"&text="+text);
Cnx = this.connect("GET");
if (Cnx==1){
Rsp=this.displayResponse();
this.disconnect();
} System.out.println(Rsp);
return Rsp;
}
public void run () {
try {
int contrainte = 1;
String Phone;
String MsgSend;
String Login = "root";
String Password = "kokodi";
double ID;
while (contrainte == 1) {
try {
IpServer = getIpServer();
LoginServer = getLoginServer();
MdpServer = getMdpServer();
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
Connection conn = DriverManager.getConnection
("jdbc:sqlserver://"+IpServer+";User="+LoginServer+";Password="+MdpServer+";
DatabaseName=smsbanking" );
state1 = conn.createStatement();
String SQL = "select CustPhone, SMSTransText,
outgoingsmsid from outgoingsms where flag = 0 or flag = -1";
ResultSet rs = state1.executeQuery(SQL);
while (rs.next()) {
Phone = rs.getString("CustPhone ");
MsgSend = rs.getString(" SMSTransText
");
ID = rs.getDouble("outgoingsmsid");
Statement state2 =
conn1.createStatement();
if (Phone == null || Phone.isEmpty())
{
state2.executeUpdate("update outgoingsms set
flag=5 where outgoingsmsid='" + ID + "'");
state2.close();
OutgoingSms.sleep(10000);
break;
}
if (Phone != null && MsgSend !=
null) {
Phone = Phone.replaceAll("-", "
");
Phone = Phone.replaceAll("/.", "
");
Phone = Phone.replaceAll("/", "
");
Phone = Phone.trim();
Phone = Phone.replaceAll(" ", "");
if (Phone.length()==7){
if (Phone.substring(0,
1).compareTo("7")==0){
Phone="7".concat(Phone);
}
if (Phone.substring(0,
1).compareTo("9")==0){
Phone="9".concat(Phone);
}
}
if (Phone.length()>=8){
RspExact = this.sendsms(Phone,
MsgSend, Login, Password);
int Rep = RspExact;
if (RspExact == 0) {
state2.executeUpdate("update
outgoingsms set flag=1, phonenumber='"+Phone+"' where outgoingsmsid='" + ID +
"'");
} else {
state2.executeUpdate("update outgoingsms set
flag=" + Rep + ", phonenumber='"+Phone+"' where outgoingsmsid='" + ID +
"'");
}
state2.close();
OutgoingSms.sleep(10000);
}else{
state2.executeUpdate("update outgoingsms set
flag=4 where outgoingsmsid='" + ID + "'");
state2.close();
OutgoingSms.sleep(10000);
}
} else {
state2.executeUpdate("update outgoingsms set
flag=5 where outgoingsmsid='" + ID + "'");
state2.close();
OutgoingSms.sleep(10000);
}
}
rs.close();
state1.close();
conn1.close();
OutgoingSms.sleep(20000);
} catch (Exception e) {
System.err.println(e);
}
}
} catch (FileNotFoundException ex) {
Logger.getLogger(OutgoingSms.class.getName()).log(Level.SEVERE, null, ex);
}
}
public int connect(String method) throws
Exception
{
try
{
server = (HttpURLConnection)url.openConnection();
server.setDoInput(true);
server.setDoOutput(true);
server.setRequestMethod(method);
server.setRequestProperty("Content-type","application/x-www-form-urlencoded");
server.connect();
return 1;
}
catch (Exception e)
{
System.err.println(e.toString());
System.err.println ("erreur de connection à la
passerelle");
return -1;
}
}
Annexe 5 : Trois classes principales de l'application
HTTP/SQL
La classe connect formate la requête
http avec une méthode
La classe sendsms contient la requête
http avec toutes les informations nécessaire afin d'être
exécuté au niveau de la passerelle
La classe run est la classe principale
Annexe 6 : Utilisation de Javaservice pour la
création du service CORESMSBANK
Annexe 7 : Diagramme de séquence des services
de notification évènementielle
Annexe 8 : Architecture simplifiée de la
passerelle kannel
Sommaire d'identification
Titre : Consultation d'historique
Résumé : ce cas
d'utilisation permet au client de consulter les 4 derniers historiques de son
compte à partir de son téléphone portable.
Acteurs : Client mobile
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication permettant l'envoi de SMS, Disposer d'un
téléphone
Post conditions : Un SM avec les 4 derniers
historiques est renvoyé au client
Description des scénarios
- Scénario nominal
|
1. Le client formate un SM et l'envoi au numéro de la
carte SIM présente dans le modem connecté à la passerelle
GSM/IP de la banque ou coopérative bancaire
|
|
2. Réception, vérification du format du SM et
stockage du SM dans la base de données de SMS-BANKING
|
|
3. Vérification du code PIN du client
|
|
4. Vérification du numéro de
téléphone du client
|
|
5. Vérification effective de l'inscription du client au
service de consultation d'historique
|
|
6. La vérification si le nombre maximal de SM a
envoyé au client pour le mois en cours et pour le service de
consultation d'historique de est atteint.
|
|
7. Récupération des 4 derniers historiques
|
|
8. Formatage du message à retourner au client
|
|
9. Insertion dans la table d'historique des SM
|
|
10. Insertion du SMS à envoyer au client dans la table
des SM sortants
|
|
11. Mis à jour du statut du SM entrée: SM
traité
|
|
12. Incrémentation du compteur de SM (ce compteur
permet de compter le nombre de SM déjà envoyé au client
durant ce mois. Il est nécessaire pour la vérification du seuil
maximal) pour le service de consultation d'historique. Le système
extrait le numéro de téléphone du récepteur
|
|
13. Envoi du SM avec 4 derniers historiques au client.
|
|
14. Mis à jour du statut du SM sortant: SM
envoyé
|
- Scénario alternatif
|
E1
|
Le système détecte des erreurs sur le
formatage du SM. Le scénario E1 démarre au point 2. du
scénario nominal.
|
|
Le système enregistre le SM avec une remarque :
« Mauvais SM ». Dans ce cas, le scénario nominal s
arrête au point 2.
|
|
E2
|
Le système détecte que le code PIN du
client est incorrect. Le scénario E2 démarre au point 3. du
scénario nominal.
|
|
Le système met à jour la table des SM
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 3
E3 Le système
détecte que le numéro de téléphone du client
est incorrect. Le scénario E3 démarre au point
4. du scénario nominal.
Le système met à jour la table des SM
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 4
|
|
E4
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E4 démarre au point
5 du scénario nominal.
|
Le système met à jour la table des SM entrant
avec pour remarque : « Client non inscrit au service
spécifié »
Dans ce cas, le scénario nominal s arrête au
point 5
|
E5
|
Le système détecte que le nombre
maximal de SM du mois courant pour le service de consultation d'historique est
atteint. Le scénario E5 démarre au point 6 du scénario
nominal.
|
Le système met à jour la table des SM entrant
avec pour remarque : « Nombre maximal de SM
atteint »
Dans ce cas, le scénario nominal s'arrête au
point 6
|
E6
|
Le système n'arrive pas à envoyer le
SM. Le scénario E6 démarre au point 13 du scénario
nominal.
|
Le système met à jour la table des SM sortant
avec un statut permettant d'identifier la source d'erreur. Le SM sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
13.
Annexe 9 : Scenarii du cas d'utilisation consultation
d'historique
Annexe 10 : Diagramme de séquence du cas
d'utilisation consultation d'historique
Annexe 11 : Diagramme d'activité du cas
d'utilisation consultation d'historique
Annexe 12 : Lancement du SMSBOX de kannel
Sommaire d'identification
Titre : Alerte débit compte
Résumé : Ce cas
d'utilisation permet d'envoyer un SM à un client lorsque son compte est
débité.
Acteurs : Client mobile, BANK SI
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication dans le modem de la banque permettant l'envoi du
SM, le réseau de l'opérateur de téléphonie doit
être opérationnel.
Post conditions : Un SM avec le montant
débité est envoyé au client
Description des scénarios
- Scénario nominal
|
1. BANK SI met à jour ou effectue un nouvel
enregistrement dans la BD SMS-BANKING avec statut non traité
|
|
2. Le système récupération du nouvel
enregistrement
|
|
3. Le système vérifie si il s'agit d'un
débit sur un compte
|
|
4. Le système vérifie si le client inscrit au
service « d'alerte en cas de débit » sur le
compte
|
|
5. Le système vérifie si le nombre maximal de SM
a envoyé au client pour le mois en cours et pour le service d'alerte en
cas de débit du compte est atteint
|
|
6. Le système formate le message à envoyer au
client avec montant debité
|
|
7. Le système recherche le numéro de
téléphone du client
|
|
8. Le système insertion SM dans la table d'historique
des SM
|
|
9. Le système insert le SM à envoyer au client
dans la table des SM sortants avec statut (non envoyé)
|
|
10. Mis à jour du Statut de l'enregistrement
(traité)
|
|
11. Le système incrémente le compteur de SM (ce
compteur permet de compter le nombre de SM déjà envoyé au
client durant ce mois. Il est nécessaire pour la vérification du
seuil maximal) pour le service alerte en cas de débit.
|
|
12. Le système envoie le SM « d'alerte de
débit du compte » au client
|
|
13. Le système met à jour du statut du SM
sortant:SM envoyé
|
- Scénario alternatif
|
E1
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E1 démarre au point
4 du scénario nominal.
|
Le système met à jour cet enregistrement :
« Client non inscrit au service spécifié »
Dans ce cas, le scénario nominal s arrête au
point 4
|
E2
|
Le système détecte que le nombre
maximal de SM du mois courant pour le service d'alerte en cas de crédit
est atteint. Le scénario E2 démarre au point 5 du scénario
nominal.
|
Le système met à jour cet enregistrement :
« Nombre maximal de SM atteint »
Dans ce cas, le scénario nominal s'arrête au
point 5
|
E3
|
Le système n'arrive pas à envoyer le
SM. Le scénario E3 démarre au point 12 du scénario
nominal.
|
Le système met à jour la table des SM sortant
avec un statut permettant d'identifier la source d'erreur. Le SM sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
12
Annexe 13 : Scenarii du cas d'utilisation alerte
débit compte
Annexe 14 : Diagramme de séquence du cas
d'utilisation Alerte débit compte
