Ce document traite de l'adaptation des interfaces homme-machine (IHM) en fonction du contexte d'usage, en soulignant l'importance d'utiliser des modèles pour optimiser la conception et l'exécution des applications. Il aborde des concepts tels que les modèles de tâches, la plasticité et l'ingénierie des modèles, tout en explorant les avantages et les limites des différentes approches. Les recherches mentionnées incluent des travaux sur l'interaction utilisateur, l'ingénierie dirigée par les modèles, et l'influence croissante des nouvelles technologies sur le développement des IHM.

1. Adaptation des IHM
Travaux de recherche : importance d’utiliser des Modèles
Anne-Marie Dery - Année 2017 2018Parcours IHM Polytech’Nice Sophia

2. Prérequis pour le cours
• Connaitre la définition de l’adaptation et du contexte d’usage
• Connaître la notion d’arbre de tâches (cours de CEIHM)
• Connaître la notion de composants (cours SI4 ISA)
• Connaitre la notion d’ontologies
• Connaitre les principes de l’IDM (cours de Mireille Blay)

3. Adaptation et Contexte d’usage
Pour qui ? Quoi ? Quand ? Comment ?

4. Rappel de l’Espace problème
• Domaine de l’adaptation au contexte d’usage
Env ironneme nt
Pl ate-forme
Ut ilisate ur
Seuil de plasticité
Domaine de plasticité
C2
Contexte non couvert
C1 Contexte couvert par l’IHM

5. Adaptation pour qui et quand ?
2 cas
 A la conception – faciliter la vie du développeur
 Réutiliser un maximum pour chaque nouvelle cible
 Diminuer le coût de développement
 Prendre en compte l’usage (exemple Jeux vidéos -Shiva)
 A l’exécution – faciliter la vie de l’utilisateur final
 Faire migrer une application d’un support à un autre
 Faire migrer des taches d’un support à un autre
 Conserver les facilités l’usage et les habitudes tout en profitant des spécificités des supports

6. Premières Approches à la conception
XML
XSL
HTML
VoiceML
WML Au centre une description
XMLisée
basées sur des Traducteurs
Un langage commun
Une génération de code
Des techniques de compilation
Limites et Avantages ?

7. Premières Approche à l’exécution
• Problème traité : Migration totale
• Exemple
• SI la batterie du PC faiblit ALORS passer sur PDA
SI condition ALORS action
Action  Réaction
Ecrire une machine à états
Limites et Avantages ?

8. Capture du
contexte
Identification
Des solutions
candidates
Selection d’une
solution
candidate
Détection de
changement de
contexte
Identification du
changement de
contexte
Exécution du
prologue
Execution de la
reaction
Execution de
L’épilogue
Cadre de référence : phase “exécution”

9. Modèles de tâches
Quelles tâches adapter ?

10. Modèles de tâches
Les modèles de tâches sont des descriptions logiques des activités à
réaliser pour atteindre les objectifs des utilisateurs
Utiles pour concevoir, analyser et évaluer les applications logicielles
interactives
Les modèles de tâches décrivent comment les activités peuvent être
réalisées pour atteindre les objectifs des utilisateurs lors de
l’interaction avec l’application considérée.

11. Analyse et Modélisation de la tâche
formalisme type HTA
(Hierarchical Task Analysis) :
Ordonnancement des tâches
UAN (User Action Notation)
CTT (ConcurTaskTrees) = HTA
+ opérateurs temporels +
ajout d’annotations sur les
tâches

12. Arbre de tâches HTA : d’usage ou projeté

14. Adaptation et ontologies

15. http://scientifics.fr/ejde/html/1776-2960%20R251.htm

16. • Identifier le problème = Quel est le besoin en plasticité ?
• Moment : Conception et/ou exécution ?
• Contexte d’usage :
• Quels dispositifs visés ?
• Quel(s) environnent(s) ?
• Quel(s) utilisateur(s) ?
• Quelle solution ?
• Modèle sous-jacent – ref pyramide des 4 niveaux d’IDM et modèle de référence
CAMELEON;
• Présentation de la solution
• Apports pour la problématique d’adaptation
• illustration sur votre exemple : comment pensez vous pouvoir utiliser cette idée dans
votre avenir professionnel ?
• votre avis ? (avantages et inconvénients).
Analyse d’article : réflexion sur la plasticité

17. Quand les chercheurs s’en
mêlent…
CAMELEON : le cadre de référence
Projet ServFace : Travaux de Pise
Travaux sur UsiXML : Valenciennes , Louvain, Grenoble
Travaux Rainbow : Construction d’IHM par composition

18. Où trouver les informations
Equipe IIHM Laboratoire IMAG à Grenoble
Gaelle Calvary & Joelle Coutaz http://iihm.imag.fr/publication/
Equipe RAINBOW Laboratoire I3S à Sophia Antipolis
Michel Riveill & Philippe Renevier & Audrey Occello & Anne Marie Dery
http://www.i3s.unice.fr/fr/node/64
Laboratoire HIIS à l’université de Pise
Fabio Paterno http://giove.isti.cnr.it/Users/Fabio/#Publications
Laboratoire CHI Université catholique de Louvain
Jean Vanderdonckt http://uclouvain.academia.edu/JeanVanderdonckt/Papers
Equipe IHM au Université de Valencienne
Anas Hariri & Sophie Lepreux & Christophe Kolski
http://www.univ-valenciennes.fr/LAMIH-
intra/site/commun/_gestion/publis/recherche/resultat.php?id_perso=97&langue=lang_fr

19. Pour commencer…
L’Ingénierie des modèles c’est quoi ?
Et pourquoi c’est utile en IHM ?

20. Ingénierie des modèles : principes
http://www.theenterprisearchitect.eu/archive/2009/08/05/a-metaphor-for-model-driven-engineering
2
0

