|Field||Explanation / Definition|
|Name||Ideally a meaningful name that will be part of the shared design|
|vocabulary. Many existing patterns do not satisfy this requirement|
|for historical reasons.|
|Also known as||Other names of the pattern.|
|Intent||A short specification or rationale of the pattern, used as a principal|
|index for goal-oriented pattern search.|
|Applicability||An outline of the circumstances in which the pattern may be appli-|
|cable and, perhaps more importantly, when it should not be applied.|
|Structure||A diagrammatic representation of the pattern.|
|Consequences||Discusses the context resulting from applying the pattern. In parti-|
|cular, trade-offs should be mentioned.|
|Implementation||Advices on how to implement the patterns, and other language spe-|
|cific issues. The implementation will depend on the abstractions|
|(objects, parameterised types,...) supported by the target language.|
|Known uses||Patterns are by essence derived from existing systems. It is therefore|
|important that they be justified by their use in several real systems.|
|Related patterns||Patterns are often coupled or composed with other patterns, leading|
|to the concept of pattern language; e.g. a visitor may be used to|
|apply an operation to the closed structure provided by a composite.|
Consider, for example, the most common situation when a software developer is within a specific situation and wants to identify whether there exists a particular pattern useful to the situation at hand. A search within a repository of patterns would, most probably, involve the intent and applicability descriptors. Assuming that the catalogue exists in an electronic format that preserves the structure of the printed catalogue, as described above, then the best option available to him is a keyword search; intent and applicability have no internal structures. This means that the software engineer attempts to retrieve documents describing relevant patterns based on phrases that he would have to guess are used in the descriptors. Each time a document/pattern is retrieved, he would have to read it thoroughly--since no summarisation or explanatory features would be supported by the discussed representation--and decide upon its suitability. Obviously, this is a cumbersome process.
The drawbacks of such a retrieval process are well known. They are more critical if the agent who carries out the process does not have at least some knowledge of the descriptions' jargon or of the possible expected results; in our case, if the software engineer is a novice. Note that by novice, we mean without much software development experience, but also inexperienced with a particular technology, or new to a company and not familiar with its policies and codes.
These drawbacks have been identified and well described in the context of the web and represent a motivating factor for the development of the semantic web .
Although they have the same nature, the scale of the problem in the context of software patterns is obviously not as large as in the context of the web. However, the effects can be similarly drastic, under the founded assumption that the pattern repository has a substancial size. Furthermore, missing or misusing a pattern with respect to a particular situation could have severe implications if the patterns represent company policies or codes of best practice. The above argument was implicitly carried out at the level of application/domain specific patterns. However, it is equally valid in the context of domain independent, but language-specific patterns (idioms). A good example for this is the Javadoc documentation of the Java platform. This knowledge base is significantly large and finding relevant solutions to a specific problem is a cumbersome process for non-expert Java programmers.
Another major drawback of this representation is the fact that it does not readily support knowledge management and sharing, also necessarily required, in particular for application-domain patterns (refer to Section 2). Informal representations based on canonical forms cannot support the level of automation at which we aim. For this, we need better-structured representations.