Tirageriadh 140321042133 Phpapp01

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
Introduction Générale
Application mobile pour la gestion des cartes de fidélité Page 1

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]
Expression des
besoins
Test Analyse
Implémentation Conception
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]

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é ! [URL3]
Disponible pour les plates formes :
Figure 3. l’application FidMe

2.2 Snapp’Fid
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.
Disponible pour les plates formes : [URL 4]
Figure 4. L’application
Snapp’Fid
2.3 Fidall
Figure 5. L’application Fidall

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.
[URL 5]
2.4 Mobifid
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. [URL 6]
Figure 6. L’application MobiFid

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 Open-source (Apache Open-source (MIT

License) Public v2.0) License)
Prix Gratuit Gratuit / $499 Gratuit / $1000
Smartphones iPhone, Android, Phone, Android iPhone, BlackBerry,
BlackBerry, Windows Mobile,
Symbian, Palm Symbian et Android
Langages HTML, HTML, JavaScript, CSS HTML, Ruby
JavaScript, CSS
Apparence non oui oui
native
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 Application Web(Mobile

mobile Apps Cross Platform)
Accès restreints aux ressources
du téléphone Toutes les
Performance Performance et capacité Fonctionnalités ne sont pas
accessibles et supportées. (limite
du navigateur)
Téléchargement Disponible pour le téléchargement Sans processus d‟approbation.
dans les Apps store, Android Market Problème d‟identification de
de l’application
(après approbation de l’administrateur l‟application par l‟utilisateur
du site)
Mode de Mode offline / online Doit être en mode online
fonctionnement
Apparence Apparence native Pas nécessairement
Complexité de complexe Dédiée pour des applications
l’application 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.

<<extend>>
Inscription
Client Finaliser profil
<<include>>
Géolocaliser les enseignes
<<include>>
<<include>>
Consulter les offres et les

promotions
Déconnexion <<include>>
<<include>>
s'authentifier
Procéder au paiement
<<include>>
Consulter le solde des points

<<include>> <<extend>>
Adhérer à une carte
chercher une carte Ajouter une carte
Gérer les cartes

Choisir une carte
Choisir une carte par

pourcentage
Supprimer une carte
Choisir une carte par points
Visualiser les détails d'une

carte
Modifier les détails d'une
carte
Figure 13 . Diagramme de cas d’utilisation de client

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 Client 1
fidélité
Consultation des nombres Client 1
de points
Géo localiser les enseignes Client 1
proches de client
Consulter les nouvelles Client 1
offres
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 Géo localiser les enseignes proches

d'utilisation
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..

connexion
do/ saisir login & password
login ou pwd non valide création compte

Pas encore inscrit
do/ remplir détails formulaire
do/ finaliser son compte
do/ choisir paramètres connexion
sinon
affichage cartes personnelles
do/ visualiser détails cartes personnelles

do/ filtrage carte par(catégories, nom)
do/ consulter les notifications des nouvelles promotions
sélectionner une carte ajouter une carte
visualiser détails carte visualiser les cartes disponibles

sélectionnée
do/ afficher code à barre do/ afficher la liste des cartes
do/ afficher points collectés do/ rechercher une carte selon(catégories, nom)
do/ retrouver les enseignes proches do/ sélectionner une carte
sélectionner une carte
géolocaliser les enseignes
visualiser détails carte
afficher la carte géographique sélectionnée
do/ accéder aux enseignes marqués sur la carte do/ afficher description carte
do/ visualiser chemin d'accés do/ sélectionner Ajouter carte
do/ sélectionner adhérer carte
choix "Ajout carte"
choix "adhésion carte"
code à barre erroné
saisir code à barre

do/ saisir son code à barre
do/ vérifier cohérance code
choix carte avec remise
choix carte avec collecte des points
procéder aux paiement
do/ saisir coordonnées bancaires Recevoir
do/ valider transaction code à barre
Ajouter la nouvelle carte à la

collection personnelles
Figure 14. Diagramme d’activité concernant le client.

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.

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

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.

Figure 24. Diagramme de séquence du cas d’utilisation « ajouter une nouvelle carte »
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 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.
Figure 29. Interface principal de LWUIT Demo présentant les principaux widgets
apportés avec LWUIT
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

