Patterns are represented in UML using the familiar class/object and interaction diagrams, and also using the more specific parameterised collaboration model [11]--allowing the variation of roles around a given collaboration. While these representations are useful for understanding a pattern and guiding through its implementation, they only express the structural aspects of the pattern. They do little to help the engineer understand its higher-level concerns, like its intent, applicability and tradeoffs. Unsurprisingly, UML is not suitable for pattern representation for the purpose stated in this paper. As a simple example, consider the strategy and state patterns. Although their intents [4] are very different, they exhibit a similar structure.