4.3 Pattern Notation

Throughout this book design patterns need to be referenced and explained in text and illustrations. A simple notation is used to consistently represent different types of patterns.

Pattern Symbols

As displayed in Figure 4.x, slightly different symbols are used to represent:

•     a design pattern

•     a compound design pattern

•     a group of related design patterns

Additionally, colors are incorporated to indicate if a displayed design pattern is just being referenced and not actually discussed, versus one that is the current topic of discussion.

Figure 4.2 – The standard symbols used to represent different types of design patterns and how design patterns relate to the current subject being covered.

Pattern Figures

The symbols displayed in Figure 4.x are used in the following three primary types of diagrams:

•     pattern application sequences

•     pattern relationships

•     compound pattern hierarchies

The pattern symbols can also be used in general diagrams wherever patterns need to be referenced in relation to other symbols (such as the oval symbols used to represent design principles). Figure 4.x at the end of this chapter provides an example of this.

LetŐs take a closer look at each of the three primary diagram types.

Pattern Application Sequence Figures

When documenting design pattern languages, it is helpful to display the suggested sequence in which patterns should be applied. Figures 4.x and 4.x show pattern application sequences for groups of related patterns and for individual patterns belonging to a particular group.

Figure 4.3 – The pattern groups from the Basic Service Design Pattern Language covered in Chapter 7. These groups are displayed in the sequence in which the language recommends they be carried out.

Figure 4.4 – The inventory structure patterns group is highlighted in this diagram taken from the Basic Service Inventory Design Pattern Language documented in Chapter 5. There are no firm requirements as to the order in which the last three patterns should be applied.

Pattern Relationship Figures

As explained in the upcoming Pattern Profiles section, this book explores numerous inter-pattern relationships, and provides one pattern relationship diagram (Figure 4.x) for each documented design pattern.

Figure 4.5 – An example of a design pattern relationship diagram.

A style convention applied to all pattern relationship diagrams is the use of color, as follows:

•     Each pattern relationship diagram explores the relationships of one pattern. Therefore, that design pattern is highlighted in red, as per the previously established symbol notation.

•     Pattern relationships are documented in a unidirectional manner. For relationships where the pattern currently being discussed affects or relates to other patterns, a red line is used along with an arrow pointing to the other pattern. When the relationship line documents how other patterns relate to the current pattern, the lines are green and the arrows are reversed.

Note that directionality of relationships is preserved in different diagrams. For example, the green relationship line emitting from Service Normalization and pointing to Logic Centralization in Figure 4.x would be reversed (and colored red) in the pattern relationship figure for the Service Normalization pattern.

Compound Pattern Hierarchy Figure

Compound patterns are comprised of combinations of design patterns. When illustrating a compound pattern, a hierarchical representation is usually required, where the compound pattern name is displayed at the top and the patterns that comprise the compound are shown underneath.

These types of diagrams (Figures 4.x and 4.x) can be considered simplified relationship figures in that they only identify which patterns belong to which compound, without getting into the details of how these patterns relate. Compound patterns are documented separately in Chapter 9, but compound hierarchy figures are displayed throughout the upcoming chapters.

Figure 4.6 – The Enterprise Service Bus compound pattern described in Chapter 9 is comprised of several core patterns, one of which (Broker) is a compound pattern in its own right and therefore represents another set of patterns. In this case the Data Model Transformation pattern is highlighted, indicating that it is the current pattern being discussed.

Figure 4.7 – There are additional patterns associated with the Orchestration compound pattern that can be considered optional extensions. In this case, the hierarchy lines are dashed.

Capitalization

All design pattern names (including names of compound patterns) are capitalized throughout this book. The names for groups of related patterns are capitalized when displayed in Figures, but not when referenced in body text.