Sender: patterns-discussion@cs.uiuc.edu From: raphael@lash.mitre.org (Raphael Malveau) Subject: Re: Different levels of design patterns ... X-Comment: Discuss theory and application of patterns I was discussing a similar issue with Tom Mowbray and Diane Mularz. I feel that Coad's "patterns" are a useful way of documenting his approach to OOA. They are not component in nature in that you can't take them and either use them to generate something you can immediately use, nor can you really apply his patterns in a truly systematic/generative progressive way to generate something concrete (like, ideally, a solution to a specific task). Rather, his "pattern language" describes the background and forces involved in OOA/OOD and explains why the steps in his technique are made. I am not interested in analyzing rather such patterns are useful, but I do also feel that they are considerably different than the ones in the Gang of Four book. Here are some thoughts on the subject from about a month ago. ------------------------------------------------------ Last night I was also thinking about why patterns are not being universally accepted by the computer community and feel a big part of it is the confusion generated by referring to patterns for a whole class of concepts. Also, the confusion about what may or may not be a pattern may be part of what's limiting the documentation of existing patterns. People see several examples and no clear overall structure or definition of patterns really emerge. And the issue is more than just the style of the pattern. The type of pattern defines its purpose and audience for a pattern and ... Well, here are what I see as three classes of patterns and how they are related: Types of Patterns Generative - Contains a solution that involves the application of several patterns, often repeatedly. Often is a framework for how to do a particular task. There is more emphasis on context and a larger amount of domain knowledge is required to fully understand how to apply them. Descriptive Pattern - Generally contains more information of the pattern background and the forces that influence the use of a pattern or pattern language. Often documents existing systems. Mainly explains why decisions were made (or are to be made- the difference is purely syntactical). Often, the solution does not follow naturally . Component - The primary focus is on the solution. Background is often brief and to the point. Generally, a "software template" that specifies a good design. Gang of Four patterns. less domain more domain knowledge knowledge | | | |------------------------|-----------------------| | | | Component Descriptive Generative Raphael ================================================================== Raphael C. Malveau E-Mail: raphael@mitre.org MITRE Corporation - Workstation Systems Engineering Center 7525 Colshire Dr., M/S Z267 Office: 703-883-3691 McLean, VA 22102-3481 FAX: 703-883-3315 Sender: patterns-discussion@cs.uiuc.edu From: Richard Helm Subject: Re: Different levels of design patterns ... Dr Winnie Pun writes... > I am reading the Design Pattern book by the 'Gang of 4'. At > the same time, I am reading some papers written by Coad on > patterns. It strikes me that the patterns discussed by > the Gang of 4 and that by Coad are at different level. Yep. > The patterns described by the 'Gang of 4' are more software > architectural things whereas that described by Coad are more > application level things. As a developer, I can see the > usefulness of those described in the Design pattern book. > However, I am sceptical about the application level patterns > described by Coad. Anyone out there shares this feeling? The GOF book does indeed aim much more at the developer, and that says alot about where the GOF were coming from when we wrote the book. Gustavo Rossi makes the point precisily. > Well, in fact Coad's patterns are far less elaborated than the ones in the > gang-of-4's book. However, some of them are also used every day; > (item-description for example). > May be Coad was thinking about "analysis patterns" and that's why they are > expressed in a different level of abstraction. Analysis patterns are indeed at different levels of abstraction! I have see patterns in requirement statements which are at a different level again. Re: the degree of elaboration, I thinks reflects the difficulty and effort required to write patterns to sufficient level of detail that they are useful. Finding patterns is easy. Writing them down so others can understand them is hard and takes a long time. I think this is much harder the higher the level of abstraction and the bigger the concepts you describe. .. richard -- Richard Helm: Richard.Helm@dmr.ca DMR Group, 1200 McGill College Ave., Montreal, QC, H3B 4G7, Canada Client: Phone: 514-738-8300 ext. 2195. Fax: 514-345-7982 DMR: Phone: 514-877-3301. Fax: 514-877-3351 Date: Fri, 2 Dec 1994 12:08:33 -0600 Sender: patterns-discussion@cs.uiuc.edu From: Steve Berczuk Subject: Re: Different levels of design patterns ... There certainly are a wide variety of ways to document patterns, which makes sense, given the short time the idea of patterns has been in wide circulation. There are also, as Raphel and others have noted, different types of patterns at different levels of abstraction, and it is not clear at this point that any one form will work for all levels. GOF format works quite well for the "component" patterns in the GOF book. >From what I recall from discussions at PLoP one of the BIG questions was how/when to come to agreement on the format/content of patterns. Aside from agreeing on the essential elements of a pattern (problem, context, solution) there was not much else EVERYONE could agree on (there was even some issue as to the absolute utility of a standard format..). There did seem to be a feeling that the best way to arrive at the answer was to develop experience at documenting patterns, and see what works. Asking the question of " what may or may not be a pattern" confuses the documenting or patterns with the patterns themselves A Pattern is "a solution to a problem in a context" (or words to that effect). How best to write down and index the patterns is the hard question, but that by itself should not devalue the idea of "patterns." On Fri, 2 Dec 1994, Raphael Malveau wrote: > Last night I was also thinking about why patterns are not being > universally accepted by the computer community and feel a big part of > it is the confusion generated by referring to patterns for a whole > class of concepts. Also, the confusion about what may or may not be a > pattern may be part of what's limiting the documentation of existing > patterns. People see several examples and no clear overall structure > or definition of patterns really emerge. And the issue is more than > just the style of the pattern. The type of pattern defines its purpose > and audience for a pattern and ... Well, here are what I see as three > classes of patterns and how they are related: I understand the classification system below is getting at, but I am not sure that agree with the details. It seems that these classifications specify different levels of abstracton (Component the lowest, and Descriptive the highest) In the case of descriptive patterns (as defined below) if the solution does not follow naturally given the appropriate background then there is something wrong with the pattern. Also, a valuable pattern will always describe experience gleaned from (a set of) existing system(s) (or a component of an existing system...). Also, the author of a pattern should be aware of the amount of domain knowledge of the audience, and should frame the context section appropriately. Thoughts? -steve --- Steve Berczuk -berczuk@mit.edu | MIT Center for Space Research NE80-6015 Phone: (617) 253-3840 | Fax: (617) 253-8084 Date: Fri, 2 Dec 1994 15:27:28 -0600 Sender: patterns-discussion@cs.uiuc.edu From: raphael@lash.mitre.org (Raphael Malveau) Subject: Re: Different levels of design patterns ... Allow me to frame the context and forces of the discussion the resulted in my writing my comments. I missed OOPSLA in September where the Gang of Four book was released (I did arrange to get a couple of copies picked up though!), pattern workshops were held and where there was a great deal of pattern discussion. When de-briefing colleagues who had attended, I was told that the introduction of patterns met with mixed reviews. While that is typical of just about anything, I insisted (and foolishly still insist) on being disappointed that patterns weren't immediately embraced by the software industry at large and declared the inevitable progression of enlightened software development. So post-OOPSLA I went around and talked to people who were recently exposed to patterns and talked to them. Basically, there was a great amount of difficulty in relating information from the pattern workshops to Coplien's articles in Object Magazine, C++ Report, and Dr. Dobb's and Beck's in Dr. Dobb's and the Gang of Four book, and Coad's patterns, etc and finding the common threads to tie the pattern concept back into their own domain. I used to believe that the difference between "styles of patterns" was simply in the level of abstraction but I have a gnawing feeling that says there is more to it than that. Rather, the authors are employing different processes to say different things. That is, the intent of the software features described drive the level of abstraction rather than the level of abstraction dictating the way the pattern is described. For example, Coplien's Development Process Patterns are at the approximate level of abstraction as Coad's Object Modeling pattern. Yet, Coplien's patterns are clearly generative. A set of problems have been clearly identified and the pattern language addresses the problems, identifies the forces, and proposes a solution. Bada-bing Bada-boom. Coad's patterns effectively asks you to search out the problems. I'll pick on the pattern of collection-worker, his fundamental object modeling pattern. There is a description of it. There are forces to examine what might lead you to believe a set of objects can be modeled "using" the collection worker pattern. There is a "process" of examining the forces. However, there is no process to take the problem of developing an object model and generating said object model. Rather, there are rules of thumb of applying judgement to get an object model made up of structures that "match" the patterns. And of course, good judgement = good object model and bad judgement = bad object model. Hence, my characterization of his work as descriptive vs Coplien's generative work. While someone may claim the terms simply avoid characterizing patterns as "good" or "bad" (and there may be a good deal of truth to that), I simply need a crutch to lean on when explaining patterns to people who have postponed the inevitable pattern familiarization process for too long. Also, when writing patterns, it is important to clearly define your intentions. It is not enough to simply say, "I know how to do something well, let me write a pattern". Rather you need to decide whether you are describing a software structure (component), describing a process that enable you to solve a problem (generative), or describing a system, that is, a collection of components and processes that work to accomplish a goal/solution (descriptive). It was difficult for me to write patterns until I was able to clearly identify my intent. While you could correlate abstraction with intent, there is no reason why you couldn't discuss a large system as a component, or have a descriptive pattern for an organization or a generative one for object modeling. An example is an object request broker. You could view it as simply a component that serves as an intermediate agent between clients and servers. The same Object Request Broker(ORB) could be described descriptively as something that encapsulates and provides transparency for object location, activation, and policy. Also, it could be viewed generatively, as a way of developing a distributed system by breaking it down in a language where each piece discusses a sub-problem that the ORB solves with a solution that goes a bit into how an ORB implementation solves that specific problem. I've developed component and descriptive patterns for an ORB (I'll try and post them in Jan.) and would like the time to work on a generative pattern language for it. Anyway, I have a tendency to babble incoherently at times and for that I apologize. I just wanted to throw out terms that I have been using to talk about the various types of pattern literature that has been available lately. I'd be the first to agree that classification of patterns should take place after I have enough "stuff" to classify to at least fill a bookshelf... Raphael p.s. BTW, just in case no one knows what the heck I'm talking about here are a few places where the patterns mentioned above have been discussed: Dr. Dobb's Journal Feb. 1994 "Patterns and Software Design" by Kent Beck. Object Magazine July/Aug 1994 "Pattern Languages for Organizational Process" by James Coplien C++ Report July/Aug 1994 "Software Design: The Emerging Patterns" by James Coplien Dr. Dobb's Journal Oct. 1994 "Examining the Software Development Process" by James Coplien And I think Peter Coad mentions his Object Modeling Patterns in a Communications of the CACM- maybe a Sept. issue of 91 or 92. Doesn't anyone keep a list of these things or is there some taboo against periodically mentioning non-book, non-ftp, non-Mosaic sources for pattern info? :) ================================================================== Raphael C. Malveau E-Mail: raphael@mitre.org MITRE Corporation - Workstation Systems Engineering Center 7525 Colshire Dr., M/S Z267 Office: 703-883-3691 McLean, VA 22102-3481 FAX: 703-883-3315 Date: Fri, 2 Dec 1994 16:52:14 -0600 Sender: patterns-discussion@cs.uiuc.edu From: Richard Helm Subject: Re: Different levels of design patterns ... > I was told that the introduction of patterns met > with mixed reviews. While that is typical of just about anything, > I insisted (and foolishly still insist) on being disappointed that > patterns weren't immediately embraced by the software industry at > large and declared the inevitable progression of enlightened software > development. I truly think it is early days yet, not a lot of understanding as to what patterns are, and over hyped-ness of a an idea which is new and struggling to define itelf before everyone jumpson it. > I used to believe > that the difference between "styles of patterns" was simply in the > level of abstraction but I have a gnawing feeling that says there > is more to it than that. Rather, the authors are employing different > processes to say different things. That is, the intent of the > software features described drive the level of abstraction rather > than the level of abstraction dictating the way the pattern is > described. > I simply need a crutch to lean on > when explaining patterns to people who have postponed the inevitable > pattern familiarization process for too long. How I explain patterns is that we all have experience/expertise which is useful for others and which you use over and over again. There is value to write this experience down so that others can reuse it. I think most people who write patterns want to communicate this experience so others may reuse it. The question which you raise is "what is the best form? I am not sure how much it has to do with what you are describing. But the level of completeness of what you are describing and how it relates to a particular problem. The typically less understanding tends to generate more "descriptive" patterns. The better the understanding you have the more generative or prescriptive the patterns become. We certainly noticed this while writing the book. The more we banged away, the more interesting relationships between patterns we discovered. The more the relationships became prescriptive. As we discovered more design patterns and used them more the richer they become and intertwined. As we did this the sections and what we felt was important to describe also changed. > Doesn't anyone keep a list of these things or is there some taboo > against periodically mentioning non-book, non-ftp, non-Mosaic sources > for pattern info? :) Laziness probably. Thank you for this list. A great service for many! -- Richard Helm: Richard.Helm@dmr.ca DMR Group, 1200 McGill College Ave., Montreal, QC, H3B 4G7, Canada Client: Phone: 514-738-8300 ext. 2195. Fax: 514-345-7982 DMR: Phone: 514-877-3301. Fax: 514-877-3351 Date: Sat, 3 Dec 1994 01:46:11 -0600 Sender: patterns-discussion@cs.uiuc.edu From: girod@trshp.trs.ntc.nokia.com Subject: Re: Different levels of design patterns ... > It seems that these classifications specify different levels of > abstracton (Component the lowest, and Descriptive the highest) This is the basis of my problem. Would anybody try and justify why it seems so obvious that there are 'levels of abstraction'. This is over and over admitted as god's law. This very idea of a universal direction from low-level to high-level strikes me over and over as non-sense. You are in a situation. You abstract from it some features that you believe relevant in some other situations you have met. You do that for your purpose. Usually, you are not conscious of the exact scope in which you apply this abstraction: this is the very reason for which it is efficient to make any abstraction, you are relieved from the burden to think to non relevant things. The point is that if somebody else abstracts other things from the same situation, there will be no way to compare the 'level' of your two abstractions: this does not make sense. A descriptive level implies somebody to whom the description is made. It is not per se 'higher level' than the 'component level'. It even introduce other bindings. In short: both 'level' and 'abstraction' are useful concepts. A priori, 'level of abstraction' is not one. -- +-----------------------------------------------------------------------------+ | Marc Girod - Nokia Telecommunications Phone: +358-0-511 7703 | | TL4E - P.O. Box 12 Fax: +358-0-511 7432 | | SF-02611 Espoo 61 - Finland Internet: marc.girod@ntc.nokia.com | | X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc | +-----------------------------------------------------------------------------+ Date: Sat, 3 Dec 1994 08:59:29 -0600 Sender: patterns-discussion@cs.uiuc.edu From: dl@g.oswego.edu (Doug Lea) Subject: Re: Different levels of design patterns ... I don't know how to classify pattern styles. Maybe it's not worth doing so. But even still, you can compare individual patterns on lots of factors. Just for fun, consider the list below. [ ] Describes a single kind of problem. [ ] Describes the context in which the problem occurs. [ ] Describes the solution as a constructable software entity. [ ] Describes design steps or rules for constructing the solution. [ ] Describes the forces leading to the solution. [ ] Describes evidence that the solution optimally resolves forces. [ ] Describes details that are allowed to vary, and those that are not. [ ] Describes at least one actual instance of use. [ ] Describes evidence of generality across different instances. [ ] Describes or refers to variants and subpatterns. [ ] Describes or refers to other patterns that it relies upon. [ ] Describes or refers to other patterns that rely upon this pattern. [ ] Relates to other patterns with similar contexts, problems, or solutions. Date: Sat, 3 Dec 1994 20:27:16 -0600 Sender: patterns-discussion@cs.uiuc.edu From: Greg Wilkins Subject: Re: Different levels of design patterns ... > From: girod@trshp.trs.ntc.nokia.com > > You are in a situation. You abstract from it some features that you > believe relevant in some other situations you have met. You do that > for your purpose. Usually, you are not conscious of the exact scope in > which you apply this abstraction: this is the very reason for which it > is efficient to make any abstraction, you are relieved from the burden > to think to non relevant things. > > A descriptive level implies somebody to whom the description is > made. It is not per se 'higher level' than the 'component level'. It > even introduce other bindings. > > In short: both 'level' and 'abstraction' are useful concepts. A > priori, 'level of abstraction' is not one. But if the "situation" you are in is built from abstractions that you or somebody else has built, then the abstractions that you create have the original abstractions as axioms to your abstractions. The original abstractions may be totally hidden by your abstractions and it could be an error for a users to design/code using the original abstractions. See it is even difficult to describe without using terms like "lower level of abstraction". I agree that you can have levels without abstractions and abstractions without levels, but you certainly can have layered abstractions. The example that comes to mind is an OO communications framework: Abstract event handler + scheduler + dispatcher used to created concrete file description handler + dispatcher used to make abstract connection handler + framework used to make concrete comms layer for sockets. used to make abstract object to object comms layer. used to make concrete object to object layer (eg CORBA stubs) used to make abstract GUI Object Manager framework used to make concrete GUI application The lower level of abstraction (event handling) is hidden by the connection abstraction. But the connection abstraction is dependant on it, so changes in the lower layer abstraction could effect the upper layer of abstraction. Furthermore, it could be an error to mix handling of comms layer style callback and event handler call backs as they represent different levels of abstract events. To describe these dependancies and possible errors it is easier to use "layers of abstraction". Note, I agree that with or without abstractions, layers need a defined context to make sense. Indeed layering is just another abstraction and all abstractions need context to make sense. -gregw ------------------------------------------------------------------------------- Greg Wilkins:Consultant for Object Oriented Pty. Ltd. (OOPL)|You're not Dorothy Site @Telecom, Intelligent Network Development |I'm not Toto! Snail:P.O. Box 1826,North Sydney,NSW.2089, Australia |And this Email:gregw@ind.tansu.com.au (gregw@oose.com.au) |definitely is Fax :(+61 2) 3953225 or OOPL Office:(+61 2) 9565089 |not Kansas! Phone:(+61 2) 3953396 or OOPL Office:(+61 2) 9571092 | -Fleischman ------------------------------------------------------------------------------- Date: Tue, 6 Dec 1994 03:22:13 -0600 Sender: patterns-discussion@cs.uiuc.edu From: winnie@hel.co.uk Subject: Re: Different levels of design patterns ... > >From what I recall from discussions at PLoP one of the BIG questions was > how/when to come to agreement on the format/content of patterns. Aside > from agreeing on the essential elements of a pattern (problem, context, > solution) there was not much else EVERYONE could agree on (there was even > some issue as to the absolute utility of a standard format..). There did > seem to be a feeling that the best way to arrive at the answer was to > develop experience at documenting patterns, and see what works. > Currently, the pattern template found in the GOF book seems to be a kind of documentation format that can be used to specify a pattern. In my opinion, we need more than that. On one hand, the template kind of documentation is the starting point for clients or potential clients of design patterns to understand the basic of the design patterns. However, to be able to decide whether a pattern can be used in a certain situation, there will be some questions and answers session between the authors and the clients. As shown in the design patterns tutorial in OOPSLA, there are questions about the design of the design pattern itself. Attendees asked questions such as 'In the Observer pattern, Why do you put the subject association in the concrete objects level and not the abstract objects level?'. People actually questioned about the design decision made by the authors. I believe these kinds of FAQs play an important part in documenting a design pattern. Winnie. -- Dr Winnie Pun Advanced Software Centre Hitachi Europe Ltd Whitebrook Park Lower Cookham Rd Maidenhead Berkshire SL6 8YA Email : winnie@hel.co.uk Date: Tue, 6 Dec 1994 08:46:21 -0600 Sender: patterns-discussion@cs.uiuc.edu From: Steve Berczuk Subject: Re: Different levels of design patterns ... On Tue, 6 Dec 1994 winnie@hel.co.uk wrote: > Currently, the pattern template found in the GOF book seems to be a kind > of documentation format that can be used to specify a pattern. In my opinion, > we need more than that. On one hand, the template kind of documentation > is the starting point for clients or potential clients of design patterns > to understand the basic of the design patterns. However, to be able > to decide whether a pattern can be used in a certain situation, there will > be some questions and answers session between the authors and the clients. > As shown in the design patterns tutorial in OOPSLA, there are questions > about the design of the design pattern itself. Attendees asked questions such > as 'In the Observer pattern, Why do you put the subject association in the concrete objects level > and not the abstract objects level?'. People actually questioned about > the design decision made by the authors. I believe these kinds of FAQs > play an important part in documenting a design pattern. Hmm, it seems to me that the rationale behind the pattern should be evident from the motivation/context of the pattern. If it is unclear from the pattern as stated, this means to me that either 1) the pattern documentation is missing important detail in the motivation context or 2) there is some slight mismatch between the background the author intended for his/her readers and the acutal background of the readers both of these can be fixed by getting reader feedback. This is consistent with what Ralph said earlier about getting reader (client) feedback to improve pattern documentation. A FAQ format may be helpful, but I'd prefer that the exposition address the issues in the main part of the text.