compte_rendu_14_janvier_2011
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
compte_rendu_14_janvier_2011 [2011/01/14 13:40] tigli |
compte_rendu_14_janvier_2011 [2011/01/14 16:42] tigli |
||
|---|---|---|---|
| Line 23: | Line 23: | ||
| == Quelques nouvelles sur le suivi du projet == | == Quelques nouvelles sur le suivi du projet == | ||
| - | * 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) | + | * RDV JY Tigli avec 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) | * 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) | ||
| - | == Prochaine Réunion == | ||
| - | Prévoir une plénière courant février (?) | ||
| - | |||
| - | Quand ça vous arrange ? | ||
| == Questions == | == Questions == | ||
| Line 41: | Line 37: | ||
| == Approche == | == Approche == | ||
| - | Dans D4.1 et D4.2 : deux principes de meta-IHM : | + | Dans D4.1 et D4.2 : trois principes de meta-IHM : |
| + | * méthode utilisant un monde simulé | ||
| * méthode graphique de liaison entre photos d'objets de la maison | * 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) | * méthode en langage pseudo naturelle (avec guidelines pour des phrases syntaxiquement et sémantiquement correctes) | ||
| - | == Le point sur les avancées == | + | == Les travaux à mener identifiés == |
| * PB1 : définition de la grammaire du langage pseudo-naturelle | * 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 : | * 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 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 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. | + | * 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 services et dispositifs abstraits et que la BdC permettra la mise en correspondance des services et dispositifs concrets avec les services et dispositifs abstraits (terminaux) attendus. |
| - | + | * PB3 : possibilité d'ajouter des metadonnées aux AAs disponibles et les intégrer ainsi dans la BdC pour pouvoir retrouver sur requête des AAs existants. | |
| - | * la génération des conditions contextuelles pour l'application d'un ensemble d'aspects donnés | + | |
| - | * la génération d'aspects à appliquer dans ce contexte | + | |
| - | + | ||
| - | * PB3 : le langage pseudo-naturel s'appuiera sur des terminaux abstraits. | + | |
| - | * les requêtes sur la BdC d'Hadas (enrichie par les meta données issues de dispositifs réels de l'infrastructure) permettra de trouver une correspondance entre les terminaux attendus et les dispositifs et services disponibles. | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | == Conséquence sur les AAs == | + | |
| - | + | ||
| - | Les AAs implémentent : | + | |
| - | + | ||
| - | Trigger := When | Where |.... avec logique booléenne / temporelle (events) | + | |
| - | + | ||
| - | Action := Méthodes .... avec logique booléenne / temporelle | + | |
| - | + | ||
| - | Problème :: les conditions de déclenchement de l'action sont-elles des caractéristiques | + | |
| - | du contexte qui déclenche un AA ou les même conditions sont elles le membres droit de l'AA | + | |
| - | + | ||
| - | Autre idée pour la continuité : abstraire la notion de condition (ex. il fait jour) pour la traduire par | + | |
| - | différents services ou devices. | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | == Travail sur le scenario du fontainier pour la projection des phrases en langage pseudo naturel vers des AAs == | + | |
| - | + | ||
| - | Cas 1 : si (vitesse > x et milieu encombré) alors disable (S1 et S2) | + | |
| - | + | ||
| - | Dans ce cas la condition correspond vraiment à un changement de contexte et la désactivation des AAs | + | |
| - | qui utilisent S1 et S2 | + | |
| - | + | ||
| - | + | ||
| - | Idée : Cas généraux (deux cas) : | + | |
| - | + | ||
| - | condition contexte -> liste d'AA à activer / désactiver | + | |
| - | + | ||
| - | AA : condition -> action | + | |
| - | + | ||
| - | + | ||
| - | Cas 2 : Me localiser sur la carte / Où suis-je | + | |
| - | + | ||
| - | Comment traduire en AA | + | |
| - | + | ||
| - | Cas 3 : Problème du rétroappel ... | + | |
| - | En fait il faut aussi annoter les méthodes+getter (ou rétro appel) qui "vont bien" comme méthode possible | + | |
| - | pour le device. | + | |
| - | + | ||
| - | Vu le nombre de getter, il faut donc le faire à la main ... | + | |
| - | + | ||
| - | exemple : checkbox pour piloter une light => l'utilisation de checkbox.setchange__getvalue | + | |
| - | pour une methode setchange() | + | |
| - | + | ||
| - | Cas 4 : problème de l'initialisation (pas d'initialisation avec WComp avant l'émission d'events) | + | |
| - | + | ||
| - | Cas 5 : si le casque est baissé afficher la position des points d'intérêt dans le casque | + | |
| - | + | ||
| - | Condition (si le casque est baissé) | + | |
| - | Action : afficher les points d'intérêt dans le casque | + | |
| - | + | ||
| - | + | ||
| - | Cas 6 : je veux regarder l'état de ma machine à laver | + | |
| - | * sous tension (On/Off) [boolean] | + | |
| - | * cycle [enum] | + | |
| - | * programme [enum] | + | |
| - | * temperature [entier] | + | |
| - | * temps restant (heure de terminaison) [0..60] | + | |
| - | + | ||
| - | == Cinq problèmes : == | + | |
| - | + | ||
| - | - 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 | + | |
| + | == Liste des TODOs du dernier meeting == | ||
| - | 4> gérer par redondance, si possible (ex. du disable) | + | 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) | ||
| - | == TODOs == | + | * Hadas : Spécifier les métadonnées dans les services et services pour dispositifs. |
| - | Sur la base du scenario du fontainier recherche de vanne + PDA / Casque | + | A priori aucun de ces TODOs n'a posé ou ne pose de difficulté. |
| + | == Méthodologie et travaux pour la suite : == | ||
| - | Rainbow : Rajouter des metadonnées aux services et services pour dispositifs. | + | Parce que le problème de(s) transformation(s) du langage pseudo naturelle vers les éléments de la mise en œuvre, il nous faut dans un premier temps simplifier le langage utilisateur, proposer les principaux exemples de mise en œuvre et étudier au cas par cas les processus de transformation. |
| - | IIHM : Reprendre la grammaire du langage pseudo-naturel, définir le vocabulaire de base pour les actions | + | - Quelques phrases exemples |
| - | et des noms terminaux de manière plus générale (type de device et méthodes et events) | + | - Etablir les conditions contextuelles qui en découlent |
| + | - Etablir les AAs mis en oeuvre | ||
| + | - Enumérer les terminaux (services et dispositifs abstraits attendus) | ||
| + | - Enumérer quelques exemples de services et dispositifs réels et leur metadonnées | ||
| - | Hadas : Spécifier les métadonnées dans les services et services pour dispositifs. | + | Pour cela : |
| + | * l'équipe IIHM : | ||
| + | * dépose sur le SVN la dernière grammaire du langage pseudo naturel | ||
| + | * fournit une dizaine d'exemple de phrases permettant d'illustrer les possibilités du langage | ||
| + | * fournit les aspects déjà générés (Cf. Emeric) | ||
| + | * avance sur la grammaire du langage | ||
| + | * l'équipe HADAS : | ||
| + | * à partir du langage pseudo naturelle établir la liste des métadonnées attendues sur les dispositifs et l'ontologie associée. | ||
| + | * l'équipe RAINBOW : | ||
| + | * fournir la dernière grammaire des AAs (déposer sur le SVN) | ||
| + | * étudier le passage des phrases du langage pseudo naturel à la génération d'AAs et de conditions contextuelles pour leur application. | ||
| - | Vers le second démonstrateur pour février . | + | Un bilan et une mise en commun des réflexions seront faits lors du prochain meeting à Grenoble. |
| + | == Prochains Meetings == | ||
| + | * Bilan prévu le Mercredi 2 Février à Grenoble sur les travaux LIG/I3S des prochains 15 jours | ||
| + | * Réunion plénière après les premiers tests d'intégration des différents travaux des équipes : Cf. doodle (http://www.doodle.com/fyeh5vp5gbtnhka5) | ||
| + | * OdJ : | ||
| + | * Bilan sur les livrables et le planning | ||
| + | * Bilan sur les premiers tests d'intégration des démonstrateurs logiciels HADAS / IIHM / RAINBOW | ||
| + | * avancées des travaux sur la sécurité avec MobileGov | ||
| + | * avancées des travaux sur le dispositif GemAlto (et l'ensemble des capteurs associés) | ||
| + | * avancées sur les évaluations des interfaces par LudoTIC | ||
| + | * Bilan sur la dissemination | ||
| + | * ... | ||
compte_rendu_14_janvier_2011.txt · Last modified: 2011/01/14 16:44 by tigli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
