Laboratoire d’Informatique de Grenoble Mai 2013

Plasticitédes Interfaces Homme-Machine

par Ingénierie Dirigée par les Modèles

Eric CéretSophie Dupuy-Chessa

Gaëlle Calvary

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Problématique

• Croissance du nombre de dispositifs interactifs

• Multiplication des modalités d’interaction

• Désir de « continuitéde service » simple

� Besoin d’adapterdynamiquement l’IHM à la situation

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Besoins

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Besoins

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

ATTENTION !

Besoins

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

�������Le rôti est cuit !

Besoins

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Besoins

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

BesoinsAdaptation « automatique » et dynamique au contexte d’usage

• Utilisateur

• Plateforme

• Environnement

(in)capacités, langue, préférences,…

Dispositifs présents, systèmes, ressources

Luminosité, bruits, contexte social,…

dans le respect des bonnes propriétés pour l’utilisateur

= plasticité des IHMs

Calvary, G., Coutaz, J., and Thevenin, D. A Unifying Reference Framework for the Development of Plastic User InterfacesIn M. Little and L. Nigay, eds., Engineering for Human-Computer Interaction. Springe r Berlin / Heidelberg, 2001, 173–192.

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Existant

• De nombreuses techniques :

• Développement de plusieurs IHMs pour des situations sélectionnées

• Adaptation pré-câblée ex. HTML+CSS : type de media, taille d’écran,…

• Portabilité (Java, QT, GTK…)

• …

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Existant : les limitesPortabilité (Java / HTML / ...)

Google Drive sur iPhonelemonde.fr sur iPhone

Problèmes : dégradation de l’interfaceadaptation très partielle à un contextecouverture partielle des contextes possibles

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Existant : les limitesPortabilité adaptable (Android SDK, QT)

TaskManager sur tablette Android TaskManager sursmartphone

Problèmes : définition de multiples contextesadaptation partielle à un contextecouverture partielle des contextes possibles

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Existant : les limitesDéveloppement multiple

« Le Monde » sur PC Application sur iPhone

Problèmes : coûtcomplexitécouverture partielle des contextes possibles

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Existant : les limitesHTML + CSS

« lemonde.fr » sur écran Aperçu avant impression

Problèmes : adaptation partielle à un contextecouverture partielle des contextes possibles

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Modèles pour la plasticité

le code source n’est plus considéré comme

l’élément central d’un logiciel, mais comme un

élément dérivé d’éléments de modélisation.

Présentation des Journées Neptune 2013

L’IHM devient AUSSI un élément dérivé de modèles

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Modèles pour la plasticité

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Modèles pour la plasticitéIHM Concrète (CUI)

Manage Home Comfort : Window

Select Room :HBox

Set Room Temp : HBox

Room Selection :Listbox

OK : Button

Input Temp : TextField

µµµµ

© JS Sottet

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Room

Cellar Kitchen Desk BedRoom

Modèles pour la plasticitéModèle de domaine / concepts

Manage Home Comfort : Window

Select Room :HBox

Set Room Temp : HBox

Room Selection :

Listbox

OK : Button

Input Temp :

TextField

µµµµ

µµµµ

© JS Sottet

CUI

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Modèles pour la plasticitéModèle d’IHM abstraite (AUI)

Manage Home Comfort : Window

Select Room :HBox

Set Room Temp : HBox

Room Selection :

Listbox

OK : Button

Input Temp :

TextField

µµµµ

Room

Cellar Kitchen Desk BedRoom

µµµµ

Manage Home Confort

SelectRoom

Set Room Temp.

µµµµ

© JS Sottet

CUI

Domaine

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Modèles pour la plasticitéModèle de tâches

Manage Home Comfort : Window

Select Room :HBox

Set Room Temp : HBox

Room Selection :

Listbox

OK : Button

Input Temp :

TextField

µµµµ

Room

Cellar Kitchen Desk BedRoomµµµµ

Manage Home Confort

SelectRoom

Set Room Temp.

µµµµ

© JS Sottet

Select Room

Set RoomTemp.

>>[]>>[]>>[]>>[]

Manage Home

Confort

∗∗∗∗

µµµµ

UpdateTemp.

>>[]>>[]>>[]>>[]

CUI

Domaine

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Modèles pour la plasticitéModèle de tâches

Manage Home Comfort : Window

Select Room :HBox

Set Room Temp : HBox

Room Selection :

Listbox

OK : Button

Input Temp :

TextField

µµµµ

Room

Cellar Kitchen Desk BedRoomµµµµ

Manage Home Confort

SelectRoom

Set Room Temp.

µµµµ

© JS Sottet

µµµµχχχχ

χχχχ

Domaine

CUI

AUI

Manage Home

Confort

Select Room

Set RoomTemp.

