Feasibility Study

1. Feasibility Study Cross-language Clone Analysis Team 2

2. Agenda • Our Team • Our Task • Introduction and Scope of Work • Background • Description of Related Research • Identification of User Benefits • Potential Markets for Project • Potential Competition • Potential Human Factors • Potential 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. Our Task • 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 if 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 and Scope of Work

6. Background • 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. • “Clones are segments of code that are similar according to some definition of similarity.” —Ira Baxter, 2002 • Simple example:

7. Background (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.

8. Background (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.

9. Background (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.

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

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. Potential Markets for Project • Who would buy this? Where are they? How many of them are there? Would they buy it or lease it? Etc etc

13. Potential Competition • Who else is out there? Have you looked at their patent applications? Don’t just consider the same technology solution – is anyone doing the same as you using a completely different technology?

14. Potential Human Factors • What are the usability requirements of your product or service? What skills do the operatives require? Can your manual be translated into Japanese/Chinese if required?

15. Potential Project and Development Issues • What is the potential timeline for the project? Are we trying to do something easy or of great difficulty? Do we have the resources for this?

16. Intellectual Property • Have we got patents, can we get them, and what patents do the competition have?

17. Risk Analysis • What are the things that would cause us to stop the project? • (Competition from Microsoft? Failed toxicity test?)

18. Project Scale-Down Factors • What are the things that would cause us to scale-down the project? (e.g. Treatment only works with type 1 not type 2 diabetics? Unavailability of key staff?)

19. Conclusion/Next Steps • List some further work you'd like to see carried out on this project before you'd make your final investment decision • List the 4-5 things you’d most worry about if it was your own money going into the project!