How a Modeling Language Should Look Like and where UML Stands with Regard to this?

 Based on the book Domain Specific Modeling by Steven Kelly and Juha-Pekka Tolvanen, Lispy, the author of Learning Lisp blog, exposed some thoughts on how a modeling language should look like:

1) It should map to the domain problem concepts and not implementation details.

2) It has to be formalized and helpful not only for communicating with domain experts but also for development tasks by making it possible to generate from the models executable code, documentation and certain classes of tests, as well as by eliminating the need for implementing some other tests and by raising the level of abstraction for code maintainers.

3) It needs to have stand alone tooling support that would allow domain experts to “organize their frameworks and libraries in such a way that the models can be “compiled” into fully functioning code”, and this without them having to think in terms of code. To illustrate this idea, Lispy uses the analogy of compiling C to machine code, where C is in some way "a modeling language for machine code" and where C programmers don't have to modify the machine code compiled using compilers created by machine language experts.

So, to get a modeling language that is actually useful, you have to go “Domain Specific” on both sides of the problem: the modeling language has to map directly to the problem domain and the generated code has to map directly to the target environment. […]If the code generation process is too complicated, you may need better abstractions at the framework level. If the code generation process is impossible, then the modeling language may not be providing a detailed enough description of the requirements. If there is too much repetition in the models, then the modeling language will need to be extended to cover additional concepts.

Where does UML stand with regard to all these observations? According to the author, it is not an appropriate tool for model-driven development. It can’t be compiled, executed, or interpreted, thus being “reduced to the level of mere documentation” and adding “no more value to a project than an elaborate code comment”. According to Lispy, UML applies abstraction “at the wrong end of the problem” because it “is designed to map to coding architectures– and because of this it fails to raise the level of abstraction”

Seven Kelly has recently expressed similar opinion:

I'd always thought of UML as being more specific about implementation choices […] -- e.g. the restriction to an object-oriented language, and the individual classes, fields and methods of an implementation specified directly in the models. […]The only part of UML that is on a high level of abstraction is the Use Case diagram, and that's only at the total loss of precision.

However, reacting to his post, Franco Civello argued that it is still possible to use UML successfully in model driven development in order “to express precise models at a high level of abstraction”, provided that one only uses “those parts of the UML amenable to a precise interpretation”:

I will justify my position by giving one example of how UML can be used to write precise models with no implementation detail.

[…] having produced informal use cases to clarify requirements, and a domain model to get an initial understanding of the subject area, the analyst produces a precise specification model, in UML, in which the system to be developed is represented as an object, belonging to a type (note, not a class, as the system is an abstraction used to define visible behaviour, not a software entity to be directly implemented in e.g. Java).

Steps in the use case flows are then formalised as operations on the system type, with a declarative specification of behaviour based on the notion of functional contract, written as pre- and post-conditions expressed on an underlying model (the system type model, derived closely from the domain model).

Lispy judges this approach interesting and he argues that it is not necessarily in contradiction with what Kelly and Tolvanen suggest in their book. UML is used to map the domain problem rather than to describe the code architecture, there is a certain level of formalization and, as highlighted by Franco Civello, “an executable subset of UML, xUML, is also available and supported by some tools”.