General talk about software patterns

[James Siddle <james.siddle AT uk.ibm.com>]

Hi Dragos,

This may or may not be relevant, but
I noticed something similar on an iterative project I worked on last year.
We applied several POSA patterns, including 'Component Configurator' and
'Broker' in an adhoc way to create a component middleware. We applied Broker
and Comp Config more or less at the same time, but there was was a relationship
between them in the emerging architecture, in that Broker really required
Component Configurator to already be in place for the architecture to make
sense, however the opposite was not necessarily true.

I've written a paper about the experience
& submitted it to EuroPLoP, it proposes a pattern sequence to recreate
the architecture. In the proposed sequence I've put Component Configurator
(which I'd view as having a strong creational aspect) before Broker (which
could be viewed as behavioural...though I'm not particularly familiar with
the GoF classifications so this is a guess). The paper explores the reasons
behind the ordering of patterns in a sequence, but only briefly - I'm hoping
this is something that will shepherding will give me a chance to improve.


My understanding is that the architecture
vision plays an important role in helping to determine ordering; so for
example a desire for platform independence would lead to something like
Wrapper-Facade being applied before other patterns. The ordering of Comp
Config & Broker is not so simple - you could argue that either could
come first. In the end, the criteria I chose for ordering these two patterns
came down to intuition - why bother having a broker if you don't have components
that need to communicate? 

We also applied several other patterns
after Comp Config, all of which refined & embellished the interaction
of components, so the creation & deletion of components via the Component
Configurator pattern was definitely 'foundational'. An interesting example
is Interceptor, which was applied to provide an interception point on component
communication - so this required both Component Configurator & Broker
to be in place first.

Hope that helps...
Jim


James Siddle
IBM WebSphere ESB Foundation Technologies
telephone: +44 1962 81 6055
email: james.siddle AT uk.ibm.com
personal webpage: www.jamessiddle.net

"Dragos Manolescu" <dmanoles AT gmail.com>
Sent by: patterns-discussion-bounces AT cs.uiuc.edu

22/03/2007 16:56

To	patterns-discussion AT cs.uiuc.edu
cc
Subject	[patterns-discussion] Relationship between pattern types and        software evolution

Are there any studies that focus on how do the types of
patterns used in software systems change as these systems mature? My intuition
tells me that in general (i.e., regrdless of problem domain and/or programming
language) new, immature systems tend to employ more creational patterns
than behavioral patterns. However as the abstractions crystallize the number
of behavioral patterns should increase. I could be wrong so that's why
I'm asking whether anybody performed this type of analysis. 
 
Thanks,
 
-Dragos_______________________________________________
patterns-discussion mailing list
patterns-discussion AT cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU