Rapport Pfe Mobile

Faculté des Sciences et
Techniques - Settat
DÉDICACE
Nous dédions ce modeste travail à :
En premier lieu ceux que personne ne peut compenser les sacrifices qu’ils ont
consentis pour notre éducation et notre bien-être à nos parents qui se sont
sacrifiés pour nous prendre en charge tout au long de notre formation et qui
sont l’origine de notre réussite que dieu les garde et les protèges.
A notre famille et nos chers amis qui nous ont accordé leur soutien dans les
instants les plus difficiles.
Tous nos formateurs et toute l’équipe pédagogique et administrative de CIGMA
pour l’aide qu’ils ont toujours porté aux étudiants.
Toute personne qui de près ou de loin a participé à notre formation.
1
Techniques - Settat
REMERCIEMENT
C’est un plaisir et un moment très agréable de rendre hommage et de
formuler des remerciements aux personnes qui, d’une manière ou d’une autre,
ont apporté leur soutien et contribué à finaliser ce travail.
Nous tenons, tout d’abord, à exprimer nos sincères gratitudes envers

notre encadreur Mr. Smail NAMIRI, pour les conseils qu’il n’a cessés de nous
prodiguer, sa compréhension et la confiance qu’il a toujours témoignée à notre
égard.
Nous remercions aussi Mr. Mounir MAHFOUD responsable formation et

développement pour ces conseils et ces écoutes de nous problèmes tout au
long de notre formation au sein du centre CIGMA.
Nous remercions également Mr. EL ALAMI Semma directeur de centre

CIGMA.
Nous associons à ces remerciements tous les enseignants qui ont

contribué à notre formation ainsi qu’à toutes les personnes qui travaillent au
sein du CIGMA à la FST de SETTAT.
2
Techniques - Settat
SOMMAIRE
DÉDICACE...................................................................................................................................................... 1
REMERCIEMENT............................................................................................................................................ 2
SOMMAIRE.................................................................................................................................................... 3
TABLE DE FIGURES......................................................................................................................................... 5
LISTE DES ABRÉVIATIONS............................................................................................................................... 6
INTRODUCTION GENERALE............................................................................................................................ 7
CHAPITRE-1: CADRE GENERAL........................................................................................................................ 8
INTRODUCTION............................................................................................................................................. 8
I. PRESENTATION DU CADRE DU PROJET........................................................................................................9

1. Problématique.........................................................................................................................................9
2. Présentation de la solution SmartBusinessCard.....................................................................................9
a. Le projet Web (Moteur de recherche des cartes de visite)................................................................................9
b. Le projet Mobile (Gestionnaire de cartes de visite).........................................................................................10
II. GESTION DU PROJET INFORMATIQUE.....................................................................................................11
3. Cycle de vie d’un logiciel.......................................................................................................................11
4. Modèle de cycle de vie d’un logiciel.....................................................................................................13
a. Modèle de cycle de vie en cascade..................................................................................................................13
b. Modèle de cycle de vie en V............................................................................................................................13
5. Planning.................................................................................................................................................15
6. Méthodologie de conception................................................................................................................15
a. Etude comparative entre MERISE et UML........................................................................................................15
b. La démarche adoptée :....................................................................................................................................16
CONCLUSION............................................................................................................................................... 17
CHAPITRE-2 : CAPTURE DES BESOINS........................................................................................................... 18
INTRODUCTION........................................................................................................................................... 18
I. IDENTIFICATION DES ACTEURS................................................................................................................19

II. LES BESOINS FONCTIONNELS..................................................................................................................20
III. BESOINS NON FONCTIONNELS................................................................................................................21
1. Contrainte ergonomique......................................................................................................................21
2. Contrainte non ergonomique................................................................................................................21
IV. DIAGRAMMES DE CAS D’UTILISATION GENERALE...................................................................................22
CONCLUSION............................................................................................................................................... 24
CHAPITRE-3 : ANALYSE & CONCEPTION........................................................................................................ 25
INTRODUCTION........................................................................................................................................... 25
I. DIAGRAMMES DE CAS D’UTILISATION.....................................................................................................26

1. Diagramme de cas d’utilisation s’identifier...........................................................................................26
2. Diagramme de cas d’utilisation « créer un compte »...........................................................................27
3. Diagramme de cas d’utilisation « lister les cartes visites par catégories »...........................................27
II. DIAGRAMMES D’ACTIVITES.....................................................................................................................28
3
Techniques - Settat
1. Diagramme d’activités de cas d’utilisation « s’identifier »..................................................................28
2. Diagramme d’activités de cas d’utilisation « créer un compte »..........................................................29
3. Diagramme d’activités de cas d’utilisation « lister carte de visite par catégorie »..............................30
III. DIAGRAMME DE CLASSES..........................................................................................................................31
CONCLUSION............................................................................................................................................... 31
CHAPITRE-5 : IMPLEMENTATION.................................................................................................................. 32
INTRODUCTION........................................................................................................................................... 32
I. ENVIRONNEMENT MATERIEL..................................................................................................................33
1. Architecture du matériel......................................................................................................................33
2. Matériels utilisés...................................................................................................................................34
II. TECHNOLOGIES.......................................................................................................................................35
1. Développement mobile.........................................................................................................................35
a. Présentation de la plateforme Android...........................................................................................................35
b. Architecture d’Android....................................................................................................................................35
c. L’API Zxing.......................................................................................................................................................36
2. Développement Web............................................................................................................................37
a. La plateforme J2EE..........................................................................................................................................37
b. Méthodologie de développement : la démarche MVC....................................................................................37
c. La plateforme de présentation Strusts............................................................................................................39
d. La plateforme de mapping Objet/Relationnel HIBERNAT................................................................................40
e. La technologie Ajax.........................................................................................................................................40
3. QR-Code.................................................................................................................................................40
III. OUTILS DE DÉVELOPPEMENT...........................................................................................................................41
1. Environnement de développement Intégré : Eclipse............................................................................41
2. Le serveur d’application Appache Tomcat............................................................................................41
3. Le serveur de base de données MySQL.................................................................................................41
4. Entreprise Architect...............................................................................................................................42
5. Le gestionnaire de version SVN.............................................................................................................42
a. Le serveur de version VisualSVN......................................................................................................................42
b. Le client TurtoiseSVN.......................................................................................................................................42
IV. ECRANS......................................................................................................................................................43
1. Réalisation Web.....................................................................................................................................43
2. Réalisation Mobile.................................................................................................................................47
CONCLUSION............................................................................................................................................... 54
CONCLUSION GENERALE.............................................................................................................................. 55
BIBLIOGRAPHIE............................................................................................................................................ 56
4
Techniques - Settat
TABLE DE FIGURES
FIGURE 1 : MODÈLE DU CYCLE DE VIE EN CASCADE............................................................................................................13
FIGURE 2 : MODÈLE DU CYCLE DE VIE EN V....................................................................................................................14
FIGURE 3 : PLANING DU PROJET..................................................................................................................................15
FIGURE 4 : METHODOLOGIES DE CONCEPTION ADOPTEE...................................................................................................16
FIGURE 5 : DIAGRAMME DE CAS D’UTILISATION GÉRER OBJET (COMPTE, CARTE VISITE, CATÉGORIE ETC.)..................................22
FIGURE 6 : DIAGRAMME DE CAS D’UTILISATION GLOBAL DE L’APPLICATION WEB...................................................................23
FIGURE 7 : DIAGRAMME DE CAS D’UTILISATION GLOBAL DE L’APPLICATION MOBILE...............................................................24
FIGURE 8 : DIAGRAMME DE CAS D’UTILISATION« S’IDENTIFIER »........................................................................................26
FIGURE 9 : DIAGRAMME D’ACTIVITÉS DE CAS D’UTILISATION « S’IDENTIFIER »......................................................................28
FIGURE 10 : DIAGRAMME D’ACTIVITÉS DE CAS D’UTILISATION CRÉER COMPTE......................................................................29
FIGURE 11 : DIAGRAMME D’ACTIVITÉS DE CAS D’UTILISATION LISTER CARTE DE VISITE PAR CATÉGORIE.......................................30
FIGURE 12 : DIAGRAMME DE CLASSE GÉNÉRAL...............................................................................................................31
FIGURE 13 : ARCHITECTURE MATÉRIEL DU SYSTÈME.........................................................................................................33
FIGURE 14 : COMMUNICATION AVEC MYSQL DEPUIS LE MOBILE........................................................................................34
FIGURE 15 : ARCHITECTURE DU SYSTÈME D’EXPLOITATION ANDROID..................................................................................35
FIGURE 16 : L'ARCHITECTURE MVC.............................................................................................................................38
FIGURE 17 : SCHÉMA DU FRAMEWORK STRUTS 2...........................................................................................................39
FIGURE 18 : SCHÉMA DU FRAMEWORK HIBERNAT........................................................................................................40
FIGURE 19 : PAGE DE RECHERCHE(LES RÉSULTATS CE FORME DE CARTE DE VISITE).................................................................43
FIGURE 20 : CODE À BARRE A DEUX DIMENSIONS DU LAFARGE (APRÈS LA CLIQUE SUR UNE CARTE)........................................44
FIGURE 21 : DÉTAIL D'UNE CARTE DE VISITE...................................................................................................................45
FIGURE 22 : FORMULAIRE D'INSCRIPTION AU SITE WEB....................................................................................................45
FIGURE 23 : FORMULAIRE D'AUTENTIFICATION...............................................................................................................46
FIGURE 24 : FORMULAIRE DE CRÉATION D'UNE CARTE DE VISITE........................................................................................46
FIGURE 25 : ACTIVITÉ D'ACCUEIL.................................................................................................................................47
FIGURE 26 : ACTIVITÉ DE RECHERCHE CATÉGORIES & CARTES DE VISITE(ONGLET CÉTGORIES)..................................................47
FIGURE 27 : ACTIVITÉ DE RECHERCHE CATÉGORIES & CARTES DE VISITE (ONGLET CARTES DE VISITE)........................................48
FIGURE 28 : MENU CONTEXTUEL DU CATÉGORIE "DÉVELOPPEURS MOBILE"........................................................................48
FIGURE 29 : LISTE DES CARTES DE VISITE (APRÈS LA CLIQUE SUR LISTE DES CARTES DE VISITE)..................................................49
FIGURE 30 : MENU CONTEXTUEL DU CONTACT "MOBILE APPLICATION"..............................................................................49
FIGURE 31 : ACTIVITÉ DÉTAILS CARTE DE VISITE DU CONTACT "MOBILE APPLICATION"...........................................................50
FIGURE 32 : LA LISTE DÉROULANTE DE CATEGORIES.........................................................................................................51
FIGURE 33 : MENU DE L'ACTIVITÉ DÉTAILS CARTES DE VISITES............................................................................................52
FIGURE 34 : ACTIVITÉ D'APPEL APRÈS LA CLIQUE SUR L'ICÔNE D'APPEL................................................................................53
FIGURE 35 : MENU CONTEXTUEL DES DIFFÉRENTS APPLICATIONS........................................................................................53
FIGURE 36 : MENU CONTEXTUEL DE PARTAGE AVEC LA LISTE DES DIFFÉRENTS.......................................................................54
5
Techniques - Settat
LISTE DES ABRÉVIATIONS

