Rapport PFE : Développement D'une application de gestion des cartes de fidélités(Taggist-Tunis)

Résumé :
L‟objectif principal de ce travail de PFE consiste à implémenter une solution mobile basée sur
la plate forme J2ME pour la gestion des cartes de fidélité
Cette Application permettra aux clients de conserver toutes leurs cartes de fidélités sur leurs
téléphones, consulter leurs soldes des points et géo localiser les enseignes dans lesquelles ils
pourraient utiliser ses cartes.
Mots clés : J2ME, LWUIT, carte de fidélité, SOAP, ZXING, QRcode.
Abstract
This final of studies project aims to implement a mobile application based on J2ME plateform
to manage fidelity cards.
This application will allow customers keeping all their fidelity cards on their phones,
checking the number of points earned at any moment and geo locating the signboard in which
they could use their cards.
Keywords: J2ME, LWUIT, loyalty cards, fidelity card, SOAP, ZXING, QRcode.

Dédicaces
A Mes Très Chers Parents (Mohamed & Lilia)
Tous les mots du monde ne sauraient exprimer l’immense amour que je vous
porte, ni la profonde gratitude que je vous témoigne pour tous les efforts et les
sacrifices que vous n’avez jamais cessé de consentir pour mon instruction et mon
bien-être.
C’est à travers vos encouragements que j’ai opté pour cette profession, et c’est à
travers vos critiques que je me suis réalisé.
J’espère avoir répondu aux espoirs que vous avez fondés en moi.
Je vous rends hommage par ce modeste travail en guise de ma reconnaissance
éternelle et de mon infini amour.
Que Dieu tout puissant vous garde et vous procure santé, bonheur et longue vie
pour que vous demeuriez le flambeau illuminant le chemin de vos enfants.
Je dédie aussi ce travail à :
Mes sœurs (Nourhouda, Sameh, Sonia ) pour leurs encouragements incessants.
Tous mes amis et spécialement (Lazhar, Mounir, Mahdi, Bilel, Noureddine,
Béchir, Wissem, Takwa, Islem et Asma), en souvenir des bons moments que nous
avons passés ensemble, pour leur soutien continu, leur aide précieuse et leur
amour.
Riadh Kort

Remerciement:
Le travail présenté dans ce mémoire a été effectué dans le cadre de la préparation du diplôme
d‟ingénieur spécialité « Génie du Logiciel et des Systèmes d‟Information » à l‟institut
Supérieur d‟informatique (ISI).
Au terme de ce projet, Nous tenons à exprimer notre profonde gratitude et notre immense
respect à Monsieur Achraf Gazdar, Maître assistant en informatique à l‟institut supérieur
d‟informatique pour sa disponibilité, ces avis éclairés, et ces judicieux conseils.
Nos vifs remerciements accompagnés de toute notre gratitude s'adressent également à
Monsieur AbdelKarim Friaa et Monsieur Lajili Abdeljaoued qui ont gardé un œil attentif
sur le déroulement et l‟avancement de notre projet, en ayant toujours des remarques très
constructives ainsi que pour la marque de confiance qu‟ils nous ont attribuée .Nous aimerons
témoigner du plaisir qu'était pour nous de travailler sous leurs directives.
Nous exprimons aussi notre gratitude à M. Oussama Frioui (Directeur Général de Taggist )
ainsi que l‟ensemble de l‟équipe de Taggist (Aymen, Elaa, Rahma, Basma, Islem,
Noureddine, Takwa, Amani, Béchir, Asma) pour leur chaleureux accueil et aide.
Avec beaucoup d'égard, nous ne manquerons pas d'exprimer notre grande reconnaissance à
tous les enseignants et administrateurs de l'Institut Supérieur d‟Informatique et tous les
membres du jury pour avoir accepté de juger ce modeste travail.

Sommaire
Introduction Générale.............................................................................................................. 1
Chapitre I : Présentation Générale......................................................................................... 4
1. Introduction ............................................................................................................. 5
2. Cadre du travail ....................................................................................................... 5
3. Présentation de l‟organisme d‟accueil..................................................................... 5
4. Présentation du projet ............................................................................................. 7
4.1 Objectifs de l‟application.............................................................................. 8
4.2 Approches du travail...................................................................................... 8
4.3 Méthodologie et formalismes adoptés ........................................................... 9
5. Conclusion............................................................................................................. 10
Chapitre II : Etat de l’art ...................................................................................................... 11
1. Introduction ........................................................................................................... 12
2. Les solutions mobiles disponibles sur le marché .................................................. 12
2.1 FidMe .......................................................................................................... 12
2.2 Snapp‟Fid .................................................................................................... 13
2.3 Fidall ............................................................................................................ 13
2.4 Mobifid ........................................................................................................ 14
3. Critiques de l‟existant............................................................................................ 15
4. Conclusion............................................................................................................. 15
Chapitre III : Etude théorique et choix techniques ............................................................ 16
1. Introduction ........................................................................................................... 17
2. Etude Préliminaire................................................................................................. 17
2.1 Smartphones et systèmes d‟exploitation pour mobiles................................ 17
2.2 Problématique .............................................................................................. 19
2.3 Les Frameworks de développement mobiles multi-plateforme................... 19
2.3.1 Comment ça marche................................................................................ 19
2.3.2 Avantages................................................................................................ 19
2.3.3 Inconvénients .......................................................................................... 20
2.3.4 Comparaison Technique.......................................................................... 21
2.3.4.1 PhoneGap............................................................................... 22
2.3.4.2 Titanium (Appcelerator)........................................................ 23
2.3.4.3 Rhodes (Rhomobile).............................................................. 24
2.3.5 Outils....................................................................................................... 25
2.3.6 Conclusion............................................................................................... 25
2.4 Solution envisagée ....................................................................................... 26
2.5 Architecture adoptée .................................................................................... 26
3. Conclusion :........................................................................................................... 27
Chapitre IV : Analyse et spécification des besoins............................................................. 28
1. Introduction ........................................................................................................... 29
2. Analyse globale de l‟application ........................................................................... 29
2.1 Description des acteurs ................................................................................ 29
2.2 Spécification des besoins fonctionnels : ...................................................... 29
2.3 Spécification des besoins non fonctionnels ................................................ 30
2.4 Diagramme des cas d‟utilisation.................................................................. 31
2.5 Raffinement des cas d‟utilisation................................................................. 33
2.5.1 Affectation des priorités.......................................................................... 33
2.5.2 Raffinement des cas d‟utilisation............................................................ 33

2.5.2.1 Raffinement du cas d‟utilisation «gestion des cartes de
fidélité»............................................................................................... 33
2.5.2.2 Raffinement du cas d‟utilisation «géo localiser les enseignes
proches du client»............................................................................... 34
2.5.2.3 Raffinement du cas d‟utilisation «consultation du nombre de
points»……………… ........................................................................ 35
2.5.2.4 Raffinement du cas d‟utilisation «consulter les nouvelles
offres» ………………………………………………………………35
2.5.2.5 Raffinement du cas d‟utilisation « authentification»............. 36
2.5.2.6 Raffinement du cas d‟utilisation «inscription»...................... 36
2.5.2.7 Raffinement du cas d‟utilisation «procéder aux paiement » :37
2.6 Diagramme d‟activité de navigation concernant le client............................ 37
Chapitre V : Conception........................................................................................................ 40
1. Introduction ........................................................................................................... 41
2. Conception détaillée.............................................................................................. 41
2.1 Le diagramme de classe............................................................................... 41
2.1.1 Diagramme de classes de l‟application serveur Middleware.................. 41
2.1.2 Les classes de l‟application mobile........................................................ 44
2.2 La base des données de l‟application........................................................... 45
2.3 Architecture de la partie serveur.................................................................. 47
2.3.1 Package web service (Les méthodes distantes au niveau serveur) : ....... 48
2.4 Les diagrammes de séquence....................................................................... 49
2.4.1 Le cas d‟utilisation « s‟authentifier »...................................................... 49
2.4.2 Le cas d‟utilisation « inscription d‟un nouveau membre »..................... 50
2.4.3 Le cas d‟utilisation « afficher la liste des cartes fidélité disponibles ».. 50
2.4.4 Le cas d‟utilisation « ajouter une nouvelle carte »................................ 51
2.4.5 Le cas d‟utilisation « afficher les cartes de fidélité personnelles »......... 52
2.4.6 Le cas d‟utilisation « géo localiser les enseignes sur une carte» ............ 53
2.4.7 Le cas d‟utilisation « visualiser le code à barre de la carte ».................. 54
3. Conclusion............................................................................................................. 54
Chapitre VI : Réalisation....................................................................................................... 55
1. Introduction ........................................................................................................... 56
2. Environnement de travail ...................................................................................... 56
2.1 Environnement matériel............................................................................... 56
2.2 Environnement logiciel................................................................................ 56
2.2.1 La plateforme « J2ME ».......................................................................... 57
2.2.1.1 Présentation............................................................................ 57
2.2.1.2 L'architecture J2ME............................................................... 57
2.2.2 LWUIT.................................................................................................... 59
2.2.3 La bibliothèque Zxing (Zebra Crossing)................................................. 61
2.2.4 La bibliothèque Geo-J2ME..................................................................... 62
2.2.5 Web service............................................................................................. 62
2.2.5.1 Définition du protocole SOAP............................................... 62
2.2.5.2 KSOAP 2 ............................................................................... 63
2.2.5.3 Apache Axis2......................................................................... 63
2.2.5.4 Hibernate................................................................................ 64
3. Interfaces de l‟application ..................................................................................... 65
4. Réalisation partie serveur ..................................................................................... 72
5. Conclusion ............................................................................................................ 73
Conclusion générale ............................................................................................................... 74

Annexes ……………………………………………………………………………………75
1. Systèmes d'exploitation utilisés par les Smartphones en 2009.............................. 75
1.1 Symbian OS ................................................................................................. 75
1.2 RIM BlackBerry OS .................................................................................... 75
1.3 Android de Google Inc................................................................................. 75
1.4 iOS de Apple Inc.......................................................................................... 75
1.5 Windows Mobile de Microsoft .................................................................... 76
1.6 Windows Phone de Microsoft...................................................................... 76
1.7 Linux............................................................................................................ 76
1.8 Bada de Samsung Electronics...................................................................... 76
2. Calcul de checksum de L‟EAN 13 :...................................................................... 77
Glossaire ……………………………………………………………………………………78
Webographie........................................................................................................................... 80
Bibliographie........................................................................................................................... 82

