MILY: 宋体; mso-hansi-font-family: 'Times New Roman'; mso-ansi-language: ZH-CN">模型驱动应用的核心和症结就在于一个长期困扰我们的问题：如何对复杂问题建模？对模型驱动的众多怀疑正是这个问题没能得到有效解决的明证。

一、MDA的规划及实现

MDA的规划其实是非常宏伟的，MDA显然充分意识到了问题的复杂性，所有严格区分了MDA四类模型：

     1、计算无关模型（Computation Independent Model, CIM）

     2、平台无关模型（Platform Independent Model, PIM）

     3、平台特定模型（Platform Specific Model, PSM）

     4、实现相关模型（Implementation Specific Model, ISM）。

其中3、4二个模型解决软件基础设施问题，也即如今热门的业务基础平台问题。模型驱动实现的关键在于，从PIM到业务基础平台如何对接。就MDA的规划来看，主要是通过模型交换。但可执行UML（xUML）显然给出了另一种快捷的方式。这样，就有二种模型驱动的实现方式：

    xUML--就是使用动态执行引擎直接执行UML模型

    模型交换--就是把PIM模型变换为容易执行的PSM模型

MDA更多的是从白盒视角规划了业务基础平台的实现架构。可执行UML的模型驱动程度无疑更高。且较之MDA采用PSM来解决对多平台的支持，xUML则是类java跨平台的方式，显得更为敏捷。

二、计算的逻辑模型或逻辑服务模型

更重要的是，xUML实际上消解了PIM与PSM的区分，而专注于计算的逻辑模型。所以，在关于《新一代企业信息系统研究与开发纲要》的对话中，我用不严格的语言表术了这个问题：

    从现实的观点出发，逻辑层（或服务层）才是模型驱动的关键。就一般而论，业务模型与技术体系的松散耦合，是以逻辑服务层为中介的。所以，我得出一个结论：一套良好的服务元语义，可能是模型驱动系统的关键。

这里，我把计算的逻辑模型称为逻辑服务模型，是想融合进SOA的思想（而不是技术）。所谓一套良好的服务元语义就是指一种xUML的规范。显然，这里一个隐含的前提是，UML语言本身并不能直接作为这种规范，需要在其上扩展，尤其是融合DSL，方能构建出良好的服务元语义。

当然，这里出现了抛开UML另起炉灶的观点。从理论上，这也是可行的。比如，Microsoft就可能这样做。但是，这个成本太高，也只有Microsoft玩得起。事实上，模型驱动的思想很早就出现了。如今通过MDA流行起来，实际上是得益于UML的成功。抛开UML谈模型驱动，明显缺乏根基。最近UMLChina上的一个消息微软: "UML and more" 的延期和期待表明，就是财大气粗的Mcrosoft也并不想赤裸裸地抛开UML闹革命。所以：

     UML无疑还是需要的，它是“模型驱动应用”具备现实可行性的前提。重要的不是抛弃UML，而是如何完善和拓展UML，以构造一套良好的逻辑服务建模规范。

在我前面的一系列随笔中，多次提到业务本体分析的意义。实际上也是在探索拓展UML的可能方式。把“本体”概念与UML关联，无疑很有希望开拓一个全新的领域。当然，这个难度很大。我曾经在转帖：CYC+CRM：知识商务的未来之路 中说：

     就已有成果看，如CYC给出的知识体系，同ERP类企业建模产生的抽象业务体系，在概念的分类上有较大的交叉；尽管从理论上讲融合起来是可能的，但实际上将可能是长期的过程。

不过，这个进展目前看来还不错。DSTC提交到OMG(对象管理组织)的本体定义元模型(ODM)，就把本体和模型清晰地关联了起来：

     面向对象模型的目的是抽象，去掉和简化了与当前任务无关的概念和关系；而本体的目的是知识表示，不能简化。没有完全的本体，必须支持本体的更新和进化。面向对象模型的实例要由最终实现来创建和管理，每个实例都是事实；而知识管理则从逻辑推理出发，不必创建所有实例，并且实例只是表示看法和观点，允许不同源的知识有冲突。

     本体和模型的关系：模型可以看作是本体在当前任务条件下的抽象和简化。本体可以转换为模型。

而且，ODM中的元模型体系也初步成熟：

      1、描述逻辑元模型

      2、RDF Schema元模型

      3、OWL元模型

      4、简单公共逻辑元模型

      5、关系实体元模型

      6、Topic Maps元模型

那么，ODM是否可以作为一个有效的逻辑服务建模规范呢？还没有定论。从现有成果来看，OWL在知识发现方面做得还不错。从一个实用的观点出发，也可以说，把本体引进UML，无非是以UML构建了一种融合OWL的知识发现领域的DSL而已。

三、计算无关模型或业务建模

当然，如何使UML变得可执行，这是问题的一个方面。还有一个重要的问题是，计算无关模型CIM又该如何同xUML对接呢？

我通常把CIM模型简单地称之业务模型，从而明确地与当前的企业建模成果关联起来。现有的主要从CIMS演化而来的企业建模，与UML的面向对象建模，是有较大裂缝的。当然，这种融合也已开始。如ARIS就已经有了与UML之间的关联性成果。最近，UMLChina的一则新闻DMTF和OMG结盟用UML和XMI来打造CIM显示，传统企业建模纷纷加快了与UML融合的步伐。网上曾经一度有关于UML究竟适不适合业务建模的争论，看来现在都搁置一边了。融合是大势所趋。

但UML如何适应业务建模其实还是一个问题。实际上，与ODM在元建模层次上融合本体与UML的做法不同，我更多的是关注通过扩展UML构建本体业务体系的可能性。也就是说，我只是在CIM模型的层面上融合本体分析的思想。

正是这种努力，我发现了问题的复杂性：从业务模型直接驱动应用，就现有技术而言，还是有困难的。所以，在关于《新一代企业信息系统研究与开发纲要》的对话中，我表达了抵达目标的通途是否已经具备的观点：

    我降低了模型驱动的目标，这是切合MDA技术发展的。也就是说，只有把业务模型转换为逻辑模型，才能放到技术引擎里执行。直接执行现有企业工程理论的那种业务模型的技术引擎是未来的目标。

总之， 模型驱动应用的现实愿景是，从业务建模的CIM模型到逻辑服务模型，适合采用模型交换实现对接，而从逻辑服务模型到可执行应用，则完全可以采用xUML技术实现。