21. L’Electricien et l’Informaticien
Un problème, des besoins
Un composant virtuel
(des entrées des sorties)
Des portes AND, OR, NOR, …
Un schéma électrique
Le composant électrique
Le programme informatique
Modèle
21
X. Blanc -Université Paris 6

22. Principes
22
To distinguish a model from any other type of artefact, Stachowiak proposes three criteria for their
unique identification [40]: (1) Mapping criteria: It must be possible to identify the object or original
phenomenon (of the system) that is represented or mapped in the model; (2) Reduction criteria:
The model must be a simplified version of the original, so not all aspects of the original must be
depicted in the model; and (3)Pragmatism criteria: The model has to be useful; namely it should
be able to replace the original for certain purposes.
From : Model-driven engineering: A survey supported by the
unified conceptual model October 2015

23. Principes 23
From : Model-driven engineering: A survey
supported by the unified conceptual model

24. Principes
24
From : Model-driven engineering: A survey
supported by the unified conceptual model
October 2015

25. Modèles et
métamodèles
2
5

26. Modèle
• définition du standard UML
• "A model is an abstraction of a physical system, with a certain
purpose."
• "A model is a simplification of a system built with an intended goal in mind. The
model should be able to answer questions in place of the actual system.“ :
Bézivin et Gérbé
Magritte
26

27. Un modèle : un point de vue sur un système
Percentage
of termite infestation
in France.
The System
Models
France in 1453
The cheese
french map
Railroad map
in western
fFrance
System ModelrepOf
27

28. Modèle : abstraction/simplification
Make everything as simple as possible, but not simpler. by Albert Einstein
Metro avant 1949
28

29. MDA proposed R&D Agenda : "Everything is a model"
… (or may be converted into a model), not only PIMs and PSMs
1. A process is a model
2. A platform is a model
3. A transformation is a model
4. A system is a model
5. A metamodel is a model
6. A model-element is a model
7. A program is a model
8. An execution trace is a model
9. A measure is a model
10.A test is a model
11.A decoration is a model
12.An aspect is a model
13.A pattern is a model
14.A legacy system is a model
15.etc.
29

30. Modèle représentant un modèle
Ce n’est pas un métamodèle !
32

31. Un modèle n’a pas de signification sans « son
métamodèle »
Percentage of places infested
by termites in France.
First round of political
election in France in 2002.
33

32. Métamodèle dans l’IDM : vers des modèles
productifs
• dans le contexte de l'IDM, Warmer et ses collègues donnent la
définition suivante:
"A model is a description of (part of) a system written in a well-defined
language"
• "A meta-model is a model that defines the language for expressing a
model".
34

33. Des langages pour décrire des métamodèles
• Meta Object Facility (MOF)
• Eclipse Modeling Framework (EMF)
• Graph eXchange Language Metaschema (GXL)
• UML 2.0 infrastructure
• KM3
35

34. La pyramide des quatre niveaux
meta-meta modèle
meta
modèle
Données Utilisateur
M0
M1
M2
M3
36

35. Relations entre les niveaux
the UML Meta-Model
Class Attribute*
1
a UML Model
Client
Name : String
M2
M1
the MOF
Class Association
source
destination
M3
c2
c2
c2 meta
metamodel
model
" real world
The MOF
The UML metamodel
Some UML Models
Various usages
of these models
M0
M1
M2
M3
37
metametamodel

36. Relations entre les niveaux
the UML Meta-Model
Class Attribute*
1
a UML Model
Client
Name : String
M2
M1
the MOF
Class Association
source
destination
M3
c2
c2
c2
metameta meta
metameta
metamodel
model
" real world
meta-
meta
The MOF
The UML metamodel
Some UML Models
Various usages
of these models
M0
M1
M2
M3

38
metametamodel

37. Les 4 niveaux de modélisation
• Hiérarchie à 4 niveaux existe en dehors du MOF et d'UML, dans
d'autres espaces technologiques que celui de l'OMG
• Langage de programmation
• M0 : l'exécution d'un programme
• M1 : le programme
• M2 : la grammaire du langage dans lequel est écrit le programme
• M3 : le concept de grammaire EBNF
• XML
• M0 : données du système
• M1 : données modélisées en XML
• M2 : DTD XML
• M3 : le langage XML
39

38. Pour commencer…
L’Ingénierie des modèles c’est quoi ?
Et pourquoi c’est utile en IHM ?

39. IHMs : Un
monde en
pleine évolution
«logicielle»
4
1

40. Société du numérique
43

41. IHMs : Un monde en pleine évolution «logicielle»
44
➡Exigences : Accélération de la
production, grande adéquation à
l’utilisateur et réduction des coûts
• Multiplicité des supports (et de leurs capacités)
• Multi-modalités
• Démocratisation du «numérique» (accessibilité, richesse)
• Déplacement de la production du logiciel vers des experts «métiers»
• Intégration des IHMs aux environnements : documents collaboratifs
• BD : phpmyadmin; Processus Métier : bonitaSoft ; googleMap ; ....

42. Mais ...
• In many cases, the tools that exist rely on proprietary formats, or
APIs specific to particular programming languages, and this hinders
developers from switching between tools, and this is increasingly a
concern in a number of industries, e.g. aviation and automotive.
• The emergence of popular libraries such as jQuery demonstrate the
importance of reducing the burden on developers, and the need to
decouple the effort required to work on different aspects of design
and implementation of interactive application front ends.
• If you are focusing on the usability or styling of a user interface,
you shouldn't need to deal with the lower level details of how this
will be realized on a given device or platform.
45
Une autre approche de
la construction des
IHMs

43. model-based user interface
development environment (MBUIDE):
• includes a high-level, abstract and explicitly
represented (declarative) model about the
interactive system to be developed (either a task
model or a domain model or both)”
• exploits a clear and computer-supported relation
from (1) to the desired and running UI. That means
that there is some kind of automatic transformation
like knowledge-based generation or simple
compilation to implement the running UI.“
46
Past, Present, and Future of Model-Based
User Interface , nov. 2011
(Schlungbaum, 1996)

