SlideShare une entreprise Scribd logo

Conception et developpement d'une application mobile Android e-location

A
ALALSYSE

La quatrième année d'études en Informatique (Maitrise Informatique) à l'UFR des Sciences Appliquées et Technologie de l'Université Gaston Berger de Saint Louis du Sénégal se termine par un mémoire. Il sera l'occasion pour l'étudiant de montrer qu'il a acquis une connaissance non seulement théorique mais aussi pratique de ces conventions. Ainsi dans ce travail de fin de la maitrise en informatique, on a voulu associer trois grandes activités qui sont, à la base, très éloignées l'une de l'autre mais qui, avec l'amélioration croissante des nouvelles technologies, sont vouées à être fusionnées. Il s'agit de la programmation mobile Android, le NOSQL et les services web. Notre défi est donc de réaliser un projet innovant, utile et lié à l’actualité. Nous devons développer une application mobile Android e-location. D'où l'objet de la rédaction du présent rapport

1  sur  52
Télécharger pour lire hors ligne
République du Sénégal
Un Peuple - Un But - Une foi
********************
MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE
UNIVERSITÉ GASTON BERGER DE SAINT-LOUIS
__________________
U.F.R DE SCIENCES APPLIQUÉES ET DE TECHNOLOGIE
___________________
Mémoire de Maitrise Informatique
Sujet : ‹‹ Conception et développement d’une application Android e-location››
Réalisé par :
Aly SECK
Sous l’encadrement de :
Pr Moussa LO (UGB)
Année académique : 2014/2015 N° d’ordre :
1
Nous vivons encore aujourd’hui au Sénégal avec cette idée, de moins en moins
justifiée et de plus en plus arrogante, que notre capacité d’innovation, en raison de
l’excellence de nos enseignants, de nos chercheurs et de nos ingénieurs, et de la qualité de
nos infrastructures, serait bien supérieure à celle des pays du Nord et de l’Est. Souvenez-vous
de la suffisance avec laquelle, au moment de la crise pétrolière, nous déclarions : “Nous
n’avons pas de pétrole mais nous avons des idées.” Il faut se rendre à l’évidence : nous
n’avons toujours pas de pétrole, mais nous ne sommes plus seuls à avoir des idées et des
capacités à les exploiter sous la forme d’applications concrètes au bénéfice du développement
économique et social. Voilà la nouveauté. Il s’agit d’un changement radical et irréversible
auquel nous devrons nous adapter.
2
Table des matières
AVANT-PROPOS.......................................................................................................................................... 6
INTRODUCTION GENERALE .......................................................................................................................... 7
CHAPITRE 1 : ETAT DE L’ART DES SOLUTIONS E-LOCATION ............................................................................. 8
INTRODUCTION .......................................................................................................................................... 8
I. DESCRIPTION DE L’EXISTANT ............................................................................................................... 9
I.1 KAYMU ............................................................................................................................................ 9
I.2 LAMUDI............................................................................................................................................ 9
I.3 EXPAT-DAKAR .................................................................................................................................. 9
II. LES LIMITES DE L’EXISTANT.................................................................................................................. 9
II.1 RESPONSIVE WEB DESIGN ................................................................................................................. 9
II.2 MENU COMPLEXE .......................................................................................................................... 10
III. NOTRE SOLUTION ........................................................................................................................ 10
CONCLUSION............................................................................................................................................ 10
CHAPITRE 2 : CAPTURE DES BESOINS.......................................................................................................... 10
INTRODUCTION .................................................................................................................................... 10
I. LES ACTEURS ................................................................................................................................ 11
I.1 L’ADMINISTRATEUR......................................................................................................................... 11
I.2 LE CLIENT ....................................................................................................................................... 11
I.3 LE FOURNISSEUR DE SERVICES .......................................................................................................... 11
II. LES DIAGRAMMES ........................................................................................................................ 11
II.1 DIAGRAMMES DE CONTEXTE ........................................................................................................... 12
II.2 DIAGRAMME DE USE CASE .............................................................................................................. 12
CONCLUSION........................................................................................................................................ 13
CHAPITRE 3 : ANALYSES DES BESOINS ........................................................................................................ 14
INTRODUCTION .................................................................................................................................... 14
I. ANALYSE DU CAS D’UTILISATION « CREER COMPTE»............................................................... 14
I.1 DESCRIPTION .................................................................................................................................. 14
II. ANALYSE DU CAS D’UTILISATION « CONTACTER FOURNISSEUR» .................................................. 15
II.1 DESCRIPTION................................................................................................................................. 15
II.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « CONTACTER UN FOURNISSEUR D’OFFRES » ....... 16
III. ANALYSE DU CAS D’UTILISATION « RETIRER UNE OFFRE»............................................................... 17
III.1 DESCRIPTION................................................................................................................................ 17
III.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « RETIRER UNE OFFRE » .............................. 18
3
IV. ANALYSE DU CAS D’UTILISATION « PROPOSER UNE OFFRE»........................................................... 19
IV.1 DESCRIPTION................................................................................................................................ 19
IV.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « PROPOSER UNE OFFRE»................................. 19
CONCLUSION ............................................................................................................................................ 20
CHAPITRE 4 : IMPLEMENTATION................................................................................................................ 21
INTRODUCTION ........................................................................................................................................ 21
I. ENVIRONNEMENT MATERIEL ....................................................................................................... 21
II. TECHNOLOGIES.................................................................................................................................. 21
II.1 NIVEAU 1 : LE CLIENT ANDROID............................................................................................................. 21
II.2 NIVEAU 2 : LE SERVEUR WEB ................................................................................................................. 22
1. POINT SUR LES SERVICES WEB.......................................................................................................... 22
POURQUOI CHOISIR SOAP ..................................................................................................................... 23
POURQUOI CHOISIR REST ?.................................................................................................................... 23
2. BACKEND AVEC GOOGLE APP ENGINE( GAE) .................................................................................... 24
 PRESENTATION.......................................................................................................................... 24
 L’ENVIRONNEMENT D’EXECUTION JAVA ........................................................................................ 24
 LA BASE DE DONNEES (DATASTORE)............................................................................................. 24
 GOOGLE CLOUD ENDPOINTS....................................................................................................... 25
 DESCRIPTION ET ARCHITECTURE DE LA SOLUTION A DEVELOPPER....................................................... 26
 LA SOLUTION A DEVELOPPER ....................................................................................................... 26
3. LA CREATION DU SERVEUR ET SA MISE EN PLACE : COTE SERVEUR ........................................................ 27
 CREER LE SERVEUR APP ENGINE................................................................................................... 27
 CREER L’APPLICATION ET LES WEB SERVICES................................................................................... 27
 LES DIFFERENTES COUCHES DE L’APPLICATION ................................................................................ 30
 L’ARCHITECTURE EN COUCHES DE L’APPLICATION APP ENGINE.......................................................... 31
II.3 NIVEAU 3: LE SERVEUR DE BASE DE DONNEES........................................................................................... 32
II.3.1 LE DATASTORE: NOTRE SERVEUR DE BASE DE DONNEES NOSQL .......................................................... 34
A. DESCRIPTION............................................................................................................................. 34
B. LE DATASTORE N’EST PAS UNE BASE DE DONNEES RELATIONNELLE .................................................... 34
C. FONCTIONNEMENT .................................................................................................................... 34
D. MANIPULER LES DATASTORE AVEC OBJECTIFY................................................................................... 39
E. MISE EN CACHE AVEC MEMCACHE ................................................................................................. 43
F. LES TRANSACTIONS...................................................................................................................... 44
III. CONCEPTION DE L’APPLICATION....................................................................................................... 45
IV. QUELQUES COMPOSANTES APPLICATIVES REALISEES ............................................................... 45
4
CONCLUSION ............................................................................................................................................ 48
CONCLUSION ET PERSPECTIVES .................................................................................................................. 49
Références bibliographiques............................................................................................................... 51
5
Liste des figures
Figure 1: Diagramme de contexte e-location........................................................................................ 12
Figure 2: Diagramme de case d’utilisations général ............................................................................. 13
Figure 3: Diagramme de séquence du cas d’utilisation « créer compte »............................................ 15
Figure 4: Diagramme de séquence du cas d’utilisation « contacter un fournisseur ».......................... 17
Figure 5: Diagramme de séquence du cas d’utilisation « retirer une offre » ....................................... 18
Figure 6: Diagramme de séquence du cas d’utilisation « retirer une offre » ....................................... 19
Figure 7: Un seul backend Endpoints avec plusieurs clients (Android, IOS, Firefox) .......................... 25
Figure 8: Architecture de la solution à développer............................................................................... 26
Figure 9: Model en couches de l'application à développer................................................................... 31
Figure 10: L'architecture de l'application App Engine (le backend)..................................................... 31
Figure 11: LE SERVEUR DE BASE DE DONNEES: les possibilités offertes par GAE................................. 32
Figure 12: Tableau comparatif SQL vs NoSQL ....................................................................................... 33
Figure 13: Fonctionnement du Datastore avec Objectify ..................................................................... 40
Figure 14: Exécution d'une requête dans le Datastore......................................................................... 44

Recommandé

PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementNassim Bahri
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile Raoua Bennasr
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Ayoub Mkharbach
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRouâa Ben Hammouda
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiDonia Hammami
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachAyoub Mkharbach
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiquejihene Ab
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 

Contenu connexe

Tendances

Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebHarrathi Mohamed
 
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Anas Riahi
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Ben Abdelwahed Slim
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESTombariAhmed
 
Conception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRConception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRSkander Driss
 
Présentation resto
Présentation restoPrésentation resto
Présentation restoMehdi Labidi
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...mouafekmazia
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Nawres Farhat
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATSiwar GUEMRI
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITLina Meddeb
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Addi Ait-Mlouk
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Karim Ben Alaya
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...Hajer Dahech
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
présentation soutenance PFE
présentation soutenance PFEprésentation soutenance PFE
présentation soutenance PFEHeithem Moumni
 
Projet de fin d’études
Projet de fin d’études  Projet de fin d’études
Projet de fin d’études TombariAhmed
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaNazih Heni
 

Tendances (20)

Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site Web
 
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
 
Rapport PFE
Rapport PFERapport PFE
Rapport PFE
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
Conception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRConception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIR
 
