The identification of design patterns as part of the reengineering process can convey important information to the designer. However, existing pattern detection methodologies generally have problems in dealing with one or more of the following issues: Identification of modified pattern versions, search space explosion for large systems and extensibility to novel patterns. In this paper, a design pattern detection methodology is proposed that is based on similarity scoring between graph vertices. Due to the nature of the underlying graph algorithm, this approach has the ability to also recognize patterns that are modified from their standard representation. Moreover, the approach exploits the fact that patterns reside in one or more inheritance hierarchies, reducing the size of the graphs to which the algorithm is applied. Finally, the algorithm does not rely on any pattern-specific heuristic, facilitating the extension to novel design structures. Evaluation on three open-source projects demonstrated the accuracy and the efficiency of the proposed method.

In this paper we evaluate logic code analysis and transformation frameworks for their suitability as basic infrastructures for fast detection and extraction of (crosscutting) concerns. Using design patterns as example concerns, we identify desirable properties that an infrastructure should fulfill. We then report our initial results of evaluating candidate systems with respect to these properties. We show how high precision design pattern detectors can be easily formulated as predicates that are evaluated in mere seconds even on the sources of large software systems, such as the Eclipse IDE. Although details still remain to be analyzed further, our current results suggest that the pair JTransformer & CTC is a good candidate for a general infrastructure, combining very good querying performance, scalability and short turnaround times with a seamless integration of querying and transformation capabilities.

A design pattern abstracts a reusable object-oriented design that solves a common recurring design problem in a particular context [14]. An object-oriented design describes the roles, responsibilities, and collaboration of participating classes and instances. Every design pattern has its own unique intent. By finding design patterns from source, we can bring program understanding to a higher level by revealing the architectural design of a system.

A design pattern is realized in various forms depending on the context of the applications. There has been intensive research on detecting pattern instances in models and in implementations. However, little work addresses variations of pattern realization. This paper describes an approach for evaluating conformance of pattern variations. This approach uses a divide-and-conquer strategy to evaluate the structural conformance of a UML class diagram to the solution of a design pattern. A design pattern is specified in an extension of the UML that defines the pattern in terms of roles. To demonstrate the approach, we use the Visitor pattern and two case studies of a price calculator and a word processor. We also present a prototype tool that supports the approach.

Abstract not found

Abstract — Software “Design Patterns ” seek to package proven solutions to design problems in a form that makes it possible to find, adapt and reuse them. A common claim is that a design based on properly applied patterns will have fewer defects than more ad hoc solutions. This case study analyzes the weekly evolution and maintenance of a large commercial product (C++, 500 000 LOC) over three years, comparing defect rates for classes that participated in selected Design Patterns to the code at large. We found that there are significant differences in defect rates among the Patterns, ranging from 63 % to 154 % of the average rate. We developed a new set of tools able to extract design pattern information at a rate 3×10 6 lines of code per hour, with relatively high precision. Based on a qualitative analysis of the code and the nature of the Patterns, we conclude that the Observer and Singleton patterns tend to be used in complex parts, and so can serve as indicators of code that requires special attention. Conversely, code designed with the Factory pattern is less complex or less central, and consequently has lower defect rates. Template Method was used in both simple and complex situations, leading to no clear tendency. Index Terms — design patterns, defects, defect frequency, industrial code, case study I.

A fuzzy matching approach for design pattern mining