Résumé - Academie pro téléchargement gratuit cours, tp ... · 2.3.1 Package web service ... 1.3 Android de Google Inc ... Figure 48. La liste des services déployés sur le serveur

Résumé :

L‟objectif principal de ce travail de PFE consiste à implémenter une solution mobile basée sur

la plate forme J2ME pour la gestion des cartes de fidélité

Cette Application permettra aux clients de conserver toutes leurs cartes de fidélités sur leurs

téléphones, consulter leurs soldes des points et géo localiser les enseignes dans lesquelles ils

pourraient utiliser ses cartes.

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

Abstract

This final of studies project aims to implement a mobile application based on J2ME plateform

to manage fidelity cards.

This application will allow customers keeping all their fidelity cards on their phones,

checking the number of points earned at any moment and geo locating the signboard in which

they could use their cards.

Keywords: J2ME, LWUIT, loyalty cards, fidelity card, SOAP, ZXING, QRcode.

Dédicaces

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

Tous les mots du monde ne sauraient exprimer l’immense amour que je vous

porte, ni la profonde gratitude que je vous témoigne pour tous les efforts et les

sacrifices que vous n’avez jamais cessé de consentir pour mon instruction et mon

bien-être.

C’est à travers vos encouragements que j’ai opté pour cette profession, et c’est à

travers vos critiques que je me suis réalisé.

J’espère avoir répondu aux espoirs que vous avez fondés en moi.

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

éternelle et de mon infini amour.

Que Dieu tout puissant vous garde et vous procure santé, bonheur et longue vie

pour que vous demeuriez le flambeau illuminant le chemin de vos enfants.

Je dédie aussi ce travail à :

Mes sœurs (Nourhouda, Sameh, Sonia ) pour leurs encouragements incessants.

Tous mes amis et spécialement (Lazhar, Mounir, Mahdi, Bilel, Noureddine,

Béchir, Wissem, Takwa, Islem et Asma), en souvenir des bons moments que nous

avons passés ensemble, pour leur soutien continu, leur aide précieuse et leur

amour.

Riadh Kort

Remerciement:

Le travail présenté dans ce mémoire a été effectué dans le cadre de la préparation du diplôme

d‟ingénieur spécialité « Génie du Logiciel et des Systèmes d‟Information » à l‟institut

Supérieur d‟informatique (ISI).

Au terme de ce projet, Nous tenons à exprimer notre profonde gratitude et notre immense

respect à Monsieur Achraf Gazdar, Maître assistant en informatique à l‟institut supérieur

d‟informatique pour sa disponibilité, ces avis éclairés, et ces judicieux conseils.

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

Monsieur AbdelKarim Friaa et Monsieur Lajili Abdeljaoued qui ont gardé un œil attentif

sur le déroulement et l‟avancement de notre projet, en ayant toujours des remarques très

constructives ainsi que pour la marque de confiance qu‟ils nous ont attribuée .Nous aimerons

témoigner du plaisir qu'était pour nous de travailler sous leurs directives.

Nous exprimons aussi notre gratitude à M. Oussama Frioui (Directeur Général de Taggist )

ainsi que l‟ensemble de l‟équipe de Taggist (Aymen, Elaa, Rahma, Basma, Islem,

Noureddine, Takwa, Amani, Béchir, Asma) pour leur chaleureux accueil et aide.

Avec beaucoup d'égard, nous ne manquerons pas d'exprimer notre grande reconnaissance à

tous les enseignants et administrateurs de l'Institut Supérieur d‟Informatique et tous les

membres du jury pour avoir accepté de juger ce modeste travail.

Sommaire Introduction Générale .............................................................................................................. 1

Chapitre I : Présentation Générale ......................................................................................... 4

1. Introduction ............................................................................................................. 5

2. Cadre du travail ....................................................................................................... 5

3. Présentation de l‟organisme d‟accueil ..................................................................... 5

4. Présentation du projet ............................................................................................. 7

4.1 Objectifs de l‟application .............................................................................. 8

4.2 Approches du travail ...................................................................................... 8

4.3 Méthodologie et formalismes adoptés ........................................................... 9

5. Conclusion ............................................................................................................. 10

Chapitre II : Etat de l’art ...................................................................................................... 11

1. Introduction ........................................................................................................... 12

2. Les solutions mobiles disponibles sur le marché .................................................. 12

2.1 FidMe .......................................................................................................... 12

2.2 Snapp‟Fid .................................................................................................... 13

2.3 Fidall ............................................................................................................ 13

2.4 Mobifid ........................................................................................................ 14

3. Critiques de l‟existant ............................................................................................ 15

4. Conclusion ............................................................................................................. 15

Chapitre III : Etude théorique et choix techniques ............................................................ 16

1. Introduction ........................................................................................................... 17

2. Etude Préliminaire ................................................................................................. 17

2.1 Smartphones et systèmes d‟exploitation pour mobiles ................................ 17

2.2 Problématique .............................................................................................. 19

2.3 Les Frameworks de développement mobiles multi-plateforme ................... 19

2.3.1 Comment ça marche ................................................................................ 19

2.3.2 Avantages ................................................................................................ 19

2.3.3 Inconvénients .......................................................................................... 20

2.3.4 Comparaison Technique .......................................................................... 21

2.3.4.1 PhoneGap ............................................................................... 22

2.3.4.2 Titanium (Appcelerator) ........................................................ 23

2.3.4.3 Rhodes (Rhomobile) .............................................................. 24

2.3.5 Outils ....................................................................................................... 25

2.3.6 Conclusion ............................................................................................... 25

2.4 Solution envisagée ....................................................................................... 26

2.5 Architecture adoptée .................................................................................... 26

3. Conclusion : ........................................................................................................... 27

Chapitre IV : Analyse et spécification des besoins ............................................................. 28

1. Introduction ........................................................................................................... 29

2. Analyse globale de l‟application ........................................................................... 29

2.1 Description des acteurs ................................................................................ 29

2.2 Spécification des besoins fonctionnels : ...................................................... 29

2.3 Spécification des besoins non fonctionnels ................................................ 30

2.4 Diagramme des cas d‟utilisation .................................................................. 31

2.5 Raffinement des cas d‟utilisation ................................................................. 33

2.5.1 Affectation des priorités .......................................................................... 33

2.5.2 Raffinement des cas d‟utilisation ............................................................ 33

2.5.2.1 Raffinement du cas d‟utilisation «gestion des cartes de

fidélité» ............................................................................................... 33

2.5.2.2 Raffinement du cas d‟utilisation «géo localiser les enseignes

proches du client» ............................................................................... 34

2.5.2.3 Raffinement du cas d‟utilisation «consultation du nombre de

points»……………… ........................................................................ 35

2.5.2.4 Raffinement du cas d‟utilisation «consulter les nouvelles

offres» ………………………………………………………………35

2.5.2.5 Raffinement du cas d‟utilisation « authentification» ............. 36

2.5.2.6 Raffinement du cas d‟utilisation «inscription» ...................... 36

2.5.2.7 Raffinement du cas d‟utilisation «procéder aux paiement » : 37

2.6 Diagramme d‟activité de navigation concernant le client ............................ 37

Chapitre V : Conception ........................................................................................................ 40

1. Introduction ........................................................................................................... 41

2. Conception détaillée .............................................................................................. 41

2.1 Le diagramme de classe ............................................................................... 41

2.1.1 Diagramme de classes de l‟application serveur Middleware .................. 41

2.1.2 Les classes de l‟application mobile ........................................................ 44

2.2 La base des données de l‟application ........................................................... 45

2.3 Architecture de la partie serveur .................................................................. 47

2.3.1 Package web service (Les méthodes distantes au niveau serveur) : ....... 48

2.4 Les diagrammes de séquence ....................................................................... 49

2.4.1 Le cas d‟utilisation « s‟authentifier » ...................................................... 49

2.4.2 Le cas d‟utilisation « inscription d‟un nouveau membre » ..................... 50

2.4.3 Le cas d‟utilisation « afficher la liste des cartes fidélité disponibles » .. 50

2.4.4 Le cas d‟utilisation « ajouter une nouvelle carte » ................................ 51

2.4.5 Le cas d‟utilisation « afficher les cartes de fidélité personnelles » ......... 52

2.4.6 Le cas d‟utilisation « géo localiser les enseignes sur une carte» ............ 53

2.4.7 Le cas d‟utilisation « visualiser le code à barre de la carte » .................. 54

3. Conclusion ............................................................................................................. 54

Chapitre VI : Réalisation ....................................................................................................... 55

1. Introduction ........................................................................................................... 56

2. Environnement de travail ...................................................................................... 56

2.1 Environnement matériel ............................................................................... 56

2.2 Environnement logiciel ................................................................................ 56

2.2.1 La plateforme « J2ME » .......................................................................... 57

2.2.1.1 Présentation............................................................................ 57

2.2.1.2 L'architecture J2ME ............................................................... 57

2.2.2 LWUIT .................................................................................................... 59

2.2.3 La bibliothèque Zxing (Zebra Crossing) ................................................. 61

2.2.4 La bibliothèque Geo-J2ME ..................................................................... 62

2.2.5 Web service ............................................................................................. 62

2.2.5.1 Définition du protocole SOAP............................................... 62

2.2.5.2 KSOAP 2 ............................................................................... 63

2.2.5.3 Apache Axis2......................................................................... 63

2.2.5.4 Hibernate................................................................................ 64

3. Interfaces de l‟application ..................................................................................... 65

4. Réalisation partie serveur ..................................................................................... 72

5. Conclusion ............................................................................................................ 73

Conclusion générale ............................................................................................................... 74

Annexes ……………………………………………………………………………………75

1. Systèmes d'exploitation utilisés par les Smartphones en 2009.............................. 75

1.1 Symbian OS ................................................................................................. 75

1.2 RIM BlackBerry OS .................................................................................... 75

1.3 Android de Google Inc. ................................................................................ 75

1.4 iOS de Apple Inc .......................................................................................... 75

1.5 Windows Mobile de Microsoft .................................................................... 76

1.6 Windows Phone de Microsoft ...................................................................... 76

1.7 Linux ............................................................................................................ 76

1.8 Bada de Samsung Electronics ...................................................................... 76

2. Calcul de checksum de L‟EAN 13 : ...................................................................... 77

Glossaire ……………………………………………………………………………………78

Webographie ........................................................................................................................... 80

Bibliographie ........................................................................................................................... 82

La liste des figures

Figure 1 : image simplifiant l‟idée de notre projet ........................................................... 7

Figure 2. Les phases d‟un processus unifié ...................................................................... 9

