建模语言应该是什么样子？UML 又处于何种位置？

根据 Steven Kelly 和 Juha-Pekka Tolvanen 所著的《Domain Specific Modeling》一书，Learning Lisp 博客的作者 Lispy 提出了一些对“建模语言应该是什么样子”的想法：

1) 它应该映射到领域问题的概念，而非实现细节。

2) 它必须形式化，不仅要有利于与领域专家之间的沟通，还要能够从模型生成可执行代码、文档和某些测试类，免除实现其它一些测试的需要，并为维护人员提升代码的抽象层次。

3) 它需要有单独的工具支持，能让领域专家“在模型能‘编译’为完全的功能代码的方式下组织框架和库”，而又不需要他们从代码的角度去考虑。为了说明这一点，Lispy 拿将 C 编译为机器代码作为类比，C 在某种程度上“对机器代码来说就是一种建模语言”，C 程序员不必修改由编译器编译的机器代码，而编译器则由机器语言专家来创建。

因此，要获得真正有用的建模语言，你必须从问题的两个方面来同时考虑“领域特定”：建模语言必须直接映射到问题领域，而生成的代码则必须映射到目标环 境。[……] 如果代码生成过程过于复杂，你在框架级别可能需要更好的抽象。如果代码生成过程不可行，那么建模语言可能并没有提供足够详细的需求描述。如果模型中出现太多重复，那就需要扩展建模语言以覆盖更多的概念。

考虑到这些观点，那 UML 又处于什么位置呢？据作者所说，UML 并不是适用于模型驱动开发的工具。UML 不能被编译、执行或解释，那它就“只剩文档编制的作用”，而且“对项目来说，除了作为详尽的代码注释外别无他用”。根据 Lispy 的观点，UML 的抽象应用在了“错误的一方”，UML“是设计用来映射到代码架构的——因此 UML 并不能提升抽象的层次”。

Seven Kelly 最近也表达了类似的观点：

我一直认为 UML 对实现的选择约束得更加具体 [……]——比如限定在面向对象语言，比如在模型中直接指定了实现中的个别类、属性和方法。[……]UML 中能算是高层次抽象的部分只有用例图，而这是在完全失却精确性的情况下。

然而，Franco Civello 在他的帖子中对此做出了回应，他认为倘若一个人只使用“UML 适用于精准阐释的那些部分”，仍然有可能在模型驱动开发中成功使用 UML “在高层次的抽象上表达精准的模型”：

我将给出一个例子来证明我的观点，这个例子使用 UML 编写精准的模型，而没有实现细节。

[……] 产出非正式的用例来阐明需求，以及领域模型来获得对主题范围的初步认识，分析师用 UML 生成一个精确的规格说明模型，其中要开发的系统被表示为对象，并属于某个类型（注意，不是一个类，因为系统是用来定义可见行为的抽象，而不是用某种语言（比如 Java）直接实现的软件实体）。

用例流程中的步骤接着形式化为基于系统类型的操作，并附带有对行为的声明性说明，行为则基于功能契约的概念，而且这些步骤会在底层模型之上（系统类型模型，从领域模型驱动）写成前置条件和后置条件。

Lispy 觉得这种做法很有意思，他认为这不一定就与 Kelly 和 Tolvanen 在其书中建议的相矛盾。UML 用来映射到领域问题，而不用来描述代码架 构，它一定程度上是形式化的，而且正如 Franco Civello 强调的那样，“UML 有一个可执行子集——xUML，并且已经具备了一些工具支持”。

查看英文原文： How a Modeling Language Should Look Like and where UML Stands with Regard to this?