Projet NavInc Florian Bastien Fabien Cornic Antoine Després

Présentation au sujet: "Projet NavInc Florian Bastien Fabien Cornic Antoine Després"— Transcription de la présentation:

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

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

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

4 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

5 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?

6 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

7 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.

8 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

9 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 :

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

11 Pré-étude Cas d’utilisation

12 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

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

14 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

15 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

16 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 !!!

17 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?

18 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

19 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

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

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

22 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

23 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

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

25 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