A Design Pattern Detection Tool for Code Reuse
Total Page:16
File Type:pdf, Size:1020Kb
DP-CORE: A Design Pattern Detection Tool for Code Reuse Themistoklis Diamantopoulos, Antonis Noutsos and Andreas Symeonidis Electrical and Computer Engineering Dept., Aristotle University of Thessaloniki, Thessaloniki, Greece [email protected], [email protected], [email protected] Keywords: Design Pattern Detection, Static Code Analysis, Reverse Engineering, Code Reuse. Abstract: In order to maintain, extend or reuse software projects one has to primarily understand what a system does and how well it does it. And, while in some cases information on system functionality exists, information covering the non-functional aspects is usually unavailable. Thus, one has to infer such knowledge by extracting design patterns directly from the source code. Several tools have been developed to identify design patterns, however most of them are limited to compilable and in most cases executable code, they rely on complex representations, and do not offer the developer any control over the detected patterns. In this paper we present DP-CORE, a design pattern detection tool that defines a highly descriptive representation to detect known and define custom patterns. DP-CORE is flexible, identifying exact and approximate pattern versions even in non-compilable code. Our analysis indicates that DP-CORE provides an efficient alternative to existing design pattern detection tools. 1 INTRODUCTION ecutable. As a result, developers cannot exploit the source code of other systems without first resolving Developers need to understand existing projects in or- their dependencies and executing them correctly. Sec- der to maintain, extend, or reuse them. However, un- ondly, pattern representations in most tools are not in- derstanding usually comes down to understanding the tuitive, thus resulting in black box systems that do not source code of a project, which is inherently difficult, allow the developer any control over the detected pat- especially when the original software architecture and terns. These tools also do not offer the ability to de- design information is unavailable. And, although sev- fine custom patterns. Finally, several DPD tools are eral tools extract information from source code, in not up-to-date, supporting only obsolete versions of cases where software projects lack proper documen- programming languages. tation, the process of understanding the intent and de- In this paper, we present DP-CORE, a Design Pat- sign of the source code requires a lot of effort. tern detection tool for COde REuse, which is designed The design decisions taken during software devel- in order to overcome the aforementioned issues. DP- opment concern the non-functional aspects of the sys- CORE uses a highly descriptive and complete repre- tem, and are usually documented in the form of de- sentation for source code elements based on UML. sign patterns. Design patterns provide reusable solu- Hence, the tool supports both the detection of sev- tions in the form of templates that developers can use eral well known patterns and the definition of custom to confront commonly occurring problems (Gamma patterns by the developer. DP-CORE is also quite et al., 1998). Inferring such non-functional knowl- flexible, matching not only strictly defined versions edge from source code typically requires extracting of patterns but also similar versions of patterns using these patterns. Lately, the problem of recovering de- wildcards. Furthermore, the detection of patterns in sign patterns from source code has attracted the atten- non-executable and even non-compilable source code tion of several researchers and has led to the devel- is fully supported, while DP-CORE also uses the lat- opment of several tools to detect patterns, known as est compiler technology to support detecting patterns Design Pattern Detection (DPD) tools. in current Java projects. Most of the tools are effective for detecting cer- The rest of this paper is organized as follows. Sec- tain types of design patterns. However, they fall short tion 2 provides background knowledge and reviews in several important aspects. At first, they require the current approaches for the detection of design patterns source code to be compilable, or in most cases ex- from source code. In Section 3, we present our DPD 160 Diamantopoulos T., Noutsos A. and Symeonidis A. DP-CORE: A Design Pattern Detection Tool for Code Reuse. DOI: 10.5220/0006223301600167 In Proceedings of the Sixth International Symposium on Business Modeling and Software Design (BMSD 2016), pages 160-167 ISBN: 978-989-758-190-8 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved DP-CORE: A Design Pattern Detection Tool for Code Reuse tool, focusing on the defined representation and the Several DPD tools in current literature employ methodology used to detect patterns, while its user in- static code analysis techniques to identify patterns. terface is presented in Section 4. Section 5 illustrates One of the first tools in this category is the DPD the usage of our tool using a case study and presents tool by Tsantalis et al. (2006), which extracts static our evaluation against the DPD tool PINOT (Shi and information about the software project including in- Olsson, 2006). Finally, Section 6 summarizes work heritance, method signatures, etc., and represents the done and provides useful insight for future research. project as a graph. Relationships among objects are represented using matrices, while the tool uses simi- larity algorithms to detect patterns. A slightly differ- 2 BACKGROUND AND RELATED ent approach is followed by Lucia et al. (2009) for the DPRE tool, which is implemented as an Eclipse plu- WORK gin. The tool constructs UML diagrams and uses vi- sual language parsing techniques to identify patterns. Software design patterns were first proposed in 1987 PINOT, designed by Shi and Olsson (2006), is an- (Beck and Cunningham, 1987), shortly after the Ob- other popular tool that combines both structural and ject Oriented Programming (OOP) paradigm began behavioral analysis. It extracts information from the gaining momentum. One of the first attempts to for- AST of the source code, and detects patterns using malize the use of design patterns was a book pub- structural and behavioral (data flow) template match- lished in 1998 by Gamma, Vlissides, Johnson, and ing. Several tools also use machine learning methods. Helm (1998), who became known as the Gang of Four Arcelli and Christina (2007) developed MARPLE, an (GoF). The GoF defined 23 patterns, which are cate- Eclipse plugin that uses neural networks to classify gorized in creational, structural, and behavioral pat- source code representations to behavioral patterns. terns. Creational patterns abstract the process of cre- The authors also extended their work, introducing ating objects, while structural patterns combine ob- JADEPT (Arcelli et al., 2008), a tool that represents jects to form larger structures and behavioral patterns patterns as combinations of rules. describe the communication between objects. Current literature in DPD methods is quite broad. FUJABA (Nickel et al., 2000) is another Eclipse According to Dong et al. (2009), the defining proper- plugin, which, among other functions, supports de- ties of a DPD tool are (a) the type of input, which can tecting design patterns. The tool defines patterns us- be source code, UML diagrams or any other repre- ing UML class diagrams and expresses their behav- sentation, (b) the intermediate representation, which ioral aspects using story-diagrams, i.e. a combina- includes all structural formats used by the DPD tool, tion of activity and interaction diagrams. Metamodel- e.g. Abstract Syntax Tree (AST), Call Dependency based approaches are also popular. Gueh´ eneuc´ and Graph (CDG), (c) the type of analysis, performed ei- Antoniol (2008) introduced DeMIMA, which extracts ther only on source code or also on the dynamic ex- classes, methods, etc. from source code to instanti- ecution trace, and (d) the type of recognition, which ate a metamodel that is used to specify objects and can be either exact or approximate. Although all of their relationships. The tool employs constraint pro- the above properties are important, the main classify- gramming techniques to identify patterns. A similar ing feature of DPD techniques is the type of analysis. approach is followed by Ptidej, designed by Kaczor Following a classification similar to that of current et al. (2006), which uses a constraints solver to detect literature (Rasool and Streitferdt, 2011; Dong et al., sets of objects that are similar to design patterns. 2007b), we distinguish among structural analysis, be- Another notable tool is D-CUBED, by Stencel and havioral analysis, and semantic analysis techniques. Wegrzynowicz (2008), which formulates design pat- Structural analysis approaches detect patterns us- terns in first order logic and inserts source code into a ing information extracted from inter-class relation- database where patterns can be identified via queries. ships (e.g. class inheritance, associations, etc.), thus Finally, DP-Miner by Dong et al. (2007a) is another they are particularly efficient for identifying cre- quite interesting tool that also uses semantics to dis- ational and structural patterns. By contrast, behav- tinguish among certain patterns that may have similar ioral analysis approaches employ dynamic program structural and behavioral aspects. The tool represents analysis, using runtime information to distinguish source code entities and relationships