Présentation resto
Présentation restoPrésentation resto
Présentation resto
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
Présentation PFE
Présentation PFEPrésentation PFE
Présentation PFE
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
présentation soutenance PFE
présentation soutenance PFEprésentation soutenance PFE
présentation soutenance PFE
 
Projet de fin d’études
Projet de fin d’études  Projet de fin d’études
Projet de fin d’études
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 

Similaire à Conception et developpement d'une application mobile Android e-location

En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...nuntiis
 
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdfMrShady1
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Codendi
 
La strategie regionale d'innovation la reunion
La strategie regionale d'innovation la reunionLa strategie regionale d'innovation la reunion
La strategie regionale d'innovation la reunionSilicon Village
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRaef Ghribi
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Oussama Ben Sghaier
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMohamed Arar
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Houssem Eddine Jebri
 
Mise en place solution de communication Unifiée avec SIPXCOM
Mise en place solution de communication Unifiée avec SIPXCOMMise en place solution de communication Unifiée avec SIPXCOM
Mise en place solution de communication Unifiée avec SIPXCOMbamaemmanuel
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Mohamed Aziz Chetoui
 
Quelle stratégies le marché de l'information professionnelle doit-il adopter ...
Quelle stratégies le marché de l'information professionnelle doit-il adopter ...Quelle stratégies le marché de l'information professionnelle doit-il adopter ...
Quelle stratégies le marché de l'information professionnelle doit-il adopter ...Caroline LIJKO
 
Rapport d'activité 2010 de l'Institut Télécom
Rapport d'activité 2010 de l'Institut TélécomRapport d'activité 2010 de l'Institut Télécom
Rapport d'activité 2010 de l'Institut TélécomInstitut Télécom
 
Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010CLES-FACIL
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD) Ben Ahmed Zohra
 
Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0ACDISIC
 
Livre blanc : nouveaux usages de la veille
Livre blanc : nouveaux usages de la veilleLivre blanc : nouveaux usages de la veille
Livre blanc : nouveaux usages de la veilleAref Jdey
 
Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Digimind
 
Le livre blanc des systemes embarques
Le livre blanc des systemes embarquesLe livre blanc des systemes embarques
Le livre blanc des systemes embarquesHichem Bensenouci
 

Similaire à Conception et developpement d'une application mobile Android e-location (20)

En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
En association avec le CEFRIO et HEC Montréal, le CIGREF délivre les résultat...
 
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
 
La strategie regionale d'innovation la reunion
La strategie regionale d'innovation la reunionLa strategie regionale d'innovation la reunion
La strategie regionale d'innovation la reunion
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Mise en place solution de communication Unifiée avec SIPXCOM
Mise en place solution de communication Unifiée avec SIPXCOMMise en place solution de communication Unifiée avec SIPXCOM
Mise en place solution de communication Unifiée avec SIPXCOM
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
Quelle stratégies le marché de l'information professionnelle doit-il adopter ...
Quelle stratégies le marché de l'information professionnelle doit-il adopter ...Quelle stratégies le marché de l'information professionnelle doit-il adopter ...
Quelle stratégies le marché de l'information professionnelle doit-il adopter ...
 
Rapport annuel2010
Rapport annuel2010Rapport annuel2010
Rapport annuel2010
 
Rapport d'activité 2010 de l'Institut Télécom
Rapport d'activité 2010 de l'Institut TélécomRapport d'activité 2010 de l'Institut Télécom
Rapport d'activité 2010 de l'Institut Télécom
 
Technocles2010 1
Technocles2010 1Technocles2010 1
Technocles2010 1
 
Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0
 
Livre blanc : nouveaux usages de la veille
Livre blanc : nouveaux usages de la veilleLivre blanc : nouveaux usages de la veille
Livre blanc : nouveaux usages de la veille
 
Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008
 
Le livre blanc des systemes embarques
Le livre blanc des systemes embarquesLe livre blanc des systemes embarques
Le livre blanc des systemes embarques
 

