Research: "What Makes a Good Pattern Language?"

List of Pattern Languages For Study

This page holds some preliminary material on a list of pattern languages. The research is to determine criteria for pattern languages and to read each langauge and evaluate it against the characteristics and criteria found to date. Some of the references have links, others do not, If you find the link, email it to me and I will add it in.


Pick a language, study it. Tell us what you found good about it. For criteria on what is a good pattern, see this link.

 

Modified

Author(s)

Comments

1-2-2002

Ali Arsanjani

Very rough draft. Needs organizations and formatting.
1-29-2002 Updates to links

1994

1.     CHECKS pattern language by Ward Cunningham

2.    Kent Beck: Ward came up with a five pattern language that helped them take advantage of Smalltalk's strengths and avoid its weaknesses:

http://c2.com/ppr/about/author/kent.html

3.     Smalltalk Best Practices Pattern Language, Kent Beck, Here is an intro : http://c2.com/ppr/best.html

4.     Patterns for Framewokr Evolution, Don Roberts, Ralph Johnson

5.     User defined Product Framework, Ralph Johnson

6.     Hotdraw Patterns, Ralph Johnson

 

1997

7.     Experiences -- A Pattern Language for User Interface Design

By Todd Coram and Jim Lee

8.     A Development Process Generative Pattern Language

Jim (Cope) Coplien, Bell Laboratories

9.     An HTML 2.0 Pattern Language

Robert Orenstein.

10.   Pattern Language for Framework Construction

Shai Ben-Yehuda (shai@sela.co.il)
A Data Flow Pattern Language

Dragos-Anton Manolescu (daman@ncsa.uiuc.edu)

11.   A Pattern Language for Workflow Systems

Kyle Brown (kbrown@ksccary.com) and Gerard Meszaros (gerard.meszaros@acm.org)
cOOherentBPR- A pattern language to build agile organizations

Michael A. Beedle (beedlem@fti-consulting.com)

12.   The Layered Agent Pattern Language

Elizabeth A. Kendall (kendall@rmit.edu.au), Chirag V. Pathak, P.V. Mural Krishna, C. B. Suresh

13.   Roundabout, A Pattern Language for Recursive Programming

Eugene Wallingford (wallingf@cs.uni.edu)
Application Scenario - A Pattern Language For Business Process Control S. Ramesh

14.   Telecommunications Input and Output Pattern Language      Bob Hanmer, Greg Stymfal

15.   A Pattern Language of Statecharts      Sherif Yacoub, Hany H. Ammar

16.   The HiStar Pattern Language for Hierarchical Query     F Nelson Loney

17.   Telephony Data Handling Pattern Language    David DeLano

18.   Tropyc: A Pattern Language for Cryptographic Software     Alexandre Melo Braga, Cecilia M. F. Rubira, Ricardo Dahab

19.   A Pattern Language for Simple Embedded Systems    Mark Bottomley

20.   A Mini-pattern language for Distributed Component Design Kyle Brown,  Philip Eskelin,  Nat Pryce 

21.   Deconstructing the Domain: A Pattern Language for Handling Large Object Models ( pdf, abs )    Eric Evans

22.   Constructing the Domain: A Pattern Language for Object Oriented Software Design ( pdf, abs )    Eric Evans

23.   Envoy A Pattern Language for Managing State in a Functional Program     Eugene Wallingford

24.   The Language of the Shepherds A Pattern Language for Shepherding ( pdf, abs )    Neil Harrison

25.   Pattern Language for User Information feed-back ( pdf, abs )    Christophe Addinquy

26.   Jini Community Pattern Language ( pdf, abs )    Richard P. Gabriel,  Ron Goldman

27.   The Planet Pattern Language for Software Internationalisation ( pdf, abs )    Michael J. Mahemoff,  Lorraine J. Johnston

28.   A System Composition Pattern Language ( pdf, abs )    Thomas R. Marzolf

29.   A Pattern Language for Business Resource Management ( pdf, abs )    Rosana T. Vaccare Braga,  Paulo Cesar Masiero,  Fernão S. R. Germano

30.   Rule Object: A Pattern Language for Adaptable and Scalable Business Rule Construction  (abs, pdf)     Ali Arsanjani

31.   The Collection-View Model: A Pattern Language for Software Reuse Tools  (abs, pdf)

Colin A. Depradine,  Brian G. Patrick, Michel de Champlain

32.   Real Time and Resource Overload Language  (abs, pdf)    Robert S. Hanmer

33.   A Pattern Language for Mobility Management (abs, pdf)    Rossana Andrade, Luigi Logrippo,  Mark Bottomley and Todd Coram

34.   Synthesizer. A Pattern Language for Designing Digital Modular Synthesis Software  (abs, pdf)34.1.                    Thomas V. Judkins  and Christopher D. Gill