La liste des figures
Figure 1 : image simplifiant l‟idée de notre projet ........................................................... 7
Figure 2. Les phases d‟un processus unifié ...................................................................... 9
Figure 3. l‟application FidMe ......................................................................................... 12
Figure 4. L‟application Snapp‟Fid.................................................................................. 13
Figure 5. L‟application Fidall ......................................................................................... 13
Figure 6. L‟application MobiFid .................................................................................... 14
Figure 7.Part de marché en 2010 Smartphone par systèmes d'exploitation.................... 18
Figure 8. Schéma montrant le fonctionnement de PhoneGap ........................................ 20
Figure 9. Interface de l‟émulateur PhoneGap................................................................. 22
Figure 10. l‟interface de lancement de Titanium............................................................ 23
Figure 11.Interface de l‟émulateur Rhodes..................................................................... 24
Figure 12. Architecture adoptée pour le développement de l‟application...................... 27
Figure 13 . Diagramme de cas d‟utilisation de client ..................................................... 32
Figure 14. Diagramme d‟activité concernant le client.................................................... 38
Figure 15. Schéma simplifiant les attentes du client et les principales fonctionnalités.. 39
Figure 16. Diagramme de classes de l‟application Middleware..................................... 43
Figure 17. Les classes de l‟application sur le mobile ..................................................... 44
Figure 18. Schéma de la base des données ..................................................................... 46
Figure 19. Architecture détaillée de l‟application .......................................................... 48
Figure 20. Les méthodes déployées sur le serveur ......................................................... 48
Figure 21 . Diagramme de séquence pour le cas d‟utilisation « s‟authentifier »............ 49
Figure 22. Diagramme de séquence pour le cas d‟utilisation « inscription nouveau
membre » ........................................................................................................................ 50
Figure 23. Diagramme de séquence pour le cas d‟utilisation « consulter la liste des
cartes disponibles »......................................................................................................... 51
Figure 24. Diagramme de séquence du cas d‟utilisation « ajouter une nouvelle carte »52
Figure 25. Diagramme de séquence du cas d‟utilisation « afficher les cartes de fidélité
personnelles » ................................................................................................................. 53
Figure 26. Diagramme de séquence du cas d‟utilisation « géo localiser enseigne »...... 53
Figure 27 . Diagramme de séquence du cas d‟utilisation « visualiser le code à barre de la
carte ».............................................................................................................................. 54
Figure 28. Architecture Logicielle de l‟application........................................................ 56

Figure 29. Interface principal de LWUIT Demo présentant les principaux widgets
apportés avec LWUIT..................................................................................................... 59
Figure 30. Interface montrant l‟effet rotation ................................................................. 60
Figure 31. interface montrant les possibilités graphiques avec LWUIT ........................ 60
Figure 32. Interface graphique de l‟application « Ressource Editor » ........................... 61
Figure 33. Schéma décrivant une communication client serveur en utilisant les web
service ............................................................................................................................. 62
Figure 34. Structure d‟un message SOAP ...................................................................... 63
Figure 35. Interface de lancement de l‟application......................................................... 65
Figure 36. Interface d‟authentification ........................................................................... 65
Figure 37. Interface ajout nouveau membre ................................................................... 66
Figure 38. Interface questionnant le client de choisir entre visualiser ses cartes ou
ajouter d‟autres cartes. .................................................................................................... 66
Figure 39. Interface liste des cartes de fidélités disponibles........................................... 67
Figure 40. Interface détails carte..................................................................................... 68
Figure 41. Interface ajout d‟une carte............................................................................ 68
Figure 42. Carte sélectionnée.......................................................................................... 69
Figure 43. Liste des cartes propriétaires ........................................................................ 69
Figure 44. Code 1D carte affiché.................................................................................... 70
Figure 45. QR code carte affiché.................................................................................... 70
Figure 46. Géo localisation vue satellite......................................................................... 71
Figure 47. Géo localisation vue normal.......................................................................... 71
Figure 48. La liste des services déployés sur le serveur ................................................. 72
Figure 49. Exemple d‟un Soap Request et d‟un Soap Response................................... 72

La liste des tableaux
Tableau 1. Comparatif des solutions Phonegap, Titanium, Rhomobile ........................ 21
Tableau 2. Tableau comparatif mentionnant les possibilités offertes par les Os mobile et
celle des Frameworks...................................................................................................... 25
Tableau 3. Tableau d‟affectation des priorités................................................................ 33
Tableau 4. Description du cas d‟utilisation « gestion des cartes de fidélité »................ 34
Tableau 5. Description du cas d‟utilisation « géo localiser les enseignes proches »...... 34
Tableau 6. Description du cas d‟utilisation « consultation du nombre des points »...... 35
Tableau 7. Description du cas d‟utilisation « consulter les nouvelles et promotions ». 35
Tableau 8. Description du cas d‟utilisation « authentification » ................................... 36
Tableau 9. Description du cas d‟utilisation « inscription » ............................................ 37
Tableau 10. Description du cas d‟utilisation « procéder au paiement »........................ 37

ISI Introduction générale Taggist
Application mobile pour la gestion des cartes de fidélité Page 1
Introduction Générale

Le marché des applications mobiles connait un essor phénoménal et devient une véritable
manne financière pour les entreprises.
C‟est dans cette optique, que plusieurs entreprises telles que les supermarchés et les
hypermarchés n'ont pas hésité à exploiter les avancées technologiques pour offrir des services
innovants et rapides à leurs consommateurs.
Le seul et unique objectif était la recherche perpétuelle de solutions pratiques pour fidéliser
les clients et faciliter leurs achats.
Une idée ingénieuse est née : Inutile désormais de trimballer ses cartes de fidélité lorsqu'on
veut faire ses achats, depuis qu'une application mobile a été développée pour les Smartphones
et qui stocke toutes ces cartes.
Le contexte de notre projet est de proposer une solution mobile permettant d‟avoir toutes les
cartes de fidélité toujours avec le client, en les retrouvant sur son téléphone mobile.
Ce rapport présente l‟ensemble des étapes suivies pour développer la solution. Il contient six
chapitres organisés comme suit :
Le premier chapitre intitulé « Présentation Générale» est consacré à la présentation du
contexte du travail ainsi que l‟organisme d‟accueil.
Le chapitre « Etat de l‟art » s‟articule autour de l‟étude de quelques applications mobiles de
gestion des cartes de fidélité et la présentation de leurs fonctionnalités offertes. Nous nous
sommes basés sur cette étude pour faire la spécification de notre application, qui fera l‟objet
du quatrième chapitre.
Le chapitre suivant intitulé « Etude théorique et choix techniques » contient une étude des
solutions techniques existantes sur le marché en mentionnant leurs avantages et leurs
inconvénients, pour finir par donner la solution retenue.
Dans le chapitre « Analyse des besoins et spécification », nous déterminons les besoins
fonctionnels et non fonctionnels de notre application et présentons les différents cas
d‟utilisation.

Le cinquième chapitre intitulé « Conception » détaille les différents aspects conceptuels de
l‟application.
Le dernier chapitre intitulé « Réalisation » présente l‟environnement de travail ainsi que les
outils logiciels que nous avons utilisés pour la réalisation de notre projet. Il illustre aussi le
travail réalisé avec un ensemble d‟interfaces graphiques conçues pour l‟application.
En conclusion, nous mentionnons les différents atouts de ce projet et les perspectives
d‟améliorations possibles.

ISI Présentation Générale Taggist
Chapitre I : Présentation
Générale

1. Introduction
Ce chapitre est consacré pour la présentation de l‟entreprise d‟accueil, la précision du
cadre du projet et la problématique puis l‟énumération des étapes de travail à réaliser pour
achever ce projet.
2. Cadre du travail
Ce stage s‟inscrit dans le cadre d‟un projet de fin d‟études pour l‟obtention d‟un diplôme
d‟ingénieur informatique de l‟Institut Supérieur d‟Informatique. Notre stage a été effectué au
sein d‟une Société de Services en Ingénierie Informatique (SS2I) « TAGGIST ».
Le sujet est intitulé "Conception et développement d‟une application mobile d‟un
programme de fidélité multi enseignes ".
3. Présentation de l’organisme d’accueil
TAGGIST est spécialiste de l‟intégration de Nouvelles Technologies. En étroite collaboration
avec les cabinets de conseil, les fabricants de matériel et les éditeurs logiciels, C‟est une
compagnie d‟intégration des technologies et des systèmes d‟innovation, spécialisée dans le
développement des applications mobile, ingénierie logicielle, développement d‟applications
web.
Les activités de TAGGIST s‟articulent autour de 4 axes :
- Prestations de conseil.
- Intégration de solutions RFID, codes à barres, NFC, biométrie et GPS.
- Développement de produits et de solutions spécifiques.
- Distribution de matériels et consommables.

TAGGIST est composée de deux groupes. Le premier groupe est spécialisé dans le
développement des solutions mobile. Le deuxième est spécialisé dans le développement des
applications web sur la plateforme J2EE. Elle est implantée dans la ville Charguia-Tunis et
la ville Kairouan.
Une liste non exhaustive des solutions développées est la suivante :
- TAGGIST®Immob : la solution de gestion des immobilisations vous donne la
possibilité de situer géographiquement votre parc mobilier et/ou informatique et
d‟automatiser l‟inventaire.
- TAGGIST®Doc : c‟est une solution de suivi des mouvements d‟ouvrages et/ou de
documents papiers. L‟idée est ici d‟équiper des documents d‟étiquettes RFID. Ainsi,
ils seront décrits dans notre logiciel, puis identifiés sur le lecteur de table.
- TAGGIST®Localisation: elle permet aux utilisateurs de suivre en temps réel et à
intervalle de temps régulier (paramétrable de 0.2 secondes à quelques minutes)
l‟identification des éléments devant être surveillés et alerter les responsables
prédéfinis par Mail et/ou SMS lorsqu‟un élément quitte sa zone de localisation
prédéfinie.
- TAGGIST®Time&Pointage : c‟est une solution de gestion du temps et de pointage
par empreinte digitale et/ou badges RFID (sans contact). Elle offre une gestion
rigoureuse des événements de présences et d‟absences à travers une liaison
automatique à une ou plusieurs pointeuses Biométriques (par Empreinte Digitale).
- TAGGIST®Security: c‟est une solution à la pointe de technologie adaptée pour des
expositions temporaires, galeries et collections privées, des musées ou collections
importantes.
- TAGGIST®GPS: cette solution est basée sur une balise GPS/GSM de tracking et de
secours, autonome et de très petite taille qui peut fonctionner en mode GPRS ou SMS.
- TAGGIST®GMAO : ce logiciel intègre toutes les fonctionnalités attendues d'un
logiciel de GMAO en conformité avec les normes qualités appliquées dans les
entreprises (normes ISO). Le logiciel TAGGIST®GMAO est d‟une implantation
simple et rapide. En outre, il est totalement paramétrable pour tout type d‟entreprise.
Les menus, les écrans, les documents ou les graphiques sont personnalisables par
chaque utilisateur.

