MDSD using patterns

Is it possible to use patterns as both a meta language and an intermediate model in MDSD? My engineering brain tells me that there is enough information there to generate the code, after a few transformations, for, say, a JMS exchange by simply naming a component, stereotyping it with <<Observer>>, and filling in a few tagged values. The first transform would take this component and create a composite model using the name and the tagged values from the abstract model and the pattern model from the "patterns.objectInteration.observer" package. This composite model, in turn, might be transformed a few more times but eventually be used to drive out the implementation code and configuration for the target platform along with the documentation and tests. The "JMS nature" however might be added after the second or third transformation.

Now, I've learned that it's a good idea to scour the web first before launching off on a grand design such as this. I mean, I don't think that I'm the first one to think of this, but, due to it's scope, I might be the first to be willing to share what I'm doing along the way. Perhaps this is a sort of Holy Grail of programming that developers keep close and locked in their tool box. But, from what I've seen in the development world, there are only a few that would be so inclined to have such a tool. So I'm going to do a few prototypes and assess the feasibility of this approach. Keep posted. I'm all for raising the level of abstraction where possible, and this approach, if successful, definitely will. Plus, it might give Gegor Hohpe's neon icons a wider range of use :)

For now, what I think I need is a good intermediate model that would contain the patterns that I'm using in my design and also a UML profile or DSL that could be used in my component model. So my plan is to create a simple component model and see what is needed to generate some of the platform specific artifacts that I'd like to have. My prototype will use the Observer pattern to create a JMS message exchange between the subject and several observers.

A few years back, one company that I was working for was creating a design for collecting NOAA's weather data. At the time, I thought that a Jini solution was in order then but the guy who was actually developing it was keen on using a database as the communication mechanism. We didn't go on to get the development work :( If only he had used the Observer pattern and hadn't committed to an implementing technology, eh :) Here's a thumbnail of a problem statement: the weather station is comprised of a set of measurement instruments that are remotely deployed. Periodically, it makes it's measurements available to all interested parties. This data needs to be collected and managed so that it can eventually be used by various agencies and businesses. Seems like a good candidate for the observer pattern to me; at least the data collection piece anyway. Truth be known, the final solution would be a bit more complicated and would probably include data collection for each weather station using a polling mechanism, this collection system would periodically post it's data, observers could then do whatever is useful to them which might include conditioning, filtering, storing, etc. Here's the initial component diagram.

One of the benefits of keeping it at this level is that the pattern isn't technology bound but is "independent" of the platform. From MDA, this would be labeled the PIM (platform independent model). In MDSD this would be an architecture-centric way of going about designing things which, in it's purest implementation, would be one step further along in the design than the domain-centric design. So perhaps the use of a patterns profile or DSL would be a good language for architecture centric abstract design. This would be helpful since there always is the guy who wants to put the strategy into the vision. You've heard it I'm sure, "Why don't we just stereotype it as an EJB; it's what we're going to use isn't it?" An abstract lingua franca would be very useful for putting such people in their place by being able to simply say, "There isn't an EJB stereotype available but there are several patterns that might do. How about 'Client Proxy', 'Business Delegate', or 'Session Facade'? What exactly are you trying to communicate when you say 'EJB'?"

Onward!