Domain-Specific Languages
Although DSLs and DSL tools have been around for a while now it is only in the past few years that interest in this area has really taken off - partly in response to Microsoft's entry into this space with its DSL Tools for Visual Studio.

As noted above, DSLs are little languages that can be used to directly model concepts in specific problem domains. These languages can be textual, like most programming languages, or graphical. Underpinning each DSL is a domain-specific code generator that maps domain-specific models created with the DSL into the required code.

One way to think of how to use a (graphical) DSL is to imagine a palette containing the boxes and lines that correspond to key concepts and relationships in your problem domain.

Modelling with this palette involves selecting the concepts you wish to model and 'painting' them onto your canvas. 'Painting' different types of lines between these concepts can then create different types of relationships between the concepts.

An advantage of the DSL approach is that the modelling environment can constrain and validate a created model for the domain's semantics, something that is not possible with UML profiles.

Tools to support the definition of DSLs and domain-specific code generators have been around for a while now but have been far less commonly available than MDA-based toolsets, with only one or two vendors offering mature products.

Given this, many developers using DSLs have chosen to go down the road of implementing their own generators with varying degrees of success due to the complexity of this type of work.

This is now changing with the increasing availability of tooling to support DSL and generator creation from companies such as MetaCase, Microsoft and as part of the Eclipse Modelling Framework. To some extent these have reduced the skill levels required to create DSLs and domain specific generators.

Which to use?
Given that both approaches now have momentum behind them in the form of vendor support, successful case studies and increasing industry awareness, the question arises for developers of which approach to adopt (assuming developers are completely open-minded!).

Perhaps the first thing to note is that developers in organisations, or supply-chains, where use of UML or Microsoft technologies is mandated may find it politically difficult to choose a 'competing' approach.

Modelling and code generation is just one part of the software life cycle, albeit an important part, and must fit in with the rest of the organisation's tooling and processes.

Similarly, in industry sectors such as real-time systems engineering, where intensive work has already been undertaken to support the particular modelling needs and constraints of the sector (with development of the SysML customisation of UML, for example), developers may not find it cost-effective to create their own unique UML profiles or DSLs that don't take advantage of this prior work.

As noted above, a basic DSL can be produced using UML profiles and this will often be a viable and relatively quick approach for a first-time code generator.

However, the baggage that UML brings to the problem can confuse novice modellers; to avoid this, generator developers may choose to directly proceed to building their own DSLs - either with tool support or in a completely bespoke manner.

It's also worth mentioning that in many cases software systems can only be implemented with multiple modelling languages and code generators addressing different aspects of the overall problem.

There's nothing to stop developers, who on the whole are a pragmatic bunch, from using a hybrid approach that combines UML with DSLs to create solutions that draw on the strengths of each approach, and indeed this is what some organisations, such as NT/e, have done very successfully.

So what is the outlook for the industry? It is our belief that as a basis for modelling for code generation, UML tools - in their current form - will gradually lose 'market share' to DSLs: DSLs can be more direct, appealing and easier to use for a wider range of users.

However, UML vendors, with their strong background in code generation approaches, can compete by adding a non-UML modelling and metamodelling 'surface'. Combined with their tool's existing UML features, this would make an attractive combination product for many companies.

Mark Dalgarno is a Partner, Software Acumen and Matthew Fowler, Matthew Fowler is founder and CEO of New Technology/enterprise.