A Comparison of Reverse Engineering Tools based on ... - CiteSeerX

A Comparison of Reverse Engineering Tools based on Design Pattern Decomposition* Francesca Arcelli, Stefano Masiero, Claudia Raibulet, Francesco Tisato DISCo – Dipartimento di Informatica Sistemistica e Comunicazione Università degli Studi di Milano-Bicocca, I-20126, Milan, Italy {arcelli, masiero, raibulet, tisato}@disco.unimib.it Abstract The usefulness of design patterns in forward engineering is already well-known and several tools provide support for their application in the development of software systems. While the role of design patterns in reverse engineering is still argued primarily due to their informal definition which leads to various possible implementations of each pattern. One of the most discussed aspects related to design patterns is about the need of their formalization according to the drawbacks this can represent. Formalization leads to the identification of the socalled sub-patterns, which are the recurring fundamental elements design patterns are composed of. In this paper we analyze the role sub-patterns play in two reverse engineering tools: FUJABA and SPQR. Attention is focused on how sub-patterns are exploited to define and to detect design patterns. To emphasize the similarities and differences between the two approaches, the Composite Design Pattern is considered as example.

1. Introduction The original aim of design patterns [9] has been to extract the common aspects of the design of available software architectures and to formulate in an informal way known and optimized solutions to specific design problems. The awareness of the design patterns existence has raised new challenging issues related to their role, specification, and usage/implementation. In the context of forward engineering, the role of design patterns is to provide optimized (common) solutions to well-known problems, solutions that have *

been already tested and validated in available implementations. This accelerates the development process ensuring also an improved quality of software. Initially, research has been concentrated on the implementation of design patterns, focusing on the possibility of using them automatically during the development of software systems. Problems occurred immediately due to the informal specification of design patterns, which is motivated by the intention to keep them independent of any implementation language and to provide a reasonable degree of flexibility of the pattern instantiation once the application context has been identified. Hence, actual implementations of design patterns are personalized by programmers to applications exigencies leading to possible variants of the same pattern. The tracing problem raises here, because it becomes difficult to keep track of variations of patterns. In the context of reverse engineering, the recognition of design patterns provides additional information related to the rationale behind the design. They do not only provide information about how the architecture has been built, but also why it has been built in a specific way due to the semantic design patterns incorporate. Primarily, the idea of detecting design patterns in the reverse engineering process, has encountered strong resistance of both the pattern and reverse engineering communities because of their various possible implementations and interpretations, as well as of the various intents of using the same structure of a single pattern [5, 10]. In this context, there is a strong need to formalize design patterns. Inevitably, formalization leads to the identification of regular recurring elements. Considering patterns as compositions of simpler elements may reduce significantly the creation of variants in forward engineering, while it increases the

This research is partially supported by the MAIS project financed by MIUR – “Ministero dell’Istruzione, dell’Università e della Ricerca° in the context of the FIRB program “Fondo per gli Investimenti della Ricerca di Base”.

possibility of identifying applied patterns in reverse engineering. The rest of the paper is organized as follows. Section 2 introduces the main steps of design patterns detection process. Section 3 presents two tools which decompose patterns to improve their detection: FUJABA [12] and SPQR [20]. Attention is concentrated on how sub-components are used to define and detect design patterns, and which are, according to tools authors, the pros and cons these tools provide. Our comments are introduced at the end of each tool presentation as a discussion paragraph. The section ends with a comparison of the two tools focused on the decomposition of design patterns. Conclusions are dealt within Section 4. Section 5 describes our current and future work by introducing two of our projects that exploit sub-components for design pattern definition and detection in Java software systems.

