Modeling Patterns, Part 3: Pattern Instantiations
So far in this series we’ve discussed the importance of:
- Modeling as it makes sense and adds value while focusing on content and intent.
- Differentiating between pattern definitions and pattern instantiations.
- Modeling structural and behavioral aspects of pattern definitions.
In this part, we’ll focus on modeling pattern instantiations. Modeling pattern instantiations has 3 main purposes:
1. Document that a given pattern has been used in the current design
2. Simplify the design documentation. We abstract away details that are not needed. Once we have the definition available – we only need to highlight where that pattern is used – we don’t need to show all of the details behind the pattern each time it is used.
3. Prepare the model to be transformed into code or any other text-based artifacts either using code generators or pattern implementations.
For example, consider the use of the Self-Service pattern from the IBM Patterns for eBusiness. We model the pattern definition once, describing the different roles involved in the pattern and then when applying we have just to use the pattern name and bind the model elements to the role they play in the pattern.
We only need to consider cases where the same pattern is used multiple times in a single model. In these cases, we gain additional benefits, including:
- Each application of the pattern takes less effort to model
- The focus is on the interaction of the pattern with the elements in the model that bind to the pattern
- When\if the pattern is updated, we have a central location where we can update the definition – and we only update it once. The instantiations may also need updating, but these changes should be minor as we are dealing with the exposed interface of the pattern rather than the inner workings of the pattern.
We need to keep in mind that communication is a key goal of this effort. When we use pattern application modeling, we need to have a common definition of the pattern and its related roles. It could be a pattern definition model as we discussed previously or a clear pattern specification. The important aspect is that when people on your organization see your pattern application model, they need to understand what the different elements mean.
Figure 1 – Modeling Application of the Self-Service Pattern
As for any kind of modeling, the formality of the modeling depends on how we plan to use the modeled information. If you plan to use it as guidance to developers you will not need as much formality compared to cases where you automatically generate other artifacts using a pattern implementation. We’ll take a look at modeling of patterns in situations where we will be using pattern implementations and automating generation of artifacts in a future posting.