Download - Memoire Fin d EtudeXX

Remerciements

Nous sommes très reconnaissants envers tous ceux qui, par leurs

Compétences scientifiques et leurs qualités humaines, ont contribué au bon

déroulement de ce mémoire.

Nous exprimons toute notre reconnaissance à Dr.Benlalla Nabil, d’avoir bien

voulu me faire l’honneur de présider le jury de ce mémoire.

Nous tenons à remercier tout d’abord Mr. Chaouche, pour ses valeureux conseils

et pour la confiance et la sympathie qu’il nous

a accordée en acceptant de nous encadrer et qu’il nous a témoignée au cours de ce

projet de Fin d’études.

Nous tenons aussi à exprimer notre profonde reconnaissance à tous mes

collègues, mes parents... Pour ses conseils, ses commentaires précieux et le suivi

de ce travail.

Rapport de Fin d’Etude

Remerciements

Nous sommes très reconnaissants envers tous ceux qui, par leurs

compétences scientifiques et leurs qualités humaines, ont contribué au bon

déroulement de ce mémoire.

Nous exprimons toute notre reconnaissance à Dr,Benlalla d’avoir bien voulu me

faire l’honneur de présider le jury de ce mémoire.

Nous tenons à remercier tout d’abord Mr.Chaouch ,pour ses valeureux conseils et

pour la confiance et la sympathie qu’il nous

a accordée en acceptant de nous encadrer et qu’il nous a témoignée au cours de ce

projet de Fin d’études.

Nous tenons aussi à exprimer notre profonde reconnaissance à tout mes collègues

pour ses conseils, ses commentaires précieux et le suivi de ce travail.


Résumé

Les autoroutes d’aujourd’hui seront gérées de manière plus intelligente et

dynamique, sur lesquelles il y aurait, non seulement, moins de risques

d’accident, mais aussi, une assistance temps-réel des conducteurs.

Le but de ce projet est de réaliser une application mobile native pour système

Android, dont l'IHM est représentée par une carte géographique interactive. Il

s'agit de développer un système coopératif pour assister les voyageurs et les

guider tout au long de leur voyage afin de rendre celui-ci le plus convivial

possible. Afin d’assurer la communication temps-réel et la persistance des

données, le système devrait fonctionner dynamiquement en se basant sur un

serveur distant (par exemple, le centre d’infrastructure routière). Ceci rendra les

véhicules, à travers notre application, sensibles à leur contexte changeant.


Sommaire

1. Chapitre 1 : Introduction général ..........................................................................09

2. Chapitre 2 : Contexte du projet .............................................................................12

2.1. Caractéristiques des autoroutes ....................................................................................13

2.2. Le besoin d’intégrer l’informatique dans les autoroutes pour une conduite sûre....15

2.3. Exploitation des nouvelles technologies mobiles pour assister le conducteur …....15

3. Chapitre 3 : Notions préliminaires …………………………………………….....17

3.1. Processus de développement et langage de modélisation ……………………………18

3.1.1. Approche Orientée Objet ………………………………………………………….........18

3.1.2. Langage de modélisation UML …………………………………………………… …..20

3.1.3. Processus de développement choisi ……………………………………………...……..25

3.1.4. Modélisation d’un projet Androïde avec UML …………………………………………29

3.2. Programmation mobile ……………………………………………………………….....29

3.2.1. Caractéristiques des systèmes mobiles …………………………………………………29

3.2.2. Systèmes d’exploitation mobiles (comparaison) ……………………………………....30

3.2.3. Comparaison par rapport à la programmation classique Web ou Desktop …………….33

3.2.4. Choix de la plateforme mobile (Androïde) …………………………………………....34

3.3. Programmation mobile sous Androïde …………………………………………...34

3.3.1. Architecture et versions d’Androïde ……………………………………………….….35

3.3.2. Structure d’un projet Androïde …………………………………………………….… 35

3.3.3. Exécution sur des Appareils et sur l’émulateur ………………………………………..45

4. Chapitre 4 : Conception du projet ……………………………………………….46

4.1. Etude Préliminaire ………………………………………………………………………47

4.1.1. Présentation du projet à réaliser ………………………………………………………..47

4.1.2. Recueil des besoins fonctionnels ……………………………………………………....47

4.1.3. Identification des acteurs ………………………………………………………….……47

4.1.4. Modélisation du contexte & identification des messages ……………………………..47

4.2. Capture des besoins fonctionnels …………………………………………….….48

4.2.1 Identification des cas d’utilisations …………………………………………………….48

4.2.2 Diagramme complet de cas d’utilisations ……………………………………………...48

4.2.3 Description détaillée des cas d’utilisations …………………………………………….49

4.2.4 Structuration des cas d’utilisations dans des packages ………………………………...51


4.3. Analyse ………………………………………………………………………………57

4.3.1. Diagrammes de classes utilisées dans chaque cas d’utilisation …………………………..57

4.3.2. Diagrammes de classes complètes ………………………………………………………..60

4.3.3. Attributs et méthodes de chaque classe …………………………………………………..60

5. Chapitre 5 : Implémentation du projet ………………………………..…………..

5.1.Plateforme matérielle ……………………………………………………………………….00

5.2. Plateforme logicielle …………………………………………………………….………...00

5.3. Présentation de l’application …………………………………………………….……….00

6. Chapitre 6 : Expérimentation ……………………………………………………….00

6.1. Captures d’écrans des activités ………………………………………………………….00

6.2. Navigabilité de l’application entre les activités………………………………..……00

7. Chapitre 7 : Conclusion générale………………………………………………......00

Bibliothèque ………………………………………………………………………..……00


LISTE DES FIGURES

Figure 1. Les activités d’UP……………………………………………………… 27

Figure 2 Les parts de marché des systèmes d'exploitation mobile

pour les années 2011 et 2014……………………………………….….. 33

Figure 3. La part de chaque version d'Android………………………………..… 36

Figure 4. Architecture logiciel de l’androide……………..……………………… 37

Figure 5. Composition d’une application androïde……………………………… 43

Figure 6. Architecture MVC……………………………………………………… 44

Figure 7. Diagramme de contexte statique……………………………………… 48

Figure 8. Diagramme de cas d’utilisation………..……………………………… 49

Figure 9. Diagramme de séquence de cas « Géo localiser »…………………..… 52

Figure 10. Diagramme d’Activiez de cas « Géo localiser »…….………………… 52

Figure 11. Diagramme de séquence de cas « Naviguer sur la carte »…… ……..… 53

Figure 12. Diagramme d’activée de cas « Naviguer sur la carte»……….………… 53

Figure 13 Diagramme de séquence de cas « Trouver des stations et des services »..54

Figure 14. Diagramme d’activité de cas « Trouver des stations et des services »… 54

Figure 15. Diagramme de séquence de cas « Signaler des alertes »………..……… 55

Figure 16. Diagramme de séquence de cas « Signaler des alertes »...……………… 56

Figure 17. Diagramme de class de cas « Géo 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 systèmes d’exploitation mobile…..………… 32

Tableau 2. Les versions de l’Android.……………………………………………… 35

Tableau 3. Cas d’utilisation « Geo localiser»…………………..…………………… 49

Tableau 4. Cas d’utilisation « Naviguer sur la carte»……………… ……………… 50

Tableau 5. Cas d’utilisation « Trouver des stations et des services»…………..…… 50

Tableau 6. Cas d’utilisation « 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 générale




Introduction générale

"Les mobiles sont aussi différents de l'internet que la télé l'a été de la radio", a

annoncé -Tomi Ahonen-, meilleur auteur technologique et médiatique à succès,

consultant de stratégie et orateur motivationnel.

Les téléphones portables sont devenus les premiers médias de masse dans le

