设想由“企业的人”清晰准确地描述它们需要的企业（部分的），然后这些需求或构想被反映在它们面对的企业信息系统中——这可以有很多种不同程度的实现方式或层次，以下四种可能是最典型和重要的：

1. 形成书面叙述文件，交给软件开发者去进一步设计实现。
2. 形成严谨的叙述文件，可能某种程度（部分）电脑可解释的，令其xx地限定整个开发过程和结果。
3. 形成xx电脑可解释的模型，自动生成代码。
4. 形成电脑可执行的模型，基于通用的平台，直接形成面对用户的“功能”。

我在1998年所提出的新一代企业信息系统构思，对应上述第四层，我自己称其为“模型驱动系统”（Model Driven System, MDS）。目前MDA的理解和应用，主要集中在第二层和第三层。不同层次上，对模型的要求、效果和实现方法，都是不可同日而语的。

所谓直接驱动企业平台，要省略上述3）所保留的{zh1}一点传统“编程”的手续，这种过渡在逻辑上是很自然的。正因为如此，很早以前我就猜测3友代表的研究走向，后来得知他们的提法是可执行的UML。

……我提出上述4点，是说明由传统的需求-软件功能转换过程到模型驱动系统可以是怎样过渡的，并非说明模型驱动的愿景。这个视角也是通常说的软件生命周期 的视角，但需要留意，我一再强调，要区分“模型驱动开发”（MDD）和“模型驱动系统” （MDS）。例如，我们可以用“模型驱动开发”的方式来开发模型驱动系统。

在上述4点中，到MDS有些事情发生了质变，譬如所谓“软件生命周期”，“最终用户应用系统的生命周期”和所谓平台的生命周期已经分离了。

{zh1}我想说的是，我的一个基本出发点，但迄今从来没有得到过一次xx的最基本点，是用户需求与MDS的关系。

正是基于对用户需求的深层认识，我才知道这个思路的核心价值还没有真正被捉住。现在已经实现的产品，其实在技术上已经比我想做到的复杂多了，但却不能捕捉到我强调的应用要点。

所以我根本不担心技术问题。问题还是出在“技术导向、概念驱动”上。

评注：以前讨论时，使用了“过渡”的提法，结果容易使人们的注意力局限于软件生命周期的思路，实际上这里讨论的，正是IT人特别重视的所谓IT与业务如何 对齐（align）的具体技术途径的问题。在这些方面，软件开发者的眼光聚焦在技术架构、实现方面。例如，MDA就是一种典型的技术架构，是相当纯粹的软件技术课题。SOA现在也基本被当成技术架构在玩。我的出发点，首先将“模型驱动”看作一种实质性的“需求”，它决定需要什么样的技术支持或实现。

上述第四种途径，关联到我新一代企业信息系统算思考的起点。“在此之后”，就是我一直研究的东西。在相关的讨论中，曾经有所涉及，例如：区别企业模型与系统模型。几年前这些公开讨论，最深的地方，大致就到这里。事实上，观察现在企业应用领域的许多焦点问题，可以发现，这个程度的认识，迄今依然是非常稀有。

后来提出的MDM与MDS，从技术或一般系统范式的角度，本身是一个更一般化的课题。问MDM的模型，不限于企业模型，MDS的系统也不限于企业应用或信息系统。软件开发人员很容易理解或者喜欢“执行”或运行（run）这样的词，但对于企业模型在企业应用/信息系统中的作用，这个词并不确切（参见后面的讨论），那么种种的模型到底都可以怎样起作用呢？这就是模型驱动机制，或再进一步的“模型工作机制”（Model-Wroking Mechanism）要研究的东西。

层级性大概是人们对复杂系统结构总结出来的最基本的特征，可是因为它太基本了，以至于无法搞清楚什么是层。可以退一步，求一个较弱的原则：不管什么是“层”，但将不同的“层”加以比较时，必须弄清楚它们各自是那一种层，或者说各自分层的原则之间有什么区别。

MDA中最重要和基本的“层”的表现，是“元层次”（M0 – M3），这实际上是一种“表达”的层次：高层次的模型要素就是低层次表达的实例。这是一个清楚的划分原则。PIM/PSM（平台无关模型与特定平台模型）的区分是另一种（或者说另一个维上面的），所以不能和元层次相提并论。

