Skip to content

Pattern Instance Notation – Another Approach for Modeling Patterns

June 10, 2011

We’ve talked about modeling pattern definitions and instantiations via the use of UML (Part 1, Part 2 and Part 3). These approaches provide information about how we’ve used patterns in creating solutions and since UML is widely supported, we can use this approach in our choice of UML tools. However, as UML is a general-purpose modeling language – we use and interpret standard, general elements to mean specific things when applied to patterns. Wouldn’t it be outstanding if there was a set of pattern-specific modeling constructs?

One pattern-specific approach to consider is the Pattern Instance Notation (PIN). It is still in its early days, but work is progressing on promoting this approach (including standardization\integration via the Object Management Group). Let’s take a look at this notation.

Starting with the simplest case, the following image shows the use of PIN to denote an instance of a pattern.

If we take things a step further, we specify the pattern and its associated roles, as shown in the next figure.

Within our solution we would then connect elements to the roles that they fulfill. PIN keeps things simple and focused on the relationship between the pattern, its roles and the solution elements that bind to those roles.

If we have compound patterns, we can use PIN as shown in the next figure.

If desired, UML can be used within the construct to provide further details on how the solution is realized.

To better understand how a pattern would be modeled using PIN, let’s take a look at a specific pattern – the Subsystem Façade pattern. As you’ll recall, this is a pattern that we identified, designed and developed in the PBE book. The following diagram shows how we’ve modeled the pattern using UML.

And here’s how the same pattern would be represented using PIN.

If you’d like to draw some of your own diagrams using PIN, there is a stencil available for use with OmniGraffle.

Additional Details on PIN can be found in

  • Jason McC. Smith, The Pattern Instance Notation: A Simple Hierarchical Visual Notation for the Dynamic Visualization and Comprehension of Software Patterns, Journal of Visual Languages and Computing (2011), doi:10.1016/j.jvlc.2011.03.003.

Thanks to Jason for his input on this posting, allowing reuse of his sample images depicting PIN notation and access to the PIN stencil.

Updated PBE Practice

April 10, 2011

I posted an updated version of the PBE Practice. Changes to this version include:

1. Added links from the concepts, tasks, and guidelines to the summaries of the PBE Patterns and Guidelines.

2. Fixed a few typos.

A download of the updated source has been made available (v1.01). Please drop myself or Celso a note if you have any suggestions on enhancements for the practice.

Thanks!

Summaries for the PBE Patterns and Guidelines

March 25, 2011

We’ve added a new section to the site providing a summary for each of the PBE Patterns and Guidelines (and graphical overviews). In addition to having a summary for each pattern\guideline – we’ve added links to related patterns\guidelines and tasks from the PBE Practice.

 

Guest post at the Art of Software Reuse

March 18, 2011

Just wrote a guest post over at the Art of Software Reuse. The post takes a look at some of the key things that we can do to have a successful reuse effort within the enterprise.

If you’ve not yet visited Art of Software Reuse – it’s definitely worth taking a look. I’m currently reviewing a short ebook that they’ve published looking at Agile Software Reuse.

PDF Version: Patterns and the Long Tail

March 1, 2011

In addition to the blog posting, we’ve made a PDF download available for the “Patterns and the Long Tail”. You can also access the PDF via the Download widget on the righthand side of site.

Patterns and the Long Tail

March 1, 2011

Do you ever wonder who is going to create new patterns? The short and simple answer is that you, me and everyone else should be creating patterns. The creation of patterns is one of the most important issues that we address with PBE (pattern consumption is the number one issue).  However, this is not just a technical discussion. It’s not just about which IDE, modeling tool or underlying metamodel is being considered. We need to understand why WE need to create patterns. Why should WE make the investment?

And – we need to be able to answer these questions with the understanding that we have scarce resources and multiple ways in which we can use these resources. In essence – this is a question of economics. An interesting idea that we can help us answer these questions is the concept of the Long Tail. Not only does the Long Tail have an impact on software, but it also has an impact on patterns.

Economic Reality for Software Vendors

Building on the idea that the Long Tail is applicable to software – and software development, let’s take a more detailed look at the relationship between the Long Tail and Patterns. Recognizing that there is an enormous amount of variation in organizations’ business processes we also have to recognize that without being generic, it is very difficult (perhaps impossible) to build one set of development tools that can accelerate, in a best practice approach, the development and delivery of all types of software solutions in all industries. We can envision today’s market of software development tooling being primarily focused on the mass-market end of the demand curve. The vendors look to produce tools that are specific to certain problems, but yet generic enough to appeal to a wide user base.

However, this is not a vendor shortcoming – just an economic reality. Vendors cannot provide support for every possible variation needed, nor do they have the expertise. Often times, only those in a particular industry and sometimes even within a specific company have the expertise that is needed. Think of the combinatorial explosion of possible solutions when creating a business process that is a competitive differentiator – using a combination of best-of-breed products, frameworks and integrating a set of internal and external systems. As such, what is the role and possible impact from a single software vendor in addressing this problem space? In such a situation – how could we expect a vendor to capture, automate and distribute the best practices codified as patterns?

This is where the Long Tail comes in. Yes, vendors traditionally focus on the head of the demand curve – limiting the patterns produced to only those that are widely applicable. However, they have a role in supporting others as they target the Long Tail. The key for the vendor is that while they still fill their traditional role, they also need to provide tooling and platforms that allow their customer to easily and quickly build customized tooling. That is, we need tools, standards and support for creating patterns that are specific to our needs – patterns in the Long Tail. And with this support we can thrive when producing patterns – exploiting the Long Tail to our advantage.

