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!

For everything a place, a place for everything

What's in here?

• Intro to MDSD
• Where I'm heading
  

I'm actively trying to get a grip on all of the implications that MDSD brings along with it. I've been listening to a few podcasts and viewing a few videos on InfoQ just to help the conversation that I have going on in my head over this topic. Sven Efftinge, Markus Voelter, Martin Fowler, et al have been close companions of late :) There is the heady world of DSL generation. Likewise, there are the model-to-model (M2M) and model-to-text (M2T) paradigms that, at the same time, make perfect sense but give the distinct impression that there is more to them than meets the eye. The technologies in this space are not few so ... odds are you know what I mean.

I've been a heavy user of AndroMDA over the past few years and have found it to be a great time saver along with producing high quality, feature rich code. For the first time I felt like I could spend most of my time on the business logic and relatively little on the wiring. I can remember the first time that I successfully ran it against one of my models; I was so thankful that I didn't have to handcraft the WSDL file or EJBs or the persistence layer. Don't get me wrong, the learning curve wasn't a walk in the park, but it was ultimately rewarding. The hook had been set and there was no turning back. I've always had a predisposition toward code generation probably more from a productivity boosting motivation rather than one of laziness or boredom. This predisposition is sated with the current release of openArchitectureWare.

One of the main things that I really like about model driven anything is that it marries the design models and the code. I believe that it's a relatively large problem to have design documents that are not only poor images of the deployed programs but, in most cases, bearing very little resemblance to the component parts of the system at all. By adopting MD*, the software development life cycle is in tact because it has to be or the project is out of control. This is good news especially for those working in the government and regulated sectors.

So the two immediate benefits are time savings and a complete life cycle. Yet another benefit is that it reintroduces the creativity back into programming. You see, the generators are very good at creating the mundane stuff, leaving it to the programmers to create (note the use of the word create) the code that realizes the business logic. Generally, this will require two tiers or peers of programming staff, those who attend to the business things and those who attend to the architecture and the plumbing generators. So you see, this is as significant an advance as subroutines, C, 4GLs, and OOP were. So now we are at the point where the target architectures are being codified; we've moved from Assembler all the way up through components and are now focused on the services layer. Next up would be the dream of composable systems and what I like to call the percolating enterprise. Beyond that would be a sort of "universal consciousness" (go to a quiet place, sit on the floor, close your eyes, and say Ummmm) as we create a trusted layer between networked entities; a piece of which is envisioned as the semantic web.

It's my opinion that the leading edge at the moment is the work around creating secure, consistent, high performance, networked systems, i.e. just a few steps behind those bleeding edge pioneers who are working on the "Ummmm" generation of systems. There are a host of tools available in this space and, as for my investment, openArchitectureWare is a clear choice. They have very functional tools for M2M and M2T work as well as a solid platform that integrates it all. They can work with almost everything that could constitute a model from a simple text file via their Xtext DSL modeling framework to UML2 compliant models. It's all there and ready to use. One of the interesting things that the oAW team has chosen to do is to leave out cartridge development; leaving this task to third parties while they concentrate on the enabling platform. This is a very good move in my estimation. Just for reference, one of the cartridge factories that has already cropped up is the Fornax Platform. I really don't see a downside to adopting this platform other than the cartridge issue but given it's flexibility, there is no reason why AndroMDA compliant models can't be generated that could then leverage their cartridges. The sky is the limit.

The waters that I'm wading into seem to be fairly deep. But coming from the AndroMDA world, the terrain is fairly familiar and the good news is that I don't have to loose touch with where I came from; it still can play a significant part in my efforts. At the same time, I am very sure that it will be worth the risk and the effort in the crossing. Along with my experience using MDSD and creating DSLs, odds are good that I'll have a healthy diet of software architecture patterns to talk about and more than a few diagrams to boot. This blog will function as my bulletin board, diary, and forum. A good friend of mine has this maxim when it comes to organizing her world, "for everything a place, a place for everything". Though I'm still coming to grips with the implications of this, I've decided that this blog will be my place to put things about software development and architecture.

'nuf said for now, eh? :)