You are on page 1of 89

Rapport de Projet de Fin dEtudes

Thme : Dveloppement dun lecteur de code barre universel pour Android

labor par: Wahid Gazzah Responsable du projet: M.Sofien Lach'hab Encadr par: Dr. Sadok Bouamama Organisme d'accueil: Ultimate Mobile Agency

Anne Universitaire : 2011/2012

Ecole Polytechnique Prive (Agrment N02-2009) Boulevard Khalifa Karoui Sahloul 4054 Sousse Tl. : (00216) 73 277 877 / (00216) 50 995 885 Fax : (00216) 73 243 685 www.polytecsousse.tn

Ddicaces

A mes chres familles A mes chers amis A tous ceux qui comptent pour moi A tous ceux pour qui je compte Je ddie ce travail

Remerciements
Au terme de notre projet fin dtude, je tiens remercier toutes les personnes, qui par leurs conseils, leurs suggestions ou par leur simple prsence mont permis de rendre mon travail aussi instructif et efficace que plaisant. Je remercie tout spcialement mon encadreur Monsieur Sadok Bouamama pour son encadrement tout au long de ce projet, sa patience, sa disponibilit et ses conseils toujours aviss. Enfin, mes remerciements vont tous les enseignants de Polytechniques Sousse pour la qualit de la formation qu'ils mont fournie et tous les membres du jury pour avoir accept de juger ce modeste travail.

Liste des figures


Figure 1 Figure 1.1 Figure 2.1 : Figure 2.2 : Figure 2.3 : Figure 2.4 : Figure 3.1 : Figure 4.1 : Figure 4.2 : Figure 4.3 : Figure 4.4 : Figure 4.5 : Figure 4.6 : Figure 4.7 : Figure 4.8 : Figure 4.9 : Logo Tunitag Logo Ultimate Mobile Agency Caractristiques de lapproche itrative Organisation du processus unifi les phases dun cycle du processus unifi processus de dveloppement 2TUP Ltude prliminaire dans 2TUP Capture des besoins fonctionnels dans 2 TUP Uses Case Globale Diagramme dactivits du cas Authentification Diagramme de cas dutilisation du package Gestion des comptes clients Diagramme de cas dutilisation du package Gestion des QR Codes Diagramme de cas dutilisation du package Gestion des cartes de fidlit Diagramme de cas dutilisation du package Gestion actualit Diagramme de cas dutilisation du package Gestion des scan Diagramme de cas dutilisation du package Gestion des co mptes

Figure 4.10 : Diagramme des classes participantes de Gestion des comptes Figure 4.11 : Digramme des classes participantes de Gestion des Actualits Figure 4.12 : Diagramme des classes participantes de Gestion des QR Code Figure 4.13 : Diagramme des classes participantes de Gestion des cartes de fidlit Figure 4.14 : Diagramme de classes participantes du package Gestion des statistiques Figure 5.1 : Figure 5.2 : Figure 5.3 : Figure 5.4 : Figure 5.5 : Figure 5.6 : Figure 6.1 : Figure 6.2 : Figure 6.3 : Situation de la capture des besoins techniques dans 2TUP Architecture simple tiers Architecture client/serveur Architecture 3 tiers Configuration matrielle du systme Diagramme de composent de systme Dcoupage en catgorie Diagramme de classe Diagramme de squence du scnario Sauthentifier

Figure 6.4 : Figure 6.5 : Figure 6.6 : Figure 6.7 : Figure 6.8 : Figure 6.9 :

Diagramme de squence du scnario Mot de passe oubli Diagramme de squence du scnario Inscription Diagramme de squence du scnario Modifier compte Diagramme de squence Gestion QR Code Diagramme de squence supprimer/partager QR Code Diagramme de squence ajouter publicit

Figure 6.10 : Diagramme de squence ajouter statistique Figure 6.11 : Diagramme de squence ajouter actualit Figure 6.12 : Diagramme de squence traitement QR Code Figure 6.13 : Diagramme de squence crer, supprimer Carte de fidlit Figure 6.14 : Diagramme de collaboration de la catgorie Authentification Figure 6.15 : Diagramme de collaboration de la catgorie Mot de passe oubli Figure 6.16 : Diagramme de collaboration du scnario Inscription Figure 1.17 : Diagramme de collaboration du scnario Modifier compte Figure 6.18 : Diagramme de collaboration du scnario cration des QR Codes Figure 6.19 : Diagramme de collaboration du scnario crer des carte de fidlit Figure 6.20 : Diagramme de collaboration de ladministrateur Figure 7.1 : Figure 7.4 : Figure 7.5 : Figure 7.6: Figure 7.7 : Figure 7.8 : Figure 7.9 : Le modle MVC Format JSON Structure dune enveloppe SOAP Caractristique dun Web Service REST Principe de communication via REST Interface daccueil Interface dauthentification

Figure 7.10 : Interface dinscription Figure 7.11 : Interface de mot de passe oubli Figure 7.12 : Menu principal Figure 7.13 : Opration du scan dun QR Code Figure 7.14 : Rsultat dun scan Figure 7.15 : Cration dun QR code Figure 7.16 : Partage dun QR code Figure 7.17 : Consultation des cartes de fidlit Figure 7.18 : Cration des cartes de fidlit Figure 7.19 : Scan du code a barre dune carte de fidlit

Figure 7.20 : Opration du scan code barre dune carte de fidlit Figure 7.21 : Consultation des actualits

Liste des tables


Tableau 1.1 : Comparaison entre code barre (1D) et (2D) Tableau 3.1 : Les besoins fonctionnels Tableau 4.1 : Liste des acteurs et des messages par cas du tilisation Tableau 4.2 : Liste des cas dutilisation et de leurs acteurs par package Tableau 7.1 : technologies utilises Tableau 7.2 : structure dune application sous Grails Tableau 7.3 : Les mthodes REST Tableau 7.4 : les taches ralises dans lapplication

Introduction gnrale Dans un monde actif et continuellement volutif, la motivation d'avoir des moyens

performants et efficaces de communication et d'change d'informations devient de plus en plus fondamentale. Cette motivation donne naissance une rvolution favorisant le travail distance et l'accs aux besoins en temps rduit laide dinternet qui a bouleverse les habitudes de travail dans de nombreux mtiers. Daprs beaucoup danalyses et statistiques effectues, il savre que de plus en plus dinternautes se connectent dsormais internet via leurs tlphones portables. Nous remarquons ces dernires annes un dveloppement exponentie l des appareils

mobiles qui sont rpandus comme une trane de poudre dans le monde en dveloppement et rvolutionnant le domaine des communications notamment dans les zones rurales.

Dans ce cadre, les Smartphones apparaissent pour rompre avec nos anciennes ides sur les tlphones portables et donner une autre dimension cette technologie tout en intgrant de nouveaux apports la tlphonie mobile et en attirant la clientle grce lergonomie exponentielle et rvolutionnaire. Grace larriv de ce miracle de la technologie, les usages des tlphones mobiles vont tre modifis dune manire significative. Les appareils mobiles joueront le rle de lien entre le monde virtuel du web et le monde physique qui nous entoure. Ils fournissent aux

utilisateurs individuels et aux communauts un accs prcieux toute une srie de services dinformation des fins personnelles et commerciales. De la surveillance des lections la possibilit de demander une aide durgence, la tlphonie mobile a cr dincroyables possibilits de mobilisation et de connexion. Cest dans cette optique se situe mon projet de stage de fin dtudes propos par Ultimate Mobile Agency. Il vise approfondir mes connaissances informatiques ainsi que dcouvrir le domaine professionnel. Probl matique et prsentation du sujet Lamlioration de la qualit de services est un challenge que tout acteur dans le domaine professionnel cherche atteindre. Afin dy parve nir, il est primordial de proposer de
1

nouvelles technologies dinformations et de communications afin damliorer, dune part, le fonctionnement et la visibilit des entreprises, et dautre part, garantir la fidlit des clients. Notre objectif travers ce travail est de proposer une solution qui rpond aux besoins de lutilisateurpar la ralisation dune application commerciale nomm Tunitag en dveloppant une application web et mobileafin de garantir la disponibilit de linformation chez le client et lui offrir la possibilit de: Crer, grer et consulter un compte utilisateur. Scanner des codes barres de tous types. Crer un QRCode facilement et de l'enregistrer sur compte client. Diffrents de QR Code sont disponible (texte, Url, Contact, Sms, Localisation, phone) Crer des cartes de fidlit comportant un code barre. Consulter lhistorique: retrouver des codes barres scanns depuis la fonction scan. Consulter l'actualit concernant Tunitag. Consulter les codes barre dsign pralablement comme favoris. Consulter une bannire publicitaire types

Figure1.2 - Logo Tunitag

Dans notre projet, nous avons men une tude approfondie du systme Android tout en tudiant le concept gnral dAndroid , et nous avons tudi le framework open source Grails. Aprs avoir prsent le cadre de notre projet et la problmatique ainsi que les objectifs atteindre travers ce projet, nous passons la prsentation de lorganisme daccueil.

Pour mener termes ce projet nous avons d effectuer des choix techniques et mthodologiques, identifier les diffrents besoins du projet, raliser une conception dtaille du projet et enfin implmenter la partie back-office ainsi que l'application Android. D'o le prsent rapport qui se rsumeen septchapitres catalogus comme suit :

