Semantic Clone Detection for Model-Based Development ... - CiteSeerX

Semantic Clone Detection for Model-Based Development of Embedded Systems Bakr Al-Batran1 , Bernhard Schätz1 , Benjamin Hummel2 1

2

fortiss GmbH, München, Germany {albatran,schaetz}@fortiss.org Fakultät für Informatik, Technische Universität München, Germany [email protected]

Abstract. With model-based development becoming an increasingly common development methodology in embedded systems engineering, models have become an important asset of the the software development process. Therefore, techniques for the automatic detection of clones in those models have been developed to improve their maintainability. As these approaches currently only consider syntactic clones, the detection of clones is limited to syntactically equivalent copies. Using the concept of normal forms, these approaches can be extended to also cover semantic clones with identical behavior but different structure. The submission presents a generalized concept of clones for Simulink models, describes a pattern-based normal-form approach, and discusses results of the application of an implementation of this approach.

1

Introduction

Software has become the driving force in many application domains for embedded systems, like the automotive domain. Consequently, software in these domains has reached a substantial size. Furthermore, the developed software systems make use of a high degree of reuse, due to the large number of variants in product-lines, high cost pressure, and decreasing length of innovation cycles. As a result, software maintenance – corrective as well as perfective – has become an important aspect of the current development process. In automotive software development, the use of a model-based approach has become standard, specially in the powertrain, chassis, and body domain. Therefore, the maintenance of those models – with Simulink or TargetLink as the corresponding domain specific language – is becoming an increasingly pressing issue. In code based development, the existence of clones [12] – duplicate or similar parts of software – is specifically known to often worsen productivity in software maintenance. With the move from code to models in the embedded domain, the question arises how to deal with clones in model-based development. 1.1

Problem and Contribution

As discussed in more detail in Section 2, clones can severely hamper the maintainability of models of embedded systems. However, only few approaches for

detection of those clones exist. Furthermore, these approaches are limited to a rather restricted syntactic notion of similarity – essentially structural identity. Therefore, an improved technique for model-clone detection is introduced, supporting detection of semantic clones, i.e., parts of models with different structure but equivalent behavior. The approach is based on the use of normal forms of Simulink models to identify semantic clones with different syntactic structures, and the use of semantic-preserving graph transformations to achieve them. 1.2

Outline

Section 2 gives a short introduction on the detection of clones, especially in the context of model-based development of embedded systems. Section 3 provides a description of the core aspects of the approach; furthermore, examples of the normalizing transformations used are given. Section 4 describes the application of the approach to realistic models and discusses the results of the application. Finally, Section 5 discusses related works, while Section 6 concludes with a discussion of the application of the approach and possible future work.

2

Clones in Model-Based Development

Although model-based engineering has become a widespread approach especially in the development of embedded systems, the identification of clones in models has be come only recently a research issue [3]. Investigation on practical application of model-clone detection [2] has shown that it can be successfully applied to industrial-scale models with a low range of false positives. 2.1

Clone Detection

In general, (code) clones are (code) fragments that are similar w.r.t. to some definition of similarity [12]. The employed notions of similarity are heavily influenced by the program representation on which clone detection is performed and the task it is used for. The central observation motivating clone detection research is that code clones normally implement a common concept. A change to this concept (e.g., a bug fix) hence typically requires modification of all (code) fragments that implement it, and therefore modifications of all clones. Clones are introduced for different reasons. Most commonly, they are created by deliberate copy-and-paste from previous solutions, or by explicitly inlining library code. However, clones can also be introduced unintendedly by independently creating similar solutions. 2.2

Model-Based Development For Control Systems

The models used in the development of embedded systems are taken from control engineering. Data-flow diagrams as shown in Figure 1 consisting of blocks and lines are used in this domain as structured description of these systems. Tools like

