1 / 23

Feasibility Study

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

duy
Download Presentation

Feasibility Study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Feasibility Study Cross Language Clone Analysis Team 2

  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

  3. Our Team • Allen Tucker • Patricia Bradford • Greg Rogers • Brian Bentley • Ashley Chafin

  4. Task Summary • Dr. Etzkorn and Dr. Kraft, our customers, have requested 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. • Key points: • The user interface is very important. • Easy comparisons of clones are important. • Good visualization of clones is important. • You will pay attention to sub-clones in this analysis. • The emphasis here will be on clone detection for large bodies of code.

  5. Introduction • Software Clones: • 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.

  6. Introduction (cont.) • Simple Example

  7. Introduction (cont.) • How clones are created: • Copy and paste programming, in which a section of code is copied "because it works". In most cases this operation involves slight modifications in the cloned code such as renaming variables or inserting/deleting code. • Functionality that is very similar to that in another part of a program is required and a developer independently writes code that is very similar to what exists elsewhere. • Plagiarism, where code is simply copied without permission or attribution.

  8. Introduction(cont.) • Problems associated with duplicate code: • Code bulk affects comprehension: Code duplication frequently creates long, repeated sections of code that differ in only a few lines or characters. The length of such routines can make it difficult to quickly understand them. • Purpose masking: The repetition of largely identical code sections can conceal how they differ from one another, and therefore, what the specific purpose of each code section is. Often, the only difference is in a parameter value. • Update anomalies: Duplicate code contradicts a fundamental principle of database theory that applies here: Avoid redundancy. Non-observance incurs update anomalies, which increase maintenance costs, in that any 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, and for example bugs thought to be fixed may persist in duplicated locations for months or years.

  9. Description of 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

  10. Task Understanding - Patricia • Chart input/output • Bullets with workflow

  11. Identification of User Benefits • Code implementing a cross-cutting concern is often spread over many different parts of an application. Identifying such code automatically greatly improves both the maintainability and the evolvability of the application. • It allows the developer to more easily find the places in the code that must change when the concern changes, and thus makes such changes less time consuming and less prone to errors. • It allows a developer to refactor the code, so that it uses modern and more advanced abstraction mechanisms, thereby restoring its modularity.

  12. Identification of User Benefits • <insert name> is a clone detection software suite the 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 • Run as a stand-alone application • Run as a plug-in to other applications • Run as a backend service

  13. Identification of User Benefits • Extendible • Ability to add new features • Additional software languages • New algorithms • Provides spatial relationships across varying code bases to help manage clones • Persists clones for easy retrieval • Aids developer to help find places in the code that must be changed when the concern changes • Helps keep software maintainable

  14. Potential Markets • Modularity is a key aspect in today’s software world. • A common goal is to divide software into a separation of concerns to help meet such software quality attributes as maintainability, understandability, 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, but a very important need to help maintenance code.

  15. Potential Markets (cont.) • Could be the perfect tool for large modular code basis • Detect code that is a candidate for modularity • Uses clone detection to help identify code that meets criteria for modularity • Track and manage crosscuts among all modular components • Helps maintenance crosscuts • Identify areas that lack needed crosscutting concerns • Could be configured to run with Configuration Management software • As part of continuous integration, could 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

  16. Human Factors • Designing to meet user needs • User center approach • Need for an intuitive user interface • Clone Visualization techniques

  17. 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.

  18. 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

  19. 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.

  20. 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.

  21. Path Forward • Begin user story development (initial requirements) • Starting spikes (C# and VB parsers)

  22. Proposed Schedule - Allen • Bi-weekly presentations • Meetings

  23. References • http://www.extremeprogramming.org/

More Related