UML versus Domain Specific Languages

There are, by now, many cases studies of the successful application of code generation tools and technologies. Allowing developers to raise the level of abstraction over that supported by general-purpose programming languages is the best bet for development organisations wishing to address the productivity problem.

Although there are other approaches to raising the level of abstraction - such as framework evolution, or even programming language evolution, code generation, because it is flexible and fast, has the advantage of being able to adapt to new environments relatively quickly.

Here we consider the two most popular starting points for code generation; UML for program modelling [part of the OMG's Model Driven Architecture (MDA)] approach), and Domain-Specific Languages (little languages that are created specifically to model some problem domain).

As well as introducing both approaches, the aim is to offer advice on their usefulness for real-world development. We also ask whether they are mutually exclusive or if in some circumstances it can make sense to combine them.

UML and MDA
Experience of using UML as a modelling language is widespread and so using UML to express what is required in a system and generating code from that is acceptable for many organisations. 'Code generation' in UML originally meant a very low level of generation - converting classes on a diagram into classes in C or Java.

Experience has shown that this level of modelling does not give any business benefit when applied to complete systems. However, by using more specialised or abstract modelling elements it is possible to increase the amount of generation.

This approach was adopted by the OMG in 2001 as part of its MDA standard. MDA was developed to enable organisations to protect their software investment in the face of continually changing technology 'platforms' (languages, operating systems, interoperability solutions, architecture frameworks and so on). If the design and implementation is tied to the platform, then a platform change means a complete rewrite of a software system.

To avoid this, MDA proposed to separate 'the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform'.

The specification of system functionality is a Platform Independent Model (PIM); the specification on a particular platform is a Platform-Specific Model (PSM). The PSM can be annotated by developers to provide advice or guidance for the final code 'text' generation step - which creates the source code and configuration files.

To reap the business benefits of this approach, the PIM must survive platform change and be reusable across platforms. The implications are twofold. Models become first-class artifacts in the development process, rather than being ignored after a certain point; if you change the PIM, the functionality of the delivered system will change.

The second is that code generation becomes important; mapping the PIM to the PSM by hand is costly and error prone, whereas automatic mapping to the PSM can significantly reduce the cost of a transition to a new or upgraded platform.

MDA defines a set of standards for transforming models that was finally completed in 2007. These standards are well supported in the telecoms and defence sectors, where there is a history of investing in development tools as part of large projects. In the commercial world, the lack of standards led to companies supporting the 'model driven' approach (MDD - development, MDE - engineering etc.) using a variety of tools to transform UML models into working systems " 'pragmatic MDA', as it was called.

The industry position of UML also means that developers can choose from a wide variety of vendors for their MDA tooling. Furthermore, vendors typically provide additional products based on the MDA approach, reducing the investment for an individual company to adopt MDA.

However, there are some issues in the use of MDA. First is the expression of detailed business logic. While 90-95% of a commercial information system can be generated from a UML model, there is a point where the business logic is not general and so not amenable to a code generation solution. There are two approaches to expressing the business logic.

The 'purist' approach is to model the business logic; one of the MDA specifications covers this approach. The 'pragmatic' approach is to leave holes in the generated application for the hand-written business logic; this is most popular where there is a rich, standardised development environment, like Java or C# and .NET.

Another issue is the low level of UML and the looseness (or generality, to put a positive slant on it) of its semantics: a common criticism is that UML is too big and vague to be effective. This assumes that the only 'code generation' possible is the very low-level code generation described earlier - the assumption is that UML can't express more abstract or specialised concepts.

But this criticism ignores UML's profile feature. 'Pragmatic MDA' vendors use this to specialise UML. To do this, they define profiles so developers can create models with a more specialised terminology and associated data. On top of that, vendors add their own validation to tighten up the UML semantics. The result is a domain-specific subset of UML if you like.

Using UML profiles gives as much expressive power as DSLs: stereotyped classes typically equate to the DSL terminology and stereotyped relationships are the same as for relationships in graphical DSL terminology. In other words, either approach can express concepts of arbitrary levels of abstraction.

There are two main problems with using UML with profiles to define new modelling languages: with current UML tools it is usually hard to remove parts of UML that are not relevant or need to be restricted in a specialised language, and; all the diagram types have restrictions based on the UML semantics.

For example, New Technology/ enterprise (NT/e) is in the process of building a graphical DSL for a novel middleware product. The key to this is being able to model methods as first-class model elements.

In theory we should be able to do this using action diagrams, but in practice there is too much other baggage that drags along with it. As we will see below, the DSLs are built from the ground up, so the modeller is not confronted with extraneous UML semantics or modelling elements.

Despite this, defining a high-level UML profile has historically been the best commercial approach to realising MDA. To produce a new profile is relatively cheap. On the marketing front, the installed base of UML tools and the understanding of the practice and benefits of modelling mean MDA products can be positioned as 'addons' rather than a completely new paradigm.