建模的重要性

一本书中介绍,没有面向对象的分析,即使使用面向对象的语言运用面向对象的编程也只能开发出似是而非的面向对象的系统,大家觉得有道理吗?

个人感觉在实际中,没有面向对象的分析,如果有面向对象设计概念,还是可以设计出OO系统。

其实,转换到OO编程,从面向对象设计思想入手反而容易,向上学习面向对象分析,向下进行OOP编程。这是一条踏实的OO之路。

目前,有些团体从OOA开始,UML ROSE学习得很好,但是无法实现到代码阶段的跨越。这是过分重视OOA的一个现象。

我个人认为OOA对于一个OO系统有很重要作用。但是不适合入行者开始使用。

OO是方法论的东西。如果说分析是面向对象的,那有需求驱动的设计就容易面向对象了,但如果没有的话,设计也完全可以独立的利用ood,那编码就更不要说了。说白点就是需求分析是对客户的业务进行分析,整理出系统应该有那些功能,更多是站在客户的角度。而设计是如何把(客户的业务)功能由软件来实现,更多是站在软件系统的角度了。所以需求和设计就OO而言没有必然的联系,也就是不管你需求是否是OOA,系统都可以OOD。而设计才真正影响coding的。

nekesai的观点我比较赞同:
"也就是不管你需求是否是OOA,系统都可以OOD。而设计才真正影响coding的。"
当然,面向模型的分析(MDA)与面向数据表的分析相比,我认为建模更加易于面向对象,虽然有时模型和数据表差别很小,但是这是一个思维侧重点的问题,导致以后的解决问题方式不一样。

我最近参与一个项目咨询,这个项目人员开始沿用面向数据表的设计思路,用Powerdesign设计了数据表,这个项目其实比较简单,我后来按照MDA思想分析出,只有两三个Domain Model,其中有一个共性抽象Model我作为父接口,这些Model之间关系比较多。

当使用面向数据表方法来设计这些数据表时,共性抽象和Model之间的关系变成在一个平面的关系,因此,整个Logic 表之间关系非常复杂,非常复杂网状的结构,当编程按照这个设计进行时,系统变得复杂和罗嗦,同时当需求变化,要求更改这些数据表结构时,编程人员开始害怕和抱怨。

我介入后,花了一个小时时间就理解了他们需求,按照MDA思路将其理顺,使用Domain Model分析后,那些可怕的网状关系就分解成了立体的关系,通过立体手段来实现,这样,从实体bean到前台Struts实现,一下子简化且条块清晰,可拓展性增强。

所以,思路的转变带来的变化是很大的,但是由于我们传统编程教育和现在的大环境,真正要做到面向Model分析设计是困难的。所以当前强调建模的重要性是非常必要的。特别是对于新项目,使用MDA很容易抓住其本质。

再贴一篇还是MDA和面向数据表设计的译文,希望对更多人有益:

The Object-Relational Impedance Mismatch

现在设计应用系统时,主要有两个派别:传统的面向数据表设计和现在流行的面向对象设计。

数据库专家(DBA等)开发设计出数据表结果(SQL或使用powerdesign之类工具建模),而应用程序员则写它们的程序代码,这两种任务在过去一直是独立地进行着,互相不干扰,我曾经在Jdon看到一篇帖子,说网易的一个DBA很厉害,写出的数据表结构如何好,这代表着过去的一种数据库系统开发的方式。

这两种工作是没有联系的,因为数据模型只完成数据实体和数据关系,而应用模型只要实现如何操作这些数据,也就是完成SQL语句或存储过程语句。

当面向对象技术诞生后,从数据专家观点来看,他们觉得这一技术对他们影响不大,但是一些数据库专家已经快速地意识到这是软件开发的一场革命,由此加入新的领域,并且这样的群体不断在增长。

非常不幸的是,还有许多数据库专家仍然认为面向对象的分析流程只是一种暂时现象,根本不接受这种新的变化,依然使用过去方式来分析设计数据库。

这两个阵营目前在互相攻击,出现了严重分裂,但是数据库专家正在遭受更严峻的挑战,特别是使用EJB的实体bean或Hibernate来实现数据持久时,很多以前的数据表设计概念要接受挑战,这也是很多项目设计的痛苦根源。

令数据库专家惊慌的是:面向对象技术UML比数据建模技术更加robust鲁棒。并且可以证明:UML是数据模型的父集,很明显,现在天平已经倾向与面向对象设计了。