monde (on compte 6,8 milliards d'abonnés au téléphone mobile). Il n'est pas un

PC plus bête, mais un téléphone portable est considéré comme un autre support

à générer des formes médiatiques.

Il a subit une évolution à une vitesse surprenante, passant du premier téléphone

portable inventé par Dr Martin Cooper -un directeur général de Motorola- en

1973 qui a été la première personne à faire un appel depuis son téléphone

portable, aux ordiphones, PDA et Smartphones qui disposent d'un système

d'exploitation adoptant des applications tierces qui leur sont dédiées.

L'invention du premier PDA au monde, Le PenPad conçu par Apple, était dans

le but de pouvoir prendre des notes, gérer son agenda, ses adresses, effectuer des

calculs, etc, sans avoir à s'encombrer d'un ordinateur portable ou d'un bloc notes.

Aujourd'hui ces périphériques ont atteint une puissance de calcul, une taille

mémoire ainsi qu'un débit nécessaire pour faire tourner des applications aussi

diverses que variées 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 développeurs à l'élaboration des petits

logiciels très prisés en profitant des multiples apports des plateformes présentes

sur le marché et des diverses innovations technologiques (Wifi, GPS, GPRS,

3G, 4G etc.).

En effet, la géo localisation du GPS des « téléphones intelligents >> est très utile

aux applications comme les annuaires, portails et autres outils permettant de

trouver ce que l'on cherche autour d'un lieu, répondant par la fin aux besoins

quotidiens de la communauté.



C'est dans ce cadre que s'inscrit notre projet de fin d'étude, intitulé

« DreamWay >> dont l'objectif est de concevoir une application dédiée au

téléphone mobile, doté de la plateforme Android, permettant au assurés la géo

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 réaliser la persistance des données à l’aide d’un

serveur distant…etc.

Le travail effectué a fait l’objet de sept chapitres. Le premier chapitre présente

une introduction générale. Le deuxième chapitre présente les contextes du

projet. Le troisième chapitre détaille les notions préliminaires. Le quatrième

chapitre porte sur la conception du projet. Le cinquième chapitre présente

l’implémentation du projet. Le sixième chapitre est une expérimentation pour le

projet et le dernier chapitre une conclusion générale, nous présentons une

synthèse ainsi que les perspectives en raison d’améliorer les performances de

l’application.

Chapitre 2 : Contexte du projet




2.1. Caractéristiques de l’autoroute est-ouest :

Historique:

Le projet d'autoroute reliant les grandes villes du nord est envisagé dès

les années 1970 par le ministère du plan. Par la suite, les différents

schémas directeurs routiers nationaux (1975-1995 et 1995-2015) vont

l'inclure dans leurs projections.

Les études préliminaires ont été réalisées en 1983. Elles ont porté sur

le choix du couloir du tracé, les prévisions du trafic, l’évolution des

indicateurs économiques et les différentes incidences du projet, elles

ont donné lieu, au cours de leur réalisation, à de nombreuses

concertations et ont abouti au choix du couloir, approuvé en Conseil

des Ministres au mois de juin 1987.

Les études d’avant projet sommaires (APS) sur environ 1 100 km entre

Annaba et Tlemcen ont été engagées en 1988 et terminées en 19943.

Années 1990, financement compliqué:

Le financement du projet par les pouvoirs publics dans un contexte

d'endettement est très compliqué. Durant les années 1990 et 2000, les

premiers tronçons sont financés par des prêts européens, arabes et

africains dans le cadre du développement.

Le 18 juin 1990, la Banque Européenne d'investissement (BEI)

accorde un prêt de 40 millions d'€ pour un premier tronçon de 30 km

entre Blida et El Affroun4. Un an plus tard en 1991, la même

institution prête 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

débloqués pour le tronçon Lakhdaria - Bouira6. De nouveau 140

millions d'€ en 20007 et 70 millions d'€ en 20028 sont investis pour

terminer ces deux tronçons est et ouest d'un total 80 km. Leur

réalisation par des entreprises algériennes ne sera achevée qu'entre

2004 et 2006.

Le 3 octobre 1995, un nouveau tronçon de 30 km entre El Affroun

(Blida) et Hoceinia (Ain Defla) est déclaré d'utilité public et une

enveloppe de 266 millions de dinars est dégagée pour les

expropriations9. Ce n'est qu'en 2002 que le Fond Arabe pour le

Développement Economique et Social (FADES) accorde un prêt de 86



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

réalisation10,11.

Entre 1996 et 2002, la Banque Africaine de Développement (BAD) a

accordé un prêt de 161 millions de $ pour le tronçon de contournement

de la ville de Constantine sur 29 km entre Ain Smara et El

Meridj12,13,14. Seil un premier tronçon de 15 km sera achevé en

2004.

2005, financement public:

Avec le retour des équilibres et la bonne santé des finances publiques,

le président Abdelaziz Bouteflika décide en février 2005, près d'un an

après sa réélection de financer l'intégralité des tronçons restants par le

trésor public, contre l'avis de son ministre des finances15.

Le 25 juillet 2005, un décret exécutif est publié pour déclarer d'utilité

publique l'opération portant réalisation de l’autoroute Est-Ouest sur

l'ensemble de son tracé16.

Lancement et attribution:

L'appel d'offres international limité, sur la base d'un cahier des charges

précis, pour le projet de l'autoroute Est-Ouest fut lancé le 23 juillet

2005. Plusieurs réponses furent enregistrées (américaine, française,

allemande et portugaise). C'est finalement deux consortiums qui ont

été sélectionnés : le chinois CITIC-CRCC et le japonais COJAAL. Les

résultats furent annoncés le 15 avril 2006 et les contrats de réalisation

signés le 18 septembre 2006.

Bureaux d'études:

Les missions de contrôle et de suivi du projet est passée par un autre

appel d'offres qui a vu la sélection :

du bureau d'études canadien "Dessau Soprane" pour le contrôle et le

suivi

du bureau d'études français "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 démarré en 2006, plusieurs

tronçons existaient déjà. Les nouveaux tronçons ont commencé à être

livrés petit à petit depuis 2008.



Les tronçons Ouest et Centre, réalisés par le groupement chinois

CITIC-CRCC, ont été livrés à la circulation, mais les travaux ne seront

pas achevés avant 2016 sur la section Est, réalisés par le groupement

japonais Cojaal. Des problèmes techniques ainsi que l'incapacité de

Cojaal à réaliser ce type d'infrastructures pourraient expliquer ce

retard. Un scandale de corruption avait déjà éclaboussé le projet en

2010 et la qualité des travaux réalisés par CITIC-CRCC ne serait pas

conforme aux normes internationales et des travaux de réfection ont

déjà été nécessaires17.

2.2. Le besoin d’intégrer l’informatique dans les

autoroutes pour une conduite sûre :

Maintenant et plus tard, plus que fois nous écoutons et voyons soit sur le

télévision ou sur le Web beaucoup des journaux qu’ils parlons à des accidents et

ses conséquences dans nos autoroutes et les nombres risqués de les victimes

..etc. Et ce dernier nous laisse penser de trouver des solutions efficaces, et de ces

solutions : le besoins d’intégrer l’informatique dans nos voitures pour une

conduite sûre

Non seulement, moins de risques d’accident, mais aussi, une assistance temps-

réel des conducteurs.

2. 3. Exploitation des nouvelles technologies mobiles

pour assister les conducteurs :

Le développement de notre application est réalisé sous Android. Nous

permettrons d’acquérir les composants fondamentaux servant à ce projet.

L’autoroute Est-Ouest étant considérée comme l’autoroute où sera déployé le

système, une carte détaillée de cette autoroute sera élaborée sous

OpenStreetCarte (Base de donnée géographique open source).Pour des raisons

d’affichage efficace et d’interactivité de l’application, une bibliothèque Android

spécialisée devra être utilisée pour exploiter la carte préalablement élaborée.

L’application à développer sera fondée sur différentes capacités en liens avec

une carte :

Déplacer ou zoomer le fond de carte sur des espaces (routes, aires de

services, borne d’appel d’urgence, ….)



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

bouchons, …)

