What are design patterns?

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.

What is so special about modelling design patterns?

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:

1. Class java.awt.Container extends class java.awt.Component
2. A class (such as java.awt.Container) must extend, either directly or indirectly, the class (such as java.awt.Component).

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.

Why the focus on the 'Gang of Four' catalogue?

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.

What's wrong with UML as a modelling language for design patterns?

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:

• Decidability & Verification: All LePUS/Class-Z specifications are decidable and can be verified automatically by a tool support (see also: The Two-Tier Programming Project)
• Rigour: Each LePUS3/Class-Z specification is equivalent to a formula in first-order classical predicate calculus, and their semantics is defined using Tarski's style truth conditions in terms of finite models.
• Abstraction viz. genericity: LePUS/Class-Z distinguish between variables, which range over (elements of) implementations, and constants, modelling specific (elements of) implementations.
• Abstraction viz. scalability: LePUS3/Class-Z offer a range of abstraction mechanisms (e.g., class hierarchies, sets of methods with same signature), whereas UML Class diagrams are limited to packages and classes.
• Abstraction viz. information neglect: If class/method/relation x is not modelled, what does it mean: That there is no such an entity? Or that it may or may not exist? In LePUS3/Class-Z, absence of information indicates nothing, and specifications merely impose constraints on the implementation but do not dictate it.

"But UML is so popular?!"--right.

Can LePUS3/Class-Z model everything about patterns?

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.

Which patterns can be modelled with LePUS3/Class-Z?

See here the full list of the 'Gang of Four' patterns that can be modelled in LePUS3/Class-Z.

Which other modelling languages for design patterns exist?

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.

Why did you convert the original diagrams to UML and how?

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.