Memoire Fin d EtudeXX

Click here to load reader

  • date post

    09-Jul-2016
  • Category

    Documents

  • view

    22
  • download

    1

Embed Size (px)

Transcript of Memoire Fin d EtudeXX

  • Remerciements

    Nous sommes trs reconnaissants envers tous ceux qui, par leurs

    Comptences scientifiques et leurs qualits humaines, ont contribu au bon

    droulement de ce mmoire.

    Nous exprimons toute notre reconnaissance Dr.Benlalla Nabil, davoir bien

    voulu me faire lhonneur de prsider le jury de ce mmoire.

    Nous tenons remercier tout dabord Mr. Chaouche, pour ses valeureux conseils

    et pour la confiance et la sympathie quil nous

    a accorde en acceptant de nous encadrer et quil nous a tmoigne au cours de ce

    projet de Fin dtudes.

    Nous tenons aussi exprimer notre profonde reconnaissance tous mes

    collgues, mes parents... Pour ses conseils, ses commentaires prcieux et le suivi

    de ce travail.

  • Rapport de Fin dEtude

    Remerciements

    Nous sommes trs reconnaissants envers tous ceux qui, par leurs

    comptences scientifiques et leurs qualits humaines, ont contribu au bon

    droulement de ce mmoire.

    Nous exprimons toute notre reconnaissance Dr,Benlalla davoir bien voulu me

    faire lhonneur de prsider le jury de ce mmoire.

    Nous tenons remercier tout dabord Mr.Chaouch ,pour ses valeureux conseils et

    pour la confiance et la sympathie quil nous

    a accorde en acceptant de nous encadrer et quil nous a tmoigne au cours de ce

    projet de Fin dtudes.

    Nous tenons aussi exprimer notre profonde reconnaissance tout mes collgues

    pour ses conseils, ses commentaires prcieux et le suivi de ce travail.

  • Rapport de Fin dEtude

    Rsum

    Les autoroutes daujourdhui seront gres de manire plus intelligente et

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

    daccident, mais aussi, une assistance temps-rel des conducteurs.

    Le but de ce projet est de raliser une application mobile native pour systme

    Android, dont l'IHM est reprsente par une carte gographique interactive. Il

    s'agit de dvelopper un systme coopratif pour assister les voyageurs et les

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

    possible. Afin dassurer la communication temps-rel et la persistance des

    donnes, le systme devrait fonctionner dynamiquement en se basant sur un

    serveur distant (par exemple, le centre dinfrastructure routire). Ceci rendra les

    vhicules, travers notre application, sensibles leur contexte changeant.

  • Rapport de Fin dEtude

    Sommaire

    1. Chapitre 1 : Introduction gnral ..........................................................................09

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

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

    2.2. Le besoin dintgrer linformatique dans les autoroutes pour une conduite sre....15

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

    3. Chapitre 3 : Notions prliminaires .....17

    3.1. Processus de dveloppement et langage de modlisation 18

    3.1.1. Approche Oriente Objet .........18

    3.1.2. Langage de modlisation UML ..20

    3.1.3. Processus de dveloppement choisi .....25

    3.1.4. Modlisation dun projet Androde avec UML 29

    3.2. Programmation mobile .....29

    3.2.1. Caractristiques des systmes mobiles 29

    3.2.2. Systmes dexploitation mobiles (comparaison) ....30

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

    3.2.4. Choix de la plateforme mobile (Androde) ....34

    3.3. Programmation mobile sous Androde ...34

    3.3.1. Architecture et versions dAndrode ..35

    3.3.2. Structure dun projet Androde . 35

    3.3.3. Excution sur des Appareils et sur lmulateur ..45

    4. Chapitre 4 : Conception du projet .46

    4.1. Etude Prliminaire 47

    4.1.1. Prsentation du projet raliser ..47

    4.1.2. Recueil des besoins fonctionnels ....47

    4.1.3. Identification des acteurs .47

    4.1.4. Modlisation du contexte & identification des messages ..47

    4.2. Capture des besoins fonctionnels ..48

    4.2.1 Identification des cas dutilisations .48

    4.2.2 Diagramme complet de cas dutilisations ...48

    4.2.3 Description dtaille des cas dutilisations .49

    4.2.4 Structuration des cas dutilisations dans des packages ...51

  • Rapport de Fin dEtude

    4.3. Analyse 57

    4.3.1. Diagrammes de classes utilises dans chaque cas dutilisation ..57

    4.3.2. Diagrammes de classes compltes ..60

    4.3.3. Attributs et mthodes de chaque classe ..60

    5. Chapitre 5 : Implmentation du projet ....

    5.1.Plateforme matrielle .00

    5.2. Plateforme logicielle ....00

    5.3. Prsentation de lapplication ..00

    6. Chapitre 6 : Exprimentation .00

    6.1. Captures dcrans des activits .00

    6.2. Navigabilit de lapplication entre les activits..00

    7. Chapitre 7 : Conclusion gnrale......00

    Bibliothque ..00

  • Rapport de Fin dEtude

    LISTE DES FIGURES

    Figure 1. Les activits dUP 27

    Figure 2 Les parts de march des systmes d'exploitation mobile

    pour les annes 2011 et 2014... 33

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

    Figure 4. Architecture logiciel de landroide.. 37

    Figure 5. Composition dune application androde 43

    Figure 6. Architecture MVC 44

    Figure 7. Diagramme de contexte statique 48

    Figure 8. Diagramme de cas dutilisation.. 49

    Figure 9. Diagramme de squence de cas Go localiser .. 52

    Figure 10. Diagramme dActiviez de cas Go localiser . 52

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

    Figure 12. Diagramme dactive de cas Naviguer sur la carte. 53

    Figure 13 Diagramme de squence de cas Trouver des stations et des services ..54

    Figure 14. Diagramme dactivit de cas Trouver des stations et des services 54

    Figure 15. Diagramme de squence de cas Signaler des alertes .. 55

    Figure 16. Diagramme de squence de cas Signaler des alertes ... 56

    Figure 17. Diagramme de class de cas Go localiser 57

    Figure 18. Diagramme de class de cas Naviguer sur la cartes .. 57

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

    Figure 20. Diagramme de class de cas Signaler des alertes. 58

    Figure 21. Diagramme de class de cas associer des informations aux alertes .. 59

    Figure 22 Diagramme de class de cas Elaborer des chemins possibles . 59

    Figure 23. Diagramme de class complet 60

  • Rapport de Fin dEtude

    Liste des tableaux

    Tableau 1. Une comparaison entre les systmes dexploitation mobile.. 32

    Tableau 2. Les versions de lAndroid. 35

    Tableau 3. Cas dutilisation Geo localiser.. 49

    Tableau 4. Cas dutilisation Naviguer sur la carte 50

    Tableau 5. Cas dutilisation Trouver des stations et des services.. 50

    Tableau 6. Cas dutilisation Signaler des alertes 51

  • Rapport de Fin dEtude

    LISTE DES ABREVIATIONS

    WAP:Wireless Application Protocol

    UMTS:Universal Mobile Telecommunications System

    HSDPA:High Speed, Downlink Packet Access

    LTE:Long Team Evolution

    WIMAX:Worldwide Interoperability for Microwave Access

    GPS:Global Positioning System

    OS: Operating System

    IOS: Internetwork Operating System

    RIM: Research In Motion

    VB: Visual Basic

    IDC: International Data Corporation

    OHA: Open Handset Alliance

    SDK: Software Development Toolkit

    API: Application Program Interface

    AVD: Android Visual Device

    HTML: Hypertext Markup Language

    HTTPS: Hypertext Transfer Protocol Secured

    HTTP: Hypertext Transfer Protocol

    XML:eXtensible Markup Language

    SGML: Standard Generalized Markup Language

    SGBD:SystemManagementDatabases

  • Chapitre 1 : Introduction gnrale

    Rapport de Fin dEtude Page 9

  • Chapitre 1 : Introduction gnrale

    Rapport de Fin dEtude Page 10

    Introduction gnrale

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

    annonc -Tomi Ahonen-, meilleur auteur technologique et mdiatique succs,

    consultant de stratgie et orateur motivationnel.

    Les tlphones portables sont devenus les premiers mdias de masse dans le

    monde (on compte 6,8 milliards d'abonns au tlphone mobile). Il n'est pas un

    PC plus bte, mais un tlphone portable est considr comme un autre support

    gnrer des formes mdiatiques.

    Il a subit une volution une vitesse surprenante, passant du premier tlphone

    portable invent par Dr Martin Cooper -un directeur gnral de Motorola- en

    1973 qui a t la premire personne faire un appel depuis son tlphone

    portable, aux ordiphones, PDA et Smartphones qui disposent d'un systme

    d'exploitation adoptant des applications tierces qui leur sont ddies.

    L'invention du premier PDA au monde, Le PenPad conu par Apple, tait dans

    le but de pouvoir prendre des notes, grer son agenda, ses adresses, effectuer des

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

    Aujourd'hui ces priphriques ont atteint une puissance de calcul, une taille

    mmoire ainsi qu'un dbit ncessaire pour faire tourner des applications aussi

    diverses que varies qui vont de l'Outlook mobile jusqu'aux applications de

    navigation GPS.

    Les plates-formes de distribution de ces applications sont en plein essor,

    Windows Phone 7 son magasin d'applications, l'iPhone l'App Store, Android

    son Market, etc.

    Ce qui ne cesse d'inciter beaucoup de dveloppeurs l'laboration des petits

    logiciels trs priss en profitant des multiples apports des plateformes prsentes

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

    3G, 4G etc.).

    En effet, la go localisation du GPS des tlphones intelligents >> est trs utile

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

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

    quotidiens de la communaut.

  • Chapitre 1 : Introduction gnrale

    Rapport de Fin dEtude 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 ddie au

    tlphone mobile, dot de la plateforme Android, permettant au assurs la go

    localisation de nos autoroutes Est-Ouest, signaler et positionner des alertes et

    des marqueurs et les associer des informations ,laborer des chemins possibles ,

    proposer une navigation et raliser la persistance des donnes laide dun

    serveur distantetc.

    Le travail effectu a fait lobjet de sept chapitres. Le premier chapitre prsente

    une introduction gnrale. Le deuxime chapitre prsente les contextes du

    projet. Le troisime chapitre dtaille les notions prliminaires. Le quatrime

    chapitre porte sur la conception du projet. Le cinquime chapitre prsente

    limplmentation du projet. Le sixime chapitre est une exprimentation pour le

    projet et le dernier chapitre une conclusion gnrale, nous prsentons une

    synthse ainsi que les perspectives en raison damliorer les performances de

    lapplication.

  • Chapitre 2 : Contexte du projet

    Rapport de Fin dEtude Page 12

  • Chapitre 2 : Contexte du projet

    Rapport de Fin dEtude Page 13

    2.1. Caractristiques de lautoroute est-ouest : Historique:

    Le projet d'autoroute reliant les grandes villes du nord est envisag ds

    les annes 1970 par le ministre du plan. Par la suite, les diffrents

    schmas directeurs routiers nationaux (1975-1995 et 1995-2015) vont

    l'inclure dans leurs projections.

    Les tudes prliminaires ont t ralises en 1983. Elles ont port sur

    le choix du couloir du trac, les prvisions du trafic, lvolution des

    indicateurs conomiques et les diffrentes incidences du projet, elles

    ont donn lieu, au cours de leur ralisation, de nombreuses

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

    des Ministres au mois de juin 1987.

    Les tudes davant projet sommaires (APS) sur environ 1 100 km entre

    Annaba et Tlemcen ont t engages en 1988 et termines en 19943.

    Annes 1990, financement compliqu:

    Le financement du projet par les pouvoirs publics dans un contexte

    d'endettement est trs compliqu. Durant les annes 1990 et 2000, les

    premiers tronons sont financs par des prts europens, arabes et

    africains dans le cadre du dveloppement.

    Le 18 juin 1990, la Banque Europenne d'investissement (BEI)

    accorde un prt de 40 millions d' pour un premier tronon de 30 km

    entre Blida et El Affroun4. Un an plus tard en 1991, la mme

    institution prte 31 millions d' pour le contournement de la ville de

    Bouira5. En 1993 et 1994, c'est un total de 100 millions d' qui sont

    dbloqus pour le tronon Lakhdaria - Bouira6. De nouveau 140

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

    terminer ces deux tronons est et ouest d'un total 80 km. Leur

    ralisation par des entreprises algriennes ne sera acheve qu'entre

    2004 et 2006.

    Le 3 octobre 1995, un nouveau tronon de 30 km entre El Affroun

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

    enveloppe de 266 millions de dinars est dgage pour les

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

    Dveloppement Economique et Social (FADES) accorde un prt de 86

  • Chapitre 2 : Contexte du projet

    Rapport de Fin dEtude Page 14

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

    ralisation10,11.

    Entre 1996 et 2002, la Banque Africaine de Dveloppement (BAD) a

    accord un prt de 161 millions de $ pour le tronon de contournement

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

    Meridj12,13,14. Seil un premier tronon de 15 km sera achev en

    2004.

    2005, financement public:

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

    le prsident Abdelaziz Bouteflika dcide en fvrier 2005, prs d'un an

    aprs sa rlection de financer l'intgralit des tronons restants par le

    trsor public, contre l'avis de son ministre des finances15.

    Le 25 juillet 2005, un dcret excutif est publi pour dclarer d'utilit

    publique l'opration portant ralisation de lautoroute Est-Ouest sur

    l'ensemble de son trac16.

    Lancement et attribution:

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

    prcis, pour le projet de l'autoroute Est-Ouest fut lanc le 23 juillet

    2005. Plusieurs rponses furent enregistres (amricaine, franaise,

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

    t slectionns : le chinois CITIC-CRCC et le japonais COJAAL. Les

    rsultats furent annoncs le 15 avril 2006 et les contrats de ralisation

    signs le 18 septembre 2006.

    Bureaux d'tudes:

    Les missions de contrle et de suivi du projet est passe par un autre

    appel d'offres qui a vu la slection :

    du bureau d'tudes canadien "Dessau Soprane" pour le contrle et le

    suivi

    du bureau d'tudes franais "EGIS-ROUTE" pour la tranche ouest

    du bureau d'tudes canadien "SNC LAVALIN" pour la tranche centre

    du groupement italien "ANAS ITALCONSULT" pour la tranche est.

    Chronologie :

    Si le projet de l'Autoroute Est-Ouest a dmarr en 2006, plusieurs

    tronons existaient dj. Les nouveaux tronons ont commenc tre

    livrs petit petit depuis 2008.

  • Chapitre 2 : Contexte du projet

    Rapport de Fin dEtude Page 15

    Les tronons Ouest et Centre, raliss par le groupement chinois

    CITIC-CRCC, ont t livrs la circulation, mais les travaux ne seront

    pas achevs avant 2016 sur la section Est, raliss par le groupement

    japonais Cojaal. Des problmes techniques ainsi que l'incapacit de

    Cojaal raliser ce type d'infrastructures pourraient expliquer ce

    retard. Un scandale de corruption avait dj clabouss le projet en

    2010 et la qualit des travaux raliss par CITIC-CRCC ne serait pas

    conforme aux normes internationales et des travaux de rfection ont

    dj t ncessaires17.

    2.2. Le besoin dintgrer linformatique dans les autoroutes pour une conduite sre :

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

    tlvision ou sur le Web beaucoup des journaux quils parlons des accidents et

    ses consquences dans nos autoroutes et les nombres risqus de les victimes

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

    solutions : le besoins dintgrer linformatique dans nos voitures pour une

    conduite sre

    Non seulement, moins de risques daccident, mais aussi, une assistance temps-

    rel des conducteurs.

    2. 3. Exploitation des nouvelles technologies mobiles

    pour assister les conducteurs :

    Le dveloppement de notre application est ralis sous Android. Nous

    permettrons dacqurir les composants fondamentaux servant ce projet.

    Lautoroute Est-Ouest tant considre comme lautoroute o sera dploy le

    systme, une carte dtaille de cette autoroute sera labore sous

    OpenStreetCarte (Base de donne gographique open source).Pour des raisons

    daffichage efficace et dinteractivit de lapplication, une bibliothque Android

    spcialise devra tre utilise pour exploiter la carte pralablement labore.

    Lapplication dvelopper sera fonde sur diffrentes capacits en liens avec

    une carte :

    Dplacer ou zoomer le fond de carte sur des espaces (routes, aires de

    services, borne dappel durgence, .)

  • Chapitre 2 : Contexte du projet

    Rapport de Fin dEtude Page 16

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

    bouchons, )

    Associer des informations aux alertes : la nature de lalerte, linstant de

    son signalement,

    Elaborer des chemins possibles et proposer une navigation base sur la

    go localisation .etc.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 17

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 18

    3.1. Processus de dveloppement et langage de

    modlisation

    3.1.1. Approche Oriente Objet :

    Lapproche oriente objet est une nouvelle mthode de programmation qui

    tend se rapprocher de notre manire naturelle dapprhender le monde. Elle

    propose une mthodologie centre sur les donnes c'est--dire, elle s'intresse

    d'abord aux donnes, auxquelles elle associe ensuite les traitements. Elle peut

    tre rsum par la question Sur quoi porte le programme ?"

    Remarque : Les frontires entre ces deux paradigmes ne sont pas toujours

    franches pour un langage

    de programmation donn. Par exemple, Java est un langage orient objet

    mais le corps des fonctions

    ou procdures est bien dcrit imprativement.

    3.1.1.1. POURQUOI LA PROGRAMMATION ORIENTE

    OBJET ? Depuis plusieurs annes :

    Le dveloppement dapplications de plus en plus performantes et

    complexes

    En programmation procdurale : cot du logiciel croit de manire

    exponentielle avec la

    complexit de lapplication

    3.1.1.2. Objectifs de la programmation oriente objet : + Diminuer le cot du logiciel + Augmenter sa dure de vie + Augmenter sa rutilisabilit + Assurer sa facilit de maintenance

    3.1.1.3. QUEST CE QUE LA PROGRAMMATION ORIENTE OBJET (POO)? Programmation Oriente Objet (POO) : paradigme de programmation

    informatique

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 19

    + labor par Alan Kay, dans les annes 70 + bas sur la dfinition et interactions de briques logicielles : objets

    3.1.1.4. CONCETPS DE BASE

    1. Objet :

    Un objet est un concept, une ide ou une entit du monde physique

    Exemple : voiture, personne, tudiant, animal, fentre graphique, forme

    gomtrique, ...

    Remarque : Dans un programme, un objet sapparente une variable

    2. Classe Une classe dcrit des schmas dobjets. Du point de vue typage, une classe est

    vue comme le type des

    objets qui seront crs partir delle. Une classe dfinit les variables (par leur

    nom et leur type avec

    ventuellement une valeur initiale) et les mthodes. Elle sert de modle

    pour la cration dobjets.

    3. Instanciation Linstanciation est lopration qui consiste crer un objet partir dune classe

    On appelle instance dune classe, un objet avec un comportement et un

    tat, tous deux dfinis par sa classe.

    4. Notion de constructeur Un constructeur est une mthode qui permet de crer les objets ou les

    instances dune classe.

    Un constructeur a le mme nom que la classe.

    Un constructeur na pas de valeur de retour (mme pad void ).

    Plusieurs constructeurs peuvent exister dans une mme classe (avec des

    arguments diffrents), on dit quils sont surchargs.

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

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 20

    5. Polymorphisme

    Principe Une sous-classe peut redfinir une mthode hrite de sa super-classe. Cette

    redfinition consiste changer le code de la mthode de la super-classe mais pas

    sa signature (nom, le type et lordre de ses paramtres et son type de retour).

    Elle est dite polymorphe.

    Surcharge : Une mme mthode peut avoir plusieurs dclarations diffrentes

    dans la mme classe. Cette diffrence concerne le nombre et le type des

    arguments (et du retour) qui peuvent varier.

    3.1.2. Langage de modlisation UML

    3.1.2.1. Introduction Dfinition Selon lOMG (Object Management Group: Fond en 1989) :

    UML : Langage visuel ddi la spcification, la construction et la

    documentation des artefacts dun systme logiciel

    UML est un langage de modlisation graphique (et textuelle) conu pour :

    comprendre et dcrire des besoins,

    spcifier et documenter des systmes,

    esquisser des architectures logicielles,

    concevoir des solutions et

    communiquer des points de vue.

    UML unifie la fois les notations et les concepts orients objet. Il unifie

    galement les notations ncessaires aux activits des diffrentes tapes dun

    processus de dveloppement et sert ainsi comme moyen pour concrtiser le suivi

    des dcisions prises depuis lexpression des besoins jusquau codage.

    UML possde des outils de gnration automatique de codes (Java, C++, C, )

    comme Objecteering, StarUML, RationalRose, etc.

    3.1.2.2.Histoire de la modlisation par objets

    Les mthodes utilises dans les annes 1980 pour organiser la programmation

    imprative (notamment Merise) taient fondes sur la modlisation spare des

    donnes et des traitements.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 21

    Lorsque la programmation par objets prend de limportance au dbut des annes

    1990, la ncessit dune mthode qui lui soit adapte devient vidente. En effet,

    rien dans les concepts de base de

    l'approche ne dicte comment modliser la structure objet d'un systme de

    manire pertinente alors que l'application de ces concepts ncessite une trs

    grande rigueur.

    Plus de cinquante mthodes apparaissent entre 1990 et 1995 (Booch, Classe-

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

    ne parvient simposer. A partir de lanne 1994, le consensus se fait autour des

    trois mthodes OMTde James Rumbaugh (1991), OOD de GradyBooch(1991)

    et OOSE dIvar Jacobson (1992). vnement considrable et presque

    miraculeux, les trois gourousqui

    rgnaient chacun sur lune des trois mthodes se mirent daccord pour dfinir

    une mthode commune qui fdrerait leurs apports respectifs (on les surnomme

    depuis the Amigos ). Le langage de modlisation unifi appel UML

    (UnifiedModelingLanguage) est n de cet effort de

    convergence. Ladjectif unified est l pour marquer quUML unifie, et donc

    remplace. Lunification a progress par tapes :

    En 1995, Booch et Rumbaugh (et quelques autres) se sont mis daccord pour

    construire une mthode unifie, UnifiedMethod 0.8 ;

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

    mthode par le mot langage, plus modeste).

    En janvier 1997, UML 1.0 a t soumis lOMG (Object Management Group)

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

    associs leffort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.).

    En novembre 1997, lOMG adopta UML 1.1 (9 diagrammes) comme langage

    de modlisation des systmes dinformation objets.

    3.1.2.3Nouvelles versions dUML :

    De 1997 2003, des modifications/amliorations de la version normalise

    (UML 1.1 UML1.5)

    En 2005, lOMG a normalis UML 2.0, en dfinissant de nouveaux

    diagrammes pour reprsenter des concepts particuliers nouveaux de systmes

    dinformation.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 22

    En 2007, UML 2.1.1: changements importants au niveau du mta-modle,

    pour permettre dutiliser UML pour la programmation.

    En 2008, UML 2.2

    La dernire version diffuse par l'OMG est UML 2.5 en octobre 2012.

    3.1.2.4 UML en application

    Les auteurs dUML ont dfini un langage graphique qui permet de reprsenter et

    de communiquer les divers aspects dun systme dinformation. Aux

    graphiques sont associs des textes qui expliquent leur contenu. UML est donc

    un mtalangage car il fournit les lments permettant de construire le modle

    qui, lui, sera le langage du projet. La notation associe consiste en un ensemble

    de diagrammes

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

    modlisation objet selon diffrentes vues complmentaires.

    Un diagramme UML est une reprsentation graphique, qui s'intresse un

    aspect prcis du modle. C'est une perspective du modle, pas "le modle de

    systme".

    Chaque type de diagramme UML possde une structure (les types des lments

    de modlisation qui le composent sont prdfinis).

    Un type de diagramme UML vhicule une smantique prcise (un type de

    diagramme offre toujours la mme vue d'un systme).

    Combins, les diffrents types de diagrammes UML offrent une vue complte

    des aspects statiques et dynamiques d'un systme.

    Par extension et abus de langage, un diagramme UML est aussi un modle (un

    diagramme modlise un aspect du modle global).

    Les 14 diagrammes dUML 2 sont gnralement rpartis en deux catgories

    (diagrammes de structure et diagrammes de comportement).

    3.1.2.5.Diagrammes de structure (ou structurels):

    De classes (class diagram)

    D'objets (objectdiagram)

    De composants (component diagram)

    De structure composite (composite structure diagram)

    De dploiement (deploymentdiagram)

    De paquetages (package diagram)

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 23

    De profils (profile diagram) diagramme de classe simplifi reprsentant

    profiles et classes.

    3.1.2.6.Diagrammes de comportement (ou comportementaux):

    De cas d'utilisation (use case diagram)

    De squence (sequencediagram)

    Vue gnrale d'interaction (interaction overviewdiagram) dactivit et de

    squence.

    De communication ou de collaboration (communication diagram)

    De temps (timing diagram) fusionne les diagrammes dtats et de squence.

    D'activit (activitydiagram)

    D'tats (state diagram)

    Dans la littrature plusieurs faons de rpartir les diagrammes UML ont t

    proposes bases essentiellement sur diffrentes vues et aspects du systme

    Lobjectif de notre cours tant une premire acquisition des concepts de

    modlisation travers lutilisation dun langage unifi, nous nous limitons

    9principaux diagrammes (dont 7 seront dtaills dans les chapitres suivants)

    rpartis sur les trois axes de modlisation : fonctionnel, statique et dynamique

    (voir figure 2.1).

    Ces diagrammes, dune utilit variable selon les cas loccasion dune

    modlisation.

    3.1.2.7. Elments et mcanismes gnraux dUML Les lments sont les briques de base du langage

    lments de modlisation: abstractions du systme modliser.

    lments de visualisation: projections textuelles ou graphiques permettant la

    manipulation des lments de modlisation.

    Exemple: acteur: lment de modlisation : lment de visualisation

    Des Mcanismes sont dfinis pour faciliter la comprhension et

    linterprtation dun diagramme et permettent ainsi dtendre UML.

    Strotypes

    tiquettes ou valeurs marques

    Notes

    Contraintes

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 24

    3.1.2.8. Prsentation de 9 Diagrammes UML

    Diagramme de cas dutilisation Le diagramme de cas dutilisation reprsente la structure des grandes

    fonctionnalits ncessaires aux utilisateurs du systme. Cest le premier

    diagramme du modle UML, celui o sassure la relation entre lutilisateur et les

    objets que le systme met en uvre.

    .Diagramme de classes Le diagramme de classes est gnralement considr comme le plus important

    dans un dveloppement orient objet. Il reprsente larchitecture conceptuelle du

    systme : il dcrit les classes que le systme utilise, ainsi que leurs liens, que

    ceux-ci reprsentent un embotement conceptuel (hritage) ou une relation

    organique (agrgation).

    .Diagramme dobjets Le diagramme dobjets permet dclairer un diagramme de classes en lillustrant

    par des exemples. Il est, par exemple, utilis pour vrifier ladquation dun

    diagramme de classes diffrents cas possibles.

    .Diagramme de composants Un diagramme de composants permet de dcrire larchitecture physique et

    statique dune application en termes de composants (modules) et de

    dpendances entre ces composants.

    Les composants sont des codes (sources, excutables), des scripts, des fichiers,

    des tables, etc. Ils exposent des interfaces reprsentant les services raliss par

    leurs classeurs.

    .Diagramme de dploiement Un diagramme de dploiement montre la disposition physique des diffrents

    matriels(Ou nuds) qui entrent dans la composition du systme, la rpartition

    des composants au sein des nuds et les supports.

    .Diagramme dtats Le diagramme dtats reprsente la faon dont voluent (i.e. cycle de vie) les

    objets appartenant une mme classe. La modlisation du cycle de vie est

    essentielle pour reprsenter et mettre en forme la dynamique du systme.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 25

    .Diagramme dactivits Le diagramme dactivits nest autre que la transcription dans UML de la

    reprsentation du processus telle quelle a t labore lors du travail qui a

    prpar la modlisation : il montre lenchanement des activits qui concourent

    au processus. Un diagramme dactivit reprsente la vue dynamique dun

    ensemble dlments sous forme de flux dexcution.

    .Diagramme dinteraction (squence et collaboration) Un diagramme dinteraction dcrit le comportement du systme par les

    interactions entre les objets qui le composent Il peut se prsenter sous deux

    formes diffrentes. Le diagramme de squence met laccent sur la squence

    ment dans le temps des interactions et des messages changs entre objets. Par

    contre le diagramme de collaboration focalise sur une reprsentation spatiale des

    objets collaborant par change de messages.

    .Paquetages (Packages) Un Paquetage (sous modle) : cest une notion qui peut apparatre dans

    beaucoup de diagrammes pour spcifier le regroupement dlments au sein

    dun sous-systme (cas, classes, objets, composants, autres paquetages, ...) et

    aussi pour encapsuler ces lments.

    _ Caractristiques: sert despace de dsignation

    peut inclure dautres paquetages et peut importer dautres paquetages

    Lhritage entre paquetages est possible

    3.1.3 Processus de dveloppement choisi (processus

    unifi) :

    3.1- Dfinition : Le processus unifi est un processus de dveloppement logiciel construit sur

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

    orient vers la diminution des risques. Il regroupe les activits mener pour

    transformer les besoins dun

    utilisateur en systme logiciel, C'est un patron de processus pouvant tre adapte

    une large classe de systmes logiciels, diffrents domaines d'application,

    diffrents types d'entreprises,

    diffrents niveaux de comptences et diffrentes tailles de l'entreprise[16] .

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 26

    3.2- UP est pilot par les cas dutilisation : Les cas dutilisation ne sont pas un simple outil de spcification des besoins du

    systme. Ils vont compltement guider le processus de dveloppement travers

    lutilisation de modles bass sur lutilisation du langage UML.

    3.3- Centr sur l'architecture Tout systme complexe doit tre dcompos en parties modulaires afin de

    garantir une maintenance et une volution facilites. Cette architecture

    (fonctionnelle, logique, matrielle

    ...) doit tre modlise en UML et pas seulement documente en texte.

    3.4- UP est itratif et incrmental : Le projet est dcoup en itrations de courte dure qui aident mieux suivre

    l'avancement global. A la fin de chaque itration, une partie excutable du

    systme final est produite de faon incrmental.

    3.5- Diminution de risques : Les risques majeurs du projet doivent tre identifis au plut tt, mais surtout

    levs le plus rapidement possible. Les mesures prendre dans ce cadre

    dterminent l'ordre des itrations.

    3.6- Larchitecture bidirectionnelle : UP gre le dveloppement selon deux axes.

    -L'axe vertical reprsente les principaux enchanements d'activits, qui

    regroupent les activits selon leur nature. Cette dimension rend compte l'aspect

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

    d'activits, d'enchanements, d'artefacts et de travailleurs.

    -L'axe horizontal reprsente le temps et montre le droulement du cycle de vie

    du processus ; cette dimension rend compte de l'aspect dynamique du processus

    qui s'exprime en terme de cycles, de phases, d'itrations et de jalons.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 27

    Figure 1 . Les activits dUP

    3.7- Les Activits :

    3.7.1- Expression des besoins : L'expression des besoins permet de :

    Inventorier les besoins principaux et fournir une liste de leurs fonctions

    Recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui

    conduisent l'laboration des modles de cas d'utilisation

    Apprhender les besoins non fonctionnels (technique) et livrer une liste des

    exigences.

    Le modle de cas d'utilisation prsente le systme du point de vue de l'utilisateur

    et reprsente sous forme de cas d'utilisation et d'acteur, les besoins du client.

    3.7.2-Analyse : L'objectif de l'analyse est d'accder une comprhension des besoins et des

    exigences du client, Il s'agit de raliser des spcifications permettant de

    concevoir la solution, Un modle d'analyse livre une spcification complte des

    besoins issus des cas d'utilisation et les

    Structures sous une forme qui facilite la comprhension (scnarios), la

    prparation (dfinition de l'architecture), la modification et la maintenance du

    futur systme. Il peut tre considr comme une premire bauche du modle de

    conception.

    3.7.3-Conception : La conception permet d'acqurir une comprhension approfondie des contraintes

    lies au langage de programmation, l'utilisation des composants et au systme

    d'exploitation. Elle dtermine les principales interfaces et les transcrit l'aide

    d'une notation commune.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 28

    -Elle constitue un point de dpart l'implmentation :

    -Elle dcompose le travail d'implmentation en sous-systme

    -Elle cre une abstraction transparente de l'implmentation

    3.7.4-Implmentation : L'implmentation est le rsultat de la conception pour implmenter le systme

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

    d'excutables et d'autres lments du mme type. Les objectifs principaux de

    l'implmentation sont de planifier les intgrations des composants pour chaque

    itration, et de produire les classes et les sous-systmes sous formes de codes

    sources.

    3.7.5-Test : Les tests permettent de vrifier des rsultats de l'implmentation en testant la

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

    itration, les

    implmenter en crant des cas de tests, effectuer ces tests et prendre en compte

    le rsultat de chacun.

    3.8 -Les Phases :

    3.8.1 - Analyse des besoins : L'analyse des besoins donne une vue du projet sous forme de produit fini, Cette

    phase porte essentiellement sur les besoins principaux (du point de vue de

    l'utilisateur), l'architecture gnrale du systme, les risques majeurs, les dlais et

    les cots (On met en place le Projet).

    Elle rpond aux questions suivantes :

    -Que va faire le systme ? Par rapport aux utilisateurs principaux, quels services

    va-t-il rendre ?

    -Quelle va tre l'architecture gnrale (cible) de ce systme

    -Quels vont tre : les dlais, les cots, les ressources, les moyens dployer ?

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

    prcise pour arriver une spcification dtaille de la solution mettre en

    oeuvre. L'laboration permet de prciser la plupart des cas dutilisation, de

    concevoir larchitecture du systme et surtout de dterminer l'architecture de

    rfrence.

    Au terme de cette phase, les chefs de projet doivent tre en mesure de prvoir les

    activits et destimer les ressources ncessaires lachvement du projet.

    Les taches effectuer dans la phase laboration sont les suivantes :

    -Crer une architecture de rfrence

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 29

    -Identifier les risques, ceux qui sont de nature bouleverser le plan, le cot et le

    calendrier

    -Dfinir les niveaux de qualit atteindre

    - Formuler les cas d'utilisation pour couvrir les besoins fonctionnels et planifier

    la phase de construction

    -Elaborer une offre abordant les questions de calendrier, de personnel et de

    budget

    3.8.3 - Construction : La construction est le moment o lon construit le produit (architecture= produit

    complet). Le produit contient tous les cas dutilisation que les chefs de projet, en

    accord avec les utilisateurs ont dcid de mettre au point pour cette version.

    3.8.4 - Transition : Un groupe dutilisateurs essaye le produit et dtecte les anomalies et dfauts.

    Cette phase suppose des activits comme la formation des utilisateurs clients, la

    mise en oeuvre dun service dassistance et la correction des anomalies

    constates.

    3.1.4 Modlisation dun projet Androde avec UML

    3.2. Programmation mobile

    3.2.1 Caractristiques des systmes mobiles

    Avant dentamer le dveloppement de lapplication, nous allons

    prsenter quelques lments dinitiation en liaison avec notre projet

    (Internet mobile, Android, etc). Pour cela, nous commenons par

    dfinir lInternet mobile, le systme dexploitation mobile en dtaillant

    celui dAndroid, systme dexploitation avec lequel on a dvelopp notre

    application. Enfin, nous dfinissons la scurisation des communications et

    des protocoles.

    Technologie de tlphonie mobile

    2.1. Technologie 3G

    Nomme aussi "technologie de troisime gnration", elle est devenue

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

    UMTS (Systme de tlcommunications mobiles universelles). Elle peut

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

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 30

    2.2. Technologie 3G+

    La 3G+ est une technologie qui permet dchanger les donnes de faon plus

    rapide et dans des tailles plus importants grce lassociation simultane des

    systmes HSDPA (High Speed, Downlink Packet Access) jusqu 3 5 fois plus

    rapide que les technologies prcdentes. La 3G+ amne une meilleure

    connexion Internet en mobile.

    2.3. Technologie 4G

    La 4G est le terme utilis pour dsigner la prochaine vague de

    technologies mobiles haut dbit qui seront utiliss pour remplacer les

    rseaux 3G actuels. Les deux principaux prtendants sont LTE (Long

    Term Evolution) et WiMAX (Worldwide Interoperability for Microwave

    Access).

    2.4. Smartphone

    Cest un tlphone mobile disposant des performances proches de lordinateur.

    Par rapport aux tlphones standards, les Smartphones ont gnralement des

    crans plus larges et des processeurs plus puissants .La saisie des donnes se fait

    par le biais d'un cran tactile ou d'un clavier. Il fournit des fonctionnalits

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

    instantane et ainsi le GPS (Systme de localisation du vhicule par satellites).

    Il dispose dun OS (systme d'exploitation) embarqu pour lexploitation de ces

    capacits : mmoire, le processeur, le capteur, etc.

    3.2.2 Systmes dexploitation mobiles (comparaison)

    Systme dexploitation mobile Le systme d'exploitation mobile est un systme d'exploitation conu pour

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

    robuste mais suffisamment flexible pour effectuer des tches qui dpassent le

    champ que lon connat dans la micro-informatique. Cela revient la richesse du

    monde mobile. En plus, le Smartphone comporte beaucoup plus de dfis que les

    stations de travails fixes. Ce type de systme d'exploitation se concentre entre

    autres sur la gestion de la connectivit sans fil et celle des diffrents types

    d'interface.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 31

    3.1. Les diffrents systmes dexploitation sur le march

    Il existe sur le march des dizaines de systmes d'exploitation diffrents :

    Symbian OS de Nokia, ios dApple, BlackBerry OS de RIM, Windows Phone

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

    Symbian OS

    Le Symbian OS est dvelopp par la socit ponyme qui est une proprit

    exclusive de Nokia. Bien que cette plateforme soit cre par la participation de

    plusieurs fabricants tels que Samsung ou Sony Ericsson, ce systme est

    fortement connot Nokia, ce qui est un frein son adoption par dautres

    constructeurs. Il est rcemment pass en open source. Cest un systme libre,

    open source se base sur un noyau Symbian.

    Ios

    IOS (Internetwork Operating System), qui tait nomm iPhone OS, se trouve

    non seulement sur les diffrents gnrations de iPhone mais galement sur

    dautres produits de Apple iPad et iPod touch. Il est driv de Mac OS X dont il

    partage les fondations : kernel, les services Unix et Cocoa. Pour Apple, le succs

    est considrable : dbut 2009, il ny avait pas moins de 5 millions de

    tlchargements par jour. Donc, il sagit du concurrent numro un pour Android.

    BlackBerry OS

    Le systme d'exploitation BlackBerry est la plate-forme exclusive mobile

    dvelopp par RIM (Research In Motion ) exclusivement pour ses Smartphones

    BlackBerry et les appareils mobiles. RIM utilise ce systme d'exploitation pour

    soutenir des fonctions spcialises, notamment le trackball de la marque,

    molette, le trackpad et l'cran tactile.

    Windows Phone

    Windows Mobile, WiMo pour les intimes, est lOS (systme d'exploitation)

    mobile de Microsoft. Cest une volution de Windows Pocket PC, anctre de

    Windows CE. Cet OS a russi au fil des annes soctroyer une part de march

    honorable. Son succs est d son affiliation la famille dOS Windows, ultra-

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

    dveloppement apporte grce lenvironnement cliquodrome de Visual Studio

    qui a su faire venir au dveloppement mobile les dveloppeurs VB (Visual

    Basic).

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 32

    Palm webOS

    Il y a quelques annes, Palm a mme cd aux sirnes de Windows Mobile en

    proposant certains de ses appareils sous lOS de Microsoft. Palm avait cess

    dinnover et devrait ragir face aux assauts dApple et de Google

    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 Intgr

    Xcode

    Gratuit Gratuit Gratuit Gratuit

    Disponibilit de

    lenvironnement de

    dveloppement

    Carbide.C++ Xcode JDE Visual Studio,

    eMbeddeb VC++

    Eclipse,

    CodeWarrior,

    PocketStudio, HB++

    Eclipse,

    Netbeans

    Multiplate-forme de

    dploiement

    Samsung iPhone,

    iPode

    touch,

    iPad

    Blackberry

    seulement

    Windows Mobile,

    Windows CE

    Palm OS Palm,

    Windows Mobile

    Andoid

    seulement

    Cout doutils de

    dveloppement

    gratuit gratuit1 Gratuit Gratuit Gratuit et

    commercial

    Gratuit

    Magasin en

    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 systmes dexploitation mobile

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 33

    Figure 2 . Les parts de march des systmes d'exploitation mobile pour les annes 2011 et

    2014

    3.2.3 Comparaison par rapport la programmation classique

    Les applications natives sont actuellement les solutions idales mais si votre

    budget n'est pas suffisant, tout n'est pas perdu pour la cause.

    Une application web mobile est un site Internet optimis pour la taille des petits

    crans (smartphones et tablettes). Cela signifie que lorsqu'un utilisateur accdera

    votre site depuis un mobile, il dcouvrira une page adapte son appareil, qui

    sera donc agrable lire et utiliser.

    L'avantage principal de cette solution est que votre application sera accessible

    sur toutes les plateformes, et pas uniquement aux possesseurs d'un iPhone par

    exemple. Et cela moindre cot, car vous ne devez dvelopper et maintenir

    qu'une seule version de votre application.

    Cette solution a cependant bien entendu ses inconvnients. Une "web app" ne

    peut pas profiter de toutes les fonctionnalits d'un smartphone : impossible par

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

    stockage des donnes, ce qui peut rendre impossible le fonctionnement de

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

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude 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 dveloppement 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

    tlphone ou la tablette, de la simuler par une machine virtuelle, de crer des

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

    d'y ajouter une signature numrique. Ces outils sont mis disposition sous la

    forme d'un plugin pour l'environnement de dveloppement Eclipse7.

    La bibliothque d'Android permet la cration d'interfaces graphiques selon un

    procd similaire aux frameworks de quatrime gnration que sont XUL,

    JavaFX ou Silverlight: l'interface graphique peut tre construite par dclaration

    et peut tre utilise avec plusieurs skins - chartes graphiques. La programmation

    consiste dclarer la composition de l'interface dans des fichiers XML ; la

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

    dclarations sont ensuite transformes en objets tels que des fentres et des

    boutons, qui peuvent tre manipuls par de la programmation Java9. Les crans

    ou les fentres (activits dans le jargon d'Android), sont remplis de plusieurs

    vues ; chaque vue tant une pice d'interface graphique (bouton, liste, case

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

    des panneaux contenant plusieurs lments visuels. Une tablette ayant -

    contrairement un tlphone - gnralement suffisamment de place l'cran

    pour plusieurs panneaux

    3.3. Programmation mobile sous Android

    Le systme dexploitation Android

    4.1. Dfinition et historique

    Android est un systme dexploitation Open Source pour Smartphone, PDA

    (Personal Digital Assistant) et terminaux mobiles conu par Android, une

    startup rachete par Google, et annonc le 15 novembre 2007. Le terme Android

    fait rfrence au nom androde qui dsigne un robot construit limage dun

    tre humain.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 35

    Afin de promouvoir ce systme ouvert, Google a su fdrer autour de lui une

    trentaine de partenaires runis au sein de l'OHA (Open Handset Alliance). En

    fait, plus de 50 entreprises ont particip l'OHA, Qualcomm, y compris,

    Broadcom, HTC, Intel, Samsung, Motorola, Sprint, Texas Instruments et le

    japonais KDDI transporteurs sans fil et NTT DoCoMo.

    Le T-Mobile G1, a t annonc le 23 Septembre 2008, et a t le premier

    Smartphone Android OS pour tre officiellement introduit sur le march.

    3.3.1 Architecture et versions dAndroid

    La rpartition des diffrentes versions Android est reprsente dans le tableau

    suivant :

    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 lAndroid

    Cest les dernires statistiques qui datent du janvier 2013 concernant la

    rpartition des diffrentes versions Android.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 36

    Figure 3. La part de chaque version d'Android

    La figure 2 est base sur le nombre d'appareils Android qui ont accd au

    Google Play, dans un dlai de 14 jours se terminant la date de la collecte des

    donnes ci-dessous.

    Nous avons la grande proportion de terminaux qui sont quips par la

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

    peut sapercevoir aussi que la version Android 4.0 prend une bonne proportion

    du march avec 29%. Les autres versions restent anecdotiques avec 1,3 % pour

    Honeycomb (Android 3.x), 2,2 % pour Eclair (Android 2.1) et 0,2 % pour Donut

    (Android 1.6)

    Architecture logiciell

    Linux Kernel

    LAndrode se fond sur la version 2,6 de Linux pour des services systme de

    noyaux tels que le systme de scurit, la gestion de mmoire, la gestion de

    processus industriel, le rseau et le modle de pilote. Le noyau agit sur la couche

    d'abstraction entre le matriel et le logiciel.

    Librairies

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

    natives constituant les couches bases du systme. Ces librairies sont crites en

    C/C++ et utilises par les diffrentes composantes du systme Android.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 37

    Android Runtime LAndroid inclut un ensemble de bibliothques de base qui fournit la plupart des

    fonctionnalits disponibles dans les bibliothques de base du langage de

    programmation Java. Les applications sexcutent chacun dans son propre

    processus.

    Une application sous Android sexcute dans son propre processus, avec son

    propre instance de machine virtuelle Dalvik. Ce dernier excute des fichiers

    avec lextension " .dex " qui est optimis pour une empreinte mmoire

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

    base telles que la gestion de la mmoire de bas niveau.

    Application Framework Les dveloppeurs ont un accs complet l'API. L'architecture d'application est

    conue pour rendre la rutilisation des composants plus simple. En fait, chaque

    application peut publier ses capacits et dautres applications peuvent alors faire

    usage de ces capacits. Toutes les applications sous-jacentes sont un ensemble

    des services et des systmes.

    Applications Android sera livr avec un ensemble d'applications de base, dont un client de

    messagerie, le programme de SMS, calendrier, cartes, navigateur, Contacts, et

    d'autres. Toutes les applications sont crites en utilisant le langage de

    programmation Java.

    Figure 4 . Architecture logiciel de landroide

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 38

    4.4. Kit de dveloppement

    Exploiter une nouvelle plate-forme nest jamais t une chose aise. Cest

    pourquoi Google fournit, en plus du systme dexploitation, un kit de

    dveloppement (Software Development Toolkit ou SDK). Ce SDK est un

    ensemble doutils qui permet aux dveloppeurs et aux entreprises de crer des

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

    Le SDK Android est compos de plusieurs lments afin daider les

    dveloppeurs crer et maintenir des applications :

    Des outils ;

    Des exemples de code ;

    De la documentation ;

    Des API (interfaces de programme dapplication).

    Les outils Le SDK est livr avec un certain nombre doutils couvrant diffrents aspects du

    cycle de dveloppement dune application Android. Le kit de dveloppement

    propose une bote outils complte pour les tches de compilation, de dbogage,

    de gnration de code AIDL et de la signature de lapplication, etc.

    Lmulateur Android : cest un tlphone virtuel qui permet de tester les

    applications qui sont entrain de se dvelopper. Il est lanc par la commande

    "emulator ". Celle-ci prend en paramtre limage AVD (Android Virtual Device)

    qui sera monte en mmoire. Il a des limitations par exemple : il nest pas

    capable de supporter le Bluetooth ainsi quil ne permet pas le teste des

    applications de ralit augmente.

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

    Google Cartes : intgre et contrle laffichage dune carte dans une interface

    graphique de lapplication.

    Go localisation : permet daccder au service de localisation du systme, de

    choisir le fournisseur en fonction des critres et de prciser la position actuelle

    du tlphone (latitude, longitude, vitesse, etc.).

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 39

    Les exemples de code Le kit de dveloppement est accompagn dun certain nombre dexemples

    illustrant les possibilits du SDK Android. Parmi ces exemples, on peut citer :

    un jeu du serpent et le projet qui couvre lutilisation de plusieurs exemples de

    lAPI Android comme les alarmes, les notifications et les menus.

    La documentation La documentation du SDK Android est scinde en deux parties bien distinctes :

    Le guide du dveloppeur qui est disponible en HTML (Hypertext Markup

    Language) dans le rpertoire du SDK quon vient dinstaller ;

    La documentation des API au format javadoc est galement situe dans le

    rpertoire docs et accessible grce au chemin dbutant du rpertoire

    dinstallation.

    La Golocalisation Parmi les fonctionnalits les plus apprcies sur les plates-formes mobiles

    modernes, la golocalisation permet de raliser des applications innovantes.

    Grce Google Cartes notamment, elle est au coeur dAndroid.

    Le service de golocalisation rcupre les coordonnes de lutilisateur et les

    envoie pour la ralisation un service informatique. A chaque fois, il demande

    lautorisation de lutilisateur avant la ralisation de cette opration. Seules les

    informations concernant la latitude et la longitude sont envoyes.

    La localisation du mobile se fait selon plusieurs technologies comme :

    GPS : il s'effectue par la rception de signaux provenant de plusieurs satellites

    qui se trouve en orbite. Le tlphone mobile quip d'un GPS permettra de

    transmettre sa position via un rseau SMS, GPRS, Edge ou UMTS.

    Internet : La prcision de la localisation par adresse IP sur le rseau internet se

    situera au niveau d'un pays, d'une ville ou d'un quartier selon l'oprateur

    (national ou local). Cependant, au sein d'un rseau ADSL d'un mme oprateur,

    la golocalisation peut tre trs prcise (adresse ou btiment par exemple) si les

    lieux des connexions sont enregistres dans une base de donns.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 40

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

    mettrices, avec une prcision infrieure 100 mtres. Une triangulation entre

    plusieurs antennes Wifi peut donner la position avec une prcision d'environ 5m

    par l'analyse de la puissance du signal radio reu de l'appareil.

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

    est autorise aprs une identification une cellule composant le rseau GSM. La

    prcision dpend de l'tendue de la cellule, de 250 mtres en zone urbaine 10

    km en zone rurale.

    La scurisation des communications

    Pour assurer une communication scurise entre le client et le serveur, il est

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

    communication qui garantissent la scurisation du canal de transport des

    donnes comme HTTPS (HyperText Transfer Protocole Secured).

    6.1. La dfinition du protocole HTTPS

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

    hypertexte scuris qui a t dvelopp par Netscape.

    Il correspond une version scurise du http (HyperText Transfer Protocole).

    Le HTTPS rpond aux diffrents problmes de confidentialit que protocole http

    a connu.

    L'ide principale de HTTPS est de crer un canal scuris sur un rseau non

    scuris et dassurer une protection raisonnable contre les oreilles indiscrtes

    condition que les suites de chiffrement adquat soient utilises et que le

    certificat de serveur soit vrifi et approuv.

    6.2. Les objectifs de scurit assurs

    Le protocole HTTPS fournit les objectifs de scurit suivants :

    L'authentification en permettant l'assurance de l'identit du programme, de la

    personne ou de l'entreprise avec laquelle on communique.

    La confidentialit des donnes changes : Il est impossible d'espionner les

    informations changes.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 41

    L'intgrit des donnes changes : Il est impossible de truquer les informations

    changes.

    La spontanit : la connexion de client avec le serveur est transparente.

    Conclusion

    Durant ce chapitre, nous avons prsent les technologies utilises et leurs

    fonctionnalits.

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

    march mondial des smartphones ne se dment pas. Ainsi sur les 287,8

    millions de terminaux livrs au 1er trimestre 2014, 81,1% tournaient sous

    Android selon IDC. Et sur le 2e trimestre, le rapport de force s'est encore

    accentu au profit des deux plateformes dominantes : 96% des terminaux

    livrs dans le monde, soit 301,3 millions dunits, tournaient sous Android et

    iOS, dont 84,7% pour le seul Android.

    Malgr une progression de ses ventes, Apple abandonne des parts de march.

    Cependant, avec un positionnement sur le haut de gamme, l'iPhone reste

    toujours trs rentable pour la firme. D'aprs IDC, la part de march d'iOS sur le

    haut de gamme est considrable, de l'ordre de 84,6%, contre seulement 19,82%

    pour Android. L'OS Google domine en revanche sur l'entre de gamme, laisse

    de ct par Apple, puisque 58,6% des androphones livrs sur la priode

    appartiennent ce segment. Du ct de Windows Phone, la ventilation par

    catgories est relativement similaire.

    3.3.2 Structure dun projet Android

    Une application Android consiste en un assemblage de composants lis via un

    fichier de configuration, qui prsentent en quelque sorte les briques sur

    lesquelles se repose l'application. Ces concepts fondamentaux prciser sont :

    Les vues

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

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

    classe View qu'hritent les widgets

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

    lequel on organise

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 42

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

    servant la cration d'une interface graphique interactive.

    - Les contrles

    C'est bien la classe des composants graphiques cits dessus. Les contrles sont

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

    - Les activits

    Une Activity reprsente la fentre qui sera affiche l'utilisateur. C'est un

    ensemble de vues et de contrles composant une interface logique. Elle permet

    galement de grer des fonctionnalits telles que l'appui sur une touche,

    l'affichage de messages, etc. Ce concept repose essentiellement sur l'interaction

    de l'utilisateur avec l'cran.

    - Les ressources

    Chaque application Android a ses propres fichiers ressources. C'est dans ces

    fichiers que seront puiss les textes, les images, les couleurs, etc.

    - Le fichier de configuration

    C'est fichier auto gnr par l'application, qui lui est indispensable. C'est un

    fichier XML appel AndroidManifest qui dcrit le point d'entre de

    l'application (le code excuter), les composants du projet ainsi que les

    permissions ncessaires pour l'excution du programme.

    Une illustration explicative de ces concepts est reprsente par le schma de la

    figure 4.

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 43

    Figure 5. Composition dune application androde

    5.1.2 Conception architecturale

    Il est primordiale la conception de tout systme informatique de choisir le

    modle d'architecture qui lui sera adquat pouvant assurer un bon

    fonctionnement, des meilleurs performances ainsi que la rutilisation et

    l'interconnexion fiable de ce systme avec d'autres.

    C'est cet effet que nous optons pour le modle MVC qui sera galement trs

    pratique pour grer l'interaction entre les diffrents composants de notre

    application Android.

    Nous dcrivons cette architecture dans la section suivante.

    5.1.3 Architecture MVC

    L'architecture MVC (modle, vue et contrleur) est une architecture trois

    couches utilise pour la programmation client/serveur et d'interface graphique.

    C'est un modle architectural trs puissant qui intervient dans la ralisation d'une

    applica-

    tion. Il tire sa puissance de son concept de base qui est la sparation des donnes

    (modle), de l'affichage (vue) et des actions (contrleur).

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 44

    C'est trois couches sont dcrites comme suit:

    - Modle

    Il correspond aux donnes stockes gnralement dans une base de donnes.

    Dans un langage oriente objet ces donnes sont exploites sous forme de

    classes. Le modle peut aussi agir sur la vue en mettant jour ses donnes.

    - Vue

    Ne contenant que les informations lies l'affichage, la vue se contente

    d'afficher le contenu qu'elle reoit sans avoir connaissance des donnes. En bref,

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

    - Contrleur

    Le contrleur sert de base rcuprer les informations, de les traiter en fonction

    des paramtres demands par la vue (par l'utilisateur), puis de renvoyer la vue

    les donnes afin d'tre affiches. C'est donc l'lment qui va utiliser les donnes

    pour les envoyer la vue.

    L'interaction entre ces trois couches est dcrite l'aide de la figure 5.

    Figure 6 Architecture MVC

  • Chapitre 3 : Notions prliminaires

    Rapport de Fin dEtude Page 45

    Les avantages apports par l'architecture MVC sont :

    - La sparation des donnes de la vue et du contrleur (ce qui permet une

    conception claire et efficace de l'application)

    - Une indpendance des donnes, de l'affichage et des actions (ce qui donne plus

    de souplesse pour la maintenabilit et l'volutivit du systme).

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

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 46

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 47

    4.1 Etude Prliminaire

    4.1.1 Prsentation du projet raliser

    Pour une meilleure comprhension du travail effectu, nous

    prsentons dans ce chapitre ltape danalyse et de conception. En

    effet, pour raliser une bonne conception de lapplication, il faut

    faire une tude approfondie des exigences du march du travail.

    Dans ce chapitre, nous commencerons par une tude prliminaire

    qui consiste reprer les besoins fonctionnels et non fonctionnels.

    Par suite, nous avons labors une modlisation claire de ce qui a

    t tabli au cours de cette tude. Aussi, ce chapitre sera ddi pour

    la conception architecturale de notre application.

    4.1.2 Recueil des besoins fonctionnels (Cahier de charge)

    1- Golocaliser : permet au conducteur de connaitre sa position sur la carte.

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

    rtrcir et de se dplacer dans la carte.

    3.3.1- Zoomer plus

    3.3.2- Zoomer moins

    3.3.3- Se dplacer

    3-Trouver des services et des stations : permet au conducteur de trouver des

    stations et des services proches.

    4-Signaler des alertes : permet de signaler des accidents, des bouchons, des

    pannes .etc.

    5-Associer des informations aux alertes :associer des informations aux les

    alertes comme (la nature , linstant de son signallement.)

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

    donnes.

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

    4.1.4 Modlisation du contexte & identification des messages

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 48

    Figure 7. Diagramme de contexte statique

    4.2 Capture des besoins fonctionnels

    4.2.1 Identification des cas dutilisations

    (Diagrammes des cas dutilisations de chaque acteur)

    4.2.2 laboration des diagrammes de cas dutilisations : Un cas dutilisation correspond un certain nombre dactions que le systme devra excuter en rponse un besoin dun acteur. Un cas dutilisation doit produire un rsultat observable pour un ou plusieurs acteurs ou parties prenantes

    du systme.

    Une interaction permet de dcrire les changes entre un acteur et un cas

    dutilisation. Pour identifier les cas dutilisation de faon pragmatique il est judicieux de dissocier les acteurs du systme en sintressant aux fonctionnalits quils peuvent enclencher.

    4.2.2.1- Diagramme des cas dutilisation des conducteurs :

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 49

    Figure 8. Diagramme de cas dutilisation

    4.2.3. Description textuelle des cas dutilisations :

    1-Go localiser :

    Cas dutilisation : Go localiser Acteurs principaux Conducteur

    Acteurs secondaires Aucun

    Pr conditions le conducteur doit tre dj entrain dutiliser lapplication.

    Post conditions Connaitre la position actuelle. Scnario nominale 1. conducteur indique au systme quil veut

    go localiser.

    2. Le systme rcupre les coordonns de la

    position.

    3. systme affiche un marqueur sur la position

    actuelle. Scnario alternatif Aucun

    Tableau 3. Cas dutilisation Geo localiser

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 50

    2-Naviguer sur la carte :

    Cas dutilisation : Naviguer sur la carte Acteurs principaux Conducteur Acteurs secondaires Aucun

    Pr conditions Lapplication soit en cours dutilisation Post condition Affichage dune nouvelle vue de la carte

    Scnario nominale 1. conducteur indique au systme quil veut naviguer sur la carte.

    2.le systme affiche la carte.

    3.Conducteur fait les indications (les choix)

    4.le Systeme Prendre en considrations les

    choix.

    Scnario alternatif Aucun

    Tableau 4. Cas dutilisation Naviguer sur la carte

    3-Trouver des stations et des services :

    Cas dutilisations : Trouver station et service

    Acteurs principaux Conducteur Acteurs secondaires SGBD

    Pr conditions Le conducteur doit naviguer sur la carte

    Post conditions Le systme affiche les services et les stations

    proches

    Scnario nominale 1 .le conducteur indique au systme quil veut chercher service ou station

    2. systme lui indique qu'il peut chercher avec

    des spcifications.

    3. Le conducteur donne son choix.

    4. Le Systme prend en considration le choix

    de Le conducteur.

    5. Le systme excute la demande.

    6. Le systme affiche le rsultat de la

    recherche.

    Scnario alternatif Aucun Tableau 5. Cas dutilisation Trouver des stations et des services

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 51

    4-Signaler des alertes :

    Cas dutilisation : Signaler les alertes acteurs principaux Conducteur Acteurs secondaires SGBD

    Pr condition Le conducteur entrain dutiliser lapplication

    Post condition Le systme affiche que lalerte est ajoute avec succs.

    Scnario nominale 1. Go localiser (cas dutilisation). 2. le conducteur fait une longue clique sur la

    carte.

    3. le system lui affiche une boite de dialogue

    Spcifi le type dalerte. 4.le conducteur choisit le type dalerte. 5.le systme affiche licne dalerte et un message de succs.

    Scnario alternatif 5.1.si il y a un problme de connexion le

    systme naffiche pas licne et affiche un message derreur.

    Tableau 6. Cas dutilisation Signaler des alertes

    4.2.4. Elaboration des diagrammes de squence et diagramme dactivits:

    Pour chaque cas dutilisation, nous allons laborer un diagramme de squence

    systme qui dcrit le cas sous forme d'interaction (squence) entre un acteur et le

    systme, qui est toujours considr comme une boite noire, son comportement

    est dcrit comme il est peru de lextrieur par lutilisateur.

    1. Go localiser :

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 52

    Figure 9. Diagramme de squence de cas Go localiser

    Figure 10 Diagramme dActiviez de cas Go localiser

    2. Naviguer sur la carte :

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 53

    Figure 11. Diagramme de squence de cas Naviguer sur la carte

    Figure 12 Diagramme dactive de cas Naviguer sur la carte

    3-Trouver des stations et des services :

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 54

    Figure 13. Diagramme de squence de cas Trouver des stations et des services

    Figure 14. Diagramme dactivit de cas Trouver des stations et des services

    4-Signaler des alertes :

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 55

    Figure 15 Diagramme de squence de cas Signaler des alertes

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 56

    Figure 16. Diagramme de squence de cas Signaler des alertes

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude Page 57

    4.3 Analyse

    4.3.1 Diagrammes de classes utiliss dans chaque cas dutilisation

    1-Go localiser :

    Figure 17. Diagramme de class de cas Go localiser

    2-Naviguer sur la carte :

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

    3-Trouver des stations et des services :

  • Chapitre 4 : Conception du projet

    Rapport de Fin dEtude 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 dEtude 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 dEtude Page 60

    Figure 23. Diagramme de class complet

    4.3.3 Attributs et mthodes de chaque classe