The most pragmatic reason to use DSM is simply the increased productivity. Industrial experiences have consistently shown DSM to be 5-10 times more productive than current software development practices. But why is DSM so fast?
According to Software Productivity Research, the average productivity in Java is only 20% better than in BASIC. C++ fares no better than Java. In fact, with the exception of Smalltalk, not a single programming language in general use today can show a substantial increase in productivity over BASIC.
So after all of the language wars, objects, components, and frameworks, we are still scarcely more effective than 20 years ago. However, go back a couple of decades more and there is a radical change: a leap in productivity of 400% from Assembler to BASIC. Why was that leap so big, and how can we achieve it again today?
The 400% increase was because of a step up to the next level of abstraction. Each statement in C++, BASIC or Java corresponds to several statements in Assembler. Most importantly, these languages can be automatically translated into Assembler. In terms of productivity, this means you effectively get five lines of code for the price of one.
Traditional modeling languages like UML have not increased productivity, since the core models are on the same level of abstraction as the programming languages supported. One day of UML modeling produces a day's worth of code - but you still need to go in by hand and add or edit the majority of the code. You're trying to maintain the same information in two places, code and models, and that's always a recipe for trouble. Ever seen anybody hand edit Assembler and try to keep their C++ code in synch with it?
Of course, UML has its benefits: the visual presentation can be read much faster to get an overview, for instance. But one look at the ongoing development of UML speaks volumes. Half of the world finds that UML cannot represent what they need in their models, and so want to add something to it. The other half says UML is too complex, and want to reduce it down to its core elements. UML tries to be all things to all men, and thus cannot raise the level of abstraction above the lowest common denominator.
Current MDA tools are based on UML, and thus suffer from its problems. Even a tool vendor sponsored study only found an increase in productivity of 35% compared with hand coding.
How then can we raise the level of abstraction? The last OOPSLA, the leading software engineering conference, put forward Domain-Specific Modeling as a solution. Similar statements have been uttered recently by Bill Gates and Grady Booch, among others.
Domain-Specific Modeling raises the level of abstraction and hides today's programming languages, in the same way that today's programming languages hide assembler. Symbols in a domain-specific model map to things in the domain - the world in which the application is to run. This is a whole level of abstraction higher than UML, and makes each symbol worth several lines of code. The application is automatically generated from these high-level specifications with domain-specific code generators, aided where necessary by existing component code.
As the name suggests, Domain-Specific Modeling is only possible because it narrows down the design space or domain, often to a single range of products for a single company. This is bespoke tailoring rather than UML's "one size fits all", and it results in significantly higher quality. Unlike traditional bespoke tailoring, though, the process can be automated. Standard 'tailors' can simply enter the information in the form laid down by the master tailor, and the product can be automatically created.
The master tailor - an expert developer - defines a domain-specific language containing the chosen domain's concepts and rules, and specifies the mapping from that to code in a domain-specific code generator. In effect, all he is saying is "this is how I look at the world of our products, and this is how I write code for them." The other developers then make models with the modeling language, guided by the rules, and code is automatically generated. As an expert has specified the code generators, they produce products with better quality than could be achieved by normal developers by hand.
Most importantly, making the models is much faster than writing the code by hand. Industrial experiences at leading-edge players like Nokia and Lucent have consistently shown development becoming 5-10 times faster. For the first time since the step up from Assembler, companies can make a major productivity leap. For those doing it first, the competitive advantage is substantial.
Want to know more? See How to get started with DSM.