150 likes | 241 Views
Spécificités de l’informatique ambiante. De nombreux services Des services métiers (apparition et disparition de fonctionnalités ) Des services pour gérer les supports physiques et les interacteurs Des services contraints Des services sur l’étagère “boites noires”
E N D
Spécificités de l’informatique ambiante • De nombreux services • Des services métiers (apparition et disparition de fonctionnalités) • Des services pour gérer les supports physiques et les interacteurs • Des services contraints • Des services sur l’étagère “boites noires” • Des devices avec leurs caratéristiques • Des usages variés • Des utilisateurs nombreux et variés • Chaque utilisateur a ses propres intérets et besoins
Problématiques liées au domaine de l’utilisateur • Adapter l’interface utilisateur à l’évolution du système • Comment modifier l’IHM pour intégrer un nouveau service ? • Adapter l’interface aux besoins utilisateurs • Adaptation aux supports physiques : travaux sur les IHMs plastiques (IHMs abstraites et rendering, expression du modèle de tâches) • Adaptation aux utilisateurs : travaux sur les IHMs (introduction de modèles de tâches, de profis) • Adapter le système aux besoins utilisateurs • Construire des applications personnalisées à partir des IHM
C C P P A A C C P A P A Patterns Architecturaux de construction d’IHMs PAC (1987) (Presentation-Abstraction-Control) MVC (1979) (Model-View-Controller) Controller View Model Arch Model (1992) ... ...
Dialogue Adaptor Adaptor Services Fonctionnel Services D’interaction Un modèle inspiré d’Arche pour les services • 1 Arche pour 1 service interactif • N services fonctionnels et leurs interactions utilisateurs : comment fusionner le tout ?
Quid des assemblages Comment fusionner 2 services respectant l’Arche ? Composition d’arches ? Assemblage des services fonctionnels Quid des dialogues ? Expression et fusion Quid des IHM? Expression et fusion
Travaux de références pour le domaine utilisateur Travaux composants (Fractal, SOA, Noah, WCOMP MODEL) Gestion de la dynamique de l’application (apparition et disparition de composants et de services) Expression des assemblages (orchestration, règles isl, langages d’aspects…) Sureté des assemblages Travaux sur l’IDM Modèles et transformation de modèles Fusion de modèles Travaux en IHMs Plasticité des interfaces Expression de modèles pour l’IHM (taches, dialogues…)
IHM • Abstraite: Structure en espaces de dialogue • Concrète : Fait le choix des interacteurs • Finale: Fait le choix de l’environnement de programmation et d’exécution Contexte d’usage • Environnement • Utilisateur • Plate-forme • Composant d’IHM Abstrait
Nos spécificités Etre centré sur le dialogue : relation « fonctionnel et IHM » Déterminer le bon modèle de dialogue et avoir une architecture N-Arches Etre indépendant plateforme : s’appuyer sur un modèle Etre indépendant dispositifs : s’appuyer sur les modèles d’IHM pour la plasticité Faire collaborer des modèles et pouvoir les changer Assurer la dynamique de l’application : assembler à tous les niveaux Déduire au maximum les assemblages Trouver le bon niveau d’IHM abstrait
Adapter l’interface à l’évolution du système (priorité 1) S’adresse au développeur ? Dialogues Intervention Si conflits Assemblage d’IHMs (Utilisation d’IHMs abstraites, puis Projection sur devices) Assemblage de services (Orchestrations, fusion d’aspects, Composants hiérarchiques) déduction
Adapter l’interface aux besoins utilisateurs (priorité 2) Device IS Service Marks Service Device IS Service IS Service WebCal Service WebCal Service 2 utilisateurs : le développeur ou l’utilisateur final Choix des services – organisation de l’IHM Choix des devices Dialogue
Adaptation du système (priorité 3) ? Déduire l’assemblage pour un utilisateur
Points communs aux adaptations visées Conception Exécution MPI M IHM Préférences, Contexte d’utilisation … Nouvelles Utilisations IHM Adaptation MD Adaptation Noyau Fonctionnel Apparition, disparition de services Evolution Noyau Fonctionnel MP Un langage abstrait orienté composition : SUNML puis LAIM / Flex Un composant d’IHM : représentation fractal Un modèle de dialogue et un modèle de plateforme Une collaboration entre les modèles
Déduire au maximum les assemblages : déduction PROLOG Assemblage d’Arches Orientées Services Trouver le bon niveau d’IHM abstrait : de LAIM vers SUNML, UsiXML… Modèles Collaboratifs Articulations entre Un Modèle de plateforme Un modèle d’IHM basé sur LAIM Un modèle de dialogue Thèse de Cédric Joffroy (année 1) RSTI 07 Architecture pour l'adaptation de Systèmes d'Information Interactifs Orientés Services" SEA 07 Architecture Model for Personalizing interactive service oriented Projets étudiants M2 Mobile HCI03 Component model and programming: a first step to manage Human Computer Interaction Adaptation" SUNML Thèse Audrey Occello ECBS-MBD 08 : Managing Model Evolution Using the CCBM Approach" Spécificités “priorité 1”
Trouver le bon niveau d’IHM abstrait : de LAIM vers UsiXML… Pour réutiliser les travaux existants Ontologies de présentation Ontologies métiers Déductions (IHM to NF) Vérifier la cohérence globale Appliquer les modèles collaboratifs (Audrey Occello) Initiateurs avec Grenoble : Ateliers IHM IDM UsiXML, Comet …. Intégration forte au groupe Cesame Master de Christophe Vergoni Collaboration Edelweiss INRIA Thèse à venir Application de la sûreté à la construction d’IHMs VV MDE08 Validation and Verification of an UML/OCL Model with USE and B: Case Study and Lessons Learnt IASSE 04 An Adaptation-safe Model for Component Platforms Spécificités “priorité 2” et “priorité 3”
Travaux futurs • Intégration et finalisation des différents axes de réflexion • Utilisation des modèles collaboratifs pour les applications fortement évolutives • Application aux interacteurs ambiants • Mise en œuvre d’une application complète