Figure 3. l‟application FidMe ......................................................................................... 12

Figure 4. L‟application Snapp‟Fid .................................................................................. 13

Figure 5. L‟application Fidall ......................................................................................... 13

Figure 6. L‟application MobiFid .................................................................................... 14

Figure 7.Part de marché en 2010 Smartphone par systèmes d'exploitation .................... 18

Figure 8. Schéma montrant le fonctionnement de PhoneGap ........................................ 20

Figure 9. Interface de l‟émulateur PhoneGap ................................................................. 22

Figure 10. l‟interface de lancement de Titanium ............................................................ 23

Figure 11.Interface de l‟émulateur Rhodes ..................................................................... 24

Figure 12. Architecture adoptée pour le développement de l‟application ...................... 27

Figure 13 . Diagramme de cas d‟utilisation de client ..................................................... 32

Figure 14. Diagramme d‟activité concernant le client. ................................................... 38

Figure 15. Schéma simplifiant les attentes du client et les principales fonctionnalités .. 39

Figure 16. Diagramme de classes de l‟application Middleware ..................................... 43

Figure 17. Les classes de l‟application sur le mobile ..................................................... 44

Figure 18. Schéma de la base des données ..................................................................... 46

Figure 19. Architecture détaillée de l‟application .......................................................... 48

Figure 20. Les méthodes déployées sur le serveur ......................................................... 48

Figure 21 . Diagramme de séquence pour le cas d‟utilisation « s‟authentifier » ............ 49

Figure 22. Diagramme de séquence pour le cas d‟utilisation « inscription nouveau

membre » ........................................................................................................................ 50

Figure 23. Diagramme de séquence pour le cas d‟utilisation « consulter la liste des

cartes disponibles » ......................................................................................................... 51

Figure 24. Diagramme de séquence du cas d‟utilisation « ajouter une nouvelle carte »52

Figure 25. Diagramme de séquence du cas d‟utilisation « afficher les cartes de fidélité

personnelles » ................................................................................................................. 53

Figure 26. Diagramme de séquence du cas d‟utilisation « géo localiser enseigne » ...... 53

Figure 27 . Diagramme de séquence du cas d‟utilisation « visualiser le code à barre de la

carte » .............................................................................................................................. 54

Figure 28. Architecture Logicielle de l‟application ........................................................ 56

Figure 29. Interface principal de LWUIT Demo présentant les principaux widgets

apportés avec LWUIT ..................................................................................................... 59

Figure 30. Interface montrant l‟effet rotation ................................................................. 60

Figure 31. interface montrant les possibilités graphiques avec LWUIT ........................ 60

Figure 32. Interface graphique de l‟application « Ressource Editor » ........................... 61

Figure 33. Schéma décrivant une communication client serveur en utilisant les web

service ............................................................................................................................. 62

Figure 34. Structure d‟un message SOAP ...................................................................... 63

Figure 35. Interface de lancement de l‟application ......................................................... 65

Figure 36. Interface d‟authentification ........................................................................... 65

Figure 37. Interface ajout nouveau membre ................................................................... 66

Figure 38. Interface questionnant le client de choisir entre visualiser ses cartes ou

ajouter d‟autres cartes. .................................................................................................... 66

Figure 39. Interface liste des cartes de fidélités disponibles ........................................... 67

Figure 40. Interface détails carte ..................................................................................... 68

Figure 41. Interface ajout d‟une carte ............................................................................ 68

Figure 42. Carte sélectionnée .......................................................................................... 69

Figure 43. Liste des cartes propriétaires ........................................................................ 69

Figure 44. Code 1D carte affiché .................................................................................... 70

Figure 45. QR code carte affiché .................................................................................... 70

Figure 46. Géo localisation vue satellite ......................................................................... 71

Figure 47. Géo localisation vue normal .......................................................................... 71

Figure 48. La liste des services déployés sur le serveur ................................................. 72

Figure 49. Exemple d‟un Soap Request et d‟un Soap Response. .................................. 72

La liste des tableaux

Tableau 1. Comparatif des solutions Phonegap, Titanium, Rhomobile ........................ 21

Tableau 2. Tableau comparatif mentionnant les possibilités offertes par les Os mobile et

celle des Frameworks. ..................................................................................................... 25

Tableau 3. Tableau d‟affectation des priorités ................................................................ 33

Tableau 4. Description du cas d‟utilisation « gestion des cartes de fidélité » ................ 34

Tableau 5. Description du cas d‟utilisation « géo localiser les enseignes proches » ...... 34

Tableau 6. Description du cas d‟utilisation « consultation du nombre des points » ...... 35

Tableau 7. Description du cas d‟utilisation « consulter les nouvelles et promotions » . 35

Tableau 8. Description du cas d‟utilisation « authentification » ................................... 36

Tableau 9. Description du cas d‟utilisation « inscription » ............................................ 37

Tableau 10. Description du cas d‟utilisation « procéder au paiement » ........................ 37

ISI Introduction générale Taggist

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

Introduction Générale



Le marché des applications mobiles connait un essor phénoménal et devient une véritable

manne financière pour les entreprises.

C‟est dans cette optique, que plusieurs entreprises telles que les supermarchés et les

hypermarchés n'ont pas hésité à exploiter les avancées technologiques pour offrir des services

innovants et rapides à leurs consommateurs.

Le seul et unique objectif était la recherche perpétuelle de solutions pratiques pour fidéliser

les clients et faciliter leurs achats.

Une idée ingénieuse est née : Inutile désormais de trimballer ses cartes de fidélité lorsqu'on

veut faire ses achats, depuis qu'une application mobile a été développée pour les Smartphones

et qui stocke toutes ces cartes.

Le contexte de notre projet est de proposer une solution mobile permettant d‟avoir toutes les

cartes de fidélité toujours avec le client, en les retrouvant sur son téléphone mobile.

Ce rapport présente l‟ensemble des étapes suivies pour développer la solution. Il contient six

chapitres organisés comme suit :

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

contexte du travail ainsi que l‟organisme d‟accueil.

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

gestion des cartes de fidélité et la présentation de leurs fonctionnalités offertes. Nous nous

sommes basés sur cette étude pour faire la spécification de notre application, qui fera l‟objet

du quatrième chapitre.

Le chapitre suivant intitulé « Etude théorique et choix techniques » contient une étude des

solutions techniques existantes sur le marché en mentionnant leurs avantages et leurs

inconvénients, pour finir par donner la solution retenue.

Dans le chapitre « Analyse des besoins et spécification », nous déterminons les besoins

fonctionnels et non fonctionnels de notre application et présentons les différents cas

d‟utilisation.



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

l‟application.

Le dernier chapitre intitulé « Réalisation » présente l‟environnement de travail ainsi que les

outils logiciels que nous avons utilisés pour la réalisation de notre projet. Il illustre aussi le

travail réalisé avec un ensemble d‟interfaces graphiques conçues pour l‟application.

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

d‟améliorations possibles.

ISI Présentation Générale Taggist


Chapitre I : Présentation

Générale



1. Introduction

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

cadre du projet et la problématique puis l‟énumération des étapes de travail à réaliser pour

achever ce projet.

2. Cadre du travail

Ce stage s‟inscrit dans le cadre d‟un projet de fin d‟études pour l‟obtention d‟un diplôme

d‟ingénieur informatique de l‟Institut Supérieur d‟Informatique. Notre stage a été effectué au

sein d‟une Société de Services en Ingénierie Informatique (SS2I) « TAGGIST ».

Le sujet est intitulé "Conception et développement d‟une application mobile d‟un

programme de fidélité multi enseignes ".

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

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

avec les cabinets de conseil, les fabricants de matériel et les éditeurs logiciels, C‟est une

compagnie d‟intégration des technologies et des systèmes d‟innovation, spécialisée dans le

développement des applications mobile, ingénierie logicielle, développement d‟applications

web.

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

- Prestations de conseil.

- Intégration de solutions RFID, codes à barres, NFC, biométrie et GPS.

- Développement de produits et de solutions spécifiques.

- Distribution de matériels et consommables.



TAGGIST est composée de deux groupes. Le premier groupe est spécialisé dans le

développement des solutions mobile. Le deuxième est spécialisé dans le développement des

applications web sur la plateforme J2EE. Elle est implantée dans la ville Charguia-Tunis et

la ville Kairouan.

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

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

possibilité de situer géographiquement votre parc mobilier et/ou informatique et

d‟automatiser l‟inventaire.

- TAGGIST®Doc : c‟est une solution de suivi des mouvements d‟ouvrages et/ou de

documents papiers. L‟idée est ici d‟équiper des documents d‟étiquettes RFID. Ainsi,

ils seront décrits dans notre logiciel, puis identifiés sur le lecteur de table.

- TAGGIST®Localisation: elle permet aux utilisateurs de suivre en temps réel et à

intervalle de temps régulier (paramétrable de 0.2 secondes à quelques minutes)

l‟identification des éléments devant être surveillés et alerter les responsables

prédéfinis par Mail et/ou SMS lorsqu‟un élément quitte sa zone de localisation

prédéfinie.

- TAGGIST®Time&Pointage : c‟est une solution de gestion du temps et de pointage

par empreinte digitale et/ou badges RFID (sans contact). Elle offre une gestion

rigoureuse des événements de présences et d‟absences à travers une liaison

automatique à une ou plusieurs pointeuses Biométriques (par Empreinte Digitale).

- TAGGIST®Security: c‟est une solution à la pointe de technologie adaptée pour des

expositions temporaires, galeries et collections privées, des musées ou collections

importantes.

- TAGGIST®GPS: cette solution est basée sur une balise GPS/GSM de tracking et de

secours, autonome et de très petite taille qui peut fonctionner en mode GPRS ou SMS.

- TAGGIST®GMAO : ce logiciel intègre toutes les fonctionnalités attendues d'un

logiciel de GMAO en conformité avec les normes qualités appliquées dans les

entreprises (normes ISO). Le logiciel TAGGIST®GMAO est d‟une implantation

simple et rapide. En outre, il est totalement paramétrable pour tout type d‟entreprise.

Les menus, les écrans, les documents ou les graphiques sont personnalisables par

chaque utilisateur.



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

l'édition du badge électronique, à l'utilisation de celui-ci aux entrées de salles, sur les

stands des exposants ou pour le contrôle de services.

- TAGGIST®Santé : Solution en cours de développement

- TAGGIST®Textile : Solution en cours de développement

- TAGGIST®TGGYNET : Solution basée sur la technologie NFC (Near Field

Communication). Cette solution est confidentielle et prouve les compétences de notre

