The Software Patterns Criteria
Proposed Definitions for Evaluating Software Pattern Quality
Version 10.2
June 2, 1998
Background: Achieving a standard definition of "What is a software pattern?" is an important goal of the software patterns community. This proposed definition is the result of a single draft review process on the software patterns community email lists. Note: These criteria apply to the evaluation of an individual pattern. A Pattern Lifecycle Model is also documented below, as a non-normative explanation, supporting the criteria.
Perspective: To define priorities for the software pattern criteria, it is appropriate to make the stakeholder perspective explicit. In this case, the stakeholder represents working software practitioners, including software architects, software designers, and programmers.
The importance of standard criteria: Standards for documenting software patterns are important to enhance the quality of documented patterns knowledge. Quality provides tangible value towards the satisfaction of human needs. The "humans" in this case are the principal pattern stakeholders: the software practitioners (See Perspective above). For example, consistency may be a quality of software patterns. Software practitioners often synthesize system solutions, combining the knowledge of multiple patterns and catalogs. Consistent pattern documentation standards are helpful for software practitioners who are using multiple pattern catalogs from different authors.
ESSENTIAL CRITERIA
The following criteria are essential requirements for all software patterns. The ordering of the essential criteria is not important, since they are all mandatory requirements.
1. RULE OF THREE: A software pattern documents a recurring solution. The pattern solution abstracts three or more experiences. The solution is something which is regularly applied or practiced by some community(s) of sophisticated developers and architects. The logical basis for the rule of three is: the first occurrence shows the design can work, the second occurrence is interesting, and the third occurrence suggests that the design might be worthy of being a pattern because it appears to have a wider applicability. Non-normative comment: The informal concept behind the rule-of-three is: the first occurrence is an event, the second occurrence is a coincidence, and the third occurrence may be a pattern.
2. PATTERN NAME: A software pattern has a name corresponding to the documented solution. Within a pattern catalog, this name is unique.
3. DOCUMENTATION: A software pattern is a literary form which contains a documented solution to a software problem and associated design forces.
4. TEACHING: A software pattern contains both solution and teaching elements. The teaching elements address the "why?" questions, including the justification and rational explanation of the pattern. The teaching elements include a discussion of context and forces or an elaboration of benefits & consequences in the resulting context. (See TEMPLATE below).
5. REVIEW: A software pattern has been reviewed and accepted by qualified peers. Based upon the review, the pattern is revised, as appropriate, by the pattern author(s) in response to peer commentary. It is also highly desirable for the pattern to be reviewed by larger groups, including public review on the Internet (See PRACTICAL FEEDBACK).
DESIRABLE CRITERIA
The following criteria are desirable attributes of software patterns, ordered by priority. The priority corresponds to the relative importance to software pattern quality. The most important criteria are listed first.
1. SOLID SOLUTION: The solution answers the "what?" and "how?" questions conclusively. A solid solution comprises substantial and valuable technical content. It provides substantial value to new software practitioners or experts not practicing this solution. A formal pattern presentation defines the solution from both abstract and concrete perspectives. In other words, there is an abstract description as well as a specific example. If appropriate, it is desirable that the solution explicitly define a structure, and that the structure be portrayed in a diagram using UML.
2. TEMPLATE: It is highly desirable for a software pattern to be organized in multiple sections (called a template) that address different aspects of the name, problem, and solution. A templated software pattern is documented using a pattern template, containing at a minimum: Name, Problem, and Solution (or equivalent) sections. The purpose of these sections is to address all of the key questions/aspects about a pattern. These template sections are subdivisions of the categories: Name, Problem, and Solution. For example: Gamma and Buschmann patterns both have 14 sections (except different), a CORBA Design Pattern has 12 sections, and a formal AntiPattern has 17 sections. In addition to the Name/Problem/Solution sections, the following sections are highly desirable: context, forces, and resulting context (AKA: benefits and consequences).
3. PRACTICAL FEEDBACK: Practical feedback is the validation of the software pattern’s effectiveness subsequent to it’s dissemination. Practical Feedback includes review and feedback from expert practitioners who have applied the pattern (See REVIEW). This criteria is in addition to the rule-of-three. In the context of a pattern catalog or language, a software pattern should contribute to successful software practice. Ideally, practical feedback is validated through software development experience of independent readers. Software patterns should contribute to the creation of architectures, software designs, or IT systems which deliver quality (or tangible value to the software stakeholders).
4. POPULAR ACCEPTANCE: It is desirable for all software patterns to be published and publicly available. The popular acceptance and awareness of a software pattern and its pattern catalog is measured by objective criteria, such as publication circulation and classroom surveys.
PATTERN LIFECYCLE MODEL
This section is non-normative for the purposes of explanation.
Software patterns undergo a number of interesting forms and transformations during a pattern’s genesis and application. These forms and transforms are important to clarify. Several Software Pattern Criteria relate to specific knowledge forms and transformations. This model is considered to be a non-normative background for the criteria.
Roles: (a) Pattern Author (or simply "author") and (b) Pattern Reader (or simply "reader").
1. Pattern Event – Pattern Events are concrete applications of the pattern that are witnessed by the author, including the author’s own application of the Pattern Event.
2. Pattern Concept – The author envisions a recurring pattern from several similar occurrences of Pattern Events (See RULE-OF-THREE). The Pattern Concept is an abstraction of these Pattern Events.
3. Pattern Document – The author documents the Pattern Concept in a written form.
4. Pattern Scrutiny – The author disseminates the Pattern Document to colleagues for review in order to solicit expert insights and feedback. The Pattern Document is revised based upon comment. This process of review and feedback is iterated until the author is satisfied with the quality of the Pattern Document. Subsequently, the Pattern Document is published or otherwise disseminated to software practitioners (i.e. readers).
5. Pattern Gestalt (AKA: Eureka!)– The reader acquires and reviews the Pattern Document until the pattern is understood. The Pattern Gestalt is the reader’s conceptual model of the pattern.
6. Pattern Instance – The reader applies the pattern to a software development activity. The Pattern Instance is the resulting artifact.
7. Pattern Feedback – Many readers apply the pattern and achieve a variety of outcomes. Reports of these outcomes comprise Pattern Feedback. Pattern Feedback influences the author, other authors, and other readers. For example, the author may choose to revise the Pattern Concept and Pattern Document.
Lifecycle to Criteria Correspondence
The RULE-OF-THREE is applied in the formation of the Pattern Concept and the Pattern Document. Pattern Scrutiny corresponds to the REVIEW criterion. Pattern Feedback is the mechanism evaluated by the PRACTICAL FEEDBACK criterion. POPULAR ACCEPTANCE is the result of factors such as: the ease of achieving Pattern Gestalt, the ease/effectiveness of applying the pattern to create a Pattern Instance, the resulting quality of the Pattern Instance, and the cumulative effects of Pattern Feedback. The Pattern Document satisfies the DOCUMENTATION criterion and is the focus of the other criteria, not explicitly mentioned here.