Skip to content

Modeling Patterns, Part 1: What should we model?

October 1, 2010

This is the start of a 3-part look at the modeling of patterns. In this first installment, we discuss what we should capture in models as we use patterns.

When modeling, we need to focus on content and intent.  That is, we need to consider what information we are trying to capture and the purposes for which we will use that information. These should be the main drivers in defining the level of effort and details in our modeling. This approach applies to modeling software solutions in general as well as how to model patterns. We want to do the things that make sense and add value – things that help us successfully deliver software. We focus on being pragmatic. What makes sense for our situations? What makes sense for those that will consume the models?

We can split pattern modeling into two cases: modeling pattern definitions and modeling pattern instantiations (or applications). We can relate this back to the idea of a class and an object within object-oriented analysis and design. The pattern definition is similar to the concept of a class, while a pattern instantiation is similar to the concept of an object (an instance of a class).

In the case of a pattern definition, we are focused on clearly explaining to others what the pattern is, how it works, points of variability (also called roles), structure, behavior, etc. However, it is not connected, or bound, to any specific solution.

In the second case, our focus is on how a specific pattern is used within a solution. More specifically, how is that pattern bound to the solution? What are the elements from the solution that are bound to the roles provided by the pattern? We are not looking to communicate all of the details related to the pattern – only those that best help us to understand how the pattern is being used; our focus is on the interaction between the solution and a specific instance of the pattern. If we require more details on the specifics of the pattern itself, we can always refer back to the pattern definition.

In supporting both cases, here are a few considerations to keep in mind:

  • We can vary the amount of detail that we include in the diagrams. The level of detail is highly dependent on the intent of the modeling.
  • As there are similarities between classes/objects and pattern definitions/pattern occurrences, we can look to use many of the techniques that we use in modeling classes and objects and use them as we model our patterns. Class diagrams – using classes, interfaces, and collaborations, composite structure diagrams and structured classes – even sequence diagrams.
  • We can use PBE Patterns and Guidelines such as Communicate Design with Patterns, Document Pattern, and Use Pattern Definitions to Understand Existing Solutions.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: