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 Next revision Both sides next revision | ||
|
compte_rendu_14_janvier_2011 [2011/01/14 13:26] tigli |
compte_rendu_14_janvier_2011 [2011/01/14 16:07] 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 45: | Line 41: | ||
| * 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 == |
| - | + | ||
| - | * définition de la grammaire du langage pseudo-naturelle | + | |
| - | * quelle(s) transformation(s) pour passer de phrase du langage à | + | |
| - | * la génération des conditions contextuelles et des AAs pour un contexte donné. | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | == 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 | + | |
| + | * PB1 : définition de la grammaire du langage pseudo-naturelle | ||
| - | 4> gérer par redondance, si possible (ex. du disable) | + | * 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. | ||
| + | == Liste des TODOs du dernier meeting == | ||
| + | Dans le cadre applicatif du scenario du fontainier (recherche de vanne + PDA / Casque) | ||
| - | == TODOs == | + | * Rainbow : Rajouter des metadonnées aux services et services pour dispositifs. |
| - | Sur la base du scenario du fontainier recherche de vanne + PDA / Casque | + | * 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. | ||
| - | Rainbow : Rajouter des metadonnées aux services et services pour dispositifs. | + | A priori aucun de ces TODOs n'a posé ou ne pose de difficulté. |
| - | IIHM : Reprendre la grammaire du langage pseudo-naturel, définir le vocabulaire de base pour les actions | + | == Méthodologie pour la suite : == |
| - | 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. | + | 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. |
| + | - Quelques phrases exemples | ||
| + | - 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 | ||
| - | Vers le second démonstrateur pour février . | ||
| + | == 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