- TAGGIST®Eventent : C‟est une solution complète de gestion d'événement. De
l'édition du badge électronique, à l'utilisation de celui-ci aux entrées de salles, sur les
stands des exposants ou pour le contrôle de services.
- TAGGIST®Santé : Solution en cours de développement
- TAGGIST®Textile : Solution en cours de développement
- TAGGIST®TGGYNET : Solution basée sur la technologie NFC (Near Field
Communication). Cette solution est confidentielle et prouve les compétences de notre
équipe et la qualité de nos dirigeants de fournir des solutions Innovantes et à la pointe
de la technologie. En effet, cette solution est lauréate au concours international
SIMAGINE 2009.
Le site web de la société TAGGIST est : www.taggist.fr
4. Présentation du projet
Les avantages des cartes de fidélité sont nombreux aussi bien pour les clients à travers les
réductions appliqués sur leurs achats et la collecte des points de fidélité, que pour les sociétés
qui préservent à long terme leurs parts dans le marché et leurs rentabilités.
Mais le nombre de ses cartes a augmenté d‟une façon exponentielle, ce qui rend impossible
de pouvoir les transporter toujours sur soi. Nous proposons comme solution une application
mobile multi-enseignes qui a comme objectif de limiter la multiplication des supports
papiers. L'idée est simple : Enregistrer toutes ses cartes de fidélités sur son Smartphone pour
les avoir toujours sur soi. Lors du passage en caisse, le code barre de la carte de fidélité est
présenté sur l'écran du téléphone.
Figure 1 : image simplifiant l’idée de notre projet

4.1 Objectifs de l’application
- Permettre le client d‟avoir toutes ses cartes de fidélité toujours sur soi.
- La possibilité pour un client d‟adhérer automatiquement à des nouvelles cartes de fidélité
depuis son téléphone mobile.
- Informer les clients sur les nouvelles offres existantes à fin de bénéficier de tous les
avantages et réductions liées.
- Visualiser sur une carte géographique, les enseignes dont le client possède une carte de
fidélité ------
-Consulter le solde de points à travers un compte en ligne ou à travers le téléphone mobile.
4.2 Approches du travail
Le projet comprend deux phases : la première est la recherche d‟une solution convenable pour
réaliser l‟application, et la deuxième, la phase de conception et de développement.
 Phase de recherche
C‟est l‟étape qui inclut l‟étude bibliographique, dans laquelle nous devons saisir les
différentes notions et technologies à utiliser dans le projet, les architectures, etc.
Aussi, elle renferme les tests des différentes solutions mises en hypothèse pour réaliser
l‟application, et nous fixons les outils nécessaires pour la réalisation du projet.
 Phase de conception et développement
C‟est une étape, dans laquelle, nous spécifions les besoins fonctionnels et nous modélisons le
système à réaliser pour clarifier les tâches à accomplir dans la partie développement.
Cette phase se termine par une partie qui comprend la programmation et les tests de
validation.

4.3 Méthodologie et formalismes adoptés
Nous allons adopter la méthode agile : Rational Unified Process comme un processus de
développement logiciel.
Nous avons opté pour ce choix dû à ces caractéristiques car il est :
 Itératif.
 centré sur l'architecture.
 piloté par des cas d'utilisation et orienté vers la diminution des risques.[URL 1]
Figure 2. Les phases d’un processus unifié
conceptuels tels que les acteurs, les processus métiers, les activités et les composants du
système, ainsi que les éléments concrets tels que les langages de programmation, les schémas
de bases de données, etc. [URL 2]
Expression des
besoins
Analyse
ConceptionImplémentation
Test

5. Conclusion
Dans ce chapitre introductif, nous avons présenté l‟organisme d‟accueil ainsi que le projet à
réaliser. Nous allons entamer maintenant la phase de préparation de ce projet qui est l‟étude
de l‟existant et la présentation des différentes solutions disponibles sur le marché.

ISI Etat de l’art Taggist
Chapitre II : Etat de l’art

1. Introduction
Ce chapitre a pour objet de présenter quelques applications mobiles pour la gestion des cartes
de fidélité d‟une manière détaillée, en exposant leurs fonctionnalités.
2. Les solutions mobiles disponibles sur le marché
La technologie mobile offre de multiples avantages en termes de fidélisation et
communication client pour les enseignes :
- Augmenter et faciliter l'adhésion au programme de fidélité.
- Dématérialiser la carte de fidélité .
- Proposer des coupons de réduction dématérialisés
-Réduire les coûts et délais d‟une campagne ciblée de communication (moins de
plastique, moins de papier, gain de temps, gratuité des notifications).
Le marché présente une panoplie des solutions informatiques dédiées à la gestion des cartes
de fidélité, que nous présentons ci-après.
2.1 FidMe
FICHE TECHNIQUE :
Innovante et simple à utiliser, FidMe vous permet d’enregistrer vos
cartes de fidélité en quelques secondes. Grâce à son outil de
reconnaissance de code barre, vous passez votre carte devant
l’objectif de votre mobile (sur certains modèles) ou saisissez votre
numéro client et le tour est joué !
Disponible pour les plates formes :
Figure 3. l’application FidMe
[URL3]

2.2 Snapp’Fid
2.3 Fidall
Fiche technique :
Snapp' (ex Business Anywhere) est spécialisée dans le commerce mobile et
la dématérialisation de programmes de fidélité.
Informations personnelles : Vos clients peuvent consulter et éditer les
informations de leur compte (suivant vos spécifications).
Identification du client : Le code-barres est affiché sur l'écran, le client peut
alors être scanné en caisse ou présenter son code en magasin.
Consultation du solde : Vos clients peuvent consulter le solde de leur
programme de fidélité et ses détails, mais également les derniers achats et
les primes acquises.
Coupons et offres : Notifications ou consultation, les clients reçoivent
directement leurs coupons et offres personnalisées utilisables en magasin.
News : les dernières actualités de votre marque ou enseigne.
Geolocalisation : Aidez vos clients à trouver facilement l'établissement le
plus proche grâce aux outils de cartographie type GPS en temps réel.
Figure 4. L’application
Snapp’Fid
[URL 4]
Figure 5. L’application Fidall

2.4 Mobifid
Fiche technique :
Fidall vous permet tout d‟abord d‟enregistrer gratuitement une fois pour
toutes vos cartes de fidélité, afin de les retrouver sur votre téléphone mobile
Vous pourrez ensuite pour certaines cartes adhérer d‟un simple clic. Fidall
se charge de transmettre votre demande d‟adhésion à la boutique ou
enseigne de votre choix.
Enfin, Fidall vous offre la possibilité de consulter les soldes de points de
certains programmes de fidélité, depuis une interface unique.
De plus, l‟application utilise la géo localisation. Fidall vous renseigne sur
les enseignes dont vous possédez la carte de fidélité et qui se trouvent près
de votre position.
Mobifid propose aux enseignes de
dématérialiser leurs programmes de fidélité sur
téléphone portable.
L'application Mobifid est brindée aux couleurs
de l'enseigne. Elle permet au consommateur de
gérer sa carte de fidélité, recevoir des coupons
de réductions, cumuler des points, consulter le
catalogue cadeau....
Cette application serait interfacée avec le
système d'information de l'enseigne.
Figure 6. L’application MobiFid
[URL 5]
[URL 6]

3. Critiques de l’existant
Quelle que soit la technologie utilisée ou les services supplémentaires apportés aux
consommateurs par ces solutions, un enjeu majeur reste l'intégration de la solution aux
systèmes d'information de l'enseigne. La remontée d'informations doit être efficace et
pertinente. Les données remontées par ces applications doivent être intégrées au SGBD de
l'enseigne.
De plus, nous constatons que la plupart des firmes offrant ces applications, présentent une
version ciblée pour chaque Os mobile (ex : offrir une application développé avec Objective C
sur l‟Apps Store pour les SmartPhone iPhone, une autre version téléchargeable depuis
l‟Android Market faite avec Java pour des appareils supportant Android, d‟autres dédiées
aux Blackberry etc.).
Nous cherchons à développer une solution générique qui serait compatible avec toutes les Os
mobiles disponibles sur le marché sans être obligé à reprendre le travail de développement
pour chaque plateforme.
4. Conclusion
Dans ce chapitre nous avons essayé d‟étudier quelques applications mobiles de gestion des
cartes de fidélité dans le but d‟avoir une idée sur les fonctionnalités de ces dernières et de
ressortir leurs points forts. Sur la base de cette étude, nous allons élaborer la spécification de
notre application. Une étude théorique sur les plates formes open source dédiées pour des
applications Smartphones fonctionnant sur plusieurs Os mobiles fera l‟objet du chapitre
suivant.

ISI Etude théoriques et choix techniques Taggist
Chapitre III : Etude théorique et
choix techniques

