Clone Detection Using Scope Trees

Transcription

1 Int'l Conf. Software Eng. Research and Practice SERP' Clone Detection Using Scope Trees M. Mohammed and J. Fawcett Department of Computer Science and Electrical Engineering, Syracuse University, Syracuse, USA Abstract - Code clones are exact or nearly exact matching code segments in software source code. Clones make software maintenance difficult. Identification and management of code clones is an important part of software maintenance. This paper proposes a clone detection system that uses a scope tree representation of the structure of source files, using several measures of similarity. The method can be used for detecting clones in C, C++, Java, and C#. An experimental clone detection tool is evaluated based on its analysis of OpenSSL and Notepad++. Using scopes makes the clones an effective guide for code restructuring. Our approach is also compared with other clone detection tools: CCFinder and Deckard. The results are encouraging both in terms of efficiency as well as detection accuracy. In addition, we expect our method to scale well for large systems based on its computational complexity and the fact that much of the analysis is readily implemented with concurrent processing of each file analyzed. Keywords: Clone Detection, Maintenance, Restructuring, Scope Tree, Token. 1. Introduction A code clone is a segment of source code which is the same or similar to another segment in the same or another file. If software has clones, maintenance becomes burdensome [4]. When a change is required for a code segment having corresponding clones in other parts of the source, the change may be needed in all corresponding parts. Therefore, detecting and managing code clones is an essential part of software maintenance. Code may be cloned for several reasons [5]. Quick fixes using copy-and-paste is the most common one. Code cloning has pros and cons [6]. There is extensive research on clone detection. Some of the tools discussed, such as CCFinder, detect clones using methods focused on code segment texts and miss modified but important clones [1]. Others use AST based approaches to detect relevant clones. The drawback of these is that they discourage use in software maintenance process as building the AST itself is a complex process, even using available compiler components, like LLVM. Also, the resulting clones may not be suitable for restructuring. We propose a clone detection method using scope trees, similar to, but significantly simpler than ASTs, that yields relevant clones in software source code, for multiple files, relatively efficiently. The approach builds scope trees for each file using a light weight parser with tokens stored in blocks for a given scope. Structural matches within a file and among files is found using a structural match algorithm by comparing scope trees. Once a structural match is detected, tokens for corresponding scopes are compared using string comparison for exact or near matchings. An edit distance algorithm [13] is also adapted to detect modified code. The rest of the paper is organized as follows. Part II gives background about clone detection and scope trees. The proposed clone detection method is presented in part III. Details of the major algorithms is provided in part IV. Part V gives information about the implementation of our analysis tool. Part VI describes results obtained by running the clone detection tool with example test source code, and two open source software system codes to examine clone detection capability and to explore refactoring opportunities. Part VII concludes with a summary of results and planned future work. Part VIII summarizes related clone detection work. 2. Background This part gives a brief overview of clone detection and scope trees. Part 2.1 discusses clones; the concept of scope trees and how they are used in this paper is discussed in the second part, Code clone basics There is no unique agreed upon single definition of code clone [4]. However, several clone types have been defined [2, 3, 4, 5]: Type 1(exact clones) - these are fragments of code which are identical except for variation in white space and comments. Type 2 (renamed/parameterized clones) fragments of code which are structurally/syntactically the same except for changes in identifiers, literals, types, layout and comments. Type 3 (near miss clones) fragments of code that are copied with further modifications such as statement insertions/deletions in addition to changes in identifiers, literals, types and layouts.

2 194 Int'l Conf. Software Eng. Research and Practice SERP'18 Type 4 (semantic clones) fragments of code which are ally similar without having text similarity. In this work, we will address efficient detection and management of all the clone types except for type 4. In the next section, we focus on the method we used for clone detection Scope trees A scope Tree is the representation of source code using a tree structure with each scope being a node in the tree. A scope is usually delimited by open and closed braces. Functions, if,, switch statements, loops, enums, classes, structs, and namespaces are all scopes. An example is shown in Fig. 1 for pseudo code described in Table 1, File 1. Table 1 - File 1 pseudocode. Fun( ) B0 if(..) B2 B3 B4 for(...) B5 if(..) B51 B6 similar to Macabe s cyclomatic complexity [10]. However, the computation and its purpose are different. 3. Proposed method of clone detection This section discusses our clone detection method. First, a general overview is given using block diagrams. The last step, clone detections, shown in the following diagram is explained in detail, in section Description of clone detection computation The proposed method uses scope trees to detect clones in software system source code. The process is illustrated in figure.2. The block diagram shows four major steps, discussed in the following except the last one which is discussed in part Tokenizer This step takes the path to a set of files to analyze and generates a stream of tokens for each file. The result is given to the next step, rule-based parser. B3, 0 Fig. 1. Example file,file 1, simplified source and scope tree representation. The source file, File1, is represented as scopes having blocks representing sequence of tokens which are in turn representations of statements in the source file. In the scope tree diagram, the blocks are stored in a list. The index indicates the place where the blocks are found relative to the child scopes. For instance, B0,0 means block B0 is located before all the child scopes whereas B4, 2 means B4 is found next to the second child scope. In addition, scope cyclomatic complexity, henceforth called cyclomatic complexity, is defined based on the scope tree hierarchy. A leaf node has a cyclomatic complexity of one. Internal nodes have cyclomatic complexity of the sum of the complexities of child nodes plus one. This complexity is Fig. 2. Scope tree-based clone detection block diagram Rule based parser Rules are specified to extract data from source code. It takes the tokens from the previous step and generates scopes such as namespaces, classes, s, conditions, loops and even just blocks separated by curly braces. See [11] for details Scope tree builder This step builds a scope tree based on the containment of one scope in another. The output of this stage is scope tree,

3 Int'l Conf. Software Eng. Research and Practice SERP' like figure 1, for each file which will be used to check structural similarity in the next stage. Algorithm 1 describes how a scope tree is built. Token block extraction is done also using the same algorithm. This algorithm scans tokens to check start and end of scope and acts accordingly. Algorithm 1 - Scope tree builder BuildScopeTree() root = CreateNode( file ) BuildScopeTree(root) BuildScopeTree(current_node) for each tok of tokenized file If (start of scope) scope_node = CreateScopeNode() current.stack.push_back(scope_node) if (end of scope) current.blocks.puch_back(block) current.stack.pop() push token to block. In addition, cyclomatic complexity of each node is computed by assigning the value 1 to leaf nodes and the sum of the cyclomatic complexities of the child nodes plus 1 to the internal nodes. To make the structure matching step efficient, nodes are ordered based on their cyclomatic complexity and placed in buckets. The maximum bucket is determined from the cyclomatic complexities of the root nodes. Nodes having the same cyclomatic complexity are stored in the same bucket. For example, the root node of File 1, in figure 1, is stored in bucket 6 as it has cyclomatic complexity of 6. Functions fun of File 1 is stored in bucket 5 as it has complexity of 5. Buckets may be combined to detect modified code at the structural level. There will be only one scope structure that spans all of the analyzed files. In the next part the clone detection step is discussed. 4. Clone detections This is the last step shown in Fig. 1.. It detects matches within a file or among different files in the source file. It is a two-stage process. First structurally similar trees are identified. The output of this stage is given to the exact or near exact match step. This stage uses a relatively precise step to detect the clones. The following algorithm handles both cases. Algorithm 2 Matching algorithm matchtrees(node1, node2, isexact) NodePairQueue.push(n1, n2) While (!NodePairQueue.empty()) Node_pair = NodePairQueue.front NodePairQueue.pop() if(!isexact) Match = matchnodes(node_pair.first, node_pair.second) if(match < matchthreshold) return 0 // Algorithm 3. nodematch = matchnodesed(node_pair.first, node_pair.second, noofnodetokens) totalnumoftokens = totalnumberoftokens + noofnodetokens numofmatchedtreetokens += nodematch for each children node1 and node2 pair of nodepair.first and nodepair.second NodePairQueue.push(node1, node2) if(!isexact) Return match if(totalnumoftokens == 0) Return 1.0 return (numofmatchedtreetokens / totalnumoftokens) 4.1. Structural matching At this stage scope trees having same cyclomatic complexity or difference of 1 or 2, are retrieved from their buckets for comparison. Similarity checking is done using different criteria such as number of blocks, number of children, number tokens, number of identifiers and type of node. These are parameters with values we can change before clone detection starts. Two trees are structurally similar if the corresponding nodes are similar Exact or near exact match At this stage the structurally similar nodes are filtered with additional matching criteria. The blocks have sequences of tokens. By setting a certain level of accuracy say 0.90 comparison is done between nodes of the structurally similar nodes. This approach can detect modified code. To detect modified code, we also use an edit distance algorithm applied