TOGAF架构，关于业务、技术等的区分，与PIM/PSM之间似乎是有“一比”的，然而MDA的讨论是有相当清楚（也比较窄）的语境的，一切关于“业务”或更具体的东西，都被概括在M0层了。我看到对MDA的探讨，则集中在M1层和如何实现——先弄个PIM，然后怎么映射到PSM，（无非是为了生成代码，{zh1}生成可执行代码）。这个思路就与我说的MDS走到不同的路上去了。而这不同的路，对“模型”自然有不同的理解和要求。

进一步说，讨论这些不同层次的模型，必须留意：

• 表达的方法应当适应（满足，或更强地说，是制约）于表达的目的；
• 用于编码实现和用于直接的功能（行为）驱动这两个目的背后隐藏着深刻的不同；
• 这使得适合它们的表达方法——建模方法也有深刻的不同。

这三句话的认识，是我对这个课题长期深入探索中一点一点体会的。

评注：前面关于MDA的模型层次，再延伸一点，到所谓CIM（计算无关模型），就触及“实质问题”了。进入到这个领域，模型的类型与层次，须与其应用方式、建模方法和支撑技术结合起来讨论，否则就可能是空中楼阁。

从UML到MDA，再到可执行UML（xUML），确实有某些东西演进到一个极点。MDS与可执行UML就好像处于极点的两边，紧紧相接，却有着xx不同的背景或寓意。

xjcxp对于MDA,UML到xUML这个思路，提出了一个“公式”来概括：

Drawt it -> Run it

这是一个很精彩的概括，但我认为 Run 代表了一个不一定是必然的过渡（这就是MDS与MDA思路的区别）。借用这个公式，可将我的看法表达为

MDS: Drawt it -> ( Run it ) -> Driven with it

这不是在改动 Drawt it -> Run it 这个表述，而是借xjcxp对 xUML 的形象描述，对 MDS 做一个对比的描述，“run it”和“driven with it” 恰好能够反应出二者的微妙差别。

就软件技术发展的现状来说，run it 是顺着“主流”思路的一种自然前景，但从技术变革的跳跃性来说，并非一定要先做到它才有更进一步的东西。不过这个话题可存而不论：软件技术会是多样性的，不同的技术有不同的用途。

MDA与MDS是不同的概念，但MDA并非MDD（模型驱动开发），MDA从来没有排斥MDS，只是——大多数软件专家，包括OMG当前的主要看法，是先把精力放在了似乎更现实的MDD上。

但是，当真正理解了MDS后面的原理（也就是MDA的提出本身所依赖的原理的深层部分），就会发现，原来现在认为要一步一步先“筷子夹着MDD，眼睛望者xUML”，并不一定是一个xx的、必然的步骤。其中有一些我们已经习惯的，不再有人怀疑的东西，并非天经地义的。

就我个人研究的结论而言，MDS会具有更“简单”的架构与实现体系，更低的运行期系统冗余度（例如以机器指令为基本要素来衡量执行系统的复杂性）。从理论的角度，我对于自己上述的结论非常自信，这个自信正是来自如你所过奖的“非常严谨”——对我来说，是小心翼翼、战战兢兢，并且尽量不使用自己的概念。

正是有这个基础，我才会提出“轻型平台”的开发计划。相对而言，当这里的一些关键原理没有弄清楚之前，就很难不陷入“冗余性、复杂性的陷阱”，所以现在我们可以看到，国内几间公司已经实现的、基于企业建模的产品，相对都比较“重”，所以定位于大型企业应用。能不能轻量化，是一个试金石。

评注：这里的讨论，就是围绕着软件语境的“执行”与新引进的“驱动”的不同展开的。讨论中提到的“MDA的提出本身所依赖的原理的深层部分”，就是模型驱动机制（更广泛地看，是模型工作机制）。十年下来，可以说，对这一方面的认识不清或忽略，限制了MDA的成就。MDA基本囿于代码重用、互操作性与集成这些IT“主流”的思维定势子，即使探索性的可执行模型（例如xUML）似乎也没有什么进展。微软这几年有一个Oslo计划，似乎与MDA没什么关系，但也没有体现出这方面的图片。企业应用领域真正的模型驱动方面的成功，反而可以不关MDA的事，例如BPMS领域的许多优秀产品。

• 《》，2004年8月
• 《》，2004年11月
• 《》，2005年7月
• 《》，2006年1月