LA RELACIÓN COBERTURA VS DIVERSIDAD

This section introduces task models as means to model feature interactions using a system model that is based on action traces. Actions are basic activities in a system such as opening a popup screen or pressing a button. Actions are thought to be atomic and instantaneous [BDD+_{92]. Based on a possibly}

innite set of actions Act, the set of streams of actions, is denoted by: Actω= Act∗∪ Act∞

where Act∗_{denotes the nite streams (including the empty stream) and Act}∞

the innite ones [BKM07, BS01]. We will use the following basic operations and relations concerning streams (following Broy et al. [BDD+_92]):

ˆ s ◦ t denotes the concatenation of t to the end of s. If s is innite, then s ◦ tjust yields s.

ˆ s t t denotes that s is an inx of t which is formally expressed by ∃u, w. u ◦ s ◦ w = t

One run of a system is a trace which is a stream of actions. The behavior of a system S can be specied by all possible system traces:

S ⊆ Actω

Each trace s ∈ S is a potential test case. The actions that are performed by the environment are test inputs and the actions that are performed by the system are test outputs. In an ideal world, every possible trace s ∈ S would be covered during testing. However, due to the potentially innite behavior of a system, this is not feasible. Hence, testing should focus on the traces that are most likely to exhibit faults in the system. The previous chapter introduced the results of a study showing that feature interaction scenarios are often error prone. Our goal is to systematically cover these scenarios by test case generation. Hence, we want to select and test traces s ∈ S that involve a feature interaction and therefore are likely to exhibit faults.

In order to obtain all traces that involve a feature interaction, feature inter- actions must be dened explicitly. Our approach is to describe features and their interactions in the form of a task model. A task model describes tasks and their temporal dependencies. A task is a goal driven interaction between system and environment, where a goal is a desired modication of the state of a system or a query to it [PMM97]. We dene a task by a nite sequence of one or more actions:

t = ha1, ..., ami : ai∈ Act∗

For example, the task Start CD Playback has the goal to start the playback of a CD, which is dened by the action sequence: Press Play Button, Start Track 1. However, the notion of a task is always bound to a certain abstraction level. For example, the task Start CD Playback involves the action Press Play Button. On a lower abstraction level, this action itself might be declared a task, namely the task Press Button. As a consequence, a task model itself is always bound to a certain abstraction level.

A task t is performed in a trace s ∈ S i: t t s

Therefore, a task model T models the behavior of a system S i: ∀t ∈ T. ∃s ∈ S. t t s

4.1 Task Models as Means to model Feature Interactions 29 We can separate a system trace s ∈ S that involves the execution of a task t into three sub streams s0, s1, t:

s = s0◦ t ◦ s1

The trace s0 comprises all actions that are performed before the task t is

performed. These actions may involve the execution of other tasks or addi- tional interactions that are necessary to reach the goal. For example, in order to perform the task Start CD Playback, the user must rst navigate to the play button. The necessary navigation steps depend on the previously exe- cuted tasks, for example, whether the user previously made a telephone call or listened to the radio. Therefore we can separate s0 into two parts:

s0= h ◦ p

Where h comprises the history of previously executed tasks and p comprises the actions that were necessary to prepare the system for the next task t. This dierentiation corresponds to the situation during testing, when the tester wants to test sequences of task execution. For example, in the rst part of a test the task Select Radio Station is tested and in the second part the task Start CD Playback is tested. Therefore, in order to test the task Start CD Playback, the tester must prepare the system by navigating to the Play CD Button from the radio menu which is the postcondition of the previously executed task.

Our goal is to model feature interactions. Therefore, we use a task model to model each feature by the tasks that can be accomplished using the feature. For example, the feature Incoming Call is modeled by the task Handle Incom- ing Call. Furthermore, a task model provides means to dene the temporal dependencies between tasks. An example for such a temporal dependency is, when the execution of a task disables the execution of another task. The basic idea is to use these dependencies to model feature interactions.

For example, given a simple task model T that comprises of three tasks a, b, c ∈ T. The task a has a disable dependency to the task b

disable(a, b)

and the task c has an enable dependency to the task b enable(c, b)

The temporal dependency disable between the tasks a and b denes that there is no trace in which the tasks a and b are performed sequentially, as long as the task c is not performed:

∀s. ∃s0, s1, s2. (s = s0◦ a ◦ s1◦ b ◦ s2) ⇒ c t s1

A feature might provide dierent interaction scenarios. For example, the interaction between environment and system of the feature Incoming Call varies depending on whether the user decides to accept or reject the incoming call. Figure 4.1 shows a sequence diagram for the Incoming Call that describes the Incoming Call feature. To model features with dierent interaction scenarios, a task can be decomposed into subtasks that describe corresponding sub goals. For example, the feature in Figure 4.1 is described by the task Handle Incoming Call. The dierent interaction scenarios of Incoming Call Handling are described by the four subtasks of Handle Incoming Call and their dependencies:

alt Signal Call Accept Call Reject Call [accept] [reject] Hang Up User System

