UsiXML July, 2004 (Hamburg, Germany) 1 USIXML: a Language Supporting Multi-Path Development of User...

July, 2004 (Hamburg, Germany) 1usiXML

USIXML: a Language Supporting Multi-Path Development of User

InterfacesQuentin Limbourg1, Jean Vanderdonckt1, Benjamin

Michotte1, Laurent Bouillon1, Víctor M. López Jaquero1,2

2Computer Science Research Institute (I3A)LoUISE Research Group

University of Castilla-La ManchaAlbacete, Spain

1Belgian Laboratory of HCIUniversity Catholic of Louvain

Louvain-la-neuve, Belgium


UIs ARE RUNNING FAST ... AFTER CHANGE

Task redefinitions Tasks reallocation Organizational adaptation Domain evolution Obsolescence of languages New languages New platforms …


DEVELOPMENT PATHS

To face these challenges several development paths may be identified:– Forward engineering– Reverse engineering– Adaptation to context of use– Middle-out approach– Widespread approach


MULTI-PATH DEVELOPMENT

To support these approaches in a single framework we need:– An ontology of concepts valid for all

paths.– A central strorage of models.– A mean to express model

transformations.– An execution mechanism for performing

transformations.


ONTOLOGY

Task (CTT + minor improvements). Domain (Class + Object diagram +

improvements) Abstract User Interface (vocabulary

independent of the modality) Concrete user interface (vocabulary

independent of the platform) Context of use (subset of CC/PP standard) Inter-model relationship mappings

(traceability, integration of all views)


SYNTAX

Abstract syntax– Directed, labelled, attributed, typed graphs. – Nodes are concepts.– Edges are relationships between these concepts.– Result: a UI specification is a BIG WHOLE

graph. Concrete syntax : USIXML

– User Interface eXtensible Mark-Up Language – (graph structure is achieved by defining

explicitly relationships)


MODEL-TO-MODELTRANSFORMATION IS THE NAME OF THE GAME

Uses language

Meta-Meta-ModelGraph Structure

is instance of

Meta-ModelusiXML Meta-Model

Meta-Model Subset 1e.g., Task+Domain Model

is instance of

Meta-Model Subset 2e.g., Concrete UI Model

is instance of

Initial UI Modele.g., MyTaskAndDomainModel

Resultant UI Modele.g., MyConcreteUIModel

Transformation RuleusiXML Transformation Catalog


DEVELOPMENT PATH CONNECTION TO TRANSFORMATIONS

Development step

Development step

Development sub-step


Development path

Development path

Transformation System


TransformationRule

TransformationRule

isComposedOf

isRealizedBy

isComposedOf

isComposedOf

*

1

*

1

1

*

1

0..1

Methodological World

Graph Transformation World

Development step

Development step



Development path

Development path



TransformationRule

TransformationRule

isComposedOf

isRealizedBy

isComposedOf

isComposedOf

*

1

*

1

1

*

1

0..1



Development step

Development step



Development path

Development path



TransformationRule

TransformationRule

isComposedOf

isRealizedBy

isComposedOf

isComposedOf

*

1

*

1

1

*

1

0..1



A development library and transformation models are available to store and resuse the defined development paths and transformations.


TRANSFORMATION PATHS, STEPS, SUB-STEPS

Task and DomainTask and Domain

Abstract User Interface


Concrete User Interface


User InterfaceCode

User InterfaceCode

Reification

Abstraction

Translation

Code Generation

Code Reverse Engineering

Forward Engineering

section 4.1.1section 4.1.2

section 4.1.3

Reverse Engineeringsection 4.2.1


Context Adaptation


section 4.3.3

Task and DomainTask and Domain





User InterfaceCode

User InterfaceCode

Reification

Abstraction

Translation

Code Generation


Reification

Abstraction

Translation

Code Generation


Forward Engineering


section 4.1.3

Reverse Engineeringsection 4.2.1


Context Adaptation


section 4.3.3


TRANSFORMATIONS

In the literature: – APIs

– XSLT

– …

Drawbacks– Execution semantics is poorly defined

– Consistency of resultant model

– Procedurality

– Cryptic syntax


CONDITIONAL GRAPH REWRITTING

Generalization of string grammars. Grounded execution semantics (pushout construction). Side-effect free. Attractive syntax. Declarativeness. Seamlessness with ontological world (rules manipulate

patterns of specification). The rules are applied in a pure sequential programmed

graph rewritting manner.


HOW IT WORKS … Find an occurrence of LHS in G (this

occurrence is called a match). If several occurrences exist, choose one non-deterministically.

Check preconditions of both type PAC and NAC. If not verified, then skip.

Remove the part of G which corresponds to (LHS – K), where K is the morphism specified between LHS and RHS.

Add RHS – K to the result of last step.

Embed RHS – K into G – (L – K) as it is given by the corresponding relation between RHS – K and K.

LHS

G

RHS

G’

r

m m*