2001

35.   Rule Object 2001: A Pattern Language for Adaptive and Scalable Business Rule ConstructionArsanjani  document

36. A Pattern Language for J2EE Web Application DevelopmentdocumentC. Richardson 

37.  A pattern language for security models E. B. Fernandez, X. Yuan  document

38.  A Pattern Language for Radio Resource Management, R. Andrade, L. Logrippo  document

39.  A Pattern Language for Online Auctions Management, R. Re, R. T. V. Braga, P. C. Masiero document

40.  A Pattern Language for Key Management, S. Lehtonen, J. Parssinen document

41.  A Pattern Language To Visitors,Y. Mai, M. de Champlain  document

 

EuroPLoP 2001

42.  Three Patterns from the ADAPTOR Pattern Language,Alan O’Callaghan

43.  A Pattern Language for Distributed Object Computing,Frank Buschmann Frank.Buschmann@mchp.siemens.

44.  Sessions,Kristian Elof Sørensenelof@elof.dk

45.  Server-Side Components: A Pattern Language,Markus Völter markus.voelter@mathema.de

 

46.  Ad Hoc Networking Pattern Language,Michael Kircher Prashant Jain Michael.Kircher@mchp.siemens.de , Prashant.Jain@ggn1.siemens.co.in

47.  A Pattern Language for Component-based Development and Integration, Ali Arsanjani arsanjan@us.ibm.com

48.  APLRAC: A Pattern Language for Designing and Implementing Role-Based Access Control , Saluka R. Kodituwakku sakoditu@cs.rmit.edu.au

49.  Patterns Language for Protocol Systems, Juha Pärssinen juha.parssinen@vtt.fi

50.  Component Design Patterns: A Pattern Language for Component-Based Development

51.  Pedagogical pattern language, Markus Voleter, Astrid Fricke www.voelter.de/seminars

52.  Server component architecture, Markus Voleter, http://www.voelter.de/publications/scp.html

53.  Software for Your Head is the first publication of the most significant results of the authors' unprecedented five-year investigation into the dynamics of contemporary teams.  http://www.softpro.com/0-201-60456-6.html
54. RAPPeL: A Requirements Analysis Process Pattern Language for Object Oriented Development, Bruce G. Whitenack, Jr..

 

How-to : “What Makes a great Pattern Language?”

Ward Cunningham

1) Pick a whole area, not just one idea. I like subject matter that is practical but seldom explored in a text book. You know, the kind of stuff you have to learn from your colleagues on the job. The discussion on the "patterns" list got me thinking about checking data.

 

2) Make a list of all the little things you have learned through the years about the area. Imagine that your kid brother has just taken responsibility for this area on his first big job. You're getting together this weekend. What are you going to tell him. Make a list.

 

3) Cast each item on your list as a solution. I like to write a sentence with "therefore" in the middle. You will have to think a little deeper here to figure out the forces that bear on your solutions. It's ok to speculate. I find this to be a rewarding activity since I often find new reason for what I do.

 

4a) Now write each item as a Pattern. I've come to favor a four paragraph form where the second paragraph ends with the pivotal "therefore:". This is a good time to flip through Alexander's Pattern Language. I feel my work has always improved when I more closely mimic his style. I'm just now learning to make the first and last paragraphs carry weight. These are the ones that link a pattern with others in the language.

 

4b) Organize your patterns into sections. Write a little introduction to each section that lists each pattern by name. You may find you need to adjust your linking paragraphs as you study the higher level structure of your patterns. Try to keep 4a and 4b fluid as you write. As you become more familiar with your patterns you may find that they organize themselves.

 

5) Now write an introduction to your pattern language that hints at the forces you will be addressing. Pick a good name too. And send a summary to the "patterns" mail list.

Gabriel

We sat down together late last year and made a map of the patterns we were pretty sure were in the language… We've dropped the requirement that there be 3 known uses - in fact, we don't care whether there are any uses at all. We are free to make up new things.

Doug Lea

most collections that you can accuse of being pattern languages
ultimately rely on a set of "principles"/"theory"/"domain knowledge"/etc.
This is especialy so at the infrastructure level I mainly work at.
Doug Schmidt et al's POSA2 book alludes to some of this as well.

Mark Grand

distinguish between the maturity of the description and frequency of the pattern's occurrence, we will be in good shape.
Ali Arsanjani

There are at least two: proto-patterns (I think this is a good solution,
I've seen it many times) and patterns (this is a good solution because I've
"been there done that" and so have a number of other people, all with pretty
good results).

The rest seems to be a spectrum.

One might also argue that there are various States of a Pattern starting
from fledgling or proto-pattern and going up all the way to be part of a
pattern society or group of collaborating patterns within a pattern
language.