4 196 Int'l Conf. Software Eng. Research and Practice SERP'18 to list of tokens. Algorithm 3 describes the edit distancebased algorithm. Algorithm 3 Modified edit distance algorithm matchnodeed(node1, node2) for each block in node1 for each token in block tokenlist1.push_back(token) for each block in node2 for each token in block tokenlist2.push_back(token) // EditDistanceStrLst is edit distance // algorithm for list of strings. editdist = EditDistanceStrLst(tokenList1, tokenlist2) nooftokens = max(len(tokenlist1, tokenlist2)) approxmatch = nooftokens editdist return approxmatch, nooftokens 5. Implementation As a proof of concept, a tool has been implemented using the C++ programming language. The tokenizer and rule-based parser are general purpose modules developed for source code analysis and have been used in previous research and class room projects. Some tuning is made to fit this work. The other components, Scope builder and Clone detection are implemented for this research. 6. Results and discussion We have carried out experiments on test code prepared for clone detection purposes by copy-and-pasting and systematically modifying files and fragments of code. First, we used c source code, implementing quick sort, to detect clones using our tool and two other clone detection tools: CCFinder [1] and Deckard [15]. For real case studies, we used Notepad++ [12] and OpenSSL [14]. Our tool also successfully detects clones in benchmark code specified in [2] Test code for clone detection To evaluate the clone detection capability of our clone detection, and two other tools: CCFinder and Deckard, we prepared test code examples by modifying an implementation of the quick sort algorithm. The algorithm is stored in a file (qsort_.c []). Various modifications are done to this file. The important for clone detection is the partition. Most of the modifications, 1a2 to 1a9, are based on this ; and these are for level clone detection even though each is stored separately in its respective file. The rest, 0 and 1, are prepared for file level clone detection. The original partition from is replaced with a different implementation in 0 leaving the rest of the s as they are; whereas, in 1, a different algorithm, merge sort algorithm is implemented leaving only two small s, display and main the same. Here are the descriptions of each test file used for clone detection: i. qsort_.c () quick sort implementation. ii. partition_1a2.c (1a2)- copy-and-pasted partition from original () with only identifier changes including name and parameters. iii. partion_1a3.c (1a3) If block, line 6-9, is added to the original () partition. iv. partion_1a4.c (1a4) block, line 12-13, added to the original() partition. v. partition_1a5.c (1a5) several comments are added to the original() partition. vi. Partition_1a6.c (1a6) - If block, line 6-9, is added to 1a2 s part before the outer loop. vii. Partition_1a7.c (1a7) - condition, line 16-17, is added to 1a6's part. viii. Partition_1a8.c(1a8) - comments are added at several places to 1a7. ix. Partition_1a9.c (1a9) the empty statement in 1a8 is modified by adding two statements. x. Qsort (0) copy-pasted with a completely different partition. However, the rest of the s are the same. xi. `Merge-sort_.c (1) this is a different algorithm, merge sort. However, two of the s are the same: display and main. The changes made in 1a2 to 1a5 are relative to the original file; whereas, the changes in 1a6 to 1a9 are cumulative, with 1a9 modified the most. We ran CCFinder[1], Deckard[15], and our tool with the above test files as input. To compare the clones detected, refer to figure 3, that shows the distinct parts of the code that will be used in the clone detection result. The block code insertions are shown with gray blocks. It shows most of the partition modifications. The content is actually 1a9 s, which is a result of all the modifications listed in 1a2 to 1a9. One can use figure 3, to make sense of most of the clone detection result discussions. The last two files, 0 and 1, are not shown in this result. Please see the link in reference [16] for these and the individual files for 1a9. Table 2 reports the clones detected by the three tools. As can be seen in Table 2, all three tools detected the same clone for 1a2 vs, 1a3 vs, and 1a5 vs. They detected whole partition, outer loop and whole partition respectively.

