UML for MDD - oxymoron or marriage made in heaven?

Recently I have come across a number of MDD related blogs suggesting that UML is inadequate to support precise and abstract models, which are a prerequisite for a model-driven development approach.
For example, in his post Microsoft DSLs + UML = ???, arguing against the use of UML as a precise and abstract modelling language, Steven Kelly says

I’d always thought of UML as being more specific about implementation choices than DSLs — e.g. the restriction to an object-oriented language, and the individual classes, fields and methods of an implementation specified directly in the models. DSM languages are almost invariably on a higher level of abstraction than UML. The only part of UML that is on a high level of abstraction is the Use Case diagram, and that’s only at the total loss of precision. It’s hard to see how anyone could mistake, say, the individual method calls of a Sequence diagram as being on a higher level of abstraction than DSM languages”

I disagree with such views. My experience is that UML can be used effectively to express precise models at a high level of abstraction. The trick is to work at the right level and to use only those parts of the UML amenable to a precise interpretation. In other words, pick the right tools from the UML toolbag, and use them appropriately.

Use cases and use case descriptions, for example, are inadequate representations for a MDD approach. Use Cases are an informal and imprecise technique for capturing requirements. If your UML experience is about writing use case descriptions, drawing use case diagrams, and producing some domain class diagrams on the side, you are certainly doing a useful job at clarifying what the business or user wants, but you are still miles away from producing models that can be fed into any kind of MDD tool/environment. At the other end of the scale, if you are using UML to draw class diagrams and sequence diagrams showing software object interaction scenarios, your level of abstraction is already pretty low - you may as well express your intent in well-written and documented code.

I will justify my position by giving one example of how UML can be used to write precise models with no implementation detail. This is a technique, borrowed from the Catalysis methodology of Desmond D’Souza and Alan Wills, that my company has successfully used for many years to develop software of medium to high complexity. It works as follows: having produced informal use cases to clarify requirements, and a domain model to get an initial understanding of the subject area, the analyst produces a precise specification model, in UML, in which the system to be developed is represented as an object, belonging to a type (note, not a class, as the system is an abstraction used to define visible behaviour, not a software entity to be directly implemented in e.g. Java).

Steps in the use case flows are then formalised as operations on the system type, with a declarative specification of behaviour based on the notion of functional contract, written as pre- and post-conditions expressed on an underlying model (the system type model, derived closely from the domain model). UML static modelling gives you the language to represent the state of the system in abstract and yet precise terms. Just don’t think of your classes as software things with methods and member data, but as specification types that give you the vocabulary to specify the business outcome of a system operation. These types can have attributes, associations, queries, constraints and definitions, all powerful UML concepts, but no state-changing operations. The only state-changing operations are defined at the system level, and are not elaborated into message-based solutions, but just specified declaratively in terms of business logic, steering clear of any design decisions.

Note that the value of UML in this approach is not just in its diagrams, but mainly as the basis for precise textual expressions that can be written (e.g. in OCL ) to represent preconditions, postconditions, invariants and other definitions. This approach requires analysts with strong abstraction and modelling skills, the same skills required in MDD or MDE to build precise models, amenable to transformation or execution.

What I’ve just outlined is just one of the UML based techniques you can use to produce precise, abstract models. A useful complement, which would make models more amenable to user interface as well as business logic generation, is to tease out the UI navigation and control behavior from the system object, representing it a separate object with an attached state machine. Each state represents a page or view shown to the user, transitions are caused by user or system generated events, and actions can invoke system operations, creating the link between UI and business logic.

In addition to the above, an executable subset of UML, xUML, is also available and supported by some tools. This is particularly applicable to real-time event driven systems, proving once again the range of applicability of the UML toolbox.

Franco Civello, RDF Group