Rapport PFE Wahid Gazzah

Rapport de Projet de Fin d’Etudes

Thème : Développement d’un 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

Année Universitaire : 2011/2012

Ecole Polytechnique Privée (Agrément N°02-2009) – Boulevard Khalifa Karoui – Sahloul 4054 Sousse Tél. : (00216) 73 277 877 / (00216) 50 995 885 – Fax : (00216) 73 243 685 www.polytecsousse.tn

Dédicaces

…A mes chères familles …A mes chers amis … A tous ceux qui comptent pour moi …A tous ceux pour qui je compte Je dédie ce travail

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

Liste des figures Figure 1

Logo Tunitag

Figure 1.1

Logo Ultimate Mobile Agency

Figure 2.1 :

Caractéristiques de l’approche itérative

Figure 2.2 :

Organisation du processus unifié

Figure 2.3 :

les phases d’un cycle du processus unifié

Figure 2.4 :

processus de développement 2TUP

Figure 3.1 :

L’étude préliminaire dans 2TUP

Figure 4.1 :

Capture des besoins fonctionnels dans 2 TUP

Figure 4.2 :

Uses Case Globale

Figure 4.3 :

Diagramme d’activités du cas «Authentification »

Figure 4.4 :

Diagramme de cas d’utilisation du package « Gestion des comptes clients »

Figure 4.5 :

Diagramme de cas d’utilisation du package «Gestion des QR Codes»

Figure 4.6 :

Diagramme de cas d’utilisation du package «Gestion des cartes de fidélité»

Figure 4.7 :

Diagramme de cas d’utilisation du package «Gestion actualité»

Figure 4.8 :

Diagramme de cas d’utilisation du package «Gestion des scan »

Figure 4.9 :

Diagramme de cas d’utilisation 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 Actualités » Figure 4.12 : Diagramme des classes participantes de « Gestion des QR Code » Figure 4.13 : Diagramme des classes participantes de « Gestion des cartes de fidélité» Figure 4.14 : Diagramme de classes participantes du package « Gestion des statistiques » Figure 5.1 :

Situation de la capture des besoins techniques dans 2TUP

Figure 5.2 :

Architecture simple tiers

Figure 5.3 :

Architecture client/serveur

Figure 5.4 :

Architecture 3 tiers

Figure 5.5 :

Configuration matérielle du système

Figure 5.6 :

Diagramme de composent de système

Figure 6.1 :

Découpage en catégorie

Figure 6.2 :

Diagramme de classe

Figure 6.3 :

Diagramme de séquence du scénario « S’authentifier »

Figure 6.4 :

Diagramme de séquence du scénario « Mot de passe oublié »

Figure 6.5 :

Diagramme de séquence du scénario « Inscription »

Figure 6.6 :

Diagramme de séquence du scénario «Modifier compte »

Figure 6.7 :

Diagramme de séquence « Gestion QR Code »

Figure 6.8 :

Diagramme de séquence « supprimer/partager QR Code »

Figure 6.9 :

Diagramme de séquence « ajouter publicité »

Figure 6.10 : Diagramme de séquence « ajouter statistique » Figure 6.11 : Diagramme de séquence « ajouter actualité » Figure 6.12 : Diagramme de séquence « traitement QR Code » Figure 6.13 : Diagramme de séquence « créer, supprimer Carte de fidélité » Figure 6.14 : Diagramme de collaboration de la catégorie « Authentification » Figure 6.15 : Diagramme de collaboration de la catégorie « « Mot de passe oublié » Figure 6.16 : Diagramme de collaboration du scénario « Inscription » Figure 1.17 : Diagramme de collaboration du scénario « Modifier compte » Figure 6.18 : Diagramme de collaboration du scénario création des QR Codes Figure 6.19 : Diagramme de collaboration du scénario « créer des carte de fidélité » Figure 6.20 : Diagramme de collaboration de l’administrateur Figure 7.1 :

Le modèle MVC

Figure 7.4 :

Format JSON

Figure 7.5 :

Structure d’une enveloppe SOAP

Figure 7.6:

Caractéristique d’un Web Service REST

Figure 7.7 :

Principe de communication via REST

Figure 7.8 :

Interface d’accueil

Figure 7.9 :

Interface d’authentification

Figure 7.10 : Interface d’inscription Figure 7.11 : Interface de mot de passe oublié Figure 7.12 : Menu principal Figure 7.13 : Opération du scan d’un QR Code Figure 7.14 : Résultat d’un scan Figure 7.15 : Création d’un QR code Figure 7.16 : Partage d’un QR code Figure 7.17 : Consultation des cartes de fidélité Figure 7.18 : Création des cartes de fidélité Figure 7.19 : Scan du code a barre d’une carte de fidélité

Figure 7.20 : Opération du scan code à barre d’une carte de fidélité Figure 7.21 : Consultation des actualités

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 d’utilisation Tableau 4.2 : Liste des cas d’utilisation et de leurs acteurs par package Tableau 7.1 : technologies utilisées Tableau 7.2 : structure d’une application sous Grails Tableau 7.3 : Les méthodes REST Tableau 7.4 : les taches réalisées dans l’application

Introduction générale 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 révolution favorisant le travail à distance et l'accès aux besoins en temps réduit à l’aide d’internet qui a bouleversée les habitudes de travail dans de nombreux métiers. D’après beaucoup d’analyses et statistiques effectuées, il s’avère que de plus en plus d’internautes se connectent désormais à internet via leurs téléphones portables. Nous remarquons ces dernières années

un développement exponentie l des appareils

mobiles qui sont répandus comme une traînée de poudre dans le monde en développement et révolutionnant le domaine des communications notamment dans les zones rurales.

Dans ce cadre, les Smartphones apparaissent pour rompre avec nos anciennes idées sur les téléphones portables et donner une autre dimension à cette technologie tout en intégrant de nouveaux apports à la téléphonie mobile et en attirant la clientèle grâce à l’ergonomie exponentielle et révolutionnaire. Grace à l’arrivé de ce miracle de la technologie, les usages des téléphones mobiles vont être modifiés d’une manière significative. Les appareils mobiles joueront le rôle de lien entre le monde virtuel du web et le monde physique qui nous entoure. Ils

