Creating Tasks from Use Cases

In this case study we model the software update functionality of an info- tainment system with TTask. This functionality allows the user to perform a software update of the infotainment system. The OEM provides software updates, which the user can save on a USB ash drive. After the user has con- nected the USB ash drive to the infotainment system, the update starts via

the GUI. Furthermore, the functionality provides features to view installed updates and to uninstall previously installed updates. The functionality is specied in the form of use cases. Our approach is to systematically translate these use cases into a TTask model. The translation is performed in six steps:

1. Create a task for each use case.

2. For each step in the informal use case description, create a subtask in the corresponding task.

3. Model the temporal dependencies between the use case specic subtasks based on the use case description.

4. For each exception that is described in a use case, create a corresponding subtask. For each expected system reaction to the exception, create a subtask as well.

5. Model the dependencies between the tasks that describe the use case be- havior and the tasks that describe the exceptional behavior.

6. Compose all use case specic tasks by modeling their temporal dependen- cies.

In the remainder of this section we introduce the use cases of the software update functionality and model them in TTask. In the following section we describe the composition of the use case specic tasks into a complete TTask model.

8.1.1 Use Case: Software Update Detection

The rst use case in Table 8.1 describes the detection process of a USB stick. Figure 8.1 shows the corresponding task Detect USB Flash Drive. This is a composite task that implements the selection pattern with three subtasks. Each subtask describes a dierent USB ash drive detection scenario:

1. The USB ash drive contains no update data.

Use case: Detection of software updates on USB ash drive

Description: The customer connects the USB ash drive to the USB port in the car. The storage device contains an update le. The software update agent detects the update le. All detected updates are reported to the Software Update Manager and are forwarded to the GUI.

Prior Condition: USB ash drive with appropriate update le is connected to the USB connector.

Post Condition: The system has detected updates on the USB ash drive.

Initiator: User

Exceptions: The system should notify the user if the USB ash drive contains an invalid update.

8.1 Creating Tasks from Use Cases 117 2. The USB ash drive contains invalid update data.

3. The USB ash drive contains valid update data.

Fig. 8.1. Update detection task.

The subtasks have no temporal dependencies. Thus the task Detect USB Flash Drive is performed when one of its subtasks is performed. The second scenario is an example, how faulty inputs can be described in TTask by being encap- sulated in separate tasks. This demonstrates how scenarios that involve faulty environment inputs can be covered in task-based test case generation.

8.1.2 Use Case: Display Installed Updates

The user can review previously installed updates. This part of the software update functionality describes the second use case in Table 8.2. Figure 8.2 shows the task Show Installed Updates which describes the use case. There is no exceptional behavior in this use case described. Thus the corresponding task has only two subtasks that model the sequential execution of the use case. This is a typical example for a GUI dialog, in which the user queries information from the system. The user performs the rst task by requesting a list of previously installed updates from the system via the GUI. The second task describes the corresponding system reaction.

Use case: Display currently installed updates and versions via GUI Description:

The customer or the service partner determines installed up- dates using the GUI.

1. The customer/service partner selects the option display in- stalled updates.

2. The currently installed software updates are displayed. Prior Condition: The system is idle.

Post Condition: The system is idle.

Initiator: User

Exceptions:

Fig. 8.2. Display updates task. 8.1.3 Use Case: Software Update Removal

If the user is not satised by the previously installed update, it can be removed from the system. The third use case in Table 8.3 describes the uninstallation procedure which removes the last installed software update. The use case is modeled by the task in Figure 8.3. This use case also describes a sequential dialog between user and system. The system noties the user over the uninstal- lation progress, which is modeled by the long running task Show Uninstallation Progress.

Use case: Uninstallation of the software update Description:

The last software update that has been installed is uninstalled by the customer using the update assistant.

1. The customer selects the software update uninstall function. 2. The customer is informed about the uninstall progress. 3. Visible conrmation of successful uninstall is given. Prior Condition: There are installed updates.

Post Condition:

Initiator: User

Exceptions:

Table 8.3. Use case: Uninstall software updates.

8.2 Composing the Use Case Tasks 119