Memoire Fin D EtudeXX

Remerciements
Nous sommes trs reconnaissants envers tous ceux qui, par leurs
Comptences scientifiques et leurs qualits humaines, ont contribu au bon
droulement de ce mmoire.
Nous exprimons toute notre reconnaissance Dr.Benlalla Nabil, davoir bien
voulu me faire lhonneur de prsider le jury de ce mmoire.
Nous tenons remercier tout dabord Mr. Chaouche, pour ses valeureux conseils
et pour la confiance et la sympathie quil nous
a accorde en acceptant de nous encadrer et quil nous a tmoigne au cours de ce
projet de Fin dtudes.
Nous tenons aussi exprimer notre profonde reconnaissance tous mes
collgues, mes parents... Pour ses conseils, ses commentaires prcieux et le suivi
de ce travail.
Remerciements
Nous sommes trs reconnaissants envers tous ceux qui, par leurs
comptences scientifiques et leurs qualits humaines, ont contribu au bon
droulement de ce mmoire.
Nous exprimons toute notre reconnaissance Dr,Benlalla davoir bien voulu me
faire lhonneur de prsider le jury de ce mmoire.
Nous tenons remercier tout dabord Mr.Chaouch ,pour ses valeureux conseils et
pour la confiance et la sympathie quil nous
a accorde en acceptant de nous encadrer et quil nous a tmoigne au cours de ce
projet de Fin dtudes.
Nous tenons aussi exprimer notre profonde reconnaissance tout mes collgues
pour ses conseils, ses commentaires prcieux et le suivi de ce travail.
Rapport de Fin dEtude
Rsum
Les autoroutes daujourdhui seront gres de manire plus intelligente et
dynamique, sur lesquelles il y aurait, non seulement, moins de risques
daccident, mais aussi, une assistance temps-rel des conducteurs.
Le but de ce projet est de raliser une application mobile native pour systme
Android, dont l'IHM est reprsente par une carte gographique interactive. Il
s'agit de dvelopper un systme coopratif pour assister les voyageurs et les
guider tout au long de leur voyage afin de rendre celui-ci le plus convivial
possible. Afin dassurer la communication temps-rel et la persistance des
donnes, le systme devrait fonctionner dynamiquement en se basant sur un
serveur distant (par exemple, le centre dinfrastructure routire). Ceci rendra les
vhicules, travers notre application, sensibles leur contexte changeant.
Sommaire
1. Chapitre 1 : Introduction gnral ..........................................................................09
2. Chapitre 2 : Contexte du projet .............................................................................12
2.1. Caractristiques des autoroutes ....................................................................................13

2.2. Le besoin dintgrer linformatique dans les autoroutes pour une conduite sre....15
2.3. Exploitation des nouvelles technologies mobiles pour assister le conducteur ....15
3. Chapitre 3 : Notions prliminaires .....17
3.1. Processus de dveloppement et langage de modlisation 18

3.1.1. Approche Oriente Objet .........18
3.1.2. Langage de modlisation UML ..20
3.1.3. Processus de dveloppement choisi .....25
3.1.4. Modlisation dun projet Androde avec UML 29
3.2. Programmation mobile .....29

3.2.1. Caractristiques des systmes mobiles 29
3.2.2. Systmes dexploitation mobiles (comparaison) ....30
3.2.3. Comparaison par rapport la programmation classique Web ou Desktop .33
3.2.4. Choix de la plateforme mobile (Androde) ....34
3.3. Programmation mobile sous Androde ...34

3.3.1. Architecture et versions dAndrode ..35
3.3.2. Structure dun projet Androde . 35
3.3.3. Excution sur des Appareils et sur lmulateur ..45
4. Chapitre 4 : Conception du projet .46
4.1. Etude Prliminaire 47

4.1.1. Prsentation du projet raliser ..47
4.1.2. Recueil des besoins fonctionnels ....47
4.1.3. Identification des acteurs .47
4.1.4. Modlisation du contexte & identification des messages ..47
4.2. Capture des besoins fonctionnels ..48

4.2.1 Identification des cas dutilisations .48
4.2.2 Diagramme complet de cas dutilisations ...48
4.2.3 Description dtaille des cas dutilisations .49
4.2.4 Structuration des cas dutilisations dans des packages ...51
4.3. Analyse 57
4.3.1. Diagrammes de classes utilises dans chaque cas dutilisation ..57
4.3.2. Diagrammes de classes compltes ..60
4.3.3. Attributs et mthodes de chaque classe ..60
5. Chapitre 5 : Implmentation du projet ....
5.1.Plateforme matrielle .00
5.2. Plateforme logicielle ....00

5.3. Prsentation de lapplication ..00
6. Chapitre 6 : Exprimentation .00
6.1. Captures dcrans des activits .00

6.2. Navigabilit de lapplication entre les activits..00
7. Chapitre 7 : Conclusion gnrale......00
Bibliothque ..00
LISTE DES FIGURES

Figure 1.
Les activits dUP 27
Figure 2
Les parts de march des systmes d'exploitation mobile

pour les annes 2011 et 2014... 33
Figure 3.
La part de chaque version d'Android.. 36
Figure 4.
Architecture logiciel de landroide.. 37
Figure 5.
Composition dune application androde 43
Figure 6.
Architecture MVC 44
Figure 7.
Diagramme de contexte statique 48
Figure 8.
Diagramme de cas dutilisation.. 49
Figure 9.
Diagramme de squence de cas Go localiser .. 52
Figure 10.
Diagramme dActiviez de cas Go localiser . 52
Figure 11.
Diagramme de squence de cas Naviguer sur la carte .. 53
Figure 12.
Diagramme dactive de cas Naviguer sur la carte. 53
Figure 13 Diagramme de squence de cas Trouver des stations et des services ..54
Figure 14. Diagramme dactivit de cas Trouver des stations et des services 54
Figure 15. Diagramme de squence de cas Signaler des alertes .. 55
Figure 16. Diagramme de squence de cas Signaler des alertes ... 56
Figure 17. Diagramme de class de cas Go localiser 57
Figure 18. Diagramme de class de cas Naviguer sur la cartes .. 57
Figure 19. Diagramme de class de cas Trouver des stations et des services 58
Figure 20. Diagramme de class de cas Signaler des alertes. 58
Figure 21. Diagramme de class de cas associer des informations aux alertes .. 59
Figure 22 Diagramme de class de cas Elaborer des chemins possibles . 59
Figure 23. Diagramme de class complet 60
Liste des tableaux

Tableau 1. Une comparaison entre les systmes dexploitation mobile.. 32
Tableau 2. Les versions de lAndroid. 35
Tableau 3. Cas dutilisation Geo localiser.. 49
Tableau 4. Cas dutilisation Naviguer sur la carte 50
Tableau 5. Cas dutilisation Trouver des stations et des services.. 50
Tableau 6. Cas dutilisation Signaler des alertes 51
LISTE DES ABREVIATIONS
WAP:Wireless Application Protocol

UMTS:Universal Mobile Telecommunications System
HSDPA:High Speed, Downlink Packet Access
LTE:Long Team Evolution
WIMAX:Worldwide Interoperability for Microwave Access
GPS:Global Positioning System
OS: Operating System
IOS: Internetwork Operating System
RIM: Research In Motion
VB: Visual Basic
IDC: International Data Corporation
OHA: Open Handset Alliance
SDK: Software Development Toolkit
API: Application Program Interface
AVD: Android Visual Device
HTML: Hypertext Markup Language
HTTPS: Hypertext Transfer Protocol Secured
HTTP: Hypertext Transfer Protocol
XML:eXtensible Markup Language
SGML: Standard Generalized Markup Language
SGBD:SystemManagementDatabases
Chapitre 1 : Introduction gnrale
Page 9
Introduction gnrale
"Les mobiles sont aussi diffrents de l'internet que la tl l'a t de la radio", a