1. Introduction
Ce chapitre est décomposé en trois sections importantes. Tout d‟abord, une étude
préliminaire sur les Smartphones, les Framework dédiés pour le développement mobile multi-
plate formes, et par la suite le choix de la solution technique à adopter. Et enfin, une vue
globale sur la plateforme du projet.
2. Etude Préliminaire
2.1 Smartphones et systèmes d’exploitation pour mobiles
Un Smartphone, un téléphone intelligent ou un ordiphone est un téléphone mobile qui offre
des fonctions d'un « Personal digital Assistant ». Il fournit les fonctionnalités d'agenda, de
navigation web, de calendrier, de consultation de courrier électronique, de messagerie
instantanée et du GPS (Global Positioning System). Un Smartphone peut aussi permettre
d'installer des applications additionnelles sur l'appareil. Ces applications peuvent être
développées par l'opérateur, par le fabricant ou par n'importe quel autre éditeur de logiciel.
Vu la grande importance des téléphones intelligents, une grande variété d‟entreprises se place
dans le marché des Smartphones en développant des systèmes d‟exploitation pour mobiles.
Vers la fin de l‟année 2007, les systèmes d'exploitation les plus répandus dans le monde sont:
 Symbian (racheté par Nokia) tout en occupant 67 % de parts de marché.
 Windows Mobile (développé par Microsoft) avec 13 % de parts de marché.
 BlackBerry avec 10 % de parts de marché.
 iPhone OS développé par Apple sur l'iPhone avec 7 % de parts de marché.
 Palm OS : encore présente sur quelques Treo.
 Linux tel que LiMo et OpenMoko.
 J2ME (Java 2 Micro Edition) est une technologie Java spécialement adaptée au
développement des applications sur des appareils mobiles (tel que des PDA, des
téléphones cellulaires, des systèmes de navigations pour voiture, etc.), à capacités
limitées en termes de processeur, mémoire, affichage et saisie.

En 2008, le nouveau système d'exploitation open source Android, développé par Google, a
fait son apparition.
En 2009, Palm Inc lance le Palm pré-équipé du Palm webOS . D'autres systèmes
d‟exploitation sortent sous Linux. Microsoft, Symbian et Blackberry mettent à jour leurs
systèmes pour rester au niveau de l'iPhone OS et d'Android. Au début de 2010, une autre
enquête sur les systèmes d'exploitation les plus courants en France, indique que Symbian est
le grand perdant dans le développement du marché durant ces deux dernières années et que
Blackberry, Windows Mobile, iPhone OS et Android sont devenus les systèmes d'exploitation
les plus utilisés : La Figure 7 présente le taux d‟occupation du marché par ses systèmes
d‟exploitation :
 iPhone OS tout en occupant près de 30% du marché
 Windows Mobile avec environ 20 % du marché
 Android avec environ 20% du marché
 Blackberry avec environ 20% du marché
 Symbian avec environ 10% du marché
 Palm webOS, Linux et autres avec des parts négligeables du marché
[ pour plus de détails, consulter la partie Annexe]
D'autres systèmes d'exploitation sont en développement au début de 2010 tels que Bada
développé par Samsung et MeeGo le produit de Intel et Nokia.[ URL 7]
Figure 7.Part de marché en 2010 Smartphone par systèmes d'exploitation