Exploiting the Long Tail

So as we look to produce patterns, how do we exploit the Long Tail? Let’s examine some of the key ideas that surface in the Long Tail discussion and look at how they apply to pattern production.  A good place to start is tooling. The Long Tail highlights the idea that tools to produce creative output have been greatly reduced in cost. No longer is a major capital investment required to produce creative goods. We can see how this is true with books, movies and other digital offerings. If we relate this to pattern production we see a strong parallel. There are many tools available for the creation of pattern specifications and implementations. In the case of a pattern specification – we likely already have a text editor or word processor available. For a pattern implementation – there are numerous tools available from both commercial vendors as well as from the open source community. Pricing on these tools start from free. Access and cost of tooling is not a barrier. Typically the biggest challenge we will face is figuring out the best practice solution – that is the idea that we will capture in the pattern.

In addition to having cheaper tools, the Long Tail highlights the idea that there is more talent, more widely distributed than we ever imagined. We no longer need to look to just a specific city, state, or country as the one source of talent. We live in a world that is highly connected, education is more widespread than ever, and ideas and imagination are present everywhere. If we look to the world of software development – we see that these ideas have been embraced. We have offshore, out-sourced and remote teammates. Globally distributed development is a reality with talented developers and architects located worldwide.

So with inexpensive tools and a wide distributed pool of talent – we now look at how to get them to work together. In this case, the Long Tail focuses on the idea of componentization. With componentization, we have access to smaller, well-defined pieces that can be orchestrated and combined – essentially remixed into new solutions. Componentization, separation of concerns, and encapsulation are cornerstone ideas in how we develop software solutions. They allow us to have a “remix” culture and approach to building software. So at a minimum, our patterns will take advantage of this culture and approach as our best practices result in solutions that build upon these ideas. However, we can also take this a step further and look to use pattern tooling to generate tooling (meta-tooling) – taking componentization to a whole new level.

The Long Tail recognizes that the gap between professional and amateur production is becoming increasingly narrow. Where not only do we see compelling content from those that are paid for their efforts, but we also see such content coming from those that produce based on their passion. If we reflect on pattern production we can see that in the past, patterns seem to be provided only from the professional patterns community. They were the experts, the professionals. They published the patterns via a number of mechanisms (mainly books) for the masses to consume. Today, anyone and everyone can and should look to produce patterns. We are all looking to use our imagination, recognizing recurring problems, and can drive toward a best practice solution. This is a PBE core value.

We started this article by pointing out that while pattern production is an issue, the number one issue is consumption. Consumption is also critical in the Long Tail – where there is recognition that for products to succeed in the long tail of the demand curve there needs to be outstanding support for consumption. With an increasing number of niche products produced, supporting and simplifying consumption becomes very important. As can be expected, there is a direct connection to how we work with patterns. As we take advantage of lower cost tools, widely distributed talent, componentization, and a shrinking gap between professional and amateur production – we are poised to see an explosion in the number of patterns available. We need to focus on consumption to help others find the patterns that they need at the moment of need. Asset repositories, metadata, packaging standards, Google, wikis and books are all simplifying and supporting how we consume patterns. In addition, development tooling is able to connect to these sources and easily consume provided patterns.

The following table provides an overview of the Long Tail and how it applies to patterns.

Table: The Long Tail key ideas applied to patterns

Long Tail Patterns and the Long Tail
Tools to produce creative output have been greatly reduced in cost Numerous tools are available for capturing both pattern specifications as well as pattern implementations. Pricing for the tools start from free.
Along with cheaper tools to use, there is more talent, more widely distributed than previously thought Globally distributed development is a reality with talented developers and architects located worldwide.
Componentization is supporting a remix culture. In addition to leveraging the componentization in the runtime, we see that the tools available leverage component based models. This allows us to have meta-tooling, that is tooling to create tooling, which is composed of the elements that we want.
The gap between professional and amateur production is becoming increasingly narrow. In the past, patterns seem to be provided only from the professional patterns community. They published the patterns via a number of mechanisms (mainly books) for the masses to consume. Today, anyone and everyone can and should look to produce patterns. This is a PBE core value.
With an increasing number of niche products produced, supporting and simplifying consumption becomes very important. Asset repositories, metadata, packaging standards, Google, wikis and books are all simplifying and supporting how we consume patterns. In addition, development tooling is able to connect to these sources and easily consume provided patterns.

 

Looking Forward

Yes we have an issue in pattern availability today. Not all of the patterns that we need have been identified, documented and automated (where appropriate). Software vendors continue to produce patterns to satisfy needs as represented by the head of the demand curve. However, today’s tooling for creating and automating patterns allows us to look at creating and applying patterns and benefiting from them – even thought most of the patterns created will exist in the Long Tail portion of the curve. And the idea of a remix culture applied to the use of patterns is exciting. It drives us toward using patterns in combination, towards componentization and standards.

So as we look forward to a future of PBE and consider where our patterns are coming from – we must consider the Long Tail. We must demand that vendors continue to strive to produce tools that allow us to produce our patterns. Providing support for remixing, flexibility, standard interfaces, and standard data exchange protocols. And to do so in a way that minimizes the cost to produce patterns, supports componentization, simplifies consumption and supports a community of talent that spans the globe.

 

PBE Acronyms and Abbreviations

February 11, 2011

We’ve posted a short document that lists the acronyms and abbreviations that are found in the PBE book. Each entry in the document has a brief description of the concept and the terms that make up the acronym\abbreviation.

Please let us know if you have any feedback on the document (omissions, errors, suggestions, etc.).

Thanks!