Matlab/Simulink are used for the construction and simulation of these models. To generate software from these models, these diagrams are interpreted as time(and value-)discrete control algorithms. By using tools like TargetLink [7], these descriptions are translated into computation tasks, which are then executed by use of a real-time operating system to implement an embedded application. In the context of Simulink models, [3] defines a model clone to be a connected submodel, which is syntactically equivalent to another one, up to certain edit operations. Syntactical equivalence means that the data-flow networks have essentially the same structure and labeling, allowing for minor modifications of the copied submodel like change of constant parameters. In the following, a model clone is understood as a connected submodel, which is semantically equivalent to another one – which means that it exposes the same behavior, again up to minor adaptions like change of parameters. In contrast to syntactic clones, semantic clones may exhibit a rather different structure.

3

Approach

In this section we introduce our approach for structural normalization of data flow models. Our normalization considers graphs describing computational dataflow. Since structural normalization of these graphs uses graph transformations we briefly introduce directed graphs and graph transformation systems. As we target embedded systems, the approach is illustrated using Simulink data-flow models. However, the approach is applicable on all types of data flow graphs using similar semantics. Directed Graphs A directed graph is a triple (V, E, λ) consisting of a set V of nodes, a set E of edges and a function λ : E → V × V associating each e ∈ E with an ordered pair (v1 , v2 ) ∈ V × V . Furthermore a labeled directed graph is a graph with an additional labeling function L : V ∪ E → N which maps nodes and edges to labels from a set N . Graph Transformation Systems A rewriting rule p = (L, R) ∈ P is a pair of graphs L = (VL , EL , λL ), R = (VR , ER , λR ) known respectively as the pattern graph and the replacement graph of p. Applying p to a source graph G resulting in a target graph H implies the existence of the graph morphisms3 α : L → G and β : R → H consisting of the two morphisms γ : VL → V and δ : EL → E such that H = (G \ α(L)) ∪ δ(R). A graph transformation rule p induces a relation →p on graphs by G →p H iff H results from application of p to G. This relation can be trivially extended to a set P of rules, yielding a relation →P . Using the transitive and reflexive closure →∗P allows to construct chains of transformations from a source to a target graph. →∗P is called confluent iff for all G, G1 , and G2 with G →∗P G1 and G →∗P G2 some G0 with G1 →∗P G0 and G2 →∗P G0 exists. Furthermore, 3

A graph morphism (V, E, λ) → (V 0 , E 0 , λ0 ) consists of a pair γ : V → V 0 and δ : E → E 0 with λ0 (δ(e)) = (γ(v), γ(v 0 )) if λ(e) = (v, v 0 ).

Fig. 1. Two syntactically different but semantically equivalent fragments A and B

→∗P is called Noetherian iff for each G a G0 exists with G →∗P G0 such that G0 6→∗P G00 for arbitrary G00 . Intuitively, deterministic rule sets yield confluent, terminating rule sets yield Noetherian relations. 3.1

Normal Forms of Data Flow Models

Behaviorally equivalent data-flow (sub-)models can have completely different structures (see Figure 1). Therefore it is difficult to directly establish equivalence of two models using structural comparison techniques. However, if the structures of two equivalent models can be transformed to the same form without changing their behavior, it suffices to check structural equality of the transformed forms to establish their behavioral equivalence. Transforming the data-flow models can be achieved using graph transformation rules. But this approach is only feasible if the transformations yield a unique target model for each source model. In short, we are therefore looking for equivalent unique normal forms of models. For a given set S of elements – in our case data-flow models – and an equivalence relation ≡, a normal form can be achieved by identifying a set N ⊆ S such that for all s ∈ S exists exactly a unique n ∈ N with s ≡ n. A set of transformation rules P induces an equivalence relation ≡P on graphs G and G0 via G ≡P G0 iff G →∗P H and G0 →∗P H for some graph H. If the set induces a confluent and Noetherian relation, the required unique normal form can be obtained by selecting graphs for which no applicable transformation rule exists. 3.2