2. Design Pattern Detection Steps The main steps a tool performs to detect design patterns are related to source code information extraction, archetypes recognition, and presentation of results (see Figure 1). Information extracted from source code depends on the elements searched by the detection algorithm to identify design patterns. Usually, extracted information is represented in a language-independent way, such as an abstract syntax tree (AST) or an abstract syntax graph (ASG). Besides extracted information, the detection algorithm receives as input a catalog of design patterns in which patterns are described according to the meta-representation formalism used by the detection algorithm. The detection algorithm is based on matching techniques which try to map representations of design patterns stored in the catalog to the representation of the extracted information from source code. Results of the detection algorithm are provided in a graphical (UML diagrams) or textual mode (ASCII or XML files). Design pattern detection tools can be evaluated with respect to the following metrics: precision and recall [17]. Precision is given by the ratio of recognized and really implemented patterns, while recall is calculated as the division between implemented and recognized patterns. In our opinion, these two evaluation parameters are mostly dependent on the catalog of design patterns and the information used by the detection algorithm to identify design patterns. Various possible implementations of design patterns are recognized based on the information stored in the design pattern

catalog. Such information is rather incomplete constraining the detection algorithm to require human intervention and/or additional information/mechanisms (i.e., fuzzy logic) to complete, if possible, its task. [10] categorizes design pattern detection tools according to the degree of the human intervention/involvement in the detection process: manual, semi-automatic, and automatic. We propose a categorization of detection tools based on the information they use during detection: - tools considering the “entire” representation of design patterns (PTIDEJ [2], CrocoPat [4]); it means the detection algorithm tries to map (at once) the entire pattern on the representation of the source code; usually, this approach claims for a “complete” catalog containing all possible implementations of design patterns. - tools considering a minimal set of key structures design patterns consist of ([17], SPOOL [10]); it means the detection algorithm tries to individuate (at once) the core set of structures a pattern is built on; this approach claims a further analysis of design patterns leading to the identification of their core elements; - tools considering the sub-components design patterns are built of (FUJABA [12], SPQR [20]); it means the detection algorithm works incrementally by individuating first the sub-components of patterns, then trying to combine these subcomponents into patterns; obviously, subcomponents are explicitly described and stored in the design pattern catalog. Of interest for the present paper is the last category of tools because they imply a further formalization of design patterns that conserve their flexibility.

Figure 1. Main Steps of Design Pattern Detection

3. Comparing Design Pattern Detection Tools through the Role of Sub-Patterns FUJABA (From Uml To Java And Back Again) [12] and SPQR (System for Pattern Query and Recognition) [20] will be presented through the formalization mechanisms they use to define design patterns and the influence these mechanisms have in their detection process.

3.1. FUJABA Design Pattern Definition Design patterns are defined in terms of UML class diagrams, which successfully describe their structure. The behavioral aspects of design patterns are expressed through story-diagrams [7, 24], which are a combination of activity and interaction diagrams. Within FUJABA, common parts of design patterns are defined separately as sub-patterns [14], which can be further (re-)used as atomic (basic) elements (like classes, methods, attributes) to define other subpatterns or patterns. Sub-patterns may have associated a direct correspondence to code (such as reference, association, generalization, delegation of implementation, etc.) [14]. The construction of patterns or sub-patterns from other sub-patterns exploits the inheritance and use relationships (as they are defined by the OO paradigm). Implementation variants are generated by the multitude of possible implementations of method bodies (i.e., head/foot – controlled loops) and associations (i.e., the multiplicity of binary associations) [14]. In addition to the implementation variants, FUJABA introduces also design variants [14]. Design patterns that may have structurally different variants with the same semantics have associated more than one design variant. In the pattern definition class diagram, variants of a design (sub-)pattern may be specified totally independent with each other (i.e., the Composite design pattern has two variants – (1) the variant with two classes: Component and Composite, and (2) the variant with one class in which Component and Composite are unified in one single class) or may be connected through an inheritance relationship (i.e., the MultiLevelInheritance sub-pattern is defined as a “sub-class” of the Generalization sub-pattern). Design Pattern Detection Information extracted from source code is expressed as an abstract syntax graph (ASG), which is further enriched with annotations during the design pattern detection process. Annotations indicate the

