On OPL Patterns

The first versions of the Pipes & Filters and Layered Systems patterns seem to have been written in the GOF form, which I personally prefer because it is a very structured form, breaking up the pattern into many headings: Intent, Motivation, Applicability, Structure, Participants, Collaborations, Consequences, Implementation, Sample Code, Known Uses, and Related Patterns. The GOF pattern are quite large, but if the user does not assume familiarity with the pattern the amount of information is very useful.

The new Pipes & Filters and Layered Systems patterns are written in the Compact form, which, in my opinion, for people closer to the development process, may not be enough. I understand that the intent is that longer pattern languages will benefit from this form because it is easier to read quickly, the structure of the overall language can be understood easier. However, since there is no doubt that both forms offer you at least a section with the crux of the problem (e.g. Intent/Motivation in GOF and Problem/Solution in Compact form), it feels like this short form supports mainly pattern theoreticians, than those who use the patterns in practice. And we all know that nothing is more useful than a code example. I cannot help but remember again a quote from Christopher Alexander: “People who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things”.

Iterative Refinement Pattern helps one exploit the concurrency implied by computational structures consisting of a sequence of high level steps which repeat until some exit condition is met, with each step, comprising a number of mostly independent computations. The Bulk Synchronous Processing (BSP) model, proposed by Leslie Valiant in 1990, is a decomposition explicit, mapping implicit model with communication being implied by the location of the processes and synchronization taking place across the whole program. BSP is designed specifically to support the Iterative Refinement Pattern.

A BSP machine consists of an arbitrary number of processors, each with local memory, connected by an interconnection network, providing functionality as data delivery and barrier synchronization of the processors. A BSP program is divided into supersteps, with each superstep consisting of a local computation for each individual processor, a global message transmission from each processor to any subset of the others and a barrier synchronization. At the end of the superstep, the transmitted messages become available as local data for the next superstep. Because communication all happens together at the end of the computation phase of the superstep, it is possible to perform automatic optimization of the communications pattern.

Coming to the question of what was hardest to understand about the Iterative Refinement Pattern, I feel I should mention again the minimalistic form in which the pattern was written. I think that understanding the solution to the iterative refinement pattern, and how the four parts (computation initialization, the sequence of computational steps, the collection of tasks that execute inside a step, the exit condition) work, an implementation example would have helped a lot.