MDA Compliance and QVT

While the MDA story is very much about transformations and targetting multiple platforms, I don't believe that the use of transformations that conform to OMG's transformation standard-in-the-making (Query/View/Transformation) is a requirement for MDA Compliance for any individual tool.

QVT is clearly very important for people who wish to write their own MDA transformations. It is very important to the OMG (or anyone else) who needs a way to standardise a transformation. However, I don't believe that every MDA tool must be constructed using QVT or to expose the transformation being undertaken. Many MDA users will want to get their transformations off-the-shelf and be quite happy for them to be black boxes, so long as it is known what to expect in terms of I/O. Similarly vendors whose intellectual property is embedded in their transformation are unlikely to want to expose it to their customers or to their competitors, so they too will be interested in black box MDA tools. And if the tool is a black box, then whether it is internally implemented using QVT or anything else becomes somewhat irrelevant.

Obviously if a tool is built on the QVT standard, it makes sense to have some conformance statement about how faithfully it implements the QVT standard, but this can be in addition to any claims about MDA conformance.

Compliance to the Model-Driven Architecture

The hot topic on the OMG mailing lists at the moment is what is required to brand a product as "MDA". The good news I guess is that the market are taking sufficient interest in MDA that vendors are desirous of branding their products accordingly. The bad news is that I suspect many of those vendors aren't really interested in MDA, simply in the rights to brand their products.

However, the issue of what makes a product "MDA" is a hot one with very little concensus. Here's my take.

I think the minimum requirement for a tool to be branded MDA would be its ability to participate in arbitrary MDA tool chains. This means that we must know what models are used as the input and output of the tool (or the sources and targets if you prefer) so you know if the tool can be meaningfully connected to other tools. And at the syntactic level, the input and outputs corresponding to those models must be interchangeable between the tools, mandating that XMI import/export (as applicable) must be available.

This does not imply that the only means of I/O is via XMI, simply that it is an option. There are many popular concrete syntaxes (e.g. SQL, IDL, UML diagrams etc) that are obvious candidates for alternative I/O forms. Indeed, having multiple forms of I/O is more or less essential for tools that anticipate interworking with existing non-MDA tools. For example your average Java compiler expects its input in Java syntax and not as XMI for the Java model.