The boilerplate approach enables the generation of dedicated task models for transitions in a domain object. Since a task model for a single transition does not comprise the complete definition of tasks to be supported by an application, we defined an modular approach to compose a complete de- scription of a task model for an application. In our approach we compose a complete task model by composing the task models we generated from the boilerplate approach.
7.3.1
Proxy Model
This modular approach defines a task model composed of proxy models. A proxy model contains a reference to an external task model. Whereas aTaskDModelis defined as a subtype ofTask, each task model is also de- fined as an input/output interface. If a proxy task model is self-contained, we can use that model in the composition of a parent task model. A self- contained task model defines all required information to complete the task model either as system and user interaction or as input constraints and does not trigger tasks outside of the task model. Whereas the proxy model defines an input and output interface, the adopting task model (the parent) should comply with the input constraints of the proxy model. When the parent complies with the input constraints, and the proxy is self-contained, the output of the proxy task model can be used in the parent task model. The advantage of this approach is threefold. First, when a transition changes, we can anticipate on that change by either generating a new version of that task model or changing the specific task model by hand. Secondly, proxy models can be nested. An example of a use-case of nesting task models is when in the middle of a task, the user has to select an object that does not exist yet. We could just abort the task and require the user to navigate to the creation task, but referring to the proxy task model that allows the
user to create such an object without forcing the user to abort his possibly long running process. In this way, we can nest proxy models to improve the usability of the user interface. Thirdly, we can define task models for specific users. By defining the capabilities in terms of transitions, we can define a task model for a specific user. This complies with theCorrectness by Constructionapproach by avoiding repetition as we defined in Section 3.3.
7.3.2
Application Configuration Model
In the conceptual model, users are described as an entity with a set of capa- bilities. A capability refers to a specific transition of a domain object. This user model can be used to compose a task model by using the derived task models of each transition in the set of capabilities. A task model is com- posed by defining a parent task model and an application configuration definition. For each transition in the set of capabilities, proxy task models are derived, which will be stored in separate models. The parent model de- fines the main structure of the application. The application configuration specifies the set of users, the parent model and a node in the parent model to insert the proxy task models. For each user, a task model is composed and forms the input for the transformation chain. The metamodel of the application configuration model is depicted in Figure 7.1 which includes the user model as well.
7.3.3
Transformation Definition
To compose a task model based on an application configuration model, we define two transformations. The structure of the first transformation is depicted in Figure 7.2. The input of this transformation is an instance of a application configuration model and an instance of the domain ob- jects. As we have discussed in Section 7.1, we can generate task models for each transition based on the specification of a domain object. This trans- formation uses the set of capabilities of each user to generate separate task models.
Domain Object Specification
T0-1
Domain Object Transition to proxy task model T0-1
Proxy Task Model User Model Muser
Proxy Task ModelProxy Task Model
Figure 7.2: Input and output models of the first part of the transformation T0
The second transformation uses the composition of the parent task model and the proxy models to create a task model for each user in the application configuration model.
Proxy Task ModelProxy Task Model Proxy Task Model
Parent Task Model T0-2
Taskmodel to AUI M2M transformation definition T1' Taskmodel Mt composes Application Configuration Model
Figure 7.3: Input and output models of the second part of the transforma- tion T0
7.4
Limitations & Constraints
• The discussed approaches to derive a task model from a behavioural domain model are straightforward; a task is defined for each argu- ment. Since this enables the user to enter a value for each argument, this can become tedious and is not user-friendly; the user has to go through every single step. More advanced transformations can de- tects groups of arguments and create logically grouped tasks.
• The current transformation defines a task for each argument. How- ever, not every argument maybe mandatory for the transition to be triggered. In that case, either the arguments should be annotated as mandatory, or the user should configure the transformation to spec- ify which arguments should be converted to a task.
• Since task models can be reused by different users with different user roles, the definition of these task models should take this into ac- count. If users have different roles, executing a task may involve different queries and different steps to achieve the same goal.
7.5
Conclusion
In this section two approaches have been discussed to leverage behavioural domain models to integrate the behaviour of the domain models in the user interface. A transformation is defined to generate task models from behavioural domain models. This transformation generates tasks and in- teraction classes for each argument of the transition. Whereas the transfor- mation is straightforward, the order of the tasks to be executed may not be considered as user-friendly. For this reason, more advanced transforma- tions have to be defined. To anticipate on changes in the domain model we have discussed an approach that generates separate models dedicated to specific transitions. When a transition changes, only that specific tran- sition has to be altered, and not the complete task model. In addition, an application with different users can be modelled and used as input for the generation of different task models for different users for the same appli- cation.
Chapter 8
Enforcing Correctness
In this chapter we discuss methods to enforce the correctness of our transformation chain results. We discuss methods we have used and that can be used to further verify correctness.