Previous automated approaches to discovering design patterns in source code have suffered from a need to enumerate static descriptions of structural and behavioural relationships, resulting in a finite library of variations on pattern implementation. Our approach, System for Pattern Query and Recognition, or SPQR, differs in that we do not seek statically to encode each pattern and each variant that we wish to find. Our system finds patterns that were not explicitly defined, but instead are inferred dynamically during code analysis by a theorem prover, providing practical tool support for software construction, comprehension, maintenance, and refactoring. We use a logical inference system to reveal large numbers of patterns and their variations from a small number of definitions by encoding in a formal denotational semantics a small number of fundamental OO concepts (elemental design patterns), encode the rules by which these concepts are combined to form patterns (reliance operators) , and encode the structural/behavioral relationships among components of objects and classes (rho-calculus). A chain of fully automated tools provides a path from source code to revealed patterns. We describe our approach in this paper with a concrete example to drive the discussion, accompanied by formal treatment of the foundational topics.

Design patterns are an important concept in the field of software engineering, providing a language and application independent method for expressing and conveying lessons learned by experienced designers. There is a large gap, however, between the aesthetic and elegance of the patterns as intended and the reality of working with an ultimately mathematically expressible system such as code. In this paper we describe a step towards meaningful formal analysis of code within the language of patterns, and discuss potential uses. The major contributions include: a compendium of Elemental Design Patterns (EDPs), a layer of seemingly simplistic relationships between objects that, on closer inspection, provide a critical link between the world of formal analysis and the realm of pattern design and implementation without reducing the patterns to merely syntactic constructs; an extension to the ς-calculus, termed ρ-calculus, a formal notation for expressing relationships between the elements of object oriented languages, and its use in expressing the EDPs directly. We discuss their use in composition and decomposition of existing patterns, identification of pattern use in existing code to aid comprehension, and future research directions, such as support for refactoring of designs, interaction with traditional code analysis systems, and the education of students of software architecture. 1. Problem Description Programming has historically been an exercise in the creation of hierarchical abstractions to manage complexity. As programming techniques have progressed in the field, language designers have continued to push the envelope of producing explicit constructs for those conceptual lessons learned in the previous generation of languages, and software architects have continued to build ever more complex and powerful abstractions. At the same time that these ab-

Design patterns are an important concept in the field of software engineering, providing a language and application independent method for expressing and conveying lessons learned by experienced designers. There is a large gap, however, between the aesthetic and elegance of the patterns as intended and the reality of working with an ultimately mathematically expressible system such as code. In this paper we describe a step towards meaningful formal analysis of code within the language of patterns, and discuss potential uses. The major contributions include: a compendium of Elemental Design Patterns (EDPs), a layer of seemingly simplistic relationships between objects that, on closer inspection, provide a critical link between the world of formal analysis and the realm of pattern design and implementation without reducing the patterns to merely syntactic constructs; an extension to the #-calculus, termed #-calculus, a formal notation for expressing relationships between the elements of object oriented languages, and its use in expressing the EDPs directly. We discuss their use in composition and decomposition of existing patterns, identification of pattern use in existing code to aid comprehension, support for refactoring of designs, integration with traditional code analysis techniques, and the education of students of software architecture.

Finding design patterns in source code helps in maintenance, comprehension, refactoring and design validation during software development. SPQR (System for Pattern Query and Recognition) is a toolset for the automated discovery of design patterns in source code. SPQR uses a logical inference system to reveal large numbers of patterns and their variations from a small number of definitions. A formal denotational semantics is used to encode fundamental OO concepts (which we term elemental design patterns), and a small number of rules (which we call reliance operators) for combining these concepts into larger patterns. These reliance operators, when combined with the #-calculus[1], provide a formal foundation we call the rho(#)-calculus. In this paper we present both the formal semantics of SPQR and a discussion of other practical applications for elemental design patterns.

Previous approaches to discovering design patterns in source code have suffered from a need to enumerate static descriptions of structural and behavioural relationships, resulting in a finite library of variations on pattern implementation. Our approach differs in that we do not seek to statically encode each pattern, and each variant, that we wish to find. Rather, we encode in a formal denotational semantics a small number of fundamental OO concepts (elemental design patterns), encode the rules by which these concepts are combined to form patterns(reliance operators), and encode the structural/behavioral relationships among components of objects and classes (rho-calculus). A logical inference system then is used to reveal large numbers of patterns and their variations from this small number of definitions. Our system finds patterns that were not explicitly defined, but instead are inferred dynamically during code analysis by a theorem prover, providing practical tool support for software construction, comprehension, maintenance, and refactoring.

Previous approaches to discovering design patterns in source code have su#ered from a need to enumerate static descriptions of structural and behavioural relationships, resulting in a finite library of variations on pattern implementation. Our approach, System for Pattern Query and Recognition, or SPQR, di#ers in that we do not seek statically to encode each pattern and each variant that we wish to find. Rather, we encode in a formal denotational semantics a small number of fundamental OO concepts (elemental design patterns), encode the rules by which these concepts are combined to form patterns (reliance operators), and encode the structural/behavioral relationships among components of objects and classes (rho-calculus). We then use a logical inference system to reveal large numbers of patterns and their variations from this small number of definitions. Our system finds patterns that were not explicitly defined, but instead are inferred dynamically during code analysis by a theorem prover, providing practical tool support for software construction, comprehension, maintenance, and refactoring. We describe our approach in this paper with a concrete example to drive the discussion, accompanied by formal treatment of the foundational topics.

We present formal analysis methods and results from SPQR, the System for Pattern Query and Recognition, a toolkit that detects instances of known design patterns directly from object-oriented source code in an automated and flexible manner. Based on previous work in rhocalculus (extended Abadi/Cardelli sigma-calculus) and Pattern/Object Markup Language (POML), the SPQR toolset is easily retargetable to any OO language, though our current results are for C++ programs. In this paper we present an overview of the current SPQR implementation, as well as both positive and negative results from running this tool on production C++ code. We also discuss how the basic formalisms can be applied to other software analyses such as refactoring support and architectural evaluation and comparisons. 1

Since the publication of the Design Patterns book, a large number of design patterns have been identified and codified. Unfortunately, these patterns are mostly organised in an ad hoc fashion, making it hard for programmers to know which pattern to apply to any particular problem. We have organised a large number of existing object oriented design patterns into a pattern language, by analysing the patterns and the relationships between them. Organising patterns into languages has the potential to make large collections of patterns easier to understand and to use. 1: Introduction A object oriented design pattern is a "description of communicating objects and classes that are customised to solve a general design problem in a particular context" [12, p.3]. Designers can incorporate patterns into their programs to address general problems in the structure of their programs' designs. Before they can apply a pattern to solve their design problem, programmers must select an appropriate desig...

Since the publication of the Design Patterns book, a large number of design patterns have been identified and codified. Unfortunately, these patterns are mostly organised in an ad hoc fashion, making it hard for programmers to know which pattern to apply to any particular problem. We have organised a large number of existing object oriented design patterns into a pattern language, by analysing the patterns and the relationships between them. Organising patterns into languages has the potential to make large collections of patterns easier to understand and to use. 1

There are, of course, many uses for inheritance. In general, they fall into two categories: expressing subtyping, and reusing implementation. In this paper we study one particular way of applying inheritance to the problem of reusing implementation: we us inheritance to mitigate the rows and columns dichotomy. We explain this problem, and then give, in pattern form, a detailed description of this use of inheritance.