Discussion

Mapping Type Description

IsDynamicallyRelated Addresses the creation of elements based on dynamic data.

This is crucial to deal with input capabilities that depend on data unknown at design-time like e.g. a list populated with dynamically generated elements where each should be directly addressable via speech at runtime.The mapping is established to dynamic interactors (DynamicInput and DynamicOutput) which allow the identication of template elements and variants, that can be populated with the dynamic data. This allows the relation of dynamic data and the concrete visualization of input options related to this data. The transformation method can be utilized to incorporate the dynamic data into the input construct of a given type.

IsAccessedThrough Relates an interaction object with an interaction resources that is used to present or manipulate the object.

IsAdaptedBy Denes the adaptation of an interaction object according to context information.

Table 5.7.: The predened mapping types supported by the mapping model to relate the dened elements.

While the IsPerformedBy and the Uses mapping mainly focus on the workow and ob-ject management the IsStateSynchronized, IsValueSynchronized and IsDynamicallyRe-lated directly address the user interface management. IsAccessedThrough and IsAdapt-edBy are related to context information. Linking the models together via these mappings allows the combination of the dierent models to a comprehensive executable system, ex-changing information between the models, with the user and the service backend. The combination of the dierent models also allows the interpretation of the interaction on dierent levels of abstraction.

They aim at the integration with a runtime architecture instead of the derivation of executable code.

While especially UsiXML and TERESA XML comprise a similar set of models there are some major dierences. In case of the interaction model, UsiXMLs abstract user interface model distinguishes components, containers and relations. Components can have one or more facets of the type: input, output, navigation, control. Containers group components and subcontainers and dene an order type and if the group is splittable. Relationships dene time and space, mutual exclusion, containment, adjacency, and dialog control in terms of LOTOS operators. TERESA XML distinguishes output and interaction on the abstract level. Output interactors are: textual, object, description, and feedback;

interaction elements are: selection (single choice, multiple choice), editing (numerical edit, text edit, position edit, object edit), control (activator, navigator), and interactive description. Additionally, interactor composition can be dened based on the following relations: grouping, relation, ordering, hierarchy and a connection to the functional core is dened as part of the model. In both approaches, the abstract model is rened by concrete elements at design-time. The concrete elements of UsiXML are the most ne grained here.

Main dierences between the presented interaction models compared to UsiXML/TERESA are:

• The strong separation of abstract and concrete model to avoid redundancy, create clear boundaries and allow the incorporation of interaction means into adaptation and input interpretation at runtime. However, the creation of the models and the related mappings can become complex and requires comprehensive tool support.

The dierent mapping types allow dierent views to the mappings in terms of mutual activation, information exchange and dynamic element handling.

• The separation of input and output and the denition of mappings between abstract-concrete and abstract-concrete-abstract-concrete levels provide an extended exibility, and allow to establish two levels of interaction:

1. task related interaction, that inuences the application logic,

2. presentation related interaction, that only controls the presentation.

• The integration of the CARE properties as attribute of complex interactors allows to express the relations between interactors across modalities.

• The incorporation of information from the task model at runtime helps to determine

grouping and temporal relations, which do not have to be redened within the interaction models.

• Additional groups for output interactors can be created to allow a rendering specic grouping and the provisioning of group specic properties.

• The direct mapping between tasks and abstract interaction objects provides clear boundaries for the level of detail of the task model and allows to rene the task semantics as abstract interaction.

• Execution and interpretation semantics are part of the model, dened as execution elements. Embedding the execution semantic into the model allows to address the denition of the interactor behavior on the meta-level. The handling of the CARE properties and fusion e.g. can be supported by the execution logic of complex elements.

• The dynamic creation of interaction objects is supported based on templates that can be dened at design-time and a mechanism to handle these templates at run-time. Additionally, multiple variants of a user interface can be created.

The integration of the interaction model in a larger net of coexisting models at runtime instead of utilizing transient models at design-time also leads to a dierent utilization of mappings between the models. While a denition of dierent types of mappings between the models has also been provided by Limbourg et al. (2004a) in the context of UsiXML, the main dierence to the their approach lies in the extension of the mappings by the inclusion of backend service access and the extended separation of tasks and manipulated objects at runtime. Using the presented mappings, the manipulation of domain objects is directly dened through the interaction objects. However, the UsiXML mappings provide valuable insights which can be transferred to runtime aspects and have been incorporated into the presented mapping types.

In summary, the presented models and especially the interaction model address several of the requirements identied for the UIDL:

• a possibility to dene interaction, while not having to specify all details of the user interface to gain the needed exibility (requirement #1.1)

• the relation and separation of input and output (requirement #2.1, #2.2) and the related support for distribution and multimodality,

• support of fusion and ssion means by the provisioning of independent building blocks as well as the separation of input and output (requirement #2.4, #3.1),

• the dynamic utilization of data slots to store user input to support persistence (requirement #4.3),

• an explicit interaction state (requirement #4.1),

• dierent levels of abstraction (requirement #3.3) and their separation of modality and device independence and specics.

• the possibility to integrate backend services via a service model (requirement #5.3) Dierent types of mappings facilitate the synchronization of elements and their dynamic creation, and the overall approach is easily extensible if more interactors are needed.

Utilizing the interaction model at runtime is strongly based on support by the runtime architecture and the interconnection of the interaction model with additional models to reect the model state within the outside world (requirement #5.1). The next chapter illustrates the integration with a context model (requirement #1.2, #1.3, #2.5) as well as the means for input and output handling (requirement #2.3, #3.2), runtime distribution, shaping, multimodality, and adaptation (requirement #4.2).