continuum

Rainbow : Hourdin, Lavirotte, Tigli, Rey

LIG : Coutaz, Jouanot, Fontaine, Anis

• Octobre 2010 ::: RETARD ::: D3.2 : Découverte d'alignement et d'assemblages : LIG/HADAS
• Décembre 2010 ::: RETARD ::: D3.3 : Raisonnement sur les propriétés et la continuité de service : LIG/HADAS
• Février 2011 : D2.32 : S'adapter au contexte, second démonstrateur (Cf. logiciel dans l'architecture générale) : I3S/ Rainbow
• Février 2011 : D3.4 : Maîtriser l'hétérogénéité, démonstrateur (Cf. logiciel dans l'architecture générale): LIG /HADAS
• Février 2011 : D4.3.2 : Mettre l'utilisateur dans la boucle, démonstrateur (Cf. logiciel dans l'architecture générale) : LIG / IIHM
• Février 2011 : D5.1 : Prototype de dispositif Gemalto : GEMALTO
• Mai 2011 : D5.2.2 : Adaptation et Développement des WebServices métiers version prototypée pour démonstrateur final : Suez environnement / Lyonnaise des eaux
• Sept 2011 : D5.3.2 : Démonstrateur final : I3S / Rainbow

• RDV JY Tigliavec Lyonnaise des eaux (Laurent Kuta) et Ludotic pour définir le panel des utilisateurs qui testeront les interfaces du Weco (28 janvier matin)
• Echanges avec I3S/GemAlto pour spécifier l'interface le dispositif GemAlto et le Weco (TODO :: Vérifier que les capteurs du dispositif ont bien été définis avec Suez environnement et Lyonnaise des eaux)

Prévoir une plénière courant février (?)

Quand ça vous arrange ?

• Quel nouveau deadline pour les D3.2 et D3.3 d'HADAS ?

Dans D4.1 et D4.2 : deux principes de meta-IHM :

• méthode graphique de liaison entre photos d'objets de la maison
• méthode en langage pseudo naturelle (avec guidelines pour des phrases syntaxiquement et sémantiquement correctes)

• PB1 : définition de la grammaire du langage pseudo-naturelle

• PB2 : quelle(s) transformation(s) pour passer de phrases du langage aux différentes éléments de mise en oeuvre dans l'architecture :
  • Phrase et définition du contexte pour le déploiement d'un ensemble particulier d'AA
  • Phrase et génération des AAs déployés dans ce contexte
  • Phrase et requêtes à la BdC pour trouver des services et dispositifs qui correspondent aux terminaux de la phrase. L'hypothèse dans ce cas étant que le langage pseudo-naturel s'appuiera sur des terminaux abstraits et que la BdC permettra la mise en correspondance des services et dispositifs concrets avec les services et dispositifs abstraits (terminaux) attendus.

Dans le cadre applicatif du scenario du fontainier (recherche de vanne + PDA / Casque)

• Rainbow : Rajouter des metadonnées aux services et services pour dispositifs.

• IIHM : Reprendre la grammaire du langage pseudo-naturel, définir le vocabulaire de base pour les actions

et des noms terminaux de manière plus générale (type de device et méthodes et events)

• Hadas : Spécifier les métadonnées dans les services et services pour dispositifs.

- alignement des terminologies (afficher, montrer)

- introduction des composants intermédiaires (insertion de composants intermédiaires : recasteur, …)

- gestion des signatures (par retroappel, …)

- deux niveaux de gestion des condition “circonstancielles” (compléments circonstanciels) : niveau contexte ou membre gauche (trigger d'action dans un AA)

- Problème de cohérence entre les états des composants à l'initialisation (exemple plusieurs checkbox qui attaque un light, si la checkbox est on et la light off, non seulement l'initialisation aujourd'hui ne gère pas la cohérence, mais en plus on ne sait pas si l'état initial doit être On/On ou Off/Off)

1> Alignement :

Step 1 Emric fonctionne avec une grammaire et des terminaux “types” : exemple Audiosource , AudioSink dont il connait les méthodes types :

Audiosource.setaudio

Audiosink.getaudio

grâce à un “terminal” comme écouter (mots clef action).

Step 2 Ensuite il fait une requête dans la BdC sur AudioSink.setaudio et AudioSource.getaudio pour récupérer les devices avec les méthodes ou events équivalents

Step 3 Les metadonnées d'un devices devant fournir à la BdC les équivalences de ses méthodes et events en terme de méthodes et events “types” pour préparer ces requêtes et les composants intermédiaires nécessaires à ces équivalences

Attention :

- il faut que la BdC renvoie quand même un nom de “famille” de devices telle GPS* ou par convention la BdC part du principe que tous les devices GPS* (ex. GPS1, GPS2) ont la même interface. Autre exemple, des pointcuts qui sont des “ou” entre les devices possibles exemple Localisateur | GPS.

ou

- la partie pointcut matching fait appel à la BdC

2> composants intermédiaires à rajouter pour rendre équivalentes des méthodes AudioSource.getaudio avec des méthodes concrètes du service

3> retroappel : idem que 2> mais avec le retroappel

4> gérer par redondance, si possible (ex. du disable)

Sur la base du scenario du fontainier recherche de vanne + PDA / Casque

Rainbow : Rajouter des metadonnées aux services et services pour dispositifs.

IIHM : Reprendre la grammaire du langage pseudo-naturel, définir le vocabulaire de base pour les actions et des noms terminaux de manière plus générale (type de device et méthodes et events)

Hadas : Spécifier les métadonnées dans les services et services pour dispositifs.

Vers le second démonstrateur pour février .