44. From model-based user interface development
environment (MBUIDE) to Model Driven ....
47
Past, Present, and Future of Model-Based
User Interface , nov. 2011
b

45. From model-based user interface
development environment (MBUIDE) to
Model Driven ....
48
Past, Present, and Future of Model-Based
User Interface , nov. 2011
b
Abstraction
des GUI et
Génération

46. From model-based user interface
development environment (MBUIDE) to
Model Driven ....
49
Past, Present, and Future of Model
User Interface , nov. 2011
b
Niveau
sémantique :
ex, modèles
de tâches

47. From model-based user interface development
environment (MBUIDE) to Model Driven ....
50
Past, Present, and Future of Model-
Based User Interface , nov. 2011
b
Interactions et
Devices :
independence
et choix
appropriés

48. From model-based user interface development
environment (MBUIDE) to Model Driven ....
51
Past, Present, and Future of Model-Based
User Interface , nov. 2011
b
Context-
Sensitive &
usability :
model driven
and not model
based

49. Modélisation des tâches
52
http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui-20100504/

50. MetaModèle de tâches
53

51. Modèle de tâches
54
<taskModel>
<task id='root' name='Digital Home' type='abstract'>
<relations>
<enabling left='login' right='access' />
<deactivation left='access' right='close' />
</relations>
</task>
<task id='access' name='Control System' type='abstract'
parent='root'>
<relations>
<choice>
<task id='home' />
<task id='entmt'>
<contextCondition situation='atHome' />
</task>
<task id='presence' />
</choice>
</relations>
</task>
<task id='home' name='Control Home' type='abstract'
parent='access'>
<relations>
<choice>
<task id='crooms' />
<task id='domesticappls' />
</choice>
</relations>
</task>
<task id='croom' type='abstract' parent='home' name='Control
Rooms'>
<relations>
<enablingInfo left='selroom' right='control' />
</relations>
</task>
</taskModel>

52. Transformations
de modèles
5
5

53. CORBA
Java/EJB
C#/DotNet
Web/XML/SOAP
PIM
etc.
Platform-Independent
Model
Multi-target
code generation
+ SVG, GML, Delphi, ASP, MySQL, PHP, etc.
data grid computing
pervasive computing
cluster computing
SMIL/Flash
[JB04
Modèles neutres
basés
sur UML et MOF
56
Model Once, Generate Anywhere

54. Principes “généraux” MDA de génération de code
Conforms
to
Conforms
to
57

55. Etapes du processus MDA
www.sqli.com/ressources/files/IBCom_mai2006_MDEMDA_ecourte.doc
CWM : Langage de modélisation pour les
entrepôts de données, Common Warehouse
Meta-model
XMI : XML Model Interchange, le standard des
échanges entre modèles
PDM : Plateform Description Model 58

56. Un exemple d’atelier
dédié aux IHMs basé
sur l’IDM
5
9
Image : http://www.sapdesignguild.org/editions/edition3/interact_design.asp

57. Un exemple d’atelier basé sur l’IDM
6
0
On stories, models and notations: Storyboard creation as an entry point for model-
based interface development with UsiXML
In Faure, D., Vanderdonckt, J., (Eds.), Proc. of 1st Int. Workshop on User Interface Extensible Markup Language UsiXML’2010 (Berlin,20 June 2010), Thales Research and Technology France,
Paris, 2010

58. StoryBoard
http://research.edm.uhasselt.be/~kris/research/projects/StoryBoardML/ 61
«To enable integration of ... storyboards with other models, we need a meta-
model for these storyboards.»

59. Un métamodele
pour les storyboard
62

60. IDM pour raisonner sur les IHMS
63

61. Using Software Metrics in
the Evaluation of a
Conceptual Component
Model
Using Software Metrics in
the Evaluation of a
Conceptual Component
Model
IHM auto-explicatives
Pourquoi?
Quoi?
Où?Comment?
Interface auto-explicative
... À sélectionner l’horaire
de la saisie d’absences
A quoi servent les
cases vertes?
Auto-explication par les modèles
64

62. Exploitation du modèle d’Interface
Concrète Utilisateur (CUI)
65
Users need your models!
Exploiting Design Models for Explanations
Garc´ıa Frey
Calvary
Dupuy-Chessa

63. UI Modeling as Ontology for Composition – Christian Brel
Increasing number of applications
6
6
Desktop/Mobile/Web

64. UI Modeling as Ontology for Composition – Christian Brel
Integration of same functionalities in several
applications
6
7
Encyclopedia
Social
Network
Hotel
Booking
Movie
Database
Travel
Plan

65. UI Modeling as Ontology for Composition – Christian Brel
Reuse functionalities without development
6
8
Adding Movie Theaters localization

66. UI Modeling as Ontology for Composition – Christian Brel
An interactive system to compose
applications
6
9
UI 2
Business
part 2
UI 1
Business
part 1

67. UI Modeling as Ontology for Composition – Christian Brel
An interactive system to compose
applications
7
0
New UI =
UI1 + UI2
UI 2
Business
part 2
UI 1
Business
part 1

68. UI Modeling as Ontology for Composition – Christian Brel
An interactive system to compose
applications
7
1
New UI =
UI1 + UI2
UI 2
Business
part 2
UI 1
Business
part 1

69. UI Modeling as Ontology for Composition – Christian Brel
Ports and Roles
Choix du métamodèle adapté à la composition
7
2

70. UI Modeling as Ontology for Composition – Christian Brel
Ports and Roles
Choix du métamodèle adapté à la composition
7
3

71. IDM & IHMS pour maitriser les
nouvelles applications
74
Travaux de Ivan Logre, Sophia Antipolis

72. Des millions d’«objets» connectés
➡Dashboards : pour «analyser», «comprendre», «apprendre», ....
75

73. Des widgets dédiées
76
2016 : 1,790,000 results
for Data Visualization Tools

74. Des Besoins «utilisateurs» variés
77

75. Une approche basée sur la composition de
modeles «as services»
78

76. Un cadre de référence dans le
domaine des IHM
CAMELEON
Cameleon
Context Aware Modelling for
Enabling and Leveraging Effective
interaction
http://giove.isti.cnr.it/projects/cameleon.html
(IST R&D 2001-2004)

77. Equipes et travaux en présence
http://giove.isti.cnr.it/projects/cameleon.html
• I.S.T.I (Pisa, Italy)
• Université Catholique de Louvain (Louvain, Belgium)
• Université Joseph Fourier (Grenoble, France)
http://giove.isti.cnr.it/projects/cameleon/external_publications.html
http://iihm.imag.fr/publication/C10a/ User Interface Plasticity: Model Driven
Engineering to the Limit!
http://iihm.imag.fr/publication/BDB+04a/ CAMELEON-RT: a Software
Architecture Reference Model for Distributed, Migratable, and Plastic User
Interfaces

78. Phase de “conception”
Config 1 Modèle
Tâches et
Concepts
IHM
concrète
IHM finale
IHM
abstraite
Modèle
Tâches et
Concepts
Modèles archétypes
Config 2
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
IHM
concrète
IHM finale
IHM
abstraite
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
Domaine
Concepts
Tâches
Contexte
User
Plate-forme
Environment
Adaptation
Evolution
Transition
Modèles ontologiques
ARTStudio
D. Thevenin
Réification, Factorisation, Traduction, Abstraction
/ Reconception, Crossing, Intervention Humaine
Spécifier 1 fois -> N Interfaces
 approche par modèles

79. Modélisation de la configuration
Domaine
Concepts
Tâches
Contexte
User
Plate-forme
Environment
Adaptation
Evolution
Transition
Modèles ontologiques
Adaptation dynamique
utilisateur
contexte d’usage

80. Modélisation de l’IHM
Modèle
Tâches et
Concepts
IHM concrète
IHM finale
IHM abstraite

81. Tâches &
Concepts
IHM
abstraite
IHM
concrète
IHM finale
Config 1
Différents niveaux d’abstraction

82. 85
Abstraction levels for multi-platform development
http://www.w3.org/2005/Incubator/model-based-ui/wiki/Main_Page
Indépendant
plateforme et
modalité

83. Exemple de transformation
86
http://personales.upv.es/jopana/Files/Conferences/A_Proposal_for_Enhancing.pdf

84. Exercice : Framework cameleon
Model-Driven Architecture
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platform
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platformRéification, Traduction, Abstraction

85. Cameleon Reference Framework
88

86. Phase de “conception”
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
Modèle
Tâches et
Concepts
IHM concrète
IHM finale
IHM abstraite

87. Phase de “conception”
Config 1 Modèle
Tâches et
Concepts
IHM
concrète
IHM finale
IHM
abstraite
Modèle
Tâches et
Concepts
Config 2
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
IHM
concrète
IHM finale
IHM
abstraite
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
CONFIGURATION 1 CONFIGURATION 2

88. Phase de “conception”
Config 1 Modèle
Tâches et
Concepts
IHM
concrète
IHM finale
IHM
abstraite
Modèle
Tâches et
Concepts
Config 2
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
IHM
concrète
IHM finale
IHM
abstraite
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
CONFIGURATION 1 CONFIGURATION 2

89. Phase de “conception”
Config 1 Modèle
Tâches et
Concepts
IHM
concrète
IHM finale
IHM
abstraite
Modèle
Tâches et
Concepts
Config 2
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
IHM
concrète
IHM finale
IHM
abstraite
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
CONFIGURATION 1 CONFIGURATION 2

90. Phase de “conception”
Config 1 Modèle
Tâches et
Concepts
IHM
concrète
IHM finale
IHM
abstraite
Modèle
Tâches et
Concepts
Modèles archétypes
Config 2
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
IHM
concrète
IHM finale
IHM
abstraite
Concepts
Tâches
User
Plate-forme
Environment
Evolution
Transition
Domaine
Concepts
Tâches
Contexte
User
Plate-forme
Environment
Adaptation
Evolution
Transition
Modèles ontologiques
ARTStudio
D. Thevenin
Réification, Factorisation, Traduction, Abstraction
/ Reconception, Crossing, Intervention Humaine
Spécifier 1 fois -> N Interfaces
 approche par modèles

91. Cameleon Reference Framework :
Transformations
94
Transformations
• Concretization : operation that transforms a particular model into another one of a lower level of
abstraction, ex : the Task and Domain level (task model and/or the domain model) is “concretized” into an
Abstract UI model,...
•Abstraction : operation that transforms a UI representation from any level of abstraction to a higher level
of abstraction. Reverse engineering of user interfaces is a typical example of abstraction.
•Translation : operation that transforms a description intended for a particular context of use into a
description at the same level of abstraction, but aimed at a different context of use.

92. The CAMELEON Reference Framework
95
http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui-
20100504/#crf

93. Différentes mises en oeuvre compatibles avec
le Framework de Reference Cameleon
96

94. SERVFACE
SERVICE ANNOTATIONS FOR USER INTERFACE
COMPOSITION
PROJET EUROPÉEN
http://giove.isti.cnr.it/Users/Fabio/

95. Vue d’ensemble
+Annotations de services avec des éléments d’interfaces
+Composition de services
+Génération de l’interface du service « composite » à
partir des annotations
+2 approches:
+1ière approche : composition visuelle des services
+2ième approche : composition dirigée par les tâches
Equipe de Fabio Paterno :
http://hiis.isti.cnr.it/publications.php

96. Annotations de services
[Izquierdo et al., 2009]

97. 1ière approche: Composition Visuelle
[Nestler et al., 2009] [Feldmann et al., 2009]
End-User Programming

98. 1ière approche: Composition Visuelle
[Nestler et al., 2009]
[Feldmann et al., 2009]
Services
(WSDL)
Services
Annotés
Auto-génération d’annotations
+ Annotations par
un “Expert”
Génération de
l’interface “abstraite”
Transformations:
1) M2M
2) M2C
Interface Finale
Service Annotator
Service Composer
MARIA