• 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
Transitions
•Des transitions prêtes pour utilisation
>Slide, Fade Figure 30. Interface montrant l’effet rotation
> 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)

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

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 37. Interface ajout nouveau membre
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é.
Figure 38. Interface questionnant le client de

choisir entre visualiser ses cartes ou ajouter d’autres
cartes.

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 40. Interface détails carte Figure 41. Interface ajout d’une 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 .

Figure 43. Liste des cartes propriétaires Figure 42. Carte sélectionnée
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 44. Code 1D carte affiché Figure 45. QR code 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.

ISI Conclusion générale Taggist
Conclusion générale
L‟objectif de ce projet de fin d‟étude était de concevoir et développer une application mobile
pour la gestion des cartes de fidélité.
Nous avons confrontés des contraintes techniques dans la phase du développement. En effet,
nous avons passé plus de temps pour l‟intégration des web services avec l‟application mobile
et de gérer la façon de communication entre les deux. Ainsi, nous avons utilisé LWUIT afin
de faire le design des interfaces, ce qui nous a poussé à s‟auto-formé avant d‟entamer cette
phase.
Comme la totalité des objectifs et fonctionnalités mentionnés dans la partie spécification ne

sont pas atteintes, d‟autres améliorations peuvent être apportées au projet. En ce qui concerne
la côté ergonomique de l‟application, on peut utiliser l‟éditeur graphique « Resource Editor »
pour faire des interfaces plus conviviales et intuitives.
Ce projet nous a donné la possibilité de découvrir de nouvelles approches de développement

dédiées aux mobile et d‟utiliser de nouvelles technologies, telles que les web services, ainsi
que les librairies de composants graphiques (LWUIT) pour J2ME.
Pour ce qui est de perspectives, la démarche éco-citoyenne et la dématérialisation des services

peut toucher plusieurs domaines et pas nécessairement les cartes de fidélité seulement,
Taggist vise encore d‟autres segments tels que les tickets restaurants.
L‟expérience au sein d‟un cadre professionnel, nous a été bénéfique. Ce stage nous a permis
de nous familiariser à la vie professionnelle, d‟exploiter des notions fondamentales dans
l‟orienté objet, et d‟approfondir nos connaissances théoriques, acquises à l‟Institut Supérieur
d‟informatique, par la pratique de l‟informatique. Nous souhaitons que la société adopte
réellement notre application et essayera de la commercialiser.

ISI Annexes Taggist
Annexe
1. Systèmes d'exploitation utilisés par les Smartphones en 2009
1.1 Symbian OS
(41.2% Part de marché) (Licence open source).

Symbian dispose de la plus grande part de marché mondialement mais reste à la traine sur le
marché nord-américain. La part de marché de 50% est passée à 40% en 2010.
1.2 RIM BlackBerry OS
(18.2% Part de marché) (Source fermé, propriétaire).

Ce système fut créé à l'origine pour le marché des hommes d'affaires. Récemment, RIM a
favorisé la création d'application web et supporte les applications multimédia. A ce jour,
Blackberry's App World dispose de 6,000 applications.
1.3 Android de Google Inc.
( 17.2% Part de marché ) Android de Google Inc. fut développé par une petite startup qui fut
acheté par Google qui poursuit activement son développement. Android distribué sous licence
open source, est une variante de Linux. Google a lancé Open Handset Alliance qui regroupe
des grands constructeurs et développeurs de logiciels (tel que Intel, HTC, ARM, Samsung,
Motorola and eBay). Ce système est assez nouveau auprès des programmeurs. Il a eu six
version - Android 1.0, 1.5, 1.6, 2.0, 2.1 et 2.2. De 2009 au second trimestre 2010, la part de
marché de l'Android est passé de 1.8% to 17.2% avec un taux de croissance de 850%..
1.4 iOS de Apple Inc
( 14.2% Part de marché ) (closed source, propriétaire)
Le téléphone iPhone,l' iPod Touch et la tablette iPad utilisent tous le système d'exploitation
iOS, qui est dérivé de Mac OS X. Les applications tierces sont supportés depuis juillet 2008.
La boutique Apple propose 300 000 applications web.

