Review: Can Domain-Specific Modeling Replace UML?

UML

According to MetaCase, DSM aligns models with code at all times, even though models are not associated with any specific code language or structure. Models in DSM target specific tasks for a technology or business domain.

For instance, by changing a query-based task from alphanumeric to numeric when designing an application in Symbian for Nokia phones, the underlying MetaEdit+ code generates the appropriate numeric checks. Changes such as this one do not affect code generation because a code generator for that query task takes into account string and numeric manipulation. The change made to the graphical query task is acting within the bounds of the objects that define the task.

Despite the advancement of programming languages and communication protocols over the past 25 years, little progress has been made in abstracting away software development methodologies from business cases. Today, UML has no way of automating transitioning between business- and programming-level diagrams. Architects have to work with business analysts to build those links correctly.

Similarly, other standardized modeling languages such as IDEF and Expressg follow UML's path of code visualization. The limitation lies in that UML-based modeling languages have borrowed most of their concepts from the world of programming.

With DSM, complete code generation directly from business models is possible as long as code fulfills narrow application tasks. In an ideal model-centric approach, models generate all the code needed to build applications without even knowing what programming technologies were used. Essentially, architects use MetaEdit+ to define language concepts and rules that make sense for specific business domains. In addition, the objects in the MetaEdit+ models do not have a one-to-one correspondence to specific classes. Therefore, software architects do not have to know anything about the code generated.

As models grow, developers build more assets by associating code to other objects. Hence, any development effort immediately satisfies new conditions added into the models.

What's more, application logic in MetaEdit+ also can describe the underlying building blocks for objects. When generating a search, for instance, if the object inherits that component code, then architects do not need to model a search object. A search component can simply become enabled if the architect activates it in the right object. Whenever changes are made to models, code adapts to the appropriate changes as long as the models are coded properly.

MetaEdit+ can make use of external APIs and libraries within models, as long as objects can generate the code to access APIs. The models do not need to know about any underlying technology or even the code. In addition to code, MetaEdit+ can be used to generate XML or any other type of Web-based file.

A common mistake that architects can make when migrating from UML to MetaEdit+ DSM is to treat objects as classes. In DSM, architects can raise the level of abstraction because task-level icons can be defined as entire processes that encompass multiple objects. Essentially, the more behaviors that are added to each task, the less likely architects will end up drawing spaghetti-like diagrams.

This emerging technology has caught the attention of Microsoft because of its ability to raise the level of code abstraction well beyond UML's capabilities.

Although in its infancy, Microsoft has incorporated a domain-specific language (DSL) tool into the Microsoft Visual Studio 2005 SDK. The release of DSL alongside the more established UML signifies a shift in Microsoft's view toward enterprise development.

DSL relies on techniques that aim to surpass UML by raising the level of abstraction of models while automatically generating code to form complete applications. Moreover, DSM reduces the need for software architects and designers to act as model translators.

DSM does not yet work well when developing a unique application for the first time. Over the lifespan of an application, however, DSM can be extremely helpful in eliminating many complexities associated with application maintenance. MetaCase believes that models can become the primary artifact for developers, so they do not need to keep modifying code every time minor changes are made to existing systems.

MetaEdit+ 4.5 is priced at $6,000 per developer for non-floating licenses. Pricing varies on volume, platforms and the partner level.

On the channel side of things, Irving, Texas-based MetaCase offers solution provider partners a commission-based package from 32 percent to 55 percent of the sale, rather than margins.