annonc -Tomi Ahonen-, meilleur auteur technologique et mdiatique succs,
consultant de stratgie et orateur motivationnel.
Les tlphones portables sont devenus les premiers mdias de masse dans le
monde (on compte 6,8 milliards d'abonns au tlphone mobile). Il n'est pas un
PC plus bte, mais un tlphone portable est considr comme un autre support
gnrer des formes mdiatiques.
Il a subit une volution une vitesse surprenante, passant du premier tlphone
portable invent par Dr Martin Cooper -un directeur gnral de Motorola- en
1973 qui a t la premire personne faire un appel depuis son tlphone
portable, aux ordiphones, PDA et Smartphones qui disposent d'un systme
d'exploitation adoptant des applications tierces qui leur sont ddies.
L'invention du premier PDA au monde, Le PenPad conu par Apple, tait dans
le but de pouvoir prendre des notes, grer son agenda, ses adresses, effectuer des
calculs, etc, sans avoir s'encombrer d'un ordinateur portable ou d'un bloc notes.
Aujourd'hui ces priphriques ont atteint une puissance de calcul, une taille
mmoire ainsi qu'un dbit ncessaire pour faire tourner des applications aussi
diverses que varies qui vont de l'Outlook mobile jusqu'aux applications de
navigation GPS.
Les plates-formes de distribution de ces applications sont en plein essor,
Windows Phone 7 son magasin d'applications, l'iPhone l'App Store, Android
son Market, etc.
Ce qui ne cesse d'inciter beaucoup de dveloppeurs l'laboration des petits
logiciels trs priss en profitant des multiples apports des plateformes prsentes
sur le march et des diverses innovations technologiques (Wifi, GPS, GPRS,
3G, 4G etc.).
En effet, la go localisation du GPS des tlphones intelligents >> est trs utile
aux applications comme les annuaires, portails et autres outils permettant de
trouver ce que l'on cherche autour d'un lieu, rpondant par la fin aux besoins
quotidiens de la communaut.
Page 10
C'est dans ce cadre que s'inscrit notre projet de fin d'tude, intitul
DreamWay >> dont l'objectif est de concevoir une application ddie au
tlphone mobile, dot de la plateforme Android, permettant au assurs la go
localisation de nos autoroutes Est-Ouest, signaler et positionner des alertes et
des marqueurs et les associer des informations ,laborer des chemins possibles ,
proposer une navigation et raliser la persistance des donnes laide dun
serveur distantetc.
Le travail effectu a fait lobjet de sept chapitres. Le premier chapitre prsente
une introduction gnrale. Le deuxime chapitre prsente les contextes du
projet. Le troisime chapitre dtaille les notions prliminaires. Le quatrime
chapitre porte sur la conception du projet. Le cinquime chapitre prsente
limplmentation du projet. Le sixime chapitre est une exprimentation pour le
projet et le dernier chapitre une conclusion gnrale, nous prsentons une
synthse ainsi que les perspectives en raison damliorer les performances de
lapplication.
Page 11
Chapitre 2 : Contexte du projet
Page 12
2.1. Caractristiques de lautoroute est-ouest :

Historique:
Le projet d'autoroute reliant les grandes villes du nord est envisag ds
les annes 1970 par le ministre du plan. Par la suite, les diffrents
schmas directeurs routiers nationaux (1975-1995 et 1995-2015) vont
l'inclure dans leurs projections.
Les tudes prliminaires ont t ralises en 1983. Elles ont port sur
le choix du couloir du trac, les prvisions du trafic, lvolution des
indicateurs conomiques et les diffrentes incidences du projet, elles
ont donn lieu, au cours de leur ralisation, de nombreuses
concertations et ont abouti au choix du couloir, approuv en Conseil
des Ministres au mois de juin 1987.
Les tudes davant projet sommaires (APS) sur environ 1 100 km entre
Annaba et Tlemcen ont t engages en 1988 et termines en 19943.
Annes 1990, financement compliqu:
Le financement du projet par les pouvoirs publics dans un contexte
d'endettement est trs compliqu. Durant les annes 1990 et 2000, les
premiers tronons sont financs par des prts europens, arabes et
africains dans le cadre du dveloppement.
Le 18 juin 1990, la Banque Europenne d'investissement (BEI)
accorde un prt de 40 millions d' pour un premier tronon de 30 km
entre Blida et El Affroun4. Un an plus tard en 1991, la mme
institution prte 31 millions d' pour le contournement de la ville de
Bouira5. En 1993 et 1994, c'est un total de 100 millions d' qui sont
dbloqus pour le tronon Lakhdaria - Bouira6. De nouveau 140
millions d' en 20007 et 70 millions d' en 20028 sont investis pour
terminer ces deux tronons est et ouest d'un total 80 km. Leur
ralisation par des entreprises algriennes ne sera acheve qu'entre
2004 et 2006.
Le 3 octobre 1995, un nouveau tronon de 30 km entre El Affroun
(Blida) et Hoceinia (Ain Defla) est dclar d'utilit public et une
enveloppe de 266 millions de dinars est dgage pour les
expropriations9. Ce n'est qu'en 2002 que le Fond Arabe pour le
Dveloppement Economique et Social (FADES) accorde un prt de 86
Page 13
millions de $, qui ne sera consomm qu' 30% pour sa

ralisation10,11.
Entre 1996 et 2002, la Banque Africaine de Dveloppement (BAD) a
accord un prt de 161 millions de $ pour le tronon de contournement
de la ville de Constantine sur 29 km entre Ain Smara et El
Meridj12,13,14. Seil un premier tronon de 15 km sera achev en
2004.
2005, financement public:
Avec le retour des quilibres et la bonne sant des finances publiques,
le prsident Abdelaziz Bouteflika dcide en fvrier 2005, prs d'un an
aprs sa rlection de financer l'intgralit des tronons restants par le
trsor public, contre l'avis de son ministre des finances15.
Le 25 juillet 2005, un dcret excutif est publi pour dclarer d'utilit
publique l'opration portant ralisation de lautoroute Est-Ouest sur
l'ensemble de son trac16.
Lancement et attribution:
L'appel d'offres international limit, sur la base d'un cahier des charges
prcis, pour le projet de l'autoroute Est-Ouest fut lanc le 23 juillet
2005. Plusieurs rponses furent enregistres (amricaine, franaise,
allemande et portugaise). C'est finalement deux consortiums qui ont
t slectionns : le chinois CITIC-CRCC et le japonais COJAAL. Les
rsultats furent annoncs le 15 avril 2006 et les contrats de ralisation
signs le 18 septembre 2006.
Bureaux d'tudes:
Les missions de contrle et de suivi du projet est passe par un autre
appel d'offres qui a vu la slection :
du bureau d'tudes canadien "Dessau Soprane" pour le contrle et le
suivi
du bureau d'tudes franais "EGIS-ROUTE" pour la tranche ouest
du bureau d'tudes canadien "SNC LAVALIN" pour la tranche centre
du groupement italien "ANAS ITALCONSULT" pour la tranche est.
Chronologie :
Si le projet de l'Autoroute Est-Ouest a dmarr en 2006, plusieurs
tronons existaient dj. Les nouveaux tronons ont commenc tre
livrs petit petit depuis 2008.
Page 14
Les tronons Ouest et Centre, raliss par le groupement chinois

CITIC-CRCC, ont t livrs la circulation, mais les travaux ne seront
pas achevs avant 2016 sur la section Est, raliss par le groupement
japonais Cojaal. Des problmes techniques ainsi que l'incapacit de
Cojaal raliser ce type d'infrastructures pourraient expliquer ce
retard. Un scandale de corruption avait dj clabouss le projet en
2010 et la qualit des travaux raliss par CITIC-CRCC ne serait pas
conforme aux normes internationales et des travaux de rfection ont
dj t ncessaires17.
2.2. Le besoin dintgrer linformatique

autoroutes pour une conduite sre :
dans
les
Maintenant et plus tard, plus que fois nous coutons et voyons soit sur le
tlvision ou sur le Web beaucoup des journaux quils parlons des accidents et
ses consquences dans nos autoroutes et les nombres risqus de les victimes
..etc. Et ce dernier nous laisse penser de trouver des solutions efficaces, et de ces
solutions : le besoins dintgrer linformatique dans nos voitures pour une
conduite sre
Non seulement, moins de risques daccident, mais aussi, une assistance tempsrel des conducteurs.
2. 3.
Exploitation des nouvelles technologies mobiles
pour assister les conducteurs :
Le dveloppement de notre application est ralis sous Android. Nous
permettrons dacqurir les composants fondamentaux servant ce projet.
Lautoroute Est-Ouest tant considre comme lautoroute o sera dploy le
systme, une carte dtaille de cette autoroute sera labore sous
OpenStreetCarte (Base de donne gographique open source).Pour des raisons
daffichage efficace et dinteractivit de lapplication, une bibliothque Android
spcialise devra tre utilise pour exploiter la carte pralablement labore.
Lapplication dvelopper sera fonde sur diffrentes capacits en liens avec
une carte :
Dplacer ou zoomer le fond de carte sur des espaces (routes, aires de
services, borne dappel durgence, .)
Page 15
Signaler et positionner des alertes et des marqueurs (accidents, pannes,

bouchons, )
Associer des informations aux alertes : la nature de lalerte, linstant de
son signalement,
Elaborer des chemins possibles et proposer une navigation base sur la
go localisation .etc.
Page 16
Chapitre 3 : Notions prliminaires
Page 17
3.1.
Processus de dveloppement et langage de
modlisation
3.1.1. Approche Oriente Objet :
Lapproche oriente objet est une nouvelle mthode de programmation qui
tend se rapprocher de notre manire naturelle dapprhender le monde. Elle
propose une mthodologie centre sur les donnes c'est--dire, elle s'intresse
d'abord aux donnes, auxquelles elle associe ensuite les traitements. Elle peut
tre rsum par la question Sur quoi porte le programme ?"
Remarque : Les frontires entre ces deux paradigmes ne sont pas toujours
franches pour un langage
de programmation donn. Par exemple, Java est un langage orient objet
mais le corps des fonctions
ou procdures est bien dcrit imprativement.
3.1.1.1. POURQUOI LA PROGRAMMATION ORIENTE

OBJET ?
Depuis plusieurs annes :
Le dveloppement dapplications de plus en plus performantes et
complexes
En programmation procdurale : cot du logiciel croit de manire
exponentielle avec la
complexit de lapplication
3.1.1.2. Objectifs de la programmation oriente objet :

+ Diminuer le cot du logiciel
+ Augmenter sa dure de vie
+ Augmenter sa rutilisabilit
+ Assurer sa facilit de maintenance
3.1.1.3. QUEST CE QUE LA PROGRAMMATION

ORIENTE OBJET (POO)?
Programmation Oriente Objet (POO) : paradigme de programmation
informatique
Page 18
+ labor par Alan Kay, dans les annes 70

+ bas sur la dfinition et interactions de briques logicielles : objets
3.1.1.4. CONCETPS DE BASE

1. Objet :
Un objet est un concept, une ide ou une entit du monde physique
Exemple : voiture, personne, tudiant, animal, fentre graphique, forme
gomtrique, ...
Remarque : Dans un programme, un objet sapparente une variable
2. Classe
Une classe dcrit des schmas dobjets. Du point de vue typage, une classe est
vue comme le type des
objets qui seront crs partir delle. Une classe dfinit les variables (par leur
nom et leur type avec
ventuellement une valeur initiale) et les mthodes. Elle sert de modle
pour la cration dobjets.
3. Instanciation
Linstanciation est lopration qui consiste crer un objet partir dune classe
On appelle instance dune classe, un objet avec un comportement et un
tat, tous deux dfinis par sa classe.
4. Notion de constructeur
Un constructeur est une mthode qui permet de crer les objets ou les
instances dune classe.
Un constructeur a le mme nom que la classe.
Un constructeur na pas de valeur de retour (mme pad void ).
Plusieurs constructeurs peuvent exister dans une mme classe (avec des
arguments diffrents), on dit quils sont surchargs.
IL faut au moins un constructeur dans une classe pour en instancier des objets.
Page 19
5. Polymorphisme
Principe
Une sous-classe peut redfinir une mthode hrite de sa super-classe. Cette
redfinition consiste changer le code de la mthode de la super-classe mais pas
sa signature (nom, le type et lordre de ses paramtres et son type de retour).
Elle est dite polymorphe.
Surcharge : Une mme mthode peut avoir plusieurs dclarations diffrentes
dans la mme classe. Cette diffrence concerne le nombre et le type des
arguments (et du retour) qui peuvent varier.
3.1.2.
Langage de modlisation UML
3.1.2.1. Introduction
Dfinition Selon lOMG (Object Management Group: Fond en 1989) :
UML : Langage visuel ddi la spcification, la construction et la
documentation des artefacts dun systme logiciel
UML est un langage de modlisation graphique (et textuelle) conu pour :
comprendre et dcrire des besoins,
spcifier et documenter des systmes,
esquisser des architectures logicielles,
concevoir des solutions et
communiquer des points de vue.
UML unifie la fois les notations et les concepts orients objet. Il unifie
galement les notations ncessaires aux activits des diffrentes tapes dun
processus de dveloppement et sert ainsi comme moyen pour concrtiser le suivi
des dcisions prises depuis lexpression des besoins jusquau codage.
UML possde des outils de gnration automatique de codes (Java, C++, C, )
comme Objecteering, StarUML, RationalRose, etc.
3.1.2.2.Histoire de la modlisation par objets
Les mthodes utilises dans les annes 1980 pour organiser la programmation
imprative (notamment Merise) taient fondes sur la modlisation spare des
donnes et des traitements.
Page 20
Lorsque la programmation par objets prend de limportance au dbut des annes

1990, la ncessit dune mthode qui lui soit adapte devient vidente. En effet,
rien dans les concepts de base de
l'approche ne dicte comment modliser la structure objet d'un systme de
manire pertinente alors que l'application de ces concepts ncessite une trs
grande rigueur.
Plus de cinquante mthodes apparaissent entre 1990 et 1995 (Booch, ClasseRelation, Fusion, HOOD, OMT, OOA, OOD,OOM, OOSE, etc.) mais aucune
ne parvient simposer. A partir de lanne 1994, le consensus se fait autour des
trois mthodes OMTde James Rumbaugh (1991), OOD de GradyBooch(1991)
et OOSE dIvar Jacobson (1992). vnement considrable et presque
miraculeux, les trois gourousqui
rgnaient chacun sur lune des trois mthodes se mirent daccord pour dfinir
une mthode commune qui fdrerait leurs apports respectifs (on les surnomme
depuis the Amigos ). Le langage de modlisation unifi appel UML
(UnifiedModelingLanguage) est n de cet effort de
convergence. Ladjectif unified est l pour marquer quUML unifie, et donc
remplace. Lunification a progress par tapes :
En 1995, Booch et Rumbaugh (et quelques autres) se sont mis daccord pour
construire une mthode unifie, UnifiedMethod 0.8 ;
en 1996, Jacobson les a rejoints pour produire UML 0.9 (remplacement du mot
mthode par le mot langage, plus modeste).
En janvier 1997, UML 1.0 a t soumis lOMG (Object Management Group)
par les acteurs les plus importants dans le monde du logiciel et qui se sont
associs leffort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.).
En novembre 1997, lOMG adopta UML 1.1 (9 diagrammes) comme langage
de modlisation des systmes dinformation objets.
3.1.2.3Nouvelles versions dUML :
De 1997 2003, des modifications/amliorations de la version normalise
(UML 1.1 UML1.5)
En 2005, lOMG a normalis UML 2.0, en dfinissant de nouveaux
diagrammes pour reprsenter des concepts particuliers nouveaux de systmes
dinformation.
Page 21
En 2007, UML 2.1.1: changements importants au niveau du mta-modle,