5 Int'l Conf. Software Eng. Research and Practice SERP' size_t part (int * data, int left, int right) int i = left + 1, j = right; // Left item is selected as pivot. int pivot = data[left]; // This case is redundant. Function upper If (l == r && data[pivot] <= data[r]) return pivot; If block (i <= j) (pivot < data[j]) j--; if (j == left) return left; Fig 3. Modified partition. Upper // No effect. Added to test clone. swap(&data[j], &data[left]); swap(&data[j], &data[left]); Else block (i < right && pivot > data[i]) i++; if (i == j) break; // Swapped to strictly put items to the left // and right of pivot. if (i < j) swap(&data[i], &data[j]); Lower swap(&data[left], &data[j]); return j; Function lower However, 1a4 vs, where an empty block is added to the outer loop of the partition resulted in different results. CCFinder detected only the lower part of the inner loop; but, Deckard detected the whole as clone. Our tool is slightly different here. It detected the whole partition ; however, it also reported block as code. It should be noted that 1a2 to 1a5 are modification of the original partition ; and the clones detected are at the level or within the. At the file level, all the three tools reported all the s other than the partition as clone for 0 vs ; however, only our tool detected the small s, main and display in 1 vs as clones. File Pairs 1 1a2 vs 2 1a3 vs 3 1a4 vs 4 1a5 vs 5 1a6 vs 6 1a7 vs 7 1a8 vs 8 1a9 vs 9 0 vs 10 1 vs 11 1a6 vs 1a2 12 1a7 vs 1a6 13 1a8 vs 1a7 14 1a9 vs 1a8 Table 2. Test code clones Clone Detection by: CCFinder Deckard Our Tool whole While Lower Part but lower Lower part lower Only partition different Upper, lower Only partition different but but Only partition different None None display and main Upper part, lower Upper part, lower Lower, upper part but but The files 1a6 to 1a7, cumulative modifications starting from a2, are used in two different ways. Rows 11 to 14 in Table 3, like rows 1-4 evaluated the effect of immediate change on clone detection; but rows 5-8 evaluated effect of the cumulative change as compared with the original file in. For the former one, all three tools reported the same clone for 1a6 vs 1a2 and 1a9 vs 1a8. However, for 1a7 vs 1a6,

6 198 Int'l Conf. Software Eng. Research and Practice SERP'18 CCFinder detected lower loop and upper part of the as clone; Deckard reported the whole as clone. Our tool detected the whole reporting the as such. For 1a9 vs 1a8, both Deckard reported fragments of or reported. Our tool reported the outer loop as clone reporting the block as. For rows 5 8, our tool entirely reported outer loop as clone with block. Deckard reported the outer loop as clone except in the last case it reported the lower and the upper part of the outer loop as clone. CCFinder, on the other hand, reported part of the loop in all the cases except the first one, row 5, outer loop detection. All in all, all the three tools detected similar codes and codes with identifier changes in an equivalent way. The difference in detecting clones became significant when codes are modified systematically. Deckard tolerated modification of code, like the case of empty insertion; however, it reported only the similar fragments if the change was above a certain threshold as defined by similarity metric [15]. CCFinder, on the other hand reported only fragments if there is any change, other than identifier changes, inside a given scope. Our tool includes the code as part of the clone detection report. However, if the scope dominated, the similar scopes, as determined by mutation threshold and a similarity threshold like Deckard s, our tool reported only the similar scopes. Reporting the scope as part of the clone report is one of the contribution of our work OpenSSL clones We also run the three tools with OpenSSL source code [14] as input. OpenSSL is suitable for clone detection study as it has similar cryptographic algorithms and routines. It is a widely used open source software library. It has more than 400, 000 lines of code. Unlike the test code clones, discussed above, where the expected clones are known in advance, here we report the approximate number of clones detected by each tool; and a few sample clone pairs for discussion. In addition, the number of overlapping clones between our tool and Deckard is given to see if our approach detects different clones than Deckard s. Unfortunately, we could not find a report that we can parse from CCFinder like ours and Deckard s. As a result, CCFinder is not considered in this comparison. The following table, Table 3, shows the total number of clones, CLOC (clone lines of code), and the metrics used to detect the clones. Two major metrics are used to filter small clone codes threshold and similarity. For CCFinder and Deckard, we used 50 tokens, the default, as the minimum threshold; whereas for our tool we used 5 CLOC as the minimum threshold. The major reason that we used CLOC as our threshold is that we used two separate clone matching steps for clone detection the exact clone matching step does not contain the entire tokens. Deckard, in addition to tokens uses stride to merge small clones. Table 3. OpenSSL clones Clone Detection Tool Metrics CCFinder Deckard Our Tool Threshold 50 tokens 50 tokens with stride 5 lines of code of 2 Similarity N/A CLOC overlap N/A Total CLOC Our tool and Deckard used 0.9 as the clone similarity level. We defined similarity as the ratio between the matched tokens and the total number of tokens in the pair of nodes, as defined in Algorithm 2; and Deckard s definition of similarity is provided in [15]. Deckard and our tool detected almost a 10-fold increase in the number of total CLOC as compared with CCFinder s. It should be noted that total CLOC for CCFinder is generated from the tool itself, so we could not do a calculation similar to our tool s and Deckard s calculation. In the latter case, the sum of CLOC for each clone is aggregated, using a separate program, from clone reports generated by the tools. We also did a visual inspection of OpenSSL code with comparisons to the code report for each tool. Our tool detected 5% more clone than Deckard s. This is in part due to use of scope detecting clones as a result clones that can be below the threshold are detected along with the scope. Our tool and Deckard detected approximately 60% of overlapping clones. Because of the difference in the way we detect clones, this number may be higher from what is reported. However, we expect that there will be difference between the two tools. All the three tools detect exact matches or slightly modified code such as identifier changes. Deckard takes clone detection further by reporting significantly modified code. The similarity can span more than one the spanning possibly can be partial. Please refer to [16] for sample clone pairs that demonstrate this. Deckard is capable of reporting better clones than CCFinder, in terms of similarity, however letting it detect clones spread across different scopes, possibly partial ones, may not result in clones that may reasonably be used for tasks such as refactoring. Our tool detects clones extending over more than one block. However, the similarity is examined at