Characteristics:
1. Thumbnails- short tabular descriptions of what each pattern does
2. Graphical relationships: how patterns are related; when you transition from one to resolve the forces by introducing another..
Ralph Johnson

Asking "what makes a great pattern language" is like asking "what makes
great literature".  It cannot be answered quickly. 

Note that a lot of the papers that are labeled a pattern language are
not.  For example, Coplien's process patterns are true, valuable, and
important.  But they are not a pattern language.  There are too many
holes.  A pattern language has to be complete in some sense.  His language
might be complete if you are a Lucent programmer, because they might
take for granted things that other people find difficult.  For example,
Cope doesn't talk about reviews or version control.  He doesn't talk
much about training or how to deal with novices.  This doesn't matter
if you are at Lucent, because they have standard ways of dealing with
these issues that work well.  But I could not give it to my students
and have them be any better at managing a project then they were before.

To me, the important characteristics of a pattern language
are that it tells you how to do things.  The patterns are all
related to that goal.  Moreover, there are enough patterns
that you actually have a chance of reaching your goal  The
problem with this is that each pattern lives in a context of
other patterns.  So, every language will be imcomplete, because
at some point you have to assume that your readers understand
what you are talking about.

My OOPSLA paper talks a bit about what makes a pattern language
different from a collection of patterns.  Note that it was written
many years before the GOF book!  The patterns are all related to
each other.  You can traverse the language and generate a design.
One pattern should solve problems raised by other patterns.
..."But if you think of XP as a set of process
patterns, it is a very well defined pattern language that is
Alexanderian in many ways.  In particular, it is generative.
There are no patterns for reliability or ease of understanding,
but the "practices" work together to generate systems that are
reliable and easily understood.  Like patterns, each practice
has a name and can be learned on its own.  Like patterns, practices
work together and the whole is greater than the sum of its parts.
It is extremely iterative, and plans as little as possible. 

So, in my opinion, XP is a pattern language for software development
that shows how to use Alexander's style of development for software."
-email to patterns discussion group feb 10, 2002

 

 

References

 

http://c2.com/ppr/about/patterns.html

References to reality

 

From:  "michael carlson" <linguophile@h...>
Date:  Tue Jul 4, 2000  12:24 am
Subject:  re: pattern langauge

 


thanks for responding. let's not wait for a book club...let's start talking
here, now.

i'm a carpenter here in madison. the company for which i build just
completed a house for the parade of homes, in 'site 175,' which is suppossed
to represent the affordable parade homes. i'd like to share some
observations of the experience. i do not intend for this to be a bromide
against the evils of developers or contractors, as i dont find this
productive or very useful. but here they are, nonetheless:

1) while feeble attempts were made by some builders to produce homes that
met certain qualifications of madison's 'green built' program, no one house
was designed sustainably. i watched day in and day out how much waste each
site generated (you'd have to see this to beleive it). i watched as houses
were built -- and built a house myself -- irrespective of the surroundings
and orientation. any passive solar heat gain, for example, was incidental,
not intentional.

2) the neighborhoods in which the parade homes are built are not
communities. they are instead living catalogs for the builders and
developers. as such, no real 'feeling of life' exists within these
neighborhoods (despite the fact that they are marketed as 'madison's most
exclusive communities').

3) the design of the homes themselves bear little relation to the folks that
eventually purchase them. this is not to say that certain houses did not
contain pleasing elements of design ( i like to think that ours did, at the
very least). however, none of the houses (including ours) was built for a
person, or a family. instead, the houses were built to be sold. this is
important.

4) because the houses are built to be sold, rather than built for people,
the techniques, materials, and design of every house was for the most part
completely standardized and repetitious. the houses are built for everyone,
and therefore no one; therefore, experimentation in materials and
techniques is to some very palpable extant discouraged... the marketplace
almost forbids it.

5) alternative methods of construction exist, which, if widespread and
mainstream, could conceivably cause the cost of housing to lower
substantially. for example, when material costs drop, housing costs drop.
materials such as straw and hemp are both renewable and easily harvested.
indeed, they are conceivably inexhaustable. widespread use of them as
materials could lower costs of housing dramatically. another example: these
materials, coupled with energy-efficient design, would substantially lower
the costs of heating and cooling, thus making housing even more affordable
for low-income folks.

6) the location of the parade neighborhood itself would practically prevent
affordable housing. the neighborhoods are far removed from city centers,
which essentially prohibits affordable, reliable mass transportation with
which to get to jobs, shopping, entertainment, etc. community disintegrates
there.


that's probably enough rambling for now. i acknowledge, and hope you do as
well, the relative subjectivity of these observations. but i do think they
are good starting points for discussion.

so let's discuss! :)

MC
________________________________________________________________________