fournissent aux

utilisateurs individuels et aux communautés un accès précieux à toute une série de services d’informationà des fins personnelles et commerciales. De la surveillance des élections à la possibilité de demander une aide d’urgence, la téléphonie mobile a créé d’incroyables possibilités de mobilisation et de connexion. C’est dans cette optique se situe mon projet de stage de fin d’études proposé par Ultimate Mobile Agency. Il vise à approfondir mes connaissances informatiques ainsi que découvrir le domaine professionnel. Problé matique et présentation du sujet L’amélioration de la qualité de services est un challenge que tout acteur dans le domaine professionnel cherche à atteindre. Afin d’y parve nir, il est primordial de proposer de 1

nouvelles technologies d’informations et de communications afin d’améliorer, d’une part, le fonctionnement et la visibilité des entreprises, et d’autre part, garantir la fidélité des clients. Notre objectif à travers ce travail est de proposer une solution qui répond aux besoins de l’utilisateurpar la réalisation d’une application commerciale nommé Tunitag en développant une application web et mobileafin de garantir la disponibilité de l’information chez le client et lui offrir la possibilité de:  Créer, gérer et consulter un compte utilisateur.  Scanner des codes barres de tous types.  Créer un QRCode facilement et de l'enregistrer sur compte client. Différents

types

de QR Code sont disponible (texte, Url, Contact, Sms, Localisation, phone)  Créer des cartes de fidélité comportant un code barre.  Consulter l’historique: retrouver des codes barres scannés depuis la fonction scan.  Consulter l'actualité concernant Tunitag.  Consulter les codes barre désigné préalablement comme favoris.  Consulter une bannière publicitaire

Figure1.2 - Logo Tunitag

Dans notre projet, nous avons mené une étude approfondie du système Android tout en étudiant le concept général d’Android, et nous avons étudié le framework open source Grails. Après avoir présenté le cadre de notre projet et la problématique ainsi que les objectifs à atteindre à travers ce projet, nous passons à la présentation de l’organisme d’accueil.

Pour mener à termes ce projet nous avons dû effectuer des choix techniques et méthodologiques, identifier les différents besoins du projet, réaliser une conception détaillée du projet et enfin implémenter la partie back-office ainsi que l'application Android. D'où le présent rapport qui se résumeen septchapitres catalogués comme suit :

2

 Le premier chapitre consiste en une Présentation générale qui présente la société d’accueil et les différents besoins lié à notre projet.  Le deuxième chapitre nommé Choix méthodologiquequi nous permet dedécider la méthodologie à suivre tout au long de la création de notre application.  Dans le troisième chapitre, nous allons énumérer les acteurs principaux ainsi que les besoins fonctionnels du projet.  Consternant le quatrième chapitre, Besoins fonctionnels, nous allons présenter les diagrammes cas d’utilisateur et classes lié aux besoins fonctionnels.  Dans le chapitreBesoins techniques,on présente les technologies et l’architecture utilisé pour le développement du projet.  Pour la partie conception, on va la diviser en trois chapitres,décrivant l’analyse et la conception de notre application, ce qui permet de mettre en œuvre les principales fonctionnalités du système. 

Analyse : intègre les diagrammes de séquences du projet.



Conception générique comporte la conception de l’architecture logicielle.



Conception : nous avons réservé cette partie pour concevoir l'application dans tout son ensemble.

 Enfin pour le chapitreRéalisation on présente les interfaces du projet Tunitag qui décrivent le développement Android et le développement avec Grails. Finalement, nous clôturons notre rapport par une conclusion qui offre une synthèse du travail réalisé et présente les perspectives.

3

Chapitre 1 : Cadre du projet et présentation générale Introduction Dans ce chapitre introductif nous allonsprésenter la société d’accueil, ainsi qu’on définir quelque mots clé nécessaires pour notre projet. 1. Présentation de la société Ultimate Mobile Agency (UMA) est une agence de marketing mobile créée en 2008, son domaine d’activité est la création des sites web. Elle a récemment intégré le développement 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, j’ai essayé de répartir les tâches et les réaliser sur les semaines de la durée du stage, dans la résumée et représenté comme suit :  4 semaines : développement d’une calculatrice sous Android, qui dispose des fonctions scientifiques les plus couramment utilisées, aussi elle permet de dessiner des fonctions sous forme des courbes.  6 semaines : développement de l’application Android Tunitag.  3 semaines : développement du BackOffice Tunitag sous la framework Grails.  2 semaines : développement des web services REST pour le site web Tunitag sous la framework Grails.

4

3. Rôle occupé dans la société, matériel utilisé et formation  Au cours de ce stage, j’ai travaillé comme développeur Android et web.  J’ai utilisé mon ordinateur portable (un HP Compaq) et mon Androphone Gaga (Huawei U8180) distribué par Orange Tunisie.  J’ai participé à un concours organisé par Orange pour assister à une formation Android que j’ai reçu dans la suite une attestation de formation après avoir passé un examen.

 J’ai participé aussi à une formation Android organisé par Yas mine Market.  J'ai suivi la formation Android« Vidéo 2 Brain », et j’ai utilisé le livre offert par UMA« Programmation Android, de la conception au déploiement avec le Sdk Google Android 2 ». 4. Définitions  Les codes barres

Un code barres, ou code à barres, est la représentation d'une donnée numérique ou alphanumérique sous forme d'un symbole constitué de barres et d'espaces dont l'épaisseur varie en fonction de la symbologie utilisée et des données ainsi codées. Le code barres peut faciliter l’accès à l’information. Il existe des milliers de codes-barres différents, mais on peut les divisé en deux catégories: Codes barres unidimensionnels (1D) et lorsque ces barres sont remplacées par de petits carrés ou points, on parle des codes barres bidimensionnels (2D).

5

