If you want to find out more, check out this old entry or check out the design considerations section of our product’s documentation.

One of the things I disagreed with, though, was the predictable UML bashing. Interestingly, Juha-Pekka used one of the arguments I use all of the time as well, only with a slightly different pitch: We agree that when you use UML to visualize low-level language constructs, for example create a UML class diagram containing all of your low-level technical J2EE artifacts, there’s little benefit and nothing domain-specific. You essentially provide a different view on your source code, at exactly the same level of abstraction.

The difference is that — at least in his talk — Juha-Pekka’s generalized this to UML in general, while I use this to criticize tools such as Together. We use UML in a number of projects in a way very, very similar to the way DSM is used in his examples. I’m the first to admit that UML is far from perfect, and I concede that using a “real” DSM approach such as MetaCase’s may often be superior to the poor man’s DSL available in UML (UML profiles). The benefit, of course, is the increased level of interoperability, both when communicating with humans as well as when exchanging information between tools.

In any case, it was funny to see that the MDA track at JAOO drew very little attention while the DSL track was packed, when in fact the presentations’ contents were very similar. It seems that MDA has now entered a massive anti-hype cycle.

(iQgen, in case you’re wondering, reads in model information in XMI format, and transforms it into output files based on templates that have been written as JSPs. It is very, very stable, works with almost any CASE tool in the market, and has command line, Ant, Swing and Eclipse interfaces. Essentially, it does only a small amount of things, but our aim has been to make it do those things extremely well. You can find more information here.)

Applying Model Driven Architecture or a simple model-based generative approach to real world projects forces you to follow strict processes in order to ensure that your development steps stay repeatable.

While in early stages of development the forward engineering approach is extremely powerful, it becomes somewhat inappropriate when going to latter phases of projects. The temptation to abandon the generative approach and do all changes in the code increases. (For more information of forward engineering you could consider this short introductory part of the iQgen doc.)

The reason for that is a shift of scope in the development activities. While the common approach follows a push model (commonly model changes are pushed into code through generators), it would be more appreciated to use a pull model (that is, "update code fragments x, y, z from model with current transformation-rules").

In order to move into that direction I've extended iQgen a little bit to track metadata according to transformations and their execution.

With this it's possible to query dependencies between model elements of various abstraction levels (PSM / PIM), code and iQgen templates.

The following picture shows a part of iQgen's GUI with the (first) simple dialogs which can be invoked on model elements or generated files in order to query the thing I've called Transformation Repository.

As you can see it's very beta. But the infrastructure would allow to execute subsets of transformations. For the ease of model driven development in latter stages it's now possible to start generation directly from the code point-of-view.

I wonder if this is considered useful or even necessary and appreciate any feedback.

I pity any UML tool vendor who takes it upon themselves to implement UML 2. I have read more coherent binaries than the UML 2 specification, which seems to have been inspired by the “Choose Your Own Adventure” books that I read as a child, but 10 times as long, and split across multiple books. It was cool when I was 7, but now its just a bloody nuisance.

I couldn’t agree more. When Phillip explained the <<combine>> concept to me, I wasn’t sure whether my problem was that I was simply too dumb to grasp it, or too wary to be bothered with something like that. I don’t claim to understand UML inside and out, as I have not wasted years of my life wrestling with its internal structure; but given that convincing people about MDA is one of the things I do for a living, I believe I know more about it than the average user. If I don’t get this, how can the authors expect somebody who just wants to use UML, but whose core competence is in some business aspect, to be able to use it?

The model was created with a trial version of Enterprise Architect 4.0 - a highly recommended CASE tool. Although there are some constraints in modelling state machines with EA in order to generate from theese with iQgen, this sample might be a good starting point.

All you have to do is to download and extract the zip-file, read the Readme.txt, and then just start generating and see the result. If you want to play around with other CASE tools, the state machines might be exported in a different way.

Maybe I'm able to show the usage of other diagram types near soon.

In MDA:

• A Platform Independent Model (PIM) is the starting point.
• The PIM is turned into a Platform Specific Model (PSM) by means of a transformation. This can be done either manually or automatically.
• The PSM can be transformed again, yielding an even more platform specific model - other words, a new PSM, targeting another platform.
• The final PSM is turned into code.

In “Pragmatic MDA” or “MDA light” or “MDA as it exists today” …

• A Platform Independent Model (PIM) is the starting point, although it might be called a PSM with some justification (as it will usually contain at least information to target an “abstract” platform)
• The PIM is turned into code by means of an automatic transformation.

So is there a PSM in the second approach? If so, where?

In my opinion, the PSM, if you insist on finding it, is the code itself. How can the code be a model? A model, in general, is a simulation of some concept or aspect from a specific point of view, intended to enable reasoning about it for a particular purpose. If I take the resulting code in the second approach from above, I can look at it in an IDE, the purpose being to edit in its textual form. If I read the same code into a 1:1 CASE tool such as Together, I see a visual rendering; the purpose of which might be to manipulate it visually or explain it to somebody else.

• First of all, you have a technical model. It’s technical, and not a pure business model, since it describes your business domain annotated (by means of UML stereotypes and tagged values) with information about the technical nature of your model elements. You might, for instance, have some UML classes that represent entities (in the most abstract sense), and others that represent processes.
• The set of stereotypes and tagged values that are allowed when you (manually) refine your business model into a technical model define a UML profile. This UML profile, together with the UML itself, form the metamodel of your model. Thus, your technical model conforms to the UML profile. The UML profile itself is (in the case of iQgen) completely open to be extended in any way that makes sense for your requirements.
• There is a set of templates that contain rules for code generation. These templates match the UML profile, and expect the model to conform to it. In the example given above, you might have one or more templates that are used for entities, others for processes, and some for both. Depending on your target platform and frameworks, the templates contain code skeletons and rules that are specific to this target environment. Thus, they match the technical platform (in this case - and this is only an example) - J2EE.
• Based on the technical model as its input (which is represented by one or more XMI files) and the templates, the code generator emits source code. If code is being generated for the second or nth time, which is usually the case, the existing source code becomes input to the generator. This way, manually added code is available to be merged into the newly generated code.
• Finally, the usual compile/build cycle is applied to turn your code into a running system.

Their development infrastructure relies heavily on modeling, in their case using Innovator, a modeling tool very popular here in Germany. Innovator is very powerful, but also pretty complex. In addition to this, they use our product, iQgen, with a huge set of custom templates that drive the code generation. While they have achieved a high degree of automation — they can generate close to 100% of their backend code in most cases — it's not an environment that is well known, nor is it easy to learn in a short time.

So the problem was: How does one address this in the context of offshore development? Should they train the offshore developers in the usage of the toolset?

My recommendation was different: Continue to do the modeling on site, and ship the generated skeleton code to the offshore IT shop. This has the major advantage of agreeing on a specification that is as close to code as you can get, because it is code. In case you're wondering what the offshore IT developers have to do then, it's about implementing those parts of the code that cannot (or rather: are not) generated, which in this case includes the Swing client UI and those business logic elements that don't lend themselves to be modeled in UML easily.

The customer has taken this approach and exercised it for 3-4 months now, and it seems to work very well.