équipe et la qualité de nos dirigeants de fournir des solutions Innovantes et à la pointe

de la technologie. En effet, cette solution est lauréate au concours international

SIMAGINE 2009.

Le site web de la société TAGGIST est : www.taggist.fr

4. Présentation du projet

Les avantages des cartes de fidélité sont nombreux aussi bien pour les clients à travers les

réductions appliqués sur leurs achats et la collecte des points de fidélité, que pour les sociétés

qui préservent à long terme leurs parts dans le marché et leurs rentabilités.

Mais le nombre de ses cartes a augmenté d‟une façon exponentielle, ce qui rend impossible

de pouvoir les transporter toujours sur soi. Nous proposons comme solution une application

mobile multi-enseignes qui a comme objectif de limiter la multiplication des supports

papiers. L'idée est simple : Enregistrer toutes ses cartes de fidélités sur son Smartphone pour

les avoir toujours sur soi. Lors du passage en caisse, le code barre de la carte de fidélité est

présenté sur l'écran du téléphone.

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

http://www.taggist.fr/



4.1 Objectifs de l’application

- Permettre le client d‟avoir toutes ses cartes de fidélité toujours sur soi.

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

depuis son téléphone mobile.

- Informer les clients sur les nouvelles offres existantes à fin de bénéficier de tous les

avantages et réductions liées.

- Visualiser sur une carte géographique, les enseignes dont le client possède une carte de

fidélité ------

-Consulter le solde de points à travers un compte en ligne ou à travers le téléphone mobile.

4.2 Approches du travail

Le projet comprend deux phases : la première est la recherche d‟une solution convenable pour

réaliser l‟application, et la deuxième, la phase de conception et de développement.

Phase de recherche

C‟est l‟étape qui inclut l‟étude bibliographique, dans laquelle nous devons saisir les

différentes notions et technologies à utiliser dans le projet, les architectures, etc.

Aussi, elle renferme les tests des différentes solutions mises en hypothèse pour réaliser

l‟application, et nous fixons les outils nécessaires pour la réalisation du projet.

Phase de conception et développement

C‟est une étape, dans laquelle, nous spécifions les besoins fonctionnels et nous modélisons le

système à réaliser pour clarifier les tâches à accomplir dans la partie développement.

Cette phase se termine par une partie qui comprend la programmation et les tests de

validation.



4.3 Méthodologie et formalismes adoptés

Nous allons adopter la méthode agile : Rational Unified Process comme un processus de

développement logiciel.

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

Itératif.

centré sur l'architecture.

piloté par des cas d'utilisation et orienté vers la diminution des risques.[URL 1]

Figure 2. Les phases d’un processus unifié

conceptuels tels que les acteurs, les processus métiers, les activités et les composants du

système, ainsi que les éléments concrets tels que les langages de programmation, les schémas

de bases de données, etc. [URL 2]

Expression des besoins

Analyse

ConceptionImplémentation

Test



5. Conclusion

Dans ce chapitre introductif, nous avons présenté l‟organisme d‟accueil ainsi que le projet à

réaliser. Nous allons entamer maintenant la phase de préparation de ce projet qui est l‟étude

de l‟existant et la présentation des différentes solutions disponibles sur le marché.

ISI Etat de l’art Taggist


Chapitre II : Etat de l’art



1. Introduction

Ce chapitre a pour objet de présenter quelques applications mobiles pour la gestion des cartes

de fidélité d‟une manière détaillée, en exposant leurs fonctionnalités.

2. Les solutions mobiles disponibles sur le marché

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

communication client pour les enseignes :

- Augmenter et faciliter l'adhésion au programme de fidélité.

- Dématérialiser la carte de fidélité .

- Proposer des coupons de réduction dématérialisés

-Réduire les coûts et délais d‟une campagne ciblée de communication (moins de

plastique, moins de papier, gain de temps, gratuité des notifications).

Le marché présente une panoplie des solutions informatiques dédiées à la gestion des cartes

de fidélité, que nous présentons ci-après.

2.1 FidMe

FICHE TECHNIQUE :

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

cartes de fidélité en quelques secondes. Grâce à son outil de

reconnaissance de code barre, vous passez votre carte devant

l’objectif de votre mobile (sur certains modèles) ou saisissez votre

numéro client et le tour est joué !

Disponible pour les plates formes :

Figure 3. l’application FidMe

[URL3]



2.2 Snapp’Fid

2.3 Fidall

Fiche technique :

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

la dématérialisation de programmes de fidélité.

Informations personnelles : Vos clients peuvent consulter et éditer les

informations de leur compte (suivant vos spécifications).

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

alors être scanné en caisse ou présenter son code en magasin.

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

programme de fidélité et ses détails, mais également les derniers achats et

les primes acquises.

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

directement leurs coupons et offres personnalisées utilisables en magasin.

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

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

plus proche grâce aux outils de cartographie type GPS en temps réel.


Figure 4. L’application

Snapp’Fid

[URL 4]

Figure 5. L’application Fidall



2.4 Mobifid

Fiche technique :

Fidall vous permet tout d‟abord d‟enregistrer gratuitement une fois pour

toutes vos cartes de fidélité, afin de les retrouver sur votre téléphone mobile

Vous pourrez ensuite pour certaines cartes adhérer d‟un simple clic. Fidall

se charge de transmettre votre demande d‟adhésion à la boutique ou

enseigne de votre choix.

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

certains programmes de fidélité, depuis une interface unique.

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

les enseignes dont vous possédez la carte de fidélité et qui se trouvent près

de votre position.


Mobifid propose aux enseignes de

dématérialiser leurs programmes de fidélité sur

téléphone portable.

L'application Mobifid est brindée aux couleurs

de l'enseigne. Elle permet au consommateur de

gérer sa carte de fidélité, recevoir des coupons

de réductions, cumuler des points, consulter le

catalogue cadeau....

Cette application serait interfacée avec le

système d'information de l'enseigne.


Figure 6. L’application MobiFid

[URL 5]

[URL 6]



3. Critiques de l’existant

Quelle que soit la technologie utilisée ou les services supplémentaires apportés aux

consommateurs par ces solutions, un enjeu majeur reste l'intégration de la solution aux

systèmes d'information de l'enseigne. La remontée d'informations doit être efficace et

pertinente. Les données remontées par ces applications doivent être intégrées au SGBD de

l'enseigne.

De plus, nous constatons que la plupart des firmes offrant ces applications, présentent une

version ciblée pour chaque Os mobile (ex : offrir une application développé avec Objective C

sur l‟Apps Store pour les SmartPhone iPhone, une autre version téléchargeable depuis

l‟Android Market faite avec Java pour des appareils supportant Android, d‟autres dédiées

aux Blackberry etc.).

Nous cherchons à développer une solution générique qui serait compatible avec toutes les Os

mobiles disponibles sur le marché sans être obligé à reprendre le travail de développement

pour chaque plateforme.

4. Conclusion

Dans ce chapitre nous avons essayé d‟étudier quelques applications mobiles de gestion des

cartes de fidélité dans le but d‟avoir une idée sur les fonctionnalités de ces dernières et de

ressortir leurs points forts. Sur la base de cette étude, nous allons élaborer la spécification de

notre application. Une étude théorique sur les plates formes open source dédiées pour des

applications Smartphones fonctionnant sur plusieurs Os mobiles fera l‟objet du chapitre

suivant.

ISI Etude théoriques et choix techniques Taggist


Chapitre III : Etude théorique et

choix techniques



1. Introduction

Ce chapitre est décomposé en trois sections importantes. Tout d‟abord, une étude

préliminaire sur les Smartphones, les Framework dédiés pour le développement mobile multi-

plate formes, et par la suite le choix de la solution technique à adopter. Et enfin, une vue

globale sur la plateforme du projet.

2. Etude Préliminaire

2.1 Smartphones et systèmes d’exploitation pour mobiles

Un Smartphone, un téléphone intelligent ou un ordiphone est un téléphone mobile qui offre

des fonctions d'un « Personal digital Assistant ». Il fournit les fonctionnalités d'agenda, de

navigation web, de calendrier, de consultation de courrier électronique, de messagerie

instantanée et du GPS (Global Positioning System). Un Smartphone peut aussi permettre

d'installer des applications additionnelles sur l'appareil. Ces applications peuvent être

développées par l'opérateur, par le fabricant ou par n'importe quel autre éditeur de logiciel.

Vu la grande importance des téléphones intelligents, une grande variété d‟entreprises se place

dans le marché des Smartphones en développant des systèmes d‟exploitation pour mobiles.

Vers la fin de l‟année 2007, les systèmes d'exploitation les plus répandus dans le monde sont:

Symbian (racheté par Nokia) tout en occupant 67 % de parts de marché.

Windows Mobile (développé par Microsoft) avec 13 % de parts de marché.

BlackBerry avec 10 % de parts de marché.

iPhone OS développé par Apple sur l'iPhone avec 7 % de parts de marché.

Palm OS : encore présente sur quelques Treo.

Linux tel que LiMo et OpenMoko.

J2ME (Java 2 Micro Edition) est une technologie Java spécialement adaptée au

développement des applications sur des appareils mobiles (tel que des PDA, des

téléphones cellulaires, des systèmes de navigations pour voiture, etc.), à capacités

limitées en termes de processeur, mémoire, affichage et saisie.

http://fr.wikipedia.org/wiki/Syst%C3%A8mes_d%27exploitation

http://fr.wikipedia.org/wiki/Symbian_OS

http://fr.wikipedia.org/wiki/Nokia

http://fr.wikipedia.org/wiki/Windows_Mobile

http://fr.wikipedia.org/wiki/Microsoft

http://fr.wikipedia.org/wiki/BlackBerry

http://fr.wikipedia.org/wiki/IPhone_OS

http://fr.wikipedia.org/wiki/Apple

http://fr.wikipedia.org/wiki/IPhone

http://fr.wikipedia.org/wiki/Palm_OS

http://fr.wikipedia.org/wiki/Treo

http://fr.wikipedia.org/wiki/Linux

http://fr.wikipedia.org/wiki/LiMo

http://fr.wikipedia.org/wiki/OpenMoko



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

http://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27exploitation

http://fr.wikipedia.org/wiki/Open_source

http://fr.wikipedia.org/wiki/Google

http://fr.wikipedia.org/wiki/2009

http://fr.wikipedia.org/wiki/Palm_pr%C3%A9

http://fr.wikipedia.org/wiki/Palm_webOS



http://fr.wikipedia.org/wiki/Blackberry