Codes-barres unidime nsionnels (1D)

Codes-barres bidime nsionnels (2D)

[EAN, CUP, Code 11, Code 39…]

[QR-Code, Data Matrix, FlashCode…]

Nombre limité d’informations encodées

Nombre important d’informations encodées : 25 à 100 fois plus

Dimensions limitées

Dimensions illimitées

Bit de contrôle / checksum

CRC 16/32

Pas de correction d’erreur

Différents niveaux de redondance

Tableau 1.1 : Comparaison entre code à barre (1D) et (2D)  QRCode ? Les QR Codes (QR pour quick response), Créée en 1994 par la société fabrication de voitures pour suivre à la trace différents composants. Leur utilité a été ensuite vite mise à contribution dans plusieurs types d'industries pour la logistique. Plus récemment, avec la possibilité de lire ces QR codes sur la majorité des téléphones portables japonais, les codesbarres 2D se sont installés partout au pays du soleil levant. Sur lesemballages, les publicités dans les journaux ou sur les portes du métro, les stations des bus, partout!  A quoi ça sert ? Ces codes-barres servent à coder une adresse URL comme par exemple celle d’un blog, en les lisant, on peut accéder très rapidement, aussi a coder un produit, un SMS, Email à envoyer, Contacte (nom, prénom, adresse, numéro téléphonique d’une personne pour l’enregistrer rapidement dans la liste des contacts après avoir scanné le QR Code via la caméra du mobile), etc. Conclusion Afin de modéliser les besoin attendus de notre application et que les objectifs soient atteinte, on va suivre le démarche du processus unifié qu’on va le détailler dans le prochain chapitre

6

Chapitre 2 : Choix méthodologique Introduction Le succès du projet dépend dès lors de l’adéquation du projet au processus de développement qui est une étape décisivepour l’élaboration d’une application indépendante de toute plateforme d’exécution et de tout langage de programmation. En effet, le processus de développement est constitué d’une succession de phases (spécification, conception et réalisation). Nous présentons, dans cette partie les méthodes de conception et les plus citées dans la littérature, et on va choisir une qui sera suivi tout au long de ce projet.

1. Les méthodes de conception On adopte souvent l’une de ces deux méthodologies lors de la conception d’une application quelconque : MERISE comme étant une méthode systémique ou Unified Process (UP) pour une méthode orientée objet. 1.1 MERISE MERISE s’appuie sur la séparation des données (la structure des informations que l’application utilise) et des traitements (réaction aux événements externes) en quatre niveaux : conceptuel, organisationnel, logique et physique. Cette séparation va assurer la continuit é au modèle. En effet, pour l’ensemble de données comme pour l’ensemble des traitements MERISE procède d’une manière progressive de l’élément le plus stable à l’élément le plus instable. [1] Le niveau conceptueldéfinit ce qu’il faut faire, le niveau organisationnel définit la manière de le faire, le niveau logique définit le choix des moyens et des ressources et le niveau physique définit les moyens pour la réalisation de l’application.

7

1.2 Processus unifié 1.2.1

Définition

Le processus unifié est un processus de développement logiciels orientés objets, centré sur l'architecture, guidé par des cas d'utilisation et orienté vers la diminution des risques. C’est une méthode générique, itérative et incrémentale, contrairement à la méthode séquentielle Merise.[2]

1.2.2 

Caractéristiques

L'itération et l’incrémentation :

UP découpe le projet en séquences d'instructions. Ces séquences seront répétées un nombre bien déterminé de fois ou tant qu'une condition indiquée n'est pas satisfaite. Généralement pour un UP, une itération prend en considération un certain nombre de cas d'utilisation et traite en priorité les risques importants. Ces itérations donnent lieu à un incrément. En effet chaque itération reprend les séquences produites par l’itération précédente et les enrichit d’une manière incrémentale. D’une manière générale Les itérations désignent des étapes de l'enchaînement, tandis que les incréments correspondent à des étapes de développement.[3]

Figure 2.1 : Caractéristiques de l’approche itérative

8

 Planification : Description de l’architecture.  Cas d’utilisation : Énoncer les cas d’utilisation et les connexions avec l’utilisateur.  Analyse et conception : Détailler les cas d’utilisation, définir la structure statique du système : classes et interfaces, définir les cas d’utilisation réalisés sous forme de collaborations entre les sous systèmes les classes et les interfaces.  Implémentation : Intègre les composants (code source) et la correspondance entre les classes et les composants.  Déploiement : Décrit l’affectation des composants sur les nœuds physiques.  Test : expose les cas de test qui vérifient les cas d'utilisation. 

Centralisation sur l’architecture

L’architecture d’un logiciel est représentée par les différentes vues du système devant être créées. Elle met en évidence les besoins des utilisateurs représentés par les cas d’utilisation. IL faut alors réaliser les cas d’utilisation représentant les fonctions principales et adapter l’architecture pour qu’elle les prenne en considération. 

Piloté par les cas d'utilisation

Le processus unifié est centré sur l’utilisateur, 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 modèle de cas d'utilisation et qui représentent les fonctionnalités complètes du système.[4] 1.2.3

Organisation du processus unifié

Le processus unifié s’organise dans la répétition d’un nombre de cycles qui se termine par une nouvelle version du logiciel. Naissance

Mort

Cycles

Figure 2.1 : Organisation du processus unifié

9

Chaque cycle est composé de quatre phases : Création, élaboration, construction et transition qui se subdivisent à leur tour en 5 itérations: l’expression des besoins, l’analyse, la conception, l’implémentation et le test.

Figure 2.2 : les phases d’un cycle du processus unifié

1.2.4

Adaptation du processus unifié

Il existe plusieurs processus de développement qui implémente le UP dont le plus intéressant le 2UP (2 tracks unified process, prononcez "toutiyoupi"). Pour un modèle2TUP, tout développement peut être décomposé ettraités en parallèle selon unaxe fonctionnelet un axetechnique.Nous pouvonsainsi suivreles évolutionsliées auxchangements desbesoins fonctionnelset aux changements des besoinstechniques. [5] La schématisation du processus de développement correspond alors à un Y. Les deux perspectives se rejoignant lors de la phase de conception préliminaire.

