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

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

4 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

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

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

7 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

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

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

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

11 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

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

13 Fonctionnalités 1/2

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

15 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

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

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

18 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

19 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

20 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

21 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

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

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

24 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

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

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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

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

35 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

36 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

37 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

38 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

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

40 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

41 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

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

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

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

45 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

46 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

47 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

48 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

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

50 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

51 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