对模型驱动软件开发的理解

作为一个面向对象的程序员、习惯于构件开发的程序员，对于模型驱动软件开发的认识经历了几个步骤。
首先我想到的是：为了适应用户不同的业务组合，很多软件中都有的运行选项。当我们依据自己的需要对选项进行组合后，将得到不同的界面和业务规则。比较常见的有：报表、对于数据的校验、流程等。
接着WEB页面进入了我的视野。利用诸如：JSP、PHP、ASP甚至CGI等技术来生成活动的界面。而太多的这些Pages都是用脚本生成的。当我们改变脚本的时候，在浏览器端的画面也随之改变。
XML是一个更加接近于这种思想的东西。简单的说格式化的数据＋如何显示，构成了XML。而XML本身只是数据而已，它并不是一个软件。但你利用它中间的定义就应该得到同样的显示。这不能不说是标准的威力。同时我也看到，同样的数据改变其中的XSL、DTD等，我们看到将是数据的另一种表达形式。作为数据的XSL、DTD等的改变引起了显示内容和形式的改变。这不也是一种模型吗？
回头看看各种脚本程序。每种脚本都有自己的解释程序。把他们当作驱动引擎，脚本当做自定义的模型。当脚本（模型）变化的时候，程序的运行也将随之改变。
这些都属于朴素的实例。再从一个程序员的眼光看看软件自身的发展历程。
其实我们现在所进行的软件开发都可以看做是一种模型。软件开发经历了静态库à动态库à构件技术。从其中可以看到的是，软件的发展是在不断地提升灵活性和提升系统的可伸缩性。在静态库的时代，代码是在编译时被装载的，动态库是程序在开始运行时被装载的。而构件却是在需要时被加载的，这种加载不一定是由你的程序代码来实现的。
中间语言成了一种趋势， Java是先驱者。先将原代码编译成中间语言，然后用解释引擎（Java虚拟机）去解释。中间语言就是一种动态的模型，它在运行期间被解释引擎解释。MS.Net步其后尘。所有的.Net语言都被先编译成一种公共的中间语言。然后在系统运行期间来解释中间语言代码。这样做坏处是显然的：运行速度降低了。这样的做法又有什么好处呢？首先想到的应该是平台的跨越。Java就是一个例证。同时让程序员摆脱了具体平台的束缚，专心于业务的实现。
这只是对于开发人员的好处。但我们可以看到，模型的不断提升，其结果是让开发人员更加接近于想要表达的业务逻辑。而运行期间的动态模型更是增加了其中的灵活性，更少的代码改变换来更多的对业务的专注。由此，我们设想一下，演进到一定的时期，是不是我们客户中的业务人员也可以设计软件了呢？
我认为这是很有可能的。
软件开发中的原型法和逐步逼近真实的思路是非常有用的。系统分析人员为了得到用户的真实想法，更符合实际业务的逻辑，首先做出一个原型出来，通过改进这个原型最终达到满足用户需要的系统。
虽然面向对象的设计从一开始以对象的方式来思考，但用户的业务流程却是需要经过多轮的磨合才能真正去理解的。
如果一开始我们就提供给用户一个模型定义（或称建模）工具，让用户自己去定义自己的业务。这样，当用户可以修改这个模型的时候也就是业务人员真正参与软件开发时代的到来。那么建模工具就要符合用户的思维习惯，用现实世界中的概念去建立软件。
面向对象、UML建模等能帮助我们去理解模型驱动软件的开发。但模型驱动的软件开发并不是OOD、OOA。在这个世界里，我们看到的是实体。实体和对象并不一样。实体可以是一个对象、一个构件、一个系统。而实体在更多的时候被理解为诸如：报表、物料单、生产计划、客户、销售情况等。
UML是帮助我们的系统分析人员进行软件开发设计的，它更多的是在贴近代码这个层面。但是复杂的图形与文字说明并没有减少用户对软件的神秘和抵触心理。暂且不说用户需要去学习UML，至少在中国能看懂UML图的系统分析员就不多。以一个软件专业人士的眼光去理解用户的业务需求，这本身是有问题的。而你与用户去谈物料单该如何处理的时候，他会显示出非常高的积极性。因为在他看来，他的工作就是处理物料单，处理报表等。谁愿意去学习一种与自己工作毫不相干的东西的？当然你有特别的兴趣除外。
模型就是要帮助用户去设计自己的系统。它是软件中的虚拟业务与现实业务之间的映射器。模型中通过对实体、规则、业务等的表达实现了以用户的思维方式去理解软件中的业务操作。
所以，我认为模型驱动的方法是下一代软件开发的方法。
它应当将OOA、OOD等方法囊括其中，这一点从OMG（http://www.omg.org）的研究中可以得到体现。OMG目前的研究是建立在UML、MOF、CWM这几个东西的基础之上的。虽然OMG的研究，过于技术化，还不是应用层面的解决方案，但其中的思想却是一致的。
以上权当抛砖引玉，欢迎大家来指正与讨论。

原文转自：http://www.ltesting.net