Le premier chapitre consiste en une Prsentation gnrale qui prsente la socit daccueil et les diffrents besoins li notre projet. Le deuxime chapitre nomm Choix mthodologique qui nous permet dedcider la mthodologie suivre tout au long de la cration de notre application. Dans le troisime chapitre, nous allons numrer les acteurs principaux ainsi que les besoins fonctionnels du projet. Consternant le quatrime chapitre, Besoins fonctionnels, nous allons prsenter les diagrammes cas dutilisateur et classes li aux besoins fonctionnels. Dans le chapitreBesoins techniques,on prsente les technologies et larchitecture utilis pour le dveloppement du projet. Pour la partie conception, on va la diviser en trois chapitres,dcrivant lanalyse et la conception de notre application, ce qui permet de mettre en uvre les principales fonctionnalits du systme. Analyse : intgre les diagrammes de squences du projet. Conception gnrique comporte la conception de larchitecture logicielle. Conception : nous avons rserv cette partie pour concevoir l'application dans tout son ensemble. Enfin pour le chapitreRalisation on prsente les interfaces du projet Tunitag qui dcrivent le dveloppement Android et le dveloppement avec Grails. Finalement, nous clturons notre rapport par une conclusion qui offre une synthse du travail ralis et prsente les perspectives.

Chapitre 1 : Cadre du projet et prsentation gnrale


Introduction Dans ce chapitre introductif nous allonsprsenter la socit daccueil, ainsi quon dfinir quelque mots cl ncessaires pour notre projet. 1. Prsentation de la socit Ultimate Mobile Agency ( UMA) est une agence de marketing mobile cre en 2008, son domaine dactivit est la cration des sites web. Elle a rcemment intgr le dveloppement des applications mobiles sur les deux plateformes iOS et Android par un groupe de stagiaires.

Figure1.1 - Logo Ultimate Mobile Agency

2. Planification Dans le long de mon stage chez UMA, jai essay de rpartir les tches et les raliser sur les semaines de la dure du stage, dans la rsume et reprsent comme suit : 4 semaines : dveloppement dune calculatrice sous Android, qui dispose des fonctions scientifiques les plus couramment utilises, aussi elle permet de dessiner des fonctions sous forme des courbes. 6 semaines : dveloppement de lapplication Android Tunitag. 3 semaines : dveloppement du BackOffice Tunitag sous la framework Grails. 2 semaines : dveloppement des web services REST pour le site web Tunitag sous la framework Grails.

3. Rle occup dans la socit, matriel utilis et formation Au cours de ce stage, jai travaill comme dveloppe ur Android et web. Jai utilis mon ordinateur portable (un HP Compaq) et mon Androphone Gaga (Huawei U8180) distribu par Orange Tunisie . Jai particip un concours organis par Orange pour assister une formation Android que jai reu dans la suite une attestation de formation aprs avoir pass un
examen.

Jai particip aussi une formation Android organis par Yas mine Market. J'ai suivi la formation Android Vido 2 Brain , et jai utilis le livre offert par UMA Programmation Android, de la conception au dploiement avec le Sdk Google Android 2 . 4. Dfinitions Les codes barres

Un code barres, ou code barres, est la reprsentation d'une donne numrique ou alphanumrique sous forme d'un symbole constitu de barres et d'espaces dont l'paisseur varie en fonction de la symbologie utilise et des donnes ainsi codes. Le code barres peut faciliter laccs linformation. Il existe des milliers de codes-barres diffrents, mais on peut les divis en deux catgories: Codes barres unidimensionnels (1D) et lorsque ces barres sont remplaces par de petits carrs ou points, on parle des codes barres bidimensionnels (2D).

Codes-barres unidime nsionnels (1D) [EAN, CUP, Code 11, Code 39]

Codes-barres bidime nsionnels (2D) [QR- Code, Data Matrix, FlashCode]

Nombre limit dinformations encodes Dimensions limites Bit de contrle / checksum Pas de correction derreur

Nombre important dinformations encodes : 25 100 fois plus Dimensions illimites CRC 16/32 Diffrents niveaux de redondance

Tableau 1.1 : Comparaison entre code barre (1D) et (2D) QRCode ? Les QR Codes (QR pour quick response), Cre en 1994 par la socit fabrication de voitures pour suivre la trace diffrents composants. Leur utilit a t ensuite vite mise contribution dans plusieurs types d'industries pour la logistique. Plus rcemment, avec la possibilit de lire ces QR codes sur la majorit des tlphones portables japonais, les codesbarres 2D se sont installs partout au pays du soleil levant. Sur lesemballages, les publicits dans les journaux ou sur les portes du mtro, les stations des bus, partout! A quoi a sert ? Ces codes-barres servent coder une adresse URL comme par exemple celle dun blog, en les lisant, on peut accder trs rapidement, aussi a coder un produit, un SMS, Email envoyer, Contacte (nom, prnom, adresse, numro tlphonique dune personne pour lenregistrer rapidement da ns la liste des contacts aprs avoir scann le QR Code via la camra du mobile), etc. Conclusion Afin de modliser les besoin attendus de notre application et que les objectifs soient atteinte, on va suivre le dmarche du processus unifi quon va le dtailler dans le prochain chapitre

Chapitre 2 : Choix mthodologique


Introduction Le succs du projet dpend ds lors de ladquation du projet au processus de dveloppement qui est une tape dcisivepour llaboration dune application indpendante de toute plateforme dexcution et de tout langage de programmation. En effet, le processus de dveloppement est constitu dune succession de phases (spcification, conception et ralisation). Nous prsentons, dans cette partie les mthodes de conception et les plus cites dans la littrature, et on va choisir une qui sera suivi tout au long de ce projet.

1. Les mthodes de conception On adopte souvent lune de ces deux mthodologies lors de la conception dune application quelconque : MERISE comme tant une mthode systmique ou Unified Process (UP) pour une mthode oriente objet. 1.1 MERISE MERISE sapp uie sur la sparation des donnes (la structure des informations que lapplication utilise) et des traitements (raction aux vnements externes) en quatre niveaux : conceptuel, organisationnel, logique et physique. Cette sparation va assurer la continuit au modle. En effet, pour lensemble de donnes comme pour lensemble des traitements MERISE procde dune manire progressive de llment le plus stable llment le plus instable. [1] Le niveau conceptueldfinit ce quil faut faire, le niveau organisationnel dfinit la manire de le faire, le niveau logique dfinit le choix des moyens et des ressources et le niveau physique dfinit les moyens pour la ralisation de lapplication.

1.2 Processus unifi 1.2.1 Dfinition

Le processus unifi est un processus de dveloppement logiciels orients objets, centr sur l'architecture, guid par des cas d'utilisation et orient vers la diminution des risques. Cest une mthode gnrique, itrative et incrmentale, contrairement la mthode squentielle Merise.[2]

1.2.2

Caractristiques

L'itration et lincrmentation :

UP dcoupe le projet en squences d'instructions. Ces squences seront rptes un nombre bien dtermin de fois ou tant qu'une condition indique n'est pas satisfaite. Gnralement pour un UP, une itration prend en considration un certain nombre de cas d'utilisation et traite en priorit les risques importants. Ces itrations donnent lieu un incrment. En effet chaque itration reprend les squences produites par litration prcdente et les enrichit dune manire incrmentale. Dune manire gnrale Les itrations dsignent des tapes de l'enchanement, tandis que les incrments correspondent des tapes de dveloppement.[3]

Figure 2.1 : Caractristiques de lapproche itrative

Planification : Description de larchitecture. Cas dutilisation : noncer les cas dutilisation et les connexions avec lutilisateur. Analyse et conception : Dtailler les cas dutilisation, dfinir la structure statique du systme : classes et interfaces, dfinir les cas dutilisation raliss sous forme de collaborations entre les sous systmes les classes et les interfaces. Implmentation : Intgre les composants (code source) et la correspondance entre les classes et les composants. Dploiement : Dcrit laffectation des composants sur les nuds physiques. Test : expose les cas de test qui vrifient les cas d'utilisation. Centralisation sur larchitecture

Larchitecture dun logiciel est reprsente par les diffrentes vues du systme devant tre cres. Elle met en vidence les besoins des utilisateurs reprsents par les cas dutilisation. IL faut alors raliser les cas dutilisation reprsentant les fonctions principales et adapter larchitecture pour quelle les prenne en considration. Pilot par les cas d'utilisation

Le processus unifi est centr sur lutilisateur, son but est de satisfaire ses besoins. Les cas d'utilisation UML permettent d'illustrer ces besoins. En effet, ils noncent les besoins fonctionnels qui constituent le modle de cas d'utilisation et qui reprsentent les fonctionnalits compltes du systme.[4] 1.2.3 Organisation du processus unifi

Le processus unifi sorganise dans la rptition dun nombre de cycles qui se termine par une nouvelle version du logiciel.
Naissance Mort

Cycles

Figure 2.1 : Organisation du processus unifi

Chaque cycle est compos de quatre phases : Cration, laboration, construction et transition qui se subdivisent leur tour en 5 itrations: lexpression des besoins, lanalyse, la conception, limplmentation et le test.

Figure 2.2 : les phases dun cycle du processus unifi

1.2.4

Adaptation du processus unifi

Il existe plusieurs processus de dveloppement qui implmente le UP dont le plus intressant le 2UP (2 tracks unified process, prononcez "toutiyoupi"). Pour un modle2TUP, tout dveloppement peut tre dcompos ettraits en parallle selon unaxe fonctionnelet un axetechnique.Nous pouvonsainsi suivreles volutionslies auxchangements desbesoins fonctionnelset aux changements des besoinstechniques. [5] La schmatisation du processus de dveloppement correspond alors un Y. Les deux perspectives se rejoignant lors de la phase de conception prliminaire.

10

Figure 2.3 : processus de dveloppement 2TUP

La branche fonctionnelle contient : la capturedes besoins et de leursanalyses. Lesrsultats de l'analysesont indpendantes destechnologies utiliss. Labranche technique contient : la capturedesbesoinstechniqueset de laconception gnrique. L'architecture techniqueconstruit le squelette dusystme informatique indpendamment des besoins fonctionnels. Lesdeux branchessont ensuite fusionnesen une seule branchequi prend en chargela conception prliminaire (cartographie des composants dvelopper), conception dtaille (comment raliser chaque composant), codage (production des composants), tests ettapes de validation des fonctions dveloppes. Conclusion Aprs avoir choisila mthodologie des processus unifis prcisment le processus 2TUP. Dans le chapitre suivant on va suivre la dmarche de ce processus tout au long de la conception.

