Télécharger le fichier original (Mémoire de fin d’études)
Le cadre méthodologique :
Les techniques de M-Banking :
Réseaux mobiles et transmission de données les réseaux mobiles disponibles utilisent la technologie (GSM et depuis UMTS). Ces normes internationales permettent aux équipements mobiles de bien sûr téléphoner, mais aussi d’effectuer des transmissions de données. Les techniques disponibles pour la transmission de données sont:
• l’échange de données par SMS : bien adapté à la transmission de données textuelles de petite taille.
• l’établissement d’une liaison TCP/IP qui selon la technologie (GSM, UMTS) et les options d’abonnement peut être à différentes vitesses:
CSD (circuit switched data), proche d’un protocole modem traditionnel: permet l’échange de données mais interdit les appels téléphoniques durant la connexion en mode data.
GPRS (General Packet Radio Service): permet l’échange de données à
64 kbps (dans la pratique plutôt 40 kbps) tout en restant disponible pour recevoir un appel: néanmoins, l’échange simultané de données et la téléphonie n’est pas possible.
UMTS: échange de données à haute vitesse (de l’ordre de 300 kbps).
Sur la liaison TCP/IP ainsi établie, les données peuvent être échangées selon tous types de protocoles:
Le WAP, version simplifiée et plus légère du Web, dont le navigateur Wap est embarqué dans la plupart des portables commercialisés actuellement.
Le Web, embarqué dans les portables haut de gamme.
Email (SMTP), également disponible sur les portables haut de gamme.
échange de messages multimédia MMS permettant la transmission de messages composites intégrant texte, photo, sons, vidéo, etc.
Toute application spécifique, qui peut être soit embarquée sur le portable (par exemple sous forme d’application Android)
Si le portable le supporte ou sur un autre équipement (PC, Palm, etc.) utilisant le portable pour accéder au réseau.
Ces différentes techniques permettent de réaliser de nombreuses applications mobiles professionnelles dans le domaine bancaire offrir les fonctionnalités suivantes en temps réel: Authentification de l’utilisateur, mise à disposition des informations utiles aux clients concernant la banque, services à la clientèle des outils liés à la banque, synthèse des comptes bancaires de type chèque, carte bancaire, placements liste des opérations d’un compte, virements internes et externes, services professionnels à forte valeur ajoutée, services destinés aux opérateurs télécoms mobiles et intégration au système d’information bancaire : Messagerie, bases de données Les Smartphones puissants actuels vous permettent à étendre vos outils de service client en ligne aux périphériques mobiles. Au fait, plusieurs processus sont rationalisés grâce à la mobilité, car les applications peuvent identifier et localiser automatiquement le client, en lui fournissant toutes autres données pertinentes.
Solution retenue :
L’application envisagée, dans le secteur bancaire est une application mobile client riche serveur sur une plateforme Android.
Cette application permet à un client d’accéder à partir d’un terminal mobile pour bénéficier des services informationnels et services transactionnels sur sa banque en toute sécurité après vérification des paramètres d’accès au niveau serveur distant. Le réseau internet via la suite des protocoles TCP/IP permet la connexion entre le terminal mobile et serveur d’application et la transmission de message se fait par le langage JSON qui constitue un moyen de communication. Le terminal mobile envoi les informations afin s’authentifier et une demande chèque de au serveur qui décode ces données et les analyse pour décision. Android est un système d’exploitation open-source pour smartphone conçu par Google. Le SDK fournit les outils et l’API nécessaires pour commencer à développer sur mobile sur la plateforme Android en C#. Le développement mobile ouvre de larges perspectives. En effet, les mobiles possèdent maintenant des accéléromètres, des connexions sans-fil et des GPS. Ce Framework est nouveau et c’était très enrichissant d’apprendre son fonctionnement. Avec ce projet, nous allons apprendre comment utiliser une architecture 3-tier et les web services. Cette architecture divise l’application en trois parties. Le client (téléphone) se connecte à un serveur (Middleware) via des web services et ce serveur interroge la base de données.
analyse et spécification des besoins :
Introduction :
Une étape essentielle de tout cycle de développement logiciel ou conceptuel consiste à Effectuer une étude préalable. Le but de cette phase est de comprendre le contexte du système. Il s’agit d’éclaircir au mieux les besoins fonctionnels et non fonctionnels, apparaitre les acteurs et identifier les cas d’utilisation. Dans ce chapitre, nous allons essayer d’exprimer les besoins sous forme de diagrammes de cas d’utilisation.
spécification des besoins :
La spécification de besoins constitue la phase de départ de toute application à développer dans laquelle nous allons identifier les besoins de notre application. Nous distinguons des besoins Fonctionnels qui présentent les fonctionnalités attendues de notre application et les besoins non fonctionnels pour éviter le développement d’une application non satisfaisante ainsi de Trouver un accord commun entre les spécialistes et les utilisateurs pour réussir le projet.
spécification des besoins fonctionnels:
Après une étude détaillée de système, cette partie est réservée à la description des exigences fonctionnelles des différents acteurs de l’application. Ces besoins se regroupent dans les diagrammes des cas d’utilisation. Les besoins utilisateur :
– L’authentification de client.
– Cours devise.
– Change devise.
– Consultation annuaire réseau des agences
– Commande chéquier.
– Consultation solde.
– Retrait à distance.
– Virement
– Contact banque par mail ou par téléphone.
spécification des besoins non fonctionnels :
Les besoins non fonctionnels décrivent toutes les contraintes techniques, ergonomiques et esthétiques auxquelles est soumis le système pour sa réalisation et pour son bon fonctionnement. Et ce qui concerne notre application, nous avons dégagé le besoins suivants :
– La disponibilité : l’application doit être disponible pour être utilisé par n’importe quel utilisateur.
– La sécurité de l’accès aux informations critiques : nous devons prendre en considération la confidentialité des données de clients surtout au niveau de l’authentification. Pour cela nous devons restreindre l’accès à ces informations à l’administrateur.
– La fiabilité : les données fournies par l’application doivent être fiables.
– La convivialité de l’interface graphique : l’application doit fournir une interface conviviale et simple pour tout type d’utilisateur car elle présente le premier contact de l’utilisateur avec l’application et par le biais de celle-ci on découvrira ses fonctionnalités.
– Une solution ouverte et évoluée : l’application peut être améliorée par l’ajout d’autres Modules pour garantir la souplesse, l’évolutivité et l’ouverture de la solution.
– La possibilité de retourner au menu principal de l’application à partir de n’importe quelle fenêtre de celle-ci.
méthodologie et approche adoptée :
Avant de programmer l’application et se lancer dans l’écriture du code : il faut tout d’abord organiser les idées, les documenter, puis organiser la réalisation en définissant les modules et Les étapes de la réalisation. Cette démarche antérieure à l’écriture que l’on appelle modélisation ; son produit et un module.
La modélisation consiste à créer une représentation virtuelle d’une réalité de telle façon à faire ressortir les points auxquels on s’intéresse. Dans le cadre de notre projet on a utilisé la Méthodologie UML pour la modélisation des différents diagrammes.
présentation d’Uml :
En regardant les objectifs fixés pour la réalisation du projet, nous remarquons que nous sommes face à une application modulaire et qui devra rester ouverte pour les améliorations futures. De ce fait, il est très important d’utiliser un langage universel pour la modélisation afin de clarifier la conception et de faciliter les échanges. Notre choix est porté sur le langage UML puisqu’il convient pour toutes les méthodes objet et se prête bien à la représentation de l’architecture du système UML : UML (Unified Modeling Language) est un langage de modélisation unifié permet de modéliser une application logicielle d’une façon standard dans le cadre de conception orienté objet. UML permet de couvrir le cycle de vie d’un logiciel depuis la spécification des besoins jusqu’au codage en offrant plusieurs moyens de description et de modélisation des acteurs et de l’utilisation système, du comportement des objets, du flot de contrôle internes aux opérations, des composants d’implémentation et leurs relations, de la structure matérielle et de la distribution des objets et des composants indépendamment des techniques d’implémentation et peut être mis à jour selon les besoins.
les avantages d’Uml :
– Universel.
– Adopté par les grandes entreprises.
– Notation unifié
– Facile à comprendre.
– Adopté par plusieurs processus de développement
– Limite les risques d’erreur.
– N’est pas limité au domaine informatique.
les diagrammes de cas d’utilisation :
Le diagramme de cas d’utilisation a pour but de donner une vision globale sur les interfaces de future application. C’est le premier diagramme UML constitué d’un ensemble d’acteurs qui agit sur des cas d’utilisation et qui décrit sous la forme d’actions et des réactions, le comportement d’un système du point de vue utilisateur. Acteur : un acteur est un utilisateur qui communique et interagit avec les cas d’utilisation du système. C’est une entité ayant un comportement comme une personne, système ou une entreprise. Système : cet élément fixe les limites du système en relation avec les acteurs qui l’utilisent (en dehors de système) et les fonctions qu’il doit fournir (à l’intérieur du système).Cas d’utilisation : un cas d’utilisation représente un ensemble de séquences d’actions à réaliser par le système et produisant un résultat observable intéressant pour un acteur particulier représenté par des ellipses et limité par un rectangle pour représenter le système.
conception :
La conception consistera à faire une représentation des diagrammes de séquences et d’activités en se basant sur le langage de modélisation UML.
On distingue deux types de conceptions :
la conception générale :
le cycle de développement en v :
De nos jours, la méthodologie adoptée dans l’analyse et la conception des systèmes représente un choix stratégique pour le bureau d’études afin de mener à terme les projets tout en respectant les délais annoncés au client et avec la qualité demandée. Vu l’évolution des besoins des utilisateurs finaux, les applications d’entreprise deviennent de plus en plus complexes et difficiles à concevoir et à développer. Pour la conception, le développement et la réalisation de notre application, nous avons opté pour l’application du processus de développement V qui actuellement le cycle de vie le plus connu et certainement le plus convenable aux projets complexes. Ce processus nous accompagnera du début de projet jusqu’à l’implémentation. Son principe est qu’avec toute décomposition doit être décrite la recomposition, et que toute description d’un composant doit être accompagnée de test qui permettront de s’assurer qu’il correspond à sa description. Ceci rend explicite la préparation des dernières phases (validation-vérification).par les premières (construction de l’application) et on sait progressivement si s’approche de ce que le client désire.
Le schéma ci-dessous représente les différentes phases du modèle en V :
la conception détaillée :
La conception détaillée met en œuvre itérativement un microprocessus de construction et c’est en cette phase que l’on génère le plus de volume d’informations. En tant que concepteurs, nous allons élaborer le modèle de conception qui va donner une image « prête à coder » de notre solution. Cette étape se fera par étape afin d’aboutir à un système fonctionnel reflétant une réalité physique. Le diagramme de déploiement : Le diagramme de déploiement définit l’architecture matérielle de l’application. Il présente les périphériques utilisés et la répartition du système sur ces différents éléments. Il montre aussi les liens de communication entre ces diverses entités. Le diagramme de déploiement de notre application est représenté par le diagramme ci-après :
le diagramme de déploiement :
Le diagramme de déploiement définit l’architecture matérielle de l’application. Il présente les Périphériques utilisés et la répartition du système sur ces différents éléments. Il montre aussi Les liens de communication entre ces diverses entités.
Le diagramme de déploiement de notre application est représenté par le diagramme ci-après :
les diagrammes de séquences :
Les diagrammes de séquence peuvent servir à illustrer les cas d’utilisations. Ils permettent de représenter la succession chronologique des opérations réalisées par un acteur et qui font passer d’un objet à un autre pour représenter un scénario. Dans cette partie, nous allons décrire les scénarios les plus importants ainsi que leurs représentations par les diagrammes de séquence
Table des matières
Introduction générale
I. Le cadre théorique et méthodologique
Chapitre I : Le cadre théorique
I.1 : Présentation du projet
I.2 : Cadre de projet
I.3 : Le M-Banking
Chapitre II : Le cadre méthodologique
II.1 : Les techniques de M-Banking
II.2 : Solution retenue
II. Le cadre analytique et quelques recommandations
Chapitre III : analyse et spécification des besoins
Introduction
III.1 : spécification des besoins
III.1.1 : spécification des besoins fonctionnels
III.1.2 : spécification des besoins non fonctionnels
Chapitre IV : méthodologie et approche adoptée
IV.1 : présentation d’Uml
IV.2 : les avantages d’Uml
IV.3 : les diagrammes de cas d’utilisation
IV.4 : identification des acteurs
IV.5 : diagramme de cas d’utilisation globale
III. La présentation, l’analyse et l’interprétation des résultats
Chapitre V : conception
V.1 : la conception générale
V.1.1 : le cycle de développement en v
V.2 : la conception détaillée
V.2.1 : le diagramme de déploiement
V.2.2 : les diagrammes de séquences
V.2.2.1 : le diagramme de séquence << s’authentifier >>
V.2.2.1 : le diagramme de séquence << consulter cours devise >>
V.2.2.1 : le diagramme de séquence << convertir billet de banque >>
V.2.2.1 : le diagramme de séquence << commander chéquiers >>
V.2.2.1 : le diagramme de séquence << consulter annuaire réseau agences >>
V.2.2.1 : le diagramme de séquence << contacter banque >>
V.2.3 : les diagrammes d’activité
V.2.2.1 : le diagramme d’activité << s’authentifier >>
V.2.2.1 : le diagramme d’activité << consulter cours devise >>
V.2.2.1 : le diagramme d’activité << convertir billet de banque >>
V.2.2.1 : le diagramme d’activité << consulter annuaire réseau agences >>
V.2.2.1 : le diagramme d’activité << contacter banque >>
IV : modélisation
Chapitre VI : Réalisation
Introduction
VI.1 Choix technique
VI.1.1 Choix du langage de programmation
VI.1.2 Choix de l’architecture de l’application
VI.2 ENVIRONNEMENT LOGISTIQUE
IV.2.1 Environnement de développement
VI.3 Travail Réalisé
VI.3.1 Les jeux de Test
VII. Sécurité
VII.1 Sécurité organisationnelle
VII.1.2 Sécurité physique
VII.1.2 Plan de secours
VII.1.2 Sécurité Logique
CONCLUSION GENERALE ET PERSPECTIVES
