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

robert_sz 2002-05-21 04:30:00
以下文章来自企业工程论坛(http://www.ee-forum.org)讨论组


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



鲨鱼(sharksz@sina.com) 2002-05-21



作为一个面向对象的程序员、习惯于构件开发的程序员,对于模型驱动软件开发的认识经历了几个步骤。

首先我想到的是:为了适应用户不同的业务组合,很多软件中都有的运行选项。当我们依据自己的需要对选项进行组合后,将得到不同的界面和业务规则。比较常见的有:报表、对于数据的校验、流程等。

接着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的研究,过于技术化,还不是应用层面的解决方案,但其中的思想却是一致的。

以上权当抛砖引玉,欢迎大家来指正与讨论。
...全文
2 点赞 收藏 5
写回复
5 条回复
切换为时间正序
请发表友善的回复…
发表回复
flyfash 2002-05-25
我的解决方式是:看看业务流程,画个图,睡一觉。看看钱能的体系,然后
写下自己的想当然的类,留下3个空属性、方法。
然后,一阵填类。一般情况,他们都是空的,但是作为流程的一部分,他们是不可或缺的。
空步骤,也是工程的一部分!
回复
romberg2002 2002-05-25
“对象可以包含在过程中,而不是过程包含在对象中.”赞同!所以首先要有过程,然后再在过程的基础上提炼解决问题的对象,再把这些对象按照现实的信息流动方式连接
回复
jnwen 2002-05-21
又:
为什么面向对象的方法很难学?就是因为这是一种不自然的想法,和一般人的理解问题的方法是相违背的.
Rationg的UML我粗看了一下,还是没有摆脱这种思维方法,所以也比较混乱,所以使用起来大家比较困惑,解决实际问题有困难.
跳出面向对象的思维圈子,才能登高望远.
回复
jnwen 2002-05-21
我觉得面向对象的思考是有问题的.面向过程才是最自然的考虑问题的方法.
对象可以包含在过程中,而不是过程包含在对象中.
比如考虑物料单,用户关心是物料怎么流动的,从哪到哪,不关心两边是怎么处理的.按照面向对象的考虑方法是设计一个发送对象,一个接收对象,然后对象间通讯,过程和信息包含在对象中.
但是一般用户关心的却是信息流动的过程,所以按照正常的设计,应该是设计一个过程,包含信息流和发送者/接收者.对象包含于过程中.这实际上就是UML的思想.
所以我说UML实际上是对面向对象思考方法的否定.
程序员从面向对象的方法去解决别人的问题,肯定会导致很多问题,双方无法沟通,因为看问题的角度不一样.如果从面向过程和信息流动的角度沟通和解决问题,思维是最自然的,最容易沟通的.
相对于模式驱动,我更觉得应该是叫做面向信息流的方法.我正在思考着方面的问题,有空联系.
面向过程和面向对象的方法都有自己的缺陷,需要批判的吸收
回复
青润 2002-05-21
文章还不错。
回复
发动态
发帖子
研发管理
创建于2007-08-27

1180

社区成员

软件工程/管理 管理版
申请成为版主
社区公告
暂无公告