7 Int'l Conf. Software Eng. Research and Practice SERP' different levels. For each scope, at the level or lowerlevel blocks, a similarity level is computed. Based on this criteria clones that meet the overall clone similarity level are included in the clone report but significantly modified code ( scopes) are reported explicitly as part of each code clone pair. Figure 4 shows a clone code pair taken from our tool to demonstrate this concept. Even though part of the code is significantly modified, as measured by the threshold level, it is reported as scope in the clone pair report. if (!noout &&!cert) if(outformat == FORMAT_ASN1) i=i2d_ssl_session_bio(out,x); if (outformat == FORMAT_PEM) i=pem_write_bio_ssl_session(out,x); BIO_printf(bio_err,"bad output format specified for outfile\n"); goto end; if (!i) BIO_printf(bio_err,"unable to write SSL_SESSION\n"); goto end; if (!noout) if (outformat == FORMAT_ASN1) i=i2d_dhparams_bio(out,dh); if (outformat == FORMAT_PEM) i=pem_write_bio_dhparams(out,dh); BIO_printf(bio_err,"bad output format specified for outfile\n"); goto end; if (!i) BIO_printf(bio_err,"unable to write DH parameters\n"); ERR_print_errors(bio_err); goto end; Fig.4 Clone with scope. The two code pairs as whole are reported as clone pairs. The last if statements pairs, in gray, are similar but did not pass the threshold criteria for the given scope; therefore, they are reported as scope as part of the overall clone report. This could be used to refactor the similar part of the code as a and leaving the significantly modified part as it is. This concept will be further explored in an extended version of this paper. 7. Conclusion We proposed and implemented a novel clone detection system. It is like AST based clone detection, such as Deckard [15], in that it builds a tree like structure. However, our tool does not build a complete AST. It just extracts scope data and tokens needed for the clone detection, using only one node type. Most of the clones that we detect may be used for software restructuring purposes as we are using scopes as boundaries for the clones. It efficiently detects clones that are not detected by CCFinder such as clones due to systematic changes in code. It does not also suffer from reporting clones spanning partial scopes. In addition, we expect our tool, to scale well for large systems based on its computational complexity and the fact that much of the analysis is readily implemented with concurrent processing of each file analyzed. In the future, we want to make use of the detection of clones for restructuring. The scope can also be examined to study program correctness modelling. We expect to use software dependency visualization to show clone distribution to plan restructuring [17]. 8. Related work There are many published clone detection papers. A detailed survey is provided in [7]. Based on their detection algorithms, clone detections are grouped into four categories. These are normalized line of code, parameter string matching, AST based, and program dependence graph based. In the following, a brief description of each category is provided. A sample work is also given Normalized lines of code This method removes white spaces and comments to do direct comparison of text at the line level [8]. This has a quadratic algorithmic complexity to detect clones as every line of a code fragment is compared with every line of the second code fragment. Even though it can be applied to multi-language source code, clone detection counts are affected by slight changes of code or even merging or splitting of lines of code Parameterized string matching This method uses a sequence of token streams as the data structure for detecting clones. It ignores white spaces and comments as in the normalized lines of code approach. Identifiers and names are replaced by place holders. A suffix tree is used to find sub strings for partial comparison. The comparison is done by tokenizing the whole file [1][9]. AST based methods This method uses an abstract syntax tree for detecting clones. The comparison may be done on blocks (open brace

8 200 Int'l Conf. Software Eng. Research and Practice SERP'18 to close brace) or s. However, this approach needs the AST to be generated which is a complex process. This is similar to our approach, but our tool builds a light weight tree, that avoids this complex AST. Deckard [15] is the most common AST based clone detection tool. It generates vectors to represent nodes in AST tree. It uses the vectors to detect clones relatively efficiently. Our approach uses scope tree instead of AST to detect clones Program dependence graphs This method uses the program dependence graph (PDG) as the underlying data structure for clone detection. Unlike the other approaches, clone detection based on PDG is not affected by statement swapping in a fragment of code. However, since it uses sub-graph comparison, which is an NPhard problem, it may not scale well. Our approach uses cyclomatic complexity ordered sub-tree comparison which grows linearly with the nodes. Token comparison is done at the node level. However, the worst-case performance is quadratic with the token size. Practically the comparison may be efficient as the tokens stored in each node is small. From existing clone detection techniques, CCFinder[1], CP-Miner[9] and Deckard[15] are among the most prominent tools. CCFinder and CP-Miner are token based. Whereas, Deckard is AST based. However, either they are not suited for parallelization or have some issues of accuracy. Based on our analysis, Deckard s performance is better than the others. In this paper, a light weight parser [11] is used to build a scope tree for all the files being analyzed. It has some similarity with AST based clone detections such as Deckard [15]. However, it does not extract detailed information like the AST does, thereby avoiding significant complexity. 9. References [1] Toshihiro Kamiya, S.Kusumoto, and K.Inoue. CCFinder: A multilinguistic token-based code clone detection system for large scale source code. Transactions on Software Engineering, 8(7): ,2002. [2] S. Bellon, R. Koschke, G. Antoniol, J. Krinke, E. Merlo, Comparison and evaluation of clone detection tools, IEEE Transactions on Software Engineering 33 (9) (2007) [3] R. Koschke, Survey of Research on Software Clones, in Duplication, Redundancy, and Similarity in Software, Dagstuhl, Germany, [4] C.K. Roy, J.R. Cordy, A Survey on Software Clone Detection Research, Technical Report , Queen s University at Kingston Ontario, Canada, 2007, p [6] C.J. Kapser, M.W. Godfrey, Supporting the analysis of clones in software systems: a case study, Journal of Software Maintenance and Evolution: Research and Practice 18 (2) (2006) [7] Dhavleesh Rattan, Rajesh Bhatia, Maninder Singh, Software clone detection: A systematic review, Information and Software Technology, Volume 55, Issue 7, July 2013, Pages , ISSN [8] S. Ducasse, M. Rieger, and S. Demeyer, A language independent approach for detecting duplicated code, in Software Maintenance, (ICSM 99) Proceedings. IEEE International Conference on, 1999, pp [9] Z. Li, S. Lu, S. Myagmar, and Y. Zhou, CP-Miner: A Tool for Finding Copy-paste and Related Bugs in Operating System Code, in Proceedings of the 6th Conference on Symposium on Operating Systems Design & Implementation - Volume 6, Berkeley, CA, USA, 2004, pp [10] T. J. McCabe, A Complexity Measure, IEEE Transactions on Software Engineering, vol. SE-2, no. 4, pp , Dec [11] Light Weight Parser, retrieved from ser.htm, December 2016 [12] Notepad++, retrieved from September [13] S. Dasgupta, C. Papadimitriou and U. Vazirani, Algorithms, Mc Graw Hill, [14] OpenSSL, retrieved from September [15] L. Jiang, G. Misherghi, Z. Su, and S. Glondu. Deckard: Scalable and accurate tree-based detection of code clones, ICSE 07. [16] Support files, retrieved from Mohammed/CloneDetectionExamples/, April [17] M. Mohammed and James W. Fawcett, Package Dependency Visualization: Exploration and Rule Generation, The 23rd International Conference on Distributed Multimedia Systems, Visual Languages and Sentient Systems, 2017 [5] Cory J. Kapser, Toward an Understanding of Software Code Cloning as a Development Practice, PhD dissertation, University of Waterloo, 2009.