Construction of Normal Forms via Model Transformation

To achieve normal forms, normalization is performed by using a set of transformation rules. The rules are applied iteratively. After no more rules are applicable,

the clone detection algorithm proposed in [3] is applied. This strategy allows detecting semantic clones using structural comparison techniques. As the normalization of the syntactically different but semantically equivalent fragments requires semantically equivalent unique normal forms, the transformation must be semantically correct, confluent, and terminating. Semantic Correctness The transformation defined by each rule has to preserve the observable behavior of the transformed model fragment, since syntactic modifications that change the behavior will lead to false positives. In our approach all transformations are based on mathematical, logical, or structural equivalence properties of Simulink models. Rule Confluence Transformation rules can introduce application conflicts if their matches overlap and thus their application would lead to non-deterministic results. This issue is known as the confluence problem and in generally undecidable [11]. In the approach presented here confluence is approximated by assigning a priority value to each rule in order to solve the overlap conflicts in favor of the rule with the highest priority. Since this however leaves conflicts between applications of the same rule, no complete confluence is assured, potentially leading to non-unique normal forms. Rule Termination Apparently, the investigation of the conditions under which the normalization can satisfy the termination criteria is very important for our approach, since a normal form can only be reached if the graph transformation terminates. In our case the set of transformation rules can be subdivided into: – Rules which reduce the size of the model – Rules which increase the size of the model or keep it unchanged Since the first class of rules always reduces the number of the finite model elements, applying these rules always terminates. However the termination of the second type of rules is undecidable in general [10]. A workaround for the problem is to use a layered transformation system [4], grouping rules in deletion and non-deletion layers. All rules belonging to one layer are applied together, and each layer is applied only once. In a deletion layer all member rules must delete at least one element but not a newly created one. In a non-deletion layer each rule must not delete any element or use a newly created element in its pattern. A finite source graph and a finite number of layers guarantee termination. In addition, to reach a normal form using a layered transformation system the following conditions must also be fulfilled: – The last creation of an element with a certain label should precede the first deletion of an element with the same label. – The occurrence of an element of a certain label in the pattern of a rule implies that all elements of the same label were already created in previous layers.

Fig. 2. Placing Gain Block before Integrator Block

These two conditions imply that no rules are applicable after all layers have been completed. Hence, termination is reached. The grouping of rules into layers is done based on sequential dependency analysis. Furthermore, checking the mentioned termination conditions in each layer can be done automatically [4]. Negative Application Conditions To avoid transforming a matched fragment changing its behavior, a set of negative application conditions are assigned to rules, which must be fulfilled before applying the transformation. For example, a transformation rule is not applied if matched blocks are involved in feedback cycles as shown in Figure 6. 3.3

Derivation of Transformation Rules

We defined 40 semantic preserving transformation rules which perform structural modifications on Simulink models [1]. The rules are derived using mathematical, logical and structural semantics of Simulink models. In the following, we present some of the transformation rules grouped by the properties they are derived from, discuss their correctness and give examples for clarification. Rules Derived from Mathematical Properties The following transformation rules are based on properties of mathematical operations like commutativity, associativity, and distributivity. Placing Gain Block before Integrator Block: In a model fragment with an integrator block followed by a gain block, the two blocks are swapped, executing the gain before the integrator, exploiting the commutativity of the operations. Figure 2 illustrates the rule. Joining Consecutive Sum/P roduct Blocks: This rule can be applied on consecutive sum or product blocks resulting in merging them. The rule is based on the commutativity and associativity of addition and multiplication. In Figure 1 the product blocks in fragment A are joined into one product block in fragment B . Trigonometric Functions: These are covered by a set of rules converting a trigonometric function block into its normalized representation using only sine blocks. For example, the tan block in Figure 3 is replaced by sine and cosine blocks sharing the original input signal, followed by a product block.

Fig. 3. Normalizing a tan block