r*

LHS

G

RHS

G’

r

m m*

r*

Check postconditions of both type PAC (and notably that the resulting graph is properly typed) and NAC. If not verified, then undo the transformation rule.


VISUAL SYNTAX

LHS RHS

::=

LHS RHS

::=


EXAMPLEWIDGET REPLACEMENT

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><cuiModel name="MyModel"> <version modifDate="2004-03-24T17:09:17.402+01:00" xmlns="">7</version> <authorName xmlns="">Youri</authorName> <window height="500" width="600" name="Formulaire (2/5)" id="window_1"> <box relativeHeight="100" name="box1_0" id="box1_0"> <box type="vert" name="boxTodo" id="boxTodo"> ... <box type="horiz" name="box_2_2_2_1" id="box_2_2_2_1">

<textComponent defaultContent="Sexe" isBold="true" id="label_2"/><radioButton groupName=“grupo01" defaultContent="Femme"

defaultState="false" id="radiobutton_0"/><radioButton groupName="grupo01" defaultContent="Homme"

defaultState="true" id="radiobutton_1"/> </box> ... </box> </box> </window></cuiModel>

Excerpt for an usiXML CUI specification.



The usiXML graph before aplying any rule



LHSRHS

NAC

Rule 1: Create a new comboBox with the same id and name as the name of the group of radioButtons.



Rule 1: Create a new comboBox with the same id and name as the name of the group of radioButtons.

The usiXML graph after aplying the first rule



LHS RHS

::=

Rule 2: Convert every radioButton within the group “x” into an item for the comboBox “x”, we have just created.



Rule 2: Convert every radioButton within the group “x” into an item for the comboBox “x”, we have just created.

The usiXML graph after aplying the second rule


<?xml version="1.0" encoding="UTF-8" standalone="yes"?><cuiModel name="MyModel"> <version modifDate="2004-03-24T17:09:17.402+01:00" xmlns="">7</version> <authorName xmlns="">Youri</authorName> <window height="500" width="600" name="Formulaire (2/5)" id="window_1"> <box relativeHeight="100" name="box1_0" id="box1_0"> <box type="vert" name="boxTodo" id="boxTodo"> ... <box type="horiz" name="box_2_2_2_1" id="box_2_2_2_1">

<textComponent defaultContent="Sexe" isBold="true" id="label_2"/><comboBox id="comboBox001" name="label_3" isDropDown="true"> <item id="radiobutton_0" name="radiobutton_0" defaultContent="Femme"/> <item id="radiobutton_1" name="radiobutton_1" defaultContent="Homme"/></comboBox>

... </box> </box> </window></cuiModel>


Excerpt from the final transformated usiXML specification


TOOL SUPPORT

Running prototypes– TransformiXML API : transformation tool– GrafiXML : CUI Hi-Fi + Code Generator (Java Swing,

XHTML) – SketchiXML : CUI Sketching Lo-Fi– VisiXML : CUI Lo-Fi, MS Visio Plug-in – FlashiXML : flash renderer – ReversiXML : reverse engineering from HTML to CUI

In development:– TransformiXML GUI : transformation tool– Task and AUI editors– Tcl/Tk renderer

In cooperation :– Teresa (F. Paterno, CUI level)


TRANSFORMIXML API

<window><button>....

<window>

USIXML specification(initial)

::=

Transformation rules expressed in USIXML


<window>

USIXML specification(resultant)

Transformation API

rules applied


<window>

USIXML specification(initial)

::=


::=



<window>

USIXML specification(resultant)

Transformation API

rules applied


GRAFIXML


FLASHIXML


TRANSFORMIXML GUI


CONCLUSIONS

Key ideas:– usiXML represents specification models as BIG WHOLE graphs, it

allows the expression of (1) multiple levels of abstraction of UI models (2)development steps (of all sorts) by using conditional graph rewritting rules.

Advantages of our approach:– Ontological commitment: our language can be criticized as it is defined

in all its dimensions, from concepts to concrete syntax, from task and domain until concrete user interface.

– Opens the black box of transformation.– Decomposes transformation into meaningful chunks: separation of

concern at methodological level. – Capitalization on transformational heuristics.– Multiple-entry points and multiple exit points = flexibility. – Model exchange formalism -> tool interoperability. – Extendibility, usiXML was planned to receive contributions (3D, multi-

modal, multi-surface interaction).– Tracaebility of design decisions .


FUTURE WORK

Pattern expression using usiXML chunks. Extension to other modalities (e.g., 3D, multi-

modal). Integration of other models in the framework

(e.g., workflow models?). Continue the development of ongoing tools …


THANK YOU!

See you on www.usixml.org !

UsiXML July, 2004 (Hamburg, Germany) 1 USIXML: a Language Supporting Multi-Path Development of User...

Documents

Transcript of UsiXML July, 2004 (Hamburg, Germany) 1 USIXML: a Language Supporting Multi-Path Development of User...