Associer des informations aux alertes : la nature de l’alerte, l’instant de

son signalement, …

Elaborer des chemins possibles et proposer une navigation basée sur la

géo localisation ….etc.

Chapitre 3 : Notions préliminaires




3.1. Processus de développement et langage de

modélisation

3.1.1. Approche Orientée Objet :

L’approche orientée objet est une nouvelle méthode de programmation qui

tend à se rapprocher de notre manière naturelle d’appréhender le monde. Elle

propose une méthodologie centrée sur les données c'est-à-dire, elle s'intéresse

d'abord aux données, auxquelles elle associe ensuite les traitements. Elle peut

être résumé par la question Sur quoi porte le programme ?"

Remarque : Les frontières 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 procédures est bien décrit impérativement.

3.1.1.1. POURQUOI LA PROGRAMMATION ORIENTÉE

OBJET ? Depuis plusieurs années :

Le développement d’applications de plus en plus performantes et

complexes

En programmation procédurale : coût du logiciel croit de manière

exponentielle avec la

complexité de l’application

3.1.1.2. Objectifs de la programmation orientée objet : + Diminuer le coût du logiciel

+ Augmenter sa durée de vie

+ Augmenter sa réutilisabilité

+ Assurer sa facilité de maintenance

3.1.1.3. QU’EST CE QUE LA PROGRAMMATION

ORIENTÉE OBJET (POO)? Programmation Orientée Objet (POO) : paradigme de programmation

informatique



+ élaboré par Alan Kay, dans les années 70’

+ basé sur la définition et interactions de briques logicielles : objets

3.1.1.4. CONCETPS DE BASE

1. Objet :

Un objet est un concept, une idée ou une entité du monde physique

Exemple : voiture, personne, étudiant, animal, fenêtre graphique, forme

géométrique, ...

Remarque : Dans un programme, un objet s’apparente à une variable

2. Classe Une classe décrit des schémas d’objets. Du point de vue typage, une classe est

vue comme le type des

objets qui seront créés à partir d’elle. Une classe définit les variables (par leur

nom et leur type avec

Éventuellement une valeur initiale) et les méthodes. Elle sert de modèle

pour la création d’objets.

3. Instanciation L’instanciation est l’opération qui consiste à créer un objet à partir d’une classe

On appelle instance d’une classe, un objet avec un comportement et un

état, tous deux définis par sa classe.

4. Notion de constructeur ▸ Un constructeur est une méthode qui permet de créer les objets ou les

instances d’une classe.

▸ Un constructeur a le même nom que la classe.

▸ Un constructeur n’a pas de valeur de retour (même pad « void »).

▸ Plusieurs constructeurs peuvent exister dans une même classe (avec des

arguments différents), on dit qu’ils sont surchargés.

▸ IL faut au moins un constructeur dans une classe pour en instancier des objets.



5. Polymorphisme

Principe Une sous-classe peut redéfinir une méthode héritée de sa super-classe. Cette

redéfinition consiste à changer le code de la méthode de la super-classe mais pas

sa signature (nom, le type et l’ordre de ses paramètres et son type de retour).

Elle est dite polymorphe.

Surcharge : Une même méthode peut avoir plusieurs déclarations différentes

dans la même classe. Cette différence concerne le nombre et le type des

arguments (et du retour) qui peuvent varier.

3.1.2. Langage de modélisation UML

3.1.2.1. Introduction Définition Selon l’OMG (Object Management Group: Fondé en 1989) :

UML : Langage visuel dédié à la spécification, la construction et la

documentation des artefacts d’un système logiciel

UML est un langage de modélisation graphique (et textuelle) conçu pour :

• comprendre et décrire des besoins,

• spécifier et documenter des systèmes,

• esquisser des architectures logicielles,

• concevoir des solutions et

• communiquer des points de vue.

UML unifie à la fois les notations et les concepts orientés objet. Il unifie

également les notations nécessaires aux activités des différentes étapes d’un

processus de développement et sert ainsi comme moyen pour concrétiser le suivi

des décisions prises depuis l’expression des besoins jusqu’au codage.

UML possède des outils de génération automatique de codes (Java, C++, C, …)

comme « Objecteering, StarUML, RationalRose, etc. »

3.1.2.2.Histoire de la modélisation par objets

Les méthodes utilisées dans les années 1980 pour organiser la programmation

impérative (notamment Merise) étaient fondées sur la modélisation séparée des

données et des traitements.



Lorsque la programmation par objets prend de l’importance au début des années

1990, la nécessité d’une méthode qui lui soit adaptée devient évidente. En effet,

rien dans les concepts de base de

l'approche ne dicte comment modéliser la structure objet d'un système de

manière pertinente alors que l'application de ces concepts nécessite une très

grande rigueur.

Plus de cinquante méthodes apparaissent entre 1990 et 1995 (Booch, Classe-

Relation, Fusion, HOOD, OMT, OOA, OOD,OOM, OOSE, etc.) mais aucune

ne parvient à s’imposer. A partir de l’année 1994, le consensus se fait autour des

trois méthodes OMTde James Rumbaugh (1991), OOD de GradyBooch(1991)

et OOSE d’Ivar Jacobson (1992). Événement considérable et presque

miraculeux, les trois gourousqui

régnaient chacun sur l’une des trois méthodes se mirent d’accord pour définir

une méthode commune qui fédérerait leurs apports respectifs (on les surnomme

depuis « the Amigos »). Le langage de modélisation unifié appelé UML

(UnifiedModelingLanguage) est né de cet effort de

convergence. L’adjectif unified est là pour marquer qu’UML unifie, et donc

remplace. L’unification a progressé par étapes :

En 1995, Booch et Rumbaugh (et quelques autres) se sont mis d’accord pour

construire une méthode unifiée, UnifiedMethod 0.8 ;

en 1996, Jacobson les a rejoints pour produire UML 0.9 (remplacement du mot

méthode par le mot langage, plus modeste).

En janvier 1997, UML 1.0 a été soumis à l’OMG (Object Management Group)

par les acteurs les plus importants dans le monde du logiciel et qui se sont

associés à l’effort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.).

En novembre 1997, l’OMG adopta UML 1.1 (9 diagrammes) comme langage

de modélisation des systèmes d’information à objets.

3.1.2.3Nouvelles versions d’UML :

De 1997 à 2003, des modifications/améliorations de la version normalisée

(UML 1.1 à UML1.5)

En 2005, l’OMG a normalisé UML 2.0, en définissant de nouveaux

diagrammes pour représenter des concepts particuliers nouveaux de systèmes

d’information.



En 2007, UML 2.1.1: changements importants au niveau du méta-modèle,

pour permettre d’utiliser UML pour la programmation.

En 2008, UML 2.2

La dernière version diffusée par l'OMG est UML 2.5 en octobre 2012.

3.1.2.4 UML en application

Les auteurs d’UML ont défini un langage graphique qui permet de représenter et

de communiquer les divers aspects d’un système d’information. Aux

graphiques sont associés des textes qui expliquent leur contenu. UML est donc

un métalangage car il fournit les éléments permettant de construire le modèle

qui, lui, sera le langage du projet. La notation associée consiste en un ensemble

de diagrammes

(9 diagrammes dans UML 1 et 14 diagrammes dans UML 2) permettant une

modélisation objet selon différentes vues complémentaires.

• Un diagramme UML est une représentation graphique, qui s'intéresse à un

aspect précis du modèle. C'est une perspective du modèle, pas "le modèle de

système".

• Chaque type de diagramme UML possède une structure (les types des éléments

de modélisation qui le composent sont prédéfinis).