Fig. 4. DeMorgan Law

Rules Derived from Logical Properties The following transformation rules are used to normalize model fragments of logical blocks. Hence, the rules are based on logical properties such as absorption, negation, distribution and DeMorgan laws. DeMorgan Law: This rule is executed on two not blocks connected to an or (and) block resulting in replacing them by an and (or) block followed by a not block. The new and (or) block combines the two original input signals of the mentioned not blocks. If the original or (and) block is connected to other inputs, the original or (and) block is retained and the output of the newly created fragment is attached to it as a new input (see Figure 4). Distribution Law: The or -form of this rule is executed on a fragment with two or blocks, or1 and or2, both with two input signals whose outputs are combined by an and block and their input signals contain the same signal s. The rule replaces the fragment by an or block combining the signal s and a new and block whose input signals are those of the blocks or1 and or2 except for s. If an or block contains more than two input signals, the rule attaches it as an input signal of

Fig. 5. Gain for Multiplying by a Constant

the new created and block. The other rule is similar to the first one except for swapping the and and or blocks. The rule uses the distribution property in logic. Rules Derived from Structural Properties The following transformation rules are based on providing alternative structures or model fragments which behave similarly to the original model fragments. Combining Consecutive M ux Blocks: The rule is applied on two consecutive mux blocks resulting in merging them. All original inputs are inputs of the new mux block, while its output is the original output of the consecutive mux blocks. The rule uses the fact that combining mux blocks does not change the resulting signal structure. Gain for Multiplying by a Constant: This rule is executed on a product block with at least one constant block as input. In case of a product block with two input signals, the rule results in replacing the product block by a gain block whose value is the value of the constant block. In case a product block with more than two input signals, only the constant block is eliminated and replaced by a gain block attached after the original product block (see Figure 5). Execution strategy Our execution strategy consists of the following steps, described in detail in [1]. First the transformation rules are grouped into rule layers to meet the above-mentioned termination criteria. To construct these layers, each rule p is assigned to the lowest layer Li respecting the following rules: 1. if Li is a deletion layer then p must at least delete one element. 2. If Li is a non deletion layer then p must not delete any element. 3. If Li is a deletion layer, and p deletes an element e with label l then all rules creating elements of label l belong to layers Lh with h < i.

Fig. 6. Context Preparation and Non-Applicability of Transformation Rules

4. If Li is a non-deletion layer then for each label l of an element e in the lefthand side of p all rules creating elements with label l belong to layers Lh with h < i

Then, the member rules of each group are prioritized in order to solve conflicts of overlapping matches in favor of the rule with the highest priority. After that, the layers are applied one after another, repeatedly applying the rule with the highest priority as often as possible. Once no more rules can be applied in a layer, the next layer is applied. Context Preparation The context preparation is aimed at preserving the overall behavior of the model after a model fragment has been normalized. If a matched block has outgoing lines to other matched blocks as well as to unmatched blocks the latter outgoing lines are called intermediate results. During the normalization the behavior provided by the intermediate results can change, in turn potentially leading a change of the overall behavior of the model outside the fragment. This problem can be solved by defining negative application conditions to forbid rule executions in case of the occurrence of intermediate results. However, this restriction leads to a limitation of further normalization of model fragments. Therefore, a second possibility has been investigated. This solution is the provision of these intermediate results by copying the parts of the match which generate them. Hence, the intermediate results still are generated in the exact same manner before the normalization and provided to the parts of the model which depend on them. In special cases the context preparation cannot be applied, for example in case of feedback loops between matched and unmatched nodes. Figure 6 illustrates the application of context preparation rules and negative application conditions: The context preparation copies the derivate block before applying the transformation rule which swaps the green colored derivative

and gain blocks. The red colored integrator and gain blocks can not be swapped because of the existence of feedback loops.

4

Case Study