10

Figure 2.3 : processus de développement 2TUP

La branche fonctionnelle contient : la capturedes besoins et de leursanalyses. Lesrésultats de l'analysesont indépendantes destechnologies utilisés. Labranche technique contient : la capturedesbesoinstechniqueset de laconception générique. L'architecture techniqueconstruit le squelette dusystème informatique indépendamment des besoins fonctionnels. Lesdeux branchessont ensuite fusionnéesen une seule branchequi prend en chargela conception préliminaire (cartographie des composants à développer), conception détaillée (comment réaliser chaque composant), codage (production des composants), tests etétapes de validation des fonctions développées. Conclusion Après avoir choisila méthodologie des processus unifiés précisément le processus 2TUP. Dans le chapitre suivant on va suivre la démarche de ce processus tout au long de la conception.

11

Chapitre 3 : Etude préliminaire

Introduction Dans cette partie, nous procéderons à l'analyse des besoins fonctionnels et non fonctionnels attendu de l’application à savoir le développement à travers la description des besoins du système qui doivent répondre à l’attente de l’utilisateur. En effet, l’identification des besoins fonctionnels représente une étape importante du processus de développement 2TUP, qui est présenté dans l’étude préliminaire.

Figure 3.1 : L’étude préliminaire dans 2TUP

12

1. Les besoins fonctionnels Les besoins fonctionnels listent les opérations réalisables de notre application. Ce sont des besoins spécifiant un comportement d'entrée / sortie du système. En fait, le système doit établir les charges préliminaires suivantes:

 Gestion des scans :

 Gestion de l’historique:

• Scanner un QR Code

• Consulter historique • Partager historique

 Gestion des QR Codes :

• Supprimer historique

• Créer QR Code • Partager QR Code

 Gestion des cartes de fidélité :

• Supprimer QR Code

• Créer carte de fidélité • Consulter carte de fidélité

 Gestion de la publicité :

• Supprimer carte de fidélité

• Consulter publicité  Gestion des actualités :  Gestion compte utilisateur :

• Consulter actualité

• Ajouter utilisateur • Consulter utilisateur

 Gestion des statistiques :

• Modifier utilisateur

• Consulter statistique

Table 3.1 : Les besoins fonctionnels

2. Les besoins opérationnels Les besoins opérationnels représentent les besoins non fonctionnels, qui caractérisent le système comme la performance ainsi que la sécurité et l’ergonomie du système. Ces besoins peuvent être énoncés suivant des plans de classifications. [6]  L'ergonomie des interfaces:  l'interface d'une application Androphone, est délicate elle doit être simple et claire : La manipulation de l'interface ne doit pas nécessiter des connaissances poussées.

13

 L’application web doit être compatible avec n'importe quel systèmed'exploitation, Facile à manipuler, compréhensible.  Les interfaces des applications Android et web doivent être bien organisées 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.  Sécurité: L'application doit garantir à l'utilisateur connecté l'intégrité et la confidentialité de ses données. Notre système doit également certifier la disponibilité qui s'avère primo rdiale pour bon fonctionnement.  L'applicationdoitgarantir: la Fiabilité et la rapidité des scans ainsi que la flexibilité, l'évolutivité et la réutilisabilité de ses ressources. Conclusion Aprèsavoirdégagé les besoins fonctionnels et opérationnels et tous les critères qu’on doit prendre en considération. 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 déférentes étapes de processus de 2TUP comme illustré dans la figure 4.1. On va s’intéresser à la branche gauche du cycle en Y qui est « la capture des besoins fonctionnels » en décrivant les différentes façons qui seront disponible pour permettre les acteurs d’utiliser la future application Android et web.

Figure 4.1 : Capture des besoins fonctionnels dans 2 TUP

1. Identification des cas d’utilisation Un cas d'utilisation (Use case) « représente un ensemble de séquences d'actions réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier ».[6] En effet, ils sont des représentations fonctionnelles du système, ils permettent de modéliser les attentes des utilisateurs afin de réaliser une bonne délimitation du système et également d'améliorer la compréhension de son fonctionnement.Les CU sont déclenchés suite à la stimulation d'un acteur externe.

15

Le tableau suivant représente quelques cas d’utilisation, les acteurs et les relations entre les deux : Tableau 4.1 : Liste des acteurs et des messages par cas d’utilisation

Cas d’utilisation

Authentification

(identification

utilisateurs)

Acteur principal

Message(s)émis / reçus

Acteur secondaire

par les Acteurs

User Admin

Ajouter compte

Emet : login et mot de passe Reçu : confirmation Emet : création Reçoit : confirmation

Modifier compte

User

Emet : modification Reçoit : validation

Récupérer mot de passe

Emet : Email Reçoit : mot de passe

Créer QR Code

Emet : création User

Supprimer QR Code

Reçoit : confirmation Emet : suppression Reçoit: validation

Consulter actualités

Emet : consultation User

Inscription Newsletter

Reçoit: liste Emet : Email Reçoit : confirmation

Consulter statistique

Emet : consultation Reçoit: liste

Ajouter publicité

Emet : création Reçoit : confirmation

Rédiger actualités

Emet : création Admin

Supprimer actualités

Reçoit : enregistrement Emet : suppression Reçoit : validation

Modifier actualités

Emet : modification Reçoit : confirmation

Consulter actualités

Emet : consultation Reçoit : affichage 16

Ajouter Compte

Emet : création Reçoit : confirmation

Supprimer Compte

Admin

Emet : suppression Reçoit: validation

Modifier Compte

Emet : modification Reçoit : validation

Consulter compte

Emet : consultation Reçoit : Liste

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

Figure 4.2 – Uses Case Globale

17