99. 2ième approche: Dirigée par les tâches
[Feldmann et al., 2009] [Janeiro, 2009]

100. 2ième approche: Dirigée par les tâches
8/15
[Feldmann et al., 2009]
[Janeiro, 2009]
Transformations:
1) M2M
2) M2C
Interface Finale
Services
Génération d’annotations
(IHM + tâches)
+ A partir des opérations du service
+ Une opération = une “tâche annotée”
+ Une “tâche annotée” = une tâche système
Génération des tâches intéractives
+ Chaque tâche d’interaction = une fenêtre (par défaut)
+ Intervention du développeur : enlever les doublons
Génération de
l’interface “abstraite”
MARIA

101. USIXML
PROJET EUROPÉEN
www.usixml.org

102. Projet Européen UsiXML
Définir, valider et standardiser un langage de description d'interfaces
utilisateur (UIDL) pour améliorer la productivité, la réutilisabilité et
l'accessibilité d'applications interactives
Un langage pour tous les acteurs de la constructions d’IHM
basé sur des niveaux d’expressivité et des outils différents
USer Interface eXtensible Markup Language
Le consortium 7 pays, 28 organisations : PME,
grandes entreprises -Thalès France, Telefonica -, des universités et
centres de recherche.
www.usixml.org
programme ITEA2

103. UsiXML
UsiXML USer Interface eXtensible Markup Language)
XML pour applications interactives
UsiXML pour des non développeurs : analystes, concepteurs,
designers, ergonomes, chefs de projet, novices,...
UsiXML : élément principal User Interface Description Language (UIDL),
langage déclaratif décrivant les UI indépendament des caractéristiques physiques.
www.usixml.org

104. UsiXML
•UsiXML indépendant device, plateforme et
modalités
•UsiXML abstraction des éléments de base : widgets,
controls, containers, modalités, techniques
d’interaction, ....
•UsiXML reutilisation d’UI existantes dans un nouveau
contexte par composition
www.usixml.org

105. UsiXML

106. 109
 Set of models for describing UI
(structure, presentation and dialog) at
different abstract levels, including:
 UI Model
 Mapping Model
 Domain Model
 AUI Model
 CUI Model
 Task Model
 Context Model
 Transformation
Model
 Resource Model

107. 110
The meta-model
for the UsiXML
context model.

108. Partial Context Model Generation
111
- Persona ➥ userStereoType
- Device element ➥ hardwarePlatform and softwarePlatform
- Annotations
* Noise ➥ isNoisy property and set it to true.
* Light ➥ lightningLevel property.
....

109. 112
UsiXML specification of task models for a car
rental system
UsiXML task Model
UsiXML task Model
rendered with
IdealXML

110. 1
1
3
UsiXML specification of abstract models
for a car rental system
UsiXML AUI
UsiXML AUI rendered by
GraphiXML

111. 114
Dialog options at concrete levels

112. 1
1
5
Exemple
1) Task model
2) Scenario
3) Abstract UI
5) Concrete dialog
6) Concrete UI
4) Abstract dialog

113. Zoom sur les travaux à Valenciennes
Sophie Lepreux
15 novembre 2013

114. Post-doc au sein du laboratoire BCHI à Louvain-la-neuve dirigé par Jean
Vanderdonckt
•Composition d’interfaces utilisateurs
(en résumé)
• basée sur UsiXML = langage de description d’interface
Utilisateur (UIDL) basé sur XML
• Centrée sur la couche de l’interface concrète = spécifique à
la modalité graphique
• Sur la base d’opérateurs inspirés de la théorie des
ensembles
• Utilisant l’algèbre des arbres [Jagadish et al.] pour modéliser les
opérateurs de composition
• Développement et tests effectués « à la conception» :
ComposiXML plug-in de GraphiXML outil de conception
d’interface concrète

115. Framework cameleon
Model-Driven Architecture
Source = < User, Platform,
Environment >
Target = < User, Platform,
Environment >

116. Framework cameleon
Model-Driven Architecture
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platform
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platform
textInput button button
Window
AIC
facet=control
AIC
facet=control
AIC
facet=control
AbstractIndividual
Container
textInput button button
Window
AIC
facet=control
AIC
facet=control
AIC
facet=control
AbstractIndividual
Container
Source = < User, Platform,
Environment >
Target = < User, Platform,
Environment >

117. UsiXML – Concrete
User Interface
<cuiModel id="FicheClient-cui_3" name="FicheClient-cui">
<window id="window_component_0" name="window_component_0"
width="300" height="200">
<box id="box_1" name="box_1" type="vertical">
<outputText id="output_text_component_2"
name="output_text_component_2« …
<box id="box_2" name="box_1" type=« horizontal">
<outputText id="output_text_component_3"
name="output_text_component_3« … >
<inputText id="input_text_component_5"
name="input_text_component_5" isVisible="true"
isEnabled="true" textColor="#000000" maxLength="50"
numberOfColumns="15" isEditable="true"/>
<box>
<box id="box_3" name="box_1" type=« horizontal">
<outputText id="output_text_component_4"
name="output_text_component_4« …
<inputText id="input_text_component_6"
name="input_text_component_6" isVisible="true« … />
<box>
<box id="box_4" name="box_1" type=« horizontal">
<button id="button_component_7"
name="button_component_7"/>
<button id="button_component_8" …/>
<box>
</box>
</window>
</cuiModel>
Window (id=window, name=window, width="300" height="200")
Box (type=« vertical »)
Button
(DefaultContent = Save)
Button
(DefaultContent=Close)
Output (Default value =« customer form »)
Box (type = horizontal)Box (type = horizontal)
Output
(…)
Input
(…)
Box (type = horizontal)
Output
(…)
Input
(…)
Window (id=window, name=window, width="300" height="200")
Box (type=« vertical »)
Button
(DefaultContent = Save)
Button
(DefaultContent=Close)
Output (Default value =« customer form »)
Box (type = horizontal)Box (type = horizontal)
Output
(…)
Input
(…)
Box (type = horizontal)
Output
(…)
Input
(…)

