rapport de stage

20 421 vues

Publié le

0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
20 421
Sur SlideShare
0
Issues des intégrations
0
Intégrations
9
Actions
Partages
0
Téléchargements
1 941
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

rapport de stage

  1. 1. Développement d’une application mobile multiplateformes pour la gestion des opérations bancaires Réalisé par : M. ELKECHA Brahim Et : M. OUARRICH Said Membres de Jury : M. IBNELHAJ Elhassane (INPT) M. BENSAID Hicham (INPT) Mme. MARGHOUBI Rabia (INPT) Juin 2013 i Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013
  2. 2. ii Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013
  3. 3. « S’il n’y avait pas d’hiver, le printemps ne serait pas si agréable : Si nous ne goûtions pas à l’adversité, la réussite ne serait pas tant appréciée » Anne Bradstreet iii Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013
  4. 4. Dédicace A la mémoire de mes grands parents Puisse Dieu les accueillir dans son infinie Miséricorde A celui qui a toujours garni mes chemins avec force et lumière…mon très cher père A la plus belle perle du monde…ma tendre mère A mes sœurs Je leur souhaitant tout le succès…tout le bonheur A A A toute ma famille pour l’amour et le respect qu’ils m’ont toujours accordé mon binôme pour le frère agréable qu’il était et qu’il restera pour moi tous mes amis Pour une sincérité si merveilleuse…jamais oubliable, en leur souhaitant tout le succès…tout le bonheur A toute personne Qui m'a aidé à franchir un horizon dans ma vie… Aimablement… ELKECHA Brahim Je dédie ce modeste travail… iv Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013
  5. 5. À ma mère et mon père en témoignage de leur affection, leurs sacrifices et de leurs précieux conseils qui m’ont conduit à la réussite dans tous ce que je fais ; À mes sœurs et mes frères en leur souhaitant la réussite dans leur vie, À mon cher binôme Pour tout ce qu’il a fait pour la réussite de ce stage À tous mes proches À tous ceux qui m’ont aidé afin de réaliser ce travail, Et à tous ceux que j’aime et qui m’aiment. Aimablement… OUARRICH Said Je dédie ce modeste travail… v Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013
  6. 6. Remerciements Premièrement nous remercions Dieu source de toute connaissance. Au terme de ce travail, nous adressons nos remerciements les plus sincères à notre encadrants M. Elhassane IBN ELHAJ & M. Hicham BENSAID, deux enseignants chercheurs à L’institut national des postes et télécommunications, pour nous avoir permis de bénéficier de leur grand savoir dans différents sujets tout au long de notre formation à l’INPT, pour leur pédagogie, leurs compétences, leur modestie et leur aide précieuse tout au long de ce projet même pendant les moments les plus difficiles. Vraiment merci pour une qualité d’encadrement si sérieuse et si consistante … Un immense merci à M. Rachid et M. Mohamed Amine Larouji méritants tout le respect pour leurs encouragements, et de nous avoir accueillis dans la société INFOSAT et également pour leur aide qu’ils nous ont offerte tout au long du stage. Nos remerciements les plus cordiaux s’adressent à notre encadreur Sakher TALIBI, ingénieur développeur à INFOSAT, pour sa disponibilité, son aide, ses conseils précieux, ses critiques constructives, ses explications et suggestions pertinentes ainsi que pour ses qualités humaines et morales que nous avons toujours appréciées. Nous ne manquerons pas l’occasion de remercier chaleureusement Mr Amine KOTNI pour son incontestable contribution à l’accomplissement de notre projet, son caractère accueillant qui nous a offert une ambiance très motivante et encourageante au travail, ainsi que pour sa disponibilité extraordinaire qui nous a permis de surmonter les difficultés et autres problèmes rencontrés. Que dieu préserve votre optimisme et votre enthousiasme. vi Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013
  7. 7. Nous remercions toutes les personnes qui nous ont soutenus, d'une façon ou d'une autre, nous éprouvons incessamment leur estime et amabilité, nous saluons réellement cette très haute bienveillance que vous portez à notre égard et qui restera pour toujours une vraie image de marque en nous. Nous terminerons ces remerciements en saluant vivement les membres du jury pour l’honneur qu’ils nous ont fait en acceptant de juger notre travail. Brahim & Said. vii Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013
  8. 8. Résumé: Le présent document est le fruit de notre travail dans le cadre du stage de fin d'étude, pour l’obtention du diplôme d’ingénieur d’état en télécommunications et technologies de l’information, qui a été réalisé au sein de l'entreprise INFOSAT communications. Notre travail Consiste à étudier les différents Framework de développement mobile hybride « multi plateformes » existants et choisir le meilleur, et à réaliser un projet mobile E-banking permettant la gestion des opérations bancaires. Afin de suivre l'évolution des technologies de l'information et l’émergence du monde mobile, notre application est conçue pour les différentes plateformes mobiles à savoir: Androïde, IOS, BlackBerry, Windows phone, Web OS, Symbian ... Nous avons commencé par l’élaboration d’une étude fonctionnelle qu’on a fini par l’élaboration d’une conception du projet, puis nous avons dressé une étude comparative des deux meilleures solutions de développement mobile multiplateformes: Titanium et PhoneGap. Cette étude nous a permis de déduire que phone Gap répond mieux à notre besoin. Ensuite nous avons procédé à la réalisation de l’application. Les principales fonctionnalités de l’ « e-Banking» sont l’authentification des membres, la consultation des comptes et des mouvements, le virement bancaire, la demande de chéquier, la demande de recharge, la géolocalisation, la consultation des effets, des crédits et des listes impayées. Grâce à ces fonctionnalités l’abonné reste en contact avec son compte bancaire à n’importe quel endroit où il se trouve et à n’importe quel instant. viii Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013
  9. 9. Abstract: This document is the result of our work in the end study’s internship, in order to obtain engineering degree in telecommunications and information technology, which has been done within the company INFOSAT communications. Our mission is to study the different existing mobile development framework hybrid "multi-platform" Existing and choose the most appropriate one to realize our mobile project e-banking. To follow the evolution of information technology and the emergence of the mobile world, our application is designed for different mobile platforms namely android, iOS, BlackBerry, Windows Phone, Web OS, Symbian... We started with a comparative analysis between the two largely usedcross-platform mobile development frameworks: Titanium and Phone Gap. Then we decide to use Phone Gap because it is the most appropriate. The main features of the "e-banking" are: authentication of members, consulting bank accounts and movements, bank transfer, check book request, demand of charge, geolocation, effect’s consultation, credits and unpaid list. With these features the subscriber remains in contact with his bank account at any place where and at any time. ix Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said 2012/2013
  10. 10. ‫ملخص:‬ ‫هذا الكتاب عبارة عن ثمرة لمجهوداتنا التي بذلناها إلنجاز مشروع نهاية تكويننا‬ ‫كطلبة مهندسين ،و ذلك بغية الحصول على رتبة مهندس دولة في تخصص تقنيات‬ ‫المواصالت السلكية والالسلكية وتقنيات المعلومات، المهمة المطلوبة منا من طرف‬ ‫شركة :”‪ “INFOSAT Communications‬كانت دراسة وتحليل وإنشاء برنامج‬ ‫"البنك المحمول" وهو عبارة عن برنامج يخول لمستعمله االتصال بحسابه البنكي،‬ ‫ومراقبة حسابه، وتحويل األموال، وغير ذلك من الخدمات التي يوفرها البنك العادي.‬ ‫بدأنا بدراسة وتحليل المشروع، كما قمنا بمقارنة دقيقة بين تكنولوجيات البرمجة‬ ‫المعلوماتية التي تستهدف جميع أنظمة االشتغال التي تستخدمها الهواتف المحمولة،‬ ‫لنختار بعد ذلك ”‪ ”Phone Gap‬إلنجاز مشروعنا.‬ ‫التطبيق الذي قمنا بتطويره، يمكن تثبيته على مختلف انواع الهواتف الذكية،‬ ‫وبالخصوص التي تستعمل انظمة االشتغال مثل، ‪ Android‬و ‪ IOS‬و‬ ‫‪BlackBerry‬و ‪ Web OS‬و ‪ Symbian‬الخ.‬ ‫‪x‬‬ ‫3102/2102 ‪Projet De Fin d’étude – ELKECHA Brahim & OUARRICH Said‬‬
  11. 11. Table des matières Liste Des Figures............................................................................................................................................ 1 Liste Des Tableaux ........................................................................................................................................ 3 Acronymes Et Abréviations ......................................................................................................................... 4 Introduction : ................................................................................................................................................... 5 1. Contexte Général du Projet :.................................................................................................................. 6 1.1. Présentation de l’organisme d’accueil : ................................................................................................. 7 1.1.1. Présentation d’INFOSAT Communications : .......................................................................... 7 1.1.2. Domaines d’intervention d’INFOSAT Communications : ...................................................... 7 1.2. Cadre général du projet :...................................................................................................................... 10 1.2.1. 1.2.2. Objectifs du projet: ................................................................................................................... 10 1.2.3. Fonctionnalités à mettre en place:............................................................................................ 11 1.2.4. 2. Problématique et analyse du besoin :....................................................................................... 10 Planification du projet: ............................................................................................................. 12 Etude Fonctionnelle et Technique: ...................................................................................................... 14 2.1. Etude fonctionnelle:............................................................................................................................... 15 2.1.1. Capture des besoins fonctionnels : ........................................................................................... 15 2.1.2. Analyse fonctionnelle : .............................................................................................................. 15 2.1.2.1. Diagramme des Use Cases: ............................................................................................... 15 2.1.2.2. Descriptions des Use cases: ............................................................................................... 16 2.1.2.3. Diagrammes de classes: ..................................................................................................... 19 2.2. Etude technique: .................................................................................................................................... 21 2.2.1. Spécifications techniques : ........................................................................................................ 21 2.2.2. Architecture: .............................................................................................................................. 21 2.2.2.1. Architecture mobile:.......................................................................................................... 21 2.2.2.2. Architecture serveur: ........................................................................................................ 21 2.2.3. 3. Choix de technologie « Services Web » : ................................................................................. 22 Choix de Framework de développement mobile: ............................................................................... 25 3.1. Développement Hybride Vs Natif: ...................................................................................................... 26 3.1.1. introduction: .............................................................................................................................. 26 3.1.2. Quelle est la meilleure approche : ............................................................................................ 26 3.2.1. Phone Gap: ................................................................................................................................. 28
  12. 12. 3.2.2. Titanium: .................................................................................................................................... 29 3.3. Comparaison : Titanium VS Phone Gap: ........................................................................................... 31 3.3.1. Comparaison des plateformes supportées: .............................................................................. 31 3.3.2. Comparaison des richesses des deux plates-formes: ............................................................. 32 3.3.2.1. 4. Synthèse : ............................................................................................................................ 33 Mise en Œuvre du projet ...................................................................................................................... 34 4.1. Choix technologiques : .......................................................................................................................... 35 4.1.1. Coté serveur: .............................................................................................................................. 35 4.1.2. Coté mobile: ............................................................................................................................... 37 4.2. Architecture globale du projet : ........................................................................................................... 37 4.3. Implémentation : ................................................................................................................................... 39 4.3.1. Authentification : ....................................................................................................................... 39 4.3.2. Consultation des comptes : ....................................................................................................... 41 4.3.3. Demande de recharge:............................................................................................................... 42 4.3.4. Simulateur de crédit : ................................................................................................................ 43 4.3.5. Effectuer un virement : ............................................................................................................. 44 4.3.6. Demander un chéquier :............................................................................................................ 47 4.3.7. Transférer de l’argent : ............................................................................................................. 49 4.3.8. Les Tâches : ................................................................................................................................ 50 4.3.9. Liste des comptes titres: ............................................................................................................ 51 4.3.10. Consultation des effets : ............................................................................................................ 52 4.3.11. Situation des crédits : ................................................................................................................ 56 4.3.12. Liste des impayés : ..................................................................................................................... 57 4.3.13. Géolocalisation :......................................................................................................................... 57 4.4. Déploiement: .......................................................................................................................................... 58 4.4.1. Les dangers du reverse engineering:........................................................................................ 58 4.4.2. Déploiement sur mobile: ........................................................................................................... 58 Conclusion :.................................................................................................................................................... 62 Glossaire: ........................................................................................................................................................ 63 Bibliographie : ............................................................................................................................................... 65 Webographie:................................................................................................................................................. 66 Annexe: ........................................................................................................................................................... 67
  13. 13. Liste Des Figures Figure 1: Diagramme de Gantt du projet ........................................................................................................ 13 Figure 2:Diagramme des uses cases ................................................................................................................ 16 Figure 3:Diagramme de classes ....................................................................................................................... 20 Figure 4: shémat expliquant l'architecture MVC ............................................................................................. 22 Figure 5: architecture phone Gap.................................................................................................................... 29 Figure 6: Architecture titanium. ...................................................................................................................... 30 Figure 7: Architecture Grails ............................................................................................................................ 36 Figure 8: Schéma directeur du projet .............................................................................................................. 38 Figure 9: Schéma simplifié du fonctionnement de Spring Security ................................................................ 39 Figure 10: Page d’authentification .................................................................................................................. 40 Figure 11: Menu principal de l’application ...................................................................................................... 40 Figure 12: Situation des comptes d’un abonné ............................................................................................... 41 Figure 14: Demande de recharge. ................................................................................................................... 42 Figure 15: bloc de signature de la demande de recharge. .............................................................................. 43 Figure 16: Simulateur de crédit. ...................................................................................................................... 43 Figure 17: Choix du type de virement. ............................................................................................................ 44 Figure 18: Saisie d’un virement de compte à compte ..................................................................................... 44 Figure 19: Récapitulatif du virement de compte à compte. ........................................................................... 45 Figure 20: Page de succès d’un virement de compte à compte...................................................................... 45 Figure 21: Saisie d’un virement vers bénéficiaire ........................................................................................... 46 Figure 22: Récapitulatif d’un virement vers bénéficiaire ................................................................................ 46 Figure 23: Ecran de succès d’un virement vers bénéficiaire. .......................................................................... 47 Figure 24: Demande de chéquier. ................................................................................................................... 48 Figure 25: Demande de chéquier(2). ............................................................................................................... 48 Figure 26: Demande de chéquier avec succès. ............................................................................................... 49 Figure 27: Saisie d’un transfert d’argent. ........................................................................................................ 50 Figure 28: Récapitulatif d’un transfert d’argent.............................................................................................. 50 Figure 29: Liste des tâches............................................................................................................................... 51 Figure 30: Situation des comptes titre. ........................................................................................................... 51 Figure 31: Transaction titre et portefeuille titre. ............................................................................................ 52 Figure 32: Choix de type d’effet. ..................................................................................................................... 52 Figure 33: Les comptes tirés. ........................................................................................................................... 53 Figure 34: La liste des effets à payer. .............................................................................................................. 53 Figure 35: Les comptes tireurs. ....................................................................................................................... 54 Figure 36: Les effets à encaisser par compte. ................................................................................................. 54 Figure 37: Les effets à encaisser par dates d’échéance. ................................................................................. 55 Figure 38: Les effets à encaisser par compte. ................................................................................................. 55 Figure 39: Liste des dossiers. ........................................................................................................................... 56 Figure 40: Contenu d’un dossier avec liste des impayés. ................................................................................ 56 Figure 41: La liste des impayés. ....................................................................................................................... 57 Figure 42: géolocalisation. ............................................................................................................................... 58 Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 1
  14. 14. Figure 43: processus du service phoneGap Build. ........................................................................................... 59 Figure 44: L'IDE Adobe Dream weaver ............................................................................................................ 59 Figure 45: fenêtre de phonegap build ............................................................................................................. 59 Figure 46: démarrage du service phonegap build. .......................................................................................... 60 Figure 47: connexion au service phonegap build ............................................................................................ 60 Figure 48: génération des fichiers exécutables. .............................................................................................. 61 Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 2
  15. 15. Liste Des Tableaux Tableau 1: Spécification techniques du projet ................................................................................................ 21 Tableau 2: Comparatif des protocoles de communication ............................................................................. 24 Tableau 3: Récapitulatif DM Natif Vs hybride ............................................................................................... 27 Tableau 5: comparaison des plateformes suportées. ..................................................................................... 32 Tableau 6: : Les APIs supportées par chaque plateformes. ............................................................................ 32 Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 3
  16. 16. Acronymes Et Abréviations A AIR: Adobe Integrated Runtime API : Application Programming Interface App: Application J JS : Java Script JSON: JavaScript Object Notation JVM : Java Virtual Machine B BPM : Business Process Management BSD: Berkeley software distribution M C R CSS: D DHTMLX: dynamic Hypertext Markup Language MVC : Model-View-Control REST : REpresentational State Transfer S EAI : Enterprise Application Integration SE: système d’exploitation SOAP: Simple Object Access Protocol SDK : Software Development Kit SQL : Structured Query Language SVG: Scalable Vector Graphics G U E GPS : Global Positioning System UI: user interface UML : Unified Modeling Language URL: Uniform Resource Locator H HTML: Hypertext Markup Language HTTP : HyperText Transfer Protocol HTTPS : HTTP Secure I IDE : Integrated Development Environment IOS: Iphone operating system IRC: Internet Relay Chat IHM : Interface Homme Machine W WS: Web Service W3C: The World Wide Web Consortium X XML : eXtensible Markup Langage Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 4
  17. 17. Introduction Introduction : Le mobile Banking est l'utilisation du téléphone portable pour fournir des services financiers qui peuvent être des transactions d’argent ou des échanges d'informations entre le client et les institutions financières. Il est basé sur l'idée d'utiliser en micro-finance un outil de communication, téléphone portable, qui s'est très fortement répandu ces dernières années, et ceci afin de diversifier et d'améliorer l'offre de services auprès de la clientèle actuelle. Toutefois, le développement d’une telle application doit cibler plusieurs plateformes, quitte à faire face au problème de la fragmentation concernant les applications mobiles et par la suite faire limiter le nombre d'utilisateurs de l'application. C'est pour cela que le développement mobile multiplateforme apparait. C'est dans ce contexte qu’INFOSAT nous a confié, dans la cadre de notre projet de fin d'étude, la mise en place d'une solution de mobile banking qui permettra d’exécuter des fonctionnalités financières accessibles à partir du mobile. Le présent rapport est une synthèse du travail réalisé le long de la période de notre stage. Il est structuré selon quatre chapitres couvrants l'ensemble des axes de notre travail. Le premier chapitre décrit l'organisme d'accueil INFOSAT, montre la problématique et l'analyse des besoins, cite les objectifs et les fonctionnalités à mettre en place et montre la planification du projet. Le deuxième chapitre définit l'architecture, l’étude fonctionnelle, la conception générale du projet et la démarche que nous avons suivie. Le troisième chapitre établit une étude comparative de deux frameworks de développement mobile multiplateforme "TITANIUM et PHONE GAP" en termes de l'apport, la productivité, les richesses des plateformes supportées et la gestion de déploiement. A la fin de ce chapitre nous donnons une comparaison entre le développement hybride et le développement natif. Au dernier chapitre nous mettons en œuvre le projet. En effet nous justifions les choix technologiques, puis nous présentons les écrans des différentes fonctionnalités implémentées. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 5
  18. 18. Chapitre 1 1.Contexte Général du Projet : Dans ce chapitre, nous présenterons le contexte général du projet qui sera décliné en deux parties : la première présentera la société d’accueil, et la seconde décrira le contexte, la problématique, l’objectif attendu du projet ainsi que les fonctionnalités à mettre en place et la planification du projet . Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 6
  19. 19. Chapitre 1 1.1. Présentation de l’organisme d’accueil : 1.1.1. Présentation d’INFOSAT Communications : INFOSAT est une société de services orientés vers les nouvelles technologies qui s’intéressent aux services des systèmes d’information, télécommunications et sécurité. Ceci comprend des domaines aussi variés que la mise en place des solutions client/serveur, l’administration de bases de données, le développement de logiciels et la mise en place des réseaux informatiques et téléphoniques. Les missions d’INFOSAT sont multiples. D’abord, INFOSAT Offre à ses clients, quelle que soit leur localisation, des produits et des services dans le domaine des technologies de l'information qui soient d'avant-garde et d'une juste mesure en fonction de leurs besoins et de leurs moyens financiers. INFOSAT est venu pour être un fournisseur d'informatique reconnu comme un leader pour la qualité de ses produits et de ses services et pour le professionnalisme de ses ressources. Nous citons aussi parmi les missions d’INFOSAT, la réalisation des interventions grâce à des professionnels hautement motivés offrant une disponibilité totale envers les clients, tout en démontrant un grand souci de la perfection et beaucoup de créativité dans les solutions qu'ils proposent. INFOSAT reflète une organisation où l’équipe travaille dans un climat serein et un environnement agréable qui lui permet de s'épanouir et de jouir de toute l'autonomie souhaitable afin de réussir et de se dépasser. INFOSAT participe à l'économie locale et régionale en étant un groupe de professionnels présents dans les activités d'affaires, culturelles, sociales et environnemental. 1.1.2. Domaines d’intervention d’INFOSAT Communications :  Développement informatique : - Logiciels, Etudes, conception et intégration de solutions informatiques standards, spécifiques et Open source sous les environnements Linux et Windows. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 7
  20. 20. Chapitre 1 - Développement d’applications Web. - Edition des logiciels notamment dans les métiers de la banque et des assurances, - Développements spécifiques autour des technologies Web, Mobile et SMS, INFOSAT ambitionne de se positionner comme un partenaire de référence auprès des établissements financiers souhaitant procéder au développement et à l’intégration de progiciels spécialisés. Leur objectif est de générer de la valeur ajoutée pour nos clients en respectant leurs spécificités, contraintes, et exigences aussi bien sur le plan de la qualité que celui du coût.  Compétences de développement: - Langages de programmation : Windev, VB, Delphi, Java (J2EE), C++ - Bases de données : PostgreSQL, SQL Server, Interbase/Firbird, MySQL… - Développement mobile : iphone , Androide ,Titanium ,Phongap … - Méthodes d'analyse et modélisation : Merise, UML. Les prestations de service sont axées principalement autour de leurs produits, et couvrent les volets suivants : - Accompagnement pour la définition et le cadrage des besoins et intégration de leurs solutions, Prise en charges des développements spécifiques, Formation et conduite de changement, Hébergement (en option) en mode SaaS de notre solution, Maintenance et assistance post-production,  Réseaux informatiques : - Etude et conception d’architectures et solutions réseaux (LAN- INTRANET-WIFI….) Installation de serveurs LINUX /Windows Server (contrôleur de domaine, serveur de fichiers, messagerie, site web, impression…) Etablissement de stratégies de sécurité réseau (Proxy, Firewall, sauvegardes, antivirus…) Travaux de câblage Ethernet (CAT5, CAT6, Fibre optique), armoires informatiques, Antennes et Points d'accès WIFI….  RÉSEAUX TELEPHONIQUES : - Travaux de câblage téléphonique (prises, moulure et accessoires…) Equipement, configuration et installation de standards téléphoniques ainsi que la Téléphonie IP. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 8
  21. 21. Chapitre 1  MAINTENANCE ET REPARATION : - SAV et Contrats de maintenance sur tous les produits (matériels et logiciels) fournis par INFOSAT. Maintenance et réparation soft et hard informatique, téléphonique et électronique.  VENTE : - SYSTÈMES DE POINTAGE (Pointeuses, cartes de proximité, badges, logiciel de gestion de présence), LOGICIELS (LGP Gestion de pointage, antivirus, gestion pharmacie, gestion commerciale, gestion paie), MATERIEL ET ACCESSOIRES INFORMATIQUE (Micro-ordinateurs, Imprimantes, Traceur, Onduleur…) , EQUIPEMENTS DE TELECOMUNICATION (routeurs, switchs, modems, équipements WIFI, standards et appareils téléphoniques), SOLUTIONS DE TÉLÉSURVEILLANCE (caméras de surveillance, caméras IP, cartes DVR….). Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 9
  22. 22. Chapitre 1 1.2. Cadre général du projet : 1.2.1. Problématique et analyse du besoin : Au fil des années, les concepts de temps et de distance ont perdu de leur significativité à cause des nouvelles technologies et plus spécifiquement l’Internet et les Smartphones, qui ont acquis une grande importance dans notre quotidien. L’un des secteurs économiques le plus touché par ce phénomène est le secteur bancaire, en effet aujourd’hui la banque propose un nombre croissant de services délivrés en ligne : de la simple consultation des soldes bancaires ou la création de virements électroniques, on peut dorénavant bien gérer nos opérations boursières, solliciter un crédit, voir même ouvrir un nouveau compte sans devoir se présenter au guichet d’une banque. Certaines de ces activités étaient impossibles il y a quelques années. Agissant avec lucidité et consciente des évolutions que connait son domaine, la banque X (le nom réel de la banque a été omis pour des raisons de confidentialité)- a fait appel à la société INFOSAT Communications afin de lui développer une application de gestion des opérations bancaires. Cette banque se veut être crédible et ne tient en aucun cas à perdre sa confiance auprès de ses clients. L’application était déjà dotée de quelques fonctionnalités en back office sur le web et avait besoin d’être améliorée et mise en place sur mobile, et c’est justement le but de notre projet. L’idée sur laquelle nous nous sommes basés était d’utiliser un moyen de communication sécurisé pour fournir des services financiers qui peuvent être des transactions financières et des échanges d’informations entre le client et l’institution financière. 1.2.2. Objectifs du projet: Le concept de la performance occupe une place centrale dans le processus de gestion de toute entreprise et précisément la société « INFOSAT Communications », puisque l’objectif principal de cette dernière est d’obtenir des résultats compatibles avec sa mission et sa planification stratégique et opérationnelle. L’évaluation de la performance est donc une activité omniprésente et s’avère encore plus qu’une nécessité avec tout changement technologique ou commercial opérant au sein de la banque. Notre application en tant que moyen de bonne gestion, doit être à la hauteur des attentes, et de la banque, et des clients bien évidemment. Les dimensions de la performance commerciale exigées par la banque dans le cahier des charges étaient : Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 10
  23. 23. Chapitre 1 1. L’amélioration de la qualité des services : La temporalisation de la prestation de service permise par divers équipements et systèmes d’informations, la délocalisation, le gain de temps, la ré-négociabilité, la flexibilité, la sécurité des transactions ainsi que l’interaction en temps réel sont les principales améliorations de la qualité des services de la banque. 2. La réduction des coûts  Coût de traitement par le client  Coût de transaction  Coût d’administration 3. La variété de la gamme d’offres : L’adoption des nouveaux canaux de l’E-Banking ouvre de nouvelles potentialités à la banque pour élargir sa gamme de produits et services offerts aux clients (signature électronique, paiement en ligne,..) 4. La conquête de nouveaux marchés : Les nouveaux canaux de distribution permettent de desservir des consommateurs à travers des zones géographiques de plus en plus éloignés. Plus la banque adopte les canaux électroniques de distribution et de communication, plus elle aura la possibilité de contourner les barrières géographiques, et ainsi conquérir, gérer et fidéliser de nouveaux clients. 5. Le renforcement de la relation avec les clients : cette relation a tendance à se renforcer avec l’utilisation de ces nouveaux canaux multiples, intégrés et disponibles en tout temps. Pour satisfaire ces besoins et assurer les nouvelles fonctionnalités que veut s’attribuer la banque X, un site web classique paraît une solution inévitable, mais qui doit être étendue avec l'utilisation d'une application web mobile. 1.2.3. Fonctionnalités à mettre en place: Les différentes fonctionnalités à mettre en place dans l’application sont :  L’accès sécurisé aux comptes bancaires et consultation de leurs soldes.  La réalisation des transactions et la visualisation de leurs détails.  La réalisation de virements : Virement de compte à compte. Virement vers un bénéficiaire.  Le Transfert d’argent.  La demande de chéquier(s). Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 11
  24. 24. Chapitre 1  La visualisation des tâches non accomplies par le client (Système de notification).  La simulation d’un crédit.  Le contact avec la banque et ses agences.  Un système de géolocalisation. 1.2.4. Planification du projet: Dans le cadre de la conduite du projet, la réalisation d’un planning à suivre tout au long du stage de fin d’études s’impose. Ainsi, le stage a débuté le mardi 4 février 2013. Du coup, une réunion a été tenue afin de définir le calendrier du projet. Le planning sur lequel on s’est mis d'accord est subdivisé en cinq grandes étapes:  La première est l’étape de documentation et d’expression des besoins.  La seconde est l’étape des spécifications fonctionnelles et techniques.  La troisième étape, quant à elle, traite de la conception.  La quatrième étape définit le contexte technique.  La dernière étape est consacrée à l’implémentation, le jeu de tests et le déploiement sur mobile. Le planning des étapes de déroulement du projet est présenté à la figure 1 qui représente le diagramme de GANTT qui permet de rendre plus simple le suivi de l’avancement du projet. Conclusion: Après une présentation de l'organisme d'accueil. Nous avons décrit le contexte, la problématique, les objectifs du projet, ainsi que la mission à accomplir dans notre stage. Dans la prochaine partie nous établirons une étude comparative des framework de développement mobile. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 12
  25. 25. Chapitre 1 Figure 1: Diagramme de Gantt du projet Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 13
  26. 26. Chapitre 2 2.Etude Fonctionnelle et Technique: Ce chapitre sera consacré à la définition de l'architecture et la conception générale de la solution. Il décrira aussi la démarche à suivre, et mettra en œuvre une étude fonctionnelle du projet ainsi qu'une autre technique. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 14
  27. 27. Chapitre 2 2.1. Etude fonctionnelle: 2.1.1. Capture des besoins fonctionnels : L’application à réaliser est une application de gestion d’opérations bancaires, elle permet à un abonné de réaliser toutes sortes d’opérations liées à son compte bancaire, il peut visualiser le solde de son ou ses comptes et revoir les dernières opérations effectuées sur ces derniers. Il peut également effectuer des virements, faire des demandes de chéquiers, ainsi que transférer de l’argent à un particulier…, en s’étant bien évidemment authentifié pour pouvoir accéder à ces fonctionnalités. En plus, un abonné a la possibilité de localiser les agences les plus proches, chercher les agences par ville et pays et connaitre la distance qui sépare son emplacement de l’agence choisie, ainsi que tracer un itinéraire vers cette destination. Enfin, il peut faire une simulation de crédit en choisissant le montant d’emprunt, pour ainsi connaitre la durée de l’emprunt ou le montant mensuel à payer selon le choix. 2.1.2. Analyse fonctionnelle : 2.1.2.1. Diagramme des Use Cases: Les cas d'utilisation permettent de recueillir, d'analyser et d'organiser les besoins, et de recenser les grandes fonctionnalités d'un système. Il s'agit donc de la première étape UML d'analyse d'un système. Dans cette section nous allons présenter les cas d’utilisation concernant le module de :  Gestion des opérations bancaires. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 15
  28. 28. Chapitre 2 Figure 2:Diagramme des uses cases 2.1.2.2. Descriptions des Use cases:  Consulter un compte : Acteur : Abonné Description : L’abonné a la possibilité de consulter le solde de chacun de ses comptes, et de voir les mouvements concernant chaque compte. Chaque mouvement est constitué des informations suivantes :     Identifiant du mouvement Intitulé du mouvement Date d’exécution Montant du mouvement Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 16
  29. 29. Chapitre 2 Effectuer un virement : Acteur : Abonné Description : Dans ce cas d’utilisation l’abonné peut effectuer un virement de compte à compte, c’est un virement qui se fait entre les comptes du même abonné. Pour cela, il doit saisir toutes les informations qui concernent ce type de virement, ce dernier caractérisé par :       Identifiant de ce virement Compte à créditer Compte à débiter Montant du virement Motif du virement Date d’exécution du virement L’abonné peut éventuellement effectuer un virement vers un bénéficiaire. Ce virement ne concerne pas un seul abonné, mais se fait entre un abonné et un autre existant parmi les bénéficiaires de cet abonné. Pour cela, il doit également saisir toutes les informations qui concernent ce type de virement, qui se voit caractérisé par :       Identifiant de ce virement Bénéficiaire Compte à créditer Montant du virement Motif du virement Date d’exécution du virement Exceptions : L’identifiant du virement est une valeur unique. Si cette donnée existe déjà dans le système, une exception doit être levée. Le montant du virement ne doit pas dépasser le plafond quotidien spécifié dans le contrat et qui représente la somme totale de tous les montants des opérations pouvant être effectuées par les abonnées liée à ce contrat. La date d’exécution ne doit pas être antérieure à la date système, sinon une exception est levée. Dans un virement de compte à compte (même abonné), le compte à créditer doit être différent du compte à débiter.  Effectuer un transfert d’argent : Acteur : Abonné Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 17
  30. 30. Chapitre 2 Description : L’abonné peut effectuer des transferts d’argent vers un bénéficiaire, même n’étant pas client de la banque. Pour cela, il doit saisir toutes les informations qui concernent ce transfert, qui se voit caractérisé par des informations concernant le compte à débiter:  Compte à débiter  Montant du transfert  Motif du transfert Ainsi que des informations sur le récepteur du transfert :        Nom et prénom du bénéficiaire Type de la pièce d’identité (Carte national, passeport, permis, carte séjour ...) Numéro pièce d’identité Adresse Ville Pays Téléphone principal  Demander un chéquier : Acteur : Abonné Description : L’abonné a aussi la possibilité de faire une demande d’un carnet de chèques, soit pour luimême ou pour un autre bénéficiaire, et cela en spécifiant les informations suivantes :     Compte à débiter Nombre de chéquiers Type de chéquier Moyen de remise du/des chéquier(s) Ainsi que des informations citées précédemment sur le bénéficiaire.  Simuler un crédit : Acteur : Abonné Description : Si l’abonné veut connaitre les détails d’une prise de crédit de cette banque, il a la possibilité de faire une simulation de crédit. Pour cela, il fournit le montant total du prêt, ainsi que l’une des informations suivantes :  Le montant mensuel qu’il a l’intention de payer Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 18
  31. 31. Chapitre 2  La durée au bout de laquelle il compte rembourser le prêt Et en fonction de l’information saisie, l’autre information est calculée.  Localiser les agences de la banque : Acteur : Abonné Description : Dans ce cas d’utilisation, l’abonné peut connaitre sa position via GPS et ainsi déterminer les agences qui sont à proximité de lui, ou bien les rechercher par ville et par nom d’agence, ces derniers qui sont transformés en coordonnées sur la map, pour enfin connaitre la distance qui le sépare d’une agence. 2.1.2.3. Diagramme de classes: Ce diagramme regroupe les différentes classes du projet à savoir : «Compte», « VirementVersBenificiares », «VirementCompteAcompte », «TransfertArgent », « PaysAgence », « Virement », « Benificiare », « Contrat », « Agent », « Demande de chequier » …, contribuant à effectuer toutes les opérations bancaires exigées par le cahier des charges. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 19
  32. 32. Chapitre 2 Figure 3:Diagramme de classes Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 20
  33. 33. Chapitre 2 2.2. Etude technique: 2.2.1. Spécifications techniques : L’outil doit être en mesure de répondre à un certain nombre d’exigences techniques. Cellesci se résument dans les objectifs présentés dans le tableau suivant : Objectif Description Multiplateformes L’application doit pouvoir être accessible depuis les deux plateformes iOS et Android. Fluidité du déploiement L’application doit marcher sans problèmes dans toutes les versions antérieures du SE. Confidentialité Les utilisateurs du système sont identifiés par leurs noms et leurs mots de passe. Optimisation du temps de réponse Aucune donnée ne doit être stockée localement. Sécurité des transactions Toutes les transactions du client vers le serveur doivent être sécurisées. Tableau 1: Spécification techniques du projet 2.2.2. Architecture: 2.2.2.1. Architecture mobile: Deux approches possibles lorsque l’on débute un projet d’application mobile ciblant plusieurs plateformes :  L’approche native: consiste à développer l’application pour chacune des plateformes.  L’approche hybride: qui consiste à développer une Application réalisée via un site Web optimisé pour mobile (Web Apps). La comparaison détaillée de ces deux approches sera dans le troisième chapitre. 2.2.2.2. Architecture serveur: Pour la séparation des données, des traitements et de la présentation, On adopte l’architecture MVC. Programmer en utilisant MVC sépare l’application en 3 parties principales : Le Modèle - La Vue - Le Contrôleur: 1. Le modèle: Il représente les données et les règles métiers. C’est dans ce composant que s’effectuent les traitements liés au cœur du métier. Les données peuvent être liées à une base de données, des services web, etc. 2. La vue : correspond à l’IHM. Elle présente les données et interagit avec l’utilisateur. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 21
  34. 34. Chapitre 2 3. Le contrôleur : se charge d’intercepter les requêtes de l’utilisateur, d’appeler le modèle puis de les rediriger vers la vue adéquate. Il ne doit faire aucun traitement. Il ne fait que de l’interception et de la redirection. Figure 4: shémat expliquant l'architecture MVC 2.2.3. Choix de technologie « Services Web » :  Services Web : Définition : Un " Service Web" est une application logicielle à laquelle on peut accéder à distance à partir de différents langages basés sur XML. Un " Service Web" est identifié par un URL, comme n'importe quel site Web. Il s'exécute sur un "Serveur d'Applications". Peu importe l'ordinateur, le système d'exploitation ou le langage utilisés par le client. Plus simplement, C'est le fait de mettre des ressources à disposition sur Internet, via un protocole d'échanges standardisé, pour des programmes écrits dans des langages quelconques. Cela nécessite :  un encodage (toujours XML) ;  un transport (souvent HTTP) ;  une organisation des requêtes et des réponses. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 22
  35. 35. Chapitre 2 La procédure de fonctionnement d'un service Web en bref est la suivante : 1. le service Web définit un format pour les requêtes et les réponses. 2. un ordinateur demandeur effectue une requête. 3. le service Web effectue une action, et renvoie la réponse à l'ordinateur demandeur.  Argumentation du choix : Les Services Web permettent de :  Faciliter le travail du développeur dans la mesure où le modèle d’interaction par appel de méthodes métiers est le même que celui de l’application, et donc les services Web permettent de faire appel aux méthodes métiers par plusieurs interfaces sans avoir à refaire le code pour chaque interface.  Améliorer un aspect de l’interopérabilité en spécifiant le format dans lequel les informations doivent être encodées.  Optimiser le temps d’appel au serveur puisque aucune donnée ne sera stockée localement lors des appels distants.  REST ou SOAP, lequel choisir ? Après le choix des web services comme moyen de communication entre le client et le serveur, vient le choix du protocole de communication. Lors de nos recherches, nous avons trouvé deux protocoles qui ont suscité notre curiosité : REST et SOAP, ce qui nous a mené à faire une étude comparative afin de faire le bon choix. REST et SOAP sont des styles architecturaux qui permettent la transmission d’objets distants. Ce sont eux qui autorisent les objets à invoquer des méthodes d’objets situées sur un autre serveur. SOAP Vision et but de Utiliser le web pour échanger des l’application objets Type SOAP utilise des requêtes cachées REST Ouvrir le web aux applications REST utilise des requêtes HTTP et Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 23
  36. 36. Chapitre 2 d’administration dans des fichiers XML ainsi son donc son administration est comme administration comme celle d’un celle du Web EAI Un service SOAP se met en place Type de développement comme le déploiement d'un objet. Cela ouvre la porte à l'utilisation de langages de programmation à typage statique Interopérabilité et plateformes Un service REST se met en place comme une page Web. Cela ouvre la porte à des développements rapides, aux tests possibles avec un simple navigateur et à l'utilisation de langage de scripts SOAP utilise beaucoup de normes REST n’a besoin que d’une pile et versions de chaque normes ce qui HTTP pour n’importe quelle diminue son interopérabilité plateforme * Tableau 2: Comparatif des protocoles de communication  Argumentation du choix : REST a été la meilleure solution comme protocole de communication du fait que : - Il est simple à mettre en place. - Il est plus sécurisé que son concurrent lors des appels distants. - Le choix de la solution mobile que nous avons appréhendé était plus compatible avec ce protocole. Conclusion: Les parties traitées dans ce chapitre sont les plus cruciales pour tout développement. Il s'agit de la capture des besoins fonctionnels et la phase d'analyse et de la conception, en se basant sur le diagramme de cas d'utilisation et le diagramme de classes. On a traité aussi l'architecture et les spécifications techniques. Les résultats de cette partie représentent la base de la réalisation technique du projet, qu’on commencera par une étude comparative des framework de développements existants. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 24
  37. 37. Chapitre 3 3.Choix de Framework de développement mobile: Cette partie dresse une étude comparative entre deux framework de développement mobile multiplateforme à savoir phone Gap et Titanium. Elle traite également la comparaison entre les développements natif et hybride. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 25
  38. 38. Chapitre 3 3.1. Développement Hybride Vs Natif: 3.1.1. introduction: Les applications natives sont des applications construites et installées sur des plates-formes spécifiques, comme iOS ou Android, en utilisant un SDK spécifique à chacune. Par exemple, pour l'iPhone et l’iPad d'Apple, les applications sont conçus et développées sur iOS : écrits dans Xcode en utilisant l’Objective-C. Quand-à Android a sa propre version de Java et Windows utilise C #, et ainsi de suite. Parmi les inconvénients des applications natives, c’est qu’elles sont écrites pour une plateforme et ne peuvent pas être déployées sur une autre. Aussi, les développeurs ont toujours besoin de ressources supplémentaires pour développer et maintenir chaque plate-forme, qui est toujours coûteux, d’où le développement mobile hybride apparait. 3.1.2. Quelle est la meilleure approche : Le meilleur choix dépend du type d'application qu’on souhaite développer. Par exemple, les applications telles que des jeux vidéo et les applications qui contiennent des animations favoriseraient le développement natif, alors que les applications hybrides peuvent être mieux adaptées pour les applications d'entreprise mobiles, car ils sont multiplateformes, d’où la cible est un marché vaste. Ci-après quelques critères qu’on a pris en considération lors du choix de notre solution de développement.  Complexité: Quelle est le niveau de complexité de l'application? Est-ce-que c’est une application rapide qui accède à un service de base de données ou sur le Web pour certaines données à afficher? – dans notre cas une application Web mobile peut suffire. .  Performance: Quel type de rendement est exigé par l'application, par exemple, pour regarder en temps réel des données à partir du réseau, la performance de l’application mobile dépend de la latence du réseau et des capacités du serveur. -- Les deux : hybrides et natif offrent des bonnes performances.  La connectivité et la disponibilité: Quel est le type de connectivité exigé? Est-ce que l'application exige d’être connecter en permanence afin de récupérer les données récentes? - Les applications natives et hybrides peuvent être construites pour fonctionner en ligne et même hors ligne.  multi-plate-forme Exigences: Ce critère fait la grande différence, et seules les applications hybrides qui supportent le développement multi-plate-formes.  Appareil-Services d'accès: Les applications natives ou hybrides permettent d'accéder aux services périphériques locaux, tels que la caméra, app contacts, accéléromètre, etc. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 26
  39. 39. Chapitre 3  Ressources: Pour le développement natif, Le nombre de développeurs consacrer à la construction et au développement de l’application mobile, leur niveau de compétence aussi l’environnement de travail « ici un système d'exploitation de chaque plate-forme, de langage de programmation bien spécifie, et des devices pour les tests » rend le travail couteux, et si on souhaite ajouter une autre plate-forme, donc un autre langage, une autre SDK, de nouveaux compétences. -- Pour ce critère les applications hybrides sont les plus rentables, mais il peut y avoir des petites différences de performances.  Autre critères: Native Hybrid Graphiques Native APIs HTML, Canvas, SVG Performance Rapide moyenne Distribution Appstore Appstore Camera oui oui Notifications oui oui Contacts oui oui Stockage hors ligne Secure file storage Fichiers de système sécurisés. Géolocalisation oui oui connectivité Online et offline Online et offline Development skills ObjectiveC, Java HTML5, CSS, Javascript App Features Device Access Tableau 3: Récapitulatif DM Natif Vs hybride Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 27
  40. 40. Chapitre 3 D’après cette étude on constate que le développement hybride est globalement plus productif. C’est une solution pour les personnes souhaitant effectuer un investissement sérieux dans le mobile. Mais sans oublier qu’ils ne vont jamais remplacer d’une manière entière le natif. 3.2. Développement mobile multiplateformes: Il existe plusieurs Framework de développement mobile hybride basés sur JavaScript et qui permettent d’améliorer la productivité, on cite : PhoneGap(Apache Cordova), Appcelerator Titanium, jQuery Mobile, Sencha Touch, DHTMLX Touch, Limes JS, JQTouch, … Ces Framework partagent quelques caractéristiques à savoir :  Optimisés pour les appareils tactiles : la saisie de données n’est plus restreinte à la souris ou au clavier mais devient aussi faisable par les doigts ce qui représente un ensemble de challenges pour le design des IU. Les plateformes de développement mobile fournissent des éléments standards pour les interfaces graphiques et une gestion des événements en particulier pour le développement mobile.  Une variété de plateforme : ils supportent des appareils avec différents systèmes d’exploitation tels que Ios et Android ce qui permet de fournir l’application à plusieurs utilisateurs.  Lightweight : à cause des limitations da la bande passante, ces Framework se concentrent très fortement sur la réduction des tailles des fichiers.  Utilisation des Standards de HTML5/CSS 3 : la plupart des équipements mobile se dote d’un navigateur qui supporte HTML5 et CSS3, ainsi les Framework de développement web mobile profitent des fonctionnalités disponibles dans ces spécifications de W3C. Dans notre projet nous avons effectué une comparaison entre Appcelerator Titanium, Phone Gap. A partir de cette étude nous avons pu établir les avantages et les inconvénients de chacune d’elles, ce qui nous a permis choisir la plateforme qui convient pour la réalisation du projet. 3.2.1. Phone Gap: C’est un framework open source (acheter ne par adobe le 3 octobre 2011. Ceci confirme l’intérêt que l’on peut avoir envers cette solution. Ce Framework permet de convertir des applications développées par le langage Java script, HTML et CSS en application native à l’aide du service Pour développer des applications PhoneGap, on crée des documents HTML, CSS et des fichiers JavaScript dans un répertoire local, tout comme l'élaboration d'un site Web. Ce qui nous Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 28
  41. 41. Chapitre 3 permet de profiter de quelques outils précisément le navigateur web du bureau, sans avoir besoin de l'ensemble des outils natifs de chaque éditeur. La compilation et la génération des fichiers exécutables sur chacune des plateformes ciblées : IOS, Android, Windows phone 7, BlackBerry…, se fait à l’aide de l’outil Phone Gap Build. C’est un service qui permet la compilation du projet dans le Cloud et la génération des APK. Figure 5: architecture phone Gap On peut toujours tester l’application développée soit avec l’émulateur soit avec le device, mais bien sur après avoir téléchargé le fichier exécutable convenable, généré par le service Phone Gap Build.  Les avantages :      petite bibliothèque. Accès à de nombreuses ressources matérielles. Extensibilité. Communauté active. Compilation à partir du cloud.  Les inconvénients :  conception avec callback parfois difficile à accorder avec d'autres librairies JavaScript. 3.2.2. Titanium: Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 29
  42. 42. Chapitre 3 C’est un Framework open source développé par Appcelerator qui vend des supports et des formations sur Titanium. Cette solution permet de développer des applications hybrides en utilisant JavaScript, HTML et CSS. Titanium est basée sur deux aspects de développement mobile:   Un noyau d'APIs pour créer des applications mobile qui peuvent être installées sur différentes plateformes. Parfois Ils existent des APIs spécifiques pour chaque plate-forme, par exemple des conventions pour l’interface graphique, et des fonctionnalités que les développeurs devraient prendre en considération lors de l’élaboration d’une application. Pour ces raisons, Titanium ne peut pas être considéré comme une solution pour coder une seule fois, exécuter partout’ comme Phone Gap.  Fonctionnement du Framework : Généralement, lors de l’exécution, l’application consiste en trois éléments qui sont :  Le code source JavaScript.  La mise en œuvre des APIs Titanium dans la plate-forme spécifique.  L’interpréteur de JavaScript qui est utilisé pour évaluer le code à l’exécution.  Les composants de l’UI peuvent être organisés hiérarchiquement pour créer des interfaces utilisateurs complexes. Les objets proxy qui représentent une interface pour les APIs non visuelles (comme système de fichiers I / O ou accès de base de données) s’exécutent dans le code natif, et de façon synchrone pour renvoyer un résultat JavaScript. Figure 6: Architecture titanium. Pour développer une application avec Titanium, le développeur doit nécessairement installer les SDK de la plateforme ciblée par exemple Ios et Android. Cependant, même après l’installation de ces outils, l’utilisateur interagit souvent avec l’interface de Scripting de SDK de Titanium Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 30
  43. 43. Chapitre 3 (Aujourd’hui basée sur Pyhton). Ceci peut être réalisé soit avec les commandes Titanium ou très souvent avec Titanium Studio qui est un IDE basé sur eclipse. En utilisant l’ensemble des outils de Titanium, le développeur peut générer un répertoire pour le projet, qui contient la configuration et la localisation des fichiers et un répertoire qui contient les images, ainsi que le code source JavaScript utile pour donner plus d’importance à l’application. Le développeur n’aura pas à utiliser les fichiers HTML et CSS que s’il a l’intention de développer une application hybride qui est à la fois native et basée sur une interface graphique HTML. Les applications de Titanium peuvent utiliser une interface graphique hybride (web et native) comme l’application native Facebook par exemple. L’exécution d’une application de Titanium se fait via l’émulateur de la plate-forme ciblée.  Les avantages :  Application native : aspect natif & performances.  Accès aux ressources matérielles.  Vitesse de développement.  Extensibilité.  Les inconvénients :  Mauvaise documentation, manque de ressources d’apprentissage.  IDE réclamant une connexion Internet permanente.  Parfois de nombreuses fuites de mémoire apparaissent.  Les SDK de chaque plateforme est nécessaire. 3.3. Comparaison : Titanium VS Phone Gap: 3.3.1. Comparaison des plateformes supportées: On commence par la comparaison des plateformes supportées par chacun des deux FrameWorks. En pratique, les applications développées par PhoneGap peuvent être installées et exécutées sur sept plateformes différentes « voir tableau numéro 5 ». Concernant Titanium, le support de BlackBerry et Windows phone sont encore récents et disponible uniquement sous Windows. A cause de l’écrasante domination de l’iPhone, d’Android et de BlackBerry), on ciblera généralement ces 3 plateformes uniquement. Mais quelques entreprises ciblent également les plateformes Web OS, Symbian, Bada …, Donc Phone Gap devient une solution incontournable. Ci-après un tableau qui illustre les différentes plateformes supportées par chacun des Framework. Phone Gap 1234- MAC IOS Android BLACKBERRY WINDOWS PHONE Titanium 1234- MAC IOS ANDROID BLACK BERRY10. WINDOWS PHONE. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 31
  44. 44. Chapitre 3 5- BADA 6- SYMBIAN 7- WEB OS Tableau 4: comparaison des plateformes suportées. 3.3.2. Comparaison des richesses des deux plates-formes: En général il y’a pas de grande différence entre ces deux plateformes en termes des APIs supportées. Pourtant, il y a quelques une en ce qui concerne l’aspect général de chacune. Titanium est fonctionnellement riche et fournira une apparence plus proche du natif, ce qui est en général l’objectif des concepteurs d’applications. PhoneGap est généralement limité en termes de fonctionnalités, car à chaque fois on doit concevoir les écrans comme des pages Web et non des écrans natifs. . Ci-après un tableau récapitulatif des APIs et plugins supportés par les deux Framework : APIs PhoneGap Titanium Accéléromètre Oui Oui Caméra Oui Oui Media Oui Oui Map Oui Oui Géolocation Oui Oui Facebook Oui Oui Database Oui Oui FileSystem Oui Oui Cloud Oui Oui Contacts Oui Oui Notification Oui Oui Network Oui Oui UI Non Oui Tableau 5: : Les APIs supportées par chaque plateformes. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 32
  45. 45. Chapitre 3 3.3.2.1. Synthèse : L’utilisation de JavaScript devient de plus en plus large, donc il est nécessaire, pour développer ce type d’applications, de se former profondément à JavaScript et de connaître les design patterns et la structuration /modularisation du code de ce langage. De manière globale, l’environnement de développement de Phonegap est mieux intégré, plus documenté ainsi qu’il est facile à apprendre. Conclusion: Cette partie a apporté une vision claire sur le développement mobile multiplateforme et a permis de faire sortir les avantages et les inconvénients des deux framework et a distingué entre le développement hybride et les développements natifs. Cette étude est une étape préliminaire vers l'étude technique du projet qui fera, en plus de l'étude fonctionnelle, l'objet de la prochaine partie Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 33
  46. 46. Chapitre 4 4.Mise en Œuvre du projet Dans ce chapitre on présentera la réalisation technique des différentes fonctionnalités du projet. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 34
  47. 47. Chapitre 4 4.1. Choix technologiques : Nous avons opté pour l’utilisation des technologies suivantes pour plusieurs notamment pour bénéficier de l’expérience du cadre professionnel présent à Communications par rapport à la partie serveur, mais également pour la simplicité utilisation. Pour la partie mobile, nous avons effectué une étude comparative pour déterminer l’outil que nous avons utilisé. raisons, Infosat de leur pouvoir 4.1.1. Coté serveur:  Groovy : Groovy est un langage de programmation orienté objet destiné à la plate-forme Java. Il constitue une alternative au langage Java pour cette plate-forme et est inspiré de Python, Ruby et Smalltalk. Il utilise une syntaxe très proche de Java, avec des accolades, et est directement compilé, soit à la volée dynamiquement, soit classiquement avec un compilateur en bytecode.  Grails : Grails est un framework open source de développement agile d'applications web basé sur le langage Groovy et sur le patron de conception Modèle-Vue-Contrôleur. Grails est basé sur cinq principes fondamentaux :    Ne pas se répéter : les éléments de l'application ne doivent être qu'à un seul endroit. L'architecture MVC et la méta programmation en Groovy rendent cela possible. Convention plutôt que configuration : il est inutile de préciser des détails lorsqu'ils respectent des conventions établies. Grails exploite cela en proposant des comportements par défaut pour la plupart de ses fonctionnalités. Architecture orientée modèle : le point d'entrée et la pierre angulaire d'un développement Grails est la description formelle des classes représentant le domaine métier (Modèle conceptuel de données) ainsi que de leurs dépendances. Les couches techniques sousjacentes sont générées. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 35
  48. 48. Chapitre 4   Prototypage : Les mécanismes de scaffolding offerts par le Framework permettent de générer automatiquement un prototype d'application "présentable" aux utilisateurs dès la formalisation des classes de domaine. Exploiter la puissance de la JVM : les scripts Groovy étant compilés en bytecode Java, Grails exploite totalement la richesse et la puissance du monde Java.  Architecture Grails : Figure 7: Architecture Grails  PostgreSQL : PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO). Il supporte une grande partie du standard SQL tout en offrant de nombreuses fonctionnalités modernes :      requêtes complexes, clés étrangères, triggers, vues, intégrité transactionnelle, contrôle des versions concurrentes (MVCC ou multi version concurrency control). Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 36
  49. 49. Chapitre 4  SpringSource Tool Suite : Basée sur Eclipse, SpringSource Tool Suite est conçue pour développer des applications Java reposant sur Spring. 4.1.2. Coté mobile: Critères de choix : Etude comparative PhoneGap vs Titanium , déjà présentée dans le troisième chapitre : VS 4.2. Architecture globale du projet : Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 37
  50. 50. Chapitre 4 Figure 8: Schéma directeur du projet La figure donne une idée générale sur le fonctionnement du projet, et qui est la suivante : Le client envoie une requête sécurisée HTTPS via le protocole REST au serveur web, et plus précisément au contrôleur où sont injectés les Web Services. Grâce à ses interactions avec les sévices il consulte les méthodes métiers, ainsi qu’avec le domaine (qui remplace la couche modèle dans l’architecture Grails), renvoie le résultat de la requête sous format JSON au client, celle-ci permet de compléter les vues développées par Phone Gap. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 38
  51. 51. Chapitre 4 4.3. Implémentation : 4.3.1. Authentification : Une étape incontournable de la création d’application consiste en l’authentification. Afin d’accéder aux fonctionnalités de l’application, un écran d’authentification s’offre à l’utilisateur dès l’exécution de cette dernière. Dans cette partie, nous avons adopté le module Spring Security. Spring Security permet de gérer l'accès aux ressources d'une application Java qui peuvent être des pages web, mais aussi des objets de services métier. Toute ressource sollicitée par un appelant est rendue accessible si : - d'une part, l'appelant s'est identifié, - d'autre part, il possède les droits nécessaires (des rôles dans le vocabulaire Spring Security) Principe de fonctionnement de Spring Security : Afin d’utiliser Spring Security dans Grails, on doit installer ce plugin via la console Grails, ce dernier qui va nous aider à installer une gestion des utilisateurs, avec gestion des rôles et filtres URL/Rôles. Les requêtes HTTP envoyées par l’utilisateur sont interceptées par un filtre de servlet qui délègue à un Bean Spring les traitements de vérification d'accès aux pages web. Figure 9: Schéma simplifié du fonctionnement de Spring Security Dans notre cas, les requêtes HTTP envoyées doivent être sécurisées du fait de la confidentialité des données lors de leur envoi par client vers le serveur et donc on utilise le protocole de transmission HTTPS plutôt que le HTTP classique. Afin d’implémenter cette fonctionnalité dans Grails, on doit le forcer à utiliser le protocole sécurisé HTTPS. Ainsi, les données provenant des formulaires sont envoyées via HTTPS, donc cryptées, et acheminées vers le serveur grâce à Spring Security qui encode les mots de passe lors de la transmission et utilise des annotations pour sécuriser l’accès aux méthodes métiers. L’abonné est appelé à s’authentifier en tapant son nom d’utilisation et son mot de passe, s’il est déjà enregistré et les deux sont validés alors l’authentification sera réalisée sans aucun problème sinon elle sera refusée. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 39
  52. 52. Chapitre 4 Figure 10: Page d’authentification Une fois l’abonné authentifié, il peut accéder aux quatorze fonctionnalités de l’application. Figure 11: Menu principal de l’application Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 40
  53. 53. Chapitre 4 4.3.2. Consultation des comptes : L’abonné peut consulter le solde de son ou ses compte(s), ainsi que les mouvements effectués pour chaque compte. Figure 12: Situation des comptes d’un abonné Consultation des mouvements : Cette fonctionnalité permet à l’abonné de consulter plusieurs informations qui concernent la liste des mouvements effectués dans chacun de ses comptes. Parmi ces informations : l’intitulé du mouvement, sa date de création ainsi que le montant. On a organisé l’affichage par une pagination qui ne permet que d’afficher les mouvements dix par dix. Et chaque page correspond à une requête HTTPS pour ne pas trop ralentir l’appel des web services. Figure 13: Affichage des mouvements sur un compte Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 41
  54. 54. Chapitre 4 4.3.3. Demande de recharge: L’utilisateur remplit le formulaire de demande de recharge : -Le compte à débiter. -Le numéro de la carte. -Le nom du bénéficiaire. -Le montant de recharge. -Le motif. -Le type de recharge : Ponctuel ou permanent. Si le client a choisi le type de recharge permanent, alors un autre bloque s’affiche et contient les informations suivantes : - La périodicité. - La date de début. - La date de fin. Figure 14: Demande de recharge. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 42
  55. 55. Chapitre 4 Après avoir rempli tous les champs, l’utilisateur reçoit le bloc de récapitulation où il est demandé de signer et confirmer la demande. Figure 15: bloc de signature de la demande de recharge. 4.3.4. Simulateur de crédit : L’abonné a accès au simulateur de crédit pour avoir une idée sur l’échéance ou le montant mensuel à payer en cas d’une demande de prêt. Ces derniers sont calculés selon le taux d’intérêt fourni, grâce à des formules connu dans le milieu bancaire.. Figure 16: Simulateur de crédit. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 43
  56. 56. Chapitre 4 4.3.5. Effectuer un virement : L’abonné a éventuellement la possibilité d’effectuer des virements, soit de l’un de ses comptes à un autre, soit vers le compte d’un bénéficiaire inscrits dans le contrat. Figure 17: Choix du type de virement. Virement compte à compte : L’abonné commence par le remplissage d’un formulaire contenant les informations sur le compte à débiter, celui à créditer, le montant, le motif et la date d’exécution du virement. A noter que la date d’exécution du virement peut être différente de la date système, mais strictement supérieure à cette dernière bien entendu. Figure 18: Saisie d’un virement de compte à compte Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 44
  57. 57. Chapitre 4 En cliquant sur le bouton valider, le client reçoit ensuite un récapitulatif du virement effectué et un bouton signer pour confirmer le virement, après avoir entré son mot de passe. Figure 19: Récapitulatif du virement de compte à compte. Après la signature du virement, le client reçoit la confirmation de la réalisation du virement avec succès auprès du serveur. Figure 20: Page de succès d’un virement de compte à compte. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 45
  58. 58. Chapitre 4 Virement vers bénéficiaire : Tout comme le virement de compte à compte, l’abonné commence par le remplissage d’un formulaire contenant tous les informations sur le virement, la différence qui existe est que le compte à créditer appartient à l’un de ses bénéficiaires Figure 21: Saisie d’un virement vers bénéficiaire Il reçoit ensuite un récapitulatif du virement effectué afin de signer pour confirmer le virement. Figure 22: Récapitulatif d’un virement vers bénéficiaire Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 46
  59. 59. Chapitre 4 Après avoir virement. signé le virement, un écran de succès s’affiche pour annoncer la fin du Figure 23: Ecran de succès d’un virement vers bénéficiaire. 4.3.6. Demander un chéquier : L’abonné rempli le formulaire de la demande :     Le Compte à débiter Le nombre de chéquier(s) Le type des chéquier(s) Le moyen de remise du/des chéquier(s) Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 47
  60. 60. Chapitre 4 Figure 24: Demande de chéquier. Après le remplissage du formulaire, l’abonné envoie les informations saisies au serveur en cliquant sur le boutant « envoyer », puis une requête de réponse sera renvoyée par le serveur vers le mobile pour afficher à l’utilisateur les informations déjà saisie, et lui donner la possibilité de rectifier avant de signer et confirmer. Figure 25: Demande de chéquier(2). Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 48
  61. 61. Chapitre 4 Figure 26: Demande de chéquier avec succès. 4.3.7. Transférer de l’argent : L’abonné saisit le compte à débiter parmi ses comptes, le montant et le motif du transfert ainsi que les informations concernant le bénéficiaire :  Nom et prénom  Type de la pièce d’identité  Numéro de la pièce d’identité  Adresse  Ville et pays  Téléphone Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 49
  62. 62. Chapitre 4 Figure 27: Saisie d’un transfert d’argent. Après avoir rempli les champs et validé le formulaire le client reçoit un récapitulatif de cette demande de transfert. Figure 28: Récapitulatif d’un transfert d’argent. 4.3.8. Les Tâches : L’abonné peut consulter à chaque instant les différentes tâches qu’il désire effectuer, pour les valider en les signant, par exemple on voit dans l’imprimé d’écran suivant quelques tâches à savoir : « Demande de virement vers bénéficiaire », « demande d’opposition sur chèque », « demande de recharge d’une carte », … qui sont déjà remplis dans les champs appropriés. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 50
  63. 63. Chapitre 4 Figure 29: Liste des tâches. 4.3.9. Liste des comptes titres: L’abonné peu consulter la situation et toutes les informations sur son compte à savoir : Numéro du compte, l’agence, numéro de la clé, la date d’ouverture le solde et le totale. Et d’autres informations supplémentaires. Figure 30: Situation des comptes titre. La suite de la Situation des comptes : Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 51
  64. 64. Chapitre 4 Figure 31: Transaction titre et portefeuille titre. 4.3.10. Consultation des effets : L’utilisateur ou l’abonné commence d’abord par le choix de type de l’effet à consulter. Quatre catégories d’effets sont offertes : -Les effets à payer. -Les effets à encaisser par compte. -Les effets à encaisser par date d’échéance. -Les remises d’effets à encaisser. Figure 32: Choix de type d’effet. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 52
  65. 65. Chapitre 4 -Les effets à payer : Cette fonctionnalité permet à l’abonné de recevoir une liste dans laquelle figure les comptes tirés, le montant total et le nombre des effets. Figure 33: Les comptes tirés. Quand l’utilisateur clique sur un compte, le serveur lui renvoie la liste des effets à payer. Chaque sous liste contient des informations sur le compte tiré, la date d’échéance, le nom du tireur et le montant tiré. Figure 34: La liste des effets à payer. -Les effets à encaisser : C’est le cas où le porteur de l’effet garde ce dernier dans son portefeuille jusqu'à l’échéance puis il le présente soit à sa banque pour encaissement (effet domicilié) ou au tiré ou bien au souscripteur pour l’encaissement. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 53
  66. 66. Chapitre 4 Ce type d’effets regroupe deux sous catégories : les effets à encaisser par compte et les effets à encaisser par date d’échéance. -Les effets à encaisser par compte : Le serveur renvoie au client dans ce cas une liste contenant des informations sur les comptes tireurs, le montant total et le nombre des effets. Figure 35: Les comptes tireurs. Quand l’utilisateur clique sur un compte, le serveur lui renvoie la liste des effets à encaisser. Chaque sous liste contient des informations sur le compte tiré, la date d’échéance, le nom du tireur et le montant tiré. Figure 36: Les effets à encaisser par compte. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 54
  67. 67. Chapitre 4 -Les effets à encaisser par date d’échéance : Au lieu que le serveur renvoie les compte tireurs comme le cas précèdent, il renvoie cette fois les dates d’échéance, les montants totaux et les nombres des effets. Figure 37: Les effets à encaisser par dates d’échéance. De la même façon que pour le cas précédent, le serveur renvoie, la liste des effets à encaisser qui ont la même date d’échéance. Les sous listes contiennent les mêmes informations. -Les remises d’effets à encaisser : Si l’abonné choisit cette option, il verra une liste contenant des informations sur le numéro de remise, le nombre des effets et le montant total. Figure 38: Les effets à encaisser par compte. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 55
  68. 68. Chapitre 4 Dans ce cas le serveur renvoie, la liste des effets à encaisser qui ont la même date d’échéance. Les sous listes contiennent les mêmes informations que pour le cas précédent. 4.3.11. Situation des crédits : Pour chaque dossier de crédit, l’abonné peut consulter plusieurs informations à savoir : nom du dossier, nom de celui qui remboursera le crédit, le statut s’il est réglé ou bien en cours, date blocage ou date de dernier échéance …. Figure 39: Liste des dossiers. Figure 40: Contenu d’un dossier avec liste des impayés. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 56
  69. 69. Chapitre 4 4.3.12. Liste des impayés : Le client peut aussi consulter la liste de ses impayés. Ainsi, le serveur renvoie la liste des informations suivante pour chaque lise des impayées.      La date d’échéance. Le montant impayé. Le montant frais impayé. Le montant d’échéance. Le statut. Figure 41: La liste des impayés. 4.3.13. Géolocalisation : La géolocalisation ou géo-référencement est un procédé permettant de positionner une personne ou un objet (guichet dans notre cas) sur une carte à l'aide de ses coordonnées géographiques. Ici on a utilisé les deux coordonnées la longitude et l’altitude récupérées à partir du GPS. On a mis en œuvre la carte mappy, car la carte de Google Map touche l’union de notre cher pays. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 57
  70. 70. Chapitre 4 Figure 42: géolocalisation. 4.4. Déploiement: 4.4.1. Les dangers du reverse engineering: Le reverse engineering est une technique permettant de reconstituer le code source d'une application à partir de sa forme compilée. La possession du code source permet de connaître le fonctionnement précis d'une application. Face aux risques liés au reverse engineering, nous nous sommes vu contraint de choisir une technique qui permettrait de cacher le code source de l’application, puisqu’il est facile de décoder le fichier exécutable. Il en existe quatre :     l'obfuscation transforme le code source avant compilation de manière à le rendre illisible pour l'être humain. (voir annexe) le chiffrement assure la confidentialité totale du code source tant que l'algorithme de chiffrement n'a pas été cassé et que la clé n'a pu être trouvée par force brute l'exécution de code distant permet de ne livrer aux clients qu'une partie de l'application, les portions sensibles sont conservées sur un serveur distant protégé sur lequel elles s'exécutent le code natif protégé est un code compilé pour une architecture matérielle très spécifique, rendant difficile l'utilisation d'un décompilateur adapté 4.4.2. Déploiement sur mobile: Après avoir réalisé l’application sous forme d’un site web, il vient le tour du Framework PhoneGap qui va s’occuper d’empaqueter le code source à l’aide de son service PhoneGap Build, intégré dans l’outil Adobe Dreamweaver (voir l’Annexe), et ainsi de générer les fichiers permettant le déploiement de l’application sur différentes plateformes. Le schéma de ce processus est représenté ci-dessous. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 58
  71. 71. Chapitre 4 Figure 43: processus du service phoneGap Build. Les figures suivantes montrent dans l’ordre la réalisation de ce processus de manière pratique. Figure 44: L'IDE Adobe Dream weaver Figure 45: fenêtre de phonegap build Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 59
  72. 72. Chapitre 4 Figure 46: démarrage du service phonegap build. Figure 47: connexion au service phonegap build Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 60
  73. 73. Chapitre 4 Figure 48: génération des fichiers exécutables. Conclusion: Ce chapitre avait pour but de décrire l’environnement technique et les différentes étapes de la réalisation du projet. En effets nous avons choisi les technologiques pour l'implémentation de l'application et finalement nous avons présenté quelques écran décrivant les fonctionnalités de notre application. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 61
  74. 74. Conclusion : En guise de conclusion, nous pouvons affirmer que le développement multiplateforme mobile est un domaine enrichissant au niveau expérimental et qu’il est en évolution constante. Ce stage a été pour nous l’occasion de faire le lien entre nos connaissances académiques et le monde professionnel. Il nous a permis de développer nos compétences techniques, d’approfondir nos connaissances théoriques et les mettre en pratique. Cette expérience a aiguisé nos capacités d’analyse et de synthèse, et nous a permis de renforcer nos connaissances concernant le développement mobile ainsi que le développement hybride. Après la réalisation technique du projet avec le framework Phone Gap, nous constatons que toutes les fonctionnalités réalisées sont fonctionnelles sur le mobile. Ce projet était une occasion pour mieux comprendre et apprendre des notions ayant une relation avec le domaine bancaire considéré comme l'un des domaines sensibles. Cette dernière considération nous a excités de traiter le sujet avec précaution en termes de sécurité. Enfin, ce stage fut une expérience très enrichissante pour nous sur les deux plans personnels et professionnels. En effet, il a été l’occasion de découvrir le dynamisme et l’enthousiasme qui caractérisent l’équipe d'INFOSAT. Les réunions régulières effectuées avec les encadrants à INFOSAT nous ont permis de mettre en œuvre les concepts de gestion de projets acquis à l'INPT. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 62
  75. 75. Glossaire:  A App Store : Plateforme de téléchargement d’applications. Aptana : Aptana Studio est un environnement de développement intégré orienté web, multiplate-forme et open-source.  D Debugger : Est un logiciel qui aide un développeur à analyser les bugs d'un programme.  G Google Play : Plateforme de téléchargement d’applications.  I IBM : International Business Machines Corporation, connue sous l’abréviation IBM, est une société multinationale américaine présente dans les domaines du matériel informatique, du logiciel et des services informatiques.  L Lotus Domino : Lotus Domino est un produit IBM qui fournit une plateforme de gestion électronique des documents développée en mode open source, qui inclut une messagerie électronique et des applications de travail collaboratif.  M Microsoft Exchange : Microsoft Exchange Server est un Groupware (logiciel de groupe de travail) pour serveur de messagerie électronique créé par Microsoft, pour concurrencer Lotus Domino d'IBM. Mobile information device profile : Désigné par l'acronyme MIDP, est un profil J2ME utilisé par certains téléphones.  P Pattern : Le mot anglais « pattern » est souvent utilisé pour désigner un modèle, une structure, un motif, un type, etc. Ruby On Rails: Ruby on Rails, également appelé RoR ou Rails est un framework web libre écrit en Ruby  S Système multitâche : Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 63
  76. 76. Un système d'exploitation est multitâche en anglais: multi-task s’il permet d’exécuter, de façon apparemment simultanée, plusieurs programmes informatiques. On parle également de multiprogrammation.  T Tag : Langage de balisage HTML.  W Widgets : Widget est une contraction des mots window et gadget. En informatique, le mot widget recouvre deux notions distinctes en relation avec les interfaces graphiques. Il peut alors être considéré comme étant la contraction des termes window (fenêtre) et gadget.  X XCode : Est un environnement de développement pour Mac OS X. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 64
  77. 77. Bibliographie : David Powers. Adobe Dreamweaver CS5.5 Studio Techniques: Designing and Developing for Mobile with jQuery, HTML5, and CSS3. JQuery Community Experts. JQuery Cookbook : Solutions & Examples for jQuery developpers. Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 65
  78. 78. Webographie: PhoneGap Google Group, Getting Started Guide: http://docs.phonegap.com/en/2.0.0/guide_getting-started_index.md.html. Appcelerator, Titanium Studio: http://www.appcelerator.com/platform/titanium-studio Appcelerator, Titanium Documentation: http://docs.appcelerator.com/titanium/2.1/index.html Comparing Titanium and PhoneGap: http://developer.appcelerator.com/blog/2012/05/comparingtitanium-and-phonegap.html GitHub, Appcelerator: http://github.com/appcelerator GitHub, PhoneGap: http://github.com/phonegap La rédaction journal du Net, Les outils de développement multiplateforme mobiles : http://www.journaldunet.com/developpeur/outils/les-outils-de-developpement-multi-plateformemobile/ [publié le 03/11/2011] http://www.wikipedia.com KONLAMBIGUE Tyab. PhoneGap vs Appcelerator: http://fr.slideshare.net/kcresus/phonegap-vsappcelerator PETITIT François. Applications mobiles multiplateformes: les approches PhoneGap et Titanium Mobile : http://blog.octo.com/applications-mobiles-multi-plateformes-les-approches-phonegap-ettitanium-mobile/ [publié le 17/10/2012] Ekito, Application mobile : web ou natif : http://www.ekito.fr/portail/application-mobile-web-ounatif Tout JavaScript: http://www.toutjavascript.com/reference/reference.php?ref=String http://www.w3schools.com/ jQuery Mobile: http://mobile.jquery-fr.com/index.html Introducing JSON: http://www.json.org/ jQuery: http://www.jquery.com/ Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 66
  79. 79. Annexe: Adobe Dreamweaver: Dreamweaver est un éditeur de site web WYSIWYG pour Microsoft Windows, et Mac OS X créé en 1997, commercialisé par Macromedia puis Adobe Systems sous licence utilisateur final. Dreamweaver fut l'un des premiers éditeurs HTML de type « tel affichage, tel résultat », mais également l'un des premiers à intégrer un gestionnaire de site (CyberStudio GoLive étant le premier). Ces innovations l'imposèrent rapidement comme l'un des principaux éditeurs de site web, aussi bien utilisable par le néophyte que par le professionnel. Depuis le rachat de Nitobi Software (développeur d’Apache Cordova) par Adobe Systems le 4 Octobre 2011, ce dernier est désormais le propriétaire de Phonegap. Suite à ça, Adobe a intégré phoneGap dans l’outil Adobe Dreamweaver (depuis la version cs5.5). HTML 5: HTML5 (HyperText Markup Language 5) est la prochaine révision majeure d'HTML (format de données conçu pour représenter les pages web). Cette version est en développement en 2012. HTML5 spécifie deux syntaxes d'un modèle abstrait défini en termes de DOM : HTML5et XHTML5. Le langage comprend également une couche application avec de nombreuses API, ainsi qu'un algorithme afin de pouvoir traiter les documents à la syntaxe non conforme. Le travail a été repris par le W3C en mars 2007 après avoir été lancé par le WHATWG (Web Hypertext Application Technology Working Group). Les deux organisations travaillent en parallèle sur le même document afin de maintenir une version unique de la technologie. Le W3C vise la clôture des ajouts de fonctionnalités le 22 mai 2011 et une finalisation de la spécification en 2014, et encourage les développeurs Web à utiliser HTML 5 dès maintenant. HTML5 présente plusieurs changements par rapport HTML 4.X et XHTML 1.X concernant les spécifications, le Doctype et l’encodage. De plus HTML5 a apporté de nouveaux éléments et de nouveaux attributs.   Spécifications : Les spécifications sont publiées par leW3C http://www.w3.org/TR/html5/. Doctype : Tout comme les pages HTML ou XHTML, les documents HTML5 nécessitent une déclaration Doctype indiquant la méthode standard de rendu par le navigateur. Toutefois, pour les documents XML cette déclaration est facultative, le navigateur l'interprétant en mode standard par défaut. Pour utiliser la structure XML il faut préciser dans le header : « Content-Type: application/xhtml+xml ». Projet de fin d’étude – ELKECHA Brahim & OUARRICH Said - 2012/2013 67

×