Change Propagation Analysis for

This part of the methodology contains the obligatory metamodels and algorithms. It consists of two metamodels to describe the domain under study and the changes in the domain. The latter is referred to hereinafter as domain-specific metamodel of modification. In addition to both metamodels, the algorithm for analyzing the change propagation has to be specified in a specific domain. To instantiate the methodology in a new domain, these metamodels and algorithm have be defined or extended in this domain. The following sections discuss the metamodels and algorithm in more detail.

5.3.1.1. Metamodel of Domain

To analyze the change propagation, the domain under study has to be metamodeled. The metamodel of the domain has to represent the proper-ties that are relevant for the maintainability analysis. It involves aspects regarding the structure of systems in the domain, the data flow, and the behavior of these systems. The following aspects should be considered when metamodeling a new domain:

Structure The instances of the methodology aim at analyzing the change propagation in the structure of the systems in different domains. Thus, the structure of systems in a domain has to be metamodeled. For example, a system can consist of components and their composition in an architectural description language such as UML [RJB04] or PCM [BKR09; Reu16]. The granularity of this metamodel plays an important role in the precision of the change propagation analysis. The more fine-grained the system’s structure is metamodeled, the more precise the task lists can be generated. However, the granularity of the metamodel is not the only factor in the precision of the task lists. Other factors are, for example, the granularity of the system model and the change propagation rules. Domain experts usually create the metamodel of the system’s structure in a specific domain [HBK18].

Data Flow The change can propagate in a system due to the data flow. For example, a data dependency graph can be utilized to analyze the change propagation [LOA00]. The data flow can also be the cause of change propa-gation between two domains. The type of the data that has to be metamod-eled depends on the domain. For example, the data in IS can be represented by data type [BKR09], while the physical data objects in the real world can represent the data in BP [Ros+17a]. Signals can represent the data in aPS [Hei+18; Koc17]. However, different types of data can usually be converted or transferred to each other. Thus, the data flow can be used to analyze the propagation of changes in different domains [HBK18].

Behavior The behavior of a system can also be affected by a change. A change can directly affect the behavior of a system. At the same time, a change to a system can lead to changes in its behavior. In other words, a

change to the system’s structure can directly affect its behavior or indirectly due to the data flow. The importance of considering the behavior during the change propagation analysis is discussed by several works. For example, Chapin et al. describe in [Cha+01] that a change in an IS can have a high impact on the experience of its users and the corresponding BP [HBK18].

5.3.1.2. Domain-specific Metamodel of Modification

This metamodel extends the domain-independent metamodel of modifica-tion by domain-specific metaclasses. In other words, an instance of the methodology extends the metaclasses in Figure 5.2, as described in the following:

• Modification: In a specific domain, this metaclass has to be extended by other metaclasses. Each metaclass references the corresponding metaclass of the metamodel of the domain, which can be potentially affected by a change.

• ChangePropagationStep: The concrete change propagation steps in a specific domain group the specific metaclasses extending the

Modificationmetaclass with the same cause. For example, a change propagation step could be due to the data

dependency [Sta15; Ros+15b].

• SeedModification: A subset of all metaclasses that can be

potentially changed in a specific domain (i.e., the extensions of the

Modificationmetaclass) can be initially affected by a change in this domain. In other words, instances of only these metaclasses can be marked as changed by domain experts.SeedModificationhas to be extended to include these metaclasses in a specific domain.

• ModificationRepository: In order to be able to create task lists in a new domain, aModificationRepositorymetaclass in this domain has to be defined, which extends theModificationRepository

metaclass of the methodology.

5.3.1.3. Algorithm of Change Propagation Analysis

As described previously, the change propagation algorithms can be com-posed of a set of change propagation rules. Such an algorithm can work iteratively. In other words, the change propagation rules are iteratively applied to the newly affected model elements, until there are no newly affected elements. The change propagation rules are based on the elements of the metamodel of the domain under study and the domain-specific meta-model of modification [HBK18]. Thus, the change propagation rules depend highly on the domain under study and have to be specified by domain ex-perts [Bus+18b]. The change propagation rules can be either in a GPL such as Java or in a DSL, which is tailored to this problem [Bus+18b; HBK18].

To support domain experts by specifying change propagation rules, a DSL was developed, which is described in Chapter 9.

5.3.2. Change Propagation Analysis for Elements of Context Metamodel

As described previously, the context elements can also be affected by a change request. These elements are domain-specific and can be associated to the elements of the metamodel of the domain under study. Thus, the modification of a domain element can cause the modification of the cor-responding context elements. For example, if a component is changed in IS, the corresponding test cases can also be affected [Sta15; Ros+15b]. A change can also involve different roles (e.g., the software architect role in IS [Ros+15b] or the system engineer role in aPS [Hei+18]), as implementing a change requires the coordination of the tasks of different roles [Sta15].

Therefore, if information regarding context elements is available in the domain under study, it should be considered in the change propagation analysis.

Context elements need not necessarily be used in all usage context of the methodology. An example of this is an early phase of the development, in which no concrete system exists. Consequently, the context elements cannot be modeled. Sometimes, considering the domain elements can be sufficient in the change propagation analysis. This depends on the overall goal of these approaches. For example, if domain experts are interested in

a rough estimation of the change propagation, context elements need not necessarily be modeled. Another reason for considering these elements as optional is the development effort of a methodology instance. Omitting these elements during the development lowers the development costs. Thus, this part of the methodology can be considered as optional [HBK18].

The following sections describe the metamodels and algorithms for instan-tiating the methodology for the context elements.

5.3.2.1. Metamodel of Context Elements

As described at the beginning of this chapter, organizational and technical artifacts, also called context elements, play an important role in the change effort estimation, as they cause additional effort during the change imple-mentation [Sta15]. These model elements are not parts of the metamodel of the domain, as the metamodel of the domain mainly represents the systems in this domain and their connection to their environment. This metamodel contains the context model elements in a certain domain, which are rele-vant for the maintainability analysis. For example, it may be important to calibrate a plant in aPS, if changes to a component or a module of it are made [Vog+17; Hei+18]. In this example, the calibration information can represent a context element. Further, the context elements can also be the elements that are involved in the change propagation analysis. For exam-ple, if activities in BP are changed, knowing the affected organizational units may help plan the implementation of the changes [Ros+17a]. As the metamodel of the domain can be considered as the main artifact in the change propagation analysis, the elements of the context metamodel have to reference the elements of the domain metamodel. This allows identifying the corresponding elements of the context metamodel while analyzing the change propagation in the elements of the domain metamodel.

5.3.2.2. Metamodel of Task Type

As described previously, a task in a task list can have a task type representing how to change the affected elements in a specific domain. Thus, task types depend on a specific domain, such as writing or executing tests. This metamodel consists of the task types in a specific domain [Sta15; HBK18]. As

task types show different changes of the elements of the domain or context metamodel, the metamodel of task types has to reference the corresponding elements of the domain or context metamodels. As it is sometimes sufficient to know if an element of the domain or context metamodel is changed regardless of the type of the change, this metamodel can be considered as optional [HBK18].

5.3.2.3. Algorithm of Context Task List

This algorithm identifies the affected context elements and can implement how the context elements are involved during a change to the domain elements. Additionally, this algorithm can also consider the specific task types. For example, if a component is changed, its test cases may need to be adapted and re-executed. By contrast, if the component is removed, its tests cases have to be removed [Ros+15b; HBK18]. Thus, domain knowledge is required to implement the algorithm of context task list. Further, as the metamodel of context elements is optional, the algorithm of context task list has to be considered as optional.