presence of patterns or sub-patterns in the ASG under analysis. Annotations are added on an ASG by using graph transformation (or rewrite) rules [15, 24] previously defined. Each transformation rule defines formally a (sub-)pattern. Additional nodes and edges inserted in the ASG indicate which sub-graphs correspond to the identified (sub-)patterns. Annotations are then used as atomic elements of the ASG by transformation rules defining other (sub)patterns, which contain the identified annotations as constituent parts. The class diagram defining (sub-)patterns specifies the types of nodes and edges of an (annotated) ASG. Transformation rules capture both structural and behavioral aspects of design (sub-)patterns. Each transformation rule has two parts: the left hand one defines the (sub-)pattern by indicating the sub-graph that has to be isomorphically bound to the ASG of the source code, while the right hand one consists of the left hand side together with the modifications to the sub-graph (nodes and edges) to be created and/or deleted. Transformation rules have a hierarchical organization which assigns them a level number [14]. Rules depending only on information extracted from source code belong to level one, while rules depending on other rules (annotations) get a number level consistent with the topological order of rules. Recursive rules included in cycles concerning their dependencies get the same level number. The design pattern detection algorithm annotates the ASG of the source code for every found (sub)pattern. Nevertheless it is a deductive algorithm [14, 15], it uses a combined bottom-up (applying transformation rules starting from the minimum level number) and top-down (applying transformation rules starting from the highest level number) strategy, which accelerates the provision of the first relevant analysis results. Level numbers associated to transformation rules are used by the detection algorithm to establish the order of applying rules on the ASG and to switch between the two types of strategies (when transformation rules in the queue cannot be applied by the current strategy). Analysis results have associated a fuzzy value which leads to the automatic acceptation or rejection when the uncertainty value is higher or lower than previously-defined values. During the detection process, a software engineer may change the uncertainty value associated to a (sub-)pattern, and moreover s/he may add, delete, or adapt transformation rules to the domain of interest. Variants explicitly defined either as design or implementation are automatically detected. Those

which are not explicitly defined may be inferred with a certain level of uncertainty expressed by fuzzy values [13]. In this way, a transformation rule may match several implementation variants with different degrees of uncertainty. Pros and Cons Even if FUJABA is presented as a tool for software systems written in Java, it can be extended to other programming languages too (also non object-oriented) [14]. The representation of the source code as an ASG sustains the previous affirmation. The definition of patterns and sub-patterns and their behavior through (standard) UML diagrams makes it easier for software engineers to understand, use, and extend FUJABA. Authors assert their approach provides a precise definition of all GoF-patterns [9], albeit with the use of alternative variants to conserve their design flexibility. Design variants are introduced to avoid the explosion of annotations in the ASG, which may lead to scalability problems. For the same reason, implementation variants are used in conjunction with fuzzy logic, which leads to less reliability. Authors argue their implementation variants are mostly related to sub-patterns which are significantly less complex than patterns [14]. The introduction of sub-patterns makes the detection process incremental enabling the provision of first results in a short time with consistent information. FUJABA allows the intervention of the software engineer during the detection process making it a semiautomatic tool for design pattern recognition. Discussion Sub-patterns are described as common parts of patterns which have associated their own definition. In the context of FUJABA, sub-patterns have been primarily introduced in the attempt to reduce the dimension of the design pattern catalog. The most interesting aspect of sub-patterns is that they can be further (re-)used as basic (atomic) elements both in the definition and the detection process of other patterns. FUJABA lacks in describing how sub-patterns should be identified neither it provides a catalog of subpatterns. Using sub-patterns in pattern definition, more levels of abstraction have been introduced between the source code and the high-level specification of design patterns. In this way, the differences between two levels of abstraction are significantly reduced. A subpattern may have different implementation variants, but at the upper abstraction level(s) it is seen as a unique element. For instance, the Composite design pattern may be expressed through three sub-patterns:

Generalization, Association, and IN_Delegation (see Figure 2). Each of these sub-patterns may have several variants. The problem of the Composite variants is reduced to the variants of three sub-patterns which are far simpler than the Composite pattern. Besides, the three sub-patterns are used also by other design patterns. The existence of intermediate abstraction levels allows the detection algorithm to use both bottom-up and top-down strategies. This leads to having in a short time partial analysis results which can be expressive enough.

