Projet NavInc Florian Bastien Fabien Cornic Antoine Després François Droumaguet Bastien Przybylski Responsables : Jean-Louis Pazat Nikos Parlavantzas

Sommaire Objectifs et cadre du projet Pré-étude Architecture générale Spécifications fonctionnelles Éléments de planification Traveling Salesman

Sommaire Objectifs et cadre du projet Pré-étude Architecture générale Spécifications fonctionnelles Éléments de planification Traveling Salesman

Objectifs et cadre du projet Réaliser un logiciel de navigation « GPS » Montrer la composition et l'adaptation de services Servir de base au développement d’un démonstrateur - Le boitier GPS utilise des services - Le démonstrateur montre la composition et l'adaptation de services

Objectifs et cadre du projet IRISA Unité mixte de projet De nombreux collaborateurs Équipe PARIS au sein du réseau S-Cube S-Cube Réseau d’excellence européen Programmation orientée service Projet de 4ieme année Informatique INSA PARIS?

Sommaire Objectifs et cadre du projet Pré-étude Architecture générale Architecture Orientée Service OSGi iPOJO Cas d’utilisation Architecture générale Spécifications fonctionnelles Éléments de planification Traveling Salesman

Pré-étude Architecture Orientée Service Contrat standardisé Couplage lâche Capacité de localiser Cohésion · Contrat standardisé : chaque service doit décrire ses caractéristiques fonctionnelles et non fonctionnelles dans un contrat. · Couplage lâche (loosely-coupled) : les services sont connectés aux clients via des contrats qui sont indépendants de l’implémentation des services. · Localisabilité : le contrat contient des méta données par lesquelles les services peuvent être trouvés. · Cohésion : les fonctionnalités fournies par un service sont fortement liées.

Pré-étude Adaptation Adaptation dynamique : modification du comportement du logiciel pendant l’exécution en fonction du contexte qui l’entoure Comprend trois tâches observer le contexte déterminer les changements à apporter au logiciel exécuter les changements sur le logiciel L'architecture orientée services facilite les changements parce que elle permet de remplacer/ajouter/enlever des services pendant l’exécution

Cycle de vie d’un bundle Pré-étude OSGi (Open Services Gateway initiative) Framework pour services basé sur Java Unité de déploiement : le bundle Framework OSGi Cycle de vie d’un bundle Cf : http://sardes.inrialpes.fr/ecole/livre/pub/Chapters/OSGI/osgi.html

Pré-étude iPOJO « Plain Old Java Object » Surcouche de OSGi Simplification du code

Pré-étude Cas d’utilisation

Sommaire Objectifs et cadre du projet Pré-étude Architecture générale Schéma général Gestion et adaptation des services Spécifications fonctionnelles Éléments de planification Traveling Salesman

Architecture générale Parler de la structure. Pas donner le détail des service (donné dans les spécif fonct.)

Architecture générale Gestion et adaptation de services Gestion des évènements levés par le framework ou les services Arrêt et démarrage de service Réalisation des adaptations : Arrêt, démarrage ou modification des liaisons d’un service Appels aux opérations d’autres services pour qu’ils s’adaptent Suivi des liaisons entre les services

Sommaire Pré-étude Architecture générale Spécifications fonctionnelles Objectifs et cadre du projet Pré-étude Architecture générale Spécifications fonctionnelles Listing des services Listing des scenarii Déroulement du scenario « Demande d’itinéraire » Déroulement du scenario « Passage sous un tunnel » Éléments de planification Traveling Salesman

Spécifications fonctionnelles Services centraux NavInc Gestionnaire des services Services de surveillance Monitoring de la voiture Monitoring du système Autre Lieux d’intérêt Services GPS Cartographie Localisation Routage Guidage Info-trafic Géolocalisation Gestion des données NE PAS MODIFIER LE MODELE DE CETTE DIAPO !!!

Spécifications fonctionnelles Scenarii prévus pour la démonstration : Obtenir un itinéraire Obtenir le guidage Passage sous un tunnel Perte du service de carte La quantité d'essence est faible Les ressources informatiques viennent à manquer Pourquoi des scenarii?

Spécifications fonctionnelles Déroulement du scenario « Demande d’itinéraire » Routage 10: calcul itinéraire(départ, arrivée) 11: itinéraire 3: à partir de la position actuelle 7: adresse de destination 1: demande d’itinéraire guidage NavInc 12: mémoriser itinéraire 2: demande adresse de départ 6: demande adresse de destination 9: coordonnées de l’adresse Pas dire OSM -> carte/format de carte 4: demande coordonnées 8: coordonnées(adresse) 5: coordonnées actuelles géolocalisation localisation

Spécifications fonctionnelles Déroulement du scénario « Passage sous un tunnel » Géolocalisation GSM Demande coordonnées Coordonnées 5: Démarrage 14: Arrêt 2: Recherche d’un service de géolocalisation insensible aux tunnels 4: Démarrage GSM 10: Démarrage GPS 13: Arrêt GSM 7: Arrêt GPS Gestionnaire de Services NavInc 12:Lie NavInc et GPS 6:Lie NavInc et GSM OSGi 3: Service GSM Demande coordonnées 1: Évènement : Tunnel proche 9: Évènement : Fin du tunnel Coordonnées Coordonnées 11: Démarrage 8: Arrêt Géolocalisation GPS Guidage

Sommaire Objectifs et cadre du projet Pré-étude Architecture générale Spécifications fonctionnelles Éléments de planification Diagramme de Gantt Traveling Salesman

Diagramme de Gantt Développement Conception Page HTML Rapport 21 21

Sommaire Objectifs et cadre du projet Pré-étude Architecture générale Spécifications fonctionnelles Éléments de planification Traveling Salesman Présentation Réutilisation pour le projet

Traveling Salesman Planificateur d’itinéraire et système de navigation par GPS Nombreuses fonctionnalités Utilisation du système de cartes OpenStreetMap Constitué de plugins Projet sous licence GPL

Traveling Salesman Reprise de Traveling Salesman Des plugins à réutiliser : Cartographie Guidage Routage Localisation Des plugins dont s’inspirer : Géolocalisation Info-Trafic

Conclusion Réaliser un logiciel de navigation en utilisant une architecture orientée services Utiliser OSGi et iPOJO Réutiliser Traveling Salesman Prochaine étape : conception