118. Les opérateurs ensemblistes

119. Opérateur « normal union »

120. L’opérateur « difference »
- -

121. L’opérateur « fusion »
Fusion(
, )=
algorithm:
The two trees T1 and T2 are merge at the %level R+1 to form the T3 window.
IF (direction = vertical)
Then Add box (vertical B’)
%Modify the window size:
T3.height = T1.height + T2.height
T3.width = T1.width
IF (direction = horizontal)
Then Add box (horizontal B’).
%Modify the window size:
T3.height = T1.height
T3.width = T1.width + T2.width
Add T1(R+1) in box B’, Add T2(R+1) in box B’.

122. ComposiXML
• Développé par Benjamin Michotte (BCHI)
intersection
Unique Union
Normal Union
Fusion
Difference
(right)
Difference
(left)
Equivalence
set selection Cut or extract
projection

123. Composition au niveau AUI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platform
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platform
textInput button button
Window
AIC
facet=control
AIC
facet=control
AIC
facet=control
AbstractIndividual
Container
textInput button button
Window
AIC
facet=control
AIC
facet=control
AIC
facet=control
AbstractIndividual
Container
Source = < User, Platform,
Environment >
Target = < User, Platform,
Environment >
LEPREUX S., HARIRI M-A., ROUILLARD J., TABARY D., TARBY J-C., KOLSKI C. (2007) « Towards Multimodal
User Interface Composition based on UsiXML and MBD principles ». Proc. of 12th International
Conference on Human-Computer Interaction HCI International'2007, Beijing, 22-27 July 2007.

124. Order a pizza
AUI01: Choose a pizza
Choose
size
Choose
toppings
Choose
vegetable
Choose
meat
AUI02: Give delivering
address
Give
name
Give
phone
Give
address
Choose
quantity
Composition au niveau AUI
AUI Model
AbstractContainer AUI0
AbstractContainer AUI03 AbstractContainer AUI02R2
AIC AIC AIC AIC AIC AIC AIC
AIC = AbstractIndividualComponent
The AUI model has been realized with IdealXML
(www.usixml.org)
<auimodel>
<abstractContainer id="idaio00" name="Order a pizza">
<abstractContainer id="idaio01" name="idaio01">
<abstractIndividualComponent id="idaio02"
name="Choose quantity">
</abstractIndividualComponent>
<abstractIndividualComponent id="idaio03"
name="Choose size">
</abstractIndividualComponent>
…
<abstractIndividualComponent id="idaio06"
name="[Choose meat]">
</abstractIndividualComponent>
</abstractContainer>
<abstractContainer id="idaio07" name="idaio07">
<abstractIndividualComponent id="idaio08"
name="Give name">
</abstractIndividualComponent>
…
</abstractContainer>
</abstractContainer>
</auimodel>
Equivalence in tree
representation

125. Case study
• The first existing application is ordering pizza.
• the task “Choose a pizza” is multimodal (cf. CUI
model and FUI (XHTML+VoiceXML))
• The task “Give delivering address” can not be
multimodal (and does not exist).
<outputText id="Ask_for_pizza_quantity"
name="Ask_for_pizza_quantity" defaultContent="Quantity:"/>
<inputText id="pizzaQuantity" name="quantity"
defaultContent="1"
voice_prompt="How many pizzas would you like?"
voice_event_help="Say a number between one and twenty."
voice_event_nomatch="Sorry I did not understand you."
voice_event_noinput="You have to pronounce a quantity of
pizza."/>
<voice_quantity:grammar>
<![CDATA[
#JSGF V1.0;
grammar pizza_quantity;
public <quantity> = 1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20
;
]]>
</voice_quantity:grammar>
</inputText>
<outputText id="Ask_for_pizza_size" name="Ask_for_pizza_size"
defaultContent="Size:"/>
<group voice_prompt="What size would you like?">
<radioButton id="radiobuttonSize1"
name="radiobuttonSize" defaultContent="small" />
<radioButton id="radiobuttonSize2"
name="radiobuttonSize" defaultContent="medium"/>
<radioButton id="radiobuttonSize3"
name="radiobuttonSize" defaultContent="large"/>
<voice_quantity:grammar>
<![CDATA[
#JSGF V1.0;
grammar pizza_size;
public <size> = small | medium | large ;
]]>
</voice_quantity:grammar>
</group>
Order a pizza
AUI01: Choose a pizza
Choose
size
Choose
toppings
Choose
vegetable
Choose
meat
AUI02: Give delivering
address
Give
name
Give
phone
Give
address
Choose
quantity
CUI
AUI
FUI

