There is virtually no work on pattern languages for engineering design. The greatest part of the work on patterns has been in architecture, management and OR, and computer programming (especially for object oriented systems).

Refer to the numerous related pages.

A pattern is a description of a repetitive, cyclic, or rhythmic structure or process that we perceive. It is our ability to recognise and reason about patterns that lets us generalise, abstract, conceptualise. We use patterns to predict the future, cause and effect, and behaviour. Patterns that extend in time allow us to connect past, present, and future.

Patterns can be represented in a variety of ways. A mathematical equation like F=ma represents a pattern: all else being equal, pushing something will make it move. Deductive logic is based on the recognition of patterns of symbols; inductive logic is based on assuming that something that has happened before will happen again - again, a recognition of pattern.

Gabriel defines a (software) pattern as:

Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves.

Jim Coplien writes:

I could tell you how to make a dress by specifying the route of a scissors through a piece of cloth in terms of angles and lengths of cut. Or, I could give you a pattern. Reading the specification, you would have no idea what was being built or if you had built the right thing when you were finished. The pattern foreshadows the product: it is the rule for making the thing, but it is also, in many respects, the thing itself.

Appleton directly associates patterns with best practices, and that a pattern also explains rationale (why the solution is needed). He also writes:

A pattern is where theory and practice meet to reinforce and complement one another, by showing that the structure it describes is useful, usable, and used.

There can be patterns for analysis, and for organisations too.