ISI Annexes Taggist
1.5 Windows Mobile de Microsoft
( 5% Part de marché ) (closed source, propriétaire)
Le système Windows CE est largement distribué en Asie. Les deux variantes du système
d'exploitation Windows Mobile 6 Professional (for touch screen devices) etWindows Mobile
6 Standard lancé en février 2007 n'ont pas été adoptées.
La part de marché de Window mobile a décliné ces dernières années pour une part de marché
de 5% en 2010. Microsoft a remplacé son ancien système d'exploitation par windows 7
mobile.
1.6 Windows Phone de Microsoft
(Part de marché négligeable 2010)(closed source, propriétaire)
Le 15 février 2010 Microsoft a lancé un nouveau système d'exploitation pour mobile,

Windows Phone 7 .Il inclut des services de Microsoft comme Windows Live, Zune, Xbox
Live and Bing. Il intègre aussi des fonctionnalités média sociaux tel Facebook et Twitter.
Comme Windows Phone 7 est une nouvelle plate-forme, il n'existe aucune compatibilité avec
les applications Windows Mobile.
1.7 Linux
(2.4% Part de marché en 2010) (open source, GPL)
Linux a une bonne part de marché en Chine grâce à Motorola et au Japon avec la société
DoCoMo.
1.8 Bada de Samsung Electronics
(closed source, propriétaire) Ce système d'exploitation a été développé par la société

coréenne Samsung qui devrait être installé sur ses téléphones traditionnels. Confirmant, à
moyen terme la fusion des mobiles simples avec les Smartphones.

ISI Annexes Taggist
Le premier appareil qui exploite Bada est le 'Wave' et fut lancé en 2010. Il s'agit d'un
téléphone 100% tactile qui dispose d'une boutique appelé Samsung Apps. Cette boutique n'a
que 300 applications.[URL 20].
2. Calcul de checksum de L’EAN 13 :
Le calcul du digit de checksum de l'EAN 13 est très simple [URL 21]
 La lecture se fait de la droite vers la gauche
 Calculer la somme des nombres de positions paires et impaires
 Impaire : 1 + 3 + 5 + 7 + 9 + 1 = 26
 Paire : 2 + 4 + 6 + 8 + 2 = 22
Formule du checksum de l'EAN 13 :
( 10 - [ (3 * Impaire + Paire) modulo 10 ] ) modulo 10
Ainsi, l'exemple donne :
 (10 - [ (3 * 26 + 22) module 10 ] ) modulo 10

 (10 - [ (78 + 22) module 10 ] ) modulo 10
 (10 - [ (100) module 10 ] ) modulo 10
 (10 - [ 0 ] ) modulo 10
 (10 - 0) modulo 10
 10 modulo 10
 0
Donc le checksum de 210987654321 est 0.

ISI Glossaire Taggist
Glossaire
Toutes ces définitions sont issues de l‟adresse électronique suivante [URL 22]
RPC :
(Remote Procedure Call) est un protocole réseau permettant de faire des appels de procédures
sur un ordinateur distant à l'aide d'un serveur d'applications. Ce protocole est utilisé dans le
modèle client-serveur et permet de gérer les différents messages entre ces entités.
SOAP :
(ancien acronyme de Simple Object Access Protocol) est un protocole de RPC orienté objet
bâti 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.
JAX-RPC :
est l'abréviation de "Java API for XML-based RPC". Il s'agit d'une API Java (définie par Sun
Microsystems) permettant de transmettre des messages SOAP en mode RPC. La version
suivante a changé de nom : JAX-WS.
JAX-WS :
L'API Java pour les Web Services (JAX-WS) est un langage de programmation Java API pour
la création des web services. Il fait partie de la plate-forme Java EE de Sun Microsystems.
Comme les autres API Java EE, JAX-WS utilise les annotations, introduit dans Java SE 5,
pour simplifier le développement et le déploiement de clients de services Web et les
terminaux. Il fait partie de la Java Web Services Pack de développement.
Le code QR :
en anglais, QR code pour Quick Response) est un code-barres en deux dimensions (ou code à
matrice) constitué de modules noirs disposés dans un carré à fond blanc. Le nom QR est
l'acronyme de l'anglais Quick Response, car son contenu de données peut être décodé

