Modeling Refactorings based on Graph Transformations

means that the selection of the first file to be modified still depends on chance.

As a result, the structure of the change coupling graph is strongly dependent on coincidence and not on the intentions of the developers. To address this issue, we present an approach to model further intentions of a developer in the next section.

These intentions influence the selection of the files of a commit, including the first file selected.

4.3. Modeling Refactorings based on Graph Transformations

To improve the structure of the simulated software graph, we reduce the randomness of the file selection process for a commit. Therefore, we introduce the developers intention to refactor the code. For example, if a developer works on code with low maintainability (e.g. a method with above average size), it can apply a refactoring to improve the quality of the code. The developer’s decision process is depicted in Figure 4.12. This behavior follows the prominent BDI [3] approach, where devel-opers formulate goals based on their beliefs and build plans to reach them. Beliefs are the current state of the software under simulation, represented as software and graph metrics.

Refactorings are a common approach to describe well defined code structure changes like described in Section 2.3. To model software refactorings we use graph trans-formations (see Section 2.4). For each refactoring a transformation rule has to be defined.

In order to create a plan for each considered refactoring, we need detailed information about the software state before the refactoring is applied. The application of a refactoring causes state changes of software entities like the change of metrics of classes and methods as well as structural graph changes. This required data is collected through mining software repositories.

To apply these transformation rules, we need a more detailed graph for the descrip-tion of the software under simuladescrip-tion. The used graph as presented in Definidescrip-tion 1 was introduced in [7]. It is transformed by the work of the developers according to formulated transformation rules. Due to the simplicity, it is easy to extend this graph when required. For modeling inheritance, for example, an additional edge label representing links between classes that belong to an inheritance hierarchy can be introduced.

Definition 1. Let Σ ={C, M} be a set of node labels and ∆ ={mm, mc} be a set of edge labels. The node types represent software entities: classes (C) and methods (M). Edges represent relationships between nodes: method memberships (mm) and method calls (mc). A graph over Σ and ∆ is a System G = (V, E, l), where V

4. Evolution of Agent-Based Simulation Models 52

project size (number of files): 1100 complexity (LOC / method): 155 number of developers: 11

Figure 4.12.:Example for developer’s intentions adapted from [7]. The developer works on a method that is hard to maintain because it has too many lines of code. To improve maintainability, the developer applies the refactoringExtract Method.

Thus, parts of the origin method are moved to a newly created method that is called from the origin method.

is a set of nodes, l : V → Σ is a function that assigns a label to each node, and E ⊆V ×∆×V is the set of edges.

To restrict the edge creation thetype graphdepicted in Figure 4.13 is used. The type graph is a generation specification such as the UML class diagram. For instance, member method edges link a class and a method as well as method calls can only occur between two methods.

C

M

Figure 4.13.:Type Graph adapted from [7].

To integrate the new entities into the existing model, two networks need to be introduced. First, an undirected one that represents the membership of a method to a class. Second, a directed network to model method calls. To keep the model

53 4.3. Modeling Refactorings based on Graph Transformations simple, we assume that there is exactly one class per file. An example for both networks is presented in Figure 4.14.

File A

Class A File B

Class B Method A1

Method A2

Method A3 Method B2

Method B1

Figure 4.14.:Example for method call and method membership networks. The blue edges represent the method membership network. Method calls are represented by red edges.

We introduced graph transformation rules for the three most frequently occurring refactoring types based on the mining process. The transformation rules are shown in Figure 4.15. The left hand side of the rule has to be replaced by the right hand side of the rule. In these rules the method calls, that are not important for the actual refactoring, are omitted. In the application of the rules it is ensured that all incident edges to a removed vertex are deleted as well. Therefore, no dangling edges occur after the transformation.

Since extract method is actually the opposite of inline method both refactorings are depicted in Figure 4.15a.

To find a match for the rule’s left-hand side, not only the structure of the software graph is taken into account. Also appropriate software metrics are considered. These are, for example, the size measured in lines of code (LOC) for extract method (Figure 4.15a) and the coupling measured in number of outgoing invocations (NOI) for move method (Figure 4.15b). Furthermore, we assume that NOI of the origin class of a method will be reduced when a move method refactoring is applied.

4. Evolution of Agent-Based Simulation Models 54

Figure 4.15.:Graph transformation rules for three software refactorings adapted from [7].

The left-hand side of the rule will be replaced by the right-hand side in the software graph. The dotted edge represents outgoing invocations, this means method calls to methods of the other class.

The modeling of refactorings reduces the randomness in the selection process of the files which are included in a commit. Furthermore, the scope of possible re-search questions is extended. How these models are implemented is described in the following.