11

Chapitre 3 : Etude prliminaire

Introduction Dans cette partie, nous procderons l'analyse des besoins fonctionnels et non fonctionnels attendu de lapplication savoir le dveloppement travers la description des besoins du systme qui doivent rpondre lattente de lutilisateur. En effet, lidentification des besoins fonctionnels reprsente une tape importante du processus de dveloppement 2TUP, qui est prsent dans ltude prliminaire.

Figure 3.1 : Ltude prliminaire dans 2TUP

12

1. Les besoins fonctionnels Les besoins fonctionnels listent les oprations ralisables de notre application. Ce sont des besoins spcifiant un comportement d'entre / sortie du systme. En fait, le systme doit tablir les charges prliminaires suivantes:

Gestion des scans : Scanner un QR Code Gestion des QR Codes : Crer QR Code Partager QR Code Supprimer QR Code Gestion de la publicit : Consulter publicit

Gestion de lhistorique : Consulter historique Partager historique Supprimer historique Gestion des cartes de fidlit : Crer carte de fidlit Consulter carte de fidlit Supprimer carte de fidlit Gestion des actualits :

Gestion compte utilisateur : Ajouter utilisateur Consulter utilisateur Modifier utilisateur

Consulter actualit Gestion des statistiques : Consulter statistique

Table 3.1 : Les besoins fonctionnels

2. Les besoins oprationnels Les besoins oprationnels reprsentent les besoins non fonctionnels, qui caractrisent le systme comme la performance ainsi que la scurit et lergonomie du systme. Ces besoins peuvent tre noncs suivant des plans de classifications. [6] L'ergonomie des interfaces : l'interface d'une application Androphone, est dlicate elle doit tre simple et claire : La manipulation de l'interface ne doit pas ncessiter des connaissances pousses.

13

Lapplication web doit tre compatible avec n'importe quel systmed'exploitation, Facile manipuler, comprhensible. Les interfaces des applications Android et web doivent tre bien organises du point de vue graphique, le choix des couleurs, et des styles. Robustesse : L'application doit permettre le stockage des informations des utilisateurs inscrits, ainsi qu'assurer une bonne gestion d'erreurs. Scurit : L'application doit garantir l'utilisateur connect l'intgrit et la confidentialit de ses donnes. Notre systme doit galement certifier la disponibilit qui s'avre primo rdiale pour bon fonctionnement. L'applicationdoitgarantir: la Fiabilit et la rapidit des scans ainsi que la flexibilit, l'volutivit et la rutilisabilit de ses ressources. Conclusion Aprsavoirdgag les besoins fonctionnels et oprationnels et tous les critres quon doit prendre en considration. On va entamer le chapitre suivant, par la formalisation de ces besoins.

14

Chapitre 4 : Capture des besoins fonctionnels


Introduction Nous commencerons ce chapitre par introduire les dfrentes tapes de processus de 2TUP comme illustr dans la figure 4.1. On va sintresser la branche gauche du cycle en Y qui est la capture des besoins fonctionnels en dcrivant les diffrentes faons qui seront disponible pour permettre les acteurs dutiliser la future application Android et web.

Figure 4.1 : Capture des besoins fonctionnels dans 2 TUP

1. Identification des cas dutilisation Un cas d'utilisation (Use case) reprsente un ensemble de squences d'actions ralises par le systme et produisant un rsultat observable intressant pour un acteur particulier .[6] En effet, ils sont des reprsentations fonctionnelles du systme, ils permettent de modliser les attentes des utilisateurs afin de raliser une bonne dlimitation du systme et galement d'amliorer la comprhension de son fonctionnement.Les CU sont dclenchs suite la stimulation d'un acteur externe.

15

Le tableau suivant reprsente quelques cas dutilisation, les acteurs et les relations entre les deux :
Tableau 4.1 : Liste des acteurs et des messages par cas dutilisation

Cas dutilisation

Acteur principal Acteur secondaire

Message(s)mis / reus par les Acteurs

Authentification utilisateurs) Ajouter compte

