A practical pattern recovery approach based on both structural and behavioral analysis

Abstract

While the merit of using design patterns is clear for forward engineering, we could also benefit from design pattern recovery in program understanding and reverse engineering. In this paper, we present a practical approach to enlarge the recoverable scope and improve precision ratio of pattern recovery. To specify both structural aspect and behavioral aspect of design patterns, we introduce traditional predicate logic combined with Allen's interval-based temporal logic as our theory foundation. The formal specifications could be conveniently converted into Prolog representations to support pattern recovery. To illustrate how to specify and recover design patterns in our approach, we take one example for each category of design patterns. Moreover, we give a taxonomy of design patterns based on the analysis in our approach to show its applicable scope. To validate our approach, we have developed a tool named PRAssistor and analyzed two well-known open source frameworks. The experiment results show that most of the patterns addressed in our taxonomy have been recovered. Besides larger recoverable scope, the recovery precision of our approach is much higher than others. Furthermore, we consider that our approach and tool could be promisingly extended to support “Debug at Design Level” and “Pattern-Driven Refactoring”.

Introduction

As an emergent technology, design pattern has received more and more attention from researchers and practitioners. A pattern is a recurring solution to a common problem in a given context and system of forces (Gamma et al., 1994). Patterns help us document design decisions and rationale, reuse wisdom and experience of master practitioners, and form a shared vocabulary for problem-solving discussion.

While the merit of using design patterns is clear for forward engineering, we could also benefit from design pattern recovery in program understanding and reverse engineering. When people work with existing code written by somebody else, it can be an enormous task to reengineer an intended architecture. Software documentation is often not up-to-date or even nonexistent, and key developers may have left the project. The most accurate and complete source of information is the source code, but there might be hundreds of files. Traditional Computer Aided Software Environment (CASE) tools, such as Rational Rose, only provide limited reverse facility to present simple visualization based on class diagrams, while the run time behaviors of the system and high level blocks of collaboration among class instances could not be captured. Design patterns are micro-architectures and high level building blocks. So recovery of pattern instances in existed systems could improve the understanding and maintainability of them, because larger chunks could be understood as a whole.

Some literatures have addressed the recovery of design patterns. However, the recoverable patterns of these approaches are very limited, and most of these patterns belong to structural category (Antoniol et al., 2001; Brown, 1996; Kramer and Prechelt, 1996). Typically, their approaches would produce many false positives. Some researchers have tried to detect more pattern instances rather than approaches strictly relying on the pattern structures (Keller et al., 1999; Niere et al., 2002; Seemann and von Gudenberg, 1998). However, their works are based on the analysis of source code files, while detecting and deciphering interactions of objects in the source code is not easy: polymorphism makes it difficult to determine which method is actually executed at run time, and inheritance means that each object in a running system exhibits such behavior as defined not only in its class, but also in each of its superclass.

It is generally accepted that coherent specifications warrant the recovery of underlying constructs, elementary building blocks, and repeating abstractions. Some researchers have tried to use formal method to specify design patterns (Eden et al., 1997; Eden, 2001; Florijn et al., 1997; Lauder and Kent, 1998; Smith and Stotts, 2002). However, their abstractions are difficult for average designers to work with. Moreover, they are not well catered for pattern recovery.

In this paper, we present an approach based on both structural and behavioral analysis to enlarge the recoverable scope and improve precision ratio of pattern recovery. In Section 2, we introduce the structural and behavioral constructs, which are the foundation of our pattern specification. Some of these constructs are borrowed from UML (Booch et al., 1999; OMG, 2003). While our focus is on supporting pattern recovery, we only consider constructs which, we think, are relevant and acquirable in the recovery process. Moreover, we introduce Allen's interval-based temporal and Hrycej's Temporal Prolog to characterize the temporal aspect of behaviors. In Section 3, we take Singleton pattern, Composite pattern, and Visitor pattern as examples to illustrate how to specify design pattern to support recovery of different category of design patterns. In addition, we give a taxonomy of design pattern's implementation schemas based on the analysis in our approach. In Section 4, we present the tool named PRAssistor, which has been developed in terms of the rationale of our approach. In the implementation of this tool, we have applied some techniques, such as pre-candidates, participants filter, sorting clauses, to reduce the time consumption of pattern recovery. We also use this tool to analysis two well-known open source frameworks to evaluate our approach. In Section 5, we describe the promising applications of our approach and tool in “Debug at Design Level” and “Pattern-Driven Refactoring”. In Section 6, we give an overview of related work, including pattern recovery approaches and formal specification of design pattern. Finally, we summarize the contributions and limitations of our work and outline ideas for the future work. Appendix A gives the detailed definitions of structural constructs, while Appendix B gives the formal definitions of message constructs.