From patterns-discussion-request@cs.uiuc.edu Thu Sep 12 11:25:17 1996
Received: from chip.cs.uiuc.edu (chip.cs.uiuc.edu [128.174.246.79])
	by amber.ccs.neu.edu (8.7.5/8.7.3) with SMTP id LAA15937; Thu, 12 Sep 1996 11:25:12 -0400 (EDT)
Resent-Date: Thu, 12 Sep 1996 11:25:12 -0400 (EDT)
Received: by chip.cs.uiuc.edu id AA03447
  (5.67b/IDA-1.4.4); Thu, 12 Sep 1996 10:04:32 -0500
From: catserv!tomj@uunet.uu.net
Message-Id: <9609121402.AA74563@catserv>
Subject: Re: Pattern Repository
To: patterns-discussion@cs.uiuc.edu (Patterns-Discussion Mailing List)
Date: Thu, 12 Sep 1996 09:02:23 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL24cjr]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-Id: <"KHHJB.0.gg.es1Eo"@chip.cs.uiuc.edu>
Resent-From: patterns-discussion@cs.uiuc.edu
X-Mailing-List: <patterns-discussion@cs.uiuc.edu> archive/latest/1125
X-Loop: patterns-discussion@cs.uiuc.edu
Precedence: list
Resent-Sender: patterns-discussion-request@cs.uiuc.edu
Status: R

Sounds like what is needed is a patterns review board to keep
down the number of patterns in the repository.

What would be good for queries on a patterns repository is:

1. The repository shall eliminate duplicate entries.
2. With regard to a set of force specifications, the repository shall:
   A. Return all patterns satisfying those forces.
   B. Rank pattern applicability to that set of forces.
3. The repository shall identify alternative related patterns.
4. The repository shall relate patterns in an unspecified number of dimensions:
   A. With regard to intent.
   B. With regard to structure.
   C. With regard to consequences.
   D. With regard to benefits.
   E. With regard to behavioral system. (Business system / domain)
   F. ...
5. The repository shall identify known solutions to a pattern's consequences:
   A. Pattern combinations.
   B. Implementation workarounds.
   C. Preferred programming language.
6. The repository shall document contained patterns:
   A. In user defined format. (allows for company specific documentation requirements.)
   B. Standard GoF format.
   C. Exportation into:
      a. Third party documentation packages:
	     1. MS/Word.
		 2. Word Perfect.
		 3. ...
	  b. Standard file formats:
	     1. Encapsulated Postscript. (.eps) (.ps) with preview.
		 2. Rich Text Format. (.rtf)
		 3. TeX format.
		 4. ...
   D. Importation from above packages and types.

Well, it looks like I started to go further than just specifing specific queries.  :)
But, any query that supports any of the above repository requirements would be 
valuable to an organization not just the organizational backbone... the programmer.

Hope this helps,

Tom Jordan
Catalyst International, Inc.
#include <stdsclmr.h>  // Definition of Reality::LegalBeagle.

Jeff Shurts wrote:
>Narayanan Sridhar wrote:
>> 
>> Hello,
>>         I would like some input on the type of queries one would
>> pose to database of patterns (in GOF style).  In particular queries
>> that a desiger can pose on psuedo-code of methods in classes or
>> collaborations in the pattern.  Thanks.
>> 
>> -Sridhar.
>
>I think this is difficult to predict, due to the dynamic nature of the
>software world right now.  The things we do today may not even resemble
>the things we'll be doing twelve months from now.  Our approach has been
>to store our patterns in a database that offers full-text search
>capabilities, in addition to nice features like hypertext links (we're
>using Lotus Notes).
>
>We have attempted to categorize our patterns as well; the catalog of
>patterns can then be viewed grouped by category.  We do mostly
>client-server database work, so our categories are things like GUI
>Patterns, Distributed Processing Patterns, and Relational Database
>Design patterns.  I expect the list of categories to change/grow over
>time, and figure the most important query tool we'll have will be the
>full-text search engine.

>
>Ideally, though, we'll keep only the most important patterns, and our
>developers will internalize them to the point where most of them won't
>need to refer to the text very often; then, when they do, they'll likely
>know exactly which pattern they're looking for.  In order to keep from
>overloading our developers with too many unimportant concepts, I'm going
>to try to keep our pattern catalog to thirty or less patterns at any
>given point in time.
>
>Jeff Shurts
>Illinois Power