To evaluate the practicability of our approach in enhancing the clone detection algorithm in [3] with the capability of detecting semantic clones, the detection method was implemented and applied to a case study. 4.1

Analyzed Model

We performed our case study on a set of models with more than 1400 Simulink blocks distributed over 8 files. The set consists partly of models which contain several identical fragments and partly of models which implement similar behaviors. The models implement related functionalities of embedded systems in the automotive domain. 4.2

Implementation

To evaluate the normalization approach and its usefulness for clone detection we implemented it as a part of the quality analysis framework ConQAT, performing the normalization as a preprocessing step before applying the clone detection algorithm introduced in [3]. Furthermore, we made use of facilities implemented in [3] for preprocessing the Simulink models used for the case study and for reviewing the results. 4.3

Application

The clone detection algorithm [3] was applied both with and without the normalization step, using 40 transformation rules (see section 3.3). After the clone detection algorithm had been applied, each detected clone class together with its size and the number of its instances was listed. Additionally, for the normalized model the number of the rule executions and the number of the context preparations together with the locations of the rule matches were determined. We removed all clones consisting of less than 4 blocks, since they were considered as irrelevant. Subsequently, we compared the found clones of both cases based on their size and location to detect related and semantic clones. Since clones could be distributed across multiple files, the clone detection algorithm was executed on all models at the same time. 4.4

Results

Our implementation of the normalization algorithm needed 4 seconds and about 6 kB of memory on a 1.7 GHz workstation with 2 GB of main memory for

Rule # Executions Gain for Multiplying by Constant 104 Joining Consecutive Gain Blocks 58 Bias for Adding a Constant 42 Joining Consecutive P roduct Blocks 40 Joining Consecutive Sum Blocks 28 Placing Gain Block before Integrator Block 16 Sum Rule in Integration 6 Power Rule 5 Distribution of Multiplication over Addition 4 Replacing Comp. to Const. by Comp. to Zero 4 Placing Gain Block before Derivative Block 2 Joining Consecutive M ux Blocks 2 Joining Consecutive Bias Blocks 2 Trigonometric functions 2 Elimination of Rounding Blocks 2 Math functions 2 Replacing U nary M inus Block by Gain Block 2 Table 1. Number of Executions for each Rule

transforming a Simulink model with 1400 blocks into a normal form. The normalization performed 321 applications of 16 defined rules, reducing the size of the model to 1351 blocks. To be able to execute the rules the normalization accomplished 142 context preparations. The execution of the clone detection after performing the model normalization found 127 clone pairs in the models, which resulted in 42 clone classes after clustering. The average clone size was about 14.5 nodes. On the other hand, the execution of the clone detection without performing the model normalization found 113 clone pairs which resulted in 49 clone classes after clustering. The average size of the found clones without performing the normalization was about 12.7 nodes. Table 1 shows how often each transformation rule was applied. The rule with the largest number of executions was the "gain for multiplying by constant”-rule followed by the “bias for adding a constant”-rule. Furthermore the joining rules were the most frequently applied rules. In contrast, the logical rules were hardly executed. In Table 2 an overview is given of the cardinality of the clone classes found with and without performing the normalization step. In both cases the most commonly reported clone classes were pairs of clones. However, after applying the normalization clone detection reported more clones but the clustering resulted in fewer clone classes and especially fewer pair classes than without normalization. This indicates that the clustering phase was more effective after applying the normalization. The left half of Table 3 shows the number of found clone classes, while the right half shows the number of reported clones, in each case in relation to the size of the clones for the clone detection with and without applying the normalization. The number of the largest clone classes and their cardinality were similar in both cases. The number of the smallest clone classes detected without the

Cardinality of Clone Class Number of Clone Classes Not Normalized Normalized 2 32 26 3 5 5 4 6 3 5 4 3 6 1 3 7 1 0 8 0 2 9 0 1 Table 2. Number of Clone Classes for Clone Class Cardinality