Conception et developpement d'une application mobile Android e-location

  • 1. République du Sénégal Un Peuple - Un But - Une foi ******************** MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE UNIVERSITÉ GASTON BERGER DE SAINT-LOUIS __________________ U.F.R DE SCIENCES APPLIQUÉES ET DE TECHNOLOGIE ___________________ Mémoire de Maitrise Informatique Sujet : ‹‹ Conception et développement d’une application Android e-location›› Réalisé par : Aly SECK Sous l’encadrement de : Pr Moussa LO (UGB) Année académique : 2014/2015 N° d’ordre :
  • 2. 1 Nous vivons encore aujourd’hui au Sénégal avec cette idée, de moins en moins justifiée et de plus en plus arrogante, que notre capacité d’innovation, en raison de l’excellence de nos enseignants, de nos chercheurs et de nos ingénieurs, et de la qualité de nos infrastructures, serait bien supérieure à celle des pays du Nord et de l’Est. Souvenez-vous de la suffisance avec laquelle, au moment de la crise pétrolière, nous déclarions : “Nous n’avons pas de pétrole mais nous avons des idées.” Il faut se rendre à l’évidence : nous n’avons toujours pas de pétrole, mais nous ne sommes plus seuls à avoir des idées et des capacités à les exploiter sous la forme d’applications concrètes au bénéfice du développement économique et social. Voilà la nouveauté. Il s’agit d’un changement radical et irréversible auquel nous devrons nous adapter.
  • 3. 2 Table des matières AVANT-PROPOS.......................................................................................................................................... 6 INTRODUCTION GENERALE .......................................................................................................................... 7 CHAPITRE 1 : ETAT DE L’ART DES SOLUTIONS E-LOCATION ............................................................................. 8 INTRODUCTION .......................................................................................................................................... 8 I. DESCRIPTION DE L’EXISTANT ............................................................................................................... 9 I.1 KAYMU ............................................................................................................................................ 9 I.2 LAMUDI............................................................................................................................................ 9 I.3 EXPAT-DAKAR .................................................................................................................................. 9 II. LES LIMITES DE L’EXISTANT.................................................................................................................. 9 II.1 RESPONSIVE WEB DESIGN ................................................................................................................. 9 II.2 MENU COMPLEXE .......................................................................................................................... 10 III. NOTRE SOLUTION ........................................................................................................................ 10 CONCLUSION............................................................................................................................................ 10 CHAPITRE 2 : CAPTURE DES BESOINS.......................................................................................................... 10 INTRODUCTION .................................................................................................................................... 10 I. LES ACTEURS ................................................................................................................................ 11 I.1 L’ADMINISTRATEUR......................................................................................................................... 11 I.2 LE CLIENT ....................................................................................................................................... 11 I.3 LE FOURNISSEUR DE SERVICES .......................................................................................................... 11 II. LES DIAGRAMMES ........................................................................................................................ 11 II.1 DIAGRAMMES DE CONTEXTE ........................................................................................................... 12 II.2 DIAGRAMME DE USE CASE .............................................................................................................. 12 CONCLUSION........................................................................................................................................ 13 CHAPITRE 3 : ANALYSES DES BESOINS ........................................................................................................ 14 INTRODUCTION .................................................................................................................................... 14 I. ANALYSE DU CAS D’UTILISATION « CREER COMPTE»............................................................... 14 I.1 DESCRIPTION .................................................................................................................................. 14 II. ANALYSE DU CAS D’UTILISATION « CONTACTER FOURNISSEUR» .................................................. 15 II.1 DESCRIPTION................................................................................................................................. 15 II.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « CONTACTER UN FOURNISSEUR D’OFFRES » ....... 16 III. ANALYSE DU CAS D’UTILISATION « RETIRER UNE OFFRE»............................................................... 17 III.1 DESCRIPTION................................................................................................................................ 17 III.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « RETIRER UNE OFFRE » .............................. 18
  • 4. 3 IV. ANALYSE DU CAS D’UTILISATION « PROPOSER UNE OFFRE»........................................................... 19 IV.1 DESCRIPTION................................................................................................................................ 19 IV.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « PROPOSER UNE OFFRE»................................. 19 CONCLUSION ............................................................................................................................................ 20 CHAPITRE 4 : IMPLEMENTATION................................................................................................................ 21 INTRODUCTION ........................................................................................................................................ 21 I. ENVIRONNEMENT MATERIEL ....................................................................................................... 21 II. TECHNOLOGIES.................................................................................................................................. 21 II.1 NIVEAU 1 : LE CLIENT ANDROID............................................................................................................. 21 II.2 NIVEAU 2 : LE SERVEUR WEB ................................................................................................................. 22 1. POINT SUR LES SERVICES WEB.......................................................................................................... 22 POURQUOI CHOISIR SOAP ..................................................................................................................... 23 POURQUOI CHOISIR REST ?.................................................................................................................... 23 2. BACKEND AVEC GOOGLE APP ENGINE( GAE) .................................................................................... 24  PRESENTATION.......................................................................................................................... 24  L’ENVIRONNEMENT D’EXECUTION JAVA ........................................................................................ 24  LA BASE DE DONNEES (DATASTORE)............................................................................................. 24  GOOGLE CLOUD ENDPOINTS....................................................................................................... 25  DESCRIPTION ET ARCHITECTURE DE LA SOLUTION A DEVELOPPER....................................................... 26  LA SOLUTION A DEVELOPPER ....................................................................................................... 26 3. LA CREATION DU SERVEUR ET SA MISE EN PLACE : COTE SERVEUR ........................................................ 27  CREER LE SERVEUR APP ENGINE................................................................................................... 27  CREER L’APPLICATION ET LES WEB SERVICES................................................................................... 27  LES DIFFERENTES COUCHES DE L’APPLICATION ................................................................................ 30  L’ARCHITECTURE EN COUCHES DE L’APPLICATION APP ENGINE.......................................................... 31 II.3 NIVEAU 3: LE SERVEUR DE BASE DE DONNEES........................................................................................... 32 II.3.1 LE DATASTORE: NOTRE SERVEUR DE BASE DE DONNEES NOSQL .......................................................... 34 A. DESCRIPTION............................................................................................................................. 34 B. LE DATASTORE N’EST PAS UNE BASE DE DONNEES RELATIONNELLE .................................................... 34 C. FONCTIONNEMENT .................................................................................................................... 34 D. MANIPULER LES DATASTORE AVEC OBJECTIFY................................................................................... 39 E. MISE EN CACHE AVEC MEMCACHE ................................................................................................. 43 F. LES TRANSACTIONS...................................................................................................................... 44 III. CONCEPTION DE L’APPLICATION....................................................................................................... 45 IV. QUELQUES COMPOSANTES APPLICATIVES REALISEES ............................................................... 45
  • 5. 4 CONCLUSION ............................................................................................................................................ 48 CONCLUSION ET PERSPECTIVES .................................................................................................................. 49 Références bibliographiques............................................................................................................... 51
  • 6. 5 Liste des figures Figure 1: Diagramme de contexte e-location........................................................................................ 12 Figure 2: Diagramme de case d’utilisations général ............................................................................. 13 Figure 3: Diagramme de séquence du cas d’utilisation « créer compte »............................................ 15 Figure 4: Diagramme de séquence du cas d’utilisation « contacter un fournisseur ».......................... 17 Figure 5: Diagramme de séquence du cas d’utilisation « retirer une offre » ....................................... 18 Figure 6: Diagramme de séquence du cas d’utilisation « retirer une offre » ....................................... 19 Figure 7: Un seul backend Endpoints avec plusieurs clients (Android, IOS, Firefox) .......................... 25 Figure 8: Architecture de la solution à développer............................................................................... 26 Figure 9: Model en couches de l'application à développer................................................................... 31 Figure 10: L'architecture de l'application App Engine (le backend)..................................................... 31 Figure 11: LE SERVEUR DE BASE DE DONNEES: les possibilités offertes par GAE................................. 32 Figure 12: Tableau comparatif SQL vs NoSQL ....................................................................................... 33 Figure 13: Fonctionnement du Datastore avec Objectify ..................................................................... 40 Figure 14: Exécution d'une requête dans le Datastore......................................................................... 44
  • 7. 6 AVANT-PROPOS La quatrième année d'études en Informatique (Maitrise Informatique) à l'UFR des Sciences Appliquées et Technologie de l'Université Gaston Berger de Saint Louis du Sénégal se termine par un mémoire. Il sera l'occasion pour l'étudiant de montrer qu'il a acquis une connaissance non seulement théorique mais aussi pratique de ces conventions. Ainsi dans ce travail de fin de la maitrise en informatique, on a voulu associer trois grandes activités qui sont, à la base, très éloignées l'une de l'autre mais qui, avec l'amélioration croissante des nouvelles technologies, sont vouées à être fusionnées. Il s'agit de la programmation mobile Android, le NOSQL et les services web. Notre défi est donc de réaliser un projet innovant, utile et lié à l’actualité. Nous devons développer une application mobile Android e-location. D'où l'objet de la rédaction du présent rapport
  • 8. 7 INTRODUCTION GENERALE Le Sénégal est un pays qui compte 14 993 125 [1] habitants et 43,68% [2] de la population vivent dans les villes, principalement dans la capitale. Cette concentration de la population dans les villes comme Dakar est due essentiellement au facteur économique. Parce que, là se trouve la majeure partie des activités industrielles et commerciales mais aussi les plus grandes infrastructures administratives et sanitaires. Ceci engendre un sérieux problème de logements des populations qui y vivent. Face à cette situation, les bailleurs investissent dans le domaine de la location, une activité lucrative. Ils proposent des offres de locations et alors un autre problème se pose: la communication et/ou la publicité. Dans ce secteur, d’une part, le citadin se demande comment trouver un bon logement satisfaisant à ses besoins, un logement qui le convient à merveille. Et d’autre part, le propriétaire de logements se demande comment trouver un preneur rapidement pour sa location. Face à cette situation, il est nécessaire de trouver quelque chose qui peut mettre en rapport le citadin avec le bailleur que nous appelons le fournisseur d’offres de locations, à faire passer son information à ceux qui sont à la recherche d’une location, les clients. Donc une plateforme qui va permettre à ces clients de trouver le logement de ses rêves en mettant à leur disposition non seulement des informations sur le marché immobilier, mais aussi en les mettant en contact avec les fournisseurs d’offres de locations. L’application Android e-location doit être la solution escomptée. E-location sera destinée à deux utilisateurs: d’une part un fournisseur qui propose des offres de location via son compte dans l'application, il donne toutes les informations concernant l'offre : photo, adresse, position géographique, prix. D’autre part un client qui, grâce à l'application, pourra voir les offres proposées, avec options de recherche par ville, par quartier, par type d’appartement (simple, R+1 ou R+2 …), et d’autres options pertinentes. Traditionnellement, la première phase dans la réalisation d’un projet est de percevoir les fonctionnalités qu’offrira notre application afin de définir un plan de conception évident pour chacune, et discerner quels types d’utilisateurs pourront utiliser notre produit. E-location n’échappera pas cette règle et de plus nous débuterons ce travail par une étude préalable des solutions existantes pour ensuite passer à la conception et à la réalisation de notre application. Ainsi ce présent rapport sera structuré en quatre (4) chapitres : Dans le premier chapitre « Etat de l’art des solutions e-location », nous décrivons des solutions existantes à savoir leurs philosophies ainsi que les limites de ces solutions. Et enfin, nous critiquons l’existant et proposons une solution. Dans le second chapitre intitulé «Capture des besoins », nous identifions les acteurs du futur système, les besoins fonctionnels et non fonctionnels ainsi que les diagrammes de cas d’utilisation et de contexte. Dans le troisième chapitre « Analyse des besoins», nous faisons une analyse détaillée et complète des cas d’utilisation repérés à travers le chapitre «Capture des besoins». Nous élaborons ensuite une conception détaillée des cas d’utilisation et les diagrammes de séquence. Dans le dernier chapitre intitulé « Implémentation », nous présentons l’environnement matériel et logiciel, les technologies utilisées le passage vers le NOSQL, les services web, le cloud
  • 9. 8 Google App Engine et quelques-uns de ses APIs. Nous terminons ce chapitre par donner quelques composantes applicatives réalisées Enfin, nous clôturons ce mémoire par une conclusion dans laquelle nous résumons notre solution et ensuite nous exposons quelques perspectives. CHAPITRE 1 : ETAT DE L’ART DES SOLUTIONS E-LOCATION INTRODUCTION Avec l’avancée des technologies et la concurrence entre les entreprises, des applications sont développées pour solutionner le problème décrit plus haut. Quelques-unes d’entre elles sont les plus utilisées dans notre pays. Il s’agit de Kaymu, Lamudi Sénégal, Expat-Dakar. Dans cette
  • 10. 9 partie nous allons d’abord essayer de décrire ces solutions. Ensuite nous identifions les limites de ces solutions. Nous concluons enfin cette partie par une description de notre solution. I. DESCRIPTION DE L’EXISTANT I.1 KAYMU Kaymu est considéré comme la communauté de shopping en ligne n° 1 au Sénégal [3]. Il Nous offrons une plateforme de rencontre entre acheteurs et vendeurs mais ne possédant pas de stock de marchandises. Les fondateurs sont portés par l’idée que l’Internet est en mesure d’effacer les barrières économiques et de faire progresser les pratiques du commerce tel que nous le connaissons. Ils ont pour objectif d’inviter le e-commerce dans la vie des africains, de valoriser l’activité des entrepreneurs locaux en les aidant à développer leurs magasins en ligne, et de rendre le shopping facile et accessible à tous. I.2 LAMUDI Lamudi [4] permet de trouver le logement, le terrain ou le local commercial de ses rêves. Leur rôle est de vous aider à trouver la résidence idéale et de faire le lien avec l’agent immobilier mandaté par le propriétaire du bien immobilier. I.3 EXPAT-DAKAR Expat-Dakar est un grand espace de vente, d’achat et d’échanges d’objets neufs ou d’occasions pour particuliers et professionnels [5]. Expat-dakar.com est un lieu dans lequel les utilisateurs peuvent échanger de l’information. Il ne fournit ni ne vend l’information et les produits ou services décrits dans les annonces du site. Chaque jour, plusieurs centaines d’annonces sont publiées sur le site, dans 47 catégories différentes. Celles-ci vont des objets plus courants (véhicules, vêtements, mobiliers, appareils électroniques...) aux objets de collection (antiquités, masques, œuvres d’art, tableaux...). II. LES LIMITES DE L’EXISTANT Les solutions décrites plus haut sont soit des sites mobiles ou des applications. Par site mobile on entend un site internet classique mais optimisé pour s’afficher aussi sur votre téléphone. Et par application, nous retenons que c’est un logiciel entièrement créé pour être visible uniquement sur un smartphone. Voyons à présent quelques limites des solutions existantes : II.1 RESPONSIVE WEB DESIGN Depuis quelques années c’est une tendance que nous constatons: les applications web mobiles sont de plus en plus prisées aux dépens des applications natives. L’avènement relativement récent du responsive web design a beaucoup joué, car il permet de transformer l’apparence du site en fonction des capacités d’affichage du terminal, via les media queries de CSS 3. Cela signifie que c’est la même application web qui s’affiche que ça soit sur ordinateur ou sur smartphone. Il n’y a donc pas à redévelopper. Ce pendant au lieu de développer une application conçue entièrement pour une plateforme spécifique (Android, iPhone, Windows Phone, Klif), les développeurs ont tendance à faire ce qu’on appelle « adaptation du site original » ceci laisse des inconvénients à l’utilisation : la plupart du temps, les utilisateurs se trouvent dans l'obligation de télécharger de manière inutile un code HTML/CSS [10]. De même, les images sont souvent simplement allongées et non redimensionnées entrainant un impact négatif sur le
  • 11. 10 temps de chargement. D'autre part, le Responsive Design ne permet pas d'ajuster facilement les titres, descriptions et autres contenus sur les téléphones mobiles. De plus, Il oblige à un chargement de tous les éléments constituant la page pouvant trahir une performance moindre. II.2 MENU COMPLEXE Ces solutions que nous venons de décrire ne sont pas juste des applications ou sites mobiles pour location de logements mais elles sont des communautés de shopping en ligne qui, de plus, proposent des offres de logements dans le marché. On peut trouver des produits dans toute sorte de catégories (beauté, santé, hygiène, mode, accessoires,…). Ainsi plusieurs fonctionnalités sont offertes à l’utilisateur, avec des options parfois intitules pour ce dernier. De plus le client aura du mal à faire la recherche et donc n’obtient guère le logement escompté. Ce qu’il lui fallait c’était quelque chose plus simple à utiliser, très innovante, utile, liée à l’actualité et qui satisfasse les utilisateurs. III. NOTRE SOLUTION Ce que nous proposons c’est quelque chose plus simple à utiliser, une application e-location, destinée à deux utilisateurs un fournisseur d’offres et un client, qui non seulement offre les fonctionnalités classiques (recherche de logement (en vente ou en location), contacter un fournisseur d’offres, proposer des offres) mais de plus qui vous recommande des offres de locations selon votre position (GPS). Et mieux encore plus léger si on utilise les mobiles et plus facile de transmettre des données entre différentes plates-formes. La suite vous aidera à mieux comprendre. CONCLUSION Dans cette partie nous avons pu faire une étude sur les solutions qui existent au Sénégal à savoir leurs statuts et leurs limites. Nous avons ensuite proposé notre solution. Ce qui prépare le terrain à une capture des futurs besoins qui seront étudiés et modélisés dans le chapitre suivant. CHAPITRE 2 : CAPTURE DES BESOINS INTRODUCTION La capture des besoins consiste à recueillir (on dit aussi capturer) les besoins des utilisateurs des actuelles ou futur. Pour cela, des modèles, à base de graphiques ou de scénarios, et des logiciels ont été élaborés. Nous allons maintenant vous présenter les acteurs qui utiliseront notre application, les fonctionnalités qu’ils pourront entreprendre, et notre système
  • 12. 11 d’information en général. Tout cela, de façon à comprendre clairement comment nous avons perçu ce projet. I. LES ACTEURS Vue la description du projet nous pouvons distinguer trois acteurs externes : un administrateur, un client et un fournisseur de service. I.1 L’ADMINISTRATEUR Ce type d’utilisateur sera mis en place afin de gérer les offres, les inscriptions et les demandes. Il pourra gérer l’ensemble des comptes fournisseurs, contacter un fournisseur. Il pourra modifier une offre en la mettant à jour ou en la supprimant. I.2 LE CLIENT En effet, l’application e-location est destinée à être accessible pour tout visiteur souhaitant connaître les biens à louer ou acheter dans une région désirée. e-location est censée faire la promotion des offres de locations, et inciter l’utilisateur à s’intéresser à un ou plusieurs offres. Ce même client pourra contacter un fournisseur de services, faire des recherches et même s’inscrire afin d’avoir accès à des fonctionnalités plus avancées comme la proposition d’une offre (en vente ou en location). I.3 LE FOURNISSEUR DE SERVICES Le fournisseur de service possède les mêmes droits qu’un client. En plus il peut proposer une offre et même retirer sa proposition. Le diagramme ci-dessous fait apparaitre les différents acteurs du système et leurs principales interactions avec celui-ci. II. LES DIAGRAMMES
  • 13. 12 II.1 DIAGRAMMES DE CONTEXTE Figure 1: Diagramme de contexte e-location II.2 DIAGRAMME DE USE CASE Chaque usage que les acteurs font du système est représenté par un cas d’utilisation. Chaque cas d’utilisation représente une fonctionnalité qui leur est offerte afin de produire le résultat attendu. Ainsi, « le diagramme de cas d’utilisation décrit l’interaction entre le système et l’acteur en déterminant les besoins de l’utilisateur et tout ce que doit faire le système pour l’acteur ». Ci-dessous le diagramme de cas d’utilisation général de notre système: l’objectif visé est le suivi d’un bien (offres de location) de sa proposition à sa validation ou l’annulation.
  • 14. 13 Figure 2: Diagramme de case d’utilisations général Résumé: Notre application doit permettre : A. Au client de rechercher ou consulter un bien, de s’inscrire dans le système et même de contacter un fournisseur. B. Au Fournisseur de service, de proposer un bien (vente ou location), consulter un bien, de s’inscrire dans le système et même de contacter un autre fournisseur. C. A l’administrateur de valider un compte client, de retirer une offre et de contacter un fournisseur. CONCLUSION Ce chapitre nous a permis de faire un découpage fonctionnel de notre futur système par le biais du diagramme de cas d’utilisation et d’anticiper sur les interfaces qui seront développées ultérieurement. Dans le chapitre suivant, nous présentons une analyse détaillée pour les cas d’utilisation de notre système.
  • 15. 14 CHAPITRE 3 : ANALYSES DES BESOINS INTRODUCTION Dans ce présent chapitre, nous nous proposons d’analyser les différents cas d’utilisation que nous venons de repérer à travers l’activité de capture des besoins afin de déterminer les différentes classes intervenant dans chacun des cas et de repérer le séquencement des flux pour chaque scénario de réalisation. I. ANALYSE DU CAS D’UTILISATION « CREER COMPTE» I.1 DESCRIPTION
  • 16. 15 I.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « CREER COMPTE » Figure 3: Diagramme de séquence du cas d’utilisation « créer compte » II. ANALYSE DU CAS D’UTILISATION « CONTACTER FOURNISSEUR» II.1 DESCRIPTION
  • 17. 16 II.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « CONTACTER UN FOURNISSEUR D’OFFRES »
  • 18. 17 Figure 4: Diagramme de séquence du cas d’utilisation « contacter un fournisseur » III. ANALYSE DU CAS D’UTILISATION « RETIRER UNE OFFRE» III.1 DESCRIPTION
  • 19. 18 III.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « RETIRER UNE OFFRE » Figure 5: Diagramme de séquence du cas d’utilisation « retirer une offre »
  • 20. 19 IV. ANALYSE DU CAS D’UTILISATION « PROPOSER UNE OFFRE» IV.1 DESCRIPTION IV.2 DIAGRAMME DE SEQUENCES DU CAS D’UTILISATION « PROPOSER UNE OFFRE» Figure 6: Diagramme de séquence du cas d’utilisation « retirer une offre »
  • 21. 20 CONCLUSION Comme nous pouvons le constater, l’activité d’analyse a permis de livrer une spécification complète des besoins issus du diagramme de cas d’utilisation, de les structurer sous une forme qui facilite la compréhension et qui ébauche vers l’activité de conception. Cette dernière, par les diagrammes de séquences, va beaucoup être utile dans la partie d’implémentation de notre application. Ce qui va être le prochain chapitre.
  • 22. 21 CHAPITRE 4 : IMPLEMENTATION INTRODUCTION Dans ce chapitre, nous présentons l'architecture sur laquelle nous avons développé notre application, les différents outils utilisés ainsi que les composantes applicatives réalisées. I. ENVIRONNEMENT MATERIEL E-location est une application embarquée qui se connecte à un serveur distant de bases de données, via internet, afin de récupérer les données. Ce qui nécessite aussi l’intégration d’un serveur web entre l’application client et le serveur de base de données. D’où l’architecture de notre application est à 3 niveaux (Architecture 3-tiers), elle est partagée entre : Le client Android : Conteneur d’application et demandeur de ressources, Le serveur Web : Vue que les données serons communiquées entre deux environnements hétérogènes, le rôle principale du serveur web est de gérer la communication entre le client Android et le serveur de base de données, Le serveur de base de données fournis les données au serveur web. II. TECHNOLOGIES E-location est une application est destinée à deux utilisateurs un fournisseur d’offres et un client. Donc e-location est une application communicante, l’envoi et la récupération de donné sont les fonctions indispensables. Comme nous l’avons dit e-location est une application à trois niveaux qui nécessite chacun des technologies bien particuliers. II.1 NIVEAU 1 : LE CLIENT ANDROID Ce niveau est moins complexe que les autres. Pour réaliser notre Android nous avons utilisé les technologies suivantes :  ANDROID STUDIO Android Studio est un nouvel environnement pour développement et programmation entièrement intégré qui a été récemment lancé par Google pour les systèmes Android. Il a été conçu pour fournir un environnement de développement et une alternative à Eclipse qui est l'IDE le plus utilisé.  ANDROID SDK Android SDK, c'est le nom de code pour le kit de développement (SDK = Software Development Kit) de Google pour développer les applications qui tourneront sur le nouveau- futur OS de la prochaine génération de téléphones mobiles... conçu par Google (et l'Open Handset Alliance). Le pack proposé inclut l'ensemble des APIs et outils nécessaires pour un développement complet d'applications. Le kit permet de tester le tout.
  • 23. 22  ANDROID Quand on pense à Android, on pense immédiatement à Google, et pourtant il faut savoir que cette multinationale n'est pas à l'initiative du projet. D'ailleurs, elle n'est même pas la seule à contribuer à plein temps à son évolution. À l'origine, « Android » était le nom d'une PME américaine, créée en 2003 puis rachetée par Google en 2005, qui avait la ferme intention de s'introduire sur le marché des produits mobiles. La gageure, derrière Android, était de développer un système d'exploitation mobile plus intelligent, qui ne se contenterait pas uniquement de permettre d’envoyer des SMS et transmettre des appels, mais qui devait permettre à l'utilisateur d'interagir avec son environnement (notamment avec son emplacement géographique). C'est pourquoi, contrairement à une croyance populaire, il n'est pas possible de dire qu'Android est une réponse de Google à l'iPhone d'Apple, puisque l'existence de ce dernier n'a été révélée que deux années plus tard. C'est en 2007 que la situation prit une autre tournure. À cette époque, chaque constructeur équipait son téléphone d'un système d'exploitation propriétaire. Chaque téléphone avait ainsi un système plus ou moins différent. Ce système entravait la possibilité de développer facilement des applications qui s'adapteraient à tous les téléphones, puisque la base était complètement différente. Un développeur était plutôt spécialisé dans un système particulier et il devait se contenter de langages de bas niveaux comme le C ou le C++. De plus, les constructeurs faisaient en sorte de livrer des bibliothèques de développement très réduites de manière à dissimuler leurs secrets de fabrication. En janvier 2007, Apple dévoilait l'iPhone, un téléphone tout simplement révolutionnaire pour l'époque. L'annonce est un désastre pour les autres constructeurs, qui doivent s'aligner sur cette nouvelle concurrence. Le problème étant que pour atteindre le niveau d'iOS (iPhone OS), il aurait fallu des années de recherche et développement à chaque constructeur... C'est pourquoi est créée en novembre de l'année 2007 l'Open Handset Alliance (OHA), et qui comptait à sa création 35 entreprises évoluant dans l'univers du mobile, dont Google. Cette alliance a pour but de développer un système open source (c'est-à-dire dont les sources sont disponibles librement sur internet) pour l'exploitation sur mobile et ainsi concurrencer les systèmes propriétaires, par exemple Windows Mobile et iOS. Cette alliance a pour logiciel vedette Android, mais il ne s'agit pas de sa seule activité. L'OHA compte à l'heure actuelle 80 membres. II.2 NIVEAU 2 : LE SERVEUR WEB 1. POINT SUR LES SERVICES WEB La méthode la plus répandue de se connecter à une base de données MySQL à distance à partir d'un appareil Android, est de mettre une sorte de service dans le milieu. MySQL est habituellement utilisé avec PHP, donc la façon la plus simple et le plus évident d'écrire des scripts PHP pour gérer la base de données et exécuter ces scripts en utilisant le protocole HTTP du système Android. Mais cela suppose que notre application est destinée seulement à un client spécifique. Pourquoi cette limite ? Pourquoi pas un client IOS ou encore un client web ? Les services Web sont devenus, depuis quelque temps, la norme de facto pour intégrer des applications internes ou offrir une interface externe aux clients. Un service web est un élément de logique applicative informatique distribué permettant l’échange de données entre applications et systèmes hétérogènes. C’est un objet avec un langage, c’est une classe avec des
  • 24. 23 méthodes qui peuvent être appelés à distance. Il est plus facile de transmettre des données entre différentes plates-formes en utilisant ce moyen; plus facile de composer le message, plus facile à déboguer, plus facile à comprendre. Alors un client développé avec n’importe quel langage peut faire des appels aux méthodes du service web via des requêtes SOAP, REST, ou bien même XML-RPC. Ainsi nous pouvons intégrer des parties du système écrites en Java, .NET, PHP, ANDROID, IOS, etc. en utilisant un protocole bien connu et des messages textes (généralement en XML). Dès lors plusieurs technologies sont à notre disposition, il nous faut donc faire un tri. Nous mettons d’un côté SOAP et XML-RPC qui permettent de transporter l’information XML à travers d’une encapsulation XML. D’un autre côté, plaçons REST qui est plus une philosophie du web et qui, pour résumer, propose de faire beaucoup plus simple que les services traditionnels. POURQUOI CHOISIR SOAP En effet SOAP présente beaucoup d’avantages : -Simple et extensible ; -Adaptable à différents protocoles de transport ; -Basé sur XML, il est indépendant des plates-formes cliente et serveur ; Mais si on ne s’en tient qu’à cette liste, SOAP est fortement concurrencé par les autres formes de services plus souples comme REST ou tout simplement par tous les mécanismes requête/réponse sur http. En ajoutant le point noir de SOAP, à savoir qu’il s’agit d’un protocole très verbeux et parfois assez gourmand en ressources, beaucoup le déconseillent sur une plate-forme telle qu’Android, qui proposera un environnement contraint sur des appareils mobiles. Enfin, même si sortis de la boite Android ils ne proposent pas de fonctionnalités pour manipuler SOAP. POURQUOI CHOISIR REST ? REST est léger et simple : les messages sont courts, faciles à décoder par le navigateur et par le serveur d’application. REST est auto-descriptif : vous pouvez naviguer à travers ses ressources comme vous le feriez avec une page Web. Il y a une URL intuitive unique pour chaque ressource. On peut facilement en déduire la structure des ressources sans avoir besoin de beaucoup de documentation. REST est « stateless » (il n’est pas adapté aux transactions longues et complexes) : il est parfait pour les opérations simples (créer, lire, mettre à jour, effacer). REST peut être géré en cache (antémémoire) : les ressources simples, identifiables sont aussi faciles à mettre en cache qu’un article sur un site Internet. L’adaptation aux variations de charge et la performance que cela apporte ne doivent pas être négligées. REST n’est pas limité à XML: beaucoup d’implémentations utilisent JSON, un format encore plus léger, moins verbeux.
  • 25. 24 2. BACKEND AVEC GOOGLE APP ENGINE( GAE) PRESENTATION App Engine est une plateforme PaaS, qui permet de créer des applications Web à l'aide des technologies Java, Python ou encore JavaScript et de les exécuter sur l'architecture évolutive de Google. App Engine permet de développer en toute simplicité des applications qui s'exécutent de manière fiable, même lorsqu'elles sont surchargées et doivent faire face à des volumes de données importants. App Engine comprend les fonctionnalités suivantes :  diffusion Web dynamique, avec prise en charge intégrale des technologies Web courantes ;  stockage permanent avec requêtes, tri et transactions ;  équilibrage des charges et évolutivité automatique ;  API qui permet d'authentifier les utilisateurs et d'envoyer des e-mails via Google Accounts ;  un environnement de développement local complet qui simule Google App Engine sur votre ordinateur ;  des files d'attente de tâches qui permettent d'effectuer du travail en dehors du champ d'une requête Web ;  des tâches planifiées qui déclenchent les événements aux moments spécifiés ou à intervalles réguliers. App Engine dispose d'un ensemble riche de services pour faciliter le développement d'applications qui seront hébergées dans le Cloud de Google. Pour notre travail, nous allons utiliser l'environnement d'exécution Java (JRE), la base de données (Datastore), et les outils Google Cloud EndPoints. L’ENVIRONNEMENT D’EXECUTION JAVA L'environnement d'exécution Java d'App Engine fournit une machine virtuelle qui supporte Java 8 et permet l'exécution des applications dans un environnement Cloud sécurisé (sandbox). Le Runtine Java de la plateforme offre également une interface Servlet Java et la prise en charge de l’interface standard avec le magasin de données et les services évolutifs App Engine tels que JDO (Java Data Objects), JPA (Java Persistence API), JavaMail et JCache. La prise en charge des normes facilite le développement des applications et permet de porter celles-ci vers et depuis votre propre environnement de servlets. LA BASE DE DONNEES (DATASTORE) App Engine fournit un service performant de stockage distribué de données qui comprend un moteur de recherche et la gestion des transactions. En même temps que les serveurs Web distribués augmentent avec votre trafic, la base de données grossit avec vos données. Le Datastore App Engine n'est pas comme une base de données relationnelle traditionnelle. Les objets de données ou « entités » ont des propriétés. Les recherches peuvent retourner des entités selon un filtre donné et les trier selon les propriétés de leurs valeurs.
  • 26. 25 Les entités Datastore n'ont pas de schéma. La structure de données des entités est fournie et mise en place par le code de l'application. Les interfaces JDO/JPA incluent les dispositifs pour mettre en place la structure à l'intérieur de l'application. L'application peut aussi accéder au Datastore directement pour mettre en place une structure répondant plus précisément aux besoins du développeur. Le Datastore implémente les transactions à travers son réseau distribué en utilisant des « groupes d'entités ». Une transaction manipule des entités à l'intérieur d'un simple groupe. Les entités du même groupe sont enregistrées ensemble par souci d'efficacité d'exécution des transactions. GOOGLE CLOUD ENDPOINTS Pour faciliter le développement d'applications mobiles utilisant App Egine, Google a développé un ensemble d'API connu sous le nom de « Cloud Endpoints ». Cloud Endpoints permet de définir la logique métier sur App Engine et d'y accéder via des API RESTful ou RPC (Remote Procedure Call) sur de multiples plateformes, y compris Android, iOS et sur le Web (JavaScript). Cloud Endpoints est construit en utilisant l'infrastructure de Google API, ce qui facilite l'interopérabilité avec des services Google. Cloud Endpoints a été construit pour simplifier la tâche aux développeurs [8], en permettant un développement flexible et agile. Il permet de :  libérer le développeur des travaux complexes de rédaction et de maintenance de code pour les interactions et les protocoles client-serveur ;  générer du code optimisé pour les opérations CRUD ;  faciliter la création des API personnalisées (REST ou RPC). Figure 7: Un seul backend Endpoints avec plusieurs clients (Android, IOS, Firefox) Cloud EndPoints est un outil qui offre souplesse et simplicité au développeur qui souhaite créer une application sur App Engine, dont les fonctionnalités seront exploitées par divers clients, quelle que soit leur plateforme exécution.
  • 27. 26 DESCRIPTION ET ARCHITECTURE DE LA SOLUTION A DEVELOPPER La solution que nous allons mettre sur pied sera constituée de deux applications. Une application App Engine qui fera office de Backend et une application Android qui sera le client (frontend). Les données seront stockées sur le Datastore d'App Engine. Le diagramme de composants ci-dessous permet d'avoir une idée plus précise sur les composants de notre solution et son architecture physique et statistique. Figure 8: Architecture de la solution à développer LA SOLUTION A DEVELOPPER Deux étapes pour obtenir le résultat escompté :  la création du serveur et sa mise en place
  • 28. 27  la création de l'application Android pour le côté client et des Web services côté serveur à l'aide de Restlet. 3. LA CREATION DU SERVEUR ET SA MISE EN PLACE : COTE SERVEUR Tout d'abord nous allons créer notre serveur App Engine. Nous nous occuperons ensuite de l'application web que nous déploierons sur le serveur App Engine. Enfin, nous mettrons en place les Webservices Restlet. CREER LE SERVEUR APP ENGINE Pour créer le serveur App Engine, il suffit de vous connecter sur https://appengine.google.com/ à l'aide de votre compte Google et suivre les options. Vous disposez de 10 applications gratuites. CREER L’APPLICATION ET LES WEB SERVICES On crée l’application sous Android studio en créant un nouveau projet. Ensuite il nous faut ajouter un nouveau module (Google Cloud Module) dans l’application. Android Studio nous donne une intégration directe avec App Engine. Grâce à Android Studio, nous pouvons générer automatiquement les bibliothèques Cloud Endpoints client nécessaires pour accéder au backend ainsi que des classes pour notre serveur. Il faut alors commencer à définir nos nouvelles classes. Et pour chaque classe d'entité, vous devez générer une classe de Cloud Endpoints pour donner à notre client l'accès aux données de l'application backend.
  • 29. 28 Dès que le module backend est ajouté à notre projet et à synchroniser Gradle finitions, une nouvelle configuration d'exécution avec le nom du module de votre backend doit être créé: Pour nous assurer que notre backend démarré avec succès, accédons à http: // localhost: 8080. Si tout va bien, nous devrions voir la page suivante:
  • 30. 29 Il reste à connecter notre application Android client avec le backend. Il vous suffit de faire une requête HTTP. L'extrait de code suivant illustre comment créer un AsyncTask qui rend la requête HTTP pour le backend et imprime le résultat chaîne entrant vers un toast dans un contexte donné: class ServletPostAsyncTask extends AsyncTask<Pair<Context, String>, Void, String> { private Context context; @Override protected String doInBackground(Pair<Context, String>... params) { context = params[0].first; String name = params[0].second; HttpClient httpClient = new DefaultHttpClient(); HttpPost httpPost = new HttpPost("http://10.0.2.2:8080/hello"); // 10.0.2.2 //l’adresse ip de l’emulateur Android try { // Add name data to request List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>(1); nameValuePairs.add(new BasicNameValuePair("name", name)); httpPost.setEntity(new UrlEncodedFormEntity(nameValuePairs));
  • 31. 30 Enfin, nous avons besoin d'invoquer cette AsyncTask d'un de nos activités Android. Par exemple, pour exécuter de la classe MainActivity, ajoutons le code suivant à la méthode LES DIFFERENTES COUCHES DE L’APPLICATION L'application Android sera constituée des couches suivantes :  la couche présentation (IHM - Interface Homme Machine) : elle correspond à la partie visible de l'application. La couche présentation relaie les requêtes de l'utilisateur à destination de la couche métier, et en retour lui présente les informations renvoyées par les traitements de cette couche ;  la couche métier (BLL - Business Logic Layer) : la couche métier sera utilisée pour développer toute la logique métier de l'application Android. Elle est intercalée entre l'IHM et la bibliothèque App Engine Client Lib, et permettra d'effectuer toutes les manipulations de données nécessaires en fonction des requêtes effectuées par les utilisateurs au travers de la couche présentation ;  App Engine Backend Client Lib : cette couche fournit un accès simplifié à l'application serveur hébergée sur App Engine via Google Cloud Endpoints ;  le modèle objets : le modèle ici représente les ressources qui seront manipulées par notre application et notre API. // Execute HTTP Post Request HttpResponse response = httpClient.execute(httpPost); if (response.getStatusLine().getStatusCode() == 200) { return EntityUtils.toString(response.getEntity()); } return "Error: " + response.getStatusLine().getStatusCode() + " " + response.getStatusLine().getReasonPhrase(); } catch (ClientProtocolException e) { return e.getMessage(); } catch (IOException e) { return e.getMessage(); } } @Override protected void onPostExecute(String result) { Toast.makeText(context, result, Toast.LENGTH_LONG).show(); } } MainActivity.onCreate=new ServletPostAsyncTask().execute(new Pair<Context, String>(this, "elocation"));
  • 32. 31 Figure 9: Model en couches de l'application à développer L’ARCHITECTURE EN COUCHES DE L’APPLICATION APP ENGINE Les différentes couches que nous allons utiliser pour cette application sont les suivantes :  les classes Endpoints : les classes Endpoints représentent en quelque sorte la couche d'accès aux données. Les méthodes que chaque classe Endpoint possède permettent d'insérer, mettre à jour et supprimer les objets dans le Datastore ;  le modèle objets : le modèle ici représente les ressources qui seront manipulées par les classes Endpoint Figure 10: L'architecture de l'application App Engine (le backend)
  • 33. 32 II.3 NIVEAU 3: LE SERVEUR DE BASE DE DONNEES II.3.1 DESCRIPTION Nous avons l'habitude de stocker deux types de fichiers :  Stocker des informations : on a très régulièrement besoin d'enregistrer des informations. Ça peut être le nom d'un nouveau membre, un message qu'il laisse, une commande qu'il effectue sur l’application...  Stocker des fichiers : on a parfois besoin de stocker de nouveaux fichiers, que ce soient des images, des .zip, etc. Ces fichiers sont le plus souvent uploadés par les utilisateurs du site web. Pour répondre à ces besoins, Google App Engine fournit différents services :  Pour le stockage d'informations, on a en général besoin d'une base de données. C'est en effet le moyen le plus sûr et le plus structuré pour "ranger" les informations. Google App Engine propose 2 types de bases de données : o Une base de données relationnelle SQL : c'est le service Google Cloud SQL. Il s'agit en fait d'une base de données MySQL gérée en Cloud. o Une base de données non relationnelle NoSQL : c'est le service Datastore. Il est basé sur Big Table, le système de stockage créé par Google pour ses propres services pour des besoins de performance (qui a d'ailleurs lui-même inspiré en bonne partie le mouvement NoSQL). Figure 11: LE SERVEUR DE BASE DE DONNEES: les possibilités offertes par GAE Si on adapte une application qui existe déjà et dans laquelle on a utilisé une base de données relationnelle comme MySQL, il est inutile de tout changer. Il faut utiliser la base de données relationnelle Google Cloud SQL.
  • 34. 33 Si on est curieux de découvrir une nouvelle façon de stocker les données, qu’on a toujours entendu parler de NoSQL mais qu’on n’a jamais eu l'occasion de s’y mettre, essayez-vous au Datastore. Voici un petit tableau comparatif SQL vs NoSQL : Fonctionnalité SQL (ex : MySQL) NoSQL (ex : Datastore) Avantage Scalabilité multi-serveurs Limité à un serveur principal pour les écritures. Pour avoir plus de puissance en écriture il faut un plus gros serveur. Multi-serveurs par défaut, pas de limitations. La charge est aisément répartie sur plusieurs serveurs. NoSQL Structuration des données Les données sont toujours très structurées dans des tables. Pratique quand on a besoin d'une structure précise. Adapté pour les données en structure arborescente (ex : XML, JSON...) dont la forme peut varier. Dépend des besoins Puissance du langage SQL Permet d'effectuer des requêtes complexes et précises (parfois assez lentes). Permet d'effectuer seulement des requêtes simples, mais rapides. SQL Schéma des données Le schéma est contraignant : vous devez absolument faire "rentrer" les données dans les cases prévues. Avantage : tout est toujours proprement rangé. Le schéma n'est pas contraignant : vous pouvez faire ce que vous voulez, stocker comme vous le voulez. Défaut : il faut vérifier manuellement si tout est bien rangé. Dépend des besoins Transactions Les transactions sont strictes : les données sont immédiatement enregistrées et à jour. Les transactions sont possibles mais cela demande plus de travail. Les données peuvent être enregistrées avec un léger retard. SQL Figure 12: Tableau comparatif SQL vs NoSQL
  • 35. 34 II.3.1 LE DATASTORE: NOTRE SERVEUR DE BASE DE DONNEES NOSQL A. DESCRIPTION Le Datastore est la voie royale pour stocker des données sur Google App Engine [1]. C'est clairement l'outil que Google nous conseille d'utiliser. Vous pouvez vous en servir gratuitement (jusqu'à une certaine limite de trafic) et on ne vous en dit que du bien : il serait rapide, capable de gérer de fortes charges, réparti sur de multiples Datacenter... On dit même qu'il serait basé sur Big Table, la technologie qu'utilise Google pour stocker toutes ses données, notamment les résultats d'indexation des milliards de pages web par le Google Bot. Le Datastore fonctionne en mode High Replication Datastore (HRD). Ce système est très résilient aux erreurs : il fait en sorte que vos données soient copiées sur de multiples Datacenter ! L'objectif est que votre application puisse continuer à fonctionner même en cas d'évènement catastrophique. Si le Datastore est alléchant, il est néanmoins très différent d'une base de données SQL comme MySQL... Pour vous et moi qui sommes habitués aux bases SQL, c'est un changement très important : le Datastore est ce qu'on appelle une base de données NoSQL. En fait beaucoup de gens croient que "NoSQL" est une opposition au SQL, alors que c'est en fait l'acronyme de "Not Only SQL" (pas seulement du SQL). On y reprend des principes de SQL mais pas tous. L'objectif est de se débarrasser de tout ce qui empêche habituellement les sites basés sur SQL de croître avec un fort trafic. B. LE DATASTORE N’EST PAS UNE BASE DE DONNEES RELATIONNELLE Le Datastore est à plusieurs égards beaucoup plus basiques et bas niveau qu'une base de données classique. Il n'utilise pas de tables. Il n'y a pas de schéma SQL : on dit que le Datastore est schemaless (sans schéma). Il faut l’imaginez comme un espace géant prêt à accepter des données, n'importe quelles données. On lui envoie du contenu et il nous le stocke. Quand nous en avons à nouveau besoin, il nous suffit de le lui demander. C. FONCTIONNEMENT Le Datastore peut être utilisé de façon massive, avec beaucoup de données et de requêtes simultanées. Pourtant, à son plus bas niveau, il fonctionne de façon très simple : il accepte des clés et des valeurs. Exactement comme une HashMap [8]. A son niveau le plus basique, le Datastore ressemble donc à ça : Clé : valeur Ex : pseudo Ex : Aly
  • 36. 35 Le Datastore stocke des paires clé-valeur et est capable d’en stocker beaucoup, beaucoup, beaucoup de paires clé-valeur : Si on en tien juste là vous pouvez penser que ce n'est pas structuré ! Ca fait juste un grand bazar ! On ne va quand même pas mélanger des noms de membres, des messages, des commandes...En fait, le Datastore est un peu plus malin que ça. Il vous permet de regrouper les données dans des entités.  Les entités organisent (un peu) les données. Le Datastore a un concept d'entités. C'est ce qui nous aide à structurer les informations. Les entités sont des regroupements d'une ou plusieurs paires clé-valeur. Elles ressemblent à ceci : Le Datastore est aussi capable d'associer les entités entre elles. Une entité peut avoir une entité parente, qui peut elle-même avoir une entité parente, etc. On peut aussi stocker des entités sans parent.
  • 37. 36  Les entités comme des objets: Un élément m'a aidé à bien comprendre le Datastore. Je me suis mis à imaginer que les entités sont comme des objets en Java. Un objet possède plusieurs attributs : ce sont les paires clé-valeur. La clé correspond au nom de l'attribut, et la valeur... à sa valeur. Pour prendre un exemple, imaginons un Fournisseur d'offres. Il possède des attributs : un nom, un numéro de téléphone,…Il possède aussi une offre de location qui a ses propres caractéristiques (id_location, adresse,…) Les entités dans le Datastore pourraient être représentées comme ceci :
  • 38. 37 Fournisseur Location  Comment identifier une entité : Les entités sont des groupes de données qui vivent dans l'espace intersidéral du Datastore. Il peut y en avoir une très grande quantité. Parfois, certaines entités sont reliées entre elles : elles ont une relation de parenté. Les données (paires clé-valeur) au sein des entités sont appelées des propriétés. Celles-ci stockent obligatoirement des données basiques, comme du texte ou des nombres. La doc de Google nous donne tous les types autorisés [11]. Vu qu'il y en a des milliers, des millions voire même des milliards qui vivent au sein du Datastore, il va falloir leur donner un nom unique pour les repérer ! Une fois qu'on aura l'entité, on saura alors facilement lire et modifier toutes ses propriétés. Pour identifier une entité, Google utilise la combinaison de 3 informations :  Un type (kind) : c'est le type de données de votre entité. Par exemple, on peut dire que le type de données de mon fournisseur d’offre est... "Fournisseur". C'est ma classe "Fournisseur".  Un identifiant (identifier) : il peut s'agir soit d'une chaîne de caractères soit d'un nombre. Vous pouvez le définir vous-mêmes ou bien laisser Google générer un nombre pour vous.  Un parent (ancestor path) : si l'entité possède un parent, celui-ci aidera à identifier l'entité de façon unique. Si l'entité ne possède pas de parent, on dit que c'est une entité racine (root). Dans ce cas l'ancestor path vaut null. En résumé : Nom : Aly Téléphone : 77 123 45 67 Id_location : 0078 Adresse : Saint Louis
  • 39. 38 Ex : Fournisseur Ex : Aly Ex : null (pas de parents) Si on le rapportait à notre exemple précédent avec des fournisseurs et des offres, ça donnerait quelque chose de ce genre : Fournisseur : aly : null Location : id_location :(Fournisseur :aly)  Les opérations: Maintenant que nous savons comment le Datastore de Google stocke les entités, il ne nous reste plus qu'une chose à voir avant de commencer à coder : quelles actions peut-on faire sur une telle base ? Il y a 4 opérations de base disponibles dans une base de données NoSQL comme le Datastore [9]  get() : récupère une entité en fonction de son identifiant  put() : écrit une entité (ou en écrase une)  delete() : supprime une entité via son identifiant  query() : retrouve des entités en fonction de certains critères de recherche Nom : Aly Téléphone : 77 123 45 67 Id_location : 0078 Adresse : Saint Louis
  • 40. 39 Avant toute chose, vous devez importer les APIs du Datastore dans votre application : import com.google.appengine.api.datastore.*; Ensuite, vous devez récupérer un objet représentant le service du Datastore. On fait appel à une factory qui nous renvoie l'objet dont nous allons avoir besoin. Cela se fait en une ligne : DatastoreService datastore = DatastoreServiceFactory.getDatastoreService(); Arrivé juste ici alors nous somme prêt à utiliser Datastore. Passons maintenant à la création d’une entité. Pour créer une entité trois opérations sont nécessaires : 1. Créez l'objet représentant l'entité, de type Entity 2. Assignez-lui une ou plusieurs propriétés (ce sont les paires clé-valeur) 3. Demandez l'écriture de l'entité au Datastore avec la méthode put() Essayons de recréer l'entité Fournisseur que j'avais inventée pour vous expliquer le fonctionnement du Datastore : D. MANIPULER LES DATASTORE AVEC OBJECTIFY On vient de le voir : le Datastore est un système puissant mais son API bas niveau est assez délicate à utiliser, notamment son système de requêtes. De l'avis de plusieurs développeurs (y compris des gens de chez Google !), il est recommandé d'utiliser la bibliothèque Objectify pour travailler avec le Datastore aujourd'hui. Contrairement au Datastore lui-même, la lib Objectify n'est pas maintenue par Google lui-même mais par un développeur externe. Objectify est particulièrement suivi et maintenu, c'est donc un excellent choix pour développer avec le Datastore. Objectify se veut être une API "ni trop bas niveau, ni trop haut niveau". Elle (heureusement) plus haut niveau que l'API de base que nous venons de découvrir, mais elle ne nous empêche pas d'effectuer des actions basiques si nécessaire. Objectify est un peu comme un ORM pour le Datastore : son rôle est de persister (stocker) vos objets dans le Datastore. // Crée l'entité de type (kind) "Fournisseur" Entity fournisseur = new Entity("Fournisseur"); // Assigne des propriétés à l'entité fournisseur.setProperty("nom", "Aly"); fournisseur.setProperty("telephone", "777777777" ); // Enregistre l'entité dans le Datastore datastore.put(fournisseur);
  • 41. 40 Figure 13: Fonctionnement du Datastore avec Objectify Objectify s'occupe de la création d'entités et de clés et de la relation entre ces éléments. Mieux: il utilise automatiquement le service Memcache de Google qui permet de mettre en cache des données pour aller encore plus vite et vous éviter d'appeler systématiquement le Datastore. Objectify est suffisamment simple à comprendre et pourtant très puissant. La plupart des vraies applications sur App Engine l'utilisent aujourd'hui. Objectify est une bibliothèque créée par un développeur tiers. Elle n'est pas installée automatiquement avec le plugin App Engine pour Eclipse. Heureusement, son installation et sa configuration sont simples. Le projet Objectify est hébergé sur Google Code à l'adresse suivante : https://github.com/objectify/objectify. i. CREER DES OBJETS PERSISTANTS Comme l'API bas niveau du Datastore, Objectify nous permet d'effectuer des opérations basiques sur les entités via leurs clés :  Ecrire une entité  Récupérer une entité grâce à sa clé  Supprimer une entité grâce à sa clé Nous nous intéressons ici à ces opérations simples. Nous verrons juste après comment effectuer des requêtes, ce qui est un poil plus complexe mais quand même bien plus lisible que l'API bas niveau. Pour travailler avec Objectify, on doit d'abord récupérer son instance. Cela se fait comme ceci: ObjectifyService.ofy() Le principe d'Objectify est que vous pouvez enchaîner plusieurs appels sur cette instance. Par exemple, pour charger un objet en fonction de sa clé on ferait : Objet monObjet = ObjectifyService.ofy().load().key(cle).now(); Comme vous allez devoir écrire ObjectifyService.ofy() de nombreuses fois, il est recommandé d'effectuer une définition statique au début du fichier : import static com.googlecode.objectify.ObjectifyService.ofy; Vous pouvez alors écrire simplement ofy() au lieu de ObjectifyService.ofy(): Objet monObjet = ofy().load().key(cle).now();
  • 42. 41 - ECRIRE UNE ENTITE Objectify travaille sur des objets. La première chose à faire est donc, dans votre servlet, de créer des objets comme vous avez l'habitude de le faire en Java : Fournisseur f = new Fournisseur ("aly", ("77 777 77 77"); Notre Personnage p peut ensuite être persisté dans le Datastore avec cette simple commande : ofy().save().entity(f); // Asynchrone (pas enregistré immédiatement) Par défaut, les sauvegardes sont asynchrones. Cela signifie que le Datastore rend la main à votre programme avant d'avoir enregistré les données. C'est la méthode la plus rapide mais, si vous avez besoin des données que vous venez d'enregistrer immédiatement après, vous voudrez peut- être forcer l'enregistrement de façon synchrone comme c'est le cas en SQL. Pour ça, rajoutez juste un appel à now () à la chaîne : ofy().save().entity(f).now(); // Synchrone (enregistré immédiatement) - RECUPERER UNE ENTITE Pour récupérer une entité, vous devez connaître sa clé. Je vous rappelle qu'une clé est simplement un identifiant constitué du type + de l'ID + du parent. - LES CLES Le Datastore nous fournissait déjà la classe Key qui représente une clé. Cette classe s'utilise comme ceci pour rappel : Key clePersonnage = KeyFactory.createKey("Fournisseur", "aly"); // API bas niveau Mais Objectify fournit une légère variante : la classe Key<?> (qui indique en plus le type d'objet stocké). On peut l'utiliser comme ceci : Key<Fournisseur> cleFournisseur = Key.create(Fournisseur.class, "aly"); Les deux types de clés sont utilisables dans Objectify. A noter qu'il existe aussi le type Ref<?> qui fonctionne comme Key<?> mais qui permet de manipuler les sous-objets plus facilement. ii. CHARGER L'INSTANCE OBJECTIFY - CHARGER UN OBJET GRACE A SA CLE
  • 43. 42 Pour charger un objet, on crée d'abord sa clé (soit avec la classe Key bas niveau du Datastore, soit avec la classe Key<?> d'Objectify) puis on demande son chargement : Key<Personnage> cleFournissseur = Key.create(Fournisseur.class, "aly"); Fournisseur r = ofy().load().key(cleFournisseur).now(); Plus fort que le Roquefort, Objectify nous permet aussi de charger un objet sans passer par l'étape préalable de création d'une clé : Fournisseur r = ofy().load().type(Fournisseur.class).id("aly").now(); Il s'agit juste d'une syntaxe plus pratique créée par Objectify. Elle a le même effet que si vous étiez passés par la création d'une clé. Si on veut récupérer une entité qui a un parent, il faudra ajouter un appel à parent() dans la chaîne comme ceci : Location a = ofy().load().type(Location.class).parent(fournisseur).id("maison").now(); - SUPPRIMER UNE ENTITE En tant que roi du Datastore, vous avez droit de vie et de mort sur vos entités. Il n'y a rien de plus simple : indiquez en paramètre l'objet que vous voulez supprimer du Datastore. ofy().delete().entity(objetASupprimer).now(); Si vous voulez varier les plaisirs, vous pouvez aussi supprimer l'entité via sa clé : ofy().delete().key(cleObjetASupprimer).now(); Ou utiliser la syntaxe offerte par Objectify qui vous évite d'avoir à créer une clé : ofy().delete().type(Fournissuer.class).id("aly").now(); iii. LES REQUETES Exécuter des requêtes avec Objectify est beaucoup plus pratique que l'API bas niveau du Datastore. En fait, la syntaxe de base est la même que le chargement via une clé. Il vous suffit de rajouter des filtres via filter() et d'indiquer que vous voulez qu'on vous retourne une liste avec list(): Retourne tous les fournisseurs dont le nom est aly List<Fourniseur> fournisseur = ofy().load().type(Fournisseur.class).filter(" nom","aly").list(); On peut aussi rechercher parmi les ancêtres via leur clé avec la même méthode :
  • 44. 43 List<Arme> armes = ofy().load().type(Location.class).ancestor(KeyFactory.createKey( "Fournisseur.class", "aly")).list(); Il faut noter que Vous ne pouvez effectuer des requêtes que sur des propriétés indexées par le Datastore. Par défaut Objectify n'indexe pas les attributs des classes, sauf si vous utilisez l'annotation @Index. Vérifiez donc que vous avez correctement défini vos index avant d'effectuer des requêtes ! E. MISE EN CACHE AVEC MEMCACHE App Engine offre un service de Memcache. Pour ceux qui ne connaissent pas Memcache, il s'agit d'un logiciel qui tourne uniquement en mémoire vive (RAM) sur des serveurs et qui stocke des paires clé-valeur. Memcache se révèle en fait un excellent complément au Datastore. Puisqu'il ne nécessite pas d'accéder à des disques, il est beaucoup plus performant que le Datastore (en gros, une requête Memcache va 10 fois plus vite qu'une requête dans le Datastore). On serait tenté de tout mettre dans Memcache mais il ne faut pas oublier que les données peuvent vraiment être perdues à tout moment : si le serveur redémarre tout est perdu et s'il n'y a plus de place en mémoire Memcache supprime arbitrairement de vieilles données en cache. Il faut savoir que le service Memcache chez Google est gratuit. Google veut nous encourager à utiliser intensivement Memcache pour alléger la charge des serveurs du Datastore. Nous n'allons donc pas nous en priver. En pratique, l'utilisation combinée de Memcache et du Datastore se fait comme ceci : 1. On s'apprête à faire une requête dans le Datastore pour récupérer des données 2. On demande d'abord à Memcache s'il possède déjà ces données 3. Si Memcache les possède, on aura récupéré les données 10x plus rapidement et sans passer par le Datastore 4. Si Memcache ne les possède pas, on fait une requête classique au Datastore et on stocke le résultat dans Memcache pour que la prochaine requête aille plus vite.
  • 45. 44 Figure 14: Exécution d'une requête dans le Datastore F. LES TRANSACTIONS Les transactions sont indispensables dans un grand nombre d'applications. Elles vous permettent d'exécuter plusieurs requêtes d'affilée et de vous assurer qu'elles ont bien fonctionné avant de réellement enregistrer les données. Objectify fournit un système très pratique pour effectuer des transactions. On pourrait aussi le faire avec l'API bas niveau. Il y a 2 cas :  Soit votre transaction doit retourner des données (sous forme d'un objet)  Soit votre transaction ne doit pas retourner de données Si la transaction ne doit pas retourner de données, voici comment on l'écrirait avec Objectify : import com.googlecode.objectify.VoidWork; ofy().transact(new VoidWork() { public void vrun() { // Tout ce qui est exécuté dans cette méthode appartient à la même transaction
  • 46. 45 Objet objet = ofy().load().key(cle).now(); /* Modification de l'objet... */ ofy().save().entity(objet); } } Si la transaction doit retourner de données, voici comment on l'écrirait avec Objectify import com.googlecode.objectify.Work; Objet monObjet = ofy().transact(new Work<Objet>() { public Objet run() { Objet objet = ofy().load().key(cle).now(); /* Modification de l'objet... */ ofy().save().entity(objet); return objet; } }); III. CONCEPTION DE L’APPLICATION La création de notre application se fera selon les étapes suivantes :  création de l'application Android ;  génération du Backend App Engine ;  création des classes Entity ;  création des classes Endpoints ;  génération de l'API Client ;  création des méthodes d'accès sous Android ;  test ;  déploiement. On crée l’application avec Android Studio. Ensuite il nous faut ajouter un nouveau module (Google Cloud Module) dans l’application afin de créer notre backend. Le backend créé il nous faut passer à la création des classes Entity qui vont être le model de l’application. Les classes Entity créées, il faut maintenant générer les classes Cloud Endpoints pour chaque classe d'entité et bien sûr des modifications seront faites sur les classes Endpoints. Il ne reste plus qu’à générer l’API client et créer des méthodes d’accès sous Android afin de pouvoir tester l’application et passer au déploiement. IV. QUELQUES COMPOSANTES APPLICATIVES REALISEES Pour plus simplicité dans l’utilisation de l’application E-location, l’interface de l’application doit présenter 2 onglets : un onglet pour la liste de toutes les offres disponibles et l’onglet pour les recommandations. De plus on a un bouton de recherche et un bouton pour ajouter une nouvelle offre. En haut de l’application on a une barre de titre affichant le nom de l’application et un bouton nous conduisant au menu de l’application. L’accueil sera comme suite :
  • 47. 46 Ainsi si on clique sur le menu on obtient l’interface suivant qui nous offre la possibilité de se connecter via son compte Gmail, de créer un compte ou même de sélectionner les offres selon leurs statuts (en location ou en vente)
  • 48. 47 Si l’application est lancée pour la première fois et on clique sur l’option se connecter, l’interface ci-dessous se présente au client Elle lui demande d’autoriser à e-location d’accéder à vos contacts
  • 49. 48 Après avoir accepté la demande, le fournisseur d’offre peut se connecter et ainsi il pourra ajouter une offre. CONCLUSION Cette partie est la partie est plus délicate dans le développement de notre application. Beaucoup de technologies sont utilisés notamment les API de Google App Engine dans la réalisation du backend. Enfin, nous nous intéressons à tester l’application.
  • 50. 49 CONCLUSION ET PERSPECTIVES Notre sujet de mémoire a consisté en la conception et le développement d’une application Android « e-location» afin d’apporter la solution aux problèmes détectés dans le marché immobilier du Sénégal. Dans une dynamique de promouvoir une bonne gestion des ressources et un très bon management moderne, dans un monde où le vent des progrès de la technologie souffle avec force, dans un milieu où les clients utilisent des devises de plateformes différentes (ordinateurs, mobile Android, mobile IOS, mobile Firefox,…), nous avons jugé nécessaire de faire deux applications : une application App Engine qui fera office de Backend et une application Android qui sera le client (frontend). Nous sommes arrivés à développer les fonctionnalités les plus essentielles de l’application backend dans les temps (l’ajout d’une nouvelle offre, la recherche d’une offre, les recommandations suivant la position géographique courante de l’utilisateur) et nous avons pu développer quelques fonctionnalités de l’application client Android. Ce mémoire nous a permis d’approfondir nos connaissances théoriques, acquises tous le long de notre formation, par la pratique des nouvelles technologies. Cette expérience nous a permis de maîtriser le langage de modélisation UML et les outils de développement Android à savoir le SDK Android. Il nous a permis aussi de découvrir les langages comme JSP, XML, JSON. Le mémoire nous a également permis de découvrir comment fonctionne l’architecture 3-tiers. Nous nous sommes beaucoup instruits, notamment dans des domaines que nous connaissions peu tels que la programmation sur Smartphone, la technologie NOSQL ou encore la technologie Google APP Engine sur lequel, le développement n’a pas été une tâche facile du fait qu’il y a peu du support puisque c’est récent. Les plus grandes difficultés que nous avons rencontrées durant la conception de l’application ont été d’utiliser le backend réalisé avec Google App Engine dans le client Android et de trouver de la documentation sur cette technologie. En effet, la recherche de renseignement demande de la patience car il est parfois difficile de trouver des informations sur quelque chose de peu commun ou nouveau. Il a également été difficile de configurer l’environnement sur lequel on travailler. Nous avons également appris à surmonter une difficulté et de savoir prendre des décisions lorsque plusieurs solutions présentent. Cela nous a permis de développer des méthodes de recherche d’informations, notamment sur Internet. Enfin, l’application que nous avons développée pourrait être enrichie par des fonctionnalités avancées telles que l’intégration de la technologie kanel dans l’application permettant ainsi de recevoir des sms de la part des fournisseurs et faire des recherches d’offres de locations ou de ventes de par l’envoi d’un simple sms. Après avoir fini le client Android, les IOS, WEB et Firefox resteront à finir. Nous pouvons aussi, rendre l’application compatible
  • 51. 50 avec plusieurs plateformes mobile, en la développant avec l’outil Adobe Flash qui génère des programmes d’extension SWF et qui est la tendance actuellement dans le développement des applications embarquées pour mobile.
  • 52. 51 Références bibliographiques [1] http://countrymeters.info/fr/Senegal dernière visite 14/07/2015 [2] http://perspective.usherbrooke.ca/bilan/tend/SEN/fr/SP.URB.TOTL.IN.ZS dernière visite 14/07/2015 [3] www.kaymu.com, dernier visite le 08/12/2015 [4] www.lamudi.com , dernier visite le 08/12/2015 [5] www.Expat-Dakar.com , dernier visite le 08/12/2015 [6] http://www.commentcamarche.net/faq/34876-responsive-design-avantages-et- inconvenients, dernier visite le 02/12/2015 [7] https://sites.google.com/site/omtrouhana/googleappengine/le-datastore , dernier visite le 25 01 2016 [8] https://openclassrooms.com/courses/montez-votre-site-dans-le-cloud-avec-google- app-engine/manipuler-le-datastore-avec-objectify , dernier visite le 25/01/2016 [9] https://cloud.google.com/datastore/ , dernier visite le 25/01/2016 [10] http://www.commentcamarche.net/faq/34876-responsive-design-avantages-et- inconvenients , dernière visite le 21/12/2015 [11] https://developers.google.com/appengine/docs/java/datastore/entities#Properties_and_ Value Types. [12] Wiiid A, Espiau F., Créez des applications pour Android, Licence Créative Commons 6 2.0, 2012. [13] Damien Guignard, Julien Chable, Emmanuel Robles, Programmation Android de la conception au déploiement, Edition Eyrolles.