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 Architecture générale Fonctions Réalisation Tests Bilan 2

Sommaire Objectifs et cadre du projet Architecture générale Fonctions Réalisation Tests Bilan 3

Objectifs et cadre du projet 1/5 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 2/5 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?

Objectifs et cadre du projet 3/5 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.

Objectifs et cadre du projet 4/5 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 qu’elle permet de remplacer/ajouter/enlever des services pendant l’exécution

Objectifs et cadre du projet 5/5 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

Sommaire Objectifs et cadre du projet Architecture générale Fonctions Réalisation Tests Bilan 9

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

Architecture générale 2/2 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 Objectifs et cadre du projet Architecture générale Fonctions Réalisation Tests Bilan 12

Fonctionnalités 1/2

Fonctionnalités 2/2 Services liés au boitier de navigation : Routage Geolocalisation Localisation Services liés à notre architecture GestionnaireServices IHM Administration Console

Scenarii 1/2 Scenarii prévus pour la démonstration : Obtenir un itinéraire Obtenir le guidage Perte du service de carte Passage sous un tunnel

Scenarii 2/2 Permettent de démontrer : La composition de services L’adaptation réactive (perte de carte) L’adaptation proactive (passage sous un tunnel)

Sommaire Objectifs et cadre du projet Architecture générale Fonctions Réalisation Tests Bilan 17

Réalisation – Catégories des services Plusieurs catégories de services Services qui utilisent Traveling Salesman Services qui utilisent une IHM Gestionnaire de services Dépendances entre les services Les services exposent les dépendances dont ils ont besoin Un service spécial, le gestionnaire de services, va résoudre ces dépendances

Réalisation – Gestionnaire de services 1/2 Résoud les dépendances entre les services au démarrage de l’application Adapte dynamiquement les services utilisés en fonction du contexte Contexte Evènements émis par OSGi Evènements émis par les services

Réalisation – Gestionnaire de services 2/2 Deux types d’adaptation Réactive Un problème s’est produit, le gestionnaire cherche une solution Proactive Un problème va se produire, le gestionnaire cherche un moyen de l’éviter

Réalisation – Services annexes 1/3 Deux services annexes Service console Service administration Affiche à l’écran les actions du gestionnaire de services ainsi que les évènements du contexte Permet de démarrer et d’arrêter les services utilisés dans l’application

Réalisation – Services annexes 2/3 Vue du service console

Réalisation – Services annexes 3/3 Vue du service d’administration

Réalisation – Service IHM 1/2 Point d’entrée de l’application Permet à l’utilisateur d’utiliser les fonctionnalités du logiciel Permet d’afficher les cartes, les itinéraires et les informations de guidage

Réalisation – Service IHM 2/2 Vue du service IHM

Réalisation - Traveling Salesman 1/4 Réutiliser l'existant : Traveling Salesman Système de navigation Open source Développé en JAVA 26

Réalisation - Traveling Salesman 2/4 Objectif : greffer notre logiciel sur une instance de Traveling Salesman Problème : impossible de lancer Traveling Salesman à partir des sources Solution : récupérer les classes dont nous avons besoin 27

Réalisation - Traveling Salesman 3/4 Extraction des fonctionnalités nécessaires pour notre démonstrateur Récupération de toutes les classes utilisées Création d'un bundle bibliothèque 28

Réalisation - Traveling Salesman 4/4 Schéma des dépendances avant modification de l’architecture Schéma des dépendances après modification de l’architecture

Réalisation – services fonctionnels Étape 1 : réaliser une classe fonctionnelle respectant une interface définie en utilisant le code de Traveling Salesman Étape 2 : encapsuler cette classe dans un service OSGi et l’intégrer dans l’application Développement progressif suivant l'ordre des dépendances entre les services 30

Réalisation – services pour la simulation Deux services ne sont pas basés sur Traveling Salesman: Service de géolocalisation Service d'horloge Ces deux services permettent de simuler un trajet 31

Réalisation – serveur OSGi 1/2 Problème Utiliser le logiciel NavInc sans passer par eclipse Solution Utiliser un serveur OSGi autonome dédié à notre logiciel

