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: [EMAIL PROTECTED] personal webpage: www.jamessiddle.net "Dragos Manolescu" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 22/03/2007 16:56 To [email protected] 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 [email protected] 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
_______________________________________________ patterns-discussion mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