SBC SmartBusinessCard
QR Quick Response
UML Unified Modeling Language
MVC Model View Control
API Application Presentaion Interface
App Application
SVNSubversion version control system
JSP JavaServer Pages
JSON JavaScript Object Notation
XML Extensible Markup Language
http HyperText Transfer Protocol
URL Uniform Resource Locator
GET Requête de la ressource située à l'URL spécifiée
POST Envoi de données au programme situé à l'URL
spécifiée
XMLHTTPREQUES est un objet ActiveX ou JavaScript qui permet
T d'obtenir des données au format XML, JSON, mais
aussi HTML, ou encore texte simple à l'aide de
requêtes HTTP
WEB Le World Wide Web (les pages avec liens et
contenus multimédia de ses sites Web
6
Techniques - Settat
INTRODUCTION GENERALE
Comme nous vivons dans un monde où le marché informatique se développe très

rapidement, Le web et le mobile sont devenus deux canaux de prédilection afin d'acquérir et
élargir une base client, fidéliser des usagers, optimiser la mise en contact des entreprises
avec leur cible, mieux segmenter et comprendre les communautés qu'elles adressent.
Dans cette perspective, et dans le cadre de notre projet de fin d’étude, nous avons
réalisé une solution que nous souhaiterons qu’elle soit un Startup. La solution
SmartBusinessCard a pour but de régler la problématique de recherche des professionnels
et la gestion des cartes visite.
Nous avons divisé cette solution en 2 parties :

 Partie web : Moteur de recherche des cartes de visite.
 Partie Mobile : Gestionnaire des cartes de visite.
Dans ce contexte, nous allons procéder comme suit :
Chapitre1 : Cadre Général

Dans ce chapitre, notre projet est présenté comme suit : la problématique à résoudre, la
solution proposée et quelques concepts de gestion projet informatique.
Chapitre2 : Capture des besoins

Nous identifions les acteurs du futur système, les besoins fonctionnels et non fonctionnels
ainsi que les diagrammes du cas d’utilisation global de chaque application.
Chapitre3 : Analyse et conception

Dans ce chapitre nous élaborons une conception détaillée des cas d’utilisation, les
diagrammes d’activité ainsi que le diagramme de classe complet de notre application web et
mobile.
Chapitre4 : Implémentation
Dans le dernier chapitre intitulé « Implémentation », nous présentons l’environnement
matériel et logiciel, le passage vers le schéma relationnel et quelques composantes
applicatives réalisées, et les différentes chartes graphiques de chaque technologie.
7
Techniques - Settat
CHAPITRE-1: CADRE GENERAL
INTRODUCTION
Dans ce chapitre on va présenter les différentes fonctionnalités de notre
solution à savoir la partie web et la partie mobile.
Et nous concluons enfin par la démarche de conception adoptée.
8
Techniques - Settat
I. PRESENTATION DU CADRE DU PROJET

1. Problématique
En tant que professionnels, il n’est pas rare de recevoir très régulièrement des cartes de visite :
clients, fournisseurs, partenaires. Même si certaines cartes finiront leur vie au fond d’une corbeille,
près du bureau, d’autres sont très utiles pour votre business (heureusement la plupart !) et ainsi vous
avez le choix entre :
 enregistrer les informations présentes sur la carte en créant un nouveau contact,

 mettre la carte dans un porte-carte,
 utiliser votre Smartphone pour la sauvegarder,
 utiliser un moteur de recherche qui facilite la recherche,
 mettre les cartes dans un endroit afin de les consulter par un ordinateur ou un smarte
phone.
2. Présentation de la solution SmartBusinessCard

3. Le projet Web (Moteur de recherche des cartes de visite)
L’application web est un moteur de recherche des cartes de visite ajouté
par les visiteurs après inscription à notre site web.
Ci-dessous les différentes fonctionnalités de l’application web.
Networking : l’application web permettra aux utilisateurs anonymes de :

 Retrouver facilement les cartes de visite des médecins, avocats, sociétés etc.
WEB
dans les différentes régions du pays.
 Retrouver la cartographie de chaque carte visite.
 Retrouver les différents produits, services, contacts pour les carte visite des
sociétés.
 Enrichir leurs porte-cartes par des cartes de visite sur le web.
 Partager les cartes visite dans les réseaux sociaux comme Google+, Facebook,
Twitter, LinkIn, Viadeo etc.
Business l’application web permettra aux clients de :

 Rendre les coordonnées personnelles et professionnelles visibles au monde
entier.
 Faciliter le contact.
 Gérer leurs images sur le web.
 Faciliter la représentation des produits, services, contacts.
 Bénéficier de la publicité dans le site web.
 Géolocalisation de leurs locaux,
9
Techniques - Settat
 Générer un code à barre à deux dimensions (QRcode) qui peut être téléchargé
et imprimé dans leurs factures, cartes visites, affiches publicitaires pour
pouvoir représenter leurs activités.
4. Le projet Mobile (Gestionnaire de cartes de visite)

L’application mobile est un gestionnaire de cartes visite situé dans la base de
donnée de l’application web, l’ajout d’une carte de visite se fait par le scanne
du code à barre (QRcode) qui identifie la carte dans le system.
Organising : l’application mobile(ou bien le porte-carte de cartes de visites) permet

de :
 Gérer les cartes visites qui pourront être classées par des catégories
Mobile modifiables en fonction de besoins (exemple : Médecins, Avocats etc.).
 Scanner les QRcodes générés par l’application web afin de les ajouter au
mobile.
 Faire des appels, envois des SMS, emails et accéder au site web.
 Partager les cartes visites dans les réseaux sociaux comme Google+,Facebook,
Twitter, LinkIn, Viadeo etc.
 Sauvegarder les données locales dans un serveur distant, et les récupérer en
cas de perte du smartphone.
10
Techniques - Settat
2. GESTION DU PROJET INFORMATIQUE

5. Cycle de vie d’un logiciel
Le cycle de vie d’un logiciel (en anglais software lifecycle), désigne toutes les étapes
de développement d’un logiciel, de sa conception à sa disparition. L’objectif d’un tel
découpage est de permettre de définir des jalons intermédiaires permettant la validation du
Développement logiciel, c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la
vérification du processus de développement, c’est-à-dire l’adéquation des méthodes mises
en œuvre.
L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant
plus élevé qu’elles sont détectées tardivement dans le processus de réalisation. Le cycle de
vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les
délais de sa réalisation et les coûts associés.
Le cycle de vie du logiciel comprend généralement au minimum les étapes suivantes :
 Définition des objectives:
Cette étape consiste à définir la finalité du projet et son inscription dans une stratégie
globale.
 Analyse des besoins et faisabilité:
C’est-à-dire l’expression, le recueil et la formalisation des besoins du demandeur (le client)

et de l’ensemble des contraintes, puis l’estimation de la faisabilité de ces besoins.
 Spécifications ou conception générale:
Il s’agit de l’élaboration des spécifications de l’architecture générale du logiciel.
 Conception détaillée:
Cette étape consiste à définir précisément chaque sous-ensemble du logiciel.
 Codage (Implémentation ou programmation):
C’est la traduction dans un langage de programmation des fonctionnalités définies lors de

phases de conception.
 Tests unitaires:
Ils permettent de vérifier individuellement que chaque sous-ensemble du logiciel est

implémenté conformément aux spécifications.
11
Techniques - Settat
 Intégration :
L’objectif est de s’assurer de l’interfaçage des différents éléments (modules) du logiciel. Elle
fait l’objet de tests d’intégration consignés dans un document.
 Qualification (ou recette) :
C’est-à-dire la vérification de la conformité du logiciel aux spécifications initiales,
 Documentation :
Elle vise à produire les informations nécessaires pour l’utilisation du logiciel et pour des
développements ultérieurs.
 Mise en production :
C’est le déploiement sur site du logiciel.
 Maintenance :
Elle comprend toutes les actions correctives (maintenance corrective) et évolutives

(maintenance évolutive) sur le logiciel.
La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix
d’un modèle de cycle de vie entre le client et l’équipe de développement. Le cycle de vie
permet de prendre en compte, en plus des aspects techniques, l’organisation et les aspects
humains.
Ils existent plusieurs modèles de cycles de vie d’un logiciel tels que : Modèle en cascade, en
V, en spiral, par incrément, etc.
12
Techniques - Settat
6. Modèle de cycle de vie d’un logiciel

a. Modèle de cycle de vie en cascade
Le modèle de cycle de vie en cascade a été mis au point dès 1966, puis formalisé aux
alentours de 1970.
Dans ce modèle le principe est très simple : chaque phase se termine à une date précise par
la production de certains documents ou logiciels. Les résultats sont définis sur la base des
interactions entre étapes, ils sont soumis à une revue approfondie et on ne passe à la phase
suivante que s’ils sont jugés satisfaisants.
Figure 1 : Modèle du cycle de vie en cascade
Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été

rajoutée ultérieurement sur la base qu’une étape ne remet en cause que l’étape précédente,
ce qui, dans la pratique, s’avère insuffisant.
L’inconvénient majeur du modèle de cycle de vie en cascade est que la vérification du bon
fonctionnement du système est réalisée trop tardivement: lors de la phase d’intégration, ou
pire, lors de la mise en production.
2. Modèle de cycle de vie en V

Le modèle en V demeure actuellement le cycle de vie le plus connu et certainement le plus
utilisé. Il s’agit d’un modèle en cascade dans lequel le développement des tests et des
logiciels sont effectués de manière synchrone.
13
Techniques - Settat
Figure 2 : Modèle du cycle de vie en V
Le principe de ce modèle est qu’avec toute décomposition doit être décrite la

recomposition et que toute description d’un composant est accompagnée de tests qui
permettront de s’assurer qu’il correspond à sa description.
Ceci rend explicite la préparation des dernières phases (validation-vérification) par les
premières (construction du logiciel), et permet ainsi d’éviter un écueil bien connu de la
spécification du logiciel : énoncer une propriété qu’il est impossible de vérifier
objectivement après la réalisation.
La représentation en V tient d'avantage compte de la réalité, le processus de

développement n'est pas réduit à un enchaînement de tâches séquentielles. Elle montre
que:
C'est en phase de spécification que l'on se préoccupe des procédures de qualification, C'est
en phase de conception globale que l'on se préoccupe des procédures d'intégration, C'est en
phase de conception détaillée que l'on prépare les tests unitaires.
Le modèle de cycle de vie en V permet d'anticiper sur les phases ultérieures de
développement du produit.
En particulier le modèle en V permet de commencer plus tôt:
 Plan de tests de qualification,
 Plan d'évaluation des performances.
Cependant, ce modèle souffre toujours du problème de la vérification trop tardive du bon
fonctionnement du système.
14
Techniques - Settat
3. Planning
Figure 3 : Planing du projet
4. Méthodologie de conception
a. Etude comparative entre MERISE et UML
MERISE (Méthode d’Etude et de Réalisation Informatique pour les Systèmes
d’Entreprise) est une méthode d'analyse et de réalisation des systèmes d'information qui est
élaborée en plusieurs étapes: schéma directeur, étude préalable, étude détaillée et la
réalisation.
Alors que UML (Unified Modeling Langage), est un langage de modélisation des systèmes
standard, qui utilise des diagrammes pour représenter chaque aspect d'un système ie:
statique, dynamique,....en s'appuyant sur la notion d'orienté objet qui est un véritable atout
pour ce langage.
Merise ou UML ?
Les "méthodologues" disent qu'une méthode, pour être opérationnelle, doit avoir 3
composantes:
 Une démarche (les étapes, phases et tâches de mise en œuvre),
 Des formalismes (les modélisations et les techniques de transformation),
 Une organisation et des moyens de mise en œuvre.
Merise se positionne comme une méthode de conception de SI organisationnel, plus

tournée vers la compréhension et la formalisation des besoins du métier que vers la
réalisation de logiciel. En sens, Merise se réclame plus de l'ingénierie du SI métier que du
génie logiciel.
Jamais Merise ne s'est voulu une méthode de développement de logiciel ni de
programmation.
UML, de par son origine (la programmation objet) s'affirme comme un ensemble de
formalismes pour la conception de logiciel à base de langage objet.
15
Techniques - Settat
Merise est encore tout à fait valable pour:
 La modélisation des données en vue de la construction d'une base de données
relationnelle,
 La modélisation des processus métiers d'un SI automatisé en partie par du logiciel.
 La formalisation des besoins utilisateur dans le cadre de cahier des charges
utilisateur, en vue de la conception d'un logiciel adapté.
UML est idéal pour :

Concevoir et déployer une architecture logicielle développée dans un langage objet
(Java, C++, VB.net). Certes UML, dans sa volonté "unificatrice" a proposé des formalismes,
pour modéliser les données (le modèle de classe réduit sans méthodes et stéréotypé en
entités), mais avec des lacunes que ne présentait pas l'entité relation de Merise, Pour
modéliser le fonctionnement métier (le diagramme d'activité et de cas d'utilisation) qui sont
des formalismes très anciens.
2. La démarche adoptée :
Après cette étude comparative, il est certes que nous adoptons UML comme langage
de modélisation puisque nous allons utiliser le concept de l’orienter objet, à travers le SDK
Android qui est basé sur JAVA, pour développer la solution BusinessSmarteCard.
Ainsi, la méthodologie de conception adoptée se base sur le choix de diagrammes UML

adéquats. Nous avons utilisé quatre diagrammes : diagramme de cas d’utilisation,
diagramme d’activités, diagramme de séquence et diagramme de classes. Le schéma suivant
représente notre méthodologie de conception :
Figure 4 : Methodologies de conception adoptee
Notre outil de conception UML est Entreprise Architect de SPARX SYSTEM. C’est une
référence pour la modélisation UML. Nous allons l’utiliser pour réaliser tous les diagrammes
UML.
16
Techniques - Settat
CONCLUSION
Après avoir présenté le cadre général du projet, une étude préalable s’impose afin
d’étudier le domaine de plus près et de repérer la procédure de fonctionnement actuelle.
17
Techniques - Settat
CHAPITRE-2 : CAPTURE
DES BESOINS
INTRODUCTION
le présent chapitre nous permet d’identifier toutes les fonctionnalités de
notre futur système pour chaque type d’utilisateur, et ceci en recensant les
besoins fonctionnels et d’appréhender la liste des exigences traduites par les
besoins non fonctionnels.
Ceci se fera par l’identification des acteurs et la définition de tous les
besoins qui seront modélisés par des diagrammes de cas d’utilisation
générales.
18
Techniques - Settat
I. IDENTIFICATION DES ACTEURS

Nous avons présenté dans cette partie les différents acteurs possibles de l’application
Web et l’application Mobile :
App. Web :
uc App. We... ac-web.utilisateurAnonyme : c’est un acteur du site web qui peut
chercher des cartes visites, scanner le qrCode s’il porte un mobile occupé
de notre application mobile.
Utilisateur
Anonyme
uc App. W... ac-web.client c’est un client qui peut s’inscrire gratuitement dans notre
application afin de créer sa propre carte visite, il a les mêmes droits du l’
ac-web. utilisateurAnonyme.
Client
uc Primary U... ac-web.client : c’est un client comme le client précédent mais il a des
avantages comme la gestion de ces contacts et services, la gestion de ces
produits avec des images etc.
il y’a des droits de l’ac-web. client mais l’inscription dans notre
application est payée et elle dépend de certains critères.
ClientAv ance
App. Mobile :
uc App. Mobile ac-mobile.clientMobile : c’est un acteur qui a déjà installé notre
application dans son smartphone, pour le stock de ces propres cartes
visite et scanner à partir de notre site web, une affiche publicitaire, ou
bien une facture, etc.
ClientMobile
19
Techniques - Settat
2. LES BESOINS FONCTIONNELS
 Chercher les cartes visites par des critères,

 Secteur d’activité : Santé, Juridique/Droit, Publicité, Télécommunication etc.
WEB  Fonction : Médecin, Avocat, Commercial, Consultant etc.
 S’inscrire pour créer son propre compte,
 Modifier son compte,
 Créer sa propre carte de visite et générer un QRcode,
 Télécharger QRCode sous format d’image,
 Gérer ses produits, services, contacts,
 Générer un devis,
 Payer sa facture.
 Scanner le QR d’une carte visite,

 S’inscrire afin de stocker ses propres cartes de visite au serveur.
Mobile 

Gérer ses cartes visite,
Gérer ses catégories,
 Appeler Contact,
 Envoyer SMS, e-mail,
 Partager carte visite sur les différents réseaux sociaux
 etc…
20
Techniques - Settat
3. BESOINS NON FONCTIONNELS

1. Contrainte ergonomique
Ce projet est notre première expérience en développement mobile. Plusieurs
contraintes nous ont considérablement retardés de:
 Limitation de la dimension de l'écran : choisir un minimum de composants

Mobile essentiels à afficher sur l'écran, pas comme celui des ordinateurs.
 Sous Android, il faut gérer la reprise de l'état de l'application après une
perturbation du cycle de vie de celui-ci. C'est-à-dire si au cours de son
fonctionnement, nous avons un appel entrant ou un message, par ordre de
priorité, le système peut arrêter l'activité en cours pour libérer de la mémoire.
2. Contrainte non ergonomique

 L’application doit garantir la sécurité à travers la gestion des droits d’accès,
 L’accès à la base de données doit être souple et rapide,
Web  L’application doit être toujours fonctionnelle,
&  Le choix se fera parmi une liste de valeur rattaché aux champs afin d’assurer le
contrôle de la saisie,
 Espace de stockage des données suffisant,
 L’application doit détecter la présence d’une connexion internet,
 Temps de réponse minimum,
 Communiquer des données entre deux environnements hétérogènes.
 Communication, format des données...
21
Techniques - Settat
4. DIAGRAMMES DE CAS D’UTILISATION GENERALE

Chaque usage que les acteurs font du système est représenté par un cas d’utilisation.
Chaque cas d’utilisation représente une fonctionnalité qui leur été offerte afin de produire le
résultat attendu.
Ainsi, « le diagramme de cas d’utilisation décrit l’interaction entre le système et l’acteur en
déterminant les besoins de l’utilisateur et tout ce que doit faire le système pour l’acteur ».
uc GererObj et
Chercher obj et
Modifier obj et
«extend»
«extend»
Supprimer obj et
Gérer Obj ets «extend»
Actor «include»
S'authentifier
«include»
Aj outer obj et
Figure 5 : Diagramme de cas d’utilisation Gérer Objet (Compte, carte visite, Catégorie etc.)
22
Techniques - Settat
uc App. Web
Rechercher Carte Visite PartageCarteVisite

«extend»
Modifier Télécharger
Scanner QRcode apartir de QRcode
l'ecran d'un ordinateur
Utilisateur Anonyme «extend» Télécharger

«extend»
Carte v isite
«extend»
Télécharger
Consulter «extend»
«include»
Créer carte v isite
«include» S'authentifier
Client
S'inscrir
«include»
Gérer images
«include»
Gérer produits «extend»
Gérer serv ices
ClientAv ance «extend»

Gérer respensables
GénererDev is
PayPal
Paiement
Versement
Figure 6 : Diagramme de cas d’utilisation global de l’application Web
23
Techniques - Settat
uc App. Mobile
Consulter les informarions

d'une Carte de v isite
«include»
Scanner un QRcode
«include»
Enregistrer une carte
de v isite
«extend»
ClientMobile
Gérer les cartes v isites

«include» S'autentifier
«include»
Gérer les catégorie

Modifier une
«extend»
catégorie
«extend» «extend»
Affecter les carte

v isites à des Aj outer une catégorie
catégories
Figure 7 : Diagramme de cas d’utilisation global de l’application Mobile
CONCLUSION
Ce chapitre nous a permis de faire un découpage fonctionnel de notre futur système
par le biais du diagramme de cas d’utilisation et d’anticiper les interfaces qui seront
développées ultérieurement.
Dans le chapitre suivant, nous présentons une analyse détaillée pour les cas
d’utilisation de notre système.
24
Techniques - Settat
CHAPITRE-3 : ANALYSE &

CONCEPTION
INTRODUCTION
Dans ce présent chapitre, nous proposons l’analyse des différents cas
d’utilisation que nous venons de repérer à travers l’activité de capture des
besoins afin de déterminer les différentes classes intervenant dans chacun des
cas et de repérer le séquencement des flux pour chaque scénario de
réalisation.
Il s’agit donc là d’une activité importante, qui sert de base pour le
passage à l’activité de conception.
25
Techniques - Settat
I. DIAGRAMMES DE CAS D’UTILISATION

1. Diagramme de cas d’utilisation s’identifier
uc Authentifer
Authentification
Actor
Figure 8 : Diagramme de cas d’utilisation« S’identifier »
SOMMAIRE D’IDENTIFICATION
Titre : S’identifier
But : Authentification et autorisation d’accès.
Résumé : Le client Web/Mobile introduit son login et mot de passe pour accéder
au système.
Acteurs : ac.clientPotentiel,ac.clientMobile
DESCRIPTION DES ENCHAINEMENTS
Pré conditions Post conditions
Le client doit avoir un compte sur la BD Accès à son espace privé.
SCENARIO NOMINAL
1. Le client demande l’accès au système,
2. Le système affiche le formulaire d’authentification,
3. L’acteur saisit son login et son mot de passe,
4. Le système vérifie les champs (champs obligatoires,..),
5. Le système vérifie l’existence de l’utilisateur,
6. Si le client est identifié, le système affiche l’interface adéquate.
26
Techniques - Settat
2. Diagramme de cas d’utilisation « créer un compte »
Titre : créer compte
But : Créer un compte dans app. Web/Mobile
Résumé : Le client Web/Mobile doit remplir un formulaire d’inscription puis
valide son action. Le système effectue une vérification puis une mise à
jour de la base de données
L’utilisateur doit accéder au système. Client inscrit
SCENARIO NOMINAL
1. Le client demande la création d’un nouveau compte,
2. Le système affiche le formulaire d’inscription,
3. Le client remplit le formulaire puis valide,
4. Le système vérifie puis crée un nouveau compte avec les informations fournies,
5. Le client accède à des interfaces privées.
3. Diagramme de cas d’utilisation « lister les cartes visites par

catégories »
Titre : Lister les cartes visites.
But : Trouver une liste des cartes de visites d’une catégorie.
Résumé : Le client Web/Mobile doit choisir une catégorie puis il appuie sur le
bouton, recherche le système, effectue une vérification et affiche la liste
des cartes de cette catégorie ,les choisie si elles sont existantes.
L’utilisateur doit choisir une catégorie. Le client avoir une liste de carte de visite
SCENARIO NOMINAL
1. Le client demande le formulaire de recherche,
2. Le système affiche le formulaire de recherche,
3. Le client choisie une catégorie,
4. Le système cherche toutes les cartes de visites de cette catégorie,
5. Le système affiche le résultat.
27
Techniques - Settat
2. DIAGRAMMES D’ACTIVITES
Un diagramme d'activités permet de modéliser un processus interactif, global ou
partiel pour un système donné (logiciel, système d'information). Il est recommandable pour
exprimer une dimension temporelle sur une partie du modèle, à partir de diagrammes de
classes ou de cas d'utilisation, par exemple.
Le diagramme d'activités est une représentation proche de l'organigramme ; la
description d'un cas d'utilisation par un diagramme d'activités correspond à sa traduction
algorithmique.
Une activité est l'exécution d'une partie du cas d'utilisation, elle est représentée par un
rectangle aux bords arrondis.
Dans ce qui suit, nous présentons les diagrammes d’activités pour quelques cas d’utilisation
dans notre système.
1. Diagramme d’activités de cas d’utilisation « s’identifier »

Pour accéder à notre application, l’utilisateur doit s’authentifier en entrant son login
et son mot de passe. Le processus d’authentification peut être résumé dans le diagramme
d’activités suivant :
act S''Identifier
demande la boite dialogue

de s'authentification
Aficher la boite dialogue

de s'authentification v ide
Saisire le login et le mot

de passe
[ Action = retour ]
v erfication des champs
[ Champs vide ]
[ Action = retour ] Alert champs v ide
Verifier si l'utilisateur
existe dans la bas
[Utilisateur non existant ]

Alerte utilisateur n'existe
pas
Afficher l'interface de
l'acceuil
Figure 9 : Diagramme d’activités de cas d’utilisation « S’identifier »
28
Techniques - Settat
2. Diagramme d’activités de cas d’utilisation « créer un compte »
act Creer compte
Demande le formulaire de
la création d'un nouv eau
compte
Afficher la formulaire de la
création d'un nouv eau
compte
Remplir la formulaire
[Action = retour]
Verification des champs
[Action = retour]
[ Champs obligatoires vides ou invalides ] Alerte champs

obligatoires v ides ou
inv alides
Verifier si le compte
existe dans la BD
[ Compte existe ]
Alerte le compte existe
déj à dans la BD
[ Compte n'existe pas]
Aj outer un nouv eau compte

/ "ok" aj outer un nouv eau compte
/exit v ider la formulaire
Figure 10 : Diagramme d’activités de cas d’utilisation créer compte
29
Techniques - Settat
3. Diagramme d’activités de cas d’utilisation « lister carte de

visite par catégorie »
act App. ListeCarteVisiteParCategorie
Demande la liste des

catégories
Affiche la liste des

catégories
Choisir une catégorie
[Action = retour] v erifier les cartes v isite

de la catégorie choisit
[Pas de carte vi site]

Alert pas de carte v isite
Afficher la liste des cartes

v isites
[carte visi te trouvé]

[Action = exi t]
choisir une carte v isite
Afficher le details de la
carte v isite
Figure 11 : Diagramme d’activités de cas d’utilisation lister carte de visite par catégorie
30
Techniques - Settat
3. DIAGRAMME DE CLASSES
Un diagramme de classes dans le langage de modélisation unifié (UML) est un type de
diagramme de structure statique qui décrit la structure d'un système en montrant le
système de classes, leurs attributs, et les relations entre les classes.
Ci-dessouss, le diagramme de classes de notre système :
class System
Utilisateur
Role enumDroitAccee
- droit: droitAccee
- designation: char
- email: char «enum»
- login: char 1 + administrateur: char
0..*
- passe: char + anonyme: char
+ client: char
+ clientAvance: char
+ clientMobile: char
Client ClienMobile
ClientAv ance
- tailleMemoireInterne: char
- nbCarteVisite: int - versionOS: char
1
1 1
0..1 1..*
1..*
CarteVisiteAv ance CarteVisite Catégorie
- presentation: char - adresse: char - designation: char

- cercle: Catégorie - id: int
- codePostal: char
- email: char
1 1 - fax: char 1
- fonction: char
1..* - id: int
1..* - logo: byte 1..*
Serv ice - nomPrenom: char
Produit - packIHM: enumPackIHM
- designation: char - QRcode: byte
- autresDetails: char
- raisonSocial: char
- designation: char
- secteurActivite: int
- siteWeb: char
1 - telephone: char
1 - ville: char
+dirige
1..*
1..*
Contact
Image
- email: char
- nom: char
- fonction: char
- type: int
- nom: char
- numGSM: char
Figure 12 : Diagramme de classe général
CONCLUSION
Comme nous pouvons le constater, l’activité de la conception a facilité la
compréhension de notre système qui ébauche vers l’activité d’implémentation.
31
Techniques - Settat
CHAPITRE-5 :
IMPLEMENTATION
INTRODUCTION
Dans ce chapitre, nous présentons l'architecture sur laquelle nous avons développé
nos applications, les différents outils utilisés ainsi que les composantes applicatives réalisées.
32
Techniques - Settat
I. ENVIRONNEMENT MATERIEL
1. Architecture du matériel
Notre solution web et mobile sont deux applications qui se connectent à un serveur
de base de données distant, via Internet, afin de récupérer les données, ce qui
nécessite aussi l’intégration d’un serveur web entre l’application client et le serveur
de base de données.
D’où l’architecture de notre application est à 3 niveaux (architecture 3-tiers),
elle est partagée entre:
 Le client Web/Mobile : Conteneur d’application et demandeur de ressources,
 Le serveur Web : Vue que les données seront communiquées entre deux
environnements hétérogènes, le rôle principal du serveur web est de gérer la
communication entre le client Web/Mobile et le serveur de base de données,
 Le serveur de base de données fournit les données au serveur web.
Requête Requête
Réponse Réponse
Client Web/Mobile Serveur Web Serveur de Données

donn
Figure 13 : Architecture matériel du système
33
Techniques - Settat
Pour le client mobile la communication avec la base de données se déroule on respectant le shama
suivant :
L‘API permet :
- d’accepter une requête par les méthodes
GET/POST
- d’interagir avec les classes PHP pour
récupérer les données.
- Ensuite les données seront encodées au
format JSON et envoyées à l’app. Android
Figure 14 : Communication avec MySql depuis le mobile
2. Matériels utilisés
Pour la réalisation du projet, nous avons utilisé :
 Un Smartphone pour les tests.

 Deux PC portable pour le développement reliés par un câble réseau afin de faciliter la
communication et la gestion de version :
PC1 :
- Processeur Intel Core 2 Duo 2.2 GHz,
- 2 Go de mémoire vive,
- Disque dur de capacité 300 Go,
- Système d’exploitation Microsoft Windows 7 Edition Familiale.
PC2 :
- Processeur Intel Core 2 Duo 2.2 GHz,
- 3 Go de mémoire vive,
- Disque dur de capacité 500 Go,
- Système d’exploitation Microsoft Windows 7 Edition Intégrale.

34
Techniques - Settat
2. TECHNOLOGIES
1. Développement mobile
a. Présentation de la plateforme Android
Android est un système d'exploitation open source utilisant le noyau
Linux, pour smartphones, tablettes tactiles, PDA et terminaux mobiles
conçu par Android, une startup rachetée par Google, et annoncé
officiellement le 5 novembre 20074. D'autres types d'appareils possédant
ce système d'exploitation existent, par exemple des téléviseurs et des
tablettes.
2. Architecture d’Android
Pour bien comprendre la plateforme Android, nous détaillons par la suite
l’architecture du système Android. Le portail des développeurs Android nous présente
l’architecture du système avec le schéma ci-contre
Figure 15 : Architecture du système d’exploitation Android
Linux Kernel : Android s’appuie sur le noyau Linux 2.6 pour les services système de base tels
que la sécurité, la gestion de la mémoire et des processus, le réseau et la gestion des drivers.
Le noyau sert de couche d’abstraction entre le matériel et le reste de la pile logicielle.
Android Runtime : Android inclut un ensemble de librairies fournissant la plupart des
fonctionnalités des librairies standard de Java. Chaque application Android s’exécute dans un
processus, avec sa propre instance de la machine virtuelle Java, appelée Dalvik. Dalvik a été
écrit pour optimiser l’exécution d’une multitude d’instances de la machine virtuelle, avec
35
Techniques - Settat
une empreinte mémoire réduite. Dalvik s’appuie sur le noyau Linux pour les fonctionnalités
bas-niveau tels que les threads ou la gestion de la mémoire.
Librairies: Android fournit un ensemble de librairies C/C++ utilisées par différents
composants du système. Ces fonctionnalités sont rendues disponibles aux développeurs au
travers du framework d’application d’Android. On trouve parmi ces librairies: librairie C
standard, moteurs d’affichage 2D et 3D, SQLite, rendu des polices de caractères etc.
Application Framework : Le framework d’application est la couche qui nous intéresse tout
particulièrement. C’est elle qui fait le lien, grâce à un ensemble d’APIs Java, entre le système
et l’application. Étant un système ouvert, Android permet aux développeurs de concevoir
des applications très riches et de tirer partie d’un maximum de fonctionnalités. Les
développeurs ont donc accès aux mêmes fonctionnalités que celles utilisées par les
applications fournies avec Android. Toute application Android repose sur un ensemble de
services et systèmes parmi lesquels :
 Un ensemble de «Views» permettant de construire l’interface graphique de
l’application : listes, grilles, champs textes, images, et même intégration d’un navigateur web
ou d’une vue Google Maps.
 Des «Content Providers» qui permettent aux applications d’accéder à des données
d’autres applications ou de partager ses propres données,
 Un «Ressource Manager» pour accéder à des éléments autres que du code :
données textuelles traduites, images, descriptions XML d’interfaces graphiques etc.
 Un «Activity Manager» pour gérer le cycle de vie de l’application.
Ce rapide survol de l’architecture du système m a permis de mieux comprendre

comment fonctionne une application Android. Confinée dans la couche la plus haute, elle
accède au système uniquement via les API’s Java exposées par la couche Application
Framework.
Ainsi, si une fonctionnalité est présente dans le noyau Linux (couche rouge sur le schéma) ou
dans les librairies système (couche verte), mais qu’elle n’est pas reliée au framework
d’application, elle ne sera pas utilisable directement dans une application Android.
3. L’API Zxing
ZXing (prononcé "zebra crossing") est un open-source, multi-
format de bibliothèque 1D/2D de traitement d'image code à barres
implémenté en Java, avec les ports vers d'autres langues. Notre objectif
est d'utiliser la caméra intégrée sur les téléphones mobiles pour lire et
décoder des codes à barres sur l'appareil, sans communiquer avec un
serveur. Cependant, le projet peut être utilisé pour coder et décoder
des codes à barres sur les ordinateurs de bureau et serveurs ainsi. Nous supportons
actuellement les formats suivants:
 UPC-A and UPC-E  Code 93

 EAN-8 and EAN-13  Code 128
 Codabar  Data Matrix
 RSS-14 (all variants)  Aztec ('beta' quality)
 QR Code  PDF 417 ('alpha' quality)
36
Techniques - Settat
4. Développement Web
a. La plateforme J2EE
L’application Web J2EE est développée entièrement en
Java et utilise plusieurs Framework, bibliothèques Open-source
dans les différentes parties du projet. Les Framework facilitent la
programmation dans le sens où la standardisation des processus
de programmation rend le code plus lisible et facilement
interprétable lors d’´éventuelles modifications. Toutes les évolutions du projet Déchèterie
ont été réalisées sous l’environnement de développement Eclipse. Ensuite divers Framework
tels que AppFuse 2, St ruts 2, Spring et Hibernante ont Base de données Microsoft SQL
Server 2005. Une présentation des différents outils est Faite ci-après.
2. Méthodologie de développement : la démarche MVC

Architecture 3-tier et mise en place du modèle MVC
Une application web possède souvent une architecture 3-tier :
 la couche dao s'occupe de l'accès aux données, le plus souvent des données
persistantes au sein d'un SGBD.
 la couche métier implémente les algorithmes " métier " de l'application. Cette couche
est indépendante de toute forme d'interface avec l'utilisateur. Ainsi elle doit être
utilisable aussi bien avec une interface console, une interface web, une interface de
client riche. Elle doit ainsi pouvoir être testée en-dehors de l'interface web et
notamment avec une interface console. C'est généralement la couche la plus stable
de l'architecture. Elle ne change pas si on change l'interface utilisateur ou la façon
d'accéder aux données nécessaires au fonctionnement de l'application.
 la couche interface utilisateur qui est l'interface (graphique souvent) qui permet à
l'utilisateur de piloter l'application et d'en recevoir des informations.
Les couches métier et dao sont normalement utilisées via des interfaces Java. Ainsi la
couche métier ne connaît de la couche dao que son ou ses interfaces et ne connaît pas les
classes les implémentant. C'est ce qui assure l'indépendance des couches entre-elles :
changer l'implémentation de la couche dao n'a aucune incidence sur la couche métier tant
qu'on ne touche pas à la définition de l'interface de la couche dao. Il en est de même entre
les couches interface utilisateur et métier.
L'architecture MVC prend place dans la couche interface utilisateur lorsque celle-ci est une
interface web.
37
Techniques - Settat
Figure 16 : L'architecture MVC
Le traitement d'une demande d'un client se déroule selon les étapes suivantes :
1. Le client fait une demande au contrôleur. Celui-ci voit passer toutes les demandes
des clients. C'est la porte d'entrée de l'application. C'est le C de MVC.
2. Le contrôleur C traite cette demande. Pour ce faire, il peut avoir besoin de l'aide de la
couche métier. Une fois la demande du client traitée, celle-ci peut appeler diverses
réponses. Un exemple classique est :
 une page d'erreurs si la demande n'a pu être traitée correctement
 une page de confirmation.
3. Le contrôleur choisit la réponse (une vue) à envoyer au client. Choisir la réponse à

envoyer au client nécessite plusieurs étapes:
 choisir l'objet qui va générer la réponse. C'est ce qu'on appelle la vue V, le V
de MVC. Ce choix dépend en général du résultat de l'exécution de l'action
demandée par l'utilisateur.
 lui fournir les données dont il a besoin pour générer cette réponse. En effet,
celle-ci contient le plus souvent des informations calculées par le contrôleur.
Ces informations forment ce qu'on appelle le modèle M de la vue, le M de
MVC. L'étape 3 consiste donc en le choix d'une vue V et en la construction du
modèle M nécessaire à celle-ci.
4. Le contrôleur C demande à la vue choisie de s'afficher. Il s'agit le plus souvent de faire

exécuter une méthode particulière de la vue V chargée de générer la réponse au client.
5. Le générateur de vue V utilise le modèle M préparé par le contrôleur C pour initialiser
les parties dynamiques de la réponse qu'il doit envoyer au client. 6. la réponse est
envoyée au client. La forme exacte de celle-ci dépend du générateur de vue. Ce peut être
un flux HTML, PDF, Excel... Dans notre application, et pour plus de simplicité, la couche
métier est intégrée au générateur de vue.
38
Techniques - Settat
3. La plateforme de présentation Strusts
Apache Struts 2 est un élégant et extensible Framework pour la création
d’applications web Java. Le Framework a été conçu pour rationaliser le cycle complet de
développement d’une application : de la construction puis du déploiement jusqu'à la
maintenance. Pour atteindre cet objectif, Struts 2 fournit différentes caractéristiques pour
réduire la configuration XML, utiliser des annotations et des conventions sur la
configuration.
D’un plus haut niveau, Struts 2 est un Framework implémentant le patron de

conception « MVC 2 » (Modèle – Vue Contrôleur). Ce patron est légèrement différent du
design pattern classique MVC dans le sens o`u les actions prennent le rôle de modèle plutôt
que de contrôleur. MVC 2 est réalisé avec 5 composants noyaux :
– Les actions
– Les intercepteurs
– La pile de valeurs/OGNL
– Les types de résultat
– Les vues technologiques/ résultat
Le schéma 7 à la page 17 montre les composants principaux du patron de conception

MVC 2 dans l’architecture haut niveau de MVC. Le contrôleur est implémenté avec un
ensemble de filtres d’expédition tout comme les intercepteurs, le modèle est implémenté
avec des actions et la vue comme une combinaison de types de résultat et de r´ résultat. La
pile de valeurs et OGNL fournissent un processus commun, liant et activant l’intégration
entre tous les composants.
Les actions doivent implémenter l’interface Action. Elles héritent ainsi de méthodes
permettant l’accès aux propriétés et méthodes du modèle pour retourner des chaînes de
caractères (String). Ces « String » sont liées avec les noms « résult définies dans le fichier de
configuration struts.xml. Les actions ont typiquement une seule méthode
« execute() » permettant d’effectuer les traitements sur la vue. Struts 2 utilise aussi
Figure 17 : Schéma du framework Struts 2
39
Techniques - Settat
Les intercepteurs pour intercepter les traitements de requêtes et de réponses des pages
Web. Les intercepteurs ressemblent `a des filtres de servlet à l’exception que l’on peut
communiquer directement avec les actions.
4. La plateforme de mapping Objet/Relationnel HIBERNAT
Hibernate est un framework open source gérant la

persistance des objets en base de données relationnelle.
Hibernate est adaptable en termes d'architecture, il
peut donc être utilisé aussi bien dans un développement
client lourd, que dans un environnement web léger de type
Apache Tomcat ou dans un environnement J2EE complet :
WebSphere, JBoss Application Server et Oracle WebLogic
Server.
Hibernate apporte une solution aux problèmes
d'adaptation entre le paradigme objet et les SGBD en
remplaçant les accès à la base de données par des appels à
des méthodes objet de haut niveau.
Figure 18 : Schéma du framework HIBERNAT
5. La technologie Ajax
Cette technologie, basée essentiellement sur le JavaScript, permet
d’accéder de manière asynchrone avec les actions de l’utilisateur à la
base de données et c’en utilisant en plus du JavaScript, une classe
XMLHTTPREQUEST, qui comporte des méthodes permettant de
communiquer avec le serveur, offrant ainsi à l’utilisateur une réponse
rapide et instantanée.
6. QR-Code
Le QRCode est un code barre à 2 dimensions sous licence libre qui permet de stocker des
informations numériques (textes, adresses de site web, etc.). Il peut-être déchiffré à partir
d'un téléphone mobile équipé d'un appareil photo et du lecteur approprié. Imprimé sur un
support ou placé dans l'environnement urbain, il permet de relier l'espace physique et
l'espace numérique.
Le QRCode permettant de déclencher facilement des actions comme :
 naviguer vers un site internet, ou mettre l’adresse d’un site en marque-page;

 faire un paiement direct via son cellulaire (Europe et Asie principalement);
 ajouter une carte de visite virtuelle (vCard, MeCard) dans les contacts, ou un événement
(iCalendar) dans l’agenda électronique;
 déclencher un appel vers un numéro de téléphone ou envoyer un SMS;
 montrer un point géographique sur Google Maps ou Bing Maps;
40
Techniques - Settat
3. OUTILS DE DÉVELOPPEMENT
1. Environnement de développement Intégré : Eclipse
Eclipse est un projet de la Fondation Eclipse visant à développer tout un
environnement de développement libre, extensible, universel et polyvalent.
Son objectif est de produire et fournir divers outils gravitant autour
de la réalisation de logiciel, englobant les activités de codage logiciel
proprement dites (avec notamment un environnement de
développement intégré) mais aussi de modélisation, de conception,
de test, de reporting, etc. Son environnement de
développement notamment vise à la généricité pour lui permettre de
supporter n'importe quel langage de programmation.
Le projet Eclipse est pour cela organisé en un ensemble cohérent de
projets logiciels distincts, sa spécificité tenant à son architecture totalement développée
autour de la notion de plugin (en conformité avec la norme OSGi) : toutes les fonctionnalités
de l'atelier logiciel doivent être développées en tant queplug-in bâti autour de l'IDE Eclipse
Platform.
Eclipse recouvre donc notamment également à cet effet tout un Framework de
développement logiciel fournissant des briques logicielles à partir desquelles développer
tous ces outils. C'est la raison pour laquelle Eclipse est présenté dans la littérature tout
autant comme un EDI ou comme un Framework.
2. Le serveur d’application Appache Tomcat

Apache TomCat est un conteneur de servlet J2EE. Issu du projet Jakarta,
TomCat est désormais un projet principal de la fondation Apache. Il
implémente les spécifications des servlets et des JSP de Sun
Microsystems. Il inclut des outils pour la configuration et la gestion, mais
peut également être configuré en éditant des fichiers de configuration
XML. Comme TomCat inclut aussi un serveur HTTP interne.
3. Le serveur de base de données MySQL

MySQL est un serveur de bases de données relationnelles SQL
développé dans un souci de performances élevées en lecture, ce
qui signifie qu'il est davantage orienté vers le service de données
déjà en place que vers celui de mises à jour fréquentes et
fortement sécurisées. Il est multi-thread et multi-utilisateur.
41
Techniques - Settat
4. Entreprise Architect
Sparx Systems Enterprise Architect est un outil de
modélisation visuelle et de conception basée sur l'UML OMG. La
plate-forme prend en charge: la conception et la construction de
systèmes logiciels, les processus opérationnels de modélisation,
et de l'industrie de modélisation basée sur des domaines. Il est
utilisé par les entreprises et les organisations de ne pas le
modèle que l'architecture de leurs systèmes, mais de traiter la
mise en œuvre de ces modèles à travers le développement d'applications cycle de vie
complet.
5. Le gestionnaire de version SVN

a. Le serveur de version VisualSVN
Subversion pour Windows. Il offre un système de
contrôle de version Subversion réglée spécifiquement pour
l'environnement Windows. VisualSVN Server est un produit
autonome et fonctionne hors de la boîte. La version payante de
VisualSVN Server offre une intégration supplémentaire dans
l'environnement Active Directory.
2. Le client TurtoiseSVN
TortoiseSVN est un des logiciels client de SVN les plus populaires1.
C'est un logiciel libre distribué selon les termes de la licence GNU GPL.
En s'intégrant dans l'explorateur de Windows, il offre aux utilisateurs
de Windows une interface graphique permettant de réaliser la plupart
des tâches qu'offre SVN en ligne de commande.
L'explorateur Windows s'enrichit des fonctionnalités suivantes :
 Superposition d'icône aux répertoires et fichiers permettant de visualiser instantanément

l'état (à jour, modifié, en conflit...)
 Menu contextuel permettant de committer ou d'updater, à l'échelle d'un fichier, d'une
sélection de fichiers ou encore d'un répertoire.
 Possibilité d'ajouter en mode détails de l'explorateur des colonnes de type numéro de
révision, état
Il est disponible en version 32 et 64 bits. 34 packs langues sont actuellement en ligne.
42
Techniques - Settat
4. ECRANS
1. Réalisation Web
Figure 19 : Page de recherche(les résultats ce forme de carte de visite)
43
Techniques - Settat
Figure 20 : Code à barre a deux dimensions du LAFARGE (Après la clique sur une carte).
44
Techniques - Settat
Figure 21 : Détail d'une carte de visite
Figure 22 : Formulaire d'inscription au site web.
45
Techniques - Settat
Figure 23 : Formulaire d'autentification
Figure 24 : Formulaire de création d'une carte de visite
46
Techniques - Settat
2. Réalisation Mobile
Figure 25 : Activité d'accueil
Figure 26 : Activité de recherche Catégories & Cartes de visite(onglet Cétgories)
47
Techniques - Settat
Figure 27 : Activité de recherche Catégories & Cartes de visite (onglet Cartes de visite)
Figure 28 : Menu Contextuel du catégorie "Développeurs Mobile"
48
Techniques - Settat
Figure 29 : Liste des cartes de visite (après la clique sur Liste des Cartes de visite)
Figure 30 : Menu contextuel du contact "Mobile Application"
49
Techniques - Settat
Figure 31 : Activité détails carte de visite du contact "Mobile Application"
50
Techniques - Settat
Figure 32 : La liste déroulante de categories
51
Techniques - Settat
Figure 33 : Menu de l'activité détails cartes de visites
52
Techniques - Settat
Figure 34 : Activité d'appel après la clique sur l'icône d'appel.
Figure 35 : Menu contextuel des différents applications

de messagerie installé sur le smarte phone
53
Techniques - Settat
Figure 36 : Menu contextuel de partage avec la liste des différents

application de partage installé sur le smarte phone.
CONCLUSION
L’activité d’implémentation était la plus délicate dans le développement de notre
système. Enfin, nous nous intéressons à tester l’application en réseau.
54
Techniques - Settat
CONCLUSION GENERALE
Ce projet avait pour objectif la réalisation d’une application
SmartBusinessCard permettant de rechercher et de gérer plus facilement nos
contacts professionnels.
Cette période du PFE nous a permis d’approfondir nos connaissances

théoriques acquises le long de notre formation par la pratique des nouvelles
technologies.
Cette expérience nous a permis de maîtriser la plateforme J2EE,

Hibernate, le langage de modélisation UML, les outils de développement
Android à savoir le SDK Android, et l’intégration de la technologie QRCode où le
développement n’a pas été une tâche facile.
Ce travail nous a donné l’opportunité de s’initier à la vie professionnelle,

et de travailler sérieusement pour atteindre un bon résultat.
Enfin, notre projet ne va pas se limiter à cette étape, nous voudrions

encore améliorer notre application afin que les interfaces soient plus
ergonomiques et diminuent le temps de réponse.
55
Techniques - Settat
BIBLIOGRAPHIE
Ouvrages :
Programmation Android de la conception au déploiement avec le SDK

Google Android
Auteurs : Damien Guignard, Julien Chable, Emmanuel Robles.
Edition : Eyrolls.
Formations Interactive :
Devenez un développeur Android VOL1.

Auteurs : Emmanuel Robles, Nicolas Sorel
Lynda - Android App Development with Java Essential Training.

Auteur Lee Brimelow : Emmanuel Robles, Nicolas Sorel
Références Netographiques :
[1] : http://www.developpez.com [En ligne].

[2] : http://www.wikipedia.com [En ligne].
[3] : http://www.siteduzero.com/ [En ligne].
[4] : Encyclopédie en ligne « comment ça marche » [En ligne].
http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3
[5] : Portail des développeurs Android [En ligne].
http://developer.android.com/
[6] : Référence du SDK Android[En ligne].
http://developer.android.com/sdk/ndk/1.5_r1/index.htm
[7] : Zxing [En ligne].
http://code.google.com/p/zxing/
[8] : http://www.androidhive.info/2012/01/android-login-and-registration-with-php-mysql-
and-sqlite/
56

Rapport Pfe Mobile

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Pfe Mobile

Transféré par

Droits d'auteur :

Formats disponibles

Faculté des Sciences et

Nous tenons, tout d’abord, à exprimer nos sincères gratitudes envers

Nous remercions aussi Mr. Mounir MAHFOUD responsable formation et

Nous remercions également Mr. EL ALAMI Semma directeur de centre

Nous associons à ces remerciements tous les enseignants qui ont

LISTE DES ABRÉVIATIONS............................................................................................................................... 6

CHAPITRE-1: CADRE GENERAL........................................................................................................................ 8

I. PRESENTATION DU CADRE DU PROJET........................................................................................................9

CHAPITRE-2 : CAPTURE DES BESOINS........................................................................................................... 18

I. IDENTIFICATION DES ACTEURS................................................................................................................19

CHAPITRE-3 : ANALYSE & CONCEPTION........................................................................................................ 25

I. DIAGRAMMES DE CAS D’UTILISATION.....................................................................................................26

LISTE DES ABRÉVIATIONS

Comme nous vivons dans un monde où le marché informatique se développe très

Nous avons divisé cette solution en 2 parties :

Dans ce contexte, nous allons procéder comme suit :

Chapitre1 : Cadre Général

Chapitre2 : Capture des besoins

Chapitre3 : Analyse et conception

CHAPITRE-1: CADRE GENERAL

I. PRESENTATION DU CADRE DU PROJET

 enregistrer les informations présentes sur la carte en créant un nouveau contact,

2. Présentation de la solution SmartBusinessCard

Networking : l’application web permettra aux utilisateurs anonymes de :

Business l’application web permettra aux clients de :

4. Le projet Mobile (Gestionnaire de cartes de visite)

Organising : l’application mobile(ou bien le porte-carte de cartes de visites) permet

2. GESTION DU PROJET INFORMATIQUE

Le cycle de vie du logiciel comprend généralement au minimum les étapes suivantes :

 Définition des objectives:

 Analyse des besoins et faisabilité:

C’est-à-dire l’expression, le recueil et la formalisation des besoins du demandeur (le client)

 Spécifications ou conception générale:

Il s’agit de l’élaboration des spécifications de l’architecture générale du logiciel.

Cette étape consiste à définir précisément chaque sous-ensemble du logiciel.

 Codage (Implémentation ou programmation):

C’est la traduction dans un langage de programmation des fonctionnalités définies lors de

Ils permettent de vérifier individuellement que chaque sous-ensemble du logiciel est

 Qualification (ou recette) :

C’est-à-dire la vérification de la conformité du logiciel aux spécifications initiales,

C’est le déploiement sur site du logiciel.

Elle comprend toutes les actions correctives (maintenance corrective) et évolutives

6. Modèle de cycle de vie d’un logiciel

Figure 1 : Modèle du cycle de vie en cascade

Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été

2. Modèle de cycle de vie en V

Figure 2 : Modèle du cycle de vie en V

Le principe de ce modèle est qu’avec toute décomposition doit être décrite la

La représentation en V tient d'avantage compte de la réalité, le processus de

Figure 3 : Planing du projet

Merise se positionne comme une méthode de conception de SI organisationnel, plus

UML est idéal pour :

Ainsi, la méthodologie de conception adoptée se base sur le choix de diagrammes UML

Figure 4 : Methodologies de conception adoptee

I. IDENTIFICATION DES ACTEURS

2. LES BESOINS FONCTIONNELS

 Chercher les cartes visites par des critères,

 Scanner le QR d’une carte visite,

3. BESOINS NON FONCTIONNELS

 Limitation de la dimension de l'écran : choisir un minimum de composants

2. Contrainte non ergonomique

4. DIAGRAMMES DE CAS D’UTILISATION GENERALE

Rechercher Carte Visite PartageCarteVisite