3.2. SPQR Design Pattern Definition Design patterns are defined through three different elements: elemental design patterns (EDP), reliance operators, and rho-calculus. EDPs [21, 22, 23] are lowlevel design patterns, which express in a formal denotational semantics a small number of fundamental OO concepts. Design patterns are expressed as compositions of EDPs, which are seen as an intermediate level of abstraction between the source code and the high-level description of design patterns. EDPs capture those mechanisms specific to the OO programming used in the every day implementation of software (i.e., creation of objects, abstraction of interface, delegation of implementation, etc.). SPQR authors assert all twenty-three GoF design patterns can be built of the sixteen EDPs. EDPs and their composition rules are expressed formally in terms of rho-calculus [21], which represents a subset of sigma-calculus [1] extended with new reliance operators. Rho-calculus inherits from sigma-calculus the type definition, object typing, and type subsumption concepts. Reliance operators are defined as direct, quantifiable expressions which indicate whether elements rely or depend on other elements and to what extend they do so. These operators indicate reliance on method invocation, field access, or generalization. Design Pattern Detection SPQR is an automatic design pattern detection tool. It consists of several component tools, corresponding to the main steps of the detection algorithm: source code feature extraction, feature-rule description, rule inference, and query results. Information looked up in the source code corresponds to the rho-calculus concepts used for the definition of EDPs. Source code is represented as an abstract syntax tree from which information is further extracted and stored into a POML file – Pattern/Object Markup Language [19], an

XML Schema for object-oriented code description. SPQR generates feature-based rules from the POML file and gives them as input to the OTTER theorem prover [20]. In addition, OTTER receives as input the elements of rho-calculus, the EDPs, and the design patterns of interest, all encoded as rules. The theorem prover provides the instances of design patterns found by inferring on the input information and rules. The output of the theorem prover is translated in an XMLbased format and can be used for further analysis (i.e., graphical representation). Design patterns and their implementation variants are not statically described, but they are dynamically inferred through formalized rules. In the context of SPQR, implementation variants are called isotopes [20], and they are seen as variations of code expression that conform to the concepts and roles of EDPs. The catalog of design patterns contains the definition of the EDPs in terms of OO elements and the definition of design patterns in terms of EDPs. Isotopes are dynamically inferred by the theorem prover. Pros and Cons The main advantages of SPQR are consequences of the formalization mechanisms it introduces for the definition of EDPs and their combination rules into design patterns. These mechanisms ensure a highdegree of flexibility to the SPQR approach. Specified through EDPs, design patterns become less complex and easier to understand and to detect. EDPs represent an intermediate level between source code and design patterns, reducing the design patterns detection to the detection of EDPs. As design patterns, also EDPs are language-independent. Due to the rho-calculus formalism, the power of the detection process increases significantly by being able to reduce dynamically variants to their corresponding patterns. SPQR provides a set of core EDPs which are necessary, if not sufficient, to reconstruct all the GoF design patterns. Even if, they are presented as mechanisms to define more complex design patterns EDPs can be seen also as stand-alone mechanisms to analyze software systems due to their capacity of capturing design intents. They can be used for better understanding of the source code in general without identifying complex design patterns. Further, they are particularly adapted for educational purposes in the context of OO software systems. SPQR is presented as an automated toolset for design pattern detection in software systems written in C++ easily extensible to other programming languages. It has a modular structure being composed by several components, which can be independently modified and/or substituted. Authors threshold are

related to the code analysis performed according to the concepts expressed through the rho-calculus formalism considered equivalent to a compilation. Currently, no significant differences for the design pattern detection process have been encountered. Discussion The keyword characterizing SPQR is formalization. As the authors sustain, formalization itself increases the flexibility of their approach. The success of SPQR is due to the attention authors give to the aspect “how design patterns can be built or rebuilt?” rather than “how to represent design patterns in another form?”. Therefore, attention is concentrated on the functionalities of design patterns, and not on their syntactical representation. SPQR is an automated design pattern detection tool. This is an important aspect demonstrating it is possible to precisely detect design patterns without human intervention. The definition of the EDPs catalog, whether it is complete or not, provides additional understanding of the source code regardless EDPs are used independently or as part of design patterns. The rho-calculus formalism has solved the problem of the implementation variants in an elegant manner. SPQR is presented as a modular tool composed of independent components which can be modified and/or substituted without affecting other components. For instances, authors sustain SPQR is easily extensible for other programming languages by replacing the components that perform code analysis and generate the POML file containing the feature based rules equivalent to the source code. Unfortunately, these adaptations can be performed only by authors because SPQR and its components are not available for download and testing. Also the composition rules of EDPs into design patterns are not presented by authors.

