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
shorts =list.findAll{it.size() <= 4}
if(S [i].length()<= 4)
shorts.each { printlnit }
S ystem.out.println(S );
Structure d’une application avec Grails La structure d’un projet créé à l’aide du Grails est illustrée dans le tableau 7.2: Tableau 7.3: structure d’une application sous Grails
Répertoire
Description
domain/
Contient les classe domaine du projet
controllers/
Contient les contrôleurs 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 installés
test/
Les tests unitaires et fonctionnels
web/
Le répertoire racine web (fichier css, js,.. )
2. MVC (Model-Vie w-Controller) C’est une architecture et une méthode de conception qui organise l'interface hommemachine (IHM) d'une application logicielle. Ce paradigme divise l'IHM en trois parties : Modèle : décrit les données manipulées par l'application et définit les méthodes d'accès. Vue : est la représentation des données dans des interfaces avec lesquelles l'utilisateur interagit. Contrôleur : prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle. Le mode de fonctionnement du MVC commence par l’envoi d’une requête à l’application par le client, celle-ci est analysée par le contrôleur, qui demande au modèle approprié d'effectuer les traitements, puis renvoie la vue adaptée au navigateur.[13]
52
Figure 7.1 : Le modèle MVC
3. Présentation du Json JSON (JavaScript Object Notation – Notation Objet issue de JavaScript) est un format léger d'échange de données. Il est facile à lire ou à écrire pour des humains. Il est aisément analysable par des machines. JSON est un format texte complètement indépendant de tout langage. Ces propriétés font de JSON un langage d'échange de données idéal.[14] 3.1 Caractéristiques Un document JSON ne comprend que deux éléments structurels : des ensembles de paires nom / valeur des listes ordonnées de valeurs. Ces mêmes éléments représentent 3 types de données : des objets des tableaux des valeurs génériques de type tableau, objet, booléen, nombre, chaîne ou null
53
3.2 Avantage Le principal avantage de l’utilisation de JSON, dans notre application, est qu’il est simple à mettre en œuvre. Au rang des avantages, nous pouvons également citer [15]: Facile à apprendre, car sa syntaxe est réduite et non-extensible; Ses types de données sont connus et simples à décrire ; Peu verbeux et léger, ce qui le rend bien adapté aux terminaux mobiles au contraire au langage XML qui est très verbeux. COMMENT JSON VA ÊTRE UTILISÉ DANS NOTRE APPLICATION ? Lorsque notre application Android s'exécute, elle se connectera au serveur web qui va récupérer les données depuis la base de données MySQL en utilisant les services web de type Rest. Ensuite les données seront encodées au format JSON et envoyées au systè me Android. L’application va obtenir ces données codées. Elleles analysera et les affichera sur le mobile. La Figure 7.4 illustre bien la façon d’échanger les données entre le client Android et la partie des serveurs (web/MySql) :
Figure 7.2 : Format JSON
4. Présentation des services web 4.1 Définition Un service web est un programme informatique permettant la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués. Il s'agit donc d'un ensemble de fonctionnalités exposées sur internet ou sur un intranet, par et pour des applications ou machines, sans intervention humaine, et de manière 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 bâti sur XML ce qui le rend indépendant de tout système d'exploitation et de tout langage de programmation, il permet de faire des appels de procédures entre objets distantsphysiquement situés sur un autre serveur.[17] SOAP est défini pour être indépendant du protocole de transport utilisé pour véhiculer le message. Cependant, le protocole le plus utilisé avec SOAP est HTTP car c'est un des protocoles le plus répandu et utilisé du fait de sa simplicité. Son utilisation a vec SOAP permet de rendre les services web plus interopérables. 4.2.2
Structure
Le protocole SOAP est composé de deux parties : une enveloppe, contenant des informations sur le message lui- même afin de permettre son acheminement et son traitement, un modèle de données, définissant le format du message, c'est-à-dire les informations à transmettre.
Figure 7.3. Structure d’une enveloppe SOAP L'entête contient des informations sur le traitement du message. Le corps du message SOAP contient les données échangées entre le client et le service.
55
4.3 Services web de type REST 4.3.1
Description
REST (REpresentational State Transfer) est une manière de concevoir des applicatio ns ou des services Web.[18] Il n’est pas un protocole ou un format, c’est un style d’architecture. [18] 4.3.2
Caractéristique
Bien que REST ne soit pas un standard, il utilise des standards. En particulier l’URI: connaître l’URI doit suffire pour nommer et identifier une ressource HTTP fournit toutes les opérations nécessaires (GET, POST, PUT et DELETE).
Figure 7.4. : Caractéristique d’un 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 opérations 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 résultat de l'interaction.[19] PUT et DELETE pour créer ou supprimer une ressource
Méthode
Action GET
Afficher
PUT
Mise à jour
POST
Enreg istrer
Tableau7.4. Les méthodes REST 56
1.1.1
Avantage
L’application est plus simple à entretenir, car les liens sont mieux structurés, et de façon universelle ; les liens sont le moteur de l’état de l’application. L’absence de gestion d’état du client sur le serveur conduit à une consommation de mémoire inférieure, une plus grande simplicité et donc à une capacité plus grande de répondre à un grand nombre de requêtes simultanées. 1.1.2
Comparaison entre SOAP et REST
L’utilisation du protocole HTTP en tirant partie de son enveloppe et ses entêtes, à l’opposé de SOAP qui ne présuppose pas un protocole : SOAP réinvente un protocole via une enveloppe, des entêtes et un document, à l’intérieur du protocole réseau l’hébergeant (la plupart du temps HTTP). Il ne bénéficie donc pas des caractéristiques HTTP, gérée par l’infrastructure réseau.[19] POUQUOI REST VA ÊTRE UTILISÉ DANS NOTRE APPLICATION MOBILE ?
Pour faire communiquer une application quelconque avec le monde extérieur, le choix en matière de protocole est très vaste. Néanmoins sur Android, compte tenu des contraintes liées à la machine virtuelle Dalvik, ce choix est beaucoup plus limité. Android étant pensé comme un système web, le protocole de transport roi est le HTTP. Lorsqu’il s’agit d’interroger un serveur distant, un protocole de type REST basé sur JSON parait bien adapté. L’usage de SOAP est bien possible mais la lourdeur de ce protocole ne semble pas le prédisposer aux terminaux mobiles.[20] Finalement on va donner une représentation de notre architecture qui illustre bien l’utilisation des services web de type REST :
57
Figure 7.5 : Principe de communication via REST
Tache réalisées et résultat obtenu Tache annulée Tache réalisée personnellement Tache réalisée par une autre personne
Taches
Réalisation
Parties Conception l’application
de Réalisation de l’étude de la base de données Créer les tables de la BD
Etablir les liaisons entre les tables Back Office Créer pub Créer espace Admin
58
Créer Compte
Créer Compte WebService REST (JSON + XML) Update Compte Update Compte WebSe rvice REST (JSON + XML) Front office
S’authentifier S’authentifier WebService REST (JSON + XML) Récupérer le mot de passe oublié dans un mail Récupérer 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
Créer des QR Code de différents types (sms, email, contact, phone, url, texte) Partager QR
Code
créé
(FaceBook,
Twitte r, Skype, sms, email…) Créer un compte utilisateur via
un
WebService REST
59
Authentification via un WebService REST Cons ulte r Compte via un WebService REST Mise
a
jour d’un
compte
via
un
WebService REST Cons ulte r un flux RSS d’actualité Récupérer un email dans le cas du mot de passe oublier via un WebService REST Réalisation de l’étude de la base de données interne Créer les tables de la BD SQLite interne Application Android
Etablir les liaisons entre les tables Cons ulte r l’historique des QR Code Scanner des cartes de fidélité Générer une carte de fidélité Cons ulte r la liste des cartes de fidélité Cons ulté les surface de vente via la Réalité augmenté (100 % réalisé) Cons ulté les surface de vente via une MapVie w (100 % réalisé) Cons ulté les surface de vente via une List Vie w (100 % réalisé)
Tableau 7.5:les taches réalisées dans l’application
60
5. Application Nous présentons dans cette section quelques interfaces principales de notre réalisation qui illustrent les différents cas d’utilisation déjà vus dans le chapitre étude préliminaire. Au démarrage de notre application une interface d’accueil démarre comme le montre la figure 7.8
Figure 7.6 : interface d’accueil
Une fois authentifié, l’utilisateur accédera à l’ensemble des fonctionnalités de l’application via le menu vertical ou horizontal.
61
Figure 7.6 : Interface d’authentification
Si l’utilisateur ne possède pas un compte il doit s’inscrire pour bénéficier des fonctionnalités de l’application.( Figure 7.9 ) En cas de perte de mot de passe, l’utilisateur peut la récupérer via son mail comme le montre l’image qui suit. (Figure 7.10 )
Figure 7.7 : Interface d’inscription
Figure 7.8 : Interface de password oublié
62
Puis on va représenter notre interface du menu principale par deux modelés différents : comme le montre la figure 7.11
Figure 7.9 : Menu principal Pour la suite, nous représentons la fonctionnalité du scan d’un QR Code.
Figure 7.10 : Opération du scan d’un QR Code
Apres le scan le résultat sera enregistré dans l’historique des scans qu’on peut le consulter comme suit tout dépend de nature du QR Code comme le montre la figure Figure 7.13
63
Figure 7.11 : Résultat d’un scan
Pour créer un QR Code l’utilisateur va choisir le type du QR Code dans l’interface liste view (contact, email, ma position, numéro téléphonique, sms, url, texte), soit le type ‘ma position comme exemple :
Figure 7.12 : Création d’un QR code
Une fois créer, l’utilisateur va sélectionner un choix de la source soit GPS soit la connexion téléphonique Le QR Code est générée à ce moment- là l’utilisateur peut le partager (Figure 7.14) 64
Figure 7.13 : Partage d’un QR code
Tunitag offre la possibilité de consulter les cartes de fidélités déjà créé, afin de la présenter à la caisse l’utilisateur doit choisir la carte correspondante voir figure 7.15
Figure 7.14 : Consultation des cartes de fidélité
Pour créer une nouvelle carte dans la galerie, après avoir sélectionner le bouton ‘+’, l’utilisateur va sélectionner un type selon le logo de la surface de vente comme le monte l’image 7.16 65
Figure 7.15 : Création des cartes de fidélité
Une fois sélectionné un nom, la fenêtre 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 d’une carte de fidélité
66
Figure 7.17 : Opération du scan code à barre d’une carte de fidélité
Les images de la figure 7.17 illustres bienl’opération Tunitag permet aussi de consulter l’actualité du site Tunitag. Voir figure 7.18
Figure 7.18 : Consultation des actualités
Conclusion Dans ce chapitre, nous avons présenté les choix techniques que nous avons adoptés, ainsi que l’environnement d’implémentation 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 développement et l’intégration d’une application nommé Tunitag au sein de la société Ultimate Agency afin d’apporter une valeur ajoutée et un meilleur service aux clients. Nous sommes arrivés à développer toutes les fonctionnalités du système dans les temps. L’intégration a été réalisée avec succès, c'est-à-dire que l’application est maintenant installée sur le mobile et prête à être commercialisé. Ce stage nous a permis d’approfondir nos connaissances théoriques, acquises tous le long de notre formation, par la pratique des nouvelles technologies. Cette expérience nous a permis de maîtriser le langage de modélisation UML, les outils de développement Android à savoir le SDK Android ainsi que le framework Grails, sous lequel, le développement n’a pas été une tâche facile, mais nous n’avons pas hésité à y participer, malgré qu’il y a peu du support. Il nous a également permis de découvrir comment se passe l’intégration d’une application sur un serveur web distant ainsi que
l’utilisation du
format
JSON pour gérer la
communication des données entre deux environnements hétérogènes qui sont le client Android et le serveur de bases de données Mysql. Le stage quotidien au sein de la société a aussi été pour nous une occasion unique pour épanouir nos capacités de communication dans un environnement professionnel. C’est une expérience très enrichissante sur tous les domaines. Bien que les principaux objectifs de notre projet soient atteints, l’application que nous avons développé pourrait être enrichie par d’autres fonctionnalités avancées et améliorations peuvent être envisagées pour l’enrichir, tel que la Géo localisation des surfaces de vente (Réalité augmentée, Mapview, List view), un comparateur de prix, un service d'horaire de bus par QR Code… Concernant l’application mobile, elle peut être implémentée sur des plateformes autres que Android. Nous souhaitons, enfin, que ce modeste travail apporte satisfaction aux membres du jury et à toute personne intéressée, de près ou de loin.
68
Annexe 1 Test des web services Il est préférable de tester
les services web avant de les implémenté dans l’application
Android. Pour ce faire, on a procédé à un plugin RESTClient du navigateur Firefox, qui représente un client virtuel. RESTClient est un débuggeur pour les services-web de type REST. C'est un bon outil, très pratique pour tester et déboguer un logiciel - en particulier les services Web. RESTClient supporte toutes les méthodes du protocole HTTP ("GET", "POST", "DELETE", ... ). Il permet de construire sur mesure les requêtes HTTP et de tester directement les demandes sur un serveur. Il suffit de remplir les champs "URL" de la requête, choisir le type de requête et remplir le corps de la requête si besoin (JSON ou XML) pour enfin l'exécuter en envoyant la requête. Puis RESTClient affiche la réponse formatée en XML ou JSON envoyée par le serveur, son affichage est bien claire et facilite la lecture des informations.
Les imprimes suivants donnent une idée sur cette utilisation : Test du WebService « Inscription »
La figure précédente représente un test d’utilisation du web service REST pour créer un objet user sous format JSON, dans la table « user » de la BD MySql de notre projet. Utilisation de la méthode POST pour envoyer via URL indiquant un objet JSON comme le montre la partie Body, en contre partie le serveur va répondre par un objet du même format, composé d’un name ‘respence ‘ et un value ‘1’ pour indiquer que la création a été faite avec succès. 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 d’envoi d’email render rep as JSON } catch(Exception e) { def rep = [ respence: "2" ] // Problem sending email render rep as JSON } } else { }
def rep = [ respence: "0" ] // email déja utilisé render rep as JSON
Remarquons bien que l’objet envoyé est bien crée dans la table ‘user’ de notre BD
Aussi un email a été envoyé pour dire bienvenue !
L’utilisateur peut se connecter à l’application Android ou web après avoir s’authentifier en saisissant son login et mot de passe.
Test authentification Android : Code source JAVA, la fonction onClick représente l’écouteur 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 l’envoie de la requête Get au serveur, il ne reste à l’application Android qu’attendre la repense : « 1 » pour dire que l’authentification est valide. « 0 » authentification non valide, email ou mot de passe incorrecte.
Authentification Web :
Supposons qu’un utilisateur a oublié son mot de passe, il peut le récupérer par la saisie de son mail. Test du WebService « mot de passe oublié»
Respence = 1 le mail est bien envoyé !
Implémentation s ur Android :
Implémentation s ur le site Web:
Annexe 2 1. Smartphones et applications mobiles Ces dernières années, l’arrivée de nouveaux acteurs: Apple avec son Iphone et Google avec Android, a changé la façon de concevoir le mobile : ce n'est plus un outil pour appeler et recevoir des messages, le téléphone est devenu un moyen de tout faire où que l'on soit. Il est ainsi devenu un outil plus qu'indispensable pour certains métiers et certaines classes sociales. Nous exhibons dans ce qui suit des statistiques sur ces acteurs afin de mieux comprendre leurs situations actuelles. Ensuite, nous présentons l’internet et les applications mobiles. 1.1 Android : statistiques impressionnantes Le taux d’activations des appareils Android, qui était de 300 000 par jour en fin 2010, 700.000 par jour en fin 2011. Aujourd’hui, en début 2012, 850 000 téléphones Android par jour. C’est à l’entour de 6 millions de téléphones par semaine, environ 24 millions de téléphones par mois, ou 288 millions de téléphones par an. Concernant les applications Android, le Google Play Store a dépassé au 1er Février 2012 la barre des 400 000 applications. Le nombre d’applications a triplé en un an. Le nombre de téléchargements faits sur le Play Store depuis son lancement est 10 milliard, mais ce n’est pas tout, Google annonce que le taux mensuel de téléchargements d’applications Android est aujourd’hui d’un milliard par mois. 1.2 Technologies de développe ment d’applications mobiles sous Android 1.2.1
Présentation
Android est un OS (Operating System) mobile Open Source pour Smartphone, PDA (Personal Digital Assistant) et tablette. Conçu initialement par Android Inc. Android a été racheté par Google en 2005. L’OS Android a été lancé officiellement le 15 novembre 2007.
1.2.2
Architecture
La figure 4 illustre les composants principaux du système d’exploitation Android. Chaque section sera décrite dans ce qui suit.
Architecture Android
1.2.3
Applications
Android est fourni avec un ensemble d’applications 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 développe ment
En fournissant une plateforme de développement ouverte, Android offre aux développeurs la possibilité de créer des applications extrêmement riches et innovants. L’architecture d’application est conçue pour simplifier la réutilisation des composants. 1.2.5
Bibliothèques
Android dispose d’un ensemble de librairies C/C++ utilisées par les différents composants du système Android. Elles sont offertes aux développeurs à travers le framework Android.
1.2.6
Android Runtime
Android inclut un ensemble de librairies de base offrant la plupart des fonctionnalités disponibles dans les bibliothèques de base du langage de programmation Java. Chaque application Android s’exécute 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 manière efficace. La machine virtuelle Dalvik s’appuie sur le noyau Linux pour les fonctionnalités de base telles que le filetage et gestion de la mémoire de bas niveau. 1.2.7
Linux Ke rnel
Android repose sur la version Linux 2.6 pour les services système de base tels que la sécurité, la gestion mémoire, gestion de processus pile réseau, et le modèle de pilote. Le noyau agit également comme une couche d’abstraction entre le matériel et le reste de la pile logicielle.
Annexe 3 3. Frame work Grails 3.1 Présentation Grails comme tout autre Framework Java se basant sur ce patron de conception, Grails possède des modèles qui comportent les données et qui sont référé en tant que "Domain class" mais la différence consiste dans le fait que dans Grails ces modèles sont persistants et peuvent directement êtres mappés dans la Base de donnée générant ainsi le schéma de données de l’application. Dans Grails c’est les contrôleurs qui gèrent les requêtes et organisent le travail des services et autres composants de la couche métier. Finalement la partie Vue est constitué des GSP (Groovy Server Pages) et qui intègrent eux aussi des fonctionnalités très intéressantes tels que les "TagLib", "les Templates" ou encore les "layout". Tous ces éléments seront revus plus en détails dans les sections qui suivront. 3.2 Architecture du frame work Grails
Architecture du framework Grails
Voici un schéma qui récapitule 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 l’infrastructure d’une application java. Spring est décrit comme étant un conteneur "léger", c'est-à-dire qu’il prend en charge la création 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 gérer la mise en page. Il implémente le design pattern decorator pour générer les pages html. Il va par exemple nous permettre d’ajouter des entêtes et pieds de page sur chacune des pages de l'application. GORM nous permet d'établir les relations entre les objets Groovy et le schéma relationnel. GORM, basé sur Hibernate, est une couche d'abstraction par rapport aux bases de données. Par défaut, Grails utilise la base de donnée intégrée à Hibernate: HSQLDB. Gant (pour "Groovyant"), est une couche au-dessus du célèbre "ant" qui permet d'écrire les tâches en groovy plutôt qu'en XML. Les commandes permettant de gérer 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 privilégiée à la configuration. En d’autres mots au lieu d’avoir recours aux fichiers de configuration à comme dans tout autre application JEE, Grails utilise un système de convention qui remplace la configuration conventionnelle. Par exemple le nom d’une class persistante sera celui de la table qui lui correspond dans la base de donnée. De cette manière il est tout à fait possible de créer toute une application sans passer par les fichiers XML, cependant si le besoin se
fait sentir il est tout à fait possible pour le
développeur de recourir à la configuration classique. Le Scaffolding
Le Scaffolding, ou échafaudage, est un atout majeur que propose Grails pour les développeurs en utilisant cette capacité il est possible de générer les contrôleurs et les vue d’une classe persistante seulement à partir de leur définition. En invoquant cette capacité Grails se charge de créer une interface CRUD (create, read, update, delete) standard selon les normes du modèle M -V-C. Il existe deux types de "scaffolding" à savoir le "scaffolding" dynamique et le "scaffolding"statique. Dans le premier cas les contrôleurs est leurs vues correspondante sont générés au "runtime" (exécution). Par contre dans l’échafaudage statique, le code source est disponible pendant le développement il est alors possible d’y apporter des modifications afin de personnaliser le résultat. Bien évidement dans ce cas de figure toute modification du modèle persistant nécessiterait la régénération du code. Les tests Dans Grails les tests possèdent une place importante. En implémentant les interfaces nécessaire les classes tests permettent de tester le fonctionnement de l’application à différent niveau ainsi on distingue entre les tests unitaires et les tests d’intégration ou de haut niveaux. Dans le cadre des tests unitaires Grails intègre le Framework "JUnit", ce type de tests est totalement indépendant de l’environnement de l’application, bases de données, conteneur de servlets, ou encore tout élément du protocole http. Néanmoins tous ces acteurs peuvent être remplacés par des objets mock (bouchons) qui offrent une simulation des fonctions proposées par ces derniers. Par contre dans le cas des tests d’intégration on a accès à tous les éléments de ce qui permet de tester les interactions entre les différentes couches et le comportement de l’application dans sa totalité. Les plugins Une autre notion fondamentale de Grails est les plugins en effet le Framework Grails est extrêmement extensible et permet l’intégration d’une multitude de composants logiciels de ce type. En quelque sorte les plugins sont des petites applications Grails pouvant posséder leurs propre contrôleur, vue ou modèle et qui s’intègrent à l’application dans le but de fournir une fonctionnalité bien précise 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 spécifiquement conçu pour exploiter toute la puissance de cette dernière. Ainsi il y’a peu ou pas de différence, réduisant ainsi d’une manière significative la période d’apprentissage. Par exemple Groovy utilise l’API "Java" plutôt que d’imposer sa propre API. Il en résulte que les développeurs n’ont pas à choisir entre utiliser les librairies Java et les librairies provenant d’autres langages. Par ailleurs la compatibilité complète de Groovy avec la JVM fait qu’il subsiste un couche épaisse de "byte code" qui facilite d’avantage l’intégration de « Java » à Groovy et vice versa. Groovy ne fait pas qu’exploiter l’API "Java" il l’étant en y ajoutant des fonctionnalités et des méthodes qui l’enrichissent d’autant plus. Il comporte tous les aspects de la programmation moderne qui rendent les langages plus productifs et plus souples tels que les "Closures" qui représente un bout de code mais pouvant être manipulé à la fois comme une variable ou une méthode, il permet aussi l’automatisation des accesseurs pour les "Beans". De cette façon le langage Groovy diminue la quantité de bruit dans le code, réduisant d’une façon significative la taille de ce dernier. Il est à noter que Groovy en plus d’être orienté objet rend possible l’écriture de scripts on peut donc exécuter du code sans que pour autant ce dernier soit contenu dans la méthode d’une classe.
Bibliographie [1] :THESE :Développement itératif, évolutif et agile Nicoletta SERGI 23/11/2007 [2] :THESE :Ingénierie des SystèmesLogiciels, Dr. Marcellin Julius NKENLIFACK [3] :http://fr.wikipedia.org/wiki/Extreme_programming [4] :THESE :Modélisation des applications distribuées a architecture dynamique , Conception et Validation 13 Novembre 2008 [5]UML en action :Deuxième édition 2003 ,de l’analyse des besoins à la conception en Java [6]Résumé du sous-ensemblede la notation UML 2 [7]: Cours « Atelier UML » Tarak Chaari [8]: Conception et réalisationd’une application de gestiondes comptes mail et internet 2010-2011 [9] : ModélisationSystèmes d’information,2005-2006 [10]: Génie logicielUML : UnifiedModelingLanguage A. Madani [11]:Projet de fin d’études 2005/2006 [12]:http://fr.wikipedia.org/wiki/Groovy [13]:Rapport de TER,Application client-serveur de vente aux enchères [14]:http://www.json.org/jsonfr.html [15]:Mémoire:Conception, développement et intégration d'une application embarquée de téléchargement 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 réalisation et le développement d’une application web et Android création des codes a barre, aussi création des cartes de fidélité.
pour la lecture et la