Projet NavInc

Florian BastienFabien CornicAntoine DesprésFrançois DroumaguetBastien Przybylski

Responsables : Jean-Louis PazatNikos Parlavantzas

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

Sommaire

2

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

Sommaire

3

Objectifs :

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

Objectifs et cadre du projet 1/5

4

IRISA Unité mixte de projetDe nombreux collaborateursÉquipe PARIS au sein du réseau S-Cube

S-CubeRéseau d’excellence européenProgrammation orientée service

Projet de 4ieme année Informatique INSA

Objectifs et cadre du projet 2/5

5

Architecture Orientée ServiceContrat standardiséCouplage lâcheCapacité de localiserCohésion

Objectifs et cadre du projet 3/5

6

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 4/5

7

OSGi (Open Services Gateway initiative)Framework pour services basé sur JavaUnité de déploiement : le bundle

Cycle de vie d’un bundle Framework OSGi

Objectifs et cadre du projet 5/5

8

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

Sommaire

9

Architecture générale 1/2

10

Gestion et adaptation de servicesGestion 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’adaptentSuivi des liaisons entre les services

Architecture générale 2/2

11

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

Sommaire

12

Fonctionnalités 1/2

13

Fonctionnalités 2/2Services liés au boitier de navigation :

Navigation Routage Geolocalisation Localisation

Services liés à notre architecture GestionnaireServices IHM Administration Console

14

Scenarii 1/2Scenarii prévus pour la démonstration :

Obtenir un itinéraire

Obtenir le guidage

Perte du service de carte

Passage sous un tunnel

15

Scenarii 2/2Permettent de démontrer :

La composition de services

L’adaptation réactive (perte de carte)

L’adaptation proactive (passage sous un tunnel)

16

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

Sommaire

17

Réalisation – Catégories des servicesPlusieurs catégories de services

Services qui utilisent Traveling SalesmanServices qui utilisent une IHMGestionnaire de services

Dépendances entre les servicesLes services exposent les dépendances dont ils ont

besoinUn service spécial, le gestionnaire de services, va

résoudre ces dépendances

18

Réalisation – Gestionnaire de services 1/2Gestionnaire de services

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 OSGiEvènements émis par les services

19

Réalisation – Gestionnaire de services 2/2Deux types d’adaptation

RéactiveUn problème s’est produit, le gestionnaire cherche une solution

ProactiveUn problème va se produire, le gestionnaire cherche un moyen de l’éviter

20

Réalisation – Services annexes 1/3Deux services annexes

Service consoleService administration

Service consoleAffiche à l’écran les actions du gestionnaire de services

ainsi que les évènements du contexte

Service administrationPermet de démarrer et d’arrêter les services utilisés

dans l’application21

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

22

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

23

Réalisation – Service IHM 1/2Point 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

24

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

25

Réalisation - Traveling Salesman 1/4

Réutiliser l'existant : Traveling SalesmanSystème de navigation Open sourceDéveloppé en JAVA

26

Réalisation - Traveling Salesman 2/4Objectif : 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

Schéma des dépendances avant modification de l’architecture

Schéma des dépendances après modification de l’architecture

29

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éolocalisationService d'horloge

Ces deux services permettent de simuler un trajet

31

Réalisation – serveur OSGi 1/2Problème

Utiliser le logiciel NavInc sans passer par eclipse

SolutionUtiliser un serveur OSGi autonome dédié à notre

logiciel

32

Réalisation – serveur OSGi 2/2Problè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

33

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

Sommaire

34

TestsTests 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

35

Scenarii 1/4Déroulement du scenario « obtenir un itinéraire »

Geolocalisation

1 : adresse2 : coordonnées

4 : coordonnées

3 : carte

Localisation

IHM

GestionDe Donnees

1 : positioncourante

2

36

Scenarii 1/4

1 : coordonnées

3 : carte

4 : itinéraire

5 : itinéraire

7 : carte

IHM

Routage

GestionDe Donnees

2

Cartographie6

Déroulement du scenario « obtenir un itinéraire »

37

Scenarii 2/4Déroulement du scenario « obtenir le guidage »

3 : coordonnées

4 : instructions9 : carte

IHM

GeolocalisationNavigation

7 : coordonnées1

2

Cartographie

GestionDe Donnees

86 : coordonnées

5

38

Scenarii 3/4Déroulement du scenario « perte du service de carte »

OSGi

utiliseIHM

Cartographie Secours

Cartographie

Gestionnaire Services

39

Scenarii 3/4Déroulement du scenario « perte du service de carte »

modificationdépendance

événementarrêt service

Cartographieutilise

IHMCartographie

Secours

OSGi

Gestionnaire Services

40

Scenarii 4/4Déroulement du scenario « passage sous un tunnel »

utilise

utilise

IHM

OSGi

Gestionnaire Services

Geolocalisation (GPS)

Geolocalisation (GSM)

Navigationévénement

tunnel proche

modificationdépendance

utiliseGeolocalisation (GPS)

41

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

Sommaire

42

BilanCe qui a été réalisé :

Adaptation dynamique des services

Application GPS à partir de Traveling Salesman

Implémentation de 4 scenarii

43

BilanCe qui n’a pas pu être réalisé :

2 scenarii parmi ceux initialement prévus

Application autonome (sans Eclipse)

44

BilanCe 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/5Deux é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

46

Bilan – Planification 2/5Analyse 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 planificationPrise en compte du risque de ne pas pouvoir réutiliser

Traveling Salesman dès le début du développementAdaptation de la répartition des tâches pour ne pas être

bloqué dans l’avancement du projet

47

Bilan – Planification 3/5Deux 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

48

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

Développement du Gestionnaire de services

Développement de l'IHM principale

Développement du service Console

Développement du service Administration

Développement du service de navigation

Première phase du développement

(sans traveling salesman)

Deuxième phase du développement

(avec traveling salesman)

Recherches sur la réutilisation de

traveling salesman

Recherche et développement du

service de géolocalisation

Développement du service de gestion de données

Développement du service d'horloge

Développement du service de routageDéveloppement du service de

cartographieDéveloppement du service de

localisation

49

Bilan – Planification 5/5Suivi 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

50

RemerciementsNous remercions nos encadreurs

Jean-Louis PazatNikos Parlavantzas

Et égalementLars Vogel, rédacteur d’un excellent guide d’utilisation

d’OSGiLes contributeurs au projet Traveling Salesman

51