3.3. FUJABA vs. SPQR: Sub-Patterns vs. EDPs Nevertheless the idea of decomposing patterns is not new, in our opinion it has not been exploited in design pattern detection tools previously of FUJABA and SPQR. FUJABA makes use of sub-patterns to reduce the dimension of the design pattern catalog and to reduce the complexity of the elements searched in the source code. It builds a hierarchy of sub-patterns by assigning them a level number which is exploited by the detection algorithm to establish the order of applying transformation rules. Within SPQR, EDPs play a central role: extraction of information from source code is performed according to the elements EDPs are built of, design pattern detection is reduced to the EDPs detection, and design patterns are

expressed exclusively through EDPs. EDPs form a plain abstraction level, this meaning they can be detected independently of each other. In our opinion, there is a connection between the names of sub-patterns, respectively elemental design patterns, and the reason for which they have been introduced in the detection tools. Sub-patterns have been born as a consequence of identifying common structural (syntactical) elements in different design patterns. They can be connected with each other through inheritance or use relationships. Hence, “subpattern” may be considered similar to the sub-class concept. While, elemental design patterns represent independent and simpler design pattern. They capture the essence of the OO concepts used by design patterns. Hence, they are considered “elemental elements” on which design patterns are built. We have adopted, for this paper, the term “subpatterns” to express the sub-components of design patterns regardless their original meaning introduced by FUJABA. To summarize, sub-patterns are mostly related to the syntactical form of the components of design patterns, while elemental design patterns are mostly related to the functionalities of the components of design patterns. To sustain this affirmation we present the sub-patterns (see Figure 2) [14] and the EDPs (see Figure 3) [11] the Composite design pattern is composed of. In the FUJABA approach, the Composite pattern is composed of three sub-patterns [14]: Generalization (level 1 – based only on source code information), Association and 1N_Delegation (level 2 – based on the Reference sub-pattern here not shown for the sake of figure clarity).

In the SPQR approach, the Composite pattern is composed of three EDPs: Inheritance, AbstractInterface, and RedirectInFamily. Both cases ignore Leaf class being not relevant for this example. A key question raises here: is there any equivalence/correspondence between sub-patterns and EDPs? In both approaches, three elements have been recognized as parts of the Composite design pattern. At first glance, Generalization corresponds to Inheritance, and 1N_Delegation to RedirectInFamily. What about Association and AbstractInterface, which seem to be different? Another question raises here: are they really equivalent differing only by their name? In the case of Generalization and Inheritance the answer is yes, they differ only by their names. In FUJABA, there is required also an Association between the two classes involved in the Generalization sub-pattern to built the Composite pattern. We ask here, should it be a particular type of Association? We suggest the name Aggregation for such an association. In SPQR, the AbstractInterface indicates the presence of a common interface for operating on an object type family delaying the definition of the actual operation to a later time [23]. Essentially, it captures the abstract feature of the Component class. The conclusion is that Association and AbstractInterface are completely different both in names and in meanings. The 1N_Delegation in FUJABA indicates there is a delegation of implementation between two operations of the two classes connected by a Generalization and an Association. While, in SPQR, the RedirectInFamily redirects some portion of a method’s implementation to a possible cluster of classes, of which the current class is a member. As it can be easily concluded, the RedirectInFamily is more complex than 1N_Delegation. In our opinion RedirectInFamily includes both Association and 1N_Delegation.

Figure 2. Sub-Patterns of the Composite Design Pattern

Figure 3. EDPs of the Composite Design Pattern

To summarize, Generalization corresponds to Inheritance, while Association and 1N_Delegation to RedirectInFamily. AbstractInterface is an additional design intent captured only by SPQR.

