The goal of this project is to enhance the identification of code duplication which can result in high cost reductions for a minimal price.

Transcription

1 Code Duplication New Proposal Dolores Zage, Wayne Zage Ball State University June 1, 2017 July 31, 2018 Long Term Goals The goal of this project is to enhance the identification of code duplication which can result in high cost reductions for a minimal price. Background for Long Term Goals Code duplication (or clones) causes an increase in software size and, sooner or later, every supplementary line of code enters the maintenance process, thereby increasing time and cost for an organization. Studies on code duplication percentages range from 15% to 25%, which lends to the fact that the embedded industry is one of the principal candidates for improvement. Very often the modification is only performed one instance at a time and developers are not aware of the existence of the other instances. Routinely, the full resolution of a bug fix occurs only after several costly implementation-test iterations. A common occurrence in commercial software systems, code duplication (or clones) can adversely impact the development and stability of software engineering projects, and multiple studies have confirmed this duplicitous nature [JARZ10]. Clones can also be introduced unintentionally or intentionally through independent development efforts. Clones may be intentionally created to improve program reliability or development speed. The same functionality may be intentionally duplicated to minimize dependencies to deliver individual control. On the other hand, the process of applying design patterns (e.g., pattern-driven development on component platforms such as JEE and.net) increases the possibility of unintentional cloning. A survey of clone research by Koschke lists many other root causes for software clones [KOSC07]. A clone is a segment of code possessing different types of similarity in text, lexical or syntactical structure, a pattern or semantics. Previous investigations including our own indicate that between 7% and 40% of a system consists of clones. Many of these figures are purely from program-text redundancy arising through the common activity in software development of reusing code sections through copying and pasting. Identical code fragments varying only in layout and comments are labeled as type-1 clones. Code can be used as is or slightly altered to fit a purpose. Code containing lexically identical fragments except for variations in identifiers, literals and types are labeled as type-2 clones. Type-3 clones occur when code statements have been added, removed or modified in segments. Type-4 clones, the semantic clones, have similar semantics but different implementations in code and are the most difficult type of clone to detect [RATT13]. As the suffix number used for the designation of the clone type increases, the process of clone identification also becomes more difficult. Type-1 and Type-2 clones can be detected by many of the current tools. There are a handful of tools that claim to detect Type-3 clones. A study by Tiarks reports that the type-3 clone detectors only detected 25% of the clones accepted by human oracle [TIAR10]. Identifying the distance between near-miss clones is not available and very few tools can detect all of the Type-3 clones. Type-4 clones remain mainly undetectable [SHEN16]. Two other basic types of clones have been added to the clone taxonomy: model-based and structural. Since clones are present in higher-level languages, it is not surprising that clones

2 exist in other development products such as UML models. Structural clones compare the patterns of interrelated classes emerging from the design. A poor design with clones will result in rework, slower development productivity and a decrease in the software s future extendibility. These consequences indicate the necessity for continuous assessment of the design, including tracking clones throughout the software lifecycle. Identifying design clones and tracking them through implementation offers valuable insights into their behavior and the consequential development actions. Of all the currently identified basic clone types, type-4, model-based and structural have been the subject of very little previous research. Why is there a growing interest in clones or code duplication? Several studies have shown that redundancy increases the risk of update anomalies and increased maintenance effort. For example, if an error is detected in a code fragment, all fragments similar to it should be checked for the same error. Duplicated fragments can also significantly increase the work to be done when enhancing or adapting code. Kent Beck states that programmers read more code than they write [McCR15]. When cloning is intentional it can be useful, such as in reuse or in the presence of an aspect. Clone detection can find shared and common features in software product lines. It can also assist in plagiarism detection, copyright infringement, software evolution analysis, virus detection and bug detection, making it an important and valuable part of software analysis [RATT13]. Clones are defined based on their granularity which defines the boundary of comparison. Granularity can be fixed as in a file, function and class or free such as the number or statements or tokens. Selecting an appropriate granularity is important. Segments that are too small are of little pragmatic significance, while too large is unlikely to be reused. The granularity chosen should exhibit characteristics of being useful in refactoring and maintenance. Approaches to identifying clones are an active research topic. Most techniques involve comparison of the identified artifact expressed as direct or abstracted structures or measures. The distance between each clone comparison can range from exact to various degrees of precision. Each technique holds both benefits and drawbacks in identifying exact copies, syntactically identical copies and copies with modifications. The metrics-identified clones are rated as the best choice in identifying all types of clones and can scale up for evaluating large systems [KOSC07]. Several researchers have noted that clone detection techniques can be improved through hybrid methods [SHEN16]. Our Previous Research: We have created an ordered 3-tuple distance metric for identifying clones that can identify Type-3 and Type-4 clones not previously identified by other tools. This advancement will support developers in clone tracking, thus avoiding the problems caused by clones. Breaking down information access barriers to code, such as identifying and tracking clones, can save organizations millions of wasted dollars each year and help refocus development on strategically significant opportunities. A study by Chanchal, Cordy, and Koschke compared the detection and classification adequacy of 42 clone detecting tools. For the study set, 16 different code clones were divided into 4 scenarios. Most of the tools performed well with three of the scenarios and the majority failed on one scenario. The failed scenario was based on the code contained in Figure 1. Figure 1: Source Basis for Clones 2

