Generic Methodology for Domain-

Propagation Analysis

This section proposes the generic methodology for the domain-spanning change propagation analysis. The methodology was developed as a generic guideline for model-based approaches to change propagation analysis. It aims at improving the development process by providing generic (i.e., domain-independent) metamodels and algorithms for all change propa-gation analysis approaches, as well as guidelines for the development of a change propagation analysis approach in a specific domain in terms of modular metamodels and algorithms. As the methodology is defined inde-pendently of a specific domain and can be instantiated in different domains, it can be considered as generic. Initially, the methodology was mainly de-veloped as a generalization of two change propagation analysis approaches in the domain of IS [Sta15; Ros+15b; Ros+17b] and BP [Ros+17a]. However, it is mainly based on the change propagation analysis approach in IS [Sta15;

Ros+15b]. The generic methodology can be instantiated in a new domain to develop a change propagation analysis approach in the domain under study. In this thesis, the resulting change propagation analysis approach is also referred to hereinafter as aninstance of the methodology. The resulting change propagation analysis approaches are mainly based on thesystem’s structure, also known as system’s architecture, reflecting system’ elements and their relationships [Con68]. Using the structure of a system as the main artifact is due to the fact that “a system’s architecture is the set of principal design decisions made during its development and any subsequent evolu-tion” [MT10, p. 1]. Additionally, different quality attributes of a system such as maintainability or performance are affected by its structure [Ros+15b;

Sta15; TMD09].

The input of the resulting change propagation analysis approach (i.e., the instance of the methodology) is the model of the systems in the domain

and a set of change requests referring to the changing elements in a system model. The initial change requests are referred to hereinafter asseed mod-ifications [HBK18]. A seed modification in an instance refers to a model element representing an affected system element [Sta15]. Model elements representing the elements of a system structure are calledstructural ele-ments in the following. The instances of the methodology use a change propagation algorithm to analyze the change propagation in the system model based on the input and to calculate the output. The output of an instance is a list of potential maintainability tasks to implement the seed modifications. The output is called hereinafter astask list [HBK18; Sta15].

Each task in the task list refers to an element of the system model that is potentially affected by the seed modifications. Further, each task has a task type, which defines how to change the specific model element [HBK18;

Sta15]. An example of a task can bedelete interface I. While interface I represents the affected element,delete represents the task type [HBK18;

Sta15]. A task in a task list can also havesub-tasks. In this example, a sub-task could bemodify the corresponding signatures [HBK18; Sta15].

As the development process of a system involves not only the structure of the system or the connection to its environment, but also different organizational and technical artifacts (e.g., test cases or documentation), the maintainability analysis has also to consider these artifacts [Ros+15b;

Sta15]. Model elements corresponding to the organizational and technical artifacts are referred to hereinafter ascontext elements [Ros+15b; Sta15].

These elements are not part of the system model. Considering context elements in addition to elements regarding the structure and the behavior of a system in the domain under study during the maintainability analysis is also motivated by the Conway’s law [Con68]. According to this law,

“organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations” [Con68, p. 4]. Thus, each task can also havefollow-up tasks, which reference the context elements. In the previous example, a follow-up task could beupdate test cases [HBK18; Sta15]. In this way, the task lists are mainly derived based on the elements of the system’s structure and behavior. Additionally, the corresponding context elements can also be considered for each task. This allows a more comprehensive effort estimation with a holistic view on the system under study, the project and the organization, as well as the involving roles and the responsible

staff (see [Ros+15b; Sta15] for IS). While this chapter gives an overview of the methodology, concrete instances of the methodology, as well as the corresponding metamodels and change propagation algorithms to derive the task lists in different domains are described in the following chapters.

In general, the methodology can be instantiated to the systems with the following characteristics regarding their structure and behavior, as well as the propagation of changes in these systems:

• Systems’ structure: As described previously, the systems in a specific domain can be specified as a set of structural elements that can be connected to each other [HBK18]. Examples of these are systems that are composed of components and their interfaces.