[Sal00b] hints that the results reported in [MGW98] can be interpretted as design occuring (even in one designer's mind) as multiple concurrent processes with competing goals. This sounds alot like the forces (or drivers as I call them) in design patterns.

A pattern for evaporative coolers has been reported, but it is not specified as a real pattern [SSS95].

Patterns for process improvement (re-engineering / BPR) have been developed by Appleton [App98].

From http://c2.com/cgi/wiki?PatternDefinition “…It seemed…that describing a pattern within a context creates a template. That is, the template is the application of a pattern to a context. Thusly, the Publisher pattern can have a Magazine template, a Newsletter template, a DailyNewspaper template, etc.”

This seems to suggest that patterns are of “middling generality” and that they are rather like abstract classes of objects. Instead, I think a pattern can be of virtually any level of generalisation.

[CG04]: indicates the need for strongly connecting problem elements to knowledge. Patterns support this by connecting solutions to classes of problems directly.

• Patterns work best in pattern languages, which cover a domain. So it's a poor PL that people go to for single patterns.
• Patterns should not give the answer, but explain how to get an answer, and how to know if the answer is a good one.
• Why do people go back to re-read a pattern? Cuz they have forgotten methodological info. Given a good pattern, why is it revisited? Alternatively, patterns that are often revisited may be particularly good ones. This may help develop metrics.

Generativity. A good pattern teach us how to build their manifestations. But more than an instruction set or cookbook or algorithm, a good pattern indicates the dynamic nature of its implementation, its adaptability, flexibility, and robustness. Because of their instructional nature, it should be possible to visually depict the kind of structure that results from a pattern application.

Descriptive. A good pattern gives a sense of what its manifestation might look like. Telling how to solve a problem is not enough; the pattern must also describe the nature (“structure”) of the solution, at least in a general way.

Explicative. A good pattern gives a sense of the reasons why the solution was chosen (as opposed to alternative solutions). Users can judge if the reasons hold for their own context.

Recurrence. A pattern must be a recurring phenomenon. Typically, at least three existing instances of a proposed pattern successfully solving the problem should be identified before it earns the label. Patterns must exhibit a track-record. Successes should come from throughout the range indicated by the context of use.

Patterns solve problems. Patterns represent solutions, not just abstract principles or strategies. They are tactical, not strategic, entities.

A pattern solves one kind of problem. Alternatives may exist to any pattern.

Problems that patterns solve take the form of conflicts. Patterns allow “forces to be resolved”. This implies an existent conflict of those forces before the pattern is applied. Identifying the conflict by identifying the conflicting forces is essential.

Patterns work in only one context. Although it may be quite general, a pattern only works in, and should be described with respect to, a single context. That context must be described sufficiently well to let potential users decide if the pattern will work in their context.

Patterns describe relationships. Patterns describe how and why their manifestations interact within a context, and the interactions between subpatterns, superpatterns, and copatterns.

Patterns have significant human components. They must appeal to aesthetics and utility (e.g. balance). Utility (fitness, goodness) is shown by explaining how and why the pattern is successful and beneficial.

References for these properties:

• http://www.bradapp.net/
• http://www.hillside.net/patterns/writing/checklist.htm
• http://c2.com/cgi/wiki?PatternDefinition

From http://www.hillside.net/patterns/writing/patterns.html#1.0

• Some benefits can be seen by considering the forces resolved through the use of patterns:
  • keeping the solution to yourself doesn't require any effort
  • sharing the solution verbally helps a few others but won't make a big impact in your field
  • writing down your understanding of the solution is hard work and requires much reflection on how you solve it
  • transforming your specific solution into a more widely applicable solution is difficult
  • people are unlikely to use a solution if you don't explain the reasons for using it
  • writing down a solution may compromise your competitive advantage (either personal or corporate)

• A benefit of pattern languages is that it allows complex problems to be broken down sensibly, facilitating understanding.

The best definition I've found so far, is from Alexander himself [AIS77]:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves. As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.

The first statement suggests: Pattern = f (c, p, s).

But from the second statement:

• Now it's not a problem but a system of forces.
  • It's a system of forces - i.e. an interacting or coupled set of forces.
  • Since the forces are resolved through the application of the pattern, they must have been unresolved before.
  • So the problem ⇒ undesirable situation ⇒ unresolved forces.
  • So the Problem section is a simple statement of the undesirable situation, whereas the Forces section is only a factual account of the drivers that are interpreted as an undesirable situation.
  • Some people prefer putting the context before the problem statement. There are hazards either way: the problem may be hard to understand without knowing the context first (so context should be given first), but without the problem statement, context information is ungrounded (making the pattern hard to understand).

• So the Problem section should contain
  1. the problem statement, a short description including a very general sense of context, then
  2. list the unresolved forces (drivers) that form the undesirable situation, then
  3. context details.

• The solution, the “certain spatial configuration,” resolves the forces. “Resolve” is a tricky word here; it can mean solve, or split into components.
  • I cannot find any web sources that indicate explicitly which interpretation is correct.
  • All web sources I've checked consistently imply that resolve ⇒ solve.
  • But resolve ⇒ split is also interesting (divide and conquer, top-down)
  • So let's call this section Resolution instead of Solution, so that it can have a solution or a decomposition (or both).

Given the above discussion, my definition of pattern is:

In Therefore/But form, the But clause captures exceptions. Generally, one puts a description of the new context in the solution section.

• This is strange: it divides the consequences into two sections. I don't like this.
• So instead of But, let's call it Consequences, which contains a description of the new context, including both good and bad features of it.

Given a wiki to capture the pattern language, we don't need a glossary section, cuz we can just point to pages that define terms as needed.

TBD

• pattern languages in education google search.
• Go through [Ale64] and see what if anything can be added here.
• Toufik Taibi's publications – he uses action logic to formalize pattern languages.
• TRIZ is very much like a pattern language. Google “pattern language triz” and see what's up there.
  • Kevin Rea published a paper in the Triz Journal, TRIZ and Software - 40 Principle Analogies, Part 2, that shows how some Triz principles are like typical programming patterns.
• [MZ96] includes a number of problem solving methods for parametric design that can probably be written as patterns.
• a pattern for breadth-first searching of design solution spaces (cf. CK and ALX3d)
• read [DGR97] and follow up on my notes.
• Anything useful in TclTk patterns?
• Go through diigo links (& SERF db) for other information worth capturing.

• A summary of different pattern forms
• My pattern template
• My three-fold path
• My [[patlan:|Engineering Pattern Language]]