Réalisation – serveur OSGi 2/2 Problèmes rencontrés Problèmes de synchronisation entre les threads swing et les threads de démarrage des services Solution trouvée: ouvrir les IHM dans un nouveau thread Problèmes de résolution des dépendances entre les services Pas de solution pour le moment => Actuellement pas de version sans eclipse

Sommaire Objectifs et cadre du projet Architecture générale Fonctions Réalisation Tests Bilan 34

Tests Tests unitaires et tests d’intégration Accent sur les tests unitaires des classes de Traveling Salesman Tests d’intégration au fur et à mesure du développement des services. Scenarii : considérés comme un test final de tous les services

Scenarii 1/4 Déroulement du scenario « obtenir un itinéraire » GestionDe Donnees IHM 2 3 : carte 1 : adresse 2 : coordonnées 1 : position courante Geolocalisation 4 : coordonnées Localisation

Scenarii 1/4 Déroulement du scenario « obtenir un itinéraire » Routage 1 : coordonnées 4 : itinéraire IHM 2 3 : carte 5 : itinéraire 6 Cartographie GestionDe Donnees 7 : carte

Scenarii 2/4 Déroulement du scenario « obtenir le guidage » GestionDe Donnees IHM 5 1 4 : instructions 9 : carte 8 6 : coordonnées 7 : coordonnées 2 Cartographie Navigation Geolocalisation 3 : coordonnées

Gestionnaire Services Scenarii 3/4 Déroulement du scenario « perte du service de carte » utilise Cartogra phie IHM Cartographie Secours Gestionnaire Services OSGi

Gestionnaire Services Scenarii 3/4 Déroulement du scenario « perte du service de carte » utilise Cartogra phie IHM Cartographie Secours modification dépendance Gestionnaire Services événement arrêt service OSGi

Scenarii 4/4 Déroulement du scenario « passage sous un tunnel » Geolocalisation (GPS) Geolocalisation (GPS) utilise IHM utilise Geolocalisation (GSM) utilise modification dépendance Gestionnaire Services Navigation événement tunnel proche OSGi

Sommaire Objectifs et cadre du projet Architecture générale Fonctions Réalisation Tests Bilan 42

Bilan Ce qui a été réalisé : Adaptation dynamique des services Application GPS à partir de Traveling Salesman Implémentation de 4 scenarii

Bilan Ce qui n’a pas pu être réalisé : 2 scenarii parmi ceux initialement prévus Application autonome (sans Eclipse)

Bilan Ce qui pourrait être fait dans le futur : Généralisation de la gestion des événements, en particulier ceux qui entraînent une adaptation Développement du mécanisme de propriétés des services permettant de les comparer sur des critères Utilisation de SWT comme bibliothèque graphique pour résoudre les problèmes d’autonomie de l’application 45

Bilan – Planification 1/5 Deux équipes L’équipe Traveling Salesman Trouver un moyen de réutiliser Traveling Salesman L’équipe OSGi Trouver un moyen de faire de l’adaptation dynamique

Bilan – Planification 2/5 Analyse des risques Retard si Traveling Salesman ne peut pas être réutilisé Retard si la technologie OSGi n’est pas maitrisée Modification de la planification Prise en compte du risque de ne pas pouvoir réutiliser Traveling Salesman dès le début du développement Adaptation de la répartition des tâches pour ne pas être bloqué dans l’avancement du projet

Bilan – Planification 3/5 Deux phases de développement Sans Traveling Salesman (mois de mars) Développement du mécanisme d’adaptation dynamique en fonction du contexte Recherche d’une solution pour pouvoir réutiliser Traveling Salesman Avec Traveling Salesman (avril et mai) Développement des services utilisant Traveling Salesman

Bilan – Planification 4/5 Ordonnancement réel des tâches

Bilan – Planification 5/5 Suivi de projet Réunions régulières de mise au point du travail effectué et du travail à faire Synchronisation des développements en parallèle pour les phases d’intégration => Bonne communication entre les deux équipes

Remerciements Nous remercions nos encadreurs Et également Jean-Louis Pazat Nikos Parlavantzas Et également Lars Vogel, rédacteur d’un excellent guide d’utilisation d’OSGi Les contributeurs au projet Traveling Salesman