ISI Glossaire Taggist
rapidement. Destiné à être lu par un lecteur de code-barres QR, un téléphone mobile, ou un

smartphone, il a l'avantage de pouvoir stocker plus d'informations qu'un code à barres
Le code EAN 13 :
(European Article Numbering à 13 chiffres) sont les codes à barres utilisés dans le monde
entier sur l'ensemble de produits de grande consommation (On utilise parfois le code EAN 8
pour les objets de petite taille). Ils comportent 13 chiffres dont la signification varie suivant le
type du produit.
 Les deux ou trois premiers correspondent au pays de provenance du produit, ou à une

classe normalisée de produits,
 les 4 ou 5 suivants sont le numéro de membre de l‟entreprise participant au système
EAN,
 les 5 suivants sont le numéro d‟article du produit ainsi marqué et
 le treizième est une clé de contrôle calculée en fonction des douze précédents.
GPS : Le Global Positioning System (GPS) – que l'on peut traduire en français par « système
de positionnement mondial » est un système de géolocalisation fonctionnant au niveau
mondial.
JQuery Mobile est un framework crée par le projet jQuery dont la première version est sortie
en octobre 2010. Il est actuellement disponible en version 1.0 alpha 4.1 (depuis le 7 avril) et
sous les licenses MIT et GPL2.Le principal atout de jQuery Mobile est sa compatibilité avec
un grand nombre de plateformes mobiles et navigateurs.
Sencha Touch : un framework HTML5 pour iOS et Android.

ISI Webographie Taggist
Webographie
[URL 1] http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/
[URL 2] http://www.chef-de-projet.org/methode/uml.htm
[URL 3] http://www.fidme.fr/accueil/
[URL 4] http://www.snapp.fr/fr/produits/snapp-fid/
[URL 5] http://www.fidall.com/
[URL 6] http://www.mobifid.com/
[URL 7]http://fr.wikipedia.org/wiki/Smartphone
[URL 8] ftp://ftp-developpez.com/pastel-pro/mobiles/frameworks/comparatif-
applications-smartphones-open-source/Frameworks-open-source-pour-applications-
smartphones-multiplateformes.pdf
[URL 9] http://blog.smile.fr/Appcelerator-annonce-la-sortie-de-Titanium-Studio-1.0
[URL 10] http://blog.smile.fr/Mobile/Developpement-mobile-cross-platform-avec-

PhoneGap
[URL 11] http://pastel-pro.developpez.com/mobiles/frameworks/comparatif-

applications-smartphones-open-source/
[URL 12] http://www.3ie.fr/nouvelles_technologies/fiche/fiche_J2ME.htm
[URL 13] http://fr.wikipedia.org/wiki/LWUIT
[URL 14] http://code.google.com/p/zxing/
[URL 15] http://code.google.com/p/geo-j2me/
[URL 16] http://fr.wikipedia.org/wiki/SOAP

ISI Webographie Taggist
[URL 17] http://ksoap2.sourceforge.net/
[URL 18] candle.enst-bretagne.fr/download/FIMATEX/wpp0802-1.pdf
[URL 19] defaut.developpez.com/tutoriel/java/eclipse/hibernate/
[URL 20] http://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27exploitation_mobile
[URL 21] http://barcode-coder.com/fr/specification-ean-13-102.html
[URL 22] http://fr.wikipedia.org/wiki/

ISI Bibliographie Taggist
Bibliographie
[Xavier 2006] : Xavier Blanc & Isabelle Mounier, UML 2 pour les développeurs, Eyrolles,
2006 ISBN 2-212-12029-5
[Anthony2008] : Anthony Patricio, Java persistence et Hibernate, Groupe Eyrolles, 2008

ISBN 978-2-212-12259-6
[Souilem2008] : A.Souilem, Rapport Développement de l‟application Mobile NEWS en