这里有很多概念误区:许多数据库专家错误地认为类图只不过是带有行为操作的数据模型,他们没有认识到这其中有些细微地区别,他们没有认识到模型行为的复杂性要超过类图。

面向对象和面向数据表的分裂造成很多恶劣的结果:
1. 项目由于未能及时完成而失败。
2. The technical impedance mismatch技术阻抗加剧
3. 数据建模与对象建模相比,无法涵括项目的全部需求设计,增加内部来回反复折腾。

如何愈合这种分裂?
1.项目参与人员必须同时掌握了解对象和数据表技术
2.按照减少耦合、封装分派等概念重构数据表。

“项目参与人员必须同时掌握了解对象和数据表技术”完全同意,不过我个人喜欢运用面向表编程的思想。因为感觉面向对象在这方面做的并不好,即没有很成熟的技术。

>向对象在这方面做的并不好,即没有很成熟的技术
UML和Rose都是非常成熟的技术啊。

我不是说在设计工具和表示法上,我是说在代码实现上,面向对象的数据库我还没听说那个比较好。若有,我当然要极力推崇。

这里不是说“面向对象的数据库”,谈的是MDA(面向模型分析)。数据库在J2EE中只是一个技术细节。

-〉当使用面向数据表方法来设计这些数据表时,共性抽象和Model之间的关系变成在一个平面的关系,因此,整个Logic 表之间关系非常复杂,非常复杂网状的结构,当编程按照这个设计进行时,系统变得复杂和罗嗦,同时当需求变化,要求更改这些数据表结构时,编程人员开始害怕和抱怨。
〈-
我还没有碰到过,不知你说的是那一种情况。
我一般是ooa,ood的同时,沉淀出数据表来,然后围饶数据表再ood出其他对象来。不知这样有那些还需改进的方。谢谢。

"围饶数据表再ood出其他对象"

这是典型的面向数据表设计,因为目前数据表是关系型的,所以,一开始使用数据表代表实体模型,而不是Domain Object,那么会产生Object-Relational Impedance Mismatch的问题。

Object-Relational Impedance Mismatch问题google中讨论很多。

当然,你可能觉得没有什么问题,但是有时对于复杂无法掌握的新项目,这个问题很多,上面一篇译文也说到,目前很多面向数据表设计阵营中人开始转向MDA,这其实也是一场革命。

进而我疑问:DBA将只是系统运营中的DBA,他如果不掌握面向对象OO分析方法,将会被淘汰。也就是极端地说:面向数据表设计的方法将会被MDA淘汰,当然这其中不免还有很多口舌和争论,我相信是趋势,早点改变早点好。

Object-Relational Impedance Mismatch
我也深感没有什么好技术,最好就是,数据库是面向对象的。但我看到目前一些所谓的匹配技术,还不如自己进行匹配好一些。主要是考虑到大部分程序员sql比较熟悉。

另外,我也看到过,使用域模型的,自己也使用了一段时间,但是虽然让面向对象的设计更彻底了,但是出现如此多的域模型,操作起来感到十分不便,所以我把他们进行了进一步的模糊化,有的地方我就直接用一些数组等集合来传递处理等,不知banq老师怎么看?谢谢。

>直接用一些数组等集合来传递处理
我个人感觉这个办法不是非常好,Struts中有动态Form是用来实现传递的,只有当系统复杂到一定程度,才推荐使用DTO。

另外数组我个人不推荐在J2EE中大量使用,它是一个微元素,在以对象为基本单位处理中,推荐使用Collection。

你说的程序员都熟悉SQL,所以习惯面向数据表分析,这种状况的出现为J2EE等新系统普及带来障碍,这也是一开始象EJB中实体Bean不为很多人接受的原因之一,但是Hibernate/JDO出现,更加会强迫他们转向MDA思维。

如果说设计模式是程序员面向对象必备的基础技能,但是大家有一个奇怪的体验,设计模式我都知道,为什么在我的实践中我很少用到?我的实践中基本都是数据库操作,好像从来用不到设计模式,怪圈就在这里,因为他们是面向数据表设计,而不是Domain Model,Domain Model表现为一个对象,一个普通的Java类,很显然,如果我们采取面向Domain Model之后,很容易就会使用设计模式,因为我们的研究领域都是对象啊。

当数据,从前向后传时我使用的Struts的form,当从后向前时,我喜欢,用“微元素”--引自banq,呵呵。我认为,Domain Model要恰当的使用,如果全用,非常彻底的用我没发现这样能够能提高实际的效率,若是,你不嫌麻烦,你可以使用。