Model of Software

The Minimal Plant example is a PLC-based plant. The control software is assumed to be programmed using the IEC 61131-3 standard. The behavior of the Minimal Plant example is also based on the xPP U [Vog+14a]. The initialization process of the conveyor initializes the local variables. After the operator pressed the start button, the conveyor is initialized. During the initialization, the conveyor runs for a short time. After a successful initialization, the control software starts the operation mode. The work pieces are conveyed to the ramps. An optical sensor is used to detect the specific types of work pieces at the extension position. After a specific shape of work pieces was detected, the pusher is extended to push the work piece of a specific type to the ramp [Vog+14a].

Structure name: Ramp 2 to Frame

Interface name: Ramp 1 to Frame

Interface

Figure 4.3.:Overview of the hardware of the Minimal Plant example as a reduced variant of the xPP U [Vog+14a]

Methodology

Sustainable systems have to be continuously changed in order to be able to provide their functionality correctly over time [Ros15; Leh79]. Thus, sustainable systems have to be maintainable. Maintainability of a system can be considered as the extent, to which a system can efficiently and effectively be modified by given changes [ISO11]. In other words, the maintainability of a system considers the required effort to implement a change request in a system [HBK18]. Thus, the maintainability of a system does not depend only on the system under study, but also on both the system under study and the upcoming change requests.

In general, the sustainable systems contain heterogeneous elements from different domains such as IS, BP, or aPS. In the context of this thesis, a system element represents a part of the system. Similar definitions are also proposed by other authors. For example, Conway states in [Con68, p. 2]

“any system of consequence is structured from smaller subsystems which are interconnected”. He describes the process of identifying the subsystems recursively, as a subsystem can be considered as a system [Con68]. This process can be iteratively repeated “until we are down to a system which is simple enough to be understood without further subdivision” [Con68, p. 2].

Similar to the Conway’s definition, the definition used in this thesis does not demand further characteristics of the system elements such as their granularity, as the choice of an element in a system depends on the context and the usage.

According to [Con68, p. 2], “a description of a system . . . must delineate each of the subsystems and how they are interconnected”. In the context of this thesis, this description corresponds to the system model, which describes the system elements and their relationships.

An example of systems comprising heterogeneous elements is an aPS (e.g., a plant), which in general consists of mechanical, electrical/electronic com-ponents and software [Vog+17; Hei+18]. A system element in this example can be a mechanical component such as a physical table or a crane arm.

During the change implementation phase, the system elements from dif-ferent domains influence each other in a mutual way [Ros+17a; HBK18].

Thus, it is not sufficient, if a change propagation analysis approach focuses on the maintainability of systems in only one domain. In other words, the maintainability analysis approaches have to consider heterogeneous sys-tem elements from several domains and their mutual dependencies [Ros15;

Ros+17a; HBK18].

Most approaches presented in Chapter 3 are designed to analyze the change propagation in systems in only one domain. Thus, they do not consider the effects of a change request to system elements in one domain on the dependent system elements in other domains. The results of different approaches from different domains can be difficultly combined to obtain a domain-spanning change propagation analysis. The main reasons for the incompatibility of approaches and their results are that the approaches are often tailored to specific types of systems (e.g., code-based approaches) and are designed at different levels of abstraction [HBK18]. The aforementioned factors make the need for an approach essential, which analyzes the change propagation across domains.

This chapter proposes a general methodology to analyze the change propa-gation in heterogeneous system elements from different domains [HBK18].

Thus, the methodology was designed to answer thefirst research question.

The remainder of this chapter is structured as follows: Section 5.1 gives an overview of the methodology. The methodology consists of two types of metamodels and algorithms: i) The metamodels and algorithms that can be applied in all domains. This is described in Section 5.2. ii) The metamodels and algorithms that have to be extended or defined for the domain under study. Section 5.3 discusses these metamodels and algorithms in more detail.

The process of instantiating the methodology in a specific domain is given in Section 5.4. Section 5.5 summarizes the contributions of this chapter.

The results of this chapter have been published in the papers [Ros15; HBK18]

and partially (e.g., duplicate elimination, supporting users’ decision by

reducing task list, or sorting the task list in the instance of the methodology in IS and BP) in the papers [Ros+17a; Bus+18a].

5.1. Generic Methodology for Domain-Spanning Change 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.

5.2. Domain-independent Elements

This section describes the metamodels and algorithms of the methodol-ogy that can be used in any instance of the methodolmethodol-ogy. The

domain-independent elements involve a metamodel to represent the modification regardless of the domain, algorithms for creating and managing task lists, as well as a metamodel and the corresponding algorithm for supporting human decisions by reducing task lists. The following subsections describe these metamodels and algorithms in more detail:

5.2.1. Domain-independent Metamodel of Modification Identifying the potentially affected element types in a specific domain plays an important role during the development of a change propagation analysis approach in this domain. These element types mainly refer to the concrete metaclasses of the system’s structure and behavior described previously. In other words, it is important to know whether the instances of a metaclass representing system elements can in principle be affected by a change. Thus, the types of system elements that can be potentially affected by a change need to be metamodeled. Further, the source types and the target types of system elements in a change propagation rule have to be determined. The source types and the target types can be especially important for example to reproduce the cause of the propagation of false positives.False positives in a task list are model elements referring to elements in the systems’ structure or behavior that are not actually affected by a change [Ros+15b]. Thus, a domain-independent metamodel representing modifications has to reflect the previously described properties of change propagation.

Modification

Figure 5.2.:Domain-independent metamodel of modification - Simplified excerpt

Figure 5.2 illustrates the domain-independent metamodel of modifica-tion. It shows the common metaclasses of modification in different do-mains regarding the change propagation analysis at a high abstraction

level. The set of model elements and the corresponding metaclass of the domain-independent metamodel of modification are described in the fol-lowing [HBK18]:

• The first class of model elements refers to the set of all model elements in a domain, which can be potentially affected by a change.

Modificationmetaclass in Figure 5.2 represents this set at the metamodel level. If a change propagates between two elements, one element is the cause of the change (i.e.,causing element in

Figure 5.2) and the other element is the affected element by the change (i.e.,affected element in Figure 5.2). Causing element and affected element in Figure 5.2 represent source element and target element in a change propagation rule.

• The second class of model elements refers to the set of all model elements in a domain, which domain experts can initially select as changed elements.SeedModificationmetaclass in Figure 5.2 represents this set at the metamodel level. The set of metaclasses that can be seed modifications is a subset of the set of metaclasses that can be potentially changed (i.e., the previously described class of model elements).

• A change propagation step refers to affected model elements that have the same change cause.ChangePropagationStepmetaclass in Figure 5.2 represents this set at the metamodel level.

• The task list is composed of a set of allSeedModificationand the set of allChangePropagationSteps.ModificationRepositoryin Figure 5.2 represents a task list at the metamodel level.

The aforementioned metaclasses have to be extended to instantiate the methodology in a new domain.Domain-specific metamodel of modification in Figure 5.1 describes the extension of theDomain-specific metamodel of modification metamodel for a new domain.

5.2.2. 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

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