Fig. 4.1. Incoming Call feature.

1. Signal Call: which is performed by the system by showing the incoming call popup and by giving an audio signal.

2. Accept Call: which is performed by the user by selecting and activating the accept call button.

3. Hang Up: which is performed by the user by selecting and activating the end call button.

4. Reject Call: which is performed by the user by selecting and activating the reject call button.

Handle Incoming Call

Signal Call Accept Call Reject Call Hang Up enable enable enable disable CD Playback … suspend

Fig. 4.2. The tasks for the feature Incoming Call.

Figure 4.2 shows a complete task model for the features Incoming Call and CD Player. The task model uses enable and disable dependencies to describe whether the execution of a task enables or disables the execution of another task respectively. Thus, when Signal Call has been executed, the tasks Accept Call and Reject Call are enabled. When one of these two tasks is performed, the other one is disabled. Thus the task model species that the task Handle Incoming Call is performed in all traces s = s0◦ s1◦ s2∈ T that hold:

'Incoming Call' t s ⇔ 'Signal Call' t s0∧

('Accept Call' t s1∧'Hang Up' t s2) ∨ ('Reject Call' t (s1◦ s2))

A composite task is performed by executing its subtasks. The temporal depen- dencies between the subtasks dene their valid execution orders. Figure 4.2

4.1 Task Models as Means to model Feature Interactions 31 also shows a dependency called suspend between the tasks Handle Incoming Call and CD Playback. This dependency models an intended feature interac- tion between the features that are represented by these two tasks, namely that the CD playback is suspended when an incoming call is handled. The traces that are specied by this dependency are the ones we want to test in order to cover intentional feature interactions.

Furthermore, the execution of tasks can be interleaved with the execution of other, independent, tasks. For example, in a trace s = s0◦ s1◦ s2 the task

'Move Seat' might be performed between the tasks Signal Incoming Call and Reject Call:

'Signal Call' t s0∧'Move Seat' t s1∧'Reject Call' t s2

The interleaved execution of tasks is potentially error prone because it might result in unintentional feature interferences. Thus scenarios where an unin- tentional feature interference might occur can be derived from a task model by nding tasks that have no temporal dependencies1_{. The basic assumption}

is that in a system all features might have potential unintentional feature in- teractions. In the context of AIS this is mostly true because most features use the same resources, such as communication devices.

So far, we have seen that task models explicitly model intentional feature inter- action scenarios and thereby implicitly model potential unintentional feature interaction scenarios. Test cases that involve feature interaction are traces that execute a number of features. But not all valid system traces involve fea- ture interactions. We use task models to express at an appropriate abstraction level:

ˆ how tasks are composed of subtasks and

ˆ how the executions of tasks constrain each other.

In the previous section 3.2 we gave an overview on reasons for feature inter- ferences. In the following, we discuss how these issues can be addressed using test case generation based on task models.

ˆ Conicting goals: are feature interferences in which features with the same preconditions but incompatible goals are in conict. Task models explicitly dene feature interactions. During the creation of the task model, one must think about potential interactions between dierent features. Hence, chances are high that one identies conicting goals during the creation of the task model. If this is not the case, conicting goals still can be identied during testing, when tests are generated that cover unintentional feature interaction scenarios. These scenarios might reveal faults in the system resulting from the conicting goals.

ˆ Competition for resources: Scenarios in which multiple tasks are active at the same time often lead to resource conicts. These scenarios are explic- itly described in a task model. Hence, test cases can be generated that 1 _{At least no such temporal dependency is included in the model, because uninten-}

cover these scenarios. However, task models do not specify resource or data dependencies. Thus it is not possible to incorporate such information during test generation. Resource and data dependencies are added during test case instantiation, which is explained in the following chapters in more detail. It is reasonable to execute the same test case multiple times with dierent resource congurations.

ˆ Changing assumptions on features: often result from new features that are added. Describing features in a task model and generating tests from the model enables the systematic and continuous test of features and their interactions. Hence, faults that result from changing boundary conditions are likely to be identied.

ˆ Design evolution: When new features are introduced to a system, a task model is a means to dene the dependencies to existing features. Further- more, when a new feature is introduced, it is possible to systematically select scenarios that test the interaction or the non-existence of an inter- action between the new feature and the existing ones.

ˆ Timing and race conditions: Task models dene no timing. Thus it is not possible to generate test cases that cover timing critical scenarios. How- ever, scenarios in which multiple tasks interfere are often timing critical. The latter can be covered by test case generation from task models. Never- theless, it is important to include timing during the test case instantiation, for example, by performing the same test case multiple times with dierent timings.

To conclude, the main advantage of task models is that they describe features and their dependencies in a concise and explicit way. Thus task models en- able the systematic coverage of critical feature interaction scenarios by test case generation. This section gave an introduction into task models based on traces and showed how task models can be used to model feature interactions. In the next section we present related work in the eld of task and feature modeling. Then we introduce our task modeling language TTask and dene the semantics of task hierarchies and task dependencies in more detail.