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