(identification

User Admin

Emet : login et mot de passe Reu : confirmation Emet : cration Reoit : confirmation

Modifier compte

User

Emet : modification Reoit : validation

Rcuprer mot de passe

Emet : Email Reoit : mot de passe

Crer QR Code User Supprimer QR Code

Emet : cration Reoit : confirmation Emet : suppression Reoit: validation

Consulter actualits User Inscription Newsletter

Emet : consultation Reoit: liste Emet : Email Reoit : confirmation

Consulter statistique

Emet : consultation Reoit: liste

Ajouter publicit

Emet : cration Reoit : confirmation

Rdiger actualits Admin Supprimer actualits

Emet : cration Reoit : enregistrement Emet : suppression Reoit : validation

Modifier actualits

Emet : modification Reoit : confirmation

Consulter actualits

Emet : consultation Reoit : affichage


16

Ajouter Compte

Emet : cration Reoit : confirmation

Supprimer Compte

Admin

Emet : suppression Reoit: validation

Modifier Compte

Emet : modification Reoit : validation

Consulter compte

Emet : consultation Reoit : Liste

Par la suite, nous illustrons graphiquement ce tableau par un diagramme de cas dutilisation global.

Figure 4.2 Uses Case Globale

17

Ce diagramme reprsente les cas dutilisation sans en montrer les dtails, chaque cas dutilisation sera dtaill plus bas. 2. Description des cas dutilisation Afin de dcrire les interactions entre les cas dutilisation, nous prsentons ces derniers de faon textuelle. Il sagit donc dassocier chaque cas dutilisation un nom, un objectif, les acteurs qui y participent, les pr-conditions et des scnarii. Cependant ; il existe trois types de scnarii : les scnarii nominaux ; les scnarii dexceptions et les scnarii alternatifs. Dans notre description textuelle, nous prsentons seulement les scnarii nominaux et alternatifs. Nous nous restreindro ns la description des cas dutilisation suivants : authentification et gestion des comptes (application Android et Web). Les autres cas sont dcris dans lannexe. 2.1 Cas d'utilisation " Authentification (identification utilisateurs) "

Titre

: Authentification (identification utilisateurs)

Parties prenantes et intrts : Authentifier un utilisateur se connectant au systme ; et lui prsenter linterface, les fonctionnalits relative son profil. Acteurs : Utilisateur. Pr conditions : Introduire login et mot de passe Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur saisi son login et son mot de passe. Enchanement (a) : Lutilisateur valide les donnes saisies. Enchanements alternatifs : Enchanement (b) : Vrifications de lexistence de lutilisateur par le systme. Enchanement (c) : Message de confirmation dentrer la session ou chec dentrer. Post conditions : Ouverture de lespace personnel.

Tous ces enchainements cits au dessus sont dcrits par le diagramme dactivit de la figure 4.3 :
18

Figure 4.3 : Diagramme dactivits du cas Authentification

2.2

Gestion des comptes

2.2.1 Cas d'utilisation " Crer un compte" Titre : crer un compte.

Parties prenantes et intrts : Faire enregistrer chaque nouveau compte. Acteurs : Utilisateur. Pr conditions : Ajouter un nouveau compte un client. Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur demande au systme lajout dun nouveau compte. Enchanement (a) : Crer un compte. Enchanement (b) : Valider le compte. Lutilisateur valide lajout du compte et le systme enregistre les nouvelles donnes saisies. Ce cas dutilisation se termine lorsque lutilisateur aura ajout le compte Post conditions : Le systme cre le nouveau compte. 2.2.2 Cas d'utilisation " Modifier un compte " Titre : Modifier un compte.

Parties prenantes et intrts : Faire enregistrer les modifications du compte, afin de mettre

19

jour les donnes. Acteurs : Utilisateur Pr conditions : Il existe forcment un compte enregistr modifier Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur demande au systme de modifier son compte. Enchanement (a) : Modifier un compte. Enchanement (b) : Valider la modification Lutilisateur valide la modification du compte et le systme enregistre les donnes modifies. Enchanements alternatifs : Ce cas dutilisation se termine lorsque lutilisateur aura modifi son compte. Post conditions : Le systme enregistre la modification du compte. 2.2.3 Cas d'utilisation " Consulter un compte " Titre : Consulter un compte.

Parties prenantes et intrts : Consultation des informations sur un compte. Acteurs : Utilisateur. Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur demande au systme de lui retourner les informations de son compte. Le systme affiche le compte. Ce cas dutilisation se termine lorsque lutilisateur aura consult leur compte. 2.3 Cas d'utilisation " Gestion QR Code " 2.3.1 Titre Cas d'utilisation Crer QR Code

: Crer QR Code.

Parties prenantes et intrts : Faire enregistrer des nouveaux QR Code Acteurs : User Scnario nominal : Ce cas dutilisation commence lorsque lut ilisateur demande au systme denregistrer un nouveau QR Code. Lutilisateur valide la crationdun QR Codeet le systme enregistre les donnes. Enchanements alternatifs : Ce cas dutilisation se termine lorsque lutilisateur aura crer son QR Code. Post conditions : Le systme enregistre la cration du QR Code

20

2.3.2 Cas d'utilisation Consulter QR Code Titre : Consulter un QR Code.

Parties prenantes et intrts : Faireafficher les diffrents QR Code du systme. Acteurs : User Pr conditions : Il existe forcment un QR Code enregistr afficher Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur demande au systme dafficher la liste des QR Code ou un QR Code bien dtermin. Lutilisateur choisit dafficher un ou des QR Code. Enchanements alternatifs : Ce cas dutilisation se termine lorsque lutilisateur aura affich le QR Code dsir. 2.3.3 Cas d'utilisation Partager QR Code Titre : PartagerQR Code. Parties prenantes et intrts : Faire partager des QR Code, afin de le publier aux clients. Acteurs : User Pr conditions : Il existe forcment un QR Code enregistr partager. Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur demande partagerun DR code. Enchanement (a) : Partager unQR Code. Enchanement (b) : Choisir laction de partage (Gmail, Twitter, Facebook) Lutilisateur valide laction de partage et le systme enregistre les donnes. Enchanements alternatifs : Ce cas dutilisation se termine lorsque lutilisateur aura choisirlaction de partage. Post conditions : Le systme enregistre laction de partage. 2.3.4 Cas d'utilisation Supprimer QR Code Titre : Supprimer QR Code.

Parties prenantes et intrts : Faire supprimerun QR Code bien dtermin Acteurs : Utilisateur Pr conditions : Il existe forcment un compte enregistr supprimer. Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur demande au systme de Supprimer QR Code.

21

Lutilisateur valide la suppression du QRcode. Enchanements alternatifs : Ce cas dutilisation se termine lorsque lutilisateur aura supprimle QR Code dsir. Post conditions : Le systme supprimele QR Code. 2.4 Cas d'utilisation " Gestion Carte de fidlit " 2.4.1 Titre Cas d'utilisation " Gestion Carte de fidlit "

: Crer Carte de fidlit.

Parties prenantes et intrts : Faire enregistrer des cartes de fidlit. Acteurs : Utilisateur Pr conditions : Il existe forcment un Point de vente pour lui faire une carte de fidlit. Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur demande au systme de crer une carte de fidlit. Lutilisateur cr une carte et le systme la valide. Enchanements alternatifs : Ce cas dutilisation se termine lorsque lutilisateur aura enregistr sa carte. Post conditions : Le systme enregistre la carte dquipe. 2.4.2 Cas d'utilisation Supprimer Carte de fidlit Titre : Supprimer Carte de fidlit. Parties prenantes et intrts : Faire supprimer une carte de fidlit parmi la galerie des cartes. Acteurs : Utilisateur Pr conditions : Il existe forcment une carte enregistr supprim Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur demande au systme de supprimer une carte. Lutilisateur valide la suppression. Enchanements alternatifs : Ce cas dutilisation se termine lorsque lutilisateur aura supprim la carte dsire. 3. Organisation des cas dutilisation Dans cette partie, nous procdons lorganisation des cas dutilisation en les rassemblant dans des packages.
22

3.1 Packages de cas dutilisation Dans cette tape ; nous regroupons les diffrents cas dutilisation cits auparavant dans des packages. Ce regroupement se fait suivant des critres. Le critre de regroupement que nous adoptons dans ce processus est le domaine d'expertise mtier. Par la suite ; nous reprenons le tableau prsentant les acteurs et les messages par cas d'utilisation, en affectant chaque cas d'utilisation un package. Nous obtenons le tableau ci dessous :
Tableau 4.2 : Liste des cas dutilisation et de leurs acteurs par package Cas dutilisation Acteur Package

Authentification (identification utilisateurs) Rcuprer mot de passe Modifier compte Ajouter compte Supprimer QR Code Crer QR Code Ajouter Compte Supprimer Compte Modifier Compte Consulter compte Crer carte Supprimer carte Rdiger actualits Supprimer actualits Modifier actualits Consulter actualits Rdiger actualits

Administrateur User

Gestion de profil

User

Gestion des comptes

User

Gestion QR Code

Gestion Admin clients

des

Comptes

Gestion des cartes de User fidlit

Admin

Gestion des actualits

23

3.2 Gnralisation des acteurs Si un ensemble d'acteurs communiquent de la mme faon avec certains cas d'utilisation, on peut crer un acteur gnralis (souvent abstrait), qui permettra de factoriser ce rle commun. Les acteurs spcialiss hritent alors des associations de l'acteur a nctre [6]. En se basant sur cette dfinition ; nous avons pu dgager les groupes dutilisateurs qui sont en interaction avec notre systme. Admin User 3.3 Diagramme de cas dutilisation Le diagramme de cas dutilisation est un moyen qui permet de dcrire les besoins des acteurs du systme. Cest un diagramme qui sert modliser un des aspects statiques du systme en passant du gnral au spcifique pour mettre en relief les besoins dj noncs dune manire dtaille. [7] Pour chaque package ; nous associons un diagramme de cas dutilisation. Voici les six diagrammes correspondants notre prcdent dcoupage: 3.4 Package Gestion des comptes clients Ladministrateur a plusieurs rles lis tout dabord la gestion des clients. Cette gestion inclut les tches de manipulation des donnes qui sont prsentes dans la figure 4.4 :

Figure 4.4 : Diagramme de cas dutilisation du package Gestion des comptes clients

24

3.5 Package Gestion des QR Codes Lagent commercialest responsable ausside la gestion des contrats. Le diagramme de la figure 4.5 reprsente les fonctionnalits accessibles par cet agent.

Figure 4.5 : Diagramme de cas dutilisation du package Gestion des QR Codes

3.6 Package Gestion des cartes de fidlit

Figure 4.6: Diagramme de cas dutilisation du package Gestion des cartes de fidlit

Ce cas dutilisation (figure 4.6) dtaille le package gestion des cartes de fidlit, qui sera prsente par lexcution de deux processus : La cration et la suppression des cartes. 3.7 Package Gestion actualit Dans ce cas dutilisation (figure 4.7), nous voyons plus en dtail comment stablie la gestion des actualits manipule par ladministrateur.
25

Figure 4.7 : Diagramme de cas dutilisation du package Gestion actualit

3.8 Package Gestion des scans Ce package est compos de trois taches : Scanner, supprimer, le partager un scan

Figure 4.8 : Diagramme de cas dutilisation du package Gestion des scan

3.9 Package Gestion des comptes Ce package consiste ajouter, modifier un compte client et la rcupration de mot de passe en cas de perte.

26

Figure 4.9 : Diagramme de cas dutilisation du package Gestion des comptes 4. Identification des classes participantes par package Dans cette partie, nous continuons le dialogue avec les utilisateurs, en mettant jour les abstractions du systme sous forme d'objets et de classes, et en essayant ainsi d'obtenir rapidement un consensus sur les dfinitions des concepts cls.[8] En exploitant la description des cas d'utilisation donns plus haut, nous avons pu ressortir les classes candidates qui participent dans chaque package. 4.1 Diagramme de classes participantes du package Gestion descomptes Nous distinguons dans ce package les classes suivantes : compte, profil, droit. (Figure 4.10)

Figure 4.10 : Diagramme des classes participantes de Gestion des comptes

4.2 Diagramme de classes participantes du package Gestion des Actualits Daprsles descriptions du cas dutilisation gestion actualit ; nous pouvons laborer le diagramme des classes participantes suivant :
27

Figure 4.11 : Digramme des classes participantes de Gestion des Actualits

4.3 Diagramme de classes participantes du package Gestion des QR Code La classe QR Code est fortement en relation avec plusieurs classes. (Figure 18). En effet ; un compte peut avoir plusieurs QR Code qui suit un type de codage bien prcis.

Figure 4.12 : Diagramme des classes participantes de Gestion des QR Code

4.4 Diagramme de classes participantes du package Gestion des cartes de fidlit Nous spcifions dans ce package les classes suivantes : compte, carte fidlit, prestataire. (Figure 4.13). En effet, une carte de fidlit ncessite la cration dun compteet unprestataire de service.

28

Figure 4.13 : Diagramme des classes participantes de Gestion des cartes de fidlit

4.5 Diagramme de classes participantes du package Gestion des statistiques

Figure 4.14 : Diagramme de classes participantes du package Gestion des statistiques En effet, ce diagramme montre la relation entre les deux classes : utilisateur et statistique. Conclusion Une fois notre tude conceptuelle approfondie est termin aprs avoir modlis les besoin des utilisateurs, on passe directement prparer et analyse rlenvironnement et les besoins techniques pour notre application

29

Chapitre 5 : Capture des besoins techniques


Introduction

On va sintresser la branche droite du cycle en Y qui est la capture des besoins techniques en couvrant avec celle des besoins fonctionnelsles contraintes qui ne traitent pas la description applicative. Nous choisissons lors de cette phase lenvironnement de travail ainsi que larchitecture globale utilise pour notre systme.

Figure 5.1 : Situation de la capture des besoins techniques dans 2TUP

1. Architectures Client/serveur Lexpression des besoins techniques implique galement le choix darchitecture. Ce choix est crucial puisquil intervient dans lvolutivit du systme, le temps de dveloppement, le cot et les performances. 1.1 Architecture simple tie rs La conception de lapplication est labore de manire fonctionner sur un ordinateur unique. En fait, tous les services fournis par l'application rsident sur la mme machine et
30

sont inclus dans l'application. Toutes les fonctionnalits sont donc comprises dans une seule couche logicielle.

Figure 5.2 : Architecture simple tiers

1.2 Architecture client/serveur Cestune architecture 2-tiers appele aussi architecture client lourd/serveur. Elle est assez simple dans sa mise en uvre. Ce type d'architecture est constitu uniquement de deux parties : le client lourd demandeur de service dune part et le serveur de donnes qui fournit le service d'autre part.[9] Nous aurons donc la base de donnes qui sera dlocalise sur un serveur ddi appel leserveur de donnes qui fournira les donnes exploiter.

Figure 5.3 : Architecture client/serveur

31

1.3 Architecture trois tiers Cette architecture physique est assez semblable larchitecture client/serveur, mais en plus des clients et duserveur de donnes voques plus haut, un serveur d'application intervient comme un troisime tiers. En effet, les machines clientes, galementappelesclients lgers ne contiennent que l'interface de l'application de manire quelles dcharges de tout traitement. [9] En effet, le traitement est ainsi assur par le serveur d'application, qui sertde liaison entre l'interface applicative et les donnes localises au niveaudu serveur de donnes.

Figure 5.4 : Architecture 3 tiers

3.

Configuration matrielle du systme Les choix des pr-requis techniques dj mentionns dans ltude prliminaire, lors de lexpression des besoins oprationnels, impliquent des contraintes relatives la configuration du rseau matriel, les performances daccs aux donnes ainsi que la scurit du systme, lintgration des applications, la volumtrie et le mode dutilisation du systme. Afin de concevoir notre application, nous avons opt larchitecture 4-tiers. Elle reprsente la solution la plus adapte notre systme car elle nous offre : Des meilleures performances grce la rpartition des charges de travail. Une disponibilit de linformation en temps rel. Une rpartition des tches entre les acteurs du systme Une technologie a la mode et plus prsentable.
32

La configuration matrielle de notre systme est schmatise comme suit :

Figure 5.5 : Configuration matrielle du systme

Comme le montre la figure5.5, notre systme est quip de : Un serveur de gestion de base de donnes comporte une importante capacit de stockage, doit tre disponible afin quon puisse y accder tout moment, et doit avoir une puissante capacit de traitement dans le cas o plusieurs clients y accdent en mme temps. Client (Web ou Android) sont des ordinateurs de bureau ou toutes sortes de machine ayant unnavigateur web qui permet daccder internet (ce sont de type client lger), ou des clients Mobile. Serveur we b est un serveur qui rpond aux commandes des clients. Serveur dapplication est lenvironnement dexcution des applications. 4. Spcification darchitecture Sur le plan logique ; notre architecture (4 tiers) est mise en uvre suivant le modle MVC (Modle Vue Contrleur) qui s'applique donc au niveau du client. En effet, la spcification dune architecture composants mtier 4-tiers implique la rpartition des composants dexploitation suivant les responsabilits. Le diagramme de composants ci-dessous, montre les diffrents types de composants dexploitation du systme.

33

Figure 5.6 : Diagramme de composant de systme

Conclusion Au cours de ce chapitre, le choix de larchitecture physique a t choisi selon lenvironnement adopt. On va modliser les diffrents diagrammes dUML qui vont tre reprsent dans le chapitre suivant.

34

Chapitre 6:Analyse
Introduction En se rfrant la dmarche de 2TUP on passe la phase danalyse qui reprsente la deuxime tape de la branche gauche du cycle en Y. Au cours de cette tape, on va reprsenterune vue statique du systme par la modlisation de diagramme de classe puis , et une vue dynamique par la modlisation des diagramme de squence. 1. Dcoupage en catgorie Le dcoupage en catgories se situe sur la branche gauche du cycle en Y. En fait, il succde ltape de capture des besoins fonctionnels constituant ainsi la premire activit de ltape danalyse. [9] Ce dcoupage permet de dterminer les classes fondamentales du projet en utilisant les diagrammes des classes participantes dgages dans ltape de captures des besoins fonctionnels.

Figure 6.1 Dcoupage en catgorie

2. Dveloppement du modle statique Le dveloppement en modle statique reprsente la deuxime activit de ltape danalyse. Lors de cette tape, nous reprenons les diagrammes de classes participantes dj identifis auparavant et organiss lors du dcoupage en catgories afin de les affiner en leur ajoutant des attributs.[10]

35

2.1

Diagramme de classe

Figure 6.2 : Diagramme de classe

3. Dveloppement du modle dynamique Le dveloppement du modle dynamique est la troisime activit de ltape danalyse. Cette activit est en relation avec lactivit de modlisation statique. Lors de cette tape, nous dcrivons les diffrentes interactions entre les objets de notre application. En effet, nous avons utilis s le modle dynamiques : le diagramme de squence.

36

Diagrammes de squences Le diagramme de squence est un diagramme dinteraction entre les objets, qui met laccent sur le classement des messages par ordre chronologique durant lexcution du systme. Un diagramme de squence est un tableau dans lequel les objets sont rangs sur laxe des abscisses et des messages par ordre dapparition sur laxe des ordonnes. [10] Il est utilis pour reprsenter certains aspects dynamiques dun systme : dans le contexte dune opration, dun systme, dun sous-systme, dun cas dutilisation (un scnario dun cas dutilisation) selon un point de vue temporel. En effet dans cette phase, et aprs identification des cas dutilisation, nous reprsentons laide des diagrammes de squences, quelques scenarios cot mobile (pareil cot web) associs aux catgories gestion des QRCode et gestion des comptes ainsi que lauthentification des utilisateurs. 3.1 Diagrammes de squences de Authentification

Aprs le dmarragede lapplication, lutilisateur saisi son login et son mot de passe. Une fois quil valide la saisie des donnes, le systme sassure dabord que les informations entres nont pas la valeur NULL puis il vrifie ces donnes au prs de la base de donnes. C ette tape sachve soit par louverture de lespace personnel associ lutilisateur, soit par laffichage de message derreur (voir Figure 6.3).

37

Figure 6.3 Diagramme de squence du scnario Sauthentifier

En cas de perte ou loubli de mot de passe lutilisateur peut le retrouver en saisissant son Email.

38

Le diagramme de squence si dessous reprsente ce scnario :

Figure 6.4 Diagramme de squence du scnario Mot de passe oubli Dans la suite, nous reprsentons les diffrents scnarios du package gestion des inscriptions. 3.2 Diagramme de squence du scnario inscription dun utilisateur

Ce cas dutilisation commence lorsque lutilisateur demande au systme de faire une inscription. Une fois le formulaire est affich, il remplit les champs de saisies puis enregistre ses donnes. Le systme sassure dabord que les champs obligatoires nont pas la valeur NULL ensuite il enregistre les informations entres dans la base de donnes. Ce cas dutilisation se termine lorsquunEmail de confirmation dajout saffiche la boite de rception dEmails (voir figure 6.5).

39

Figure 6.5 : Diagramme de squence du scnario Inscription

3.3

Diagramme de squence du scnario Modifier compte

Aprs avoir dcid de mettre jour son compte, lutilisateur effectue une demande de modification. Une fois le formulaire de mise jour apparait, ilsaisit ses nouvelles donnes puis il valide la modification pour que le systme enregistre les donnes mod ifies. Ce cas se termine lorsquun message de confirmation saffiche.

40

Figure 6.6 : Diagramme de squence du scnario Modifier compte

3.4

Diagramme de squence du scnario cration dun QR Code

Lorsque lutilisateurveut enregistrer un QR Code, il remplit le formulaire de cration avec des donnes correctes si non un message derreur saffiche indiquant une erreur denregistrement.

Figure 6.7 : Diagramme de squence crer QR Code


41

3.5

Diagramme de squence du scnario suppression et partage dun QR Code

Il peut ainsi aprs cration le partager et de faire une demande de suppression. Ce scnario sachve lorsque lutilisateur valide ou annule la suppression

Figure 6.8 : Diagramme de squence supprimer/partager QR Code

42

3.6

Diagrammes de squence du scnario concernant Administrateur ajout publicit, ajout statistique et ajout actualit

Figure 6.9 : Diagramme de squence ajouter publicit

Figure 6.10 : Diagramme de squence ajouter statistique


43

Figure 6.11 : Diagramme de squence ajouter actualit Le scnario ci-dessous illustre les dtails de traitement des QR Codes ; Scanner, supprimer ou partager un QR Code.

Figure 6.12 : Diagramme de squence traitement QR Code 44

3.7

Diagramme de squence du scnario cration et suppression duneCarte De fidlit

Figure 6.13 : Diagramme de squence crer, supprimer Carte de fidlit

1. Elaboration des diagrammes de collaborations Le diagramme de collaboration sert galement illustrer des interactions entre les objets travers la reprsentation denvoi de message dans le cadre dun fonctionnement particulier du systme. En effet, il est utilis pour modliser le contexte du systme. Enfin, les diagrammes decollaboration permettent de concevoir les mthodes.[11]

45

1.1

Diagrammes de collaborations Authentification

Figure 6.14 : Diagramme de collaboration de la catgorie Authentification Ce diagramme nous illustre le scnario dauthentification dcrit par le diagramme de squence travers lchange des messages entre lutilisateur et le systme. 1.2 Diagramme de collaborations de scnario Mot de passe oubli

Figure 6.15 : Diagramme de collaboration de la catgorie Mot de passe oubli

46

Dans les diagrammes qui suivent, nous allons schmatiser lecas dinscription des clients 1.3 Diagramme de collaboration du scnario Inscription

Figure 6.16 : Diagramme de collaboration du scnario Inscription 1.4 Diagramme de collaboration du scnario Modifier compte

Figure 1.17 : Diagramme de collaboration du scnario Modifier compte

47

1.5

Diagramme de collaboration du scnario crer des QR Code

Figure 6.18 : Diagramme de collaboration du scnario cration des QR Codes

1.6

Diagramme de collaboration du scnario crer des carte de fidlit

Figure 6.19 : Diagramme de collaboration du scnario crer des carte de fidlit

48

1.7

Diagramme de collaboration de ladministrateur

Enfin nous allons reprsenter le diagramme de collaboration concernant les taches de ladministrateur

Figure 6.20 : Diagramme de collaboration de ladministrateur Conclusion Au cours de ce chapitre, nous avons prsent tape danalyse quinous a permis de passer dune structuration fonctionnelle via les cas dutilisations et lespackages une structuration objet via les classes et les catgories.

49

Chapitre 7 : Ralisation
Introduction Dans ce chapitre, nous prsentons la partie ralisation et mise en uvre de notre travail. Pour cela, nous prsentons, en premier lieu, lenvironnement de travail et les outils de dveloppement utiliss. En second lieu, nous laborons une prsentation des diffrentes interfaces cres.

1. Technologies Dans le tableau 7.1, on va reprsenter les diffrentes technologies utilises dans notre application et quon va les dtailler par la suite: Tableau 7.1 : technologies utilises
Androi d Systme d'explo itation open source pour Smartphones, PDA et terminau x mobiles Vo ir annexe 1 pour plus de dtails Grails

Framework de dveloppement rapide pour les applications web, il est bas sur le langage Groovy do le nom Grails pour Groovy on Rails. Grails nest pas seulement un Framework libre pour Java mais constitue une plateforme de dveloppement part entire. Il sorganise autour du modle M-V-C Pour plus de dtails voir annexe 2.
Groovy Langage de programmation orient objet destin la p late-forme Java. MySQL Systme de gestion de base de donnes (SGBD).

50

JSON (JavaScript Ob ject Notation) Format de donnes textuel, gnrique.

Service Web RES T cest le style architectural original du Web.

Groovy est un langage relativement nouveau il peut aussi bien tre compil que interprt et il est spcifiquement dsign pour la plateforme Java. Il est inspir des langages tels que Ruby, Python, Perl et mais repose principalement sur java.[12] Une tude comparative semble ncessaire entre Java et Groovy montr dans le tableau 7.1.
Tableau 7.2: Comparaison entre Java et Groovy

Java 2
S tring name = "World" S ystem.out.println ("Hello " + name); Objectname = "Groovy"; S ystem.out.println(((S tring) name).toUpperCase()); S tring[]s={"Php", "Grails "," Java " }; for(inti = 0; i <S.length; i++) if(S [i].length()<= 4) S ystem.out.println(S );

Groovy
def name = "World" println "Hello $name" def name = "Groovy" printlnname.toUpperCase()

list = ["Php ", "Grails ", " Java "] shorts =list.findAll{it.size() <= 4} shorts.each { printlnit }

Structure d une application avec Grails La structure dun projet cr laide du Grails est illustre dans le tableau 7.2:
Tableau 7.3: structure dune application sous Grails

Rpertoire
domain/

Description
Contient les classe domaine du projet

controllers/

Contient les contrleurs du projet

views/

Contient les vues du projet

51

lib/

Les librairies et classes du projet

conf/

Les fichiers de configuration du projet

pl ugins/

Les plugins installs

test/

Les tests unitaires et fonctionnels

web/

Le rpertoire racine web (fichier css, js,.. )

2. MVC (Model-Vie w-Controller) Cest une architecture et une mthode de conception qui organise l'interface hommemachine (IHM) d'une application logicielle. Ce paradigme divise l'IHM en trois parties : Modle : dcrit les donnes manipules par l'application et dfinit les mthodes d'accs. Vue : est la reprsentation des donnes dans des interfaces avec lesquelles l'utilisateur interagit. Contrleur : prend en charge la gestion des vnements de synchronisation pour mettre jour la vue ou le modle. Le mode de fonctionnement du MVC commence par lenvoi dune requte lapplication par le client, celle-ci est analyse par le contrleur, qui demande au modle appropri d'effectuer les traitements, puis renvoie la vue adapte au navigateur.[13]

52

Figure 7.1 : Le modle MVC

3. Prsentation du Json JSON (JavaScript Object Notation Notation Objet issue de JavaScript) est un format lger d'change de donnes. Il est facile lire ou crire pour des humains. Il est aisment analysable par des machines. JSON est un format texte compltement indpendant de tout langage. Ces proprits font de JSON un langage d'change de donnes idal.[14] 3.1 Caractristiques Un document JSON ne comprend que deux lments structurels : des ensembles de paires nom / valeur des listes ordonnes de valeurs. Ces mmes lments reprsentent 3 types de donnes : des objets des tableaux des valeurs gnriques de type tableau, objet, boolen, nombre, chane ou null

53

3.2 Avantage Le principal avantage de lutilisation de JSON, dans notre application, est quil est simple mettre en uvre. Au rang des avantages, nous pouvons galement citer [15]: Facile apprendre, car sa syntaxe est rduite et non-extensible; Ses types de donnes sont connus et simples dcrire ; Peu verbeux et lger, ce qui le rend bien adapt aux terminaux mobiles au contraire au langage XML qui est trs verbeux. COMMENT JSON VA TRE UTILIS DANS NOTRE APPLICATION ? Lorsque notre application Android s'excute, elle se connectera au serveur web qui va rcuprer les donnes depuis la base de donnes MySQL en utilisant les services web de type Rest. Ensuite les donnes seront encodes au format JSON et envoyes au syst me Android. Lapplication va obtenir ces donnes codes. Elleles analysera et les affichera sur le mobile. La Figure 7.4 illustre bien la faon dchanger les donnes entre le client Android et la partie des serveurs (web/MySql) :

Figure 7.2 : Format JSON

4. Prsentation des services web 4.1 Dfinition Un service web est un programme informatique permettant la communication et l'change de donnes entre applications et systmes htrognes dans des environnements distribus. Il s'agit donc d'un ensemble de fonctionnalits exposes sur internet ou sur un intranet, par et pour des applications ou machines, sans intervention humaine, et de manire synchrone.[16]
54

Il existe deux grandes familles de services web : Les services web de type SOAP Les services web de type REST 4.2 Services web de type SOAP 4.2.1 Description

SOAP (Simple Object Access Protocol) est un protocole RPC orient objet bti sur XML ce qui le rend indpendant de tout systme d'exploitation et de tout langage de programmation, il permet de faire des appels de procdures entre objets distantsphysiquement situs sur un autre serveur.[17] SOAP est dfini pour tre indpendant du protocole de transport utilis pour vhiculer le message. Cependant, le protocole le plus utilis avec SOAP est HTTP car c'est un des protocoles le plus rpandu et utilis du fait de sa simplicit. Son utilisation a vec SOAP permet de rendre les services web plus interoprables. 4.2.2 Structure

Le protocole SOAP est compos de deux parties : une enveloppe, contenant des informations sur le message lui- mme afin de permettre son acheminement et son traitement, un modle de donnes, dfinissant le format du message, c'est--dire les informations transmettre.

Figure 7.3. Structure dune enveloppe SOAP L'entte contient des informations sur le traitement du message. Le corps du message SOAP contient les donnes changes entre le client et le service.

55

4.3 Services web de type REST 4.3.1 Description

REST (REpresentational State Transfer) est une manire de concevoir des applicatio ns ou des services Web.[18] Il nest pas un protocole ou un format, cest un style darchitecture. [18] 4.3.2 Caractristique

Bien que REST ne soit pas un standard, il utilise des standards. En particulier lURI : connatre lURI doit suffire pour nommer et identifier une ressource HTTP fournit toutes les oprations ncessaires (GET, POST, PUT et DELETE).

Figure 7.4. : Caractristique dun Web Service REST

L'utilisation de GET : l'tat de la ressource ne doit pas tre modifi par un GET. Ceci Il faut donc utiliser GET pour des oprations qui ressemblent des questions ou des lectures de l'tat de la ressource.En revanche, il faut utiliser POST quand la demande ressemble une commande, ou quand l'tat de la ressource est modifi ou quand l'utilisateur est tenu pour responsable du rsultat de l'interaction.[19]
PUT et DELETE pour crer ou supprimer une ressource

Mthode
GET

Action
Afficher

PUT

Mise jour

POST

Enreg istrer

Tableau7.4. Les mthodes REST


56

1.1.1

Avantage

Lapplication est plus simple entretenir, car les liens sont mieux structurs, et de faon universelle ; les liens sont le moteur de ltat de lapplication. Labsence de gestion dtat du client sur le serveur conduit une consom mation de mmoire infrieure, une plus grande simplicit et donc une capacit plus grande de rpondre un grand nombre de requtes simultanes. 1.1.2 Comparaison entre SOAP et REST

Lutilisation du protocole HTTP en tirant partie de son enveloppe et ses enttes, loppos de SOAP qui ne prsuppose pas un protocole : SOAP rinvente un protocole via une enveloppe, des enttes et un document, lintrieur du protocole rseau lhbergeant (la plupart du temps HTTP). Il ne bnficie donc pas des caractristiques HTTP, gre par linfrastructure rseau.[19] POUQUOI REST VA TRE UTILIS DANS NOTRE APPLICATION MOBILE ?

Pour faire communiquer une application quelconque avec le monde extrieur, le choix en matire de protocole est trs vaste. Nanmoins sur Android, compte tenu des contraintes lies la machine virtuelle Dalvik, ce choix est beaucoup plus limit. Android tant pens comme un systme web, le protocole de transport roi est le HTTP. Lorsquil sagit dinterroger un serveur distant, un protocole de type REST bas sur JSON parait bien adapt. Lusage de SOAP est bien possible mais la lourdeur de ce protocole ne semble pas le prdisposer aux terminaux mobiles.[20] Finalement on va donner une reprsentation de notre architecture qui illustre bien lutilisation des services web de type REST :

57

Figure 7.5 : Principe de communication via REST

Tache ralises et rsultat obtenu Tache annule Tache ralise personnellement Tache ralise par une autre personne

Taches Parties Conception lapplication de Ralisation de ltude de la base de donnes Crer les tables de la BD

Ralisation

Etablir les liaisons entre les tables Back Office Crer pub Crer espace Admin

58

Crer Compte

Crer Compte WebService REST (JSON + XML) Update Compte Update Compte WebSe rvice REST (JSON + XML) Front office Sauthentifier Sauthentifier WebService REST (JSON + XML) Rcuprer le mot de passe oubli dans un mail Rcuprer le mot de passe oubli dans un mail via un WebService REST (JSON + XML) Enregistrer les QR Code cr dans la BD via un WebService REST (JSON + XML) Cons ulte r les QR Code Cr WebService REST (JSON + XML) Splash Screen Menu principal en deux versions Scan des codes a barre Application Android Crer des QR Code de diffrents types (sms, email, contact, phone, url, texte) Partager QR Code cr (FaceBook, Twitte r, Skype, sms, email) Crer un compte utilisateur via WebService REST un

59

Authentification via un WebService REST Cons ulte r Compte via un WebService REST Mise a jour dun compte via un

WebService REST Cons ulte r un flux RSS dactualit Rcuprer un email dans le cas du mot de passe oublier via un WebService REST Ralisation de ltude de la base de donnes interne Crer les tables de la BD SQLite interne Application Android

Etablir les liaisons entre les tables Cons ulte r lhistorique des QR Code Scanner des cartes de fidlit Gnrer une carte de fidlit Cons ulte r la liste des cartes de fidlit Cons ult les surface de vente via la Ralit augment (100 % ralis) Cons ult les surface de vente via une MapVie w (100 % ralis) Cons ult les surface de vente via une List Vie w (100 % ralis)

Tableau 7.5 :les taches ralises dans lapplication

60

5. Application Nous prsentons dans cette section quelques interfaces principales de notre ralisation qui illustrent les diffrents cas dutilisation dj vus dans le chapitre tude prliminaire. Au dmarrage de notre application une interface daccueil dmarre com me le montre la figure 7.8

Figure 7.6 : interface daccueil

Une fois authentifi, lutilisateur accdera lensemble des fonctionnalits de lapplication via le menu vertical ou horizontal.

61

Figure 7.6 : Interface dauthentification

Si lutilisateur ne possde pas un compte il doit sinscrire pour bnficier des fonctionnalits de lapplication.( Figure 7.9 ) En cas de perte de mot de passe, lutilisateur peut la rcuprer via son mail comme le montre limage qui suit. (Figure 7.10 )

Figure 7.7 : Interface dinscription

Figure 7.8 : Interface de password oubli

62

Puis on va reprsenter notre interface du menu principale par deux models diffrents : comme le montre la figure 7.11

Figure 7.9 : Menu principal Pour la suite, nous reprsentons la fonctionnalit du scan dun QR Code.

Figure 7.10 : Opration du scan dun QR Code

Apres le scan le rsultat sera enregistr dans lhistorique des scans quon peut le consulter comme suit tout dpend de nature du QR Code comme le montre la figure Figure 7.13

63

Figure 7.11 : Rsultat dun scan

Pour crer un QR Code lutilisateur va choisir le type du QR Code dans linterface liste view (contact, email, ma position, numro tlphonique, sms, url, texte), soit le type ma position comme exemple :

Figure 7.12 : Cration dun QR code

Une fois crer, lutilisateur va slectionner un choix de la source soit GPS soit la connexion tlphonique Le QR Code est gnre ce moment- l lutilisateur peut le partager (Figure 7.14)
64

Figure 7.13 : Partage dun QR code

Tunitag offre la possibilit de consulter les cartes de fidlits dj cr, afin de la prsenter la caisse lutilisateur doit choisir la carte correspondante voir figure 7.15

Figure 7.14 : Consultation des cartes de fidlit

Pour crer une nouvelle carte dans la galerie, aprs avoir slectionner le bouton +, lutilisateur va slectionner un type selon le logo de la surface de vente comme le monte limage 7.16
65

Figure 7.15 : Cration des cartes de fidlit

Une fois slectionn un nom, la fentre ci-dessous se lance pour scanner le code a barre du Carte correspondante ou saisir manuellement le code.

Figure 7.16 : Scan du code a barre dune carte de fidlit

66

Figure 7.17 : Opration du scan code barre dune carte de fidlit

Les images de la figure 7.17 illustres bien lopration Tunitag permet aussi de consulter lactualit du site Tunitag. Voir figure 7.18

Figure 7.18 : Consultation des actualits

Conclusion Dans ce chapitre, nous avons prsent les choix techniques que nous avons adopts, ainsi que lenvironnement dimplmentation et quelques interfaces de notre application.

67

CONCLUSION GENERALE ET PERSPECTIVES Notre projet a consist en la conception en se basant sur le processus unifi 2TUP, le dveloppement et lintgration dune application nomm Tunitag au sein de la socit Ultimate Agency afin dapporter une valeur ajoute et un meilleur service aux clien ts. Nous sommes arrivs dvelopper toutes les fonctionnalits du systme dans les temps. Lintgration a t ralise avec succs, c'est-- dire que lapplication est maintenant installe sur le mobile et prte tre commercialis. Ce stage nous a per mis dapprofondir nos connaissances thoriques, acquises tous le long de notre formation, par la pratique des nouvelles technologies. Cette exprience nous a permis de matriser le langage de modlisation UML, les outils de dveloppement Android savoir le SDK Android ainsi que le framework Grails, sous lequel, le dveloppement na pas t une tche facile, mais nous navons pas hsit y participer, malgr quil y a peu du support. Il nous a galement permis de dcouvrir comment se passe lintgration dune application sur un serveur web distant ainsi que lutilisation du format JSON pour grer la

communication des donnes entre deux environnements htrognes qui sont le client Android et le serveur de bases de donnes Mysql. Le stage quotidien au sein de la socit a aussi t pour nous une occasion unique pour panouir nos capacits de communication dans un environnement professionnel. Cest une exprience trs enrichissante sur tous les domaines. Bien que les principaux objectifs de notre proj et soient atteints, lapplication que nous avons dvelopp pourrait tre enrichie par dautres fonctionnalits avances et amliorations peuvent tre envisages pour lenrichir, tel que la Go localisation des surfaces de vente (Ralit augmente, Mapview, List view), un comparateur de prix, un service d'horaire de bus par QR Code Concernant lapplication mobile, elle peut tre implmente sur des plateformes autres que Android. Nous souhaitons, enfin, que ce modeste travail apporte satisfaction aux membres du jury et toute personne intresse, de prs ou de loin.

68

Annexe 1
Test des web services Il est prfrable de tester les services web avant de les implment dans lapplication

Android. Pour ce faire, on a procd un plugin RESTClient du navigateur Firefox , qui reprsente un client virtuel. RESTClient est un dbuggeur pour les services-web de type REST. C'est un bon outil, trs pratique pour tester et dboguer un logiciel - en particulier les services Web. RESTClient supporte toutes les mthodes du protocole HTTP ("GET", "POST", "DELETE", ... ). Il permet de construire sur mesure les requtes HTTP et de tester directement les demandes sur un serveur. Il suffit de remplir les champs "URL" de la requte, choisir le type de requte et remplir le corps de la requte si besoin (JSON ou XML) pour enfin l'excuter en envoyant la requte. Puis RESTClient affiche la rponse formate en XML ou JSON envoye par le serveur, son affichage est bien claire et facilite la lecture des informations.

Les imprimes suivants donnent une ide sur cette utilisation : Test du WebService Inscription

La figure prcdente reprsente un test dutilisation du web service REST pour crer un objet user sous format JSON, dans la table user de la BD MySql de notre projet. Utilisation de la mthode POST pour envoyer via URL indiquant un objet JSON comme le montre la partie Body, en contre partie le serveur va rpondre par un objet du mme format, compos dun name respence et un value 1 pour indiquer que la cration a t faite avec succs. Une partie du code de la fonction CreateUserJSON de UserController.groovy
if (userInstance.validate()) { userInstance.save(); response.status = 201 try { sendMail { to "${userInstance. email }" subject "Tunitag: Bien venu !" html g.render(template:'/email/inscription', model:[user:userInstance]) } def rep = [ respence: "1" ] // Confirmation denvoi demail render rep as JSON } catch (Exception e) { def rep = [ respence: "2" ] // Problem sending email render rep as JSON } } else { } def rep = [ respence: "0" ] // email dja utilis render rep as JSON

Remarquons bien que lobjet envoy est bien cre dans la table user de notre BD

Aussi un email a t envoy pour dire bienvenue !

Lutilisateur peut se connecter lapplication Android ou web aprs avoir sauthentifier en saisissant son login et mot de passe.

Test authentification Android : Code source JAVA, la fonction onClick reprsente lcouteur de la clique sur le bouton Connect

public static String URL = http;//10.0.2.2:8080/TestTun/user; public void onClick(View v) { String em = Email.getText().toString(); String ps = PassWord.getText().toString(); HttpPost request = new HttpPost(URL); JSONStringer json = null; try { json = new JSONStringer() .object() .key("email").value(em) .key("password").value(ps) .endObject(); } catch (JSONException e) { // TODO Auto-generated catch block e.printStackTrace(); } Log.i ("json",json.toString()); StringEntity entity = null; try { entity = new StringEntity(json.toString()); } catch (UnsupportedEncodingException e) { // TODO Auto-generated catch block e.printStackTrace(); } entity.setContentType("application/json;charset=UTF-8"); entity.setContentEncoding(new BasicHeader(HTTP. CONTENT_TYPE,"application/json;charset=UTF-8")); request.setEntity(entity); // Send request to WCF service DefaultHttpClient httpClient = new DefaultHttpClient(); try { HttpResponse response = httpClient.execute(request); Log.i("Send request",json.toString()); } catch (ClientProtocolException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } }

Apres lenvoie de la requte Get au serveur, il ne reste lapplication Android quattendre la repense : 1 pour dire que lauthentification est valide. 0 authentification non valide, email ou mot de passe incorrecte.

Authentification Web :

Supposons quun utilisateur a oubli son mot de passe, il peut le rcuprer par la saisie de son mail. Test du WebService mot de passe oubli

Respence = 1 le mail est bien envoy !

Implmentation s ur Android :

Implmentation s ur le site Web:

Annexe 2
1. Smartphones et applications mobiles Ces dernires annes, larrive de nouveaux acteurs: Apple avec son Iphone et Google avec Android, a chang la faon de concevoir le mobile : ce n'est plus un outil pour appeler et recevoir des messages, le tlphone est devenu un moyen de tout faire o que l'on soit. Il est ainsi devenu un outil plus qu'indispensable pour certains mtiers et certaines classes sociales. Nous exhibons dans ce qui suit des statistiques sur ces acteurs afin de mieux comprendre leurs situations actuelles. Ensuite, nous prsentons linternet et les applications mobiles. 1.1 Android : statistiques impressionnantes Le taux dactivations des appareils Android, qui tait de 300 000 par jour en fin 2010, 700.000 par jour en fin 2011. Aujourdhui, en dbut 2012, 850 000 tlphones Android par jour. Cest lentour de 6 millions de tlphones par semaine, environ 24 millions de tlphones par mois, ou 288 millions de tlphones par an. Concernant les applications Android, le Google Play Store a dpass au 1er Fvrier 2012 la barre des 400 000 applications. Le nombre dapplications a tripl en un an. Le nombre de tlchargements faits sur le Play Store depuis son lancement est 10 milliard, mais ce nest pas tout, Google annonce que le taux mensuel de tlchargements dappl ications Android est aujourdhui dun milliard par mois. 1.2 Technologies de dveloppe ment dapplications mobiles sous Android 1.2.1 Prsentation

Android est un OS (Operating System) mobile Open Source pour Smartphone, PDA (Personal Digital Assistant) et tablette. Conu initialement par Android Inc. Android a t rachet par Google en 2005. LOS Android a t lanc officiellement le 15 novembre 2007.

1.2.2

Architecture

La figure 4 illustre les composants principaux du systme dexploitation Android. Chaque section sera dcrite dans ce qui suit.

Architecture Android

1.2.3

Applications

Android est fourni avec un ensemble dapplications dont un client email, une application SMS, un calendrier, un service de cartographie, un navigateur etc. Toutes crites en JAVA. 1.2.4 Frame work de dveloppe ment

En fournissant une plateforme de dveloppement ouverte, Android offre aux dveloppeurs la possibilit de crer des applications extrmement riches et innovants. Larchitecture dapplication est conue pour simplifier la rutilisation des com posants. 1.2.5 Bibliothques

Android dispose dun ensemble de librairies C/C++ utilises par les diffrents composants du systme Android. Elles sont offertes aux dveloppeurs travers le framework Android.

1.2.6

Android Runtime

Android inclut un ensemble de librairies de base offrant la plupart des fonctionnalits disponibles dans les bibliothques de base du langage de programmation Java. Chaque application Android sexcute dans son propre processus, avec sa propre instance de la machine virtuelle Dalvik. Elle a t crite pour que le dispositif puisse faire tourner plusieurs machines virtuelles de manire efficace. La machine virtuelle Dalvik sappuie sur le noyau Linux pour les fonctionnalits de base telles que le filetage et gestion de la mmoire de bas niveau. 1.2.7 Linux Ke rnel

Android repose sur la version Linux 2.6 pour les services systme de base tels que la scurit, la gestion mmoire, gestion de processus pile rseau, et le modle de pilote. Le noyau agit galement comme une couche dabstraction entre le matriel et le reste de la pile logicielle.

Annexe 3
3. Frame work Grails 3.1 Prsentation Grails comme tout autre Framework Java se basant sur ce patron de conception, Grails possde des modles qui comportent les donnes et qui sont rfr en tant que "Domain class" mais la diffrence consiste dans le fait que dans Grails ces modles sont persistants et peuvent directement tres mapps dans la Base de donne gnrant ainsi le schma de donnes de lapplication. Dans Grails cest les contrleurs qui grent les requtes et organisent le travail des services et autres composants de la couche mtier. Finalement la partie Vue est constitu des GSP (Groovy Server Pages) et qui intgrent eux aussi des fonctionnalits trs intressantes tels que les "TagLib", "les Templates" ou encore les "layout". Tous ces lments seront revus plus en dtails dans les sections qui suivront. 3.2 Architecture du frame work Grails

Architecture du framework Grails

Voici un schma qui rcapitule l'architecture de Grails : il se base sur : Le Framework Spring : qui est un Framework open source dont la principale fonction est la construction de linfrastructure dune application java. Spring est dcrit comme tant un conteneur "lger", c'est--dire quil prend en charge la cration des objets et leur mise en relations en utilisant des fichiers de configuration, comportant la description de chacun et les relations qui les relient les uns aux autres. Le Framework SiteMesh qui va grer la mise en page. Il implmente le design pattern decorator pour gnrer les pages html. Il va par exemple nous permettre dajouter des enttes et pieds de page sur chacune des pages de l'application. GORM nous permet d'tablir les relations entre les objets Groovy et le schma relationnel. GORM, bas sur Hibernate, est une couche d'abstraction par rapport aux bases de donnes. Par dfaut, Grails utilise la base de donne intgre Hibernate: HSQLDB. Gant (pour "Groovyant"), est une couche au-dessus du clbre "ant" qui permet d'crire les tches en groovy plutt qu'en XML. Les commandes permettant de grer Grails utilisent Gant. 3.3 Fonctionne ment Les principes de fonctionnement de Grails est le suivant: CoC (convention over configuration) Dans Grails la convention est privilgie la configuration. En dautres mots au lieu davoir recours aux fichiers de configuration comme dans tout autre application JEE, Grails utilise un systme de convention qui remplace la configuration conventionnelle. Par exemple le nom dune class persistante sera celui de la table qui lui correspond dans la base de donne. De cette manire il est tout fait possible de crer toute une application sans passer par les fichiers XML, cependant si le besoin se fait sentir il est tout fait possible pour le

dveloppeur de recourir la configuration classique. Le Scaffolding

Le Scaffolding, ou chafaudage, est un atout majeur que propose Grails pour les dveloppeurs en utilisant cette capacit il est possible de gnrer les contrleurs et l es vue dune classe persistante seulement partir de leur dfinition. En invoquant cette capacit Grails se charge de crer une interface CRUD (create, read, update, delete) standard selon les normes du modle M -V-C. Il existe deux types de "scaffolding" savoir le "scaffolding" dynamique et le "scaffolding"statique. Dans le premier cas les contrleurs est leurs vues correspondante sont gnrs au "runtime" (excution). Par contre dans lchafaudage statique, le code source est disponible pendant le dveloppement il est alors possible dy apporter des modifications afin de personnaliser le rsultat. Bien videment dans ce cas de figure toute modification du modle persistant ncessiterait la rgnration du code. Les tests Dans Grails les tests possdent une place importante. En implmentant les interfaces ncessaire les classes tests permettent de tester le fonctionnement de lapplication diffrent niveau ainsi on distingue entre les tests unitaires et les tests dintgration ou de haut niveaux. Dans le cadre des tests unitaires Grails intgre le Framework "JUnit", ce type de tests est totalement indpendant de lenvironnement de lapplication, bases de donnes, conteneur de servlets, ou encore tout lment du protocole http. Nanmoins tous ces acteurs peuvent tre remplacs par des objets mock (bouchons) qui offrent une simulation des fonctions proposes par ces derniers. Par contre dans le cas des tests dintgration on a accs tous les lments de ce qui permet de tester les interactio ns entre les diffrentes couches et le comportement de lapplication dans sa totalit. Les plugins Une autre notion fondamentale de Grails est les plugins en effet le Framework Grails est extrmement extensible et permet lintgration dune multitude de c omposants logiciels de ce type. En quelque sorte les plugins sont des petites applications Grails pouvant possder leurs propre contrleur, vue ou modle et qui sintgrent lapplication dans le but de fournir une fonctionnalit bien prcise parmi les plugins les plus utilis on peut citer : Hibernate, SpringSecurite, ou encore Tomcat. Groovy

Contrairement tout autre langage ayant subi un reportage pour la JVM, Groovy a tait spcifiquement conu pour exploiter toute la puissance de cette dernire. Ain si il ya peu ou pas de diffrence, rduisant ainsi dune manire significative la priode dapprentissage. Par exemple Groovy utilise lAPI "Java" plutt que dimposer sa propre API. Il en rsulte que les dveloppeurs nont pas choisir entre utiliser les librairies Java et les librairies provenant dautres langages. Par ailleurs la compatibilit complte de Groovy avec la JVM fait quil subsiste un couche paisse de "byte code" qui facilite davantage lintgration de Java Groovy et vice versa. Groovy ne fait pas quexploiter lAPI "Java" il ltant en y ajoutant des fonctionnalits et des mthodes qui lenrichissent dautant plus. Il comporte tous les aspects de la programmation moderne qui rendent les langages plus productifs et plus souples tels que les "Closures" qui reprsente un bout de code mais pouvant tre manipul la fois comme une variable ou une mthode, il permet aussi lautomatisation des accesseurs pour les "Beans". De cette faon le langage Groovy diminue la quantit de br uit dans le code, rduisant dune faon significative la taille de ce dernier. Il est noter que Groovy en plus dtre orient objet rend possible lcriture de scripts on peut donc excuter du code sans que pour autant ce dernier soit contenu dans la mthode dune classe.

Bibliographie
[1] : THESE :Dveloppement itratif, volutif et agile Nicoletta SERGI 23/11/2007 [2] : THESE :Ingnierie des SystmesLogiciels, Dr. Marcellin Julius NKENLIFACK [3] : http://fr.wikipedia.org/wiki/Extreme_programming [4] : THESE :Modlisation des applications distribues a architecture dynamique , Conception et Validation 13 Novembre 2008 [5]UML en action :Deuxime dition 2003 ,de lanalyse des besoins la conception en Java [6]Rsum du sous-ensemblede la notation UML 2 [7] : Cours Atelier UML Tarak Chaari [8] : Conception et ralisationdune application de gestiondes comptes mail et internet 2010-2011 [9] : ModlisationSystmes dinformation,2005-2006 [10]: Gnie logicielUML : UnifiedModelingLanguage A. Madani [11]:Projet de fin dtudes 2005/2006 [12]: http://fr.wikipedia.org/wiki/Groovy [13]: Rapport de TER,Application client-serveur de vente aux enchres [14]: http://www.json.org/jsonfr.html [15]:Mmoire:Conception, dveloppement et intgration d'une application embarque de tlchargement des application android 2010-2011 [16] : http://fr.wikipedia.org/wiki/Service_Web [17] : http://fr.shortopedia.com/P/R/Protocole_r,C3,A9seau__page4 [18]: https:// 304.ibm.com/services/learning/content /ites.wss/ca [19] : http://www.figer.com/publications/REST.htm [20] : http://fr.wikipedia.org/wiki/Representational_State_Transfer

RESUME A travers ce travail on a pu effectuer une tude conceptuelle de notre application ainsi que la ralisation et le dveloppement d une application web et Android cration des codes a barre, aussi cration des cartes de fidlit. pour la lecture et la