1 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
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” - PowerPoint PPT Presentation
Citation preview
Architecture Model for Personalizing Interactive Service-Oriented
ApplicationDe nombreux services
Des services pour gérer les supports physiques et les
interacteurs
Des services contraints
Des devices avec leurs caratéristiques
Des usages variés
Chaque utilisateur a ses propres intérets et besoins
Titre a changé !!
Ici, l’importance c’est :
On a une multitude d’éléments (services, dispositifs) utilisable
par les utilisateurs.
Mais son objectif est de choisir ce qu’il a besoin au moment où il
en est à besoin donc en fonction de ce qu’il est en train de faire
et de où il est (contexte)
Propre à chaque utilisateur, difficulté de savoir ce dont il peut
utiliser par rapport au fonctionnalité du système mais aussi des
devices qui peuvent personnel ou partagé.
Eléments tous représentés par des services aussi bien WS que
WSD.
Services à tous les niveaux => WS - WSD
Multiplicité des services
First of all, what is the current context ?
During the last 10 years, we saw the emergence of Internet.
Everybody can create applications or services and broadcast it.
This development can be made by students during projects or by
industrials or by the owner of an Information System.
So we don't have the control on all services we use.
There is also the technological rise. Yesterday, we use informatics
only in the office, or in science. Now everybody use informatics.
The devices changed too. They are more little, more mobile. So we
can use technology everywhere, with our mobile phone or our
PDA.
*
Un bâtiment universitaire équipé : SEDUITE
Des services métiers : News, Timetable, Marks, ..
Des devices variés : écrans plasma, PDA, téléphone mobile,
ordinateur personel, ...)
Pour illustrer la mise en œuvre des préférences, on se place dans
le cadre d’une application qui existe qui est l’application
SEDUITE, et c’est dans cette application que l’on va illustrer la
mise en place des préférences utilisateurs.
Public visé différent enseignant, étudiants, administratifs,
…
Donc a bien des besoins différents.
*
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
Notre proposition, comment va-t-on le résoudre ?
Préciser ces 3 points, en expliquant pourquoi on doit permettre de
personnaliser tout le système, et que cette personnalisation va
entrainer des adaptation à différents niveaux (SI - UI)
Séparer les différentes notions IS – UI – User (application très
évolutives)
Découpage existe depuis longtemps
Presque le plan
MVC (1979)
Modèle qui ont découpage clair
Retirer le discours, mettre en avant sur les schémas la séparation
IS – UI
Chacun de ces modèles permet de répondre à ces préoccupation
Nous on a choisit Arch parce qu’il embarque déjà une part de
personnalisation au niveau des adaptateurs.
Représente bien le SI et SInt
Et que l’utilisateur ressort bien.
*
1 Arche pour
1 service interactif
N services fonctionnels et leurs interactions utilisateurs :
comment fusionner le tout ?
Services
Fonctionnel
Services
Dialogue
Adaptor
Adaptor
On arrive au problème que si on souhaite représenter les besoins de
tous les utilisateurs dans les différents contextes d’utilisation
qu’ils peuvent avoir, ainsi que les différents services que l’on
peut avoir.
On se retrouve à devoir représenter toutes cela par une arche à
chaque fois ce qui fait que l’on a une explosion au niveau du
nombre d’arche, afin de représenter tout.
Problème de capitalisation !!!
L’utilisateur peut utiliser un même service sur différents
dispositifs.
Sur un dispositif différents services
Un même service, un même dispositifs, différents
utilisateurs.
Problème de redondance des informations => l’utilisateur devra
personnaliser à nouveau les services/dispositifs pour chacun des
usages
*
Composition d’arches ?
Assemblage des services
Quid des dialogues ?
Expression et fusion
Quid des IHM?
Expression et fusion
On arrive au problème que si on souhaite représenter les besoins de
tous les utilisateurs dans les différents contextes d’utilisation
qu’ils peuvent avoir, ainsi que les différents services que l’on
peut avoir.
On se retrouve à devoir représenter toutes cela par une arche à
chaque fois ce qui fait que l’on a une explosion au niveau du
nombre d’arche, afin de représenter tout.
Problème de capitalisation !!!
L’utilisateur peut utiliser un même service sur différents
dispositifs.
Sur un dispositif différents services
Un même service, un même dispositifs, différents
utilisateurs.
Problème de redondance des informations => l’utilisateur devra
personnaliser à nouveau les services/dispositifs pour chacun des
usages
*
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
Fusion de modèles
Travaux en IHMs
Plasticité des interfaces
Expression de modèles pour l’IHM (taches, dialogues…)
Pour éviter à l’utilisateur de devoir refaire ses préférences, on
se propose d’avoir une arche à n pied côtés SI m pieds côté SInt
pour capitaliser les préférences.
Rajouter des utilisateurs qui arrivent sur le DC pour bien
illustrer que l’on a qu’une arche pour tous les utilisateurs et pas
n arche pour les n utilisateurs.
Titre à revoir !!!
Découpage de haut niveau. Une boîte ne représente pas forcément un
service mais un assemblage de services.
*
Concrète :
Finale:
Fait le choix de l’environnement de programmation et
d’exécution
Contexte d’usage
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
Pour éviter à l’utilisateur de devoir refaire ses préférences, on
se propose d’avoir une arche à n pied côtés SI m pieds côté SInt
pour capitaliser les préférences.
Rajouter des utilisateurs qui arrivent sur le DC pour bien
illustrer que l’on a qu’une arche pour tous les utilisateurs et pas
n arche pour les n utilisateurs.
Titre à revoir !!!
Découpage de haut niveau. Une boîte ne représente pas forcément un
service mais un assemblage de services.
*
Adapter l’interface à l’évolution du système (priorité 1)
déduction
Projection sur devices)
S’adresse au développeur
Pour éviter à l’utilisateur de devoir refaire ses préférences, on
se propose d’avoir une arche à n pied côtés SI m pieds côté SInt
pour capitaliser les préférences.
Rajouter des utilisateurs qui arrivent sur le DC pour bien
illustrer que l’on a qu’une arche pour tous les utilisateurs et pas
n arche pour les n utilisateurs.
Titre à revoir !!!
Découpage de haut niveau. Une boîte ne représente pas forcément un
service mais un assemblage de services.
*
2 utilisateurs : le développeur ou
l’utilisateur final
IS Service
Marks Service
IS Service
WebCal Service
IS Service
WebCal Service
Pour éviter à l’utilisateur de devoir refaire ses préférences, on
se propose d’avoir une arche à n pied côtés SI m pieds côté SInt
pour capitaliser les préférences.
Rajouter des utilisateurs qui arrivent sur le DC pour bien
illustrer que l’on a qu’une arche pour tous les utilisateurs et pas
n arche pour les n utilisateurs.
Titre à revoir !!!
Découpage de haut niveau. Une boîte ne représente pas forcément un
service mais un assemblage de services.
*
Déduire
pour un utilisateur
Pour éviter à l’utilisateur de devoir refaire ses préférences, on
se propose d’avoir une arche à n pied côtés SI m pieds côté SInt
pour capitaliser les préférences.
Rajouter des utilisateurs qui arrivent sur le DC pour bien
illustrer que l’on a qu’une arche pour tous les utilisateurs et pas
n arche pour les n utilisateurs.
Titre à revoir !!!
Découpage de haut niveau. Une boîte ne représente pas forcément un
service mais un assemblage de services.
*
Noyau Fonctionnel
Un composant d’IHM : représentation fractal
Un modèle de dialogue et un modèle de plateforme
Une collaboration entre les modèles
MP
MD
Conception
Exécution
et description LAIM
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 dialogue
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
*
*
*
*
Spécificités “priorité 2” et “priorité 3”
Trouver le bon niveau d’IHM abstrait : de LAIM vers UsiXML…
Pour réutiliser les travaux existants
Ontologies de présentation
UsiXML, Comet ….
Master de Christophe Vergoni
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
*
*
Utilisation des modèles collaboratifs pour les applications
fortement évolutives
Application aux interacteurs ambiants