【IT168 技术文章】

    代码生成过程不可行，那么建模语言可能并没有提供足够详细的需求描述。如果模型中出现太多重复，那就需要扩展建模语言以覆盖更多的概念。

    考虑到这些观点，那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，并且已经具备了一些工具支持”。