Connecting the Models

text). This way multiple variants of the user interface can be created and the most appropriate variant is selected at runtime.

While the rst case is addressed by the list interactor itself, which takes care of the cre-ation of the items to display, the second case is handled by the provisioning of templates within the DynamicInput and DynamicOutput interactors. The actors handle the cre-ation of interaction elements and take care of their presentcre-ation or input processing. In the third case the dynamic interactors allow the denition of dierent variants, that can be activated according to other model information. Variants and template utilization are handled via mappings to the execution elements and the activated elements are stored as situation (child-) elements. Storing these elements as situation elements is crucial for the approach, as they are created at runtime, according to the model processing logic and are not provided by the designer.

Based on these cases and requirements for the mappings between interactors, a set of mapping types expressing the described means can be identied as described in the next section.

models have already been described in section 5.4, additional mappings between task-, domain-, service- and interaction-model are discussed in this section. Figure 5.10 shows the created net, connecting the core models to handle the interaction state.

Figure 5.10.: Interconnection of and mappings between the involved Models.

Starting with the task model, the graphic illustrates that based on the workow, dened in the task model, service calls or abstract interaction elements are (de-)activated. Map-pings between the task- and domain model facilitate the specication of a life cycle and object management for the stored domain objects and allow the creation of objects if needed as well as the garbage collection of objects not needed any further. The service model utilizes information from the task and the domain model, to make service calls.

Thus whenever an application task becomes active, the corresponding service call is ac-tivated as well. Mappings between service calls and domain objects take care about the passing of parameters to the service and the update of the domain object with the result of the service call. On the other hand the abstract interaction model is also related to task and domain model. In a similar way, as the activation of an application task activates a service call, the activation of an interaction task activates the corresponding interaction elements. The interaction elements are also related to domain objects, pro-viding the dynamic information to visualize through the interaction objects as well as the information to alter through the actual user interaction. The abstract interaction model is related to more concrete representations of the interaction, separated into input and output.

Using this general structure a set of dierent types of mappings can be distinguished.

Based on the mapping metamodel, all types relate denition elements of two dierent models and contain a set of links that detail the relationship. The mapping types are listed in table 5.7.

Mapping Type Description

IsPerformedBy Relates an application task to a service call or an interaction task to an interaction object. The mapping activates the corresponding service call or interaction element whenever the related task becomes active and also changes the task state to done, when the service call nishes or the

interaction is complete.

Uses Denotes the domain objects involved in an interaction or service call. In case of a service call the object can be a parameter or a service result, in case of a user interaction the object can be presented to the user or manipulated / created by the user.

IsStateSynchronized Relates two interaction objects and synchronizes their state.

This means that if one element becomes active, the other does as well. The relation is either direct or with a

translation function redening the dependency of the states.

State synchronization from abstract to concrete or concrete to concrete elements e.g. guarantees that all related

concrete elements are activated whenever an abstract interaction element becomes active and that related concrete elements are activated simultaneously.

IsValueSynchronized Addresses the need to transport additional information between the dierent elements and across dierent levels of abstraction. It allows to communicate user input to higher levels of abstraction and to congure concrete interaction elements according to information from other elements. For the communication of input e.g. each concrete input

element provides a value attribute (situation element) that can be changed during the interaction.

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.