http://fr.wikipedia.org/wiki/Android



http://fr.wikipedia.org/wiki/Android

http://fr.wikipedia.org/wiki/Blackberry


http://fr.wikipedia.org/wiki/Palm_webOS

http://fr.wikipedia.org/wiki/Linux


http://fr.wikipedia.org/wiki/Bada

http://fr.wikipedia.org/wiki/Samsung

http://fr.wikipedia.org/wiki/MeeGo

http://fr.wikipedia.org/wiki/Intel

http://fr.wikipedia.org/wiki/Nokia



2.2 Problématique

Cette diversité au niveau des plateformes mobiles, met les sociétés éditrice des logiciels dans

l‟embarras du choix de l‟environnement du développement.

Taggist a pensé dans un premier lieu à concevoir une application mobile multi-plate forme,

c'est-à-dire compatible et fonctionnelles sur plusieurs os de smartphones (iphones,

android,etc.)

Ceci devient de plus en plus possible pour des petites applications simples grâce aux

nombreux Frameworks open source dédiées pour des applications Smartphones

multiplateforme. Ces applications sont développées avec des langages destinés au web (de

plus en plus, html5 et JavaScript).

2.3 Les Frameworks de développement mobiles multi-plateforme

2.3.1 Comment ça marche

Malgré le fait que chaque Smartphone parle une langue totalement différente que les autres,

ils partagent un grand avantage, c'est qu'ils ont tous un navigateur web, afin qu'ils

comprennent tous HTML, CSS et JavaScript. Donc, c'est le point d'entrée pour toute

technique de ciblage multiplateforme. La Figure 8 illustre un exemple concret de

fonctionnement de PhoneGap, l‟un de ces Frameworks mobiles

2.3.2 Avantages

- Ecrire avec des technologies de développement web, au lieu de l'apprentissage de chaque

Framework.