Ce diagramme représente les cas d’utilisation sans en montrer les détails, chaque cas d’utilisation sera détaillé plus bas. 2. Description des cas d’utilisation Afin de décrire les interactions entre les cas d’utilisation, nous présentons ces derniers de façon textuelle. Il s’agit donc d’associer à chaque cas d’utilisation un nom, un objectif, les acteurs qui y participent, les pré-conditions et des scénarii. Cependant ; il existe trois types de scénarii : les scénarii nominaux ; les scénarii d’exceptions et les scénarii alternatifs. Dans notre description textuelle, nous présentons seulement les scénarii nominaux et alternatifs. Nous nous restreindrons à la description des cas d’utilisation suivants : authentification et gestion des comptes (application Android et Web). Les autres cas sont décris dans l’annexe. 2.1 Cas d'utilisation " Authentification (identification utilisateurs) "

Titre

: Authentification (identification utilisateurs)

Parties prenantes et intérêts : Authentifier un utilisateur se connectant au système ; et lui présenter l’interface, les fonctionnalités relative à son profil. Acteurs : Utilisateur. Pré conditions : Introduire login et mot de passe Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur saisi son login et son mot de passe. Enchaînement (a) : L’utilisateur valide les données saisies. Enchaînements alternatifs : Enchaînement (b) : Vérifications de l’existence de l’utilisateur par le système. Enchaînement (c) : Message de confirmation d’entrer à la session ou échec d’entrer. Post conditions : Ouverture de l’espace personnel.

Tous ces enchainements cités au dessus sont décrits par le diagramme d’activité de la figure 4.3 : 18

Figure 4.3 : Diagramme d’activités du cas «Authentification »

2.2

Gestion des comptes

2.2.1 Cas d'utilisation " Créer un compte" Titre

: créer un compte.

Parties prenantes et intérêts : Faire enregistrer chaque nouveau compte. Acteurs : Utilisateur. Pré conditions : Ajouter un nouveau compte à un client. Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système l’ajout d’un nouveau compte. Enchaînement (a) : Créer un compte. Enchaînement (b) : Valider le compte. L’utilisateur valide l’ajout du compte et le système enregistre les nouvelles données saisies. Ce cas d’utilisation se termine lorsque l’utilisateur aura ajouté le compte Post conditions : Le système crée le nouveau compte. 2.2.2 Cas d'utilisation " Modifier un compte " Titre

: Modifier un compte.

Parties prenantes et intérêts : Faire enregistrer les modifications du compte, afin de mettre

19

à jour les données. Acteurs : Utilisateur Pré conditions : Il existe forcément un compte enregistré à modifier Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système de modifier son compte. Enchaînement (a) : Modifier un compte. Enchaînement (b) : Valider la modification L’utilisateur valide la modification du compte et le système enregistre les données modifiées. Enchaînements alternatifs : Ce cas d’utilisation se termine lorsque l’utilisateur aura modifié son compte. Post conditions : Le système enregistre la modification du compte. 2.2.3 Cas d'utilisation " Consulter un compte " Titre

: Consulter un compte.

Parties prenantes et intérêts : Consultation des informations sur un compte. Acteurs : Utilisateur. Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système de lui retourner les informations de son compte. Le système affiche le compte. Ce cas d’utilisation se termine lorsque l’utilisateur aura consulté leur compte. 2.3

Cas d'utilisation " Gestion QR Code " 2.3.1 Titre

Cas d'utilisation « Créer QR Code »

: Créer QR Code.

Parties prenantes et intérêts : Faire enregistrer des nouveaux QR Code Acteurs : User Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système d’enregistrer un nouveau QR Code. L’utilisateur valide la créationd’un QR Codeet le système enregistre les données. Enchaînements alternatifs : Ce cas d’utilisation se termine lorsque l’utilisateur aura créer son QR Code. Post conditions : Le système enregistre la création du QR Code

20

2.3.2 Cas d'utilisation « Consulter QR Code » Titre

: Consulter un QR Code.

Parties prenantes et intérêts : Faireafficher les différents QR Code du système. Acteurs : User Pré conditions : Il existe forcément un QR Code enregistré à afficher Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système d’afficher la liste des QR Code ou un QR Code bien déterminé. L’utilisateur choisit d’afficher un ou des QR Code. Enchaînements alternatifs : Ce cas d’utilisation se termine lorsque l’utilisateur aura affiché le QR Code désiré. 2.3.3 Cas d'utilisation « Partager QR Code » Titre : PartagerQR Code. Parties prenantes et intérêts : Faire partager des QR Code, afin de le publier aux clients. Acteurs : User Pré conditions : Il existe forcément un QR Code enregistré à partager. Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande partagerun DR code. Enchaînement (a) : Partager unQR Code. Enchaînement (b) : Choisir l’action de partage (Gmail, Twitter, Facebook) L’utilisateur valide l’action de partage et le système enregistre les données. Enchaînements alternatifs : Ce cas d’utilisation se termine lorsque l’utilisateur aura choisirl’action de partage. Post conditions : Le système enregistre l’action de partage. 2.3.4 Cas d'utilisation « Supprimer QR Code » Titre

: Supprimer QR Code.

Parties prenantes et intérêts : Faire supprimerun QR Code bien déterminé Acteurs : Utilisateur Pré conditions : Il existe forcément un compte enregistré à supprimer. Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système de Supprimer QR Code.

21

L’utilisateur valide la suppression du QRcode. Enchaînements alternatifs : Ce cas d’utilisation se termine lorsque l’utilisateur aura suppriméle QR Code désiré. Post conditions : Le système supprimele QR Code. 2.4

Cas d'utilisation " Gestion Carte de fidélité " 2.4.1 Titre

Cas d'utilisation " Gestion Carte de fidélité "

: Créer Carte de fidélité.

