Can pattern languages be used in design engineering? I think so.
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.
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.
[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.
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:
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:
Given the above discussion, my definition of pattern is:
A pattern models a relationship between
In Therefore/But form, the But clause captures exceptions. Generally, one puts a description of the new context in the solution section.
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.
[[patlan:|Engineering Pattern Language]]