DSM questions

How does DSM differ from UML?

Answer:The central concepts of UML are from the code world: classes, methods, attributes. Each company that uses UML also has its own domain: its own set of concepts that make up the products it produces. Furthermore, even two companies making similar products will each have their own kind of code. UML tries to offer a 'one size fits all' set of concepts and generators, making it a "jack of all trades but master of none". From most UML models virtually no code can be produced; even if the full set of UML models are made, only a small fraction of the total code can be generated. UML thus does not raise the level of abstraction much from the world of code, and so fails to provide an increase in productivity.

Domain-specific modeling says that each company should take its modeling concepts from the products it makes. These concepts are the same as those found in requirements documents. An expert developer in that domain is able to implement good code based on the requirements.

Part of that skill is being able to express in terms of the domain concepts precisely what the requirements mean. By creating a modeling language and rules for that domain, the expert can enable and guide other developers to create precise definitions of the product at a high level of abstraction.

A second part of the expert developer's skill is in turning those precise definitions in domain terms into good code that works on top of their framework or platform. By specifying that skill into a code generator, the expert developer makes it possible for full code to be generated directly from models. Domain-specific modeling thus provides a radical increase in productivity. Industrial experiences consistently show productivity increases of a factor of 5-10.

UML tools can't generate full code - why can DSM tools?

Answer:Fixed code generators in standard UML tools try to fit all situations, and so can generate only skeletons or bulky inefficient code. In DSM tools like MetaEdit+ both the modeling language and generators are designed separately for each company's requirements, by that company's experts. The models thus include the exact information needed to fully specify the product, and the code generators produce the same code as the experts themselves would write.

Is the generated code efficient?

Answer:The generated code is as efficient as your best expert can write. Instead of writing all the code manually himself, or trying to teach his skills to others, he defines the code generator. In effect, he teaches his skills to MetaEdit+, which - unlike human developers - will not forget or make mistakes applying those skills.

How does DSM differ from MDA?

Answer:The OMG have tacitly admitted that full code generation from UML is not going to happen, and they are pinning their hopes on MDA (model-driven architecture). At its most basic, this involves transforming one UML model into another UML model, possibly several times and possibly automatically, then automatically generating substantial code from the final model.

A manufacturer-sponsored study of UML-based MDA showed productivity increases of 35%. While good, that is a far cry from the 500%-1000% consistently found with DSM.

Can't we achieve the same results as DSM by customizing UML?

Answer:Some MDA proponents envisage higher forms of MDA incorporating elements of DSM. In these, the base UML can be extended with domain-specific enhancements, or even replaced with new MOF-based metamodels. However, experiences with the former have found current tools lacking the necessary extensibility, and no tools support the latter, largely because of fundamental problems and omissions in MOF itself.

MOF describes concepts of the language and how models of those concepts are to be stored and interchanged. A MOF description of a language describes little about those aspects that are of direct interest to its user: what models in the language actually look like, or how the user interacts with them.

Domain-specific modeling has been applied in practice for many years already, with consistent results. In addition, metaCASE tools have proven themselves as ways of implementing tool support for new metamodels. Providing tool support with MetaEdit+ allows you to go much further and with much less work than any MOF-based tool ever could.

How does MetaCase's approach to DSM differ from Microsoft Software Factories?

Answer:Generally they are the same, both advocating the creation of modeling languages to fit the problem at hand. The details are difficult to estimate as concrete Software Factories tools are not yet ready. In conversations with the leading Software Factories people at Microsoft, they have said their tool will be somewhere between what MetaCase's MetaEdit+ offers and what Eclipse offers, and closer to MetaEdit+. Using Eclipse EMF and GEF to create DSM support takes a lot of time and resources. For example, a recent presentation at OOP 2005 by Timothy Ströbele revealed that implementing UML support in Eclipse took 5000 man-days. In MetaCase's MetaEdit+ it took 5 man-days. Similar results are reported in Dr. Dobb's Journal (Tools for DSM, September 2004).

Microsoft unsurprisingly has a strong focus on providing support for domains whose implementations will run on top of their platforms. They also seem to be aiming more at a model where third parties will create and sell DSM languages made with their tools. These third party DSM languages will thus be significantly less domain-specific, and therefore be able to offer fewer benefits. This approach may be necessary if Microsoft's tools require significantly more work to create a DSM language than MetaEdit+: Few companies would be willing to spend 5000 man-days to create support for their own DSM language.