J2ME,2008 [ l‟Ecole Nationale des Sciences de l‟Informatique (ENSI)]
[Zhioua2010] : Zhioua Zeineb, Spécification, conception et réalisation d‟un système de E-

learning et de gestion des formations en ligne, 2010, [ L‟Ecole Nationale des Ingénieurs de
Tunis ]

Tirageriadh 140321042133 Phpapp01

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tirageriadh 140321042133 Phpapp01

Transféré par

Droits d'auteur :

Formats disponibles

Résumé :

Mots clés : J2ME, LWUIT, carte de fidélité, SOAP, ZXING, QRcode.

A Mes Très Chers Parents (Mohamed & Lilia)

Je vous rends hommage par ce modeste travail en guise de ma reconnaissance

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,

Nos vifs remerciements accompagnés de toute notre gratitude s'adressent également à

Application mobile pour la gestion des cartes de fidélité Page 1

Le premier chapitre intitulé « Présentation Générale» est consacré à la présentation du

Le chapitre « Etat de l‟art » s‟articule autour de l‟étude de quelques applications mobiles de

Le cinquième chapitre intitulé « Conception » détaille les différents aspects conceptuels de

En conclusion, nous mentionnons les différents atouts de ce projet et les perspectives

Application mobile pour la gestion des cartes de fidélité Page 3

Application mobile pour la gestion des cartes de fidélité Page 4

Ce chapitre est consacré pour la présentation de l‟entreprise d‟accueil, la précision du

3. Présentation de l’organisme d’accueil

TAGGIST est spécialiste de l‟intégration de Nouvelles Technologies. En étroite collaboration

Les activités de TAGGIST s‟articulent autour de 4 axes :

Application mobile pour la gestion des cartes de fidélité Page 5

Une liste non exhaustive des solutions développées est la suivante :

- TAGGIST®Immob : la solution de gestion des immobilisations vous donne la

Application mobile pour la gestion des cartes de fidélité Page 6

- TAGGIST®Eventent : C‟est une solution complète de gestion d'événement. De

Figure 1 : image simplifiant l’idée de notre projet

Application mobile pour la gestion des cartes de fidélité Page 7

4.1 Objectifs de l’application

- La possibilité pour un client d‟adhérer automatiquement à des nouvelles cartes de fidélité

4.2 Approches du travail

 Phase de conception et développement

Application mobile pour la gestion des cartes de fidélité Page 8

4.3 Méthodologie et formalismes adoptés

Nous avons opté pour ce choix dû à ces caractéristiques car il est :

Figure 2. Les phases d’un processus unifié

Application mobile pour la gestion des cartes de fidélité Page 9

Application mobile pour la gestion des cartes de fidélité Page 10

Chapitre II : Etat de l’art

Application mobile pour la gestion des cartes de fidélité Page 11

2. Les solutions mobiles disponibles sur le marché

La technologie mobile offre de multiples avantages en termes de fidélisation et

Innovante et simple à utiliser, FidMe vous permet d’enregistrer vos

Disponible pour les plates formes :

Figure 3. l’application FidMe

Application mobile pour la gestion des cartes de fidélité Page 12

Snapp' (ex Business Anywhere) est spécialisée dans le commerce mobile et

Informations personnelles : Vos clients peuvent consulter et éditer les

Identification du client : Le code-barres est affiché sur l'écran, le client peut

Consultation du solde : Vos clients peuvent consulter le solde de leur

Coupons et offres : Notifications ou consultation, les clients reçoivent

News : les dernières actualités de votre marque ou enseigne.

Geolocalisation : Aidez vos clients à trouver facilement l'établissement le

Disponible pour les plates formes : [URL 4]

Figure 5. L’application Fidall

Application mobile pour la gestion des cartes de fidélité Page 13

Enfin, Fidall vous offre la possibilité de consulter les soldes de points de

De plus, l‟application utilise la géo localisation. Fidall vous renseigne sur

Disponible pour les plates formes :

Cette application serait interfacée avec le

Disponible pour les plates formes :

Figure 6. L’application MobiFid

Application mobile pour la gestion des cartes de fidélité Page 14

Application mobile pour la gestion des cartes de fidélité Page 15

Chapitre III : Etude théorique et