Parties prenantes et intérêts : Faire enregistrer des cartes de fidélité. Acteurs : Utilisateur Pré conditions : Il existe forcément un Point de vente pour lui faire une carte de fidélité. Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système de créer une carte de fidélité. L’utilisateur créé une carte et le système la valide. Enchaînements alternatifs : Ce cas d’utilisation se termine lorsque l’utilisateur aura enregistré sa carte. Post conditions : Le système enregistre la carte d’équipe. 2.4.2 Cas d'utilisation « Supprimer Carte de fidélité » Titre : Supprimer Carte de fidélité. Parties prenantes et intérêts : Faire supprimer une carte de fidélité parmi la galerie des cartes. Acteurs : Utilisateur Pré conditions : Il existe forcément une carte enregistré à supprimé Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande au système de supprimer une carte. L’utilisateur valide la suppression. Enchaînements alternatifs : Ce cas d’utilisation se termine lorsque l’utilisateur aura supprimé la carte désirée. 3. Organisation des cas d’utilisation Dans cette partie, nous procédons à l’organisation des cas d’utilisation en les rassemblant dans des packages. 22

3.1 Packages de cas d’utilisation Dans cette étape ; nous regroupons les différents cas d’utilisation cités auparavant dans des packages. Ce regroupement se fait suivant des critères. Le critère de regroupement que nous adoptons dans ce processus est le domaine d'expertise métier. Par la suite ; nous reprenons le tableau présentant 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 d’utilisation et de leurs acteurs par package Cas d’utilisation Acteur Package

Authentification (identification utilisateurs)

Administrateur

Gestion de profil

User

Récupérer mot de passe Modifier compte

User

Gestion des comptes

User

Gestion QR Code

Ajouter compte Supprimer QR Code Créer QR Code Ajouter Compte Gestion

Supprimer Compte Modifier Compte

Admin

des

Comptes

clients

Consulter compte Créer carte Supprimer carte

Gestion des cartes de User

fidélité

Rédiger actualités Supprimer actualités Modifier actualités

Admin

Gestion des actualités

Consulter actualités Rédiger actualités

23

3.2 Généralisation des acteurs Si un ensemble d'acteurs communiquent de la même façon avec certains cas d'utilisation, on peut créer un acteur généralisé (souvent abstrait), qui permettra de factoriser ce rôle commun. Les acteurs spécialisés héritent alors des associations de l'acteur a ncêtre [6]. En se basant sur cette définition ; nous avons pu dégager les groupes d’utilisateurs qui sont en interaction avec notre système.  Admin  User 3.3 Diagramme de cas d’utilisation Le diagramme de cas d’utilisation est un moyen qui permet de décrire les besoins des acteurs du système. C’est un diagramme qui sert à modéliser un des aspects statiques du système en passant du général au spécifique pour mettre en relief les besoins déjà énoncés d’une manière détaillée.[7] Pour chaque package ; nous associons un diagramme de cas d’utilisation. Voici les six diagrammes correspondants à notre précédent découpage: 3.4 Package «Gestion des comptes clients» L’administrateur a plusieurs rôles liés tout d’abord à la gestion des clients. Cette gestion inclut les tâches de manipulation des données qui sont présentées dans la figure 4.4 :

Figure 4.4 : Diagramme de cas d’utilisation du package « Gestion des comptes clients »

24

3.5 Package «Gestion des QR Codes» L’agent commercialest responsable ausside la gestion des contrats. Le diagramme de la figure 4.5 représente les fonctionnalités accessibles par cet agent.

Figure 4.5 : Diagramme de cas d’utilisation du package «Gestion des QR Codes»

3.6 Package «Gestion des cartes de fidélité»

Figure 4.6: Diagramme de cas d’utilisation du package «Gestion des cartes de fidélité»

Ce cas d’utilisation (figure 4.6) détaille le package gestion des cartes de fidélité, qui sera présentée par l’exécution de deux processus : La création et la suppression des cartes. 3.7 Package «Gestion actualité» Dans ce cas d’utilisation (figure 4.7), nous voyons plus en détail comment s’établie la gestion des actualités manipulée par l’administrateur. 25

Figure 4.7 : Diagramme de cas d’utilisation 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 d’utilisation du package «Gestion des scan »

3.9 Package «Gestion des comptes» Ce package consiste à ajouter, modifier un compte client et la récupération de mot de passe en cas de perte.

26

Figure 4.9 : Diagramme de cas d’utilisation 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 système sous forme d'objets et de classes, et en essayant ainsi d'obtenir rapidement un consensus sur les définitions des concepts clés.[8] En exploitant la description des cas d'utilisation donnés 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 Actualités » D’aprèsles descriptions du cas d’utilisation gestion actualité ; nous pouvons élaborer le diagramme des classes participantes suivant : 27

Figure 4.11 : Digramme des classes participantes de « Gestion des Actualités »

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 précis.

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

4.4 Diagramme de classes participantes du package « Gestion des cartes de fidélité» Nous spécifions dans ce package les classes suivantes : compte, carte fidélité, prestataire. (Figure 4.13). En effet, une carte de fidélité nécessite la création d’un compteet unprestataire de service.

28

Figure 4.13 : Diagramme des classes participantes de « Gestion des cartes de fidélité»

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é après avoir modélisé les besoin des utilisateurs, on passe directement à préparer et analyserl’environnement et les besoins techniques pour notre application

29

Chapitre 5 : Capture des besoins techniques Introduction

On va s’intéresser à 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 l’environnement de travail ainsi que l’architecture globale utilisée pour notre système.

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

1. Architectures Client/serveur L’expression des besoins techniques implique également le choix d’architecture. Ce choix est crucial puisqu’il intervient dans l’évolutivité du système, le temps de développement, le coût et les performances. 1.1 Architecture simple tie rs La conception de l’application est élaborée de manière à fonctionner sur un ordinateur unique. En fait, tous les services fournis par l'application résident sur la même machine et 30

sont inclus dans l'application. Toutes les fonctionnalités sont donc comprises dans une seule couche logicielle.

Figure 5.2 : Architecture simple tiers

1.2 Architecture client/serveur C’estune architecture 2-tiers appelée 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 d’une part et le «serveur de données» qui fournit le service d'autre part.[9] Nous aurons donc la base de données qui sera délocalisée sur un serveur dédié appelé leserveur de données qui fournira les donnéesà exploiter.

