A perspective as background

Many people in the software development arena believe that models are equal to diagrams, particularly UML diagrams.

That is a reason why UML does not feel so compelling any more in comparison with the perspective of a comprehensive notation in the context of a coherent and systematic software design method. It is very hard to communicate with technical teams at customer sites who view UML as a methodology, disregarding many useful lessons from reported industry experience on design methods.

Often, I am using UML as a sketching design tool [1] to communicate in-the-large aspects of software design, sometimes documenting those sketches are useful to show a snapshot of the design at a particular point in time, here is a somewhat eclectic example:



Big problems arise when technical people wanting to look good with management over-sell technicalities as silver bullets that solve social or organizational problems like programmers’ productivity, software quality and the like.

So once again with MDA we have that misleading notion that throwing some in-the-abstract concepts called models is enough to generate a complete, full-fledged production-grade software solution.

That notion can be true for very particular domains, where all commonalities and variabilities have been acquired by means of an intense closed-loop feedback control of the design; and even there unexpected variabilities can be very disruptive.

Stretching the same notion as a general purpose system for software formulation is very hard to grasp. Several industry past projects have wanted to reach that holy grail of a new general purpose source code at a higher level of abstraction, and have failed. Certainly many will try over and over again, that is ok if the general public has not to pay for their tries.

Why Microsoft is on the right track with Visual Studio 2005 DSLs and non-compliance with UML 2.0?

A possible practical alternative is to elevate the level of abstraction for particular domains, and here I mean very specific application domains, e.g. the marketing logic to target previous customers at Western U.S. branch of Contoso Insurance Inc. since 2000 to date.

Visual Studio 2005 comes with domain-specific languages (DSL) mechanisms that are handy for the problem at hand: a family of software systems with a single architectural style and conceptual integrity between their parts.

This is not a "one-size-fits-all" approach; I think this is a practical approach to go higher in the abstraction stack of computations, perhaps a new kind of source code intended to be used in cooperation not in substitution of third generation programming languages.

References

[1] UnwantedModelingLanguage
http://martinfowler.com/bliki/UnwantedModelingLanguage.html