• Un type de diagramme UML véhicule une sémantique précise (un type de

diagramme offre toujours la même vue d'un système).

• Combinés, les différents types de diagrammes UML offrent une vue complète

des aspects statiques et dynamiques d'un système.

• Par extension et abus de langage, un diagramme UML est aussi un modèle (un

diagramme modélise un aspect du modèle global).

Les 14 diagrammes d’UML 2 sont généralement répartis en deux catégories

(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 déploiement (deploymentdiagram)

• De paquetages (package diagram)



• De profils (profile diagram) diagramme de classe simplifié représentant

profiles et classes.

3.1.2.6.Diagrammes de comportement (ou comportementaux):

• De cas d'utilisation (use case diagram)

• De séquence (sequencediagram)

• Vue générale d'interaction (interaction overviewdiagram) d’activité et de

séquence.

• De communication ou de collaboration (communication diagram)

• De temps (timing diagram) fusionne les diagrammes d’états et de séquence.

• D'activité (activitydiagram)

• D'états (state diagram)

Dans la littérature plusieurs façons de répartir les diagrammes UML ont été

proposées basées essentiellement sur différentes vues et aspects du système

L’objectif de notre cours étant une première acquisition des concepts de

modélisation à travers l’utilisation d’un langage unifié, nous nous limitons

9principaux diagrammes (dont 7 seront détaillés dans les chapitres suivants)

répartis sur les trois axes de modélisation : fonctionnel, statique et dynamique

(voir figure 2.1).

Ces diagrammes, d’une utilité variable selon les cas l’occasion d’une

modélisation.

3.1.2.7. Eléments et mécanismes généraux d’UML • Les Éléments sont les briques de base du langage

• Éléments de modélisation: abstractions du système à modéliser.

• Éléments de visualisation: projections textuelles ou graphiques permettant la

manipulation des éléments de modélisation.

• Exemple: acteur: élément de modélisation : élément de visualisation

• Des Mécanismes sont définis pour faciliter la compréhension et

l’interprétation d’un diagramme et permettent ainsi d’étendre UML.

• Stéréotypes

• Étiquettes ou valeurs marquées

• Notes

• Contraintes



3.1.2.8. Présentation de 9 Diagrammes UML

Diagramme de cas d’utilisation Le diagramme de cas d’utilisation représente la structure des grandes

fonctionnalités nécessaires aux utilisateurs du système. C’est le premier

diagramme du modèle UML, celui où s’assure la relation entre l’utilisateur et les

objets que le système met en œuvre.

.Diagramme de classes Le diagramme de classes est généralement considéré comme le plus important

dans un développement orienté objet. Il représente l’architecture conceptuelle du

système : il décrit les classes que le système utilise, ainsi que leurs liens, que

ceux-ci représentent un emboîtement conceptuel (héritage) ou une relation

organique (agrégation).

.Diagramme d’objets Le diagramme d’objets permet d’éclairer un diagramme de classes en l’illustrant

par des exemples. Il est, par exemple, utilisé pour vérifier l’adéquation d’un

diagramme de classes à différents cas possibles.

.Diagramme de composants Un diagramme de composants permet de décrire l’architecture physique et

statique d’une application en termes de composants (modules) et de

dépendances entre ces composants.

Les composants sont des codes (sources, exécutables), des scripts, des fichiers,

des tables, etc. Ils exposent des interfaces représentant les services réalisés par

leurs classeurs.

.Diagramme de déploiement Un diagramme de déploiement montre la disposition physique des différents

matériels(Ou nœuds) qui entrent dans la composition du système, la répartition

des composants au sein des nœuds et les supports.

.Diagramme d’états Le diagramme d’états représente la façon dont évoluent (i.e. cycle de vie) les

objets appartenant à une même classe. La modélisation du cycle de vie est

essentielle pour représenter et mettre en forme la dynamique du système.



.Diagramme d’activités Le diagramme d’activités n’est autre que la transcription dans UML de la

représentation du processus telle qu’elle a été élaborée lors du travail qui a

préparé la modélisation : il montre l’enchaînement des activités qui concourent

au processus. Un diagramme d’activité représente la vue dynamique d’un

ensemble d’éléments sous forme de flux d’exécution.

.Diagramme d’interaction (séquence et collaboration) Un diagramme d’interaction décrit le comportement du système par les

interactions entre les objets qui le composent Il peut se présenter sous deux

formes différentes. Le diagramme de séquence met l’accent sur la séquence

ment dans le temps des interactions et des messages échangés entre objets. Par

contre le diagramme de collaboration focalise sur une représentation spatiale des

objets collaborant par échange de messages.

.Paquetages (Packages) Un Paquetage (sous modèle) : c’est une notion qui peut apparaître dans

beaucoup de diagrammes pour spécifier le regroupement d’éléments au sein

d’un sous-système (cas, classes, objets, composants, autres paquetages, ...) et

aussi pour encapsuler ces éléments.

_ Caractéristiques: sert d’espace de désignation

peut inclure d’autres paquetages et peut importer d’autres paquetages

L’héritage entre paquetages est possible

3.1.3 Processus de développement choisi (processus

unifié) :

3.1- Définition : Le processus unifié est un processus de développement logiciel construit sur

UML. Il est itératif, centré sur l'architecture, piloté par des cas d'utilisation et

orienté vers la diminution des risques. Il regroupe les activités à mener pour

transformer les besoins d’un

utilisateur en système logiciel, C'est un patron de processus pouvant être adaptée

à une large classe de systèmes logiciels, à différents domaines d'application, à

différents types d'entreprises, à

différents niveaux de compétences et à différentes tailles de l'entreprise[16] .



3.2- UP est piloté par les cas d’utilisation : Les cas d’utilisation ne sont pas un simple outil de spécification des besoins du

système. Ils vont complètement guider le processus de développement à travers

l’utilisation de modèles basés sur l’utilisation du langage UML.

3.3- Centré sur l'architecture Tout système complexe doit être décomposé en parties modulaires afin de

garantir une maintenance et une évolution facilitées. Cette architecture

(fonctionnelle, logique, matérielle

...) doit être modélisée en UML et pas seulement documentée en texte.

3.4- UP est itératif et incrémental : Le projet est découpé en itérations de courte durée qui aident mieux suivre

l'avancement global. A la fin de chaque itération, une partie exécutable du

système final est produite de façon incrémental.

3.5- Diminution de risques : Les risques majeurs du projet doivent être identifiés au plut tôt, mais surtout

levés le plus rapidement possible. Les mesures à prendre dans ce cadre

déterminent l'ordre des itérations.

3.6- L’architecture bidirectionnelle : UP gère le développement selon deux axes.

-L'axe vertical représente les principaux enchaînements d'activités, qui

regroupent les activités selon leur nature. Cette dimension rend compte l'aspect

statique du processus qui s'exprime en termes de composants, de processus,

d'activités, d'enchaînements, d'artefacts et de travailleurs.

-L'axe horizontal représente le temps et montre le déroulement 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'itérations et de jalons.



Figure 1 . Les activités d’UP

3.7- Les Activités :

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 modèles de cas d'utilisation

Appréhender les besoins non fonctionnels (technique) et livrer une liste des

exigences.

Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur

et représente sous forme de cas d'utilisation et d'acteur, les besoins du client.

3.7.2-Analyse : L'objectif de l'analyse est d'accéder à une compréhension des besoins et des

exigences du client, Il s'agit de réaliser des spécifications permettant de

concevoir la solution, Un modèle d'analyse livre une spécification complète des

besoins issus des cas d'utilisation et les

Structures sous une forme qui facilite la compréhension (scénarios), la

préparation (définition de l'architecture), la modification et la maintenance du

futur système. Il peut être considéré comme une première ébauche du modèle de

conception.

3.7.3-Conception : La conception permet d'acquérir une compréhension approfondie des contraintes

liées au langage de programmation, à l'utilisation des composants et au système

d'exploitation. Elle détermine les principales interfaces et les transcrit à l'aide

d'une notation commune.



-Elle constitue un point de départ à l'implémentation :

-Elle décompose le travail d'implémentation en sous-système

-Elle créée une abstraction transparente de l'implémentation

3.7.4-Implémentation : L'implémentation est le résultat de la conception pour implémenter le système

sous formes de composants, c'est-à-dire, de code source, de scripts, de binaires,

d'exécutables et d'autres éléments du même type. Les objectifs principaux de

l'implémentation sont de planifier les intégrations des composants pour chaque

itération, et de produire les classes et les sous-systèmes sous formes de codes

sources.

3.7.5-Test : Les tests permettent de vérifier des résultats de l'implémentation en testant la

construction. Pour mener à bien ces tests, il faut les planifier pour chaque

itération, les

implémenter en créant des cas de tests, effectuer ces tests et prendre en compte

le résultat 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 générale du système, les risques majeurs, les délais et

les coûts (On met en place le Projet).

Elle répond aux questions suivantes :

-Que va faire le système ? Par rapport aux utilisateurs principaux, quels services

va-t-il rendre ?

-Quelle va être l'architecture générale (cible) de ce système

-Quels vont être : les délais, les coûts, les ressources, les moyens à déployer ?

3.8.2 - Elaboration : L'élaboration reprend les éléments de la phase d'analyse des besoins et les

précise pour arriver à une spécification détaillée de la solution à mettre en

oeuvre. L'élaboration permet de préciser la plupart des cas d’utilisation, de

concevoir l’architecture du système et surtout de déterminer l'architecture de

référence.

Au terme de cette phase, les chefs de projet doivent être en mesure de prévoir les

activités et d’estimer les ressources nécessaires à l’achèvement du projet.

Les taches à effectuer dans la phase élaboration sont les suivantes :

-Créer une architecture de référence



-Identifier les risques, ceux qui sont de nature à bouleverser le plan, le coût et le

calendrier

-Définir 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ù l’on construit le produit (architecture= produit

complet). Le produit contient tous les cas d’utilisation que les chefs de projet, en

accord avec les utilisateurs ont décidé de mettre au point pour cette version.

3.8.4 - Transition : Un groupe d’utilisateurs essaye le produit et détecte les anomalies et défauts.

Cette phase suppose des activités comme la formation des utilisateurs clients, la

mise en oeuvre d’un service d’assistance et la correction des anomalies

constatées.

3.1.4 Modélisation d’un projet Androïde avec UML

3.2. Programmation mobile

3.2.1 Caractéristiques des systèmes mobiles

Avant d’entamer le développement de l’application, nous allons

présenter quelques éléments d’initiation en liaison avec notre projet

(Internet mobile, Android, …etc). Pour cela, nous commençons par

définir l’Internet mobile, le système d’exploitation mobile en détaillant

celui d’Android, système d’exploitation avec lequel on a développé notre

application. Enfin, nous définissons la sécurisation des communications et

des protocoles.

Technologie de téléphonie mobile

2.1. Technologie 3G

Nommée aussi "technologie de troisième génération", elle est devenue

disponible au public depuis 2013 et elle se base sur la norme de communication

UMTS (Système de télécommunications mobiles universelles). Elle peut

atteindre un débit égal à 2 Mbps (244Ko/s) à partir d'un lieu .



2.2. Technologie 3G+

La 3G+ est une technologie qui permet d’échanger les données de façon plus

rapide et dans des tailles plus importants grâce à l’association simultanée des

systèmes HSDPA (High Speed, Downlink Packet Access) jusqu’à 3 à 5 fois plus

rapide que les technologies précédentes. La 3G+ amène une meilleure

connexion Internet en mobile.

2.3. Technologie 4G

La 4G est le terme utilisé pour désigner la prochaine vague de

technologies mobiles haut débit qui seront utilisés pour remplacer les

réseaux 3G actuels. Les deux principaux prétendants sont LTE (Long

Term Evolution) et WiMAX (Worldwide Interoperability for Microwave

Access).

2.4. Smartphone

C’est un téléphone mobile disposant des performances proches de l’ordinateur.

Par rapport aux téléphones standards, les Smartphones ont généralement des

écrans plus larges et des processeurs plus puissants .La saisie des données se fait

par le biais d'un écran tactile ou d'un clavier. Il fournit des fonctionnalités

basiques comme : l'agenda, le calendrier, la navigation sur le web, le messagerie

instantanée et ainsi le GPS (Système de localisation du véhicule par satellites).

Il dispose d’un OS (système d'exploitation) embarqué pour l’exploitation de ces

capacités : mémoire, le processeur, le capteur, etc.

3.2.2 Systèmes d’exploitation mobiles (comparaison)

Système d’exploitation mobile Le système d'exploitation mobile est un système d'exploitation conçu pour

fonctionner sur un appareil mobile. Pour le faire, il faut qu’il soit non seulement

robuste mais suffisamment flexible pour effectuer des tâches qui dépassent le

champ que l’on connaît dans la micro-informatique. Cela revient à la richesse du

monde mobile. En plus, le Smartphone comporte beaucoup plus de défis que les

stations de travails fixes. Ce type de système d'exploitation se concentre entre

autres sur la gestion de la connectivité sans fil et celle des différents types

d'interface.



3.1. Les différents systèmes d’exploitation sur le marché

Il existe sur le marché des dizaines de systèmes d'exploitation différents :

Symbian OS de Nokia, ios d’Apple, BlackBerry OS de RIM, Windows Phone

de Microsoft, Palm webOS, Bada de Samsung et Android de Google.

Symbian OS

Le Symbian OS est développé par la société éponyme qui est une propriété

exclusive de Nokia. Bien que cette plateforme soit crée par la participation de

plusieurs fabricants tels que Samsung ou Sony Ericsson, ce système est

fortement connoté Nokia, ce qui est un frein à son adoption par d’autres

constructeurs. Il est récemment passé en open source. C’est un système 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 différents générations de iPhone mais également sur

d’autres produits de Apple iPad et iPod touch. Il est dérivé de Mac OS X dont il

partage les fondations : kernel, les services Unix et Cocoa. Pour Apple, le succès

est considérable : début 2009, il n’y avait pas moins de 5 millions de

téléchargements par jour. Donc, il s’agit du concurrent numéro un pour Android.

BlackBerry OS

Le système d'exploitation BlackBerry est la plate-forme exclusive mobile

développé par RIM (Research In Motion ) exclusivement pour ses Smartphones

BlackBerry et les appareils mobiles. RIM utilise ce système d'exploitation pour

soutenir des fonctions spécialisées, notamment le trackball de la marque,

molette, le trackpad et l'écran tactile.

Windows Phone

Windows Mobile, WiMo pour les intimes, est l’OS (système d'exploitation)

mobile de Microsoft. C’est une évolution de Windows Pocket PC, ancêtre de

Windows CE. Cet OS a réussi au fil des années à s’octroyer une part de marché

honorable. Son succès est dû à son affiliation à la famille d’OS Windows, ultra-

dominante sur le bureau. Un autre avantage souvent cité est la facilité de

développement apportée grâce à l’environnement cliquodrome de Visual Studio

qui a su faire venir au développement mobile les développeurs VB (Visual

Basic).



Palm webOS

Il y a quelques années, Palm a même cédé aux sirènes de Windows Mobile en

proposant certains de ses appareils sous l’OS de Microsoft. Palm avait cessé

d’innover et devrait réagir face aux assauts d’Apple et de Google

Symbian OS Ios Blackberry Windows Phone Palm webOS Android

Langage de

programmation

C++ Objective-

C

Java C, C++ HTML,

CSS, JavaScript,

JSON, etc.

Java

gratuit Intégré à

Xcode

Gratuit Gratuit Gratuit Gratuit

Disponibilité de

l’environnement de

développement

Carbide.C++ Xcode JDE Visual Studio,

eMbeddeb VC++

Eclipse,

CodeWarrior,

PocketStudio, HB++

Eclipse,

Netbeans

Multiplate-forme de

déploiement

Samsung iPhone,

iPode

touch,

iPad

Blackberry

seulement

Windows Mobile,

Windows CE

Palm OS Palm,

Windows Mobile

Andoid

seulement

Cout d’outils de

développement

gratuit gratuit1 Gratuit Gratuit Gratuit et

commercial

Gratuit

Magasin en

Ligne

Ovi Store App Store App World Windows

Market

Place

App catalog Android

Market

Open source Oui Non Oui Non Non Oui

Constructeur Nokia Apple RIM Microsoft Palm Google

Tableau 1. Une comparaison entre les systèmes d’exploitation mobile



Figure 2 . Les parts de marché des systèmes d'exploitation mobile pour les années 2011 et

2014

3.2.3 Comparaison par rapport à la programmation classique

Les applications natives sont actuellement les solutions idéales 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 accédera

à votre site depuis un mobile, il découvrira une page adaptée à son appareil, qui

sera donc agréable à 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 coût, car vous ne devez développer et maintenir

qu'une seule version de votre application.

Cette solution a cependant bien entendu ses inconvénients. Une "web app" ne

peut pas profiter de toutes les fonctionnalités d'un smartphone : impossible par

exemple d'utiliser l'appareil photo. Vous êtes également limité au niveau du

stockage des données, ce qui peut rendre impossible le fonctionnement de

l'application lorsqu'il n'y a pas de connexion Internet active. Impossible



é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 développement d'applications pour Android s'effectue avec un ordinateur

personnel sous Mac OS, Windows ou Linux en utilisant le JDK de la plate-

forme Java et des outils pour Android. Des outils qui permettent de manipuler le

téléphone ou la tablette, de la simuler par une machine virtuelle, de créer des

fichiers APK (les fichiers de paquet d'Android), de déboguer les applications et

d'y ajouter une signature numérique. Ces outils sont mis à disposition sous la

forme d'un plugin pour l'environnement de développement Eclipse7.

La bibliothèque d'Android permet la création d'interfaces graphiques selon un

procédé similaire aux frameworks de quatrième génération que sont XUL,

JavaFX ou Silverlight: l'interface graphique peut être construite par déclaration

et peut être utilisée avec plusieurs skins - chartes graphiques. La programmation

consiste à déclarer la composition de l'interface dans des fichiers XML ; la

description peut comporter des ressources (des textes et des pictogrammes). Ces

déclarations sont ensuite transformées en objets tels que des fenêtres et des

boutons, qui peuvent être manipulés par de la programmation Java9. Les écrans

ou les fenêtres (activités dans le jargon d'Android), sont remplis de plusieurs

vues ; chaque vue étant une pièce d'interface graphique (bouton, liste, case à

cocher…). Android 3.0, destiné aux tablettes, introduit la notion de fragments:

des panneaux contenant plusieurs éléments visuels. Une tablette ayant -

contrairement à un téléphone - généralement suffisamment de place à l'écran

pour plusieurs panneaux

3.3. Programmation mobile sous Android

Le système d’exploitation Android

4.1. Définition et historique

Android est un système d’exploitation Open Source pour Smartphone, PDA

(Personal Digital Assistant) et terminaux mobiles conçu par Android, une

startup rachetée par Google, et annoncé le 15 novembre 2007. Le terme Android

fait référence au nom « androïde » qui désigne un robot construit à l’image d’un

être humain.

https://fr.wikipedia.org/wiki/Mac_OS

https://fr.wikipedia.org/wiki/Microsoft_Windows

https://fr.wikipedia.org/wiki/Linux

https://fr.wikipedia.org/wiki/Java_Development_Kit

https://fr.wikipedia.org/wiki/Machine_virtuelle

https://fr.wikipedia.org/wiki/Paquet_%28logiciel%29

https://fr.wikipedia.org/wiki/Signature_num%C3%A9rique

https://fr.wikipedia.org/wiki/Plugin

https://fr.wikipedia.org/wiki/Environnement_de_d%C3%A9veloppement

https://fr.wikipedia.org/wiki/Eclipse_%28projet%29

https://fr.wikipedia.org/wiki/Eclipse_%28projet%29

https://fr.wikipedia.org/wiki/Interface_graphique

https://fr.wikipedia.org/wiki/XML-based_User_interface_Language

https://fr.wikipedia.org/wiki/JavaFX

https://fr.wikipedia.org/wiki/Silverlight

https://fr.wikipedia.org/wiki/Extensible_Markup_Language

https://fr.wikipedia.org/wiki/Android#cite_note-K9ZAs-9



Afin de promouvoir ce système ouvert, Google a su fédérer autour de lui une

trentaine de partenaires réunis 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 d’Android

La répartition des différentes versions Android est représentée dans le tableau

suivant :

Version Nom API Level Distribution

1.5 Cupcake 3 0.2%

1.6 Donut 4 0.5%

2.1 Eclair 7 4.2%

2.2 Froyo 8 15.5%

2.3 – 2.3.2 Gingerbread 9 0.3%

2.3.3 – 2.3.7 10 60.3%

3.1 Honeycomb 12 0.5%

3.2 13 1.8%

4.0 – 4.0.2 Ice Cream

Sandwich

14 0.1%

4.0.3 – 4.0.4 15 15.8%

4.1 Jelly Bean 16 0.8%

Tableau 2. Les versions de l’Android

C’est les dernières statistiques qui datent du janvier 2013 concernant la

répartition des différentes versions Android.



Figure 3. La part de chaque version d'Android

La figure 2 est basée sur le nombre d'appareils Android qui ont accédé au

Google Play, dans un délai de 14 jours se terminant à la date de la collecte des

données ci-dessous.

Nous avons la grande proportion de terminaux qui sont équipés par la

version Android 2.3 qui est toujours leader avec 45,6%, on

peut s’apercevoir 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

L’Androïde se fond sur la version 2,6 de Linux pour des services système de

noyaux tels que le système de sécurité, la gestion de mémoire, la gestion de

processus industriel, le réseau et le modèle de pilote. Le noyau agit sur la couche

d'abstraction entre le matériel et le logiciel.

Librairies

Au-dessus du noyau kernel , proprement dit, se loge un ensemble de librairies

natives constituant les couches bases du système. Ces librairies sont écrites en

C/C++ et utilisées par les différentes composantes du système Android.



Android Runtime L’Android inclut un ensemble de bibliothèques de base qui fournit la plupart des

fonctionnalités disponibles dans les bibliothèques de base du langage de

programmation Java. Les applications s’exécutent chacun dans son propre

processus.

Une application sous Android s’exécute dans son propre processus, avec son

propre instance de machine virtuelle Dalvik. Ce dernier exécute des fichiers

avec l’extension " .dex " qui est optimisé pour une empreinte mémoire

minimale. Le VM Dalvik s'appuie sur le noyau Linux pour les fonctionnalités de

base telles que la gestion de la mémoire de bas niveau.

Application Framework Les développeurs ont un accès complet à l'API. L'architecture d'application est

conçue pour rendre la réutilisation des composants plus simple. En fait, chaque

application peut publier ses capacités et d’autres applications peuvent alors faire

usage de ces capacités. Toutes les applications sous-jacentes sont un ensemble

des services et des systèmes.

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 l’androide



4.4. Kit de développement

Exploiter une nouvelle plate-forme n’est jamais été une chose aisée. C’est

pourquoi Google fournit, en plus du système d’exploitation, un kit de

développement (Software Development Toolkit ou SDK). Ce SDK est un

ensemble d’outils qui permet aux développeurs et aux entreprises de créer des

applications. Il est disponible gratuitement sur le site de Google.

Le SDK Android est composé de plusieurs éléments afin d’aider les

développeurs à créer et à maintenir des applications :

Des outils ;

Des exemples de code ;

De la documentation ;

Des API (interfaces de programme d’application).

Les outils Le SDK est livré avec un certain nombre d’outils couvrant différents aspects du

cycle de développement d’une application Android. Le kit de développement

propose une boîte à outils complète pour les tâches de compilation, de débogage,

de génération de code AIDL et de la signature de l’application, etc.

L’émulateur Android : c’est un téléphone virtuel qui permet de tester les

applications qui sont entrain de se développer. Il est lancé par la commande

"emulator ". Celle-ci prend en paramètre l’image AVD (Android Virtual Device)

qui sera montée en mémoire. Il a des limitations par exemple : il n’est pas

capable de supporter le Bluetooth ainsi qu’il ne permet pas le teste des

applications de réalité augmentée.

Les API Android offre plusieurs API (Application Program Interface) tel que :

Google Cartes : intègre et contrôle l’affichage d’une carte dans une interface

graphique de l’application.

Géo localisation : permet d’accéder au service de localisation du système, de

choisir le fournisseur en fonction des critères et de préciser la position actuelle

du téléphone (latitude, longitude, vitesse, etc.).



Les exemples de code Le kit de développement est accompagné d’un certain nombre d’exemples

illustrant les possibilités du SDK Android. Parmi ces exemples, on peut citer :

un jeu du serpent et le projet qui couvre l’utilisation de plusieurs exemples de

l’API Android comme les alarmes, les notifications et les menus.

La documentation La documentation du SDK Android est scindée en deux parties bien distinctes :

Le guide du développeur qui est disponible en HTML (Hypertext Markup

Language) dans le répertoire du SDK qu’on vient d’installer ;

La documentation des API au format javadoc est également située dans le

répertoire docs et accessible grâce au chemin débutant du répertoire

d’installation.

La Géolocalisation Parmi les fonctionnalités les plus appréciées sur les plates-formes mobiles

modernes, la géolocalisation permet de réaliser des applications innovantes.

Grâce à Google Cartes notamment, elle est au coeur d’Android.

Le service de géolocalisation récupère les coordonnées de l’utilisateur et les

envoie pour la réalisation un service informatique. A chaque fois, il demande

l’autorisation de l’utilisateur avant la réalisation de cette opération. Seules les

informations concernant la latitude et la longitude sont envoyées.

La localisation du mobile se fait selon plusieurs technologies comme :

GPS : il s'effectue par la réception de signaux provenant de plusieurs satellites

qui se trouve en orbite. Le téléphone mobile équipé d'un GPS permettra de

transmettre sa position via un réseau SMS, GPRS, Edge ou UMTS.

Internet : La précision de la localisation par adresse IP sur le réseau internet se

situera au niveau d'un pays, d'une ville ou d'un quartier selon l'opérateur

(national ou local). Cependant, au sein d'un réseau ADSL d'un même opérateur,

la géolocalisation peut être très précise (adresse ou bâtiment par exemple) si les

lieux des connexions sont enregistrées dans une base de donnés.



Wifi : La localisation est similaire au cas du réseau GSM ou IP, par les cellules

émettrices, avec une précision inférieure à 100 mètres. Une triangulation entre

plusieurs antennes Wifi peut donner la position avec une précision d'environ 5m

par l'analyse de la puissance du signal radio reçu de l'appareil.

GSM : il est basé sur le code unique de la carte SIM. La connexion au réseau

est autorisée après une identification à une cellule composant le réseau GSM. La

précision dépend de l'étendue de la cellule, de 250 mètres en zone urbaine à 10

km en zone rurale.

La sécurisation des communications

Pour assurer une communication sécurisée entre le client et le serveur, il est

obligatoire utiliser des protocoles de cryptage. On trouve aussi des protocoles de

communication qui garantissent la sécurisation du canal de transport des

données comme HTTPS (HyperText Transfer Protocole Secured).

6.1. La définition du protocole HTTPS

"HyperText Transfer Protocole Secured" (HTTPS) est un protocole de transfert

hypertexte sécurisé qui a été développé par Netscape.

Il correspond à une version sécurisée du http (HyperText Transfer Protocole).

Le HTTPS répond aux différents problèmes de confidentialité que protocole http

a connu.

L'idée principale de HTTPS est de créer un canal sécurisé sur un réseau non

sécurisé et d’assurer une protection raisonnable contre les oreilles indiscrètes à

condition que les suites de chiffrement adéquat soient utilisées et que le

certificat de serveur soit vérifié et approuvé.

6.2. Les objectifs de sécurité assurés

Le protocole HTTPS fournit les objectifs de sécurité 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 données échangées : Il est impossible d'espionner les

informations échangées.



L'intégrité des données échangées : Il est impossible de truquer les informations

échangées.

La spontanéité : la connexion de client avec le serveur est transparente.

Conclusion

Durant ce chapitre, nous avons présenté les technologies utilisées et leurs

fonctionnalités.

Android et iOS "dominent le monde" - La domination d'Android sur le

marché mondial des smartphones ne se dément pas. Ainsi sur les 287,8

millions de terminaux livrés 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

livrés dans le monde, soit 301,3 millions d’unités, 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 très rentable pour la firme. D'après IDC, la part de marché d'iOS sur le

haut de gamme est considérable, de l'ordre de 84,6%, contre seulement 19,82%

pour Android. L'OS Google domine en revanche sur l'entrée de gamme, laissée

de côté par Apple, puisque 58,6% des androphones livrés sur la période

appartiennent à ce segment. Du côté de Windows Phone, la ventilation par

catégories est relativement similaire.

3.3.2 Structure d’un projet Android

Une application Android consiste en un assemblage de composants liés via un

fichier de configuration, qui présentent en quelque sorte les briques sur

lesquelles se repose l'application. Ces concepts fondamentaux à préciser sont :

Les vues

Les Views sont les composants basiques de l'interface graphique. Ce sont les

éléments de l'interface que l'utilisateur voit et sur lesquels il agit. C'est de la

classe View qu'héritent les widgets

(exemple de composants graphiques tel que les boutons), les layouts(le plan sur

lequel on organise



et on place les composants graphiques) et tous les composants graphiques

servant à la création d'une interface graphique interactive.

- Les contrôles

C'est bien la classe des composants graphiques cités dessus. Les contrôles sont

tels que les boutons, les champs de saisie de texte, les cases à cocher, etc.

- Les activités

Une Activity représente la fenêtre qui sera affichée à l'utilisateur. C'est un

ensemble de vues et de contrôles composant une interface logique. Elle permet

également de gérer des fonctionnalités 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 puisés les textes, les images, les couleurs, etc.

- Le fichier de configuration

C'est fichier auto généré par l'application, qui lui est indispensable. C'est un

fichier XML appelé « AndroidManifest» qui décrit le point d'entrée de

l'application (le code à exécuter), les composants du projet ainsi que les

permissions nécessaires pour l'exécution du programme.

Une illustration explicative de ces concepts est représentée par le schéma de la

figure 4.



Figure 5. Composition d’une application androïde

5.1.2 Conception architecturale

Il est primordiale à la conception de tout système informatique de choisir le

modèle d'architecture qui lui sera adéquat pouvant assurer un bon

fonctionnement, des meilleurs performances ainsi que la réutilisation et

l'interconnexion fiable de ce système avec d'autres.

C'est à cet effet que nous optons pour le modèle MVC qui sera également très

pratique pour gérer l'interaction entre les différents composants de notre

application Android.

Nous décrivons cette architecture dans la section suivante.

5.1.3 Architecture MVC

L'architecture MVC (modèle, vue et contrôleur) est une architecture à trois

couches utilisée pour la programmation client/serveur et d'interface graphique.

C'est un modèle architectural très puissant qui intervient dans la réalisation d'une

applica-

tion. Il tire sa puissance de son concept de base qui est la séparation des données

(modèle), de l'affichage (vue) et des actions (contrôleur).



C'est trois couches sont décrites comme suit:

- Modèle

Il correspond aux données stockées généralement dans une base de données.

Dans un langage orientée objet ces données sont exploitées sous forme de

classes. Le modèle peut aussi agir sur la vue en mettant à jour ses données.

- Vue

Ne contenant que les informations liées à l'affichage, la vue se contente

d'afficher le contenu qu'elle reçoit sans avoir connaissance des données. En bref,

c'est l'interface homme machine de l'application.

- Contrôleur

Le contrôleur sert de base à récupérer les informations, de les traiter en fonction

des paramètres demandés par la vue (par l'utilisateur), puis de renvoyer à la vue

les données afin d'être affichées. C'est donc l'élément qui va utiliser les données

pour les envoyer à la vue.

L'interaction entre ces trois couches est décrite à l'aide de la figure 5.

Figure 6 Architecture MVC



Les avantages apportés par l'architecture MVC sont :

- La séparation des données de la vue et du contrôleur (ce qui permet une

conception claire et efficace de l'application)

- Une indépendance des données, de l'affichage et des actions (ce qui donne plus

de souplesse pour la maintenabilité et l'évolutivité du système).

- Un gain de temps de maintenance et d'évolution de l'application.

Chapitre 4 : Conception du projet




4.1 Etude Préliminaire

4.1.1 Présentation du projet à réaliser

Pour une meilleure compréhension du travail effectué, nous

présentons dans ce chapitre l’étape d’analyse et de conception. En

effet, pour réaliser une bonne conception de l’application, il faut

faire une étude approfondie des exigences du marché du travail.

Dans ce chapitre, nous commencerons par une étude préliminaire

qui consiste à repérer les besoins fonctionnels et non fonctionnels.

Par suite, nous avons élaborés une modélisation claire de ce qui a

été établi au cours de cette étude. Aussi, ce chapitre sera dédié pour

la conception architecturale de notre application.

4.1.2 Recueil des besoins fonctionnels (Cahier de charge)

1- Géolocaliser : permet au conducteur de connaitre sa position sur la carte.

2- Naviguer sur la carte : permet au conducteur de consulter, d'agrandir, de

rétrécir et de se déplacer dans la carte.

3.3.1- Zoomer plus

3.3.2- Zoomer moins

3.3.3- Se déplacer

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 , l’instant de son signallement….)

6-Elaborer des chemins possibles :contruire des chemins entre deux point

données.

4.1.3 Identification des acteurs : on a un seul acteur (le conducteur).

4.1.4 Modélisation du contexte & identification des messages



Figure 7. Diagramme de contexte statique

4.2 Capture des besoins fonctionnels

4.2.1 Identification des cas d’utilisations

(Diagrammes des cas d’utilisations de chaque acteur)

4.2.2 Élaboration des diagrammes de cas d’utilisations : Un cas d’utilisation correspond à un certain nombre d’actions que le système

devra exécuter en réponse à un besoin d’un acteur. Un cas d’utilisation doit

produire un résultat observable pour un ou plusieurs acteurs ou parties prenantes

du système.

Une interaction permet de décrire les échanges entre un acteur et un cas

d’utilisation.

Pour identifier les cas d’utilisation de façon pragmatique il est judicieux de

dissocier les acteurs du système en s’intéressant aux fonctionnalités qu’ils

peuvent enclencher.

4.2.2.1- Diagramme des cas d’utilisation des conducteurs :



Figure 8. Diagramme de cas d’utilisation

4.2.3. Description textuelle des cas d’utilisations :

1-Géo localiser :

Cas d’utilisation : Géo localiser Acteurs principaux Conducteur

Acteurs secondaires Aucun

Pré conditions le conducteur doit être déjà entrain d’utiliser

l’application. Post conditions Connaitre la position actuelle.

Scénario nominale 1. conducteur indique au système qu’il veut

géo localiser.

2. Le système récupère les coordonnés de la

position.

3. système affiche un marqueur sur la position

actuelle. Scénario alternatif Aucun

Tableau 3. Cas d’utilisation « Geo localiser»



2-Naviguer sur la carte :

Cas d’utilisation : Naviguer sur la carte Acteurs principaux Conducteur Acteurs secondaires Aucun

Pré conditions L’application soit en cours d’utilisation Post condition Affichage d’une nouvelle vue de la carte

Scénario nominale 1. conducteur indique au système qu’il veut

naviguer sur la carte.

2.le système affiche la carte.

3.Conducteur fait les indications (les choix)

4.le Systeme Prendre en considérations les

choix.

Scénario alternatif Aucun

Tableau 4. Cas d’utilisation « Naviguer sur la carte»

3-Trouver des stations et des services :

Cas d’utilisations : Trouver station et service

Acteurs principaux Conducteur Acteurs secondaires SGBD

Pré conditions Le conducteur doit naviguer sur la carte

Post conditions Le système affiche les services et les stations

proches

Scénario nominale 1 .le conducteur indique au système qu’il veut

chercher service ou station

2. système lui indique qu'il peut chercher avec

des spécifications.

3. Le conducteur donne son choix.

4. Le Système prend en considération le choix

de Le conducteur.

5. Le système exécute la demande.

6. Le système affiche le résultat de la

recherche.

Scénario alternatif Aucun Tableau 5. Cas d’utilisation « Trouver des stations et des services»



4-Signaler des alertes :

Cas d’utilisation : Signaler les alertes

acteurs principaux Conducteur Acteurs secondaires SGBD

Pré condition Le conducteur entrain d’utiliser l’application

Post condition Le système affiche que l’alerte est ajoutée avec

succès.

Scénario nominale 1. Géo localiser (cas d’utilisation).

2. le conducteur fait une longue clique sur la

carte.

3. le system lui affiche une boite de dialogue

Spécifié le type d’alerte.

4.le conducteur choisit le type d’alerte.

5.le système affiche l’icône d’alerte et un

message de succès.

Scénario alternatif 5.1.si il y a un problème de connexion le

système n’affiche pas l’icône et affiche un

message d’erreur. Tableau 6. Cas d’utilisation « Signaler des alertes»

4.2.4. Elaboration des diagrammes de séquence et diagramme d’activités:

Pour chaque cas d’utilisation, nous allons élaborer un diagramme de séquence

système qui décrit le cas sous forme d'interaction (séquence) entre un acteur et le

système, qui est toujours considéré comme une boite noire, son comportement

est décrit comme il est perçu de l’extérieur par l’utilisateur.

1. Géo localiser :



Figure 9. Diagramme de séquence de cas « Géo localiser »

Figure 10 Diagramme d’Activiez de cas « Géo localiser »

2. Naviguer sur la carte :



Figure 11. Diagramme de séquence de cas « Naviguer sur la carte »

Figure 12 Diagramme d’activée de cas « Naviguer sur la carte»




Figure 13. Diagramme de séquence de cas « Trouver des stations et des services »

Figure 14. Diagramme d’activité de cas « Trouver des stations et des services »




Figure 15 Diagramme de séquence de cas « Signaler des alertes »



Figure 16. Diagramme de séquence de cas « Signaler des alertes »



4.3 Analyse

4.3.1 Diagrammes de classes utilisés dans chaque cas d’utilisation

1-Géo localiser :

Figure 17. Diagramme de class de cas « Géo localiser »

2-Naviguer sur la carte :

Figure 18. Diagramme de class de cas « Naviguer sur la cartes »




Figure 19. Diagramme de class de cas « Trouver des stations et des services »


Figure 20. Diagramme de class de cas « Signaler des alertes »



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



Figure 23. Diagramme de class complet

4.3.3 Attributs et méthodes de chaque classe