Figure 5.3 : Architecture client/serveur

31

1.3 Architecture trois tiers Cette architecture physique est assez semblable à l’architecture client/serveur, mais en plus des « clients» et duserveur de données évoquées plus haut, un serveur d'application intervient comme un troisième tiers. En effet, les machines clientes, égalementappelées«clients légers» ne contiennent que l'interface de l'application de manière qu’elles déchargées 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 données localisées au niveaudu serveur de données.

Figure 5.4 : Architecture 3 tiers

3.

Configuration matérielle du système Les choix des pré-requis techniques déjà mentionnés dans l’étude préliminaire, lors de l’expression des besoins opérationnels, impliquent des contraintes relatives à la configuration du réseau matériel, les performances d’accès aux données ainsi que la sécurité du système, l’intégration des applications, la volumétrie et le mode d’utilisation du système. Afin de concevoir notre application, nous avons opté à l’architecture 4-tiers. Elle représente la solution la plus adaptée à notre système car elle nous offre :    

Des meilleures performances grâce à la répartition des charges de travail. Une disponibilité de l’information en temps réel. Une répartition des tâches entre les acteurs du système Une technologie a la mode et plus présentable. 32

La configuration matérielle de notre système est schématisée comme suit :

Figure 5.5 : Configuration matérielle du système

Comme le montre la figure5.5, notre système est équipé de :  Un serveur de gestion de base de données comporte une importante capacité de stockage, doit être disponible afin qu’on puisse y accéder à tout moment, et doit avoir une puissante capacité de traitement dans le cas où plusieurs clients y accèdent en même temps.  Client (Web ou Android) sont des ordinateurs de bureau ou toutes sortes de machine ayant unnavigateur web qui permet d’accéder à internet (ce sont de type client léger), ou des clients Mobile.  Serveur we b est un serveur qui répond aux commandes des clients.  Serveur d’application est l’environnement d’exécution des applications. 4. Spécification d’architecture Sur le plan logique ; notre architecture (4tiers) est mise en œuvre suivant le modèle MVC (Modèle Vue Contrôleur) qui s'applique donc au niveau du client. En effet, la spécification d’une architecture à composants métier 4-tiers implique la répartition des composants d’exploitation suivant les responsabilités. Le diagramme de composants ci-dessous, montre les différents types de composants d’exploitation du système.

33

Figure 5.6 : Diagramme de composant de système

Conclusion Au cours de ce chapitre, le choix de l’architecture physique a été choisi selon l’environnement adopté. On va modéliser les différents diagrammes d’UML qui vont être représenté dans le chapitre suivant.

34

Chapitre 6:Analyse Introduction En se référant à la démarche de 2TUP on passe à la phase d’analyse qui représente la deuxième étape de la branche gauche du cycle en Y. Au cours de cette étape, on va représenterune vue statique du système par la modélisation de diagramme de classe puis , et une vue dynamique par la modélisation des diagramme de séquence. 1. Découpage en catégorie Le découpage en catégories se situe sur la branche gauche du cycle en Y. En fait, il succède l’étape de capture des besoins fonctionnels constituant ainsi la première activité de l’étape d’analyse.[9] Ce découpage permet de déterminer les classes fondamentales du projet en utilisant les diagrammes des classes participantes dégagées dans l’étape de captures des besoins fonctionnels.

Figure 6.1 Découpage en catégorie

2. Développement du modèle statique Le développement en modèle statique représente la deuxième activité de l’étape d’analyse. Lors de cette étape, nous reprenons les diagrammes de classes participantes déjà identifiés auparavant et organisés lors du découpage en catégories afin de les affiner en leur ajoutant des attributs.[10]

35

2.1

Diagramme de classe

Figure 6.2 : Diagramme de classe

3. Développement du modèle dynamique Le développement du modèle dynamique est la troisième activité de l’étape d’analyse. Cette activité est en relation avec l’activité de modélisation statique. Lors de cette étape, nous décrivons les différentes interactions entre les objets de notre application. En effet, nous avons utilisé s le modèle dynamiques : le diagramme de séquence.

36

 Diagrammes de séquences Le diagramme de séquence est un diagramme d’interaction entre les objets, qui met l’accent sur le classement des messages par ordre chronologique durant l’exécution du système. Un diagramme de séquence est un tableau dans lequel les objets sont rangés sur l’axe des abscisses et des messages par ordre d’apparition sur l’axe des ordonnées. [10] Il est utilisé pour représenter certains aspects dynamiques d’un système : dans le contexte d’une opération, d’un système, d’un sous-système, d’un cas d’utilisation (un scénario d’un cas d’utilisation) selon un point de vue temporel. En effet dans cette phase, et après identification des cas d’utilisation, nous représentons à l’aide des diagrammes de séquences, quelques scenarios coté mobile (pareil coté web) associés aux catégories gestion des QRCode et gestion des comptes ainsi que l’authentification des utilisateurs. 3.1

Diagrammes de séquences de« Authentification »

Après le démarragede l’application, l’utilisateur saisi son login et son mot de passe. Une fois qu’il valide la saisie des données, le système s’assure d’abord que les informations entrées n’ont pas la valeur NULL puis il vérifie ces données au près de la base de données. Cette étape s’achève soit par l’ouverture de l’espace personnel associé à l’utilisateur, soit par l’affichage de message d’erreur (voir Figure 6.3).

37

Figure 6.3 Diagramme de séquence du scénario « S’authentifier »

En cas de perte ou l’oubli de mot de passe l’utilisateur peut le retrouver en saisissant son Email.

38

Le diagramme de séquence si dessous représente ce scénario :

Figure 6.4 Diagramme de séquence du scénario « Mot de passe oublié » Dans la suite, nous représentons les différents scénarios du package « gestion des inscriptions». 3.2

Diagramme de séquence du scénario « inscription d’un utilisateur »