MetaCase's approach is to provide a toolset where it is fast and easy for companies to build their own DSM languages, with final products not restricted to a particular manufacturer's platform. This requires a few man-weeks of extra work up front to create the DSM language, rather than buying it in from a third party. The result however fits the company's needs much more closely, and the company has the skills and tools to evolve the language as its domain and platforms change.

A true comparison of the approaches will only be possible when the Microsoft approach has been used in the real world, and its tool set has had a chance to mature over a few versions. The MetaCase approach has proven viable over fifteen years particularly in various embedded software products, but also in workflow applications, web applications, telecommunication, financial applications etc.

What is the biggest obstacle companies are faced with when adopting DSM?

Answer:Defining a DSM language is a new experience for most people, and they may thus see it as an obstacle. Defining a modeling language involves three aspects: the domain concepts, the notation used to represent these in graphical models, and the rules that guide the modeling process. Defining a complete language is considered a difficult task: this is certainly true if you want to build a language for everyone, like UML for example. The task eases considerably if you make it only for one problem domain in one company!

The key issue for finding domain concepts is the expertise provided by one or a small team of expert developers in that domain. Typically, the expert is an experienced developer who has already developed several products in this domain. He may have developed the architecture behind the products, or been responsible for forming the component library. He can easily identify the domain concepts from its terminology, existing system descriptions, and component services. Problem domain concepts are typically already known and used, well-defined semantics exist and are considered "natural" as they are formed internally in a company.

DSM gives these domain-specific semantics, which must be mastered anyway, first class status. Developers do not need to learn additional semantics (e.g. UML) and map back and forth between domain and UML semantics. This unnecessary mapping takes time and resources, is error-prone, and is carried out by all designers - some doing it better, but often all differently.

Another obstacle is simply the issue of organizational change, present whenever improving the development process. Companies who have been quick to follow fads and all kinds of new 'standards' may well be tired of having to change things yet again. At least this time there is no danger of finding themselves locked in to somebody else's idea of what their models or code should look like!

How does DSM impact the daily work of developers?

Answer:DSM minimizes routine, repetitive tasks the developer can focus on the actual problem. It does not eliminate coding as framework code and code generators need to be defined. However, there is no sense in manually coding something if you can automatically produce the same code, better quality and error-free, 10 times faster with DSM.

The bulk of the cost of any given software project is in maintenance and not in the creation of the software. How does DSM relate to this?

Answer:Software creation is a continuous process, including design and maintenance phases. The domain, requirements and platforms evolve, and thus tools, languages, models and code must evolve with them.

With DSM, the models are both the design documentation - a view of the product at a high level of abstraction - and its implementation. The implementation and documentation are thus always in synch, so developers can trust the models.

There are three main kinds of work in the maintenance phase: bug corrections, responses to new or changed requirements, and responses to platform or environment changes. Since code is automatically generated, many common types of bugs are avoided in DSM. Bugs in the models and responses to new or changed requirements are handled by changing models, with the same productivity gains compared to hand-coding as when creating the initial models.

If there are changes in the underlying platform or environment then this normally has an effect on the code that needs to be generated and possibly on the modeling language. In this case just the expert need make the changes, and the developers' models and code will update automatically. For instance, a Java generator can be changed to create MIDP Java for mobile devices, or a new generator can be made to create C code from the exact same models.

Some UML experts say that modeling solutions that don't adhere to the OMG standard will at best have some relevance in niche markets. What is your point of view on that?

Answer:Standards have a useful lifetime, and then new ways of doing things emerge - look at CORBA for instance.

10 years of UML have proved that it is great for documentation but comes up short for code generation. If we want models to be useful for full code generation instead of just documentation, we need to move beyond one size fits all approaches like UML. Each modeling language in DSM is thus made for a very narrow niche, and is the better for it.

Whilst each DSM implementation will be its own niche, the DSM approach and DSM toolsets are valid across the whole software development market. DSM has already proven itself in many industries, with consistent productivity gains: see the DSM Forum for some of the publicly available cases.