410 likes | 733 Views
Feasibility Study. Cross Language Clone Analysis Team 2. Agenda (Needs to be fixed once slides have been set). Team Introduction Task Summary Introduction Scope of Work Description of Related Research Identification of User Benefits Potential Markets Potential Competition
E N D
Feasibility Study Cross Language Clone Analysis Team 2
Agenda (Needs to be fixed once slides have been set) • Team Introduction • Task Summary • Introduction • Scope of Work • Description of Related Research • Identification of User Benefits • Potential Markets • Potential Competition • Human Factors • Project and Development Issues • Intellectual Property • Risk Analysis • Project Scale-Down Factors • Conclusion/Next Steps
Our Team • Allen Tucker • Patricia Bradford • Greg Rogers • Brian Bentley • Ashley Chafin
Task Summary • Our Customers: Dr. Etzkorn and Dr. Kraft • Customer Request: • A tool that will abstract programs in C++, C#, Java, and (Python or VB) to the Dagstuhl Middle Metamodel, Microsoft CodeDOM or something similar, and detect cross-language clones. • Areas to Note: • the user interface • easy comparisons of clones • visualization of clones • sub-clones • clone detection for large bodies of code
Introduction • Software Clones: (Definitions from Wikipedia) • Duplicate code: a sequence of source code that occurs more than once, either within a program or across different programs owned or maintained by the same entity. • Clones: sequences of duplicate code. • “Clones are segments of code that are similar according to some definition of similarity.” —Ira Baxter, 2002
Introduction (cont.) • Simple Example
Introduction (cont.) • 3 Types of Clones: • Type 1: an exact copy without modifications (except for whitespace and comments). • Type 2: a syntactically identical copy • only variable, type, or function identifiers have been changed. • Type 3: a copy with further modifications • statements have been changed, added, or removed.
Introduction (cont.) • How clones are created: • copy and paste programming • similar functionality, similar code • plagiarism
Introduction(cont.) • A few of the problems associated with clones: • Code bulk affects comprehension • Large redundant code sections causes longer comprehension times or no comprehension at all. • Purpose masking • Can hide differences between code sections. • Can hide the specific purpose of each code section. • Update anomalies • A modification to a redundant piece of code must be made for each duplicate separately. • At best, coding and testing time are multiplied by the number of duplications. • At worst, some locations may be missed.
Introduction (cont.) • Per our task, in order to find clones across different programming languages, we will have to first convert the code from each language over to a language independent object model. • Some Language Independent Object Models: • Dagstuhl Middle Metamodel (DMM) • Microsoft CodeDOM • Both of these models provide a language independent object model for representing the structure of source code.
Related Research • Detecting clones across multiple programming languages is on the cutting edge of research. • A preliminary version of this was done by Dr. Kraft and his students for C# and VB. • They compared the Mono C# parser (written in C#) to the Mono VB parser (written in VB). • Publication: • Nicholas A. Kraft, Brandon W. Bonds, Randy K. Smith: Cross-language Clone Detection. SEKE 2008: 54-59
Task Understanding • Three Step Process • Step 1 Code Translation • Step 2 Clone Detection • Step 3 Visualization Common Model Translator Source Files Detected Clones Inspector Common Model Clone Visualization UI Detected Clones
Task Understanding (cont.) • Step 1: Code Translation • C#, C++, Java, VB (or Python) • CodeDOM • Step 2: Clone Detection • Leverage current clone detection techniques and research • Step 3: Clone Visualization • Need for an intuitive user interface
User Benefits • Clone detection software suite that identifies, tracks, and manages software clones • Multi-language support • C++, C#, Java and Python • Provides complete coverage for large bodies of code • Configurable for multi-application support • stand-alone • plug-in • backend service
User Benefits (cont.) • Extendible • Provides spatial relationships across varying code bases to help manage clones • Aids developer to help find places in the code that must be changed when the concern changes • Persists clones for easy retrieval • Helps keep software maintainable
Potential Markets • Modularity is a key aspect in today’s software world. • Divide software into a separation of concerns • Software quality attributes as maintainability, reusability, testability, reliability and correctness. • But not all code is modular. • Crosscutting concerns are functionality that is inherently not modular and is spread throughout many modules • Example: logging • Identifying crosscutting concerns is an error-prone and time consuming task • Very important need to help maintenance code
Potential Markets (cont.) • Could be the perfect tool for large modular code basis • Detect code that is a candidate for modularity • Track and manage crosscuts among all modular components • Could be configured to run with Configuration Management software • Continuously scan code base to manage software clones • Integrate with build scripts to generate clone reports • Integrate with bug tracking software to help identify related bugs
Market Competition • Currently no other products that provide our proposed functionality
Human Factors • Designing to meet user needs • User center approach • Need for an intuitive user interface • Clone Visualization techniques
Intellectual Property • The University of Alabama in Huntsville would own and manage any and all intellectual property associated with the research and developmental artifacts of this project.
Project and Development Issues • Fast, Good, and Cheap…choose two. • Fast…time required to deliver products • Good…quality of product • Cheap…cost of designing and building
Risk Analysis • Complexity of problem proves more difficult than initial estimates. • Technology to be applied is neither well-established or has yet to be developed. • Unable to complete defined project scope within schedule. • Volatile user requirements leading to redefinition of project objectives.
Project Scale-Down Factors • Our initial approach…maximize existing open sourced developed items in order to reduce project timeline. • Instability in harvested projects. • Lack of support…documentation, forums, etc. • Disjoint projects code bases. • Non-existing code bases to harvest from.
Path Forward • Begin user story development (initial requirements) • Release Planning • Starting spikes (C# and VB parsers)
References • http://www.extremeprogramming.org/ • http://www.15seconds.com/issue/020917.htm • www.site.uottawa.ca/~tcl/presentations/DMMateM2003.ppt