126. Case study
• The second existing application is to order
Chinese food.
• the task “Choose Meal” is GUI (cf. CUI model
and FUI (realized with GrafiXML)
• The task “Give delivering address” exists.
CUI
AUI
FUI
<cuiModel id="ChineseFood-cui_12" name="ChineseFood-cui">
<window id="window_component_0" name="window_component_0"
defaultContent="Chinese Food Order" width="263" height="491">
<gridBagBox id="grid_bag_box_1" name="grid_bag_box_1"
gridHeight="24" gridWidth="13">
<outputText id="output_text_component_2"
name="output_text_component_2"
defaultContent="APPETIZER :"/>
<checkBox id="checkbox_component_3"
name="checkbox_component_3"
defaultContent="Small Fried Shrimp"/>
<checkBox id="checkbox_component_4"
name="checkbox_component_4"
defaultContent="Nicky's Egg Roll"/>
<checkBox id="checkbox_component_5"
name="checkbox_component_5"
defaultContent="Fried Popcorn Shrimp"/>
<outputText id="output_text_component_6"
name="output_text_component_6"
defaultContent="STARTER :" isVisible="true"/>
<radioButton id="radiobutton_component_7"
name="radiobutton_component_7"
defaultContent="Seaweed Soup" isVisible="true"/>
<radioButton id="radiobutton_component_9"
name="radiobutton_component_9"
defaultContent="Hot and Sour Soup"/>
…
<button id="button_component_22"
name="button_component_22"
defaultContent="Cancel" isVisible="true"/>
<button id="button_component_23"
name="button_component_23"
defaultContent="Order" isVisible="true"/>
</gridBagBox>
</window>
</cuiModel>

127. Case study
• Goals:
• multimodal application allowing to order Chinese food or
pizza,
• reuse the “give delivering address” task from the Chinese
food ordering applicationAUI
AUI0: Order food
AUI0’: Choose food
AUI03: Choose meal
AUI02: Give
delivering
address
AUI01: Choose a pizza
Give
name
Give
phone
Give
address
[Choose
Appetizer]
[Choose
Starter]
choose
soup
Choose
rice
Choose
Quantity
Choose
Size
Choose
toppings
[Choose
Vegetable]
[Choose
Meat]
FUI

128. Composition au niveau des tâches
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platform
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platform
textInput button button
Window
AIC
facet=control
AIC
facet=control
AIC
facet=control
AbstractIndividual
Container
textInput button button
Window
AIC
facet=control
AIC
facet=control
AIC
facet=control
AbstractIndividual
Container
Source = < User, Platform,
Environment >
Target = < User, Platform,
Environment >
LEWANDOWSKI A., LEPREUX S., BOURGUIN G. (2007). Tasks models merging for high-level component
composition. J. Jacko (Ed.), Human-Computer Interaction, Part I, HCII 2007, Lecture Notes in Computer
Science (LNCS) 4550, Springer-Verlag, pp. 1129-1138, juillet

129. Composition au niveau des tâches
• Travaux de Gregory Bourguin et Arnaud Lewandowski
(Laboratoire d’informatique du littoral) et Jean-Claude Tarby
(LIFL) :
• Les arbres de tâches sont intégrés à chaque composant métier.
• La composition de composant métier => composition d’arbres de tâches
• => Toujours une notation avec structure arbres

130. Composition au niveau des tâches
• Illustration :
• 2 composants chat et tableau blanc possédant des tâches « similaires ».

131. Composition au niveau des tâches
• Illustration suite :
• Résultat de la composition (fusion).

132. Problématique de construction
d’IHM par composition

133. Projet ASPECT
Composition de composants
et de leurs IHMs
200
3

134. Equipes et travaux en présence
Equipe Rainbow
Anne-Marie Pinna-Dery and Jérémy Fierstone. Component model and
programming : a first step to manage Human Computer Interaction
Adaptation. In Mobile HCI’03, volume LNCS 2795, pages 456–460, Udine,
Italy, September 2003. L. Chittaro (Ed.), Springer Verlag.

135. Problématique
• Applications évolutives et adaptables
• accessibles via un PDA, un portable ou une station
• variabilité des fonctionnalités selon le contexte d'utilisation
(mode dégradé, connecté ou déconnecté, dépendance des ressources…)
• Applications construites à base de composants (composants métiers,
composants d’IHM, composants services…)
 S’appuyer sur les infrastructures systèmes (RMI, EJB, …)
 Fournir une plate-forme à composants
 Exemples :
• Agenda collaboratif
• Gestion commerciale (facturations, commandes, client, fournisseur)

136. Composition de composants
" Fusion de menus correspondants aux composants (1)

137. Composition de composants
" Fusion de menus correspondants aux composants (2)

138. Proposition :
modèle de composants et abstraction
• La communication entre composants
IHM et métier est exprimée par des
interactions
• Un langage abstrait de description
structurelle des IHMs : SUNML dans
la lignée de XForms, RIML,... (inspiré
de UIML)
• Composition de composants métiers
par interactions
• Règles de composition adaptées aux
IHMs
• Fusion de règles vérifiant la
cohérence de la composition
• Atelier de composition : Amusing
Réutiliser
des composants métiers
Composer les
IHMs des
composants
métiers
Un modèle de composant + ISL + SUNML
Un modèle de composants qui découple composant métier et composants d ’IHM.
Spécification d ’ IHM
indépendantes du support

139. De l’IHM abstraite vers l’IHM concrète
JFrame1
JPanel1
JLabel1 JField1 ...
IHM concrète (Exécution)
Projection
FicheClient
MainDialog
LabelFieldNom FieldNom ...
IHM abstraite (Exécution)
HMI
Dialog
Field Field
JFrame
JPanel
JTextFieldJLabel
<sunml>
<interface id="FicheClient">
<structure>
<dialog id="MainDialog" sequence="true"> ...
<field id="LabelFieldNom" mode="read">
<element type="String">Nom :</element>
</field>
<field id="FieldNom" mode="read-write">
<element type="String">Toto</element>
</field> ...
</dialog>
</structure>
</interface>
</sunml>
Fichier SUNML (Spécification)
Réification
durand
Composant métier (Exécution)
?
?
?

140. Exemple de Liste de Clients
<sunml>
<interface id="ListeClients">
<structure>
<dialog id="MainDialog" sequence="true">
<list id="ListeClients" reference="FicheClient"
select="Field[FieldNom]"/>
</list>
</structure>
</interface>
</sunml>
Fichier SUNML (spécification)
Exemple en Swing
Composition Représentant – Client (1-n) : Liste de clients

141. De l’IHM abstraite vers l’IHM concrète
Séparation du composant d’IHM du composant métier
Expression des communications possibles entre ces composants avec
ISL
Adaptation des composants suivant le contexte d’exécution
durand
FicheClient
IHM concrète
IHM abstraite
Composant métier
JFrame1
Légende
Instance
interaction
Controleur

142. Exercice : SUNML et ISL ?
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platform
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
 Task & Concepts
 Abstract UI
 Concrete UI
 Final UI
Source platform Target platform

143. Equipe RAINBOW I3S
Construction d’applications
adaptables par composition

144. Un modèle inspiré d’Arche pour les services
Proposer un modèle d’architecture
pour un service interactif
N services fonctionnels et leurs interactions utilisateurs : comment
fusionner le tout ?
Services
Fonctionnel
Services
D’interaction
AdaptorAdaptor
Dialogue

145. Quid des assemblages
Comment fusionner 2 services respectant l’architecture?
Composition d’arches ?
Assemblage des services
fonctionnels
Quid des dialogues ?
Expression et fusion
Quid des IHM?
Expression et fusion

146. 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…)

