IF you find yourself in CONTEXT for example EXAMPLES with PROBLEM entailing FORCES THEN for some REASONS apply DESIGN FORM AND/OR RULES to construct SOLUTION leading to NEW CONTEXT and OTHER PATTERNSGraphical notations can help, expecially with showing relations among pattern objects/classes. But they are not sufficient.
We need to give several types of information about the problem domain, the forces acting in the sytem, and the resolution to which a pattern is to be applied.
This is not the only format used to describe design patterns but it is a popular one, from the GoF text.
|name and classification||classification by "creational", "structural", "behavioral"|
|intent||what does the design pattern do? rationale? what design issues or problems does it address?|
|aka||names that are common as alternatives|
|motivation||scenario to illustrate a design problem and how this pattern solves it.|
|applicability||situations in which this pattern may be applied? examples of poor design to which it may be applied? how can one recognize when to use this pattern?|
|structure||graphical representation of classes (UML)|
|participants||classes and responsibilities|
|collaborations||how do these participants interact?|
|consequences||how does the pattern support the objectives? trade offs when using the pattern? what system structures may be varied independently of the pattern?|
|implementation||pitfalls, hints, for using this pattern... language-specific issues|
|sample code||as extra illustration|
|known uses||from real systems. Need at least two frm different domains.|
|related patterns||are there similar patterns; though related, what are the essential differences? what other patterns are generally used with this one?|