Modelling Design Patterns: Frequently-Asked Questions
Design patterns are 'recipe's for solving software design problems by describing a particular design motif: a category of solutions to a class of common design problems. The most widely used kind of design patterns are patterns of object-oriented design: recipes which describe a category of problems common to object-oriented design and how they should be solved. The excellent 'Gang of Four' catalogue [Gamma et al. 1995] has established the widest practice of design patterns in object-oriented design. A nice introduction to design patterns is offered in [Schmidt et al. 1996] (available online).
Most often, however, a 'pattern' in the vernacular refers to the design motif element of the design pattern, not to the recipe as a whole. While some see this as a confusion, others consider this a natural by-product in the evolution of standard software design solutions to common problems, such as architectural styles [Garlan & Shaw 1993], programming paradigms, and component-based software engineering technologies [Szyperski 2002]. In LePUS3 and Class-Z we adopt the common practice of using the term 'design pattern' (in short, 'pattern') with reference to the design motif that the pattern's recipe describes.
Modelling languages in standard use, such as the Unified Modeling Language and its predecessors (e.g. Object Modeling Technique, Booch Notation, etc.) are focused on modelling a particular software system—a specific program (or a specific collection of programs). Design patterns however are design motifs: there is usually an unbound number of programs that implement each pattern. Modelling a design pattern is therefore an exercise in abstraction cum genericity: it requires the use of variables (as opposed to constants) which range over a category of implementations.
Why variables are so important? Try 'modelling' the difference between the following two statements:
java.awt.Container) must extend, either directly or indirectly, the
The first sentence describes a specific implementation, the second describes a design pattern—a category of implementations. The first statement determines the relation between specific classes, whereas the second statement imposes a constraint on such classes. The first statement is closed, the second is open.
The book Design Patterns: Elements of Reusable Object-Oriented Software [Gamma et al. 1995] was authored by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, a quartet which came to be known as the 'gang of four' (hence: the 'Gang of Four' Catalogue). The catalogue delivers a meticulous description of twenty-three design patterns. Many of the patterns described in the book have been implemented in a wide range of well-designed programs and are currently recognized as paragons of good design.
For these reasons, The 'Gang of Four' Companion is focused on modelling the design patterns in the 'Gang of Four' catalogue.
Giving a full answer to this question would require not one page but an entire encyclopaedia. We are not in the business of writing the seven volumes of What's Wrong with UML; others have already done so successfully (see Bertrand's Meyer's excellent UML—The Positive Spin.) Rather, let us describe what mechanisms of LePUS3 and Class-Z are specifically tailored for modelling design patterns, none of which applies to UML:
"But UML is so popular?!"--right.
No. The syntax of LePUS3/Class-Z is extremely limited, allowing only for three kinds of predicates and only one kind of ground formula. Furthermore, only decidable relations can be expressed using LePUS3 and Class-Z. Therefore we cannot model statements such as 'each instance of class X holds exactly 3 instances of class Y at each point in time.' Objects are not modelled directly using LePUS3 and Class-Z, only classes.
Nonetheless, you would be surprised how much about patterns can be captured with these simple concepts. See here the full list of the 'Gang of Four' patterns that can be modelled in LePUS3/Class-Z.
See here the full list of the 'Gang of Four' patterns that can be modelled in LePUS3/Class-Z.
There are many attempts to tailor formal specification languages specifically for the purpose of modelling design patterns. Many of these efforts are listed in this page.
Each 'Structure' diagram in our 'Gang of Four Companion' includes UML Class Diagrams for illustrating the informal description, although OMT was used by the [Gamma et al. 1995] catalogue. We could not quote the original OMT diagrams due to copyright issues, and UML is currently much more popular.
UML Class diagrams were created in Visio 2003 format (download UML Class Diagrams of the 'Gang of Four' design patterns.)
The 'conversion' process is free-style for illustrative purposes only: namely to show the inadequacy of UML in modelling each pattern. Don't write us about so called 'errors' in the UML Class Diagrams; we could not care less about those because neither UML nor OMT is any good for modelling design patterns anyway.