Task List Algorithms

In addition to metamodels, algorithms play an important role to create and manage task lists. These algorithms can be used in the instances

of the methodology. Which algorithm is necessary in a specific change propagation analysis approach depends on the overall goal of the change propagation analysis and the usage context. For example, some algorithms are necessary to create deterministic task lists for the same input. Using these algorithms, the generated task lists are duplicate-free and sorted. The following sections describe these algorithms in more detail.

5.2.2.1. Algorithm for Derivation of Task Lists

This section proposes a basic algorithm to derive and manage the task lists (see Algorithm 1 in pseudo-code). This algorithm mainly calls fur-ther domain-independent and domain-specific algorithms and gafur-ther their results.

In the first phase, the algorithm calls the corresponding algorithms to cal-culate a base task list. To calculate a base task list, the propagation of changes in the model of system’s structure and behavior in a specific do-main has to be analyzed. Additionally, further activities have to be carried out based on differences between two versions of a system model: i) the base version representing the system’s structure and behavior before any change and ii) thetarget version representing the system’s structure and behavior after changes. Examples of these changes are deleting or adding model elements. The actual change propagation and the activities caused by the difference calculation (e.g., by refining existing generic algorithms for difference calculation) for the elements of different domains have to be implemented in each domain separately, as they require domain knowledge (i.e., domain-specificAlgorithm of Change Propagation Analysis and Algo-rithm of Difference Calculation in Figure 5.1). These algoAlgo-rithms are described in the follow-up chapters of this thesis for BP, aPS, and requirements in more detail. Thus, this phase of the algorithm gathers this information from different domain-specific algorithms.BaseTaskListin Algorithm 1 represents the result of this phase of the algorithm. This task list contains the initial changes and the structural model elements that are potentially affected by the initial changes.

In the next phase, the algorithm for derivation of task lists calls a further algorithm to eliminate the duplicates in the task list. Thealgorithm of

duplicate elimination is described in the following section in more detail (see Section 5.2.2.2).

During the implementation of change requests, it is not always sufficient to only analyze the change propagation in the system’s structure and behavior, as the change can also cause technical, management, or organizational efforts [Sta15]. In other words, the metamodel of the system’s structure and behavior may not be sufficient to estimate the total effort of a change request [Sta15]. The reason for this is that a change may affect elements that are not considered by the metamodel of the system’s structure and behavior (i.e., context elements) [Sta15; Ros+15b].

To consider the activities caused by context elements, the next phase of Algorithm 1 is a call to the corresponding algorithms to extend the tasks of the base task list to include the context elements. Similar to the first step of the algorithm, the instances of the methodology in each domain have to determine i) which context elements are affected by a change to structural elements and ii) how they change. The reason for this is that the effort resulted from changing context elements requires domain knowledge and cannot be generalized for all domains. These algorithms are also described in the follow-up chapters for BP and aPS. For example,component C may be affected by a change.Component C can be tested by test case T. In this phase, the taskchange component C is extended by further tasks such as adapt test T or execute test T [Sta15]. This example shows that annotating a task list regarding specific task types requires domain knowledge and has to be implemented in each domain separately (i.e.,Metamodel of Task Types and Algorithm of Context Task List in Figure 5.1). Thus, this phase of the algorithm gathers the extended task lists of the domains, in which the methodology is instantiated.

In the last phases, Algorithm 1 calls the corresponding algorithm to sort the task list. Thetask list sorter algorithm is described in Section 5.2.2.3 in more detail. The result of this phase of the algorithm is an annotated task list (i.e.,AnnotatedTaskListin Algorithm 1). The annotated task list contains the base task list and the corresponding context model elements affected by the change.

Algorithm 1 Algorithm for Derivation of Task Lists

Input: BaseVersion . The metamodel instances before changes Input: TargetVersion . The metamodel instances after changes BaseTaskList = ∅ . Task list containing the modified domain elements, as well as the added and removed domain elements

AnnotatedTaskList = ∅ . Base task list annotated with context elements if BaseV ersion , ∅ and TarдetVersion , ∅ then

BaseTaskList = Calculate base task list based on TarдetVersion and BaseV ersion

Remove duplicates f rom BaseTaskList

AnnotatedTaskList = Calculate annotated task list based on TarдetV ersion, BaseV ersion, and BaseTaskList

Sort AnnotatedTaskList end if

5.2.2.2. Duplicate Elimination Algorithm

It is possible that redundant tasks occur in a task list. In general, redun-dant tasks refer to the same model element and have the same task type.

However, other definitions of redundant tasks are also possible depending on usage context. For example, the tasks that refer to the same model element but have different task types can also be considered as redundant.

The redundant tasks are referred to hereinafter asduplicates. Duplicates can have several causes. In the following some causes for duplicates in a task list are discussed. In general, more than one seed modification can result in duplicates, as different change propagation rules for different seed modifications can cause duplicates in a task list. Further, duplicates can also occur in a task list for only one seed modification, as different concatenation of change propagation rules can result in duplicates. In addition, duplicates can occur in a task list due to several change propagation rules that have the same affected element. However, it is important to have duplicate-free task lists to better estimate the effort of a change request and to have comparable task lists [Ros+17a; HBK18].

The methodology provides an algorithm to eliminate duplicate tasks in a task list. The duplicate elimination is mainly based on merging the tasks, which refer to the same model element of the system’s structure

and behavior and have the same task type. The idea of this algorithm is described in the following.

LetA be a set of all tasks in the generated task list and let R be the set of the tasks that have been already considered by the algorithm. In other words, R is the result set comprising unique tasks, as these tasks have not been eliminated as duplicate by the algorithm (hereinafter also referred to as the set of duplicate-free tasks).

To eliminate the duplicates, each task in the task lista ∈ A has to be compared to all considered tasks (i.e.,R). In the next step, the subset of these tasks, which refer to the same model element of the system’s structure and behavior and has the same task type as the task under study (i.e.,a), has to be identified. If this subset is empty, the task under study has to be added to the set of duplicate-free tasks (i.e.,R). This algorithm can be recursively applied to all sub-tasks and/or follow-up tasks until the base case. In the base case, the algorithm merges two tasks, which refer to the same model element of the system’s structure and behavior and has the same task type. In other words, it removes one of two identical tasks. Each of both tasks can have (merged) sub-tasks and (merged) follow-up tasks.

However, the sub-tasks and follow-up tasks of both tasks may differ. In this case, the algorithm adds the sub-tasks and follow-up tasks of one of both tasks to the other task and remove the first task. In this way, it recursively merges the tasks, as well as the sub-tasks and the follow-up tasks.

Although the methodology provides an algorithm to merge duplicate tasks in a task list, there are already various algorithms to eliminate duplicates.

As the methodology is independent of a specific tool, technology, or pro-gramming language, domain experts can also use an existing algorithm to obtain a duplicate-free task list.

5.2.2.3. Task List Sorter Algorithm

In order to generate a deterministic task list for the same seed modifica-tions, the task lists have to be sorted after duplicate elimination. Thus, the methodology provides an algorithm, which can sort tasks together with their sub-tasks and follow-up tasks. Although the methodology provides a sorting algorithm, any sorting algorithm or its extension and modification

can be used. The only prerequisite is that the algorithms have to be able to sort tasks on the top level, the sub-tasks, and the follow-up tasks, if this hierarchy of tasks is used in a certain instance of the methodology.