Analysis Patterns 2 - Work in Progress

Temporal Patterns
Quantity and Range
Accounting patterns: a (considerable) update of the material in the Analysis Patterns book.
Accountability narrative and patterns

For a while now, I've been working on analysis patterns again. Currently my plans are not to write a second edition of analysis patterns, but rather to work on writing patterns that I think are particularly important to write. This includes some material from the original analysis patterns book, but also some new material. In my current thinking I'll produce a new analysis patterns book at some point, but this will only partially replace the exisiting book. Exactly how much I haven't decided yet.

Here, I intend to put the material on analysis patterns as I come up with it. This way I get the maximum amount of information out to people who might use it, and I also hope to get feedback on the patterns so far. I'm very interested in your experiences with these patterns. Have you used these patterns? Were they useful or not? Have you come across interesting variations? Please let me know and I'll feed comments back into the material on this site.

Patterns So Far

The first set of patterns I made available were the accountability patterns, which essentially reworks the patterns from chapter 2 of analysis patterns into the new form that I'm now using. These patterns come in two pdf files: a narrative and a collection of patterns. I'm moving away from using pdf and will use html for future patterns - but it will probably be a while before I move these ones over to the new physical format.

Two small, but very common patterns are Quantity and Range. These a small fundamental patterns, yet ones that are used pretty widely. If you write OO systems they should be an ever-present part of your toolkit.

Accounting, of one form or another, seems to be a never ending theme in my professional life. Analysis patterns contained a chapter on accounting patterns, and I've had more ideas since, which are the accounting pdf file. The paper includes an opening narrative followed by several patterns. As with the other patterns, read the narrative first to get an overview of the patterns. You can then use the patterns to dig into the details. Those who've seen my half-day analysis patterns tutorial over the last year or so will find the details on the patterns I talk about there in here.

My most recent set of patterns is a set of patterns to do with historic information. Capturing history usually adds an enormous amount of complexity to models, these patterns help factor the historic issues out, allowing you to deal with them separately. At the same time the patterns suggest some common implementation techniques.

The New Form

One of the biggest things I've been experimenting with since the publication of analysis patterns is the form for patterns. In analysis patterns I used straight narrative. I realized that this made it harder to use the patterns for reference, but I felt that the narrative form made it easier to discuss the trade offs and relationships between patterns that, for me, are the heart of what patterns are about. Wrestling between narrative and reference forms has been a common theme for me ever since

My solution, for the moment, is to divide the writing into two sections. A short narrative section introduces the patterns, gives an overview of what they are about, and discusses the trade-offs between them. A longer catalog section takes each pattern in turn, going into all the details. Not just do I feel this split allows me to have the best of both worlds, it also allows the reader to read just the narratives to understand what patterns are present and roughly what they mean. That way you don't have to read the whole book to get a good view of what the patterns are about - you can just read the narratives.

The catalog item details the pattern in the following form.

the Name
the Intent
a Sketch
How it Works
When to use it:
Some code samples showing an example implementation

This format for the patterns is fairly loose, yet I hope shows up the main sections of the patterns.

One item that several people have commented on is the use of code samples. These comments have varied from the delighted to the horrified. The main reason I use them is to better communicate with programmers, who after all understand programs. Many programmers had difficulty in understanding how patterns work just from diagrams and textual descriptions, code samples help sharpen the ideas.

The first thing to remember is that these are example implementations only. Hardly anyone will be able to just use them - they will need to adapt them to suit the problem they are working on. They are there to help explain the ideas, nothing more.

Also the code samples are not essential to understanding the patterns. My aim is that if you can read UML diagrams reasonably, you should be able to understand the patterns without digging through the code. So if you don't like reading code, you should just ignore it, and if I'm successful the patterns should still make sense.

Thanks to those who've commented and pointed out errors. [Ismet Kahraman]