Patterns in UML
Existing Pattern Representations
Existing Pattern Representations

PDF version   PostScript version

Informal Representation

Patterns are most generally represented in natural language, and are typically published in printed catalogues. The term ``presentation'' seems more suitable for this type of description. Such documents are loosely structured, in what we call canonical forms. Such a structure consists of a series of fields, each having a meaning introduced via an informal definition or description. An example of a canonical form is that proposed in [4]. A fragment of this is illustrated in Table 1, below.

Table 1: Fragment of a canonical form for pattern representation [4].

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 [10].

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.