To specify the data flow and advanced workflows, we adopt the Task Ori- ented Object Design [51] in the dynamic task model, to specify tasks as objects with an input and output transition. A dynamic task model defines data flows, system state checks, and events that trigger tasks.
4.5.1
Task object
In the dynamic task model we define a task as an object which consists of an input and output interface, and a body. The input interface defines the required input data necessary for the execution of the task. This data is con- sidered as the initial condition to be able to execute the task. Three types of input conditions are defined: events, preconditions and input data. The body describes the subtasks and the data flow between subtasks and from the task to the subtasks. The output interface specifies the data that is cre- ated, the postconditions that must be met and which reactions are trig- gered.
Figure 4.6: Task object with the elements of the input and output interface
Input interface
• TriggersTo trigger the execution of a task, an event within the set of triggers should be raised either as a result of the previous tasks, or by the system. We define two types of events: internal events and external events. Internal events are produced by other tasks in the task model and are used to trigger the other tasks in the workflow. External events can be set off by the system as a result of an asyn- chronous call or to interrupt the current workflow such that the user should perform a task with a higher priority.
• Input dataspecifies the incoming data from another task to perform the task.
• Preconditionscan be defined to constrain the valid input data to start the execution of the task.
Output interface
• Reactionscan be produced by the user during the task and can be used asEventsas input for other tasks.
• Output dataspecifies the data that is produced or transformed dur- ing the performance of the task and can be used by other tasks. By defining input/output sequences we can define a data flow from one task to another.
• Postconditionsdefine the constraints of the values of the output data.
4.5.2
Event-Driven Tasks
Temporal constructors are capable of defining relationships between tasks. This defines the basic workflows that a user interface should support. Whereas these constructors are powerful, the specified behaviour is not completely deterministic. It does not specify what happens when tasks become obso- lete, when users want to abort a task or go back to the previous task. In all cases, the user should be able to abort the task, and the user interface should return to a state that is relevant to the user. Since the Task Ob- ject Oriented Design defines the tasks as event-driven, tasks are triggered by the corresponding events. Tasks defined in the structural model can be transformed to event-driven tasks as defined in Figure 4.7. Comple- mentary to the derived tasks, dedicated events can be defined that can be raised by the user to go back to the previous task or to abort the task.
4.5.3
Input/output mapping interaction classes
Since every interaction task is annotated with an interaction class, this an- notation specifies the type of input and output data. For example, a task which is annotated with theselectinteraction class, should receive alistas input and anitemof that list as output. In the dynamic model we spec- ify the constraints on the input and output of a task. For user interaction the input/output pattern is used in the transformation to select a construct element that is able to receive and provide the data. For the system in- teraction, the input/output pattern is used to generate the specification of the interface. We define the input/output pattern resulted from an interac- tion class as functions. We define the constraints on the input and output pattern in of both the user interaction classes and the system interaction classes in Listing 8 and the syntax is introduced in Listing 9.
By defining tasks with input/output mappings, user interaction is abstracted from modality and platform. The interaction specification does not de- fine how actors should carry out their tasks but defines the relationship between the input and output. In the transformation chain, model trans-
T1 r1
t t1 T2 r
(a) SequenceEnabling / SequenceEnablingInfo
T1 r t1 T2 r t2 T0 r1 t r2 (b) Choice T1 r1 t1 T2 r1 t2 T0 r1 t (c) Interleaving T1 r1 t1 T2 r1 t2 T0 r1 t t2 disable r t (d) Disabling T2 r1 t2 T0 r1 t r2 T1 r1 t1 t2 resume suspend (e) SuspendResume T1 r t1 T2 r t2 T0 r1 t r2 r3 t r (f) OrderIndependence Figure 4.7: Temporal constructors expressed in event-driven tasks
{i:Set<Item>}Select{o:Item of i}
{i:Set<Item>}MultipleSelect{o:Set<Item> subset of i} {i:−}Generate{o:Value}
{i:Value}Manipulate{o:Value} {i:Value}Observe{o:−}
{t:Type,id:ID}GetObject{o:Objecto f typet} {t:Type,f ilters:Set<KeyValue>}GetObjects{o:Set<Object>}
{i:Set<KeyValue>,id:ID}InvokeCommand{o:Value}
Listing 8: User Interaction classes projected as functions
formations use this specification to derive the corresponding construct el- ements and create data bindings to retrieve and store the corresponding data. In the dynamic model, this input and output interface specification allows the validation to enforce that the specified interaction can be carried out due to the availability of input data.
{I}C{O}
I =Input Constraints C=Name of interaction class O=Output Constraints
DomainModelTypes=Set of types of Domain Models Type=member of DomainModelTypes
ID=Identi f ier
ValueSet={String,Integer,Double}
Value=member of ValueSet
Object=instance of a Domain Model object KeyValue=Key/Value mapping
Set<Item>=Set of items of type Item