3 Four clones were created from the source code in Figure 1 and are displayed in Table 1. Table 1: Clones types created from code in Figure 1 Thirty of the 42 tools could not detect Table 1 clones and these tools included some of the most popular clone detection tools. The other remaining 12 clone detection tools only detected a partial set of Table 1 clones. Table 1 clones also were used in other more recent studies [SHEN16] producing similar results. Thus, Table 1 s code initially was used to validate our method of calculating a naming, sequence and usage distance to identify clones and their respective type. This approach proved to be successful. The type of clone can be distinguished by using the values of the three distance metrics. A pair of blocks is a Type-1 clone if all three metrics are zero. A pair of blocks would be a Type-2 clone if the sequence and usage metrics are zero and the naming metric is greater than zero. If the usage metric is greater than zero and less than the threshold (the maximum distance defined by the user), then it is a Type-3 clone. If the sequence metric returns a number greater than zero, the pair of blocks is a possible Type-4 clone. For a Type-4 clone, user feedback is required to determine if the pair is actually a clone. Table 2 presents the possible outcomes of the 3 metrics and the resulting possible clone types. Table 2: Clone types determined by Naming, Usage and Sequence Metrics Currently, there is no tool capable of discovering all kinds of Type-4 clones. Using the distance metrics improves the process of finding Type-4s by highlighting all the possible Type-4 clones and requires the user s feedback to determine if they are actual clones. In our Secure Coding Project, the Java code of each file is transformed into a specific xml file using a research tool called the Design Metrics Analyzer (DMA). From this xml format we collect and calculate 114 Java primitive and composite metrics for each method and class. One class or method is a metric clone of another if both possess exactly the same values for all of the 3

4 metrics considered. As part of the analysis, each unique java tag type from the xml project files is totaled. Since these tags take into account the various structures of the program, they are a more precise representation of content. Also the distribution of the individual tags can be used to calibrate different types of programs. The xml tags provide a static internal view of each module. The metrics include such information as fan-in, fan-out, data-in and data-out, providing a static but external view of each module. Together, the xml tags and the metrics can provide a powerful technique to identify a wider spectrum of clones. Both the Code Duplication proposal and the Secure Coding project use metrics as the basis for identification of duplication and insecure patterns. Some metrics and their subsequent values could be dependent on format manipulation, such as lines of code. Other metrics do not impact the semantics but are useful to collect such as the number of comments. As we search for duplication and matching patterns in the code, it could prove useful to determine how each technique provides additional or complementary information to enhance the identification process by either confirming the result or narrowing the cases that require user feedback such as in the case of a Type 4 clone. Intermediate Term Objectives Retest the three distance metrics on an existing Java code base attempting to achieve high precision and recall. A good technique detects fewer false positives, which means high precision. A good technique should also detect most or all of the duplicated code in a system which means high recall. Calculate the three distance metrics on the OWASP data determining the precision and recall of these data. Analyze the overlap of the identified metric clones to the distance metrics Naming, Usage and Sequence. Determine the relationship of the two techniques to support achieving either higher precision, higher recall or both. Schedule of Major Steps: Identify an existing database of clone types and compute the detection and classification type using the three distance metrics. Calculate the precision and recall on the database. Precision and recall are the two most common metrics used to measure the quality of a clone finding program. Repeat using the secure coding metric clone approach and determine the relationship between metric clones and distance metrics. Many believe that hybrid methods can improve results. Determine optimal granularity. Clones reported as clone classes are more useful than clone pairs. Finding clone classes reduces the number of comparisons and can determine the impact of slight changes on class. Outcome of another project, reported in S 2 ERC Final Report, Before and After Project, Design Metric Analysis of P3 highlighted the differences between entire Java classes [ZAGE09]. Dependencies: Our analysis will be on Java systems and some of the insights gained may only reflect these types of systems. Major Risks: Tools to assist in analysis require significant effort. Researchers have found it difficult to detect semantic clones (type-4). The functional equivalence problem is undecidable in general. Budget: PI support is requested to conduct the data collection and analysis. Total request is $66,057. 4

5 Staffing: Wayne Zage, Dolores Zage, principal investigators Category of Current Stage: Preliminary work and setup have begun. Contacts with Affiliates: Through conversations with affiliates about the Secure Coding project, we have been able to identify the importance of identifying clones and their types. Publications and Research Products: 1. Status Reports on major steps. 2. Analysis of the technique to calculate the three distance measures. 3. Rudimentary Java clone classifier. References: [CHAN09] Chanchal K., Roy, James R. Cordy, and Rainer Koschke, Comparison and evaluation of code clone detection techniques and tools: A qualitative approach, Science of Computer Programming, Volume 74 (2009), no. 7, [JARZ10] Jarzabek, S., and Y. Xue, Are Clones Harmful for Maintenance?, IWSC 10, May 8, 2010, Cape Town, South Africa, Proceedings of the 4 th International Workshop on Software Clones, ACM, New York, NY. [KOSC07] Koschke, R., Survey of research on software clones., Duplication, Redundancy, and Similarity in Software, number 06301, Dagstuhl Seminar Proceedings, Dagstuhl, Germany, [McCR15] McCreary, J. Patterns, Code Smells and the Pragmatic Programmer, Slideshare.net, May 2015, Accessed on May 10, [RATT13] Rattan, D, R. Bhatia and M. Singh, Software clone detection: A systematic review, Information and Technology Journal, Volume 55, Issue 7, Pages , July 2013, Elsevier Publication. [SHEN16] Sheneamer, A. and J. Kalita, A Survey of Software Clone Detection Techniques, International Journal of Computer Applications, Volume 137-No 10, March 2016, Accessed May pdf [TIAR10] Tiarks, R., R. Koschke, R. Falke, An extended assessment of type-3 clones as detected by state-of-the-art-tools, Software Quality Journal, : Published online November Accessed May 10, [ZAGE09] Before and After Project, Design Metric Analysis of P3, S 2 ERC Final Report. Copies made available upon request. 5