Upload
anonymous-ob2u638a8s
View
35
Download
1
Embed Size (px)
Citation preview
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.
Rapport de Fin d’Etude
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.
Rapport de Fin d’Etude
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
Rapport de Fin d’Etude
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
Rapport de Fin d’Etude
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
Rapport de Fin d’Etude
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
Rapport de Fin d’Etude
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
Rapport de Fin d’Etude Page 9
Chapitre 1 : Introduction générale
Rapport de Fin d’Etude Page 10
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é.
Chapitre 1 : Introduction générale
Rapport de Fin d’Etude Page 11
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
Rapport de Fin d’Etude Page 12
Chapitre 2 : Contexte du projet
Rapport de Fin d’Etude Page 13
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
Chapitre 2 : Contexte du projet
Rapport de Fin d’Etude Page 14
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.
Chapitre 2 : Contexte du projet
Rapport de Fin d’Etude Page 15
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, ….)
Chapitre 2 : Contexte du projet
Rapport de Fin d’Etude Page 16
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
Rapport de Fin d’Etude Page 17
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 18
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
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 19
+ é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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 20
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 21
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 22
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)
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 23
• 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
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 24
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 25
.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] .
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 26
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 27
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 28
-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
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 29
-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 .
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 30
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 31
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).
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 32
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
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 33
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
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 34
é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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 35
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 36
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 37
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
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 38
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.).
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 39
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 40
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 41
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
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 42
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.
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 43
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).
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 44
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
Chapitre 3 : Notions préliminaires
Rapport de Fin d’Etude Page 45
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
Rapport de Fin d’Etude Page 46
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 47
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
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 48
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 :
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 49
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»
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 50
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»
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 51
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 :
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 52
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 :
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 53
Figure 11. Diagramme de séquence de cas « Naviguer sur la carte »
Figure 12 Diagramme d’activée de cas « Naviguer sur la carte»
3-Trouver des stations et des services :
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 54
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 »
4-Signaler des alertes :
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 55
Figure 15 Diagramme de séquence de cas « Signaler des alertes »
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 56
Figure 16. Diagramme de séquence de cas « Signaler des alertes »
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 57
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 »
3-Trouver des stations et des services :
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 58
Figure 19. Diagramme de class de cas « Trouver des stations et des services »
4-Signaler des alertes :
Figure 20. Diagramme de class de cas « Signaler des alertes »
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 59
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
Chapitre 4 : Conception du projet
Rapport de Fin d’Etude Page 60
Figure 23. Diagramme de class complet
4.3.3 Attributs et méthodes de chaque classe