>>[]>>[]>>[]>>[]

∗∗∗∗Tâches

Set RoomTemp.

>>[]>>[]>>[]>>[]

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Modèles pour la plasticitéGénération de l’IHM Finale

Modèle de

tâches

IHM

abstraite

IHM

concrète

ττττ

ττττ

ττττ

IHM finale

Utilisateur

Plateforme

Environnement

QOC

Qualité

Domaine

Organisation

Transformation

Robot

Interacteurs

Programme

Workflow

Projets 2000 – 2013 CaméléonEMODEUsiXML V1UsiXML v2

Respect des bonnes propriétéspour l’utilisateur

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

AdaptationsAdaptation du style

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

AdaptationsAdaptation des modalités d’interaction

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

AdaptationsAdaptation des interacteurs

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

AdaptationsAdaptation de la structure

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

AdaptationsAdaptation des tâches

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

AdaptationsMigration totale / partielle

Remodelage

Paris14:30:49

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Adaptations

Style

Structure

Tâche

Modalité d’interaction

Interacteurs

Remodelage

Migration partielle / totaleRedistribution

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Coût d’apprentissage

rule AuiInteractionUnit2CuiInteractionUnit{froma:Abstract!AuiInteractionUnittoc:Concrete!CuiInteractionUnit (title <- a.title,

auiInteractionUnit2 <- a.auiInteractionUnit2,auiObject1 <- a.auiObject1)

}rule AuiObject2CuiObject{

froma: Abstract!AuiObjecttoc:Concrete!CuiObject (id <- a.id, label <- a.label, longLabel <- a.l

, help <- a.help, shortLabel <- a.shortLabel, cont}

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Adoption des méthodes

Les développeurs résistent à appliquer une méthode :

• Inadéquation au projet

• Difficulté d’apprentissage

• Processus complexe, linéaire, rigide, inadapté aux compétences

���� Méthode adaptable���� Flexibilité du modèle de processus

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Flexibility

Cycle

Collaboration Recommended Use

MaturityArtefacts

VariabilityVariability

CompletenessCompleteness

DistensibilityDistensibility

GranularabilityGranularability

UserCentring

UsageCentring

External

Roles

Internal

Roles Forms

Increment

Iteration

Parallelism

Backwards

Duration

Approach

Focus

Project size

Team size

Requirementsmaturity

Risk

Application type

Expertise

internal

non-exec.

formalisationquantity

formalisationquantity

executable

deliverables

formalisationquantity

formalisationquantity

executable non-exec.

Validation

Metric

Formalisation

Diffusion

Promote

E. Céret, S. Dupuy-Chessa, G. Calvary, A. Front, D. Rieu , A Taxonomy of Design Methods Process Models, Information and Software Technology Volume 55, Issu e 5 (mars 2013), pp. 795-821

Flexibilité du modèle de processus

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Adaptation par les modèles du métierAdaptation par les modèles de l’IHM

M2Flexmétamodèle de processus flexible

E. Céret, S. Dupuy-Chessa, G. Calvary,M2Flex: a process metamodel for flexibility at runtime, IEEE Research Challenges in Information Science, RCIS’2013, Paris, in press

Variabilité

Variabilité

Granularabilité

Complétude

Distensibilité

( )trueisOptionala

trueisOptionalsinputas

StatussActivitya

=⇒

=∧∈∈∀∈∀

.

..

,,

Flexibilité du modèle de processus

���� Adaptation par les modèles du processus

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

D2Flex : outil de conception de modèle de processus

Granularabilité

Complétude

Variabilité

Flexibilité du modèle de processus

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

ConclusionPlasticité des IHMs

Modèle de

tâches

IHM

abstraite

IHM

concrète

ττττ

ττττ

ττττ

IHM finale

Utilisateur

Plateforme

Environnement

QOC

Qualité

Domaine

Organisation

Transformation

Robot

Interacteurs

Programme

Workflow

Style

StructureTâche

Modalité d’interactionInteracteurs

Remodelage

Migration partielle / totaleRedistributionCapacité d’une Interface Homme-Machine (IHM)– À s’adapter

– À son contexte d’usage <Utilisateur, Plateforme, Environmt>

– Dans le respect des bonnes propriétés pour l’utilisateur

Complexité de l’approche

Paradigme peu connu

Using Software

Metrics in the

Evaluation of a

Conceptual

Component Model

1. Problématique

2. Besoins

3. Existant

4. Modèles

5. Adaptation

6. Flexibilité

7. Conclusion

Conclusion

VariabilityVariability

CompletenessCompleteness

DistensibilityDistensibility

GranularabilityGranularability

Promote : Flexibility

M2Flex – métamodèle de processus flexible

D2Flex – design de processus flexible

R2Flex – exécution de processus flexible

Flexibilité du modèle de processus