Components and interfaces in this example represent general components and interfaces. Examples of components can be software components or components in the domain of aPS [HBK18].

In this context, the interfaces can be provided or required by software components [Reu16]. Further, the interfaces can present physical interfaces for the fixation of mechanical components or the communication interfaces of the electrical components [Hei+18]. To instantiate the methodology in a domain, the systems’ structure in this domain has to be defined by a metamodel. The methodology does not depend on a certain type of metamodel. Thus, it can be used for any metamodel with the aforementioned properties.

• Systems’ behavior: Conway demands a further characteristic for a system description: “A description of a system . . . must describe the system’s connections to the outside world” [Con68, p. 2]. This is particularly important to analyze the impact of a change in a system on its outside world. For example, changing a software system may lead to changes in its provided services. This affects the interaction between the software and its users [Cha+01]. This can be

considered as changes in the behavior of the software. In general, a change may only affect the behavior of a system. Further, a change to the structure of a system may affect its behavior (i.e., regarding its connection to its environment as proposed by Conway [Con68]).

To analyze the change propagation in the behavior of a system, its behavior has to be described as activities that are connected to each other. Similar to the system’s structure, the activities are also generally defined. For example, the activities can be performed by a

human actor [Hei+17] or a system such as a software, an

electrical/electronic, or a mechanical system [HBK18]. To represent the behavior in a domain, metamodels with the previously

described characteristics have to be defined. The methodology can be instantiated to analyze the impact of a change on the behavior regardless of the type of the metamodels.

• Rule-based change propagation analysis: The instances of the methodology need to implement a change propagation algorithm to analyze the change propagation. In general, the change propagation algorithm can be composed of a set ofchange propagation rules. A change propagation rule from element A to element B describes, if element A changes, the change propagates to element B [HBK18;

Bus+18b]. Element A is referred to hereinafter as thesource element and element B as thetarget element hereinafter. Change propagation rules are based on the dependencies between the metaclasses of the aforementioned metamodels describing the system’s structure or its behavior. In other words, a change propagation rule is described for all systems in a specific domain [Bus+18b]. Thus, change

propagation rules highly depend on the metamodels of the systems’

structure and behavior [Bus+18b]. Domain knowledge is required to specify change propagation rules.

Figure 5.1 gives an overview of the generic methodology. The rectangles with rounded corners represent the algorithms, while the other rectangles represent the metamodels. The algorithms and metamodels of the method-ology are referred to hereinafter asthe elements of the methodology in the following. Note that the methodology should be considered as a guideline to develop an approach to change propagation analysis. It does not require the use of a specific modeling language or a certain programming language.

For example, domain experts can either develop a metamodel or use_Enum and GPL code instead, if it is possible. Another example is the usage of a GPL or a DSL to describe the algorithms. The methodology consists of two main parts:

• Domain-independent part of the methodology: The first part contains the domain-independent elements of the methodology.

During the development of the methodology, they were conceptual elements, which can occur in several domains. Factoring out these

elements enables using them in different domains. In the following, the reason for choosing different conceptual elements are described in more detail [HBK18].

• Domain-specific part of the methodology: The second part contains domain-specific elements, which have to be instantiated in a domain. The second part can be divided into two further parts: an obligatory part and an optional part. The obligatory part contains elements that need to be defined or extended in a new domain in order to instantiate the methodology. The optional part contains methodology elements that can be extended in a new domain if required. This optional elements of the methodology is represented by dashed rectangles in Figure 5.1 [HBK18].

Domain-independentDomain-specific Change Propagation Analysis for the Elements of the Domain Metamodel

Metamodel

Change Propagation Analysis for the Elements of the Context Metamodel

Algorithm

Figure 5.1.:Overview of the methodology for the domain-spanning change propa-gation analysis [HBK18, p. 2]

Section 5.2 describes the domain-independent metamodels and algorithms of the methodology in more detail, while the domain-specific metamodels and algorithms of the methodology are described in Section 5.3.