Clone Size No. of Clone Classes No. of Reported Clones Not Normalized Normalized Not Normalized Normalized 4-6 31 17 46 43 7-10 8 13 11 25 11-15 4 4 5 7 16-21 0 4 0 6 21-30 1 0 1 0 >30 4 4 5 5 Table 3. Number of Clone Classes and Number of Reported Clones for Clone Size

normalization was significantly greater than after applying the normalization. Since the number of the reported clones in both cases was similar we expected that the normalization resulted in detecting semantic clones which led to fewer clone classes after clustering. For the size ranges 7-10 and 16-21, the clone detection reported considerably more clones after applying the normalization which indicated the detection of semantic clones within these size ranges. About 62% of the originally detected clones were recognized again after the normalization. The size of these clones mostly increased or decreased due to the applied rules. In 5 detected clones the cardinality of the detected clone classes increased which indicated the detection of semantic clones. About 17% of the originally detected clones were not recognized after the normalization, since due to the reduction in clone size, they were considered as irrelevant. About 21% of the originally detected clones were destroyed after the normalization, caused by lack of confluence specifically in context preparation. Detected Semantic Clones After the reported clone classes had been manually inspected, we found out that 5 clone classes contained substantial semantic clones. One of the found clone classes was very small and of limited functionality. Two pair classes extended syntactic cones by adding more blocks as a result of the normalization. The last two clone classes – one of them shown in Figure 7 – con-

Fig. 7. Two Model Fragments A and B Recognizable as Clones after Normalization

sisted of model fragments of relevant size which had different syntax but similar significant functionalities. 4.5

Discussion

The results – confirmed by additional experiments with models from environment modeling, embedded control, and energy systems – indicate that the normalization approach effectively extends the clone detection algorithm proposed in [3] with the capability of detecting semantic clones. Moreover the manual inspection of the found semantic clones shows that simple rules like replacement (trigonometry rules) or swapping rules can be useful for detecting semantic clones. Such simple rules were useful in our experiment as the syntax of the semantic clones were equal except for slight differences. However, a comparison of the reported clones after applying the normalization with those without applying the normalization shows that the context preparation in our experiment led often to destruction of existing clones or generation of new ones, due to a lack of confluence. Therefore it is favorable to constraint the context preparation using negative application conditions even if this decreases the number of possible rule executions. In addition, the results indicate that normalization often reduced the size of existing clones, making them considered as irrelevant. The set of transformations used in the case study potentially results in the reduction of the size of clones through the normalization and the lack of confluence, thus leading to a possibility of false negatives, i.e., undetected (syntactic) clones. As semantic clones detection is used in addition to the detection of syntactic clones, from a pragmatic point of view this still substantially improves the

state of the art via better recall in form of larger and more relevant clones, but requires research to provide a more complete treatment.

5

Related Work

Currently, clone-detection in model-based development has only gained little attention. [3] discusses the use of clone-detection for a Simulink-based development process, however uses a very restricted notion of similarity. [2] gives a more detailed comparison of this syntactic clone detection – forming the second step after the normalization in the semantic clone detection used here – to other related approaches, and discusses means to improve precision. In [9], Pham et al. presents an approach for detecting approximate clones in Simulink models, allowing slight structural differences in the models. However the approach can not be used to approximate semantic similarity, since small structural modifications can introduce substantial behavior changes. In [6], a formalism is shown for detecting equivalent business process models based on detecting of semantically equivalent model fragments, transforming a business process model into a term system and using term rewriting to obtain a normal form. However, the approach is very specific to business process models supporting only a more structural notion of similarity. Hence, the approach cannot be directly adapted to data-flow models such as Simulink. In [5] Program Dependence Graphs (PDG) are used to identify semantic clones in programs independent from their linear syntactic representation. As a dataflow model is similar in nature to a PDG, isomorphic syntactic Simulinkclones already correspond to those kind of semantic clones, while the normalization used here exceeds the aspect of isomorphism. Approaches like [8] are using a more relaxed notion of similarity lifting this limitation, but are not sensitive to topological differences between subgraphs, thus making them unsuitable for data-flow models, as topology plays a crucial role there.