Ce cas d’utilisation commence lorsque l’utilisateur demande au système de faire une inscription. Une fois le formulaire est affiché, il remplit les champs de saisies puis enregistre ses données. Le système s’assure d’abord que les champs obligatoires n’ont pas la valeur NULL ensuite il enregistre les informations entrées dans la base de données. Ce cas d’utilisation se termine lorsqu’unEmail de confirmation d’ajout s’affiche à la boite de réception d’Emails (voir figure 6.5).

39

Figure 6.5 : Diagramme de séquence du scénario « Inscription »

3.3

Diagramme de séquence du scénario « Modifier compte »

Après avoir décidé de mettre à jour son compte, l’utilisateur effectue une demande de modification. Une fois le formulaire de mise à jour apparait, ilsaisit ses nouvelles données puis il valide la modification pour que le système enregistre les données mod ifiées. Ce cas se termine lorsqu’un message de confirmation s’affiche.

40

Figure 6.6 : Diagramme de séquence du scénario «Modifier compte »

3.4

Diagramme de séquence du scénario « création d’un QR Code »

Lorsquel’utilisateurveut enregistrer un QR Code, il remplit le formulaire de création avec des données correctes si non un message d’erreur s’affiche indiquant une erreur d’enregistrement.

Figure 6.7 : Diagramme de séquence « créer QR Code » 41

3.5

Diagramme de séquence du scénario « suppression et partage d’un QR Code »

Il peut ainsi après création le partager et de faire une demande de suppression. Ce scénario s’achève lorsque l’utilisateur valide ou annule la suppression

Figure 6.8 : Diagramme de séquence « supprimer/partager QR Code »

42

3.6

Diagrammes de séquence du scénario concernant Administrateur« ajout publicité, ajout statistique et ajout actualité »

Figure 6.9 : Diagramme de séquence « ajouter publicité »

Figure 6.10 : Diagramme de séquence « ajouter statistique » 43

Figure 6.11 : Diagramme de séquence « ajouter actualité » Le scénario ci-dessous illustre les détails de traitement des QR Codes ; Scanner, supprimer ou partager un QR Code.

Figure 6.12 : Diagramme de séquence « traitement QR Code » 44

3.7

Diagramme de séquence du scénario « création et suppression d’uneCarte De fidélité »

Figure 6.13 : Diagramme de séquence « créer, supprimer Carte de fidélité »

1. Elaboration des diagrammes de collaborations Le diagramme de collaboration sert également à illustrer des interactions entre les objets à travers la représentation d’envoi de message dans le cadre d’un fonctionnement particulier du système. En effet, il est utilisé pour modéliser le contexte du système. Enfin, les diagrammes decollaboration permettent de concevoir les méthodes.[11]

45

1.1

Diagrammes de collaborations« Authentification »

Figure 6.14 : Diagramme de collaboration de la catégorie « Authentification » Ce diagramme nous illustre le scénario d’authentification décrit par le diagramme de séquence à travers l’échange des messages entre l’utilisateur et le système. 1.2

Diagramme de collaborations de scénario « Mot de passe oublié »

Figure 6.15 : Diagramme de collaboration de la catégorie « « Mot de passe oublié »

46

Dans les diagrammes qui suivent, nous allons schématiser lecas d’inscription des clients 1.3

Diagramme de collaboration du scénario « Inscription »

Figure 6.16 : Diagramme de collaboration du scénario « Inscription » 1.4

Diagramme de collaboration du scénario « Modifier compte »

Figure 1.17 : Diagramme de collaboration du scénario « Modifier compte »

47

1.5

Diagramme de collaboration du scénario « créer des QR Code »

Figure 6.18 : Diagramme de collaboration du scénario création des QR Codes

1.6

Diagramme de collaboration du scénario « créer des carte de fidélité »

Figure 6.19 : Diagramme de collaboration du scénario « créer des carte de fidélité »

48

1.7

Diagramme de collaboration de l’administrateur

Enfin nous allons représenter le diagramme de collaboration concernant les taches de l’administrateur

Figure 6.20 : Diagramme de collaboration de l’administrateur Conclusion Au cours de ce chapitre, nous avons présenté étape d’analyse quinous a permis de passer d’une structuration fonctionnelle via les cas d’utilisations et lespackages à une structuration objet via les classes et les catégories.

49

Chapitre 7 : Réalisation Introduction Dans ce chapitre, nous présentons la partie réalisation et mise en œuvre de notre travail. Pour cela, nous présentons, en premier lieu, l’environnement de travail et les outils de développement utilisés. En second lieu, nous élaborons une présentation des différentes interfaces créées.

1. Technologies Dans le tableau 7.1, on va représenter les différentes technologies utilisées dans notre application et qu’on va les détailler par la suite: Tableau 7.1 : technologies utilisées Androi d Système d'explo itation open source pour Smartphones, PDA et terminau x mobiles Vo ir annexe 1 pour plus de détails Grails

Framework de développement rapide pour les applications web, il est basé sur le langage Groovy d’où le nom Grails pour Groovy on Rails. Grails n’est pas seulement un Framework libre pour Java mais constitue une plateforme de développement à part entière. Il s’organise autour du modèle M-V-C Pour plus de détails voir annexe 2. Groovy Langage de programmation orienté objet destiné à la p late-forme Java. MySQL Système de gestion de base de données (SGBD).

50

JSON (JavaScript Ob ject Notation) Format de données textuel, générique.

Service Web RES T c’est le style architectural original du Web.

 Groovy est un langage relativement nouveau il peut aussi bien être compilé que interprété et il est spécifiquement désigné 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 nécessaire entre Java et Groovy montré dans le tableau 7.1. Tableau 7.2: Comparaison entre Java et Groovy

Java 2

Groovy

S tring name = "World"

def name = "World"

S ystem.out.println("Hello " + name);

println "Hello $name"

Objectname = "Groovy";

def name = "Groovy"

S ystem.out.println(((S tring)

printlnname.toUpperCase()

name).toUpperCase()); S tring[]s={"Php", "Grails "," Java "};

list = ["Php ", "Grails ", " Java "]

for(inti = 0; i