pour permettre dutiliser UML pour la programmation.
En 2008, UML 2.2
La dernire version diffuse par l'OMG est UML 2.5 en octobre 2012.
3.1.2.4 UML en application
Les auteurs dUML ont dfini un langage graphique qui permet de reprsenter et
de communiquer les divers aspects dun systme dinformation. Aux
graphiques sont associs des textes qui expliquent leur contenu. UML est donc
un mtalangage car il fournit les lments permettant de construire le modle
qui, lui, sera le langage du projet. La notation associe consiste en un ensemble
de diagrammes
(9 diagrammes dans UML 1 et 14 diagrammes dans UML 2) permettant une
modlisation objet selon diffrentes vues complmentaires.
Un diagramme UML est une reprsentation graphique, qui s'intresse un
aspect prcis du modle. C'est une perspective du modle, pas "le modle de
systme".
Chaque type de diagramme UML possde une structure (les types des lments
de modlisation qui le composent sont prdfinis).
Un type de diagramme UML vhicule une smantique prcise (un type de
diagramme offre toujours la mme vue d'un systme).
Combins, les diffrents types de diagrammes UML offrent une vue complte
des aspects statiques et dynamiques d'un systme.
Par extension et abus de langage, un diagramme UML est aussi un modle (un
diagramme modlise un aspect du modle global).
Les 14 diagrammes dUML 2 sont gnralement rpartis en deux catgories
(diagrammes de structure et diagrammes de comportement).
3.1.2.5.Diagrammes de structure (ou structurels):
De classes (class diagram)
D'objets (objectdiagram)
De composants (component diagram)
De structure composite (composite structure diagram)
De dploiement (deploymentdiagram)
De paquetages (package diagram)
Page 22
De profils (profile diagram) diagramme de classe simplifi reprsentant

profiles et classes.
3.1.2.6.Diagrammes de comportement (ou comportementaux):
De cas d'utilisation (use case diagram)
De squence (sequencediagram)
Vue gnrale d'interaction (interaction overviewdiagram) dactivit et de
squence.
De communication ou de collaboration (communication diagram)
De temps (timing diagram) fusionne les diagrammes dtats et de squence.
D'activit (activitydiagram)
D'tats (state diagram)
Dans la littrature plusieurs faons de rpartir les diagrammes UML ont t
proposes bases essentiellement sur diffrentes vues et aspects du systme
Lobjectif de notre cours tant une premire acquisition des concepts de
modlisation travers lutilisation dun langage unifi, nous nous limitons
9principaux diagrammes (dont 7
seront dtaills dans les chapitres suivants)
rpartis sur les trois axes de modlisation : fonctionnel, statique et dynamique
(voir figure 2.1).
Ces diagrammes, dune utilit variable selon les cas loccasion dune
modlisation.
3.1.2.7. Elments et mcanismes gnraux dUML

Les lments sont les briques de base du langage
lments de modlisation: abstractions du systme modliser.
lments de visualisation: projections textuelles ou graphiques permettant la
manipulation des lments de modlisation.
Exemple: acteur: lment de modlisation : lment de visualisation
Des Mcanismes sont dfinis pour faciliter la comprhension et
linterprtation dun diagramme et permettent ainsi dtendre UML.
Strotypes
tiquettes ou valeurs marques
Notes
Contraintes
Page 23
3.1.2.8. Prsentation de 9 Diagrammes UML

Diagramme de cas dutilisation
Le diagramme de cas dutilisation reprsente la structure des grandes
fonctionnalits ncessaires aux utilisateurs du systme. Cest le premier
diagramme du modle UML, celui o sassure la relation entre lutilisateur et les
objets que le systme met en uvre.
.Diagramme de classes
Le diagramme de classes est gnralement considr comme le plus important
dans un dveloppement orient objet. Il reprsente larchitecture conceptuelle du
systme : il dcrit les classes que le systme utilise, ainsi que leurs liens, que
ceux-ci reprsentent un embotement conceptuel (hritage) ou une relation
organique (agrgation).
.Diagramme dobjets
Le diagramme dobjets permet dclairer un diagramme de classes en lillustrant
par des exemples. Il est, par exemple, utilis pour vrifier ladquation dun
diagramme de classes diffrents cas possibles.
.Diagramme de composants
Un diagramme de composants permet de dcrire larchitecture physique et
statique dune application en termes de composants (modules) et de
dpendances entre ces composants.
Les composants sont des codes (sources, excutables), des scripts, des fichiers,
des tables, etc. Ils exposent des interfaces reprsentant les services raliss par
leurs classeurs.
.Diagramme de dploiement
Un diagramme de dploiement montre la disposition physique des diffrents
matriels(Ou nuds) qui entrent dans la composition du systme, la rpartition
des composants au sein des nuds et les supports.
.Diagramme dtats
Le diagramme dtats reprsente la faon dont voluent (i.e. cycle de vie) les
objets appartenant une mme classe. La modlisation du cycle de vie est
essentielle pour reprsenter et mettre en forme la dynamique du systme.
Page 24
.Diagramme dactivits
Le diagramme dactivits nest autre que la transcription dans UML de la
reprsentation du processus telle quelle a t labore lors du travail qui a
prpar la modlisation : il montre lenchanement des activits qui concourent
au processus. Un diagramme dactivit reprsente la vue dynamique dun
ensemble dlments sous forme de flux dexcution.
.Diagramme dinteraction (squence et collaboration)

Un diagramme dinteraction dcrit le comportement du systme par les
interactions entre les objets qui le composent Il peut se prsenter sous deux
formes diffrentes. Le diagramme de squence met laccent sur la squence
ment dans le temps des interactions et des messages changs entre objets. Par
contre le diagramme de collaboration focalise sur une reprsentation spatiale des
objets collaborant par change de messages.
.Paquetages (Packages)
Un Paquetage (sous modle) : cest une notion qui peut apparatre dans
beaucoup de diagrammes pour spcifier le regroupement dlments au sein
dun sous-systme (cas, classes, objets, composants, autres paquetages, ...) et
aussi pour encapsuler ces lments.
_ Caractristiques:
sert despace de dsignation

peut inclure dautres paquetages et peut importer dautres paquetages
Lhritage entre paquetages est possible
3.1.3 Processus de dveloppement choisi (processus

unifi) :
3.1- Dfinition :
Le processus unifi est un processus de dveloppement logiciel construit sur
UML. Il est itratif, centr sur l'architecture, pilot par des cas d'utilisation et
orient vers la diminution des risques. Il regroupe les activits mener pour
transformer les besoins dun
utilisateur en systme logiciel, C'est un patron de processus pouvant tre adapte
une large classe de systmes logiciels, diffrents domaines d'application,
diffrents types d'entreprises,
diffrents niveaux de comptences et diffrentes tailles de l'entreprise[16] .
Page 25
3.2- UP est pilot par les cas dutilisation :

Les cas dutilisation ne sont pas un simple outil de spcification des besoins du
systme. Ils vont compltement guider le processus de dveloppement travers
lutilisation de modles bass sur lutilisation du langage UML.
3.3- Centr sur l'architecture

Tout systme complexe doit tre dcompos en parties modulaires afin de
garantir une maintenance et une volution facilites. Cette architecture
(fonctionnelle, logique, matrielle
...) doit tre modlise en UML et pas seulement documente en texte.
3.4- UP est itratif et incrmental :

Le projet est dcoup en itrations de courte dure qui aident mieux suivre
l'avancement global. A la fin de chaque itration, une partie excutable du
systme final est produite de faon incrmental.
3.5- Diminution de risques :

Les risques majeurs du projet doivent tre identifis au plut tt, mais surtout
levs le plus rapidement possible. Les mesures prendre dans ce cadre
dterminent l'ordre des itrations.
3.6- Larchitecture bidirectionnelle :

UP gre le dveloppement selon deux axes.
-L'axe vertical reprsente les principaux enchanements d'activits, qui
regroupent les activits selon leur nature. Cette dimension rend compte l'aspect
statique du processus qui s'exprime en termes de composants, de processus,
d'activits, d'enchanements, d'artefacts et de travailleurs.
-L'axe horizontal reprsente le temps et montre le droulement du cycle de vie
du processus ; cette dimension rend compte de l'aspect dynamique du processus
qui s'exprime en terme de cycles, de phases, d'itrations et de jalons.
Page 26
Figure 1 . Les activits dUP
3.7- Les Activits :

3.7.1- Expression des besoins :
L'expression des besoins permet de :
Inventorier les besoins principaux et fournir une liste de leurs fonctions
Recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui
conduisent l'laboration des modles de cas d'utilisation
Apprhender les besoins non fonctionnels (technique) et livrer une liste des
exigences.
Le modle de cas d'utilisation prsente le systme du point de vue de l'utilisateur
et reprsente sous forme de cas d'utilisation et d'acteur, les besoins du client.
3.7.2-Analyse :
L'objectif de l'analyse est d'accder une comprhension des besoins et des
exigences du client, Il s'agit de raliser des spcifications permettant de
concevoir la solution, Un modle d'analyse livre une spcification complte des
besoins issus des cas d'utilisation et les
Structures sous une forme qui facilite la comprhension (scnarios), la
prparation (dfinition de l'architecture), la modification et la maintenance du
futur systme. Il peut tre considr comme une premire bauche du modle de
conception.
3.7.3-Conception :
La conception permet d'acqurir une comprhension approfondie des contraintes
lies au langage de programmation, l'utilisation des composants et au systme
d'exploitation. Elle dtermine les principales interfaces et les transcrit l'aide
d'une notation commune.
Page 27
-Elle constitue un point de dpart l'implmentation :

-Elle dcompose le travail d'implmentation en sous-systme
-Elle cre une abstraction transparente de l'implmentation
3.7.4-Implmentation :
L'implmentation est le rsultat de la conception pour implmenter le systme
sous formes de composants, c'est--dire, de code source, de scripts, de binaires,
d'excutables et d'autres lments du mme type. Les objectifs principaux de
l'implmentation sont de planifier les intgrations des composants pour chaque
itration, et de produire les classes et les sous-systmes sous formes de codes
sources.
3.7.5-Test :
Les tests permettent de vrifier des rsultats de l'implmentation en testant la
construction. Pour mener bien ces tests, il faut les planifier pour chaque
itration, les
implmenter en crant des cas de tests, effectuer ces tests et prendre en compte
le rsultat de chacun.
3.8 -Les Phases :

3.8.1 - Analyse des besoins :
L'analyse des besoins donne une vue du projet sous forme de produit fini, Cette
phase porte essentiellement sur les besoins principaux (du point de vue de
l'utilisateur), l'architecture gnrale du systme, les risques majeurs, les dlais et
les cots (On met en place le Projet).
Elle rpond aux questions suivantes :
-Que va faire le systme ? Par rapport aux utilisateurs principaux, quels services
va-t-il rendre ?
-Quelle va tre l'architecture gnrale (cible) de ce systme
-Quels vont tre : les dlais, les cots, les ressources, les moyens dployer ?
3.8.2 - Elaboration :
L'laboration reprend les lments de la phase d'analyse des besoins et les
prcise pour arriver une spcification dtaille de la solution mettre en
oeuvre. L'laboration permet de prciser la plupart des cas dutilisation, de
concevoir larchitecture du systme et surtout de dterminer l'architecture de
rfrence.
Au terme de cette phase, les chefs de projet doivent tre en mesure de prvoir les
activits et destimer les ressources ncessaires lachvement du projet.
Les taches effectuer dans la phase laboration sont les suivantes :
-Crer une architecture de rfrence
Page 28
-Identifier les risques, ceux qui sont de nature bouleverser le plan, le cot et le
calendrier
-Dfinir les niveaux de qualit atteindre
- Formuler les cas d'utilisation pour couvrir les besoins fonctionnels et planifier
la phase de construction
-Elaborer une offre abordant les questions de calendrier, de personnel et de
budget
3.8.3 - Construction :
La construction est le moment o lon construit le produit (architecture= produit
complet). Le produit contient tous les cas dutilisation que les chefs de projet, en
accord avec les utilisateurs ont dcid de mettre au point pour cette version.
3.8.4 - Transition :
Un groupe dutilisateurs essaye le produit et dtecte les anomalies et dfauts.
Cette phase suppose des activits comme la formation des utilisateurs clients, la
mise en oeuvre dun service dassistance et la correction des anomalies
constates.
3.1.4 Modlisation dun projet Androde avec UML

3.2.
Programmation mobile
3.2.1 Caractristiques des systmes mobiles
Avant dentamer le dveloppement de lapplication, nous allons
prsenter quelques lments dinitiation en liaison avec notre projet
(Internet mobile, Android, etc). Pour cela, nous commenons par
dfinir lInternet mobile, le systme dexploitation mobile en dtaillant
celui dAndroid, systme dexploitation avec lequel on a dvelopp notre
application. Enfin, nous dfinissons la scurisation des communications et
des protocoles.
Technologie de tlphonie mobile

2.1. Technologie 3G
Nomme aussi "technologie de troisime gnration", elle est devenue
disponible au public depuis 2013 et elle se base sur la norme de communication
UMTS (Systme de tlcommunications mobiles universelles). Elle peut
atteindre un dbit gal 2 Mbps (244Ko/s) partir d'un lieu .
Page 29
2.2. Technologie 3G+

La 3G+ est une technologie qui permet dchanger les donnes de faon plus
rapide et dans des tailles plus importants grce lassociation simultane des
systmes HSDPA (High Speed, Downlink Packet Access) jusqu 3 5 fois plus
rapide que les technologies prcdentes. La 3G+ amne une meilleure
connexion Internet en mobile.
2.3. Technologie 4G
La 4G est le terme utilis pour dsigner la prochaine vague de
technologies mobiles haut dbit qui seront utiliss pour remplacer les
rseaux 3G actuels. Les deux principaux prtendants sont LTE (Long
Term Evolution) et WiMAX (Worldwide Interoperability for Microwave
Access).
2.4. Smartphone
Cest un tlphone mobile disposant des performances proches de lordinateur.
Par rapport aux tlphones standards, les Smartphones ont gnralement des
crans plus larges et des processeurs plus puissants .La saisie des donnes se fait
par le biais d'un cran tactile ou d'un clavier. Il fournit des fonctionnalits
basiques comme : l'agenda, le calendrier, la navigation sur le web, le messagerie
instantane et ainsi le GPS (Systme de localisation du vhicule par satellites).
Il dispose dun OS (systme d'exploitation) embarqu pour lexploitation de ces
capacits : mmoire, le processeur, le capteur, etc.
3.2.2 Systmes dexploitation mobiles (comparaison)

Systme dexploitation mobile
Le systme d'exploitation mobile est un systme d'exploitation conu pour
fonctionner sur un appareil mobile. Pour le faire, il faut quil soit non seulement
robuste mais suffisamment flexible pour effectuer des tches qui dpassent le
champ que lon connat dans la micro-informatique. Cela revient la richesse du
monde mobile. En plus, le Smartphone comporte beaucoup plus de dfis que les
stations de travails fixes. Ce type de systme d'exploitation se concentre entre
autres sur la gestion de la connectivit sans fil et celle des diffrents types
d'interface.
Page 30
3.1. Les diffrents systmes dexploitation sur le march

Il existe sur le march des dizaines de systmes d'exploitation diffrents :
Symbian OS de Nokia, ios dApple, BlackBerry OS de RIM, Windows Phone
de Microsoft, Palm webOS, Bada de Samsung et Android de Google.
Symbian OS
Le Symbian OS est dvelopp par la socit ponyme qui est une proprit
exclusive de Nokia. Bien que cette plateforme soit cre par la participation de
plusieurs fabricants tels que Samsung ou Sony Ericsson, ce systme est
fortement connot Nokia, ce qui est un frein son adoption par dautres
constructeurs. Il est rcemment pass en open source. Cest un systme libre,
open source se base sur un noyau Symbian.
Ios
IOS (Internetwork Operating System), qui tait nomm iPhone OS, se trouve
non seulement sur les diffrents gnrations de iPhone mais galement sur
dautres produits de Apple iPad et iPod touch. Il est driv de Mac OS X dont il
partage les fondations : kernel, les services Unix et Cocoa. Pour Apple, le succs
est considrable : dbut 2009, il ny avait pas moins de 5 millions de
tlchargements par jour. Donc, il sagit du concurrent numro un pour Android.
BlackBerry OS
Le systme d'exploitation BlackBerry est la plate-forme exclusive mobile
dvelopp par RIM (Research In Motion ) exclusivement pour ses Smartphones
BlackBerry et les appareils mobiles. RIM utilise ce systme d'exploitation pour
soutenir des fonctions spcialises, notamment le trackball de la marque,
molette, le trackpad et l'cran tactile.
Windows Phone
Windows Mobile, WiMo pour les intimes, est lOS (systme d'exploitation)
mobile de Microsoft. Cest une volution de Windows Pocket PC, anctre de
Windows CE. Cet OS a russi au fil des annes soctroyer une part de march
honorable. Son succs est d son affiliation la famille dOS Windows, ultradominante sur le bureau. Un autre avantage souvent cit est la facilit de
dveloppement apporte grce lenvironnement cliquodrome de Visual Studio
qui a su faire venir au dveloppement mobile les dveloppeurs VB (Visual
Basic).
Page 31
Palm webOS
Il y a quelques annes, Palm a mme cd aux sirnes de Windows Mobile en
proposant certains de ses appareils sous lOS de Microsoft. Palm avait cess
dinnover et devrait ragir face aux assauts dApple et de Google
Langage de
programmation
Symbian OS
Ios
Blackberry
Windows Phone
Palm webOS
Android
C++
ObjectiveC
Java
C, C++
HTML,
Java
CSS, JavaScript,
JSON, etc.
gratuit
Intgr
Xcode
Gratuit
Gratuit
Gratuit
Gratuit
Disponibilit de
lenvironnement de
dveloppement
Carbide.C++
Xcode
JDE
Visual Studio,
eMbeddeb VC++
Eclipse,
CodeWarrior,
PocketStudio, HB++
Eclipse,
Netbeans
Multiplate-forme de
dploiement
Samsung
iPhone,
iPode
touch,
iPad
Blackberry
seulement
Windows Mobile,
Windows CE
Palm OS Palm,
Windows Mobile
Andoid
seulement
Cout doutils de
dveloppement
gratuit
gratuit1
Gratuit
Gratuit
Gratuit et
commercial
Gratuit
Magasin en
Ovi Store
App Store
App World
Windows
App catalog
Android
Ligne
Market
Market
Place
Open source
Oui
Non
Oui
Non
Non
Oui
Constructeur
Nokia
Apple
RIM
Microsoft
Palm
Google
Tableau 1. Une comparaison entre les systmes dexploitation mobile
Page 32
Figure 2 . Les parts de march des systmes d'exploitation mobile pour les annes 2011 et
2014
3.2.3 Comparaison par rapport la programmation classique

Les applications natives sont actuellement les solutions idales mais si votre
budget n'est pas suffisant, tout n'est pas perdu pour la cause.
Une application web mobile est un site Internet optimis pour la taille des petits
crans (smartphones et tablettes). Cela signifie que lorsqu'un utilisateur accdera
votre site depuis un mobile, il dcouvrira une page adapte son appareil, qui
sera donc agrable lire et utiliser.
L'avantage principal de cette solution est que votre application sera accessible
sur toutes les plateformes, et pas uniquement aux possesseurs d'un iPhone par
exemple. Et cela moindre cot, car vous ne devez dvelopper et maintenir
qu'une seule version de votre application.
Cette solution a cependant bien entendu ses inconvnients. Une "web app" ne
peut pas profiter de toutes les fonctionnalits d'un smartphone : impossible par
exemple d'utiliser l'appareil photo. Vous tes galement limit au niveau du
stockage des donnes, ce qui peut rendre impossible le fonctionnement de
l'application lorsqu'il n'y a pas de connexion Internet active. Impossible
Page 33
galement de publier votre application sur l'AppStore ou l'Android Market ou

encore d'envoyer des notifications push.
3.2.4 Choix de la plateforme mobile (Android)

Le dveloppement d'applications pour Android s'effectue avec un ordinateur
personnel sous Mac OS, Windows ou Linux en utilisant le JDK de la plateforme Java et des outils pour Android. Des outils qui permettent de manipuler le
tlphone ou la tablette, de la simuler par une machine virtuelle, de crer des
fichiers APK (les fichiers de paquet d'Android), de dboguer les applications et
d'y ajouter une signature numrique. Ces outils sont mis disposition sous la
forme d'un plugin pour l'environnement de dveloppement Eclipse7.
La bibliothque d'Android permet la cration d'interfaces graphiques selon un
procd similaire aux frameworks de quatrime gnration que sont XUL,
JavaFX ou Silverlight: l'interface graphique peut tre construite par dclaration
et peut tre utilise avec plusieurs skins - chartes graphiques. La programmation
consiste dclarer la composition de l'interface dans des fichiers XML ; la
description peut comporter des ressources (des textes et des pictogrammes). Ces
dclarations sont ensuite transformes en objets tels que des fentres et des
boutons, qui peuvent tre manipuls par de la programmation Java9. Les crans
ou les fentres (activits dans le jargon d'Android), sont remplis de plusieurs
vues ; chaque vue tant une pice d'interface graphique (bouton, liste, case
cocher). Android 3.0, destin aux tablettes, introduit la notion de fragments:
des panneaux contenant plusieurs lments visuels. Une tablette ayant contrairement un tlphone - gnralement suffisamment de place l'cran
pour plusieurs panneaux
3.3. Programmation mobile sous Android

Le systme dexploitation Android
4.1. Dfinition et historique
Android est un systme dexploitation Open Source pour Smartphone, PDA
(Personal Digital Assistant) et terminaux mobiles conu par Android, une
startup rachete par Google, et annonc le 15 novembre 2007. Le terme Android
fait rfrence au nom androde qui dsigne un robot construit limage dun
tre humain.
Page 34
Afin de promouvoir ce systme ouvert, Google a su fdrer autour de lui une

trentaine de partenaires runis au sein de l'OHA (Open Handset Alliance). En
fait, plus de 50 entreprises ont particip l'OHA, Qualcomm, y compris,
Broadcom, HTC, Intel, Samsung, Motorola, Sprint, Texas Instruments et le
japonais KDDI transporteurs sans fil et NTT DoCoMo.
Le T-Mobile G1, a t annonc le 23 Septembre 2008, et a t le premier
Smartphone Android OS pour tre officiellement introduit sur le march.
3.3.1 Architecture et versions dAndroid

La rpartition des diffrentes versions Android est reprsente dans le tableau
suivant :
Distribution
Version
Nom
API Level
1.5
Cupcake
0.2%
1.6
Donut
0.5%
2.1
Eclair
4.2%
2.2
Froyo
15.5%
2.3 2.3.2
Gingerbread
0.3%
10
60.3%
12
0.5%
13
1.8%
14
0.1%
15
15.8%
16
0.8%
2.3.3 2.3.7
3.1
Honeycomb
3.2
4.0 4.0.2
Ice Cream
4.0.3 4.0.4
Sandwich
4.1
Jelly Bean
Tableau 2. Les versions de lAndroid
Cest les dernires statistiques qui datent du janvier 2013 concernant la

rpartition des diffrentes versions Android.
Page 35
Figure 3. La part de chaque version d'Android
La figure 2 est base sur le nombre d'appareils Android qui ont accd au
Google Play, dans un dlai de 14 jours se terminant la date de la collecte des
donnes ci-dessous.
Nous avons la grande proportion de terminaux qui sont quips par la
version Android 2.3 qui est toujours leader avec 45,6%, on
peut sapercevoir aussi que la version Android 4.0 prend une bonne proportion
du march avec 29%. Les autres versions restent anecdotiques avec 1,3 % pour
Honeycomb (Android 3.x), 2,2 % pour Eclair (Android 2.1) et 0,2 % pour Donut
(Android 1.6)
Architecture logiciell
Linux Kernel
LAndrode se fond sur la version 2,6 de Linux pour des services systme de
noyaux tels que le systme de scurit, la gestion de mmoire, la gestion de
processus industriel, le rseau et le modle de pilote. Le noyau agit sur la couche
d'abstraction entre le matriel et le logiciel.
Librairies
Au-dessus du noyau kernel , proprement dit, se loge un ensemble de librairies
natives constituant les couches bases du systme. Ces librairies sont crites en
C/C++ et utilises par les diffrentes composantes du systme Android.
Page 36
Android Runtime
LAndroid inclut un ensemble de bibliothques de base qui fournit la plupart des
fonctionnalits disponibles dans les bibliothques de base du langage de
programmation Java. Les applications sexcutent chacun dans son propre
processus.
Une application sous Android sexcute dans son propre processus, avec son
propre instance de machine virtuelle Dalvik. Ce dernier excute des fichiers
avec lextension " .dex " qui est optimis pour une empreinte mmoire
minimale. Le VM Dalvik s'appuie sur le noyau Linux pour les fonctionnalits de
base telles que la gestion de la mmoire de bas niveau.
Application Framework
Les dveloppeurs ont un accs complet l'API. L'architecture d'application est
conue pour rendre la rutilisation des composants plus simple. En fait, chaque
application peut publier ses capacits et dautres applications peuvent alors faire
usage de ces capacits. Toutes les applications sous-jacentes sont un ensemble
des services et des systmes.
Applications
Android sera livr avec un ensemble d'applications de base, dont un client de
messagerie, le programme de SMS, calendrier, cartes, navigateur, Contacts, et
d'autres. Toutes les applications sont crites en utilisant le langage de
programmation Java.
Figure 4 . Architecture logiciel de landroide

Page 37
4.4. Kit de dveloppement

Exploiter une nouvelle plate-forme nest jamais t une chose aise. Cest
pourquoi Google fournit, en plus du systme dexploitation, un kit de
dveloppement (Software Development Toolkit ou SDK). Ce SDK est un
ensemble doutils qui permet aux dveloppeurs et aux entreprises de crer des
applications. Il est disponible gratuitement sur le site de Google.
Le SDK Android est compos de plusieurs lments afin daider les
dveloppeurs crer et maintenir des applications :
Des outils ;
Des exemples de code ;
De la documentation ;
Des API (interfaces de programme dapplication).
Les outils
Le SDK est livr avec un certain nombre doutils couvrant diffrents aspects du
cycle de dveloppement dune application Android. Le kit de dveloppement
propose une bote outils complte pour les tches de compilation, de dbogage,
de gnration de code AIDL et de la signature de lapplication, etc.
Lmulateur Android : cest un tlphone virtuel qui permet de tester les
applications qui sont entrain de se dvelopper. Il est lanc par la commande
"emulator ". Celle-ci prend en paramtre limage AVD (Android Virtual Device)
qui sera monte en mmoire. Il a des limitations par exemple : il nest pas
capable de supporter le Bluetooth ainsi quil ne permet pas le teste des
applications de ralit augmente.
Les API
Android offre plusieurs API (Application Program Interface) tel que :
Google Cartes : intgre et contrle laffichage dune carte dans une interface
graphique de lapplication.
Go localisation : permet daccder au service de localisation du systme, de
choisir le fournisseur en fonction des critres et de prciser la position actuelle
du tlphone (latitude, longitude, vitesse, etc.).
Page 38
Les exemples de code

Le kit de dveloppement est accompagn dun certain nombre dexemples
illustrant les possibilits du SDK Android. Parmi ces exemples, on peut citer :
un jeu du serpent et le projet qui couvre lutilisation de plusieurs exemples de
lAPI Android comme les alarmes, les notifications et les menus.
La documentation
La documentation du SDK Android est scinde en deux parties bien distinctes :
Le guide du dveloppeur qui est disponible en HTML (Hypertext Markup
Language) dans le rpertoire du SDK quon vient dinstaller ;
La documentation des API au format javadoc est galement situe dans le
rpertoire docs et accessible grce au chemin dbutant du rpertoire
dinstallation.
La Golocalisation
Parmi les fonctionnalits les plus apprcies sur les plates-formes mobiles
modernes, la golocalisation permet de raliser des applications innovantes.
Grce Google Cartes notamment, elle est au coeur dAndroid.
Le service de golocalisation rcupre les coordonnes de lutilisateur et les
envoie pour la ralisation un service informatique. A chaque fois, il demande
lautorisation de lutilisateur avant la ralisation de cette opration. Seules les
informations concernant la latitude et la longitude sont envoyes.
La localisation du mobile se fait selon plusieurs technologies comme :
GPS : il s'effectue par la rception de signaux provenant de plusieurs satellites

qui se trouve en orbite. Le tlphone mobile quip d'un GPS permettra de
transmettre sa position via un rseau SMS, GPRS, Edge ou UMTS.
Internet : La prcision de la localisation par adresse IP sur le rseau internet se

situera au niveau d'un pays, d'une ville ou d'un quartier selon l'oprateur
(national ou local). Cependant, au sein d'un rseau ADSL d'un mme oprateur,
la golocalisation peut tre trs prcise (adresse ou btiment par exemple) si les
lieux des connexions sont enregistres dans une base de donns.
Page 39
Wifi : La localisation est similaire au cas du rseau GSM ou IP, par les cellules
mettrices, avec une prcision infrieure 100 mtres. Une triangulation entre
plusieurs antennes Wifi peut donner la position avec une prcision d'environ 5m
par l'analyse de la puissance du signal radio reu de l'appareil.
GSM : il est bas sur le code unique de la carte SIM. La connexion au rseau
est autorise aprs une identification une cellule composant le rseau GSM. La
prcision dpend de l'tendue de la cellule, de 250 mtres en zone urbaine 10
km en zone rurale.
La scurisation des communications

Pour assurer une communication scurise entre le client et le serveur, il est
obligatoire utiliser des protocoles de cryptage. On trouve aussi des protocoles de
communication qui garantissent la scurisation du canal de transport des
donnes comme HTTPS (HyperText Transfer Protocole Secured).
6.1. La dfinition du protocole HTTPS

"HyperText Transfer Protocole Secured" (HTTPS) est un protocole de transfert
hypertexte scuris qui a t dvelopp par Netscape.
Il correspond une version scurise du http (HyperText Transfer Protocole).
Le HTTPS rpond aux diffrents problmes de confidentialit que protocole http
a connu.
L'ide principale de HTTPS est de crer un canal scuris sur un rseau non
scuris et dassurer une protection raisonnable contre les oreilles indiscrtes
condition que les suites de chiffrement adquat soient utilises et que le
certificat de serveur soit vrifi et approuv.
6.2. Les objectifs de scurit assurs

Le protocole HTTPS fournit les objectifs de scurit suivants :
L'authentification en permettant l'assurance de l'identit du programme, de la
personne ou de l'entreprise avec laquelle on communique.
La confidentialit des donnes changes : Il est impossible d'espionner les
informations changes.
Page 40
L'intgrit des donnes changes : Il est impossible de truquer les informations

changes.
La spontanit : la connexion de client avec le serveur est transparente.
Conclusion
Durant ce chapitre, nous avons prsent les technologies utilises et leurs
fonctionnalits.
Android et iOS "dominent le monde" - La domination d'Android sur le
march mondial des smartphones ne se dment pas. Ainsi sur les 287,8
millions de terminaux livrs au 1er trimestre 2014, 81,1% tournaient sous
Android selon IDC. Et sur le 2e trimestre, le rapport de force s'est encore
accentu au profit des deux plateformes dominantes : 96% des terminaux
livrs dans le monde, soit 301,3 millions dunits, tournaient sous Android et
iOS, dont 84,7% pour le seul Android.
Malgr une progression de ses ventes, Apple abandonne des parts de march.
Cependant, avec un positionnement sur le haut de gamme, l'iPhone reste
toujours trs rentable pour la firme. D'aprs IDC, la part de march d'iOS sur le
haut de gamme est considrable, de l'ordre de 84,6%, contre seulement 19,82%
pour Android. L'OS Google domine en revanche sur l'entre de gamme, laisse
de ct par Apple, puisque 58,6% des androphones livrs sur la priode
appartiennent ce segment. Du ct de Windows Phone, la ventilation par
catgories est relativement similaire.
3.3.2 Structure dun projet Android

Une application Android consiste en un assemblage de composants lis via un
fichier de configuration, qui prsentent en quelque sorte les briques sur
lesquelles se repose l'application. Ces concepts fondamentaux prciser sont :
Les vues
Les Views sont les composants basiques de l'interface graphique. Ce sont les
lments de l'interface que l'utilisateur voit et sur lesquels il agit. C'est de la
classe View qu'hritent les widgets
(exemple de composants graphiques tel que les boutons), les layouts(le plan sur
lequel on organise
Page 41
et on place les composants graphiques) et tous les composants graphiques

servant la cration d'une interface graphique interactive.
- Les contrles
C'est bien la classe des composants graphiques cits dessus. Les contrles sont
tels que les boutons, les champs de saisie de texte, les cases cocher, etc.
- Les activits
Une Activity reprsente la fentre qui sera affiche l'utilisateur. C'est un
ensemble de vues et de contrles composant une interface logique. Elle permet
galement de grer des fonctionnalits telles que l'appui sur une touche,
l'affichage de messages, etc. Ce concept repose essentiellement sur l'interaction
de l'utilisateur avec l'cran.
- Les ressources
Chaque application Android a ses propres fichiers ressources. C'est dans ces
fichiers que seront puiss les textes, les images, les couleurs, etc.
- Le fichier de configuration
C'est fichier auto gnr par l'application, qui lui est indispensable. C'est un
fichier XML appel AndroidManifest qui dcrit le point d'entre de
l'application (le code excuter), les composants du projet ainsi que les
permissions ncessaires pour l'excution du programme.
Une illustration explicative de ces concepts est reprsente par le schma de la
figure 4.
Page 42
Figure 5. Composition dune application androde
5.1.2 Conception architecturale

Il est primordiale la conception de tout systme informatique de choisir le
modle d'architecture qui lui sera adquat pouvant assurer un bon
fonctionnement, des meilleurs performances ainsi que la rutilisation et
l'interconnexion fiable de ce systme avec d'autres.
C'est cet effet que nous optons pour le modle MVC qui sera galement trs
pratique pour grer l'interaction entre les diffrents composants de notre
application Android.
Nous dcrivons cette architecture dans la section suivante.
5.1.3 Architecture MVC

L'architecture MVC (modle, vue et contrleur) est une architecture trois
couches utilise pour la programmation client/serveur et d'interface graphique.
C'est un modle architectural trs puissant qui intervient dans la ralisation d'une
application. Il tire sa puissance de son concept de base qui est la sparation des donnes
(modle), de l'affichage (vue) et des actions (contrleur).
Page 43
C'est trois couches sont dcrites comme suit:

- Modle
Il correspond aux donnes stockes gnralement dans une base de donnes.
Dans un langage oriente objet ces donnes sont exploites sous forme de
classes. Le modle peut aussi agir sur la vue en mettant jour ses donnes.
- Vue
Ne contenant que les informations lies l'affichage, la vue se contente
d'afficher le contenu qu'elle reoit sans avoir connaissance des donnes. En bref,
c'est l'interface homme machine de l'application.
- Contrleur
Le contrleur sert de base rcuprer les informations, de les traiter en fonction
des paramtres demands par la vue (par l'utilisateur), puis de renvoyer la vue
les donnes afin d'tre affiches. C'est donc l'lment qui va utiliser les donnes
pour les envoyer la vue.
L'interaction entre ces trois couches est dcrite l'aide de la figure 5.
Figure 6 Architecture MVC
Page 44
Les avantages apports par l'architecture MVC sont :

- La sparation des donnes de la vue et du contrleur (ce qui permet une
conception claire et efficace de l'application)
- Une indpendance des donnes, de l'affichage et des actions (ce qui donne plus
de souplesse pour la maintenabilit et l'volutivit du systme).
- Un gain de temps de maintenance et d'volution de l'application.
Page 45
Chapitre 4 : Conception du projet
Page 46
4.1 Etude Prliminaire

4.1.1 Prsentation du projet raliser
Pour une meilleure comprhension du travail effectu, nous
prsentons dans ce chapitre ltape danalyse et de conception. En
effet, pour raliser une bonne conception de lapplication, il faut
faire une tude approfondie des exigences du march du travail.
Dans ce chapitre, nous commencerons par une tude prliminaire
qui consiste reprer les besoins fonctionnels et non fonctionnels.
Par suite, nous avons labors une modlisation claire de ce qui a
t tabli au cours de cette tude. Aussi, ce chapitre sera ddi pour
la conception architecturale de notre application.
4.1.2 Recueil des besoins fonctionnels (Cahier de charge)

1- Golocaliser : permet au conducteur de connaitre sa position sur la carte.
2- Naviguer sur la carte : permet au conducteur de consulter, d'agrandir, de
rtrcir et de se dplacer dans la carte.
3.3.1- Zoomer plus
3.3.2- Zoomer moins
3.3.3- Se dplacer
3-Trouver des services et des stations : permet au conducteur de trouver des
stations et des services proches.
4-Signaler des alertes : permet de signaler des accidents, des bouchons, des
pannes .etc.
5-Associer des informations aux alertes :associer des informations aux les
alertes comme (la nature , linstant de son signallement.)
6-Elaborer des chemins possibles :contruire des chemins entre deux point
donnes.
4.1.3 Identification des acteurs : on a un seul acteur (le conducteur).

4.1.4 Modlisation du contexte & identification des messages
Page 47
Figure 7. Diagramme de contexte statique
4.2 Capture des besoins fonctionnels

4.2.1 Identification des cas dutilisations
(Diagrammes des cas dutilisations de chaque acteur)
4.2.2 laboration des diagrammes de cas dutilisations :

Un cas dutilisation correspond un certain nombre dactions que le systme
devra excuter en rponse un besoin dun acteur. Un cas dutilisation doit
produire un rsultat observable pour un ou plusieurs acteurs ou parties prenantes
du systme.
Une interaction permet de dcrire les changes entre un acteur et un cas
dutilisation.
Pour identifier les cas dutilisation de faon pragmatique il est judicieux de
dissocier les acteurs du systme en sintressant aux fonctionnalits quils
peuvent enclencher.
4.2.2.1- Diagramme des cas dutilisation des conducteurs :
Page 48
Figure 8. Diagramme de cas dutilisation
4.2.3. Description textuelle des cas dutilisations :
1-Go localiser :
Cas dutilisation : Go localiser

Acteurs principaux
Acteurs secondaires
Pr conditions
Post conditions
Scnario nominale
Scnario alternatif
Conducteur
Aucun
le conducteur doit tre dj entrain dutiliser

lapplication.
Connaitre la position actuelle.
1. conducteur indique au systme quil veut
go localiser.
2. Le systme rcupre les coordonns de la
position.
3. systme affiche un marqueur sur la position
actuelle.
Aucun
Tableau 3. Cas dutilisation Geo localiser
Page 49
2-Naviguer sur la carte :

Cas dutilisation : Naviguer sur la carte
Acteurs principaux
Conducteur
Acteurs secondaires
Aucun
Pr conditions
Lapplication soit en cours dutilisation
Post condition
Affichage dune nouvelle vue de la carte
Scnario nominale
1. conducteur indique au systme quil veut
naviguer sur la carte.
2.le systme affiche la carte.
3.Conducteur fait les indications (les choix)
4.le Systeme Prendre en considrations les
choix.
Scnario alternatif
Aucun
Tableau 4. Cas dutilisation Naviguer sur la carte
3-Trouver des stations et des services :

Cas dutilisations : Trouver station et service
Conducteur
Acteurs principaux
Acteurs secondaires
SGBD
Le conducteur doit naviguer sur la carte
Pr conditions
Le systme affiche les services et les stations
Post conditions
proches
Scnario nominale 1 .le conducteur indique au systme quil veut
chercher service ou station
2. systme lui indique qu'il peut chercher avec
des spcifications.
3. Le conducteur donne son choix.
4. Le Systme prend en considration le choix
de Le conducteur.
5. Le systme excute la demande.
6. Le systme affiche le rsultat de la
recherche.
Aucun
Scnario alternatif
Tableau 5. Cas dutilisation Trouver des stations et des services
Page 50
4-Signaler des alertes :

Cas dutilisation : Signaler les alertes
acteurs principaux
Conducteur
Acteurs secondaires
SGBD
Le conducteur entrain dutiliser lapplication

Le systme affiche que lalerte est ajoute avec
succs.
Scnario nominale 1. Go localiser (cas dutilisation).
2. le conducteur fait une longue clique sur la
carte.
3. le system lui affiche une boite de dialogue
Spcifi le type dalerte.
4.le conducteur choisit le type dalerte.
5.le systme affiche licne dalerte et un
message de succs.
Scnario alternatif 5.1.si il y a un problme de connexion le
systme naffiche pas licne et affiche un
message derreur.
Pr condition
Post condition
Tableau 6. Cas dutilisation Signaler des alertes
4.2.4. Elaboration des diagrammes de squence et diagramme dactivits:

Pour chaque cas dutilisation, nous allons laborer un diagramme de squence
systme qui dcrit le cas sous forme d'interaction (squence) entre un acteur et le
systme, qui est toujours considr comme une boite noire, son comportement
est dcrit comme il est peru de lextrieur par lutilisateur.
1. Go localiser :
Page 51
Figure 9. Diagramme de squence de cas Go localiser
Figure 10 Diagramme dActiviez de cas Go localiser
2. Naviguer sur la carte :

Page 52
Figure 11. Diagramme de squence de cas Naviguer sur la carte
Figure 12 Diagramme dactive de cas Naviguer sur la carte
Page 53
Figure 13. Diagramme de squence de cas Trouver des stations et des services
Figure 14. Diagramme dactivit de cas Trouver des stations et des services
Page 54
Figure 15 Diagramme de squence de cas Signaler des alertes
Page 55
Figure 16. Diagramme de squence de cas Signaler des alertes
Page 56
4.3 Analyse
4.3.1 Diagrammes de classes utiliss dans chaque cas dutilisation
1-Go localiser :
Figure 17. Diagramme de class de cas Go localiser
2-Naviguer sur la carte :
Figure 18. Diagramme de class de cas Naviguer sur la cartes
Page 57
Figure 19. Diagramme de class de cas Trouver des stations et des services
Figure 20. Diagramme de class de cas Signaler des alertes

Page 58
5- associer des informations aux alertes :
Figure 21 Diagramme de class de cas associer des informations aux alertes
6-Elaborer des chemins possibles :
Figure 22. Diagramme de class de cas Elaborer des chemins possibles
4.3.2 Diagrammes de classes complet
Page 59
Figure 23. Diagramme de class complet
4.3.3 Attributs et mthodes de chaque classe
Page 60

Memoire Fin D EtudeXX

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

Memoire Fin D EtudeXX

Transféré par

Droits d'auteur :

Formats disponibles

Remerciements

Rapport de Fin dEtude

Rapport de Fin dEtude

2.1. Caractristiques des autoroutes ....................................................................................13

3.1. Processus de dveloppement et langage de modlisation 18

3.2. Programmation mobile .....29

3.3. Programmation mobile sous Androde ...34

4.1. Etude Prliminaire 47

4.2. Capture des besoins fonctionnels ..48

5.2. Plateforme logicielle ....00

6.1. Captures dcrans des activits .00

Rapport de Fin dEtude

LISTE DES FIGURES

Les activits dUP 27

Les parts de march des systmes d'exploitation mobile

La part de chaque version d'Android.. 36

Architecture logiciel de landroide.. 37

Composition dune application androde 43

Diagramme de contexte statique 48

Diagramme de cas dutilisation.. 49

Diagramme de squence de cas Go localiser .. 52

Diagramme dActiviez de cas Go localiser . 52

Diagramme de squence de cas Naviguer sur la carte .. 53

Diagramme dactive de cas Naviguer sur la carte. 53

Rapport de Fin dEtude

Liste des tableaux

Rapport de Fin dEtude

LISTE DES ABREVIATIONS

WAP:Wireless Application Protocol

Rapport de Fin dEtude

Chapitre 1 : Introduction gnrale

Rapport de Fin dEtude

Chapitre 1 : Introduction gnrale

"Les mobiles sont aussi diffrents de l'internet que la tl l'a t de la radio", a

Chapitre 1 : Introduction gnrale

Rapport de Fin dEtude

Chapitre 2 : Contexte du projet

Rapport de Fin dEtude

Chapitre 2 : Contexte du projet

2.1. Caractristiques de lautoroute est-ouest :

Rapport de Fin dEtude

Chapitre 2 : Contexte du projet

millions de $, qui ne sera consomm qu' 30% pour sa

Chapitre 2 : Contexte du projet

Les tronons Ouest et Centre, raliss par le groupement chinois

2.2. Le besoin dintgrer linformatique

Chapitre 2 : Contexte du projet

Signaler et positionner des alertes et des marqueurs (accidents, pannes,

Rapport de Fin dEtude

Chapitre 3 : Notions prliminaires

Rapport de Fin dEtude

Chapitre 3 : Notions prliminaires

3.1.1.1. POURQUOI LA PROGRAMMATION ORIENTE

3.1.1.2. Objectifs de la programmation oriente objet :

3.1.1.3. QUEST CE QUE LA PROGRAMMATION

Rapport de Fin dEtude

Chapitre 3 : Notions prliminaires

+ labor par Alan Kay, dans les annes 70

3.1.1.4. CONCETPS DE BASE

Rapport de Fin dEtude

Chapitre 3 : Notions prliminaires

Langage de modlisation UML

Rapport de Fin dEtude