Rapport PFE Wahid Gazzah
89
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 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
Transcript of Rapport PFE Wahid Gazzah
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
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
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 comptes »
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
1
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 parvenir, il est primordial de proposer de
2
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 :
3
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.
4
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.
5
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 Yasmine 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).
6
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 codes-
barres 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
Codes-barres unidimensionnels (1D)
[EAN, CUP, Code 11, Code 39…]
Codes-barres bidimensionnels (2D)
[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
7
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.
8
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
9
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.
Figure 2.1 : Organisation du processus unifié
Naissance Mort
Cycles
10
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.
11
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.
12
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
13
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 :
• Scanner un QR Code
Gestion des QR Codes :
• Créer QR Code
• Partager QR Code
• Supprimer QR Code
Gestion de la publicité :
• Consulter publicité
Gestion compte utilisateur :
• Ajouter utilisateur
• Consulter utilisateur
• Modifier utilisateur
Gestion de l’historique:
• Consulter historique
• Partager historique
• Supprimer historique
Gestion des cartes de fidélité :
• Créer carte de fidélité
• Consulter carte de fidélité
• Supprimer carte de fidélité
Gestion des actualités :
• Consulter actualité
Gestion des statistiques :
• 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.
14
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.
15
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.
16
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
Acteur principal
Acteur secondaire
Message(s)émis / reçus
par les Acteurs
Authentification (identification
utilisateurs)
User Emet : login et mot de passe
Reçu : confirmation Admin
Ajouter compte
User
Emet : création
Reçoit : confirmation
Modifier compte Emet : modification
Reçoit : validation
Récupérer mot de passe Emet : Email
Reçoit : mot de passe
Créer QR Code
User
Emet : création
Reçoit : confirmation
Supprimer QR Code Emet : suppression
Reçoit: validation
Consulter actualités
User
Emet : consultation
Reçoit: liste
Inscription Newsletter Emet : Email
Reçoit : confirmation
Consulter statistique
Admin
Emet : consultation
Reçoit: liste
Ajouter publicité Emet : création
Reçoit : confirmation
Rédiger actualités Emet : création
Reçoit : enregistrement
Supprimer actualités Emet : suppression
Reçoit : validation
Modifier actualités Emet : modification
Reçoit : confirmation
Consulter actualités Emet : consultation
Reçoit : affichage
17
Ajouter Compte
Admin
Emet : création
Reçoit : confirmation
Supprimer Compte 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
18
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 :
19
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
20
à 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 Cas d'utilisation « Créer QR Code »
Titre : 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
21
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.
22
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 Cas d'utilisation " Gestion Carte de fidélité "
Titre : 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.
23
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
User
Gestion de profil
Récupérer mot de passe
User
Gestion des comptes Modifier compte
Ajouter compte
Supprimer QR Code User Gestion QR Code
Créer QR Code
Ajouter Compte
Admin
Gestion des Comptes
clients
Supprimer Compte
Modifier Compte
Consulter compte
Créer carte
User
Gestion des cartes de
fidélité Supprimer carte
Rédiger actualités
Admin
Gestion des actualités
Supprimer actualités
Modifier actualités
Consulter actualités
Rédiger actualités
24
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 ancê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 »
25
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.
26
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.
27
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 :
28
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.
Figure 4.11 : Digramme des classes participantes de « Gestion des Actualités »
29
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
30
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 tiers
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
31
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
32
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.
33
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 web 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.
34
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.
35
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]
36
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.
37
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).
38
En cas de perte ou l’oubli de mot de passe l’utilisateur peut le retrouver en saisissant son
Email.
Figure 6.3 Diagramme de séquence du scénario « S’authentifier »
39
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).
40
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.
41
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 »
42
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 »
43
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 »
44
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 »
45
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]
46
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é »
47
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 »
48
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é »
49
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.
50
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
Android
Système d'explo itation open source pour
Smartphones, PDA et terminaux mobiles
Voir 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).
51
JSON (JavaScript Object 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
String name = "World"
System.out.println("Hello " + name);
def name = "World"
println "Hello $name"
Objectname = "Groovy";
System.out.println(((String)
name).toUpperCase());
def name = "Groovy"
printlnname.toUpperCase()
String[]s={"Php", "Grails "," Java "};
for(inti = 0; i <S.length; i++)
if(S[i].length()<= 4)
System.out.println(S);
list = ["Php ", "Grails ", " Java "]
shorts =list.findAll{it.size() <= 4}
shorts.each { printlnit }
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
52
lib/
Les librairies et classes du projet
conf/ Les fichiers de configuration du projet
plugins/ Les plugins installés
test/ Les tests unitaires et fonctionnels
web/ Le répertoire racine web (fichier css, js,.. )
2. MVC (Model-View-Controller)
C’est une architecture et une méthode de conception qui organise l'interface homme-
machine (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]
53
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
54
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]
55
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 avec 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.
56
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
57
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 :
58
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
Parties
Taches Réalisation
Conception de
l’application
Réalisation de l’étude de la base de
données
Back Office
Créer les tables de la BD
Etablir les liaisons entre les tables
Créer pub
Créer espace Admin
59
Front office
Créer Compte
Créer Compte WebService REST (JSON
+ XML)
Update Compte
Update Compte WebService REST (JSON
+ XML)
S’authentifier
S’authentifier WebService REST (JSON +
XML)
Récupérer le mot de passe oublié dans un
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)
Consulter les QR Code Créé WebService
REST (JSON + XML)
Application Android
Splash Screen
Menu principal en deux versions
Scan des codes a barre
Créer des QR Code de différents types
(sms, email, contact, phone, url, texte)
Partager QR Code créé (FaceBook,
Twitter, Skype, sms, email…)
Créer un compte utilisateur via un
WebService REST
60
Authentification via un WebService REST
Consulter Compte via un WebService
REST
Application Android
Mise a jour d’un compte via un
WebService REST
Consulter 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
Etablir les liaisons entre les tables
Consulter l’historique des QR Code
Scanner des cartes de fidélité
Générer une carte de fidélité
Consulter la liste des cartes de fidélité
Consulté les surface de vente via la Réalité
augmenté (100 % réalisé)
Consulté les surface de vente via une
MapView (100 % réalisé)
Consulté les surface de vente via une List
View (100 % réalisé)
Tableau 7.5:les taches réalisées dans l’application
61
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.
62
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é
63
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
64
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)
65
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
66
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é
67
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.
68
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.
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 sur Android :
Implémentation sur 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éveloppement 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 Framework de développement
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 Kernel
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. Framework 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 framework 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 Fonctionnement
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 pour la lecture et la
création des codes a barre, aussi création des cartes de fidélité.