- "Write once run every where" (en fait ce n'est pas de cette façon que les choses se passent,

la plupart du temps, c'est «Write once debug every where").

Donc, pas de phase d'apprentissage pour chaque plate-forme, et pas de temps de

développement supplémentaire pour le portage à chaque plate-forme, seul un petit effort pour

un déploiement sur des plateformes différentes.



Figure 8. Schéma montrant le fonctionnement de PhoneGap

2.3.3 Inconvénients

- Plus approprié pour les applications orientées données, mais moins efficace dans les

applications multimédia riches.

- Pas de support pour les jeux.

- Un rendement inférieur par rapport aux technologies indigènes et natives.

- Le Look & Feel est le même sur toutes les plateformes: la quasi-totalité de ces Framework

ont décidé de fonder l‟apparence de leurs composants graphiques similaires à celle de

l'iPhone. Bien que cette décision permet de créer des applications presque identiques à des

applications natives sur l'iPhone, mais cela risque de décevoir ou de frustrer certains



utilisateurs de BlackBerry et / ou Android qui sont familiarisés avec ces environnement.

[URL10 ]

2.3.4 Comparaison Technique

Nous allons étudier les 3 principales technologies de base à savoir: Phone gap, Titanium, et

Rhodes .Le tableau Tableau 1 représente un comparatif de solutions open source pour créer

des applications pour smartphones qui seront fonctionnelles sur plusieurs OS .[URL 11]

Produit PhoneGap Titanium Appcelerator RhodesRhomobile

Licence Open-source (MIT

License)

Open-source (Apache

Public v2.0)

Open-source (MIT

License)

Prix Gratuit Gratuit / $499 Gratuit / $1000

Smartphones iPhone, Android,

BlackBerry,

Symbian, Palm

Phone, Android iPhone, BlackBerry,

Windows Mobile,

Symbian et Android

Langages HTML,

JavaScript, CSS

HTML, JavaScript, CSS HTML, Ruby

Apparence

native

non oui oui

Déploiement manuel manuel RhoSync

Tableau 1. Comparatif des solutions Phonegap, Titanium, Rhomobile



2.3.4.1 PhoneGap

Figure 9. Interface de l’émulateur PhoneGap

Description :

PhoneGap crée des applications mobiles utilisant les technologies web seulement: HTML,

CSS et JS. Une application Téléphone n'est pas si différent d'une application web en mode

Ajax: les pages ne sont jamais (ou rarement) rafraîchie, et l'interface et l'application sont gérés

entièrement en JavaScript.

Ce choix de technologies signifie que PhoneGap peut être utilisé seuls pour des applications

simples, ou peut être combiné avec des framework JavaScript comme Sencha Touch, jQuery

Mobile ou avec un langage mobiles tels que MOBL . Ces Framework aident à développer des

applications avec des interfaces utilisateurs riches, intuitives et conviviales.

L'avantage du Framework PhoneGap est clair: le développement est rapide et plusieurs

plates-formes le supportent.

http://www.sencha.com/products/touch/

http://www.sencha.com/products/touch/

http://jquerymobile.com/



http://www.mobl-lang.org/



Inconvénients :

Malgré le fait que JavaScript soit largement utilisé, l'expérience de l'utilisateur dépend

beaucoup de la puissance de l'appareil et l'accélération de certaines fonctions au

niveau du matériel. Certains téléphones Android, par exemple, offrent une interaction

rapide et de qualité élevée, tandis que d'autres offrent une expérience plus limitée et

presque lente.

2.3.4.2 Titanium (Appcelerator)

Figure 10. l’interface de lancement de Titanium

Description : Les applications faites avec Titanium sont compilées pour l'OS de destination.

Elles paraissent donc plus natives que celles développées avec PhoneGap et sont moins

gourmandes en ressources.

Inconvénients :

Il n'est pas toujours facile de construire un code qui fonctionne sur Android et

iPhone. Certains composants sont parfois présents sur une plate-forme, mais pas

forcément sur l'autre, certains comportements ne sont pas les mêmes sur l'un ou

l'autre.



2.3.4.3 Rhodes (Rhomobile)

Figure 11.Interface de l’émulateur Rhodes

Description :Rhodes est basé sur un modèle complètement différent: chaque application

mobile embarque un VM Ruby, un framework minuscule basé sur le modèle MVC sur Ruby

on Rails et un serveur Web simplifiée. Il supporte une large gamme d'appareils: la version

BlackBerry 4,6 +, 5.x, 6.x, Android, IOS et Windows Mobile.

Inconvénient :

Caractéristiques Graphique: Avec Rhodes, les vues sont créées sous forme de pages

HTML. Il y a des composants natives que nous pouvons accéder. jQTouch (un

plugin JQuery pour le développement mobile) est également intégré, mais dans

l'ensemble, les applications créées ont une apparence plus proche du "web" et moins

"native" et pas nécessairement conviviales.

Vitesse d’exécution lente: l‟intégration d'une Machine virtuelle Ruby, un petit

serveur web qui envoie des pages HTML à un navigateur rend la vitesse d‟exécution

plus lent. Le démarrage de l'application, est en particulier, plus lent que sur les autres

outils. Le temps de latence est important.



2.3.5 Outils

Rhodes : apporte avec lui un cœur dédié pour la construction et le paquetage des applications

et possède un éditeur web web tool pour accomplir ses tâches.

Phonegap : dépend des outils de développement natives intégrés avec chaque plateforme

SDK, xCode pour iPhone, le plugin Eclipse pour Blackberry

Titanium : possède un puissant environnement de développement intégré pour la construction

des applications mobiles.

2.3.6 Conclusion

Application Native sur différent Os

mobile

Application Web(Mobile

Apps Cross Platform)

Performance

Performance et capacité

Accès restreints aux ressources

du téléphone Toutes les

Fonctionnalités ne sont pas

accessibles et supportées. (limite

du navigateur)

Téléchargement

de l’application

Disponible pour le téléchargement

dans les Apps store, Android Market

(après approbation de l’administrateur

du site)

Sans processus d‟approbation.

Problème d‟identification de

l‟application par l‟utilisateur

Mode de

fonctionnement

Mode offline / online Doit être en mode online

Apparence Apparence native Pas nécessairement

Complexité de

l’application

complexe Dédiée pour des applications

simple

Tableau 2. Tableau comparatif mentionnant les possibilités offertes par les Os

mobile et celle des Frameworks.



2.4 Solution envisagée

Tenant compte de cette étude, nous avons jugé que ces Framework sont des solutions non

fiables surtout avec des applications complexes et gourmandes en ressources. Alors, la

sélection d‟une de ces plateforme serait un risque potentiel qui pourra engendrer des résultats

inattendues.

Suite à cette constatation, nous avons choisi de travailler avec la plate forme J2ME et de

reprendre la même application sur les autres environnements (Blackberry, iPhone, Android )

avec d‟autres collègue.

2.5 Architecture adoptée

La Figure 12 illustre l‟architecture à adopter pour notre application. Tout d‟abord, notre

projet sera défalqué en trois modules :

- Une partie cliente : elle consiste à la réalisation des différentes interfaces de l‟application

mobile ainsi que l‟interprétation des données fournis et leurs affichages.

- Une partie serveur : Cette partie permet l‟alimentation de la partie cliente avec les données.

De plus, elle permet l‟insertion, la consultation des données et la mise à jour de l‟application

cliente.

- Une partie d’interconnexion entre le client et le serveur : Ce module permet de mettre en

correspondance l‟interaction entre les différents intervenants de l‟application et assure la

communication entre eux..



Figure 12. Architecture adoptée pour le développement de l’application

3. Conclusion :

Nous avons présenté dans ce chapitre une idée sur l‟architecture à adoptée dans notre projet. De

plus, nous avons présenté la solution retenue et les technologies à utiliser. Une étude plus

approfondie sera présentée dans les prochains chapitres. L‟analyse des besoins et la spécification

feront l‟objet du chapitre suivant.

ISI Analyse et spécification des besoins Taggist


Chapitre IV : Analyse et

spécification des besoins



1. Introduction

La phase d‟analyse et spécification des besoins présente une étape primordiale dans le cycle

de développement d‟un projet. En effet, elle permet de mieux comprendre le travail demandé

en dégageant les besoins des différents utilisateurs que le système doit accomplir.

2. Analyse globale de l’application

L‟objectif de notre travail est de concevoir et développer une application mobile pour un

programme de fidélité multi-enseignes qui permettra à un client connecté à partir du site ou de

son mobile(J2ME) de gérer ses cartes.

2.1 Description des acteurs

Cette section a pour objet de présenter les acteurs et leurs fonctionnalités à lesquelles doit

répondre notre application. Nous commençons notre analyse par identifier les acteurs qui

agissent sur notre système à savoir :

Le client : Le client est un acteur principal qui interagit avec notre application. Cette

personne bénéficie de toutes les fonctionnalités de l‟application en mode connecté ainsi qu‟en

mode non connecté.

L’enseigne : c‟est un acteur principal qui intervient seulement dans la partie web. Il présente

ses différentes agences, boutiques, dans le but d‟exposer leurs cartes de fidélité.

L’administrateur : joue un rôle primordial dans l‟assurassions du bon fonctionnement du

système. C‟est la personne qui prend en charge la gestion des comptes des utilisateurs (les

clients et les enseignes) ainsi que la gestion des cartes fidélités sur lesquelles portent les

traitements des différents utilisateurs (ajout, adhésion, suppression, modification…) et la

gestion des promotions.

2.2 Spécification des besoins fonctionnels :

Le Client :

Il accède à l‟application sur son téléphone mobile pour :



Ouvrir un compte sur cette application s‟il n‟est pas encore inscrit.

Ajouter une carte de fidélité sur son mobile (saisir les détails de la carte : nom,

prénom, N° de la carte)

Choisir l‟une de ces cartes de fidélités déjà acquis.

Adhérer à une nouvelle carte de fidélité.

Géo localiser les enseignes proches dont il possède une carte de fidélité.

Retrouver le solde des points de certaines cartes de fidélité.

Procéder aux paiements des cartes sélectionnées.

L’enseigne peut :

Gérer ses cartes :

o Consulter la liste de ses cartes.

o Ajouter une carte avec spécification du nombre des points offerts,

délais de validité de la carte...

o Modifier la description d‟une carte.

o Supprimer une carte.

Gérer les offres :

o Consulter la liste de ses offres.

o Ajouter une nouvelle offre (délai de l‟offre, description de l‟offre).

o Modifier une offre (délai, détails).

o Supprimer une offre.

L’administrateur peut :

Gérer les comptes des utilisateurs: ajout, modification, suppression,

consultation d‟un compte utilisateur.

Gérer les cartes : ajout, modification, suppression, consultation d‟une carte.

Gérer les offres sur les cartes : ajout d‟une nouvelle offre, modification d‟une

offre, suppression d‟une offre lors ce qu‟elle dépasse la date limite.

2.3 Spécification des besoins non fonctionnels

Après avoir déterminé les besoins fonctionnels nous présentons ci-dessous l‟ensemble des

contraintes à respecter pour garantir la performance du système, donc de fournir un produit



performant qui respecte les exigences de l‟utilisateur et qui peut faire face à des risques de

panne ou de non fonctionnement.

Performance :

Afin d‟être acceptée par le client, notre application doit respecter ce critère tout en assurant

un temps de réponse minimum et des fonctionnalités rependant aux besoins de l‟utilisateur.

La simplicité:

Un visiteur assez modeste pourra utiliser un tel service de façon intuitive.

L’ergonomie de l’interface :

Les interfaces doivent être simple et conviviale : On doit essayer le maximum d‟éliminer

l‟encombrement.

La modularité de l’application :

Avoir un code simple facile à maintenir et à comprendre en cas de besoin.

2.4 Diagramme des cas d’utilisation

La Figure 13 illustre les différentes fonctionnalités offertes pour le client à travers notre

application mobile.



Figure 13 . Diagramme de cas d’utilisation de client

s'authentifier

Finaliser profil

chercher une carte Ajouter une carte

Supprimer une carte

Adhérer à une carte

Visualiser les détails d'une carte

Modifier les détails d'une carte

<<include>>

Choisir une carte

Choisir une carte par points

Choisir une carte par pourcentage

Inscription

<<include>>

<<extend>>

Géolocaliser les enseignes

<<include>>

Consulter les offres et les promotions

<<include>>

Déconnexion

Procéder au paiement<<include>>

Gérer les cartes

<<include>>

Consulter le solde des points

Client

<<include>> <<extend>>



2.5 Raffinement des cas d’utilisation

2.5.1 Affectation des priorités

A cette étape de cycle de développement, il est nécessaire de déterminer les cas d‟utilisation

les plus prioritaires. Le choix repose sur la dépendance des cas d‟utilisation, de l‟activité de

l‟entreprise et des choix des utilisateurs.

Cas d’utilisation Acteur priorité

S’authentifier Client 2

Inscription Client 2

Gestion des cartes de

fidélité

Client 1

Consultation des nombres

de points

Client 1

Géo localiser les enseignes

proches de client

Client 1

Consulter les nouvelles

offres

Client 1

Procéder aux paiements Client 2

Tableau 3. Tableau d’affectation des priorités

2.5.2 Raffinement des cas d’utilisation

2.5.2.1 Raffinement du cas d’utilisation «gestion des cartes de fidélité»

Nom du cas d'utilisation Gestion des cartes de fidélité

Acteurs Client

Pré condition Le système fonctionne et l‟utilisateur est authentifié

Post condition Le client pourra ajouter, supprimer, et modifier les détails de ces

cartes de fidélité.

Scénario principal 1. Le système présente les différentes cartes de fidélité

existantes.

2. Le client pourra soit ajouter ou adhérer à une carte.

3. Dans le cas d‟ajout, le client doit insérer le code de sa

carte déjà acquise et quelques renseignements.

4. Dans le cas d‟adhésion, les détails de la carte seront

affichés et un code à barre est généré automatiquement.

5. Le client peut modifier ou supprimer les cartes

enregistrées dans son profil.



Exceptions

Le système affiche un message d‟erreur dans le cas où :

-Les données introduites par le client sont incohérentes. Par

exemple : un code à barre contenant des caractères alphabétiques.

-le client ne remplit pas tous les champs obligatoires.

-le code à barre de la carte ajouté est inexistant dans la base des

données.

Tableau 4. Description du cas d’utilisation « gestion des cartes de fidélité »

2.5.2.2 Raffinement du cas d’utilisation «géo localiser les enseignes proches du client»

Nom du cas

d'utilisation

Géo localiser les enseignes proches

Acteurs Client

Pré condition Le système fonctionne. -

l‟utilisateur est authentifié et possède au moins une carte de

fidélité.

Post condition Le système pourra trouver facilement les enseignes les plus

proches grâce aux outils de cartographie type GPS en temps réel.

Scénario principal 1. Le système présente les différentes cartes de fidélité du

client.

2. Le client choisit une de ses cartes.

3. Le système montre une carte contenant des marqueurs

indiquant l‟emplacement des enseignes et la façon d‟y accéder.

4. Les offres doivent être aussi géo localisée.

Exceptions

Le système se plante s‟il est n‟arrive pas à accéder aux services

GPS pour identifier l‟emplacement actuel du client et les

enseignes proches du lieu.

Tableau 5. Description du cas d’utilisation « géo localiser les enseignes proches »



2.5.2.3 Raffinement du cas d’utilisation «consultation du nombre de points»

Nom du cas d'utilisation Consultation du nombre de points

Acteurs Client


l‟utilisateur est authentifié et possède au moins une carte de

fidélité.

Post condition Le client pourra consulter son cumul des points de fidélité

collectés chez l‟un des enseignes.


client.


3. Le client consulte l‟ensemble des points de fidélité

collectés et ses détails, Il pourra également visionner

l‟historique de ses derniers achats et les primes acquises.

Exceptions

Le système affiche un message d‟erreur si la connexion avec le

serveur base des données est inaccessible.

Tableau 6. Description du cas d’utilisation « consultation du nombre des points »

2.5.2.4 Raffinement du cas d’utilisation «consulter les nouvelles offres»

Nom du cas d'utilisation consulter les nouvelles offres et promotions

Acteurs Client


L‟utilisateur est authentifié et possède au moins une carte de

fidélité.

Post condition Notifications ou consultation, les clients reçoivent directement

sur leurs appareils les offres et les promotions offertes par l‟une

des enseignes.


client.


3. Il choisit ensuite de visualiser les nouvelles offres et

promotions concernant l‟enseigne propriétaire de cette carte.

Exceptions

Les offres et promotions ne seront présentées sur le téléphone

du client que dans le mode Online. Dans le cas d‟absence de

connexion, rien n‟est affiché.

Tableau 7. Description du cas d’utilisation « consulter les nouvelles et promotions »



2.5.2.5 Raffinement du cas d’utilisation « authentification»

Nom du cas d'utilisation Authentification

Acteurs Client

Pré condition Chaque personne désirant bénéficier des services de l‟application

doit s‟authentifier d‟abord. Cette personne doit saisir son login et

mot de passe puis cliquez sur le bouton s‟authentifier.

Post condition Cet utilisateur accédera aux fonctionnalités de l‟application selon

ces privilèges. Un simple utilisateur aura des fonctionnalités

restreintes.

Scénario principal 1. Le système affiche le formulaire d'authentification

2. L‟utilisateur saisit son login et mot de passe.

3. L‟utilisateur bénéficiera des fonctionnalités de

l‟application selon son privilège (administrateur / simple

utilisateur)

4. Le système affiche un message d'erreur, si le mot de passe

est incorrect et demande à l‟utilisateur de s‟enregistrer s‟il

n‟avait pas un login et un mot de passe.

Exceptions

En cas d„inexistence du mot de passe et du login introduit, un

message d‟erreur est affiché.

Tableau 8. Description du cas d’utilisation « authentification »

2.5.2.6 Raffinement du cas d’utilisation «inscription»

Nom du cas d'utilisation Inscription

Acteurs Client

Pré condition Le système fonctionne et l‟utilisateur voulant bénéficier des

services offerts par l‟application.

Post condition L‟utilisateur aura un mot de passe et un login et pourra

accéder aux services de l‟application.

Scénario principal 1. Le système demande au client de saisir son login, mot

de passe, et CIN.

2. Les données seront envoyées à un serveur distant pour

vérifier leur cohérence et unicité.

3. Le système affiche un message de confirmation

concernant l‟inscription.

4. Le système demande au client de finaliser son compte

avec ses informations personnelles.

Exceptions

Les détails de l‟inscription (login, CIN) existent déjà dans

notre système. Dans ce cas, un message d‟erreur sera émis

invitant le client à saisir de nouveau ses détails.



Tableau 9. Description du cas d’utilisation « inscription »

2.5.2.7 Raffinement du cas d’utilisation «procéder aux paiement » :

Nom du cas d'utilisation procéder au paiement

Acteurs Client

Pré condition Lorsque le client choisit les cartes de fidélité type avec remise, il

doit payer en ligne une somme d‟argent contre ce type de service

accordé.

Post condition Le client aura un code à barre (1D, 2D) pour sa nouvelle carte de

fidélité choisie.

Scénario principal 1. Le système propose au client ce type de service en

présentant les détails et les avantages accordés.

2. Le client choisit la carte cible.

3. Il procède ensuite au paiement : Il devra saisir ses

coordonnés bancaires et quelques informations personnelles.

4. Le système affiche un message indiquant la réussite de la

transaction.

Exceptions

Le système affiche un message d'erreur, si les données bancaires

sont erronées, ou si son solde est insuffisant.

Tableau 10. Description du cas d’utilisation « procéder au paiement »

2.6 Diagramme d’activité de navigation concernant le client

La Figure14 représente un scénario complet d‟utilisation de l‟application..



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

connexion

do/ saisir login & password

création compte

do/ remplir détails formulaire

do/ finaliser son compte

do/ choisir paramètres connexion

affichage cartes personnelles

do/ visualiser détails cartes personnelles

do/ filtrage carte par(catégories, nom)

do/ consulter les notifications des nouvelles promotions

visualiser détails carte sélectionnée

do/ afficher code à barre

do/ afficher points collectés

do/ retrouver les enseignes proches

visualiser les cartes disponibles

do/ afficher la liste des cartes

do/ rechercher une carte selon(catégories, nom)

do/ sélectionner une carte

visualiser détails carte sélectionnée

do/ afficher description carte

do/ sélectionner Ajouter carte

do/ sélectionner adhérer carte

saisir code à barre

do/ saisir son code à barre

do/ vérifier cohérance code

procéder aux paiement

do/ saisir coordonnées bancaires

do/ valider transaction

afficher la carte géographique

do/ accéder aux enseignes marqués sur la carte

do/ visualiser chemin d'accés

Pas encore inscrit

sinon

login ou pwd non valide

sélectionner une carte ajouter une carte

géolocaliser les enseignessélectionner une carte

Recevoir code à barre

choix "Ajout carte"choix "adhésion carte"

choix carte avec remise

choix carte avec collecte des points

Ajouter la nouvelle carte à la collection personnelles

code à barre erroné



Dans ce qui suit, une figure récapitulative et simplifiée des objectifs à entamer et de

l‟architecture à mettre en place.

Figure 15. Schéma simplifiant les attentes du client et les principales fonctionnalités

Conclusion :

Dans ce chapitre, nous avons énuméré les différents besoins fonctionnels et non fonctionnels

de notre application. Ensuite, nous avons fait une étude des différents cas d‟utilisation de

notre solution. Ce chapitre a été d‟une importance cruciale surtout pour la compréhension des

besoins et attentes du client.

ISI Conception Taggist


Chapitre V : Conception



1. Introduction

Dans ce chapitre nous abordons la partie conception du projet, dans laquelle, nous détaillons

les différents éléments de conception, à savoir les diagrammes de séquences, et les

diagrammes de classes.

2. Conception détaillée

La conception est la plus importante étape du cycle du développement logiciel. Elle se base

essentiellement sur la bonne spécification et l‟analyse des besoins. Notre démarche débute par la

compréhension du problème. Ensuite nous analysons le problème pour donner une solution

adéquate. A présent, nous sommes dans la phase de concevoir la solution. Notre conception doit

obéir à l‟architecture déjà choisie pour les différentes parties du système d‟où cette phase

préliminaire qui nous permettra de définir les composants globaux de notre système.

2.1 Le diagramme de classe

Le diagramme de classes est une modélisation statique du système en termes de classes et de

relations entre ces classes. Son intérêt réside dans la modélisation des entités du système

d‟information.

2.1.1 Diagramme de classes de l’application serveur Middleware

La Figure 16 illustre les principales classes de notre application :

Classe Client : est la classe qui contient toutes les informations concernant le client.

Classe Enseigne : est la classe qui contient tous les détails concernant une enseigne.

Classe Carte Service : est la classe qui représente réellement la carte de fidélité avec sa

description, sa validité, son prix d‟achat, le taux de remise accordé, les nombres des points

gagnés en échange d‟un montant dépensé et son état soit activée ou non.

Classe Catégories : elle sert à classifier les cartes de fidélité sous des catégories par exemple :

les produits alimentaires, cosmétiques, motos et autos …

Classe Plage Code : sert à associer et restreindre une plage spécifique de code pour une carte

de fidélité.

Classe Promotion : contient tous les détails d‟une offre lancée par une enseigne.



Classe coordonnée : enregistre les longitudes et les latitudes d‟une enseigne pour faciliter sa

localisation dans Google Maps.

Classe compte : sert à associer une carte de fidélité précise à un client donné tout en

enregistrant ses détails tels que son cumul de points de fidélités, sa date d‟acquisition, son

code à barre.

Classe Connexion : gère les connexions à l‟application (contient tous les logins et mots de

passe) qui servent à la phase d‟authentification.

Classe Préférences : sert à présenter une liste non exhaustive des préférences d‟un client pour

que les offres ou les campagnes publicitaires soient bien ciblées.

Classe ApourPréférences : c‟est une classe de jointure entre la classe client et la classe

préférence.



Figure 16. Diagramme de classes de l’application Middleware



2.1.2 Les classes de l’application mobile

Figure 17. Les classes de l’application sur le mobile

La Figure 17 montre les classes utilisées au niveau client.

La classe LocalMidlet est la Midlet de notre application qui représente l‟élément principale.

Elle a des relations avec toutes les classes de notre projet.

La classe SoapConnection est la classe qui gère les relations d‟échanges et d‟analyse des

données transitant entre le web service et notre application.



La classe Checksum sert à vérifier la cohérence des codes à barres insérés et s‟ils respectent

les normes EAN13.

La classe BarcodeFunction est la classe responsable de génération des codes à barres sous la

forme EAN13 ou Qrcode

La classe GoogleMap est la classe responsable de gé localisation et d‟ajout des marqueurs sur

la carte géographique.

Les classes restantes sont des formes et représentent les interfaces de l‟application mobile.

2.2 La base des données de l’application

La Figure 18 représente les tables utilisé dans notre base des données .Ces tables représentent

l‟unité de persistance de notre application.



Figure 18. Schéma de la base des données

FK_POSSEDER

FK_GERER

FK_LIER

FK_OFFRIR

FK_SPECIFIER

FK_LOCALISER

FK_APPARTENIR

FK_APPARTINE

FK_IDENTIFIER_CLI2

FK_IDENTIFIER_ENS2

FK_IDENTIFIER_ENS

FK_IDENTIFIER_CLI

client

id_cli

id_lo

nom_cli

prenom_cli

adresse_cli

vil le

code_pos

tel_cli

email_cli

cin_cli

date_naiss

situation_fam

prof

int

int

varchar(255)

varchar(255)

varchar(255)

longtext

varchar(255)

longtext

longtext

varchar(20)

date

varchar(50)

longtext

<pk>

<fk>

compte

id_comp

id_carte

id_cli

code_bar

montant_comp

nbr_pt

etat_comp

code_pin

date_acq

identification

motdePasse

int

int

int

longtext

double

numeric(8,0)

bool

numeric(5,0)

date

text

text

<pk>

<fk2>

<fk1>

enseigne

id_ens

id_lo

nom_com

adresse_com

ville_com

code_pos_com

tel_com

mail_com

num_rg

...

int

int

varchar(255)

varchar(255)

varchar(50)

numeric(8,0)

varchar(20)

varchar(255)

varchar(255)

<pk>

<fk>

carte_service

id_carte

id_ens

id_type

id_plage

desc_carte

validation

prix_ach

taux_rem

montant

nb_pt

etat

...

int

int

int

int

varchar(255)

numeric(8,0)

float

float

float

int

bool

<pk>

<fk1>

<fk3>

<fk2>

plage

id_plage

plage_min

plage_max

etat_plage

...

int

bigint

bigint

bool

<pk>

promotion

id_pro

id_carte

desc_pro

prix_ach_pro

taux_rem_pro

montant_pro

nb_pt_pro

date_deb_pro

date_fin_pro

...

int

int

varchar(255)

float

float

float

int

date

date

<pk>

<fk>

connexion

id_lo

id_cat

login

pwd

etat_lo

int

int

varchar(50)

varchar(50)

bool

<pk>

<fk3>

categorie

id_cat

type_cat

int

varchar(255)

<pk>

coordonnee

id_cor

id_ens

longitude_ven

latitude_ven

adresse_cor

vil le_cor

tel_cor

mail_cor

...

int

int

float

float

varchar(255)

varchar(50)

varchar(20)

varchar(255)

<pk>

<fk>

type_carte

id_type

libelle

int

varchar(255)

<pk>



2.3 Architecture de la partie serveur

Pour réaliser notre application, nous avons opté pour une architecture n-tiers à base d‟objets.

C‟est un modèle logique d‟architecture applicative qui vise à séparer nettement 3 couches

logicielles au sein d‟un même système. Le rôle de chaque couche est clairement défini comme

suit:

Couche présentation des données: Contient les interfaces qui vont interagir avec

l‟utilisateur de l‟application.

Le traitement métier des données: correspondant à l‟ensemble des règles de gestion

de la logique applicative.

L’accès aux données persistantes: correspondant aux données qui vont être gardées

de manière persévérante.

Dans cette approche, les couches communiquent entre elles à travers un « modèle d‟échange »

et chacune d‟entre elles propose un ensemble de services rendus. Les services d‟une couche

sont mis à la disposition de la couche supérieure.

Dans cette partie, nous allons détailler notre architecture en l‟illustrant par des diagrammes de

paquetage illustré par la Figure 19.

L‟application doit garantir une indépendance des modules accomplissant les différentes

fonctionnalités prédéfinies. Le choix des packages dépend fortement de l‟architecture de

l‟application décrite précédemment.

Le package présentation contient la classe principal LocalMidlet qui est le moteur de

l‟application Java mobile. Initialement, elle regroupe un ensemble de méthodes prédéfinie

nécessaire pour la réalisation et le déclenchement de l‟application mobile (startApp(),

pauseApp(), destroyApp(), commandAction()).

Notre application mobile réalise un ensemble de fonctionnalités principales (La mise à jour des

données, le parse des fichiers XML provenant des messages SOAP généré par le web service.

Ces tâches sont principalement gérées par la classe SoapConnection qui joue un rôle

primordial de consommation de web service .



Figure 19. Architecture détaillée de l’application

2.3.1 Package web service (Les méthodes distantes au niveau serveur) :

La figure ci-dessous présente les méthodes déployées sur le serveur, et que nous pouvons

accéder à travers les messages SOAP.

Figure 20. Les méthodes déployées sur le serveur



2.4 Les diagrammes de séquence

Le diagramme de séquence décrit l‟aspect dynamique du système. Il modélise les interactions

entre les objets ou entre utilisateur et objet, en mettant l‟accent sur la chronologie des

messages échangés. Dans ce qui suit, nous allons dresser les diagrammes de séquences de

chaque cas d‟utilisation :

2.4.1 Le cas d’utilisation « s’authentifier »

C‟est le premier scénario qui se déroule lors du déclenchement de l‟application. Selon la

Figure 21, le client est invité à saisir ses paramètres de connexion. Le système vérifie la

disponibilité du login et du mot de passe, pour donner ensuite accès aux fonctionnalités de

l‟application.

Figure 21 . Diagramme de séquence pour le cas d’utilisation « s’authentifier »



2.4.2 Le cas d’utilisation « inscription d’un nouveau membre »

Selon la Figure 22, le système invite l‟utilisateur à choisir ses paramètres d‟accès (login et

mot de passe). Il essaie ensuite de vérifier l‟unicité de ses paramètres .Lorsque tout est réglé,

un message de confirmation évoque le succès de l‟inscription.

Figure 22. Diagramme de séquence pour le cas d’utilisation « inscription nouveau

membre »

2.4.3 Le cas d’utilisation « afficher la liste des cartes fidélité disponibles »

Après une procédure d‟authentification réussie, le client pourrait consulter la liste des cartes

de fidélités disponibles. Dans le cas échéant, il pourrait soit adhérer à cette carte ou tout

simplement l‟ajouter à ses cartes personnelles.Ce scénario est décrit dans la Figure 23.



Figure 23. Diagramme de séquence pour le cas d’utilisation « consulter la liste des cartes

disponibles »

2.4.4 Le cas d’utilisation « ajouter une nouvelle carte »

L‟ajout d‟une carte nécessite que le client ne possède pas auparavant une carte de même type.

En plus lors de la saisie du code à barre, le client doit respecter les normes de codage EAN13

sinon un message d‟erreur s‟affiche inhibant ainsi l‟opération d‟ajout de la carte.

Si toutes les conditions sont remplies correctement, la nouvelle carte s‟ajoute au compte

client.



2.4.5 Le cas d’utilisation « afficher les cartes de fidélité personnelles »

Le diagramme de la Figure 25, illustre les interactions entre un client et l‟application lorsque

ce dernier désire visualiser ses cartes personnelles. Il peut ensuite consulter son solde des

points, géo localiser les enseignes, présenter son code à barre à la caisse au moment d‟achat.

Figure 24. Diagramme de séquence du cas d’utilisation « ajouter une nouvelle carte »



Figure 25. Diagramme de séquence du cas d’utilisation « afficher les cartes de fidélité

personnelles »

2.4.6 Le cas d’utilisation « géo localiser les enseignes sur une carte»

La fonction de géo localisation aide l‟utilisateur à accéder facilement à ses enseignes dont il

possède une carte de fidélité.

Figure 26. Diagramme de séquence du cas d’utilisation « géo localiser enseigne »



2.4.7 Le cas d’utilisation « visualiser le code à barre de la carte »

Au moment de paiement chez la caisse, le client peut montrer le code à barre de sa carte pour

qu‟il bénéfice des réductions et offres accordées par une marque donnée.

Le diagramme de la Figure 27 illustre le déroulement de ce cas.

Figure 27 . Diagramme de séquence du cas d’utilisation « visualiser le code à barre de la

carte »

3. Conclusion

Dans ce chapitre nous avons détaillé les différentes vues conceptuelles des applications à

réaliser à travers les modèles UML nécessaires. Cette conception est essentielle pour la phase

de réalisation qui constitue l‟objet du chapitre suivant.

ISI Réalisation Taggist


Chapitre VI : Réalisation



1. Introduction

Dans ce chapitre, nous présentons l‟environnement matériel et logiciel du projet. Ensuite,

nous nous intéressons à la description de quelques interfaces du système implémenté dans le

cadre de quelques scénarios d‟utilisation.

2. Environnement de travail

2.1 Environnement matériel

Machine de développement : ordinateur portable Sony Vaio, Intel® Pentium® M 1,7 Ghz, 2 Go

de RAM.

2.2 Environnement logiciel

Système d‟exploitation : Windows XP Familial version SP 3

SGBD: MySQL version 5

IDE de développement : Eclipse Helios, MyEclipse. LWUIT Ressource Editor.

Outil pour la conception : Visual paradigm, Rational Rose.

Traitement et modification des images : Adobe Photoshop CS.

Nous avons intérêt à mettre en place une architecture rigoureuse, de manière à garantir la

maintenabilité, l'évolutivité et l'exploitabilité de notre application. La Figure 28 montre

l'architecture qui sera mise en place dans le cadre de notre projet.

² Figure 28. Architecture Logicielle de l’application



2.2.1 La plateforme « J2ME »

2.2.1.1 Présentation

Java 2 Micro Edition est une architecture technique dont le but est de fournir un socle de

développement aux applications embarquées. L‟intérêt étant de proposer toute la puissance

d‟un langage tel que Java associé aux services proposés par une version bridée du Framework

J2SE : J2ME.

2.2.1.2 L'architecture J2ME

L'architecture J2ME se découpe donc en plusieurs couches [URL 12] :

• Les profiles : Ils permettent à une certaine catégorie de terminaux d‟utiliser des

caractéristiques communes telles que la gestion de l‟affichage, des évènements

d‟entrées/sorties (pointage, clavier, …) ou des mécanismes de persistance (Base de données

légère intégrée). Ces profiles sont soumis à spécifications suivant le principe du JCP (Java

Community Process)

• Les configurations : Elles définissent une plate-forme minimale en terme de services

concernant un ou plusieurs profiles donnés.

• Les machines virtuelles : En fonction de la cible, la machine virtuelle pourra être

allégée afin de consommer plus ou moins de ressources (KVM, CVM, …)

• Le système d’exploitation : L‟environnement doit s‟adapter au système

d‟exploitation existant (Windows CE, Palm Os) .

La technologie J2ME se compose d‟une machine virtuelle et d‟un jeu d‟APIs appropriées

pour fournir des environnements d‟exécution sur mesure aux terminaux mobiles. Les 2 types

de composants principaux de la technologie J2ME sont les configurations et les profils.

Une configuration est composée d‟une machine virtuelle, des bibliothèques du noyau, de

classes et d‟APIs. Actuellement, il y a deux configurations J2ME possibles :

“Connected Limited Device Configuration (CLDC)” et “ConnectedDevice Configuration

(CDC) ”.



CLDC est créée pour les terminaux dont les ressources processeur et mémoire sont limitées.

Généralement, ces terminaux fonctionnent soit sur un processeur 16-bit, soit sur un 32-bit et

disposent de moins de 512 Kbytes de mémoire disponible pour la plate-forme Java et ses

applications.

CDC est créée pour la prochaine génération de terminaux disposant de plus de ressources.

Généralement, ces terminaux fonctionnent sur un processeur 32-bit et disposent de 2 Mbytes

ou plus de mémoire disponible pour la plate-forme et ses applications.

Les Profiles

Un profile définit la structure d‟une application. Il est basé sur une configuration et c‟est la

base pour produire un environnement de fonctionnement complet pour un type d'appareil

donné. Il fournit généralement l'interface utilisateur, les méthodes d'entrées-sorties et le

mécanisme de persistance pour un groupe d'appareil (alors un seul terminal peut supporter

plusieurs profils). Toutefois certains profils peuvent être créés pour répondre à certaines

capacités ou services d'appareils (RMI, multimédia, etc.).

Il existe plusieurs profiles dont nous citons : MIDP (Mobile Information Device Profile),

Foundation Profile

Le profil « Foundation » est destiné à la configuration CDC. Il permet un accès à une

implémentation complète des fonctionnalités de J2SE. Il englobe des API de gestion de réseau

pour les dispositifs qui n'ont pas besoin de possibilités graphiques

Le profil « MIDP » est destiné à la configuration CLDC. Il prend en charge un nombre limité

des classes de J2SE et définit des classes d'entrée/sortie et d'interface spécialisées pour cette

configuration.

Les Midlets

Les Midlets sont l'élément principal d'une application Java embarquée. Pour bien saisir leur

mode de fonctionnement, il suffit de prendre comme analogie les Applets ou les Servlets.



Le cycle de vie d‟une Applet est géré par un conteneur, en l‟occurrence le Navigateur Web,

dont le rôle est d‟interagir avec celle-ci sous la forme de méthodes de notifications prédéfinies

(init(),paint(),destroyed(),…).

2.2.2 LWUIT

Développée par Sun, LWUIT (LightWeight UI Toolkit) est une librairie de composants

graphiques pour J2ME sortie en 2008.[URL 13]

Cette librairie apporte des composants graphiques plus riches que les librairies standards pour

le développement d'applications mobiles.

Les principaux caractéristiques sont :Touch Screen, Animations & Transitions, Widgets, 3D

Integration, Painters, Modal Dialogs, External Tools, Fonts, rich widgets,themes

Principaux avantages :

• garantir un développement rapide

API Familier

Facile & Simple

Figure 29. Interface principal de LWUIT Demo présentant les principaux widgets

apportés avec LWUIT



Transitions

•Des transitions prêtes pour utilisation

>Slide, Fade

> 3D transitions Cube, Rotate, Fly in

Touch Screen Support

• Tous les widgets supporte les événements provenant

d‟un écran tactile.

• le support de l‟évènement Drag and Drop,

flow reArrange on Drop

• Gestion de défilement(Scrolling) (Effet iPhone)

• Facilité de déploiement

Un seul JAR à importer

Destinés pour des nombreux dispositifs

• Les dispositifs du marché de masse

• Consistent + extensible

• Interface utilisateur riche

Figure 30. Interface montrant l’effet rotation

Figure 31. interface montrant les

possibilités graphiques avec LWUIT



Designer Tool (“Ressource Editor”) : éditeur graphique pour créer des Interfaces

utilisateurs intuitives et conviviales. Il est développé pour les designers. Il s‟agit d‟une

application autonome qui permet de créer des thèmes dédiés aux applications mobiles.

Figure 32. Interface graphique de l’application « Ressource Editor »

2.2.3 La bibliothèque Zxing (Zebra Crossing)

ZXing est un projet open-source multi-format de code-barres 1D/2D de traitement d'images

mis en œuvre en Java. Ce projet met l'accent sur l'utilisation de la caméra intégrée sur les

téléphones mobiles et de décoder les codes-barres sur l'appareil, sans communiquer avec un

serveur.

Les formats pouvant être décodés sont :

- UPC-A and UPC-E

- EAN-8 and EAN-13

- Code 39

- Code 128

- QR Code

- Data Matrix ('alpha quality) .[URL 15]



2.2.4 La bibliothèque Geo-J2ME

C‟est une API qui permet l‟intégration rapide et facile de la carte GPS à une application

J2ME. The API is easy to use as entering an address and returns the coordinates for the same

image of the map sought. The API uses Google Maps statics.

L'API est si facile à utiliser il suffit d'entrer une adresse et l‟API se charge de renvoyer les

coordonnées et l'image satellitaire. La bibliothèque permet aussi d‟ajouter des marqueurs

sur la carte. Elle utilise les API Google Maps statique. [URL 15]

2.2.5 Web service

2.2.5.1 Définition du protocole SOAP

SOAP (ancien acronyme de Simple Object Access Protocol) est un protocole utile pour

exécuter des dialogues requête-réponse RPC (Remote Procedure Call).C‟est un protocole

orienté objet basé sur XML. Il permet la transmission de messages entre objets distants, ce qui

veut dire qu‟il autorise un objet à invoquer des méthodes d‟objets physiquement situés sur un

autre serveur. Le transfert se fait le plus souvent à l‟aide du protocole HTTP, mais peut

également se faire par un autre protocole, comme SMTP.[URL 16]

Figure 33. Schéma décrivant une communication client serveur en utilisant les web

service



Le protocole SOAP est composé de deux parties :

une enveloppe, contenant des informations sur le message lui-même afin de permettre

son acheminement et son traitement

un modèle de données, définissant le format du message, c‟est-à-dire les informations

à transmettre.

Figure 34. Structure d’un message SOAP

2.2.5.2 KSOAP 2

Une bibliothèque SOAP client léger, idéale pour les appareils mobiles telles que les

applications J2ME (CLDC / CDC / MIDP) pour consommer les web service. il faut construire

à la main sa requête SOAP, et ensuite parser le résultat soi-même. kSOAP2 est relativement

facile une fois que vous savez quelques concepts de base: Comment établir une connexion,

comment envoyer une demande, et comment accéder aux objets dans une réponse analysée.

[URL17].

2.2.5.3 Apache Axis2

Axis2 est une Framework utile pour la génération des web service. Elle se trouve avec deux

implémentations Apache Axis2/Java et Apache Axis2/C. C'est un package Java libre qui

fournit :

http://fr.wikipedia.org/wiki/Paquet_%28logiciel%29

http://fr.wikipedia.org/wiki/Java_%28langage%29

http://fr.wikipedia.org/wiki/Logiciel_libre



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]

http://fr.wikipedia.org/wiki/Apache_Tomcat

http://fr.wikipedia.org/wiki/RPC

http://fr.wikipedia.org/wiki/HTTP

http://fr.wikipedia.org/wiki/File_Transfer_Protocol

http://fr.wikipedia.org/wiki/Courriel

http://fr.wikipedia.org/wiki/Java_%28langage%29

http://fr.wikipedia.org/wiki/Web_Services_Description_Language

http://fr.wikipedia.org/wiki/Serveur_mandataire



3. Interfaces de l’application

Nous exposerons quelques interfaces de notre application, en essayant à chaque fois de décrire les

différents objets interactifs mis à la disposition de l‟utilisateur.

Lors de lancement de l‟application, une interface SplashScreen ( Figure 35) apparaît

mentionnant le nom de l‟application et l‟entreprise éditrice de la solution à savoir Taggist.

Ensuite le client est invité à s‟authentifier en saisissant ses paramètres d‟accès (Figure 36).

Figure 35. Interface de lancement de l’application Figure 36. Interface d’authentification



Figure 37. Interface ajout nouveau membre

Lorsque le client n‟admet pas de

compte, il pourrait accéder aux

fonctionnalités d‟ajout d‟un

membre tout en saisissant

quelques informations

personnelles et les paramètres

d‟accès .La figure 37 illustre ce

cas d‟utilisation.

Figure 38. Interface questionnant le client de

choisir entre visualiser ses cartes ou ajouter d’autres

cartes.

La figure 38 est une interface de transition où le

client doit choisir entre soit visualiser ses propres

cartes, soit ajouter une nouvelle carte de fidélité.



Lors d‟un ajout d‟une carte, le client visualise

d‟abord une liste contenant toutes les cartes de

fidélité disponibles(voir Figure 39 ). En cliquant

là-dessus, une nouvelle interface apparaît

mentionnant les détails de cette carte, le prix

d‟acquisition, le taux de remise accordé etc…

Figure 39. Interface liste des cartes de

fidélités disponibles



Figure 41. Interface ajout d’une carte

Figure 40. Interface détails carte

L‟action d‟ajout d‟une carte vérifie d‟abord le checksum

du code inséré et s‟il respecte les normes EAN13 (Voir

Annexe).Ensuite, il vérifie si le client possède déjà une

carte de même type .Si non, il vérifie encore si le code

appartient à la plage des codes associée. Et enfin, il

ajoute cette nouvelle carte .



Lorsque le client choisit de visualiser ses propres cartes, une liste apparaît .elle

contient toutes les cartes possédés par ce dernier. Lorsqu‟il ferait une sélection, la

taille de la carte choisie, grandit et un menu apparaît en dessous présentant des

fonctionnalités tels que : l‟affichage du Qrcode de la carte, l‟affichage du code

1D de la carte, la géo localisation des enseignes associées à cette carte (Figure

42).

Figure 43. Liste des cartes propriétaires Figure 42. Carte sélectionnée



Figure 45. QR code carte affiché Figure 44. Code 1D carte affiché

La bibliothèque Zxing permet au client de

générer son code à barre soit sous la forme 1D ou

Qrcode. Les code à barre affichés dans la figure 44 et

45 sont générés avec cette bibliothèque.



Figure 47. Géo localisation vue normal Figure 46. Géo localisation vue satellite

L‟application permet de visualiser à l‟aide des

marqueurs l‟emplacement géographique des

enseignes sur une carte.



4. Réalisation partie serveur

Figure 48. La liste des services déployés sur le serveur

Figure 49. Exemple d’un Soap Request et d’un Soap Response.



La figure 48 et 49 exposent la liste des services déployés sur Axis2.Leurs spécifications

reposent sur les standards SOAP et WSDL. Ces services servent à alimenter l‟application

mobile par les données nécessaires lors des traitements, assurer l‟interfaçage entre le serveur et

cette dernière et gèrer aussi la persistance des donnés au niveau de la base des données.

serveur back-End pour alimenter les applications mobiles.

5. Conclusion

Dans ce chapitre nous avons détaillé les technologies utilisées pour la réalisation de notre projet

ainsi que les fonctionnalités de base de l‟application à travers un ensemble de captures d‟écran.

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é

http://fr.wikipedia.org/wiki/Protocole_r%C3%A9seau

http://fr.wikipedia.org/wiki/Ordinateur

http://fr.wikipedia.org/wiki/Serveur_d%27applications

http://fr.wikipedia.org/wiki/Client_(informatique)

http://fr.wikipedia.org/wiki/Serveur_informatique

http://fr.wikipedia.org/wiki/Remote_procedure_call

http://fr.wikipedia.org/wiki/Extensible_markup_language

http://fr.wikipedia.org/wiki/Message

http://fr.wikipedia.org/wiki/Serveur_informatique

http://fr.wikipedia.org/wiki/Java_(technologie)

http://fr.wikipedia.org/wiki/Interface_de_programmation

http://fr.wikipedia.org/wiki/Extensible_Markup_Language

http://fr.wikipedia.org/wiki/Remote_Procedure_Call

http://fr.wikipedia.org/wiki/Plate-forme_Java

http://fr.wikipedia.org/wiki/Sun_Microsystems



http://fr.wikipedia.org/wiki/Simple_Object_Access_Protocol

http://fr.wikipedia.org/wiki/Remote_Procedure_Call

http://fr.wikipedia.org/w/index.php?title=JAX-WS&action=edit&redlink=1

http://fr.wikipedia.org/wiki/Anglais

http://fr.wikipedia.org/wiki/Code-barres

http://fr.wikipedia.org/wiki/Matrice_%28math%C3%A9matiques%29

http://fr.wikipedia.org/wiki/Acronymie

http://fr.wikipedia.org/wiki/Donn%C3%A9es

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.

http://fr.wikipedia.org/wiki/Lecteur_de_code-barres

http://fr.wikipedia.org/wiki/T%C3%A9l%C3%A9phonie_mobile

http://fr.wikipedia.org/wiki/Smartphone

http://fr.wikipedia.org/wiki/Code-barres_EAN

http://fr.wikipedia.org/wiki/EAN_8

http://fr.wikipedia.org/wiki/Cl%C3%A9_de_contr%C3%B4le

http://fr.wikipedia.org/wiki/Fran%C3%A7ais

http://fr.wikipedia.org/wiki/G%C3%A9olocalisation

http://jquery.org/

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

http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/

http://www.chef-de-projet.org/methode/uml.htm

http://www.fidme.fr/accueil/

http://www.snapp.fr/fr/produits/snapp-fid/

http://www.fidall.com/

http://www.mobifid.com/

http://fr.wikipedia.org/wiki/Smartphone

ftp://ftp-developpez.com/pastel-pro/mobiles/frameworks/comparatif-applications-smartphones-open-source/Frameworks-open-source-pour-applications-smartphones-multiplateformes.pdf



http://blog.smile.fr/Appcelerator-annonce-la-sortie-de-Titanium-Studio-1.0

http://blog.smile.fr/Mobile/Developpement-mobile-cross-platform-avec-PhoneGap

http://blog.smile.fr/Mobile/Developpement-mobile-cross-platform-avec-PhoneGap

http://pastel-pro.developpez.com/mobiles/frameworks/comparatif-applications-smartphones-open-source/

http://pastel-pro.developpez.com/mobiles/frameworks/comparatif-applications-smartphones-open-source/

http://www.3ie.fr/nouvelles_technologies/fiche/fiche_J2ME.htm

http://fr.wikipedia.org/wiki/LWUIT

http://code.google.com/p/geo-j2me/

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/

http://ksoap2.sourceforge.net/

http://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27exploitation_mobile

http://barcode-coder.com/fr/specification-ean-13-102.html

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 ]

Documents

Résumé - Academie pro téléchargement gratuit cours, tp ... · 2.3.1 Package web service ... 1.3 Android de Google Inc ... Figure 48. La liste des services déployés sur le serveur