4. Conclusions Due to the fact design patterns provide common solutions to common problems which are of significant complexity to require additional explanations, it has been born the idea of decomposing patterns and to identify recurring elements they consist of. These recurring elements have been recognized both in the context of forward and reverse engineering, and they have been named fragments [8], motifs [6], minipatterns [16], sub-patterns [12], or elemental design patterns [20]. As the variety of names suggests, there is little agreement what patterns should be decomposed in. From the abstraction point of view, the sub-components of patterns should be situated at the half-way between the source code and the high-level definition of design patterns. Their goal should be to capture design intents, not just being another formalism to represent source code. A hierarchy of sub-patterns simplifies the understanding and the detection of design patterns. We aim at summarizing in the following the main benefits sub-patterns provide for the definition and detection of design patterns: - sub-patterns are less complex than design patterns, hence also the rules their detection is based on are simpler; - design patterns can be described formally as combinations of sub-patterns; - decomposing patterns into sub-patterns do not affect the flexibility of the first once; the variants problems impacts mainly on sub-patterns; - sub-patterns represent an intermediate abstraction level between design patterns and source code; they can be considered also independently from design pattern in the context of reverse engineering due to their ability to incorporate design intents.

5. Current and Further Work Considering the SPQR approach particularly interesting, we have extended it to software systems written in Java [3]. We have used the Recoder [18] framework to parse the source code and to generate its equivalent AST. Further, we have implemented a Visitor [9] to extract the information given as input to the OTTER theorem prover used by SPQR and to encode this information in a POML file. The output of

our prototype called J2POML [3] goes in input to the theorem prover of SPQR, which provides a report with the detected design patterns. Further, we are evaluating the idea of using the catalog of EDPs independently of the SPQR approach. This choice considers also that SPQR is based on a mathematical paradigm not commonly used by software engineers, and difficult to be understood and extended for other programming languages or new design patterns. Currently, we have implemented a prototype EDPDetector4Java [11] able to identify EDPs within the Java source code. We have concentrated our attention only on static analysis of the source code. The limitations of such an analysis are generated by the polymorphism of the object-oriented languages. Our approach uses an AST representation of the source code in association with information related to type expressions, reference resolutions, and crossreferences. EDPs belonging to the Object Elements and Type Relation groups [20] are easy to detect through a direct relation with the Java constructs represented in the AST nodes. During the analysis of such a node it is possible to identify an EDP directly or using cross-reference information. The detection of the EDPs belonging to the Method Invocation group [20] is more complex because it requires an analysis of the object types and methods implicated in the interaction. Considering only the static analysis, we cannot detect EDPs precisely, hence we have associated them a degree of uncertainty as in the FUJABA approach. Further work will be concentrated on introducing dynamic analysis of the source code, the identification of mechanisms to infer design patterns from EDPs, and the resolution of implementation variants. Moreover, we intent to experiment the FUJABA tool for the detection of the EDPs defined in the context of SPQR, and to identify similarities and differences between sub-patterns and EDPs.

Acknowledgements We would like to thank Jörg Niere from University of Siegen, Germany and Jason McC Smith from University of North Carolina, USA for their collaborations and useful hints.

6. References [1] M. Abadi, and L. Cardelli, A Theory of Objects, SpringerVerlag, New York, Inc., 1996. [2] H. Albin-Amiot, P. Cointe, Y. G. Guéhéneuc, and N. Jussien, “Instantiating and Detecting Design Patterns: Putting

