UML supports the MDD process: No match made in heaven or oxymoron.

This post builds on previous posts (1,2) and is serves as additional commentary and context to a post by  Franco Civello - UML for MDD - Oxymoron or match made in heaven?  Not sure what Model-Driven Development (MDD) is exactly, then check out IBM's MDD Redbook which is one perspective.

UML is a modeling language with thousands of features and facets.  Most people discount UML, even experienced modelers and language developers, without understanding what the language is capable off.  The primary UML feature missed of importance here is the UML Profiles capability.  People miss that UML Profiles allow for extension and constraints of the language itself, read section 18 of the UML Superstructure or take a look at the UML profile catalog.  The two linked posts (1,2) speak to what UML profiles are etc, so you might consider reading them before proceeding.  This extension and constraint mechanism is exactly what is needed to create domain specific models i.e. support MDD.

Now MDD is just a process, so what are the actual implementations or tooling used?  The following are just examples and it is not complete as I am sure there are a hundred ways to do it.  Firstly, there are DSL (Domain Specific Language) tool kits.  A classic example would be YACC and LEX, but a modern example is Eclipse XText Model/Language Definition.  Another significant way is with DSM (Domain Specific Modeling) tool kits, such as Eclipse EMF or MetaEdit+ (a leader in the DSM space).  The DSM space is not free from it's challenges too, but they are further along on average.  Think of DSMs as graphically represented DSLs if you are newer to this area.  Finally UML Profiles are another way to implement the domain specific tooling required.  Tools such as Rational Software Modeler (RSA/RSM), Eclipse MDT, and other tools.

What adds to the confusion between DSL/DSM and UML Profiles when it comes to the creation of domain models for MDD processes is approach and familiarity. The good DSL/DSM tools typically are tabla rasa (blank slate) model creation, much like a empty file when you start programming.  There is less baggage by starting with a blank slate, you also do not have to worry about removing or limiting existing model elements.  Now strictly speaking for UML Profiles you can start with a basically blank slate, but most tools don't support this.  A modeler in the UML Profile space must not only construct/extend the model, but constrain the other model elements that are not needed or conflict with the DSM.  You also have to research and pick the right UML element type to extend to minimize the constraining work you have to do.  Interestingly, in my experience creating small DSMs/logical constructs for a group of architects having a rich language actually reduces the work, but this need not always be the case.

You could really do MDD with any of the tools above, the question often becomes what is the cost, time, and skill level needed by the resources?  What actually seperates the tools are the features and ease of rolling out model tooling to all of the involved parties, such as business, vendors, developers, etc.  So the seven hundred pound gorilla in the room is actually the lack of wide spread usable tooling to build UML Profiles.  Few tools if any implement all of the UML Profile features and creating tooling for use in the MDD process can be very difficult.  I suspect most people use free or drawing oriented UML tools and thus never get exposure to UML Profiles.  Even if they did they would have to buy a specific software suite to support it fulling.  I use Rational Software Modeler (RSM/RSA) which is thousands of dollars and even it does not correctly implement UML Profiles, but it is close.  The DSM tools are not all free, but at least there is Eclipse MDT with EMF/GMF and the generative tools needed.  In a year or two Eclipse may have an offering that is usable enough for novices and support UML Profiles for the tooling efforts more fully.

So UML and MDD go together just fine when you understand the extension, constraining, and profiling capabilities of the language, but all is not well with the union.  UML requires lots of time and energy to learn and understand it before it will begin yielding results.  Better cheap tooling and tutorials are still needed to support the modeling and programming communities at large lest UML/MDD/MDA remain for 'experts only' which I would quantify as a failure by it's advocates.  Much of these challenges are not just limited to a UML Profiles based approach to MDD.

It is worth noting that at some point the industry should look back to Case Tools and YACC/Lex to evaluate why Domain Specific movements have failed in the past, or we may just repeat it.