2.2 Problématique
Cette diversité au niveau des plateformes mobiles, met les sociétés éditrice des logiciels dans
l‟embarras du choix de l‟environnement du développement.
Taggist a pensé dans un premier lieu à concevoir une application mobile multi-plate forme,
c'est-à-dire compatible et fonctionnelles sur plusieurs os de smartphones (iphones,
android,etc.)
Ceci devient de plus en plus possible pour des petites applications simples grâce aux
nombreux Frameworks open source dédiées pour des applications Smartphones
multiplateforme. Ces applications sont développées avec des langages destinés au web (de
plus en plus, html5 et JavaScript).
2.3 Les Frameworks de développement mobiles multi-plateforme
2.3.1 Comment ça marche
Malgré le fait que chaque Smartphone parle une langue totalement différente que les autres,
ils partagent un grand avantage, c'est qu'ils ont tous un navigateur web, afin qu'ils
comprennent tous HTML, CSS et JavaScript. Donc, c'est le point d'entrée pour toute
technique de ciblage multiplateforme. La Figure 8 illustre un exemple concret de
fonctionnement de PhoneGap, l‟un de ces Frameworks mobiles
2.3.2 Avantages
- Ecrire avec des technologies de développement web, au lieu de l'apprentissage de chaque
Framework.
- "Write once run every where" (en fait ce n'est pas de cette façon que les choses se passent,
la plupart du temps, c'est «Write once debug every where").
Donc, pas de phase d'apprentissage pour chaque plate-forme, et pas de temps de
développement supplémentaire pour le portage à chaque plate-forme, seul un petit effort pour
un déploiement sur des plateformes différentes.

Figure 8. Schéma montrant le fonctionnement de PhoneGap
2.3.3 Inconvénients
- Plus approprié pour les applications orientées données, mais moins efficace dans les
applications multimédia riches.
- Pas de support pour les jeux.
- Un rendement inférieur par rapport aux technologies indigènes et natives.
- Le Look & Feel est le même sur toutes les plateformes: la quasi-totalité de ces Framework
ont décidé de fonder l‟apparence de leurs composants graphiques similaires à celle de
l'iPhone. Bien que cette décision permet de créer des applications presque identiques à des
applications natives sur l'iPhone, mais cela risque de décevoir ou de frustrer certains

utilisateurs de BlackBerry et / ou Android qui sont familiarisés avec ces environnement.
[URL10 ]
2.3.4 Comparaison Technique
Nous allons étudier les 3 principales technologies de base à savoir: Phone gap, Titanium, et
Rhodes .Le tableau Tableau 1 représente un comparatif de solutions open source pour créer
des applications pour smartphones qui seront fonctionnelles sur plusieurs OS .[URL 11]
Produit PhoneGap Titanium Appcelerator RhodesRhomobile
Licence Open-source (MIT
License)
Open-source (Apache
Public v2.0)
Open-source (MIT
License)
Prix Gratuit Gratuit / $499 Gratuit / $1000
Smartphones iPhone, Android,
BlackBerry,
Symbian, Palm
Phone, Android iPhone, BlackBerry,
Windows Mobile,
Symbian et Android
Langages HTML,
JavaScript, CSS
HTML, JavaScript, CSS HTML, Ruby
Apparence
native
non oui oui
Déploiement manuel manuel RhoSync
Tableau 1. Comparatif des solutions Phonegap, Titanium, Rhomobile

2.3.4.1 PhoneGap
Figure 9. Interface de l’émulateur PhoneGap
Description :
PhoneGap crée des applications mobiles utilisant les technologies web seulement: HTML,
CSS et JS. Une application Téléphone n'est pas si différent d'une application web en mode
Ajax: les pages ne sont jamais (ou rarement) rafraîchie, et l'interface et l'application sont gérés
entièrement en JavaScript.
Ce choix de technologies signifie que PhoneGap peut être utilisé seuls pour des applications
simples, ou peut être combiné avec des framework JavaScript comme Sencha Touch, jQuery
Mobile ou avec un langage mobiles tels que MOBL . Ces Framework aident à développer des
applications avec des interfaces utilisateurs riches, intuitives et conviviales.
L'avantage du Framework PhoneGap est clair: le développement est rapide et plusieurs
plates-formes le supportent.

Inconvénients :
 Malgré le fait que JavaScript soit largement utilisé, l'expérience de l'utilisateur dépend
beaucoup de la puissance de l'appareil et l'accélération de certaines fonctions au
niveau du matériel. Certains téléphones Android, par exemple, offrent une interaction
rapide et de qualité élevée, tandis que d'autres offrent une expérience plus limitée et
presque lente.
2.3.4.2 Titanium (Appcelerator)
Figure 10. l’interface de lancement de Titanium
Description : Les applications faites avec Titanium sont compilées pour l'OS de destination.
Elles paraissent donc plus natives que celles développées avec PhoneGap et sont moins
gourmandes en ressources.
Inconvénients :
 Il n'est pas toujours facile de construire un code qui fonctionne sur Android et
iPhone. Certains composants sont parfois présents sur une plate-forme, mais pas
forcément sur l'autre, certains comportements ne sont pas les mêmes sur l'un ou
l'autre.

2.3.4.3 Rhodes (Rhomobile)
Figure 11.Interface de l’émulateur Rhodes
Description :Rhodes est basé sur un modèle complètement différent: chaque application
mobile embarque un VM Ruby, un framework minuscule basé sur le modèle MVC sur Ruby
on Rails et un serveur Web simplifiée. Il supporte une large gamme d'appareils: la version
BlackBerry 4,6 +, 5.x, 6.x, Android, IOS et Windows Mobile.
Inconvénient :
 Caractéristiques Graphique: Avec Rhodes, les vues sont créées sous forme de pages
HTML. Il y a des composants natives que nous pouvons accéder. jQTouch (un
plugin JQuery pour le développement mobile) est également intégré, mais dans
l'ensemble, les applications créées ont une apparence plus proche du "web" et moins
"native" et pas nécessairement conviviales.
 Vitesse d’exécution lente: l‟intégration d'une Machine virtuelle Ruby, un petit
serveur web qui envoie des pages HTML à un navigateur rend la vitesse d‟exécution
plus lent. Le démarrage de l'application, est en particulier, plus lent que sur les autres
outils. Le temps de latence est important.

2.3.5 Outils
Rhodes : apporte avec lui un cœur dédié pour la construction et le paquetage des applications
et possède un éditeur web web tool pour accomplir ses tâches.
Phonegap : dépend des outils de développement natives intégrés avec chaque plateforme
SDK, xCode pour iPhone, le plugin Eclipse pour Blackberry
Titanium : possède un puissant environnement de développement intégré pour la construction
des applications mobiles.
2.3.6 Conclusion
Application Native sur différent Os
mobile
Application Web(Mobile
Apps Cross Platform)
Performance Performance et capacité
Accès restreints aux ressources
du téléphone Toutes les
Fonctionnalités ne sont pas
accessibles et supportées. (limite
du navigateur)
Téléchargement
de l’application
Disponible pour le téléchargement
dans les Apps store, Android Market
(après approbation de l’administrateur
du site)
Sans processus d‟approbation.
Problème d‟identification de
l‟application par l‟utilisateur
Mode de
fonctionnement
Mode offline / online Doit être en mode online
Apparence Apparence native Pas nécessairement
Complexité de
l’application
complexe Dédiée pour des applications
simple
Tableau 2. Tableau comparatif mentionnant les possibilités offertes par les Os
mobile et celle des Frameworks.

2.4 Solution envisagée
Tenant compte de cette étude, nous avons jugé que ces Framework sont des solutions non
fiables surtout avec des applications complexes et gourmandes en ressources. Alors, la
sélection d‟une de ces plateforme serait un risque potentiel qui pourra engendrer des résultats
inattendues.
Suite à cette constatation, nous avons choisi de travailler avec la plate forme J2ME et de
reprendre la même application sur les autres environnements (Blackberry, iPhone, Android )
avec d‟autres collègue.
2.5 Architecture adoptée
La Figure 12 illustre l‟architecture à adopter pour notre application. Tout d‟abord, notre
projet sera défalqué en trois modules :
- Une partie cliente : elle consiste à la réalisation des différentes interfaces de l‟application
mobile ainsi que l‟interprétation des données fournis et leurs affichages.
- Une partie serveur : Cette partie permet l‟alimentation de la partie cliente avec les données.
De plus, elle permet l‟insertion, la consultation des données et la mise à jour de l‟application
cliente.
- Une partie d’interconnexion entre le client et le serveur : Ce module permet de mettre en
correspondance l‟interaction entre les différents intervenants de l‟application et assure la
communication entre eux..

Figure 12. Architecture adoptée pour le développement de l’application
3. Conclusion :
Nous avons présenté dans ce chapitre une idée sur l‟architecture à adoptée dans notre projet. De
plus, nous avons présenté la solution retenue et les technologies à utiliser. Une étude plus
approfondie sera présentée dans les prochains chapitres. L‟analyse des besoins et la spécification
feront l‟objet du chapitre suivant.

ISI Analyse et spécification des besoins Taggist
Chapitre IV : Analyse et
spécification des besoins

1. Introduction
La phase d‟analyse et spécification des besoins présente une étape primordiale dans le cycle
de développement d‟un projet. En effet, elle permet de mieux comprendre le travail demandé
en dégageant les besoins des différents utilisateurs que le système doit accomplir.
2. Analyse globale de l’application
L‟objectif de notre travail est de concevoir et développer une application mobile pour un
programme de fidélité multi-enseignes qui permettra à un client connecté à partir du site ou de
son mobile(J2ME) de gérer ses cartes.
2.1 Description des acteurs
Cette section a pour objet de présenter les acteurs et leurs fonctionnalités à lesquelles doit
répondre notre application. Nous commençons notre analyse par identifier les acteurs qui
agissent sur notre système à savoir :
Le client : Le client est un acteur principal qui interagit avec notre application. Cette
personne bénéficie de toutes les fonctionnalités de l‟application en mode connecté ainsi qu‟en
mode non connecté.
L’enseigne : c‟est un acteur principal qui intervient seulement dans la partie web. Il présente
ses différentes agences, boutiques, dans le but d‟exposer leurs cartes de fidélité.
L’administrateur : joue un rôle primordial dans l‟assurassions du bon fonctionnement du
système. C‟est la personne qui prend en charge la gestion des comptes des utilisateurs (les
clients et les enseignes) ainsi que la gestion des cartes fidélités sur lesquelles portent les
traitements des différents utilisateurs (ajout, adhésion, suppression, modification…) et la
gestion des promotions.
2.2 Spécification des besoins fonctionnels :
Le Client :
Il accède à l‟application sur son téléphone mobile pour :

 Ouvrir un compte sur cette application s‟il n‟est pas encore inscrit.
 Ajouter une carte de fidélité sur son mobile (saisir les détails de la carte : nom,
prénom, N° de la carte)
 Choisir l‟une de ces cartes de fidélités déjà acquis.
 Adhérer à une nouvelle carte de fidélité.
 Géo localiser les enseignes proches dont il possède une carte de fidélité.
 Retrouver le solde des points de certaines cartes de fidélité.
 Procéder aux paiements des cartes sélectionnées.
L’enseigne peut :
 Gérer ses cartes :
o Consulter la liste de ses cartes.
o Ajouter une carte avec spécification du nombre des points offerts,
délais de validité de la carte...
o Modifier la description d‟une carte.
o Supprimer une carte.
 Gérer les offres :
o Consulter la liste de ses offres.
o Ajouter une nouvelle offre (délai de l‟offre, description de l‟offre).
o Modifier une offre (délai, détails).
o Supprimer une offre.
L’administrateur peut :
 Gérer les comptes des utilisateurs: ajout, modification, suppression,
consultation d‟un compte utilisateur.
 Gérer les cartes : ajout, modification, suppression, consultation d‟une carte.
 Gérer les offres sur les cartes : ajout d‟une nouvelle offre, modification d‟une
offre, suppression d‟une offre lors ce qu‟elle dépasse la date limite.
2.3 Spécification des besoins non fonctionnels
Après avoir déterminé les besoins fonctionnels nous présentons ci-dessous l‟ensemble des
contraintes à respecter pour garantir la performance du système, donc de fournir un produit

performant qui respecte les exigences de l‟utilisateur et qui peut faire face à des risques de
panne ou de non fonctionnement.
 Performance :
Afin d‟être acceptée par le client, notre application doit respecter ce critère tout en assurant
un temps de réponse minimum et des fonctionnalités rependant aux besoins de l‟utilisateur.
 La simplicité:
Un visiteur assez modeste pourra utiliser un tel service de façon intuitive.
 L’ergonomie de l’interface :
Les interfaces doivent être simple et conviviale : On doit essayer le maximum d‟éliminer
l‟encombrement.
 La modularité de l’application :
Avoir un code simple facile à maintenir et à comprendre en cas de besoin.
2.4 Diagramme des cas d’utilisation
La Figure 13 illustre les différentes fonctionnalités offertes pour le client à travers notre
application mobile.

Figure 13 . Diagramme de cas d’utilisation de client
s'authentifier
Finaliser profil
chercher une carte Ajouter une carte
Supprimer une carte
Adhérer à une carte
Visualiser les détails d'une
carte
Modifier les détails d'une
carte
<<include>>
Choisir une carte
Choisir une carte par points
Choisir une carte par
pourcentage
Inscription
<<include>>
<<extend>>
Géolocaliser les enseignes
<<include>>
Consulter les offres et les
promotions
<<include>>
Déconnexion
Procéder au paiement
<<include>>
Gérer les cartes
<<include>>
Consulter le solde des points
Client
<<include>> <<extend>>

2.5 Raffinement des cas d’utilisation
2.5.1 Affectation des priorités
A cette étape de cycle de développement, il est nécessaire de déterminer les cas d‟utilisation
les plus prioritaires. Le choix repose sur la dépendance des cas d‟utilisation, de l‟activité de
l‟entreprise et des choix des utilisateurs.
Cas d’utilisation Acteur priorité
S’authentifier Client 2
Inscription Client 2
Gestion des cartes de
fidélité
Client 1
Consultation des nombres
de points
Client 1
Géo localiser les enseignes
proches de client
Client 1
Consulter les nouvelles
offres
Client 1
Procéder aux paiements Client 2
Tableau 3. Tableau d’affectation des priorités
2.5.2 Raffinement des cas d’utilisation
2.5.2.1 Raffinement du cas d’utilisation «gestion des cartes de fidélité»
Nom du cas d'utilisation Gestion des cartes de fidélité
Acteurs Client
Pré condition Le système fonctionne et l‟utilisateur est authentifié
Post condition Le client pourra ajouter, supprimer, et modifier les détails de ces
cartes de fidélité.
Scénario principal 1. Le système présente les différentes cartes de fidélité
existantes.
2. Le client pourra soit ajouter ou adhérer à une carte.
3. Dans le cas d‟ajout, le client doit insérer le code de sa
carte déjà acquise et quelques renseignements.
4. Dans le cas d‟adhésion, les détails de la carte seront
affichés et un code à barre est généré automatiquement.
5. Le client peut modifier ou supprimer les cartes
enregistrées dans son profil.

Exceptions Le système affiche un message d‟erreur dans le cas où :
-Les données introduites par le client sont incohérentes. Par
exemple : un code à barre contenant des caractères alphabétiques.
-le client ne remplit pas tous les champs obligatoires.
-le code à barre de la carte ajouté est inexistant dans la base des
données.
Tableau 4. Description du cas d’utilisation « gestion des cartes de fidélité »
2.5.2.2 Raffinement du cas d’utilisation «géo localiser les enseignes proches du client»
Nom du cas
d'utilisation
Géo localiser les enseignes proches
Acteurs Client
Pré condition Le système fonctionne. -
l‟utilisateur est authentifié et possède au moins une carte de
fidélité.
Post condition Le système pourra trouver facilement les enseignes les plus
proches grâce aux outils de cartographie type GPS en temps réel.
Scénario principal 1. Le système présente les différentes cartes de fidélité du
client.
2. Le client choisit une de ses cartes.
3. Le système montre une carte contenant des marqueurs
indiquant l‟emplacement des enseignes et la façon d‟y accéder.
4. Les offres doivent être aussi géo localisée.
Exceptions Le système se plante s‟il est n‟arrive pas à accéder aux services
GPS pour identifier l‟emplacement actuel du client et les
enseignes proches du lieu.
Tableau 5. Description du cas d’utilisation « géo localiser les enseignes proches »

2.5.2.3 Raffinement du cas d’utilisation «consultation du nombre de points»
Nom du cas d'utilisation Consultation du nombre de points
Acteurs Client
l‟utilisateur est authentifié et possède au moins une carte de
fidélité.
Post condition Le client pourra consulter son cumul des points de fidélité
collectés chez l‟un des enseignes.
client.
3. Le client consulte l‟ensemble des points de fidélité
collectés et ses détails, Il pourra également visionner
l‟historique de ses derniers achats et les primes acquises.
Exceptions Le système affiche un message d‟erreur si la connexion avec le
serveur base des données est inaccessible.
Tableau 6. Description du cas d’utilisation « consultation du nombre des points »
2.5.2.4 Raffinement du cas d’utilisation «consulter les nouvelles offres»
Nom du cas d'utilisation consulter les nouvelles offres et promotions
Acteurs Client
L‟utilisateur est authentifié et possède au moins une carte de
fidélité.
Post condition Notifications ou consultation, les clients reçoivent directement
sur leurs appareils les offres et les promotions offertes par l‟une
des enseignes.
client.
3. Il choisit ensuite de visualiser les nouvelles offres et
promotions concernant l‟enseigne propriétaire de cette carte.
Exceptions Les offres et promotions ne seront présentées sur le téléphone
du client que dans le mode Online. Dans le cas d‟absence de
connexion, rien n‟est affiché.
Tableau 7. Description du cas d’utilisation « consulter les nouvelles et promotions »

2.5.2.5 Raffinement du cas d’utilisation « authentification»
Nom du cas d'utilisation Authentification
Acteurs Client
Pré condition Chaque personne désirant bénéficier des services de l‟application
doit s‟authentifier d‟abord. Cette personne doit saisir son login et
mot de passe puis cliquez sur le bouton s‟authentifier.
Post condition Cet utilisateur accédera aux fonctionnalités de l‟application selon
ces privilèges. Un simple utilisateur aura des fonctionnalités
restreintes.
Scénario principal 1. Le système affiche le formulaire d'authentification
2. L‟utilisateur saisit son login et mot de passe.
3. L‟utilisateur bénéficiera des fonctionnalités de
l‟application selon son privilège (administrateur / simple
utilisateur)
4. Le système affiche un message d'erreur, si le mot de passe
est incorrect et demande à l‟utilisateur de s‟enregistrer s‟il
n‟avait pas un login et un mot de passe.
Exceptions En cas d„inexistence du mot de passe et du login introduit, un
message d‟erreur est affiché.
Tableau 8. Description du cas d’utilisation « authentification »
2.5.2.6 Raffinement du cas d’utilisation «inscription»
Nom du cas d'utilisation Inscription
Acteurs Client
Pré condition Le système fonctionne et l‟utilisateur voulant bénéficier des
services offerts par l‟application.
Post condition L‟utilisateur aura un mot de passe et un login et pourra
accéder aux services de l‟application.
Scénario principal 1. Le système demande au client de saisir son login, mot
de passe, et CIN.
2. Les données seront envoyées à un serveur distant pour
vérifier leur cohérence et unicité.
3. Le système affiche un message de confirmation
concernant l‟inscription.
4. Le système demande au client de finaliser son compte
avec ses informations personnelles.
Exceptions Les détails de l‟inscription (login, CIN) existent déjà dans
notre système. Dans ce cas, un message d‟erreur sera émis
invitant le client à saisir de nouveau ses détails.

Tableau 9. Description du cas d’utilisation « inscription »
2.5.2.7 Raffinement du cas d’utilisation «procéder aux paiement » :
Nom du cas d'utilisation procéder au paiement
Acteurs Client
Pré condition Lorsque le client choisit les cartes de fidélité type avec remise, il
doit payer en ligne une somme d‟argent contre ce type de service
accordé.
Post condition Le client aura un code à barre (1D, 2D) pour sa nouvelle carte de
fidélité choisie.
Scénario principal 1. Le système propose au client ce type de service en
présentant les détails et les avantages accordés.
2. Le client choisit la carte cible.
3. Il procède ensuite au paiement : Il devra saisir ses
coordonnés bancaires et quelques informations personnelles.
4. Le système affiche un message indiquant la réussite de la
transaction.
Exceptions Le système affiche un message d'erreur, si les données bancaires
sont erronées, ou si son solde est insuffisant.
Tableau 10. Description du cas d’utilisation « procéder au paiement »
2.6 Diagramme d’activité de navigation concernant le client
La Figure14 représente un scénario complet d‟utilisation de l‟application..

Figure 14. Diagramme d’activité concernant le client.
connexion
do/ saisir login & password
création compte
do/ remplir détails formulaire
do/ finaliser son compte
do/ choisir paramètres connexion
affichage cartes personnelles
do/ visualiser détails cartes personnelles
do/ filtrage carte par(catégories, nom)
do/ consulter les notifications des nouvelles promotions
visualiser détails carte
sélectionnée
do/ afficher code à barre
do/ afficher points collectés
do/ retrouver les enseignes proches
visualiser les cartes disponibles
do/ afficher la liste des cartes
do/ rechercher une carte selon(catégories, nom)
do/ sélectionner une carte
visualiser détails carte
sélectionnée
do/ afficher description carte
do/ sélectionner Ajouter carte
do/ sélectionner adhérer carte
saisir code à barre
do/ saisir son code à barre
do/ vérifier cohérance code
procéder auxpaiement
do/ saisir coordonnées bancaires
do/ valider transaction
afficher la carte géographique
do/ accéder aux enseignes marqués sur la carte
do/ visualiser chemin d'accés
Pas encore inscrit
sinon
login ou pwd non valide
sélectionner une carte ajouter une carte
géolocaliser les enseignes
sélectionner une carte
Recevoir
code à barre
choix "Ajout carte"
choix "adhésion carte"
choix carte avec remise
choix carte avec collecte des points
Ajouter la nouvelle carte à la
collection personnelles
code à barre erroné

Dans ce qui suit, une figure récapitulative et simplifiée des objectifs à entamer et de
l‟architecture à mettre en place.
Figure 15. Schéma simplifiant les attentes du client et les principales fonctionnalités
Conclusion :
Dans ce chapitre, nous avons énuméré les différents besoins fonctionnels et non fonctionnels
de notre application. Ensuite, nous avons fait une étude des différents cas d‟utilisation de
notre solution. Ce chapitre a été d‟une importance cruciale surtout pour la compréhension des
besoins et attentes du client.

ISI Conception Taggist
Chapitre V : Conception

1. Introduction
Dans ce chapitre nous abordons la partie conception du projet, dans laquelle, nous détaillons
les différents éléments de conception, à savoir les diagrammes de séquences, et les
diagrammes de classes.
2. Conception détaillée
La conception est la plus importante étape du cycle du développement logiciel. Elle se base
essentiellement sur la bonne spécification et l‟analyse des besoins. Notre démarche débute par la
compréhension du problème. Ensuite nous analysons le problème pour donner une solution
adéquate. A présent, nous sommes dans la phase de concevoir la solution. Notre conception doit
obéir à l‟architecture déjà choisie pour les différentes parties du système d‟où cette phase
préliminaire qui nous permettra de définir les composants globaux de notre système.
2.1 Le diagramme de classe
Le diagramme de classes est une modélisation statique du système en termes de classes et de
relations entre ces classes. Son intérêt réside dans la modélisation des entités du système
d‟information.
2.1.1 Diagramme de classes de l’application serveur Middleware
La Figure 16 illustre les principales classes de notre application :
Classe Client : est la classe qui contient toutes les informations concernant le client.
Classe Enseigne : est la classe qui contient tous les détails concernant une enseigne.
Classe Carte Service : est la classe qui représente réellement la carte de fidélité avec sa
description, sa validité, son prix d‟achat, le taux de remise accordé, les nombres des points
gagnés en échange d‟un montant dépensé et son état soit activée ou non.
Classe Catégories : elle sert à classifier les cartes de fidélité sous des catégories par exemple :
les produits alimentaires, cosmétiques, motos et autos …
Classe Plage Code : sert à associer et restreindre une plage spécifique de code pour une carte
de fidélité.
Classe Promotion : contient tous les détails d‟une offre lancée par une enseigne.

Classe coordonnée : enregistre les longitudes et les latitudes d‟une enseigne pour faciliter sa
localisation dans Google Maps.
Classe compte : sert à associer une carte de fidélité précise à un client donné tout en
enregistrant ses détails tels que son cumul de points de fidélités, sa date d‟acquisition, son
code à barre.
Classe Connexion : gère les connexions à l‟application (contient tous les logins et mots de
passe) qui servent à la phase d‟authentification.
Classe Préférences : sert à présenter une liste non exhaustive des préférences d‟un client pour
que les offres ou les campagnes publicitaires soient bien ciblées.
Classe ApourPréférences : c‟est une classe de jointure entre la classe client et la classe
préférence.

Figure 16. Diagramme de classes de l’application Middleware

2.1.2 Les classes de l’application mobile
Figure 17. Les classes de l’application sur le mobile
La Figure 17 montre les classes utilisées au niveau client.
La classe LocalMidlet est la Midlet de notre application qui représente l‟élément principale.
Elle a des relations avec toutes les classes de notre projet.
La classe SoapConnection est la classe qui gère les relations d‟échanges et d‟analyse des
données transitant entre le web service et notre application.

La classe Checksum sert à vérifier la cohérence des codes à barres insérés et s‟ils respectent
les normes EAN13.
La classe BarcodeFunction est la classe responsable de génération des codes à barres sous la
forme EAN13 ou Qrcode
La classe GoogleMap est la classe responsable de gé localisation et d‟ajout des marqueurs sur
la carte géographique.
Les classes restantes sont des formes et représentent les interfaces de l‟application mobile.
2.2 La base des données de l’application
La Figure 18 représente les tables utilisé dans notre base des données .Ces tables représentent
l‟unité de persistance de notre application.

Figure 18. Schéma de la base des données
FK_POSSEDER
FK_GERER
FK_LIER
FK_OFFRIR
FK_SPECIFIER
FK_LOCALISER
FK_APPARTENIR
FK_APPARTINE
FK_IDENTIFIER_CLI2
FK_IDENTIFIER_ENS2
FK_IDENTIFIER_ENS
FK_IDENTIFIER_CLI
client
id_cli
id_lo
nom_cli
prenom_cli
adresse_cli
ville
code_pos
tel_cli
email_cli
cin_cli
date_naiss
situation_fam
prof
int
int
varchar(255)
varchar(255)
varchar(255)
longtext
varchar(255)
longtext
longtext
varchar(20)
date
varchar(50)
longtext
<pk>
<fk>
compte
id_comp
id_carte
id_cli
code_bar
montant_comp
nbr_pt
etat_comp
code_pin
date_acq
identification
motdePasse
int
int
int
longtext
double
numeric(8,0)
bool
numeric(5,0)
date
text
text
<pk>
<fk2>
<fk1>
enseigne
id_ens
id_lo
nom_com
adresse_com
ville_com
code_pos_com
tel_com
mail_com
num_rg
...
int
int
varchar(255)
varchar(255)
varchar(50)
numeric(8,0)
varchar(20)
varchar(255)
varchar(255)
<pk>
<fk>
carte_service
id_carte
id_ens
id_type
id_plage
desc_carte
validation
prix_ach
taux_rem
montant
nb_pt
etat
...
int
int
int
int
varchar(255)
numeric(8,0)
float
float
float
int
bool
<pk>
<fk1>
<fk3>
<fk2>
plage
id_plage
plage_min
plage_max
etat_plage
...
int
bigint
bigint
bool
<pk>
promotion
id_pro
id_carte
desc_pro
prix_ach_pro
taux_rem_pro
montant_pro
nb_pt_pro
date_deb_pro
date_fin_pro
...
int
int
varchar(255)
float
float
float
int
date
date
<pk>
<fk>
connexion
id_lo
id_cat
login
pwd
etat_lo
int
int
varchar(50)
varchar(50)
bool
<pk>
<fk3>
categorie
id_cat
type_cat
int
varchar(255)
<pk>
coordonnee
id_cor
id_ens
longitude_ven
latitude_ven
adresse_cor
ville_cor
tel_cor
mail_cor
...
int
int
float
float
varchar(255)
varchar(50)
varchar(20)
varchar(255)
<pk>
<fk>
type_carte
id_type
libelle
int
varchar(255)
<pk>

2.3 Architecture de la partie serveur
Pour réaliser notre application, nous avons opté pour une architecture n-tiers à base d‟objets.
C‟est un modèle logique d‟architecture applicative qui vise à séparer nettement 3 couches
logicielles au sein d‟un même système. Le rôle de chaque couche est clairement défini comme
suit:
 Couche présentation des données: Contient les interfaces qui vont interagir avec
l‟utilisateur de l‟application.
 Le traitement métier des données: correspondant à l‟ensemble des règles de gestion
de la logique applicative.
 L’accès aux données persistantes: correspondant aux données qui vont être gardées
de manière persévérante.
Dans cette approche, les couches communiquent entre elles à travers un « modèle d‟échange »
et chacune d‟entre elles propose un ensemble de services rendus. Les services d‟une couche
sont mis à la disposition de la couche supérieure.
Dans cette partie, nous allons détailler notre architecture en l‟illustrant par des diagrammes de
paquetage illustré par la Figure 19.
L‟application doit garantir une indépendance des modules accomplissant les différentes
fonctionnalités prédéfinies. Le choix des packages dépend fortement de l‟architecture de
l‟application décrite précédemment.
Le package présentation contient la classe principal LocalMidlet qui est le moteur de
l‟application Java mobile. Initialement, elle regroupe un ensemble de méthodes prédéfinie
nécessaire pour la réalisation et le déclenchement de l‟application mobile (startApp(),
pauseApp(), destroyApp(), commandAction()).
Notre application mobile réalise un ensemble de fonctionnalités principales (La mise à jour des
données, le parse des fichiers XML provenant des messages SOAP généré par le web service.
Ces tâches sont principalement gérées par la classe SoapConnection qui joue un rôle
primordial de consommation de web service .

Figure 19. Architecture détaillée de l’application
2.3.1 Package web service (Les méthodes distantes au niveau serveur) :
La figure ci-dessous présente les méthodes déployées sur le serveur, et que nous pouvons
accéder à travers les messages SOAP.
Figure 20. Les méthodes déployées sur le serveur

2.4 Les diagrammes de séquence
Le diagramme de séquence décrit l‟aspect dynamique du système. Il modélise les interactions
entre les objets ou entre utilisateur et objet, en mettant l‟accent sur la chronologie des
messages échangés. Dans ce qui suit, nous allons dresser les diagrammes de séquences de
chaque cas d‟utilisation :
2.4.1 Le cas d’utilisation « s’authentifier »
C‟est le premier scénario qui se déroule lors du déclenchement de l‟application. Selon la
Figure 21, le client est invité à saisir ses paramètres de connexion. Le système vérifie la
disponibilité du login et du mot de passe, pour donner ensuite accès aux fonctionnalités de
l‟application.
Figure 21 . Diagramme de séquence pour le cas d’utilisation « s’authentifier »

2.4.2 Le cas d’utilisation « inscription d’un nouveau membre »
Selon la Figure 22, le système invite l‟utilisateur à choisir ses paramètres d‟accès (login et
mot de passe). Il essaie ensuite de vérifier l‟unicité de ses paramètres .Lorsque tout est réglé,
un message de confirmation évoque le succès de l‟inscription.
Figure 22. Diagramme de séquence pour le cas d’utilisation « inscription nouveau
membre »
2.4.3 Le cas d’utilisation « afficher la liste des cartes fidélité disponibles »
Après une procédure d‟authentification réussie, le client pourrait consulter la liste des cartes
de fidélités disponibles. Dans le cas échéant, il pourrait soit adhérer à cette carte ou tout
simplement l‟ajouter à ses cartes personnelles.Ce scénario est décrit dans la Figure 23.

Figure 23. Diagramme de séquence pour le cas d’utilisation « consulter la liste des cartes
disponibles »
2.4.4 Le cas d’utilisation « ajouter une nouvelle carte »
L‟ajout d‟une carte nécessite que le client ne possède pas auparavant une carte de même type.
En plus lors de la saisie du code à barre, le client doit respecter les normes de codage EAN13
sinon un message d‟erreur s‟affiche inhibant ainsi l‟opération d‟ajout de la carte.
Si toutes les conditions sont remplies correctement, la nouvelle carte s‟ajoute au compte
client.

2.4.5 Le cas d’utilisation « afficher les cartes de fidélité personnelles »
Le diagramme de la Figure 25, illustre les interactions entre un client et l‟application lorsque
ce dernier désire visualiser ses cartes personnelles. Il peut ensuite consulter son solde des
points, géo localiser les enseignes, présenter son code à barre à la caisse au moment d‟achat.
Figure 24. Diagramme de séquence du cas d’utilisation « ajouter une nouvelle carte »

Figure 25. Diagramme de séquence du cas d’utilisation « afficher les cartes de fidélité
personnelles »
2.4.6 Le cas d’utilisation « géo localiser les enseignes sur une carte»
La fonction de géo localisation aide l‟utilisateur à accéder facilement à ses enseignes dont il
possède une carte de fidélité.
Figure 26. Diagramme de séquence du cas d’utilisation « géo localiser enseigne »

2.4.7 Le cas d’utilisation « visualiser le code à barre de la carte »
Au moment de paiement chez la caisse, le client peut montrer le code à barre de sa carte pour
qu‟il bénéfice des réductions et offres accordées par une marque donnée.
Le diagramme de la Figure 27 illustre le déroulement de ce cas.
Figure 27 . Diagramme de séquence du cas d’utilisation « visualiser le code à barre de la
carte »
3. Conclusion
Dans ce chapitre nous avons détaillé les différentes vues conceptuelles des applications à
réaliser à travers les modèles UML nécessaires. Cette conception est essentielle pour la phase
de réalisation qui constitue l‟objet du chapitre suivant.

ISI Réalisation Taggist
Chapitre VI : Réalisation

1. Introduction
Dans ce chapitre, nous présentons l‟environnement matériel et logiciel du projet. Ensuite,
nous nous intéressons à la description de quelques interfaces du système implémenté dans le
cadre de quelques scénarios d‟utilisation.
2. Environnement de travail
2.1 Environnement matériel
Machine de développement : ordinateur portable Sony Vaio, Intel® Pentium® M 1,7 Ghz, 2 Go
de RAM.
2.2 Environnement logiciel
 Système d‟exploitation : Windows XP Familial version SP 3
 SGBD: MySQL version 5
 IDE de développement : Eclipse Helios, MyEclipse. LWUIT Ressource Editor.
 Outil pour la conception : Visual paradigm, Rational Rose.
 Traitement et modification des images : Adobe Photoshop CS.
Nous avons intérêt à mettre en place une architecture rigoureuse, de manière à garantir la
maintenabilité, l'évolutivité et l'exploitabilité de notre application. La Figure 28 montre
l'architecture qui sera mise en place dans le cadre de notre projet.
²
Figure 28. Architecture Logicielle de l’application

2.2.1 La plateforme « J2ME »
2.2.1.1 Présentation
Java 2 Micro Edition est une architecture technique dont le but est de fournir un socle de
développement aux applications embarquées. L‟intérêt étant de proposer toute la puissance
d‟un langage tel que Java associé aux services proposés par une version bridée du Framework
J2SE : J2ME.
2.2.1.2 L'architecture J2ME
L'architecture J2ME se découpe donc en plusieurs couches [URL 12] :
• Les profiles : Ils permettent à une certaine catégorie de terminaux d‟utiliser des
caractéristiques communes telles que la gestion de l‟affichage, des évènements
d‟entrées/sorties (pointage, clavier, …) ou des mécanismes de persistance (Base de données
légère intégrée). Ces profiles sont soumis à spécifications suivant le principe du JCP (Java
Community Process)
• Les configurations : Elles définissent une plate-forme minimale en terme de services
concernant un ou plusieurs profiles donnés.
• Les machines virtuelles : En fonction de la cible, la machine virtuelle pourra être
allégée afin de consommer plus ou moins de ressources (KVM, CVM, …)
• Le système d’exploitation : L‟environnement doit s‟adapter au système
d‟exploitation existant (Windows CE, Palm Os) .
La technologie J2ME se compose d‟une machine virtuelle et d‟un jeu d‟APIs appropriées
pour fournir des environnements d‟exécution sur mesure aux terminaux mobiles. Les 2 types
de composants principaux de la technologie J2ME sont les configurations et les profils.
Une configuration est composée d‟une machine virtuelle, des bibliothèques du noyau, de
classes et d‟APIs. Actuellement, il y a deux configurations J2ME possibles :
“Connected Limited Device Configuration (CLDC)” et “ConnectedDevice Configuration
(CDC) ”.

CLDC est créée pour les terminaux dont les ressources processeur et mémoire sont limitées.
Généralement, ces terminaux fonctionnent soit sur un processeur 16-bit, soit sur un 32-bit et
disposent de moins de 512 Kbytes de mémoire disponible pour la plate-forme Java et ses
applications.
CDC est créée pour la prochaine génération de terminaux disposant de plus de ressources.
Généralement, ces terminaux fonctionnent sur un processeur 32-bit et disposent de 2 Mbytes
ou plus de mémoire disponible pour la plate-forme et ses applications.
Les Profiles
Un profile définit la structure d‟une application. Il est basé sur une configuration et c‟est la
base pour produire un environnement de fonctionnement complet pour un type d'appareil
donné. Il fournit généralement l'interface utilisateur, les méthodes d'entrées-sorties et le
mécanisme de persistance pour un groupe d'appareil (alors un seul terminal peut supporter
plusieurs profils). Toutefois certains profils peuvent être créés pour répondre à certaines
capacités ou services d'appareils (RMI, multimédia, etc.).
Il existe plusieurs profiles dont nous citons : MIDP (Mobile Information Device Profile),
Foundation Profile
Le profil « Foundation » est destiné à la configuration CDC. Il permet un accès à une
implémentation complète des fonctionnalités de J2SE. Il englobe des API de gestion de réseau
pour les dispositifs qui n'ont pas besoin de possibilités graphiques
Le profil « MIDP » est destiné à la configuration CLDC. Il prend en charge un nombre limité
des classes de J2SE et définit des classes d'entrée/sortie et d'interface spécialisées pour cette
configuration.
Les Midlets
Les Midlets sont l'élément principal d'une application Java embarquée. Pour bien saisir leur
mode de fonctionnement, il suffit de prendre comme analogie les Applets ou les Servlets.

Le cycle de vie d‟une Applet est géré par un conteneur, en l‟occurrence le Navigateur Web,
dont le rôle est d‟interagir avec celle-ci sous la forme de méthodes de notifications prédéfinies
(init(),paint(),destroyed(),…).
2.2.2 LWUIT
Développée par Sun, LWUIT (LightWeight UI Toolkit) est une librairie de composants
graphiques pour J2ME sortie en 2008.[URL 13]
Cette librairie apporte des composants graphiques plus riches que les librairies standards pour
le développement d'applications mobiles.
Les principaux caractéristiques sont :Touch Screen, Animations & Transitions, Widgets, 3D
Integration, Painters, Modal Dialogs, External Tools, Fonts, rich widgets,themes
Principaux avantages :
• garantir un développement rapide
API Familier
Facile & Simple
Figure 29. Interface principal de LWUIT Demo présentant les principaux widgets
apportés avec LWUIT

Transitions
•Des transitions prêtes pour utilisation
>Slide, Fade
> 3D transitions Cube, Rotate, Fly in
Touch Screen Support
• Tous les widgets supporte les événements provenant
d‟un écran tactile.
• le support de l‟évènement Drag and Drop,
flow reArrange on Drop
• Gestion de défilement(Scrolling) (Effet iPhone)
• Facilité de déploiement
Un seul JAR à importer
Destinés pour des nombreux dispositifs
• Les dispositifs du marché de masse
• Consistent + extensible
• Interface utilisateur riche
Figure 30. Interface montrant l’effet rotation
Figure 31. interface montrant les
possibilités graphiques avec LWUIT

Designer Tool (“Ressource Editor”) : éditeur graphique pour créer des Interfaces
utilisateurs intuitives et conviviales. Il est développé pour les designers. Il s‟agit d‟une
application autonome qui permet de créer des thèmes dédiés aux applications mobiles.
Figure 32. Interface graphique de l’application « Ressource Editor »
2.2.3 La bibliothèque Zxing (Zebra Crossing)
ZXing est un projet open-source multi-format de code-barres 1D/2D de traitement d'images
mis en œuvre en Java. Ce projet met l'accent sur l'utilisation de la caméra intégrée sur les
téléphones mobiles et de décoder les codes-barres sur l'appareil, sans communiquer avec un
serveur.
Les formats pouvant être décodés sont :
- UPC-A and UPC-E
- EAN-8 and EAN-13
- Code 39
- Code 128
- QR Code
- Data Matrix ('alpha quality) .[URL 15]

2.2.4 La bibliothèque Geo-J2ME
C‟est une API qui permet l‟intégration rapide et facile de la carte GPS à une application
J2ME. The API is easy to use as entering an address and returns the coordinates for the same
image of the map sought. The API uses Google Maps statics.
L'API est si facile à utiliser il suffit d'entrer une adresse et l‟API se charge de renvoyer les
coordonnées et l'image satellitaire. La bibliothèque permet aussi d‟ajouter des marqueurs
sur la carte. Elle utilise les API Google Maps statique. [URL 15]
2.2.5 Web service
2.2.5.1 Définition du protocole SOAP
SOAP (ancien acronyme de Simple Object Access Protocol) est un protocole utile pour
exécuter des dialogues requête-réponse RPC (Remote Procedure Call).C‟est un protocole
orienté objet basé sur XML. Il permet la transmission de messages entre objets distants, ce qui
veut dire qu‟il autorise un objet à invoquer des méthodes d‟objets physiquement situés sur un
autre serveur. Le transfert se fait le plus souvent à l‟aide du protocole HTTP, mais peut
également se faire par un autre protocole, comme SMTP.[URL 16]
Figure 33. Schéma décrivant une communication client serveur en utilisant les web
service

Le protocole SOAP est composé de deux parties :
 une enveloppe, contenant des informations sur le message lui-même afin de permettre
son acheminement et son traitement
 un modèle de données, définissant le format du message, c‟est-à-dire les informations
à transmettre.
Figure 34. Structure d’un message SOAP
2.2.5.2 KSOAP 2
Une bibliothèque SOAP client léger, idéale pour les appareils mobiles telles que les
applications J2ME (CLDC / CDC / MIDP) pour consommer les web service. il faut construire
à la main sa requête SOAP, et ensuite parser le résultat soi-même. kSOAP2 est relativement
facile une fois que vous savez quelques concepts de base: Comment établir une connexion,
comment envoyer une demande, et comment accéder aux objets dans une réponse analysée.
[URL17].
2.2.5.3 Apache Axis2
Axis2 est une Framework utile pour la génération des web service. Elle se trouve avec deux
implémentations Apache Axis2/Java et Apache Axis2/C. C'est un package Java libre qui
fournit :

 Un environnement pouvant soit fonctionné comme un serveur SOAP/REST
indépendant soit comme un plug-in de moteurs de Servlet (en particulier Tomcat).
 Une API pour développer des services web SOAP RPC ou à base de messages SOAP.
 Le support de différentes couches de transport : HTTP, FTP, SMTP, POP et IMAP, ...
 La sérialisation/dé sérialisation automatique d'objets Java dans des messages SOAP.
 des outils pour créer automatiquement les WSDL correspondant à des classes Java ou
inversement pour créer les classes Java sur la base d'un WSDL (classe proxy en
quelque sorte, qui fait le lien entre l'application Java cliente et le service distant).
 Des outils pour déployer et tester des web-services. [URL 18]
2.2.5.4 Hibernate
C‟est un Framework pour J2EE qui est capable d‟écrire soit même les classes qui seront
ensuite exposées au code métier. Il s‟occupe aussi du transfert des classes Java dans les tables
de la base de données. Il permet également d‟interroger les données et proposer des moyens
de les récupérer. [URL 19]

3. Interfaces de l’application
Nous exposerons quelques interfaces de notre application, en essayant à chaque fois de décrire les
différents objets interactifs mis à la disposition de l‟utilisateur.
Lors de lancement de l‟application, une interface SplashScreen ( Figure 35) apparaît
mentionnant le nom de l‟application et l‟entreprise éditrice de la solution à savoir Taggist.
Ensuite le client est invité à s‟authentifier en saisissant ses paramètres d‟accès (Figure 36).
Figure 35. Interface de lancement de l’application Figure 36. Interface d’authentification

Figure 37. Interface ajout nouveau membre
Lorsque le client n‟admet pas de
compte, il pourrait accéder aux
fonctionnalités d‟ajout d‟un
membre tout en saisissant
quelques informations
personnelles et les paramètres
d‟accès .La figure 37 illustre ce
cas d‟utilisation.
Figure 38. Interface questionnant le client de
choisir entre visualiser ses cartes ou ajouter d’autres
cartes.
La figure 38 est une interface de transition où le
client doit choisir entre soit visualiser ses propres
cartes, soit ajouter une nouvelle carte de fidélité.

Lors d‟un ajout d‟une carte, le client visualise
d‟abord une liste contenant toutes les cartes de
fidélité disponibles(voir Figure 39 ). En cliquant
là-dessus, une nouvelle interface apparaît
mentionnant les détails de cette carte, le prix
d‟acquisition, le taux de remise accordé etc…
Figure 39. Interface liste des cartes de
fidélités disponibles

Figure 41. Interface ajout d’une carteFigure 40. Interface détails carte
L‟action d‟ajout d‟une carte vérifie d‟abord le checksum
du code inséré et s‟il respecte les normes EAN13 (Voir
Annexe).Ensuite, il vérifie si le client possède déjà une
carte de même type .Si non, il vérifie encore si le code
appartient à la plage des codes associée. Et enfin, il
ajoute cette nouvelle carte .

Lorsque le client choisit de visualiser ses propres cartes, une liste apparaît .elle
contient toutes les cartes possédés par ce dernier. Lorsqu‟il ferait une sélection, la
taille de la carte choisie, grandit et un menu apparaît en dessous présentant des
fonctionnalités tels que : l‟affichage du Qrcode de la carte, l‟affichage du code
1D de la carte, la géo localisation des enseignes associées à cette carte (Figure
42).
Figure 43. Liste des cartes propriétaires Figure 42. Carte sélectionnée

Figure 45. QR code carte affichéFigure 44. Code 1D carte affiché
La bibliothèque Zxing permet au client de
générer son code à barre soit sous la forme 1D ou
Qrcode. Les code à barre affichés dans la figure 44 et
45 sont générés avec cette bibliothèque.

Figure 47. Géo localisation vue normal Figure 46. Géo localisation vue satellite
L‟application permet de visualiser à l‟aide des
marqueurs l‟emplacement géographique des
enseignes sur une carte.

4. Réalisation partie serveur
Figure 48. La liste des services déployés sur le serveur
Figure 49. Exemple d’un Soap Request et d’un Soap Response.

La figure 48 et 49 exposent la liste des services déployés sur Axis2.Leurs spécifications
reposent sur les standards SOAP et WSDL. Ces services servent à alimenter l‟application
mobile par les données nécessaires lors des traitements, assurer l‟interfaçage entre le serveur et
cette dernière et gèrer aussi la persistance des donnés au niveau de la base des données.
serveur back-End pour alimenter les applications mobiles.
5. Conclusion
Dans ce chapitre nous avons détaillé les technologies utilisées pour la réalisation de notre projet
ainsi que les fonctionnalités de base de l‟application à travers un ensemble de captures d‟écran.

Rapport PFE : Développement D'une application de gestion des cartes de fidélités(Taggist-Tunis)

Rapport PFE : Développement D'une application de gestion des cartes de fidélités(Taggist-Tunis)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport PFE : Développement D'une application de gestion des cartes de fidélités(Taggist-Tunis)

Similaire à Rapport PFE : Développement D'une application de gestion des cartes de fidélités(Taggist-Tunis) (20)

Plus de Riadh K.

Plus de Riadh K. (9)

Rapport PFE : Développement D'une application de gestion des cartes de fidélités(Taggist-Tunis)