6

Conclusions

In this contribution, an extension to the detection of clones in the development of dataflow models for embedded control systems has been presented. In contrast to previous approaches, mainly relying on the detection of syntactically equivalent model fragments, in the approach presented here the concept of semantic equivalence was used. To that end, normalization of models by means of graph transformations has been used to identify model fragments with equivalent behavior. Although specifically implemented for Simulink, the presented approach is also directly applicable for other data-flow formalisms like ASCET-SD, Esterel, or Lustre. While the basic approach – comparing normal-forms of models obtained by graph transformations – also applies to other specification forms like state machines, the practical usefulness is ongoing research. The feasibility of the approach has been proven by the successful application of a its implementation to models of practical size. This application lead to

the identification of additional clones, not identified by the detection approach relying on structural equivalence alone without the use of normalization. While the basic feasibility of the approach has been shown in the performed case studies, more experiments with larger and more heterogeneous models are needed to finally assess the pragmatic advantages of the approach. As obviously the effectiveness of the detection of semantic clones depends on the notion of similarity used, which depends on the transformations used to obtain the normalizations, the introduction of additional transformations must be investigated for model fragments considered to be equivalent but not detected by the approach.

References 1. Al-Batran, B.: Model-Based Clone Detection Using Normal Forms. Master’s thesis, Technische Universität München (2011) 2. Deissenboeck, F., Hummel, B., Jürgens, E., Pfähler, M., Schätz, B.: Model clone detection in practice. In: International Workshop on Software Clones. pp. 57–64. IWSC ’10, ACM, New York, NY, USA (2010), http://doi.acm.org/10.1145/ 1808901.1808909 3. Deissenboeck, F., Hummel, B., Jürgens, E., Schätz, B., Wagner, S., Girard, J.F., Teuchert, S.: Clone Detection in Automotive Model-Based Development. In: International Conference on Software Engineering (2008) 4. Ehrig, H., Ehrig, K., de Lara, J., Taentzer, G., Varro, D., Varro-Gyapay, S.: Termination criteria for model transformation. In: Proc. Fundamental Approaches to Software Engineering. pp. 49–63. Springer (2005) 5. Gabel, M., Jiang, L., Su, Z.: Scalable detection of semantic clones. In: International Conference on Software Engineering. pp. 321–330 (2008) 6. Gerth, C., Luckey, M., Kuster, J.M., Engels, G.: Detection of Semantically Equivalent Fragments for Business Process Model Change Management. In: International Conference on Services Computing. pp. 57–64. IEEE Computer Society (2010) 7. dSpace GmbH: TargetLink Production Code Generation, www.dspace.de 8. Krinke, J.: Identifying similar code with program dependence graphs. In: WCRE’01 (2001) 9. Pham, N.H., Nguyen, H.A., Nguyen, T.T., Al-Kofahi, J.M., Nguyen, T.N.: Complete and accurate clone detection in graph-based models. In: International Conference on Software Engineering. pp. 276–286. IEEE Computer Society, Los Alamitos, CA, USA (2009) 10. Plump, D.: Termination of graph rewriting is undecidable. Fundam. Inf. 33, 201– 209 (February 1998), http://portal.acm.org/citation.cfm?id=294994.294998 11. Plump, D.: Confluence of graph transformation revisited. In: Processes, Terms and Cycles: Steps on the Road to Infinity: Essays Dedicated to Jan Willem Klop on the Occasion of His 60th Birthday, volume 3838 of LNCS. pp. 280–308. Springer (2005) 12. Roy, C.K., Cordy, J.R.: A survey on software clone detection research. Tech. rep., Queen’s University, Canada (2007)