Bits and Pieces Together”, Proceedings of the 16th International Conference on Automated Software Engineering, San Diego, CA, USA, 2001, pp. 166-173. [3] D. Bellinzona, “J2POML: Extraction of Information for Design Pattern Recognition from Java Source Code”, University of Milano-Bicocca, Milan, Italy, November, 2004. [4] D. Beyer, and C. Lewerentz, “CrocoPat: Efficient Pattern Analysis in Object-Oriented Programs”, Proceedings of the 11th IEEE International Workshop on Program Comprehension, Los Alamitos, CA, USA, 2003, pp. 294295. [5] C. Chambers, B. Harrison, and J. Vlissides, “A Debate on Language and Tool Support for Design Patterns”, Proceeding of the 27th ACM SIGPLAN-SIGART Symposium on Principles of Programming Languages, Boston, MA, USA, 2000, pp. 277-289. [6] A. H. Eden, “Precise Specification of Design Patterns and Tool Support in Their Application." PhD Dissertation. Department of Computer Science, Tel Aviv University, 2000. [7] T. Fischer, J. Niere, L. Torunski, and A. Zündorf, “Story Diagrams: A New Graph Rewrite Language based on the Unified Modeling Language”, Proceedings of the 6th International Workshop on Theory and Application of Graph Transformation, Paderborn, Germany, LNCS 1764, Springer Verlag, November 1998, pp. 296—309. [8] G. Florijn, M. Meijers, and P. van Winsen, “Tool Support for Object Oriented Patterns”, Proceedings of the 11th European Conference on Object-Oriented Programming, Springer Verlag, Berlin, Germany, 1997. [9] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: elements of reusable object-oriented software, Addison Wesley, Reading MA, USA, 1994. [10] R. K. Keller, R. Schauer, S. Robitaille, and P. Page, “Pattern-Based Reverse-Engineering of Design Components”, Proceedings of the International Conference on Software Engineering, Los Angeles, CA, USA, 1999, pp. 226-235. [11] S. Masiero, “Design Pattern Detection in Reverse Engineering – The Role of Sub-Patterns”, Master Thesis, University of Milano-Bicocca, Milan, Italy, October, 2004. [12] U. Nickel, J. Niere, and A. Zündorf, “The FUJABA Environment“, Proceedings of the 22nd International Conference on Software Engineering, Limerick, Ireland, 2000, pp. 742-745. [13] J. Niere, “Fuzzy Logic based Interactive Recovery of Software Design”, Proceedings of the 24th International

Conference on Software Engineering, Orlando, Florida, USA, 2002, pp. 727-728. [14] J. Niere, W. Schäfer, J. P. Wadsack, L. Wendehals, and J. Welsh, “Towards Pattern-Based Design Recovery”, Proceedings of the 24th International Conference on Software Engineering, Orlando, Florida, USA, 2002, pp. 338-348. [15] J. Niere, M. Meyer, and L. Wendehals, “User-driven Adaption in Rule-Based Pattern Recognition”, Tech. Rep. trri-04-249, University of Paderborn, Paderborn, Germany, June 2004. [16] M. Ò Cinnéide, “Automated Application of Design Patterns: A Refactoring Approach”, Ph.D Dissertation, University of Dublin, Trinity College, 2001. [17] I. Philippow, D. Streitferdt, M. Riebisch, and S. Naumann, “An Approach for Reverse Engineering of Design Pattern”, Software and Systems Modeling, Springer Verlag, April 2004. [18] Recoder - http://recoder.sourceforge.net/ [19] J. McC. Smith, and D. Stotts, “Pattern/Object Markup Language (POML): A Simple XML Schema for Object Oriented Code Description”, Tech. Rep. 04-010, Computer Science Department, University of North Carolina at Chapel Hill, April 2004. [20] J. McC. Smith, and D. Stotts, “SPQR: Flexible Automated Design Pattern Extraction From Source Code”, Proceedings of the 2003 IEEE International Conference on Automated Software Engineering, Montreal QC, Canada, October, 2003, pp. 215-224 [21] J. McC. Smith, and D. Stotts, “Elemental Design Patterns and the Rho-calculus: Foundations for Automated Design Pattern Detection in SPQR”, Tech. Rep. 03-032, Computer Science Department, University of North Carolina at Chapel Hill, September 2003. [22] J. McC. Smith, and D. Stotts, “Elemental Design Patterns: A Formal Semantics for Composition of OO Software Architecture”, Proceedings of the 27th Annual IEEE/NASA Software Engineering Laboratory Workshop, Greenbelt, MD, 2002, pp. 183-190. [23] J. McC. Smith, “An Elemental Design Patterns Catalog”, Tech. Rep. 02-040, Computer Science Department, University of North Carolina at Chapel Hill, December 2002. [24] L. Wendehals, “Improving Design Pattern Instance Recognition by Dynamic Analysis”, Proceedings of the ICSE 2003 Workshop on Dynamic Analysis, Portland, USA, May 2003.