147. 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

148. Adapter l’interface à l’évolution du système
déduction
Assemblage de services
(Orchestrations, fusion
d’aspects, composants
hiérarchiques)
Assemblage d’IHMs
(Utilisation d’IHMs abstraites,
Puis projection sur devices)
Intervention
Si conflits
S’adresse au développeur

149. Adapter l’interface aux besoins utilisateurs
2 utilisateurs : le développeur ou
l’utilisateur final
Choix des services organisation de
l’IHM
Choix des devices
Dialogue
Device Device
IS Service
Marks Service
IS Service
WebCal Service
IS Service
WebCal Service

150. Adaptation du système
Déduire
l’assemblage
pour un utilisateur

151. MPI
Points communs aux adaptations visées
Conception Exécution
Noyau Fonctionnel
IHM
Evolution Noyau Fonctionnel Apparition, disparition de services
Nouvelles Utilisations Préférences, Contexte d’utilisation …
Adaptation
Adaptation
M IHM
Un langage abstrait orienté composition : SUNML
Un composant d’IHM : représentation fractal
Un modèle de dialogue et un modèle de plateforme
Une collaboration entre les modèles

152. QUID des IHMS pour l’IDM
155
IMAGES : http://www.123rf.com/photo_15881605_illustration-of-people-doing-business-inside-the-virtual-world-
of-internet.html

153. Model driven software migration :
Abstraction
15
6
• Code = la logique applicative, la persistance, la gestion des erreurs, ...
➡on attend d’un modèle de réduire la complexité en allant à l’essentiel.
• Deux points de départ à l’abstraction :
➡la structuration des codes et
➡les interfaces internes et externes des programmes : en particulier les GUI !
Les menus, options, .. représentent des points d’entrées d’actions utilisateurs possibles :
l’ensemble des points d’entrées dans les processus métier!
➡Un modèle du code est obtenu par «abstraction» des codes sous-jacent aux
GUI.
Model-Driven Software Migration: A Methodology: Reengineering, Recovery and Modernization
of Legacy Systems (Google eBook), Christian Wagner, Springer Science & Business Media, Mar 10,

154. Emergence du métamodèle ?
15
7
https://openflexo.org

155. Expression & visualisation de la complexité
15
8
http://www.iutbayonne.univ-pau.fr/~roose/gdri3/images/ThomasPolacsek.pdf

156. Expression & visualisation
de la complexité
15
9
http://www.iutbayonne.univ-pau.fr/~roose/gdri3/images/ThomasPolacsek.pdf

157. Expression & visualisation
de la complexité
16
1http://www.iutbayonne.univ-pau.fr/~roose/gdri3/images/ThomasPolacsek.pdf

158. Spécification
dirigée par les
IHMs
162
http://arstechnica.com/science/2015/08/mit-claims-to-have-found-a-language-u

159. Systèmes complexes : de la specification par
l’exemple à la génération d’IHMS
16
3Designing Functional Specifications for Complex Systems, HCI 2016
- Controlling such a system onboard requires widgets for high-level control
and monitoring, allowing functions to be run more easily.
- Functional specifications are user’s sequences of actions on the system,
required for performing functions taking into account all possibilities
(configurations).
- The task of the expert in system design is to define these functional
specifications. S/he writes these latter in natural language, and then
provides them to the designers of the supervision interface and the control-
command code.
- The designers’ job is to implement and integrate these specifications into
the system.
Case Study : a system for the production, storage and distribution of
fresh water, onboard a ship

160. Systèmes complexes : de la specification par
l’exemple à la génération d’IHMS
16
4
Designing Functional Specifications for Complex Systems, HCI 2016
- Specification interpretation errors come from the difference of
technical knowledge between prescribers (mechanic engineers) and
designers (computer system engineers and/or control-command
engineers)
Case Study : a system for the production, storage and distribution of
fresh water, onboard a ship

161. Spécification d’un
système complexe
16
5Designing Functional Specifications for Complex Systems, HCI 2016

162. Spécification d’un système complexe
16
6Designing Functional Specifications for Complex Systems, HCI 2016
- 7 functions to be specified (transfer, treatment, embedded distribution,
distribution from quay, production, loading and unloading)
- Each function can be performed according to several configurations.
- Possibility of performing several functions simultaneously.
- The expert’s task is to define
- 73 unit configurations (functional specification)
- and simultaneous executions

163. Spécification d’un système
complexe
16
7Designing Functional Specifications for Complex Systems, HCI 2016
- S/He provides them to the designers of the supervision interface and the
control-command code. The designer’s job is then to implement and
integrate these specifications into the system.

164. Processus de production du Système :
exemple
16
8Designing Functional Specifications for Complex Systems, HCI 2016

165. Processus de production du Système
16
9Designing Functional Specifications for Complex Systems, HCI 2016