谁的硬伤?

rolt UMLChina(杭州先思软件技术有限公司) CTO/CIO/技术总监  2002-05-11 03:12:49
谁的硬伤?

http://www.umlchina.com/News/fatal.htm
(更新:5/11/2002)

讨论和补充
http://umlchina.smiling.com/group/posts/view_forum.ecgi?group_id=9986&res_message_id=1130079

你知道人的硬伤是什么吗?自私?贪婪?懒惰?不宽容?...都不是,是死亡。死亡是一切宗教的核心秘密。现在,如果有人以死亡为理由攻击人类,讥笑人类,并推销他的“长生不死药”,你相信吗?

《程序员》杂志2002年5月号里就有一篇《UML三大硬伤》(第49页,以下简称《程》文),列举了UML给软件开发带来的累累罪恶,令人毛骨悚然。考虑到《程序员》发行量较大,而且UMLChina的名字里带了UML三个字,只好出来解释一下,以避免《对象技术三大硬伤》、《设计模式三大硬伤》、《XML三大硬伤》等文章不加思索地出现,误人子弟。也希望能对《程序员》杂志有所助益,因为在合上杂志之前,又发现一处明显错误,第23页,李维演讲摘要,编辑特别重点括出来的地方的第一段只有一句话,就有两个错误:(1)设计模式的英文变成了design partner;(2)“写coding”说不通。

本文不是反驳和辩论,也不是探讨。辩论和探讨,这么多年,国外已经进行得够多。本文的目的是,对《程》文进行一些分析,针对由于《程》文对UML和对象技术认识不足或某些原因导致的行文偏差进行澄清,并分析《程》文产生的深层次根源。由于时间关系,本文不能一次写完,但一定会抽时间慢慢写完,也希望本文读者能积极补充。

首先要说的是:(1)实在很抱歉,UML不能化解巴以危机;(2)事物的发展是一个扬弃的过程,对象技术是对以往结构化等开发技术的扬弃;(3)旧事物经常以“各有千秋”来否定新事物;(4)很多时候,屁股决定脑袋,利益决定观点。

《程》文:在国内的公开报道中,几乎众口一词地充斥着对UML的褒奖,即使有公开抱怨也只是怪自己无法理解三位UML创始人的深度思想,怪自己水平不够,没有料到UML本身却存在着种种问题。

评论:作者似乎在这里搞反了。国人的习惯,在学习先进事物碰到问题的时候,不是虚心钻研,深入研究,而是倾向于妄加攻击,另起炉灶。如果实践者在运用UML碰到问题时,都是象《程》文作者所言“怪自己无法理解三位UML创始人的深度思想”,必然就会更深入地去查资料,看资料,思考...如果能这样,那真是阿弥陀佛。我相信随着学习的深入,多数问题都会不成其问题。但是实际上并非如此,我们更多看到的却是不加思索地认为“问题多多,不合国情”,然后以“民族工业”、“中国特色”为口号来攻击对手。

题外话:UMLChina和《非程序员》推崇的是谦逊,虚心学习。所以,UMLChina的专家交流一直坚持邀请国外真正的大师和大家交流,绕过了国内。《非程序员》的稿件也不强调原创(很多原创就是抄,这是公开的秘密),而是在作者的同意下,如实地翻译一些包含优秀思想的文章。

《程》文:本文作者在北京大学计算机系同行那里发现他们撰文对UML的有效性提出了质疑。与公开报道相左,业界私下流行的观点形象地说明了UML存在的问题和为软件开发设置的障碍,那就是“上不着天,下不着地,一盘散沙”

评论:打住!“上不着天,下不着地,一盘散沙”此言何来?是“北京大学计算机系同行”说的吗?我知道北大的邵维忠老师是写过一篇“统一建模语言UML述评”,但好像里面没有这么说。是“业界私下流行的观点”吗?在何处流行呢?还有下文提到的顺口溜式的“高不成,低不就”,似乎是那么的熟悉。我查阅了作者以前在《程序员》发表的文章,这些顺口溜果然在其中。UMLChina讨论组也曾经对此进行了评论:http://www.umlchina.com/best/g6/g377.htm。

Martin Fowler在1997年就指出:“你应该使用UML吗?一个字:是!旧的面向对象符号正在快速地消逝。它们还会残留在UML稳固前出版的书上面,但新的书、文章等等将会全部以UML作为符号。如果你正在使用旧的符号,你就应该在1998年间转换到UML。如里你正要开始使用建模符号,你就该直接学习UML。”(面向对象分析和设计技术,Martin Fowler,《非程序员》第五期)。五年过去了,事实证明正是如此。我们可以翻翻能买到的国外1998年以后出版的和面向对象有关的书籍,看一看是否如此。---不用UML用什么?用一种“符合中国国情的建模语言”?

《程》文:“上不着天”这种隔阂使建模结果无法与用户沟通确认所谓的需求,埋下了软件危机的祸根;

评论:用例已经被证明是捕获功能需求的有效手段(《非程序员》几乎每一期都有相关文章)。《程》文中“无法与用户沟通所谓的需求”咄咄逼人的语句不知从何而来。

事实上,作者在文中各处,把很多不应该由UML负担的责任,统统推给了UML。UML只是一种语言,用好用坏,全在于使用者的知识(也许是对象技术知识,也许是业务领域知识)。低劣的用例文档粗陋不堪,不忍卒读;优秀的用例文档,就象清新的文章,读起来赏心悦目。编码领域也是如此,同样是用C++,程序设计专家和新手的代码也是天差地别。

《程》文:“下不着地”这种隔阂使千辛万苦得到的建模结果无法指挥程序员编码,最后得到的软件与用户期望的结果相差很远,返工,误工,烦恼无穷。

评论:1. 建模过程并非“千辛万苦”;2. UML顺序图和类图的映射,类图和编码的映射,在各种UML工具中越来越完善。3. 同上:UML只是一种语言,用好用坏,全在于使用者的知识。4. “模型-代码转化”这个难题,UML工具可能现在还有很多不完善之处,我们只能等待改善--难道××法就可以吗?(关于UML的将来改进,OMG的UML负责人的观点在《非程序员》第13期)

《程》文:“一盘散沙”这种隔阂让建模图形之间的关系凌乱不堪,建模过程千辛万苦,建模结果很难自圆其说。这三大隔阂造成的建模硬伤使UML辜负了人们的殷切期望,“高不成,低不就”说明了UML建模在软件生命周期中步履蹒跚,“一盘散沙”说明了UML在建模内容中并未实现Unified的原旨,图1是UML存在问题的可视化表达。

评论:此段文字先假定UML是“一盘散沙”、“高不成,低不就”,然后在推理出应用UML时发生的种种惨状,并用一幅图形来定死。文革时人们也经常说,“就是好,就是好,就是好”,然后再围绕“就是好”这个先行主题引申,不管如何写,都离不开事先定下的基调。

《程》文:诚然,掌握UML很容易谋到一份很好的系统分析员工作,但用它却很难做好系统分析员的份内工作,使用UML肯定可以100%地蒙住用户,因为用户对满篇的建模图表只有招架之功,绝无理解反驳之力,使用UML也可以几乎100%蒙住软件公司老板,因为老板不是系统分析员,不知道使用UML进行建模的千辛万苦,系统分析员无法向老板反映UML存在的问题,因为这样很容易招致水平不高的责难。

评论:

1. 按照第一句话,系统分析员们真的是比黑哨还黑,比贪官还坏。

2. “用户对满篇的建模图表只有招架之功”一句说明作者对UML的知识缺乏。按照统一过程的框架,在需求工作流阶段,用户需要面对的非文字的“图表”就是域类图和用例图(视需要还有界面原型),文字类的工件是术语表,用例文档,补充需求说明。而以上这些工件都强调“技术无关”、“使用业务语言”。

Martin Fowler曾说过,“我曾经为客户服务监督、医生、护士、金融商货和公司财务分析员教授面向对象的分析和设计技术,同时,我发现,对于他们来说,有没有IT背景其实是无关紧要的,例如,我知道的最好的建模人员是伦敦一家医院的外科医生。”(《非程序员》第一期)。

再看看《非程序员》第13期里Gary K. Evans怎么说,“我所知道的一个最好的用例撰写者之一是一位女士,她是一位银行家。她在生意上非常精明,但不懂技术。我们用了三个两小时的会议一起开发一个电子商务系统的用例。在这些会议后,她有了灵感,完全明白了。于是她利用获得的新知识和她出色的写作能力,迅速完成了新系统的用例需求。她的工作是杰出的:没有一句技术术语,只有非常清晰的业务过程。”。

《非程序员》第13期的James J. Odell访谈中也指出,“每个人都应该懂得UML,但不是每个人都需要知道UML的所有东西。领域专家不需要看组件模型。”

★暂时先写到此处,有时间再写,希望大家能进行补充,谢谢--think★ 

讨论和补充
http://umlchina.smiling.com/group/posts/view_forum.ecgi?group_id=9986&res_message_id=1130079
...全文
27 点赞 收藏 7
写回复
7 条回复
切换为时间正序
请发表友善的回复…
发表回复
weidegong 2002-05-17
Dr.OO 看了原文的论点,完全是站不住脚的,作者行文非常武断而且情绪化,根本不是一种科学的态度,说得不客气一点,简直是“胡言乱语”!不经过科学的调查就轻下妄语,不知他们哪里来得胆量。《程序员》居然刊出这样的文章,令人遗憾而后怕!

说得不错
回复
faust 2002-05-17
UML是很好的用来帮助对象设计的描述语言
想用好它,关键是要深入理解和应用OOP的设计开发思路

围绕它,配合一些好的软件过程被证明都是很成功的。

国内:
由于历史的和现实的一些原因:
个人认为:面向对象的设计方法在很多开发设计中并没有被很好的应用
更别说围绕OOP的开发过程了

对复杂的对象间关系可以用进程图描述静态的分析,用活动图描述动态的分析

现在的项目,特别是在大中型项目,最重要的是整体的构架,UML配合一些软件过程能有效的按规程,高效率的作出设计分析。而相对来说,一些细部的处理,本身的重要性,对一个企业来说,对一个项目来说,都不是很重要。(这正是认为UML薄弱的地方,别人的开发,我并不赞成)

有些细部设计用UML难以描述:
这有两种情况:
1、过程非常复杂,但事实上是因为没有很好的抽象,没有进一步按照面向对象设计思想进一步分解(这种情况很多)
只要按面向对象设计的设计思路做出更好的设计,这个设计自然可以用UML很好的描述.

2、过程很复杂且不可分解(很少,我的理解)
可以按原来面向过程的流程图做出描述(但有遵守一个已定义的规范,UML是允许这种扩展的)

总之,个人认为UML是帮助面向对象开发的利器,前提是对OOP,设计模式有深入的理解和应用。最好公司的软件过程也围绕OOP。

对UML我这样看,发现了UML不能描述的设计,多想想自己的设计过程,设计思路为什么难以描述,这样比指责UML得到收益要大得多

说说我个人的经历吧,
我刚接触UML,也发现了自己的设计过程,设计思路用 UML难以描述
深入的找资料,分析后,发现关键是我对OOP的设计过程不了解
我把以前很多的代码重构了
同时新的设计全部用OOP的设计思路设计

当然这个过程里,也有开发过程的改进,这大概花了我半年时间
现在,我觉得真是受益菲浅,感觉以前的开发过程真是&(&$@$^@#^^

请相信UML,让它帮助你改进自己的设计方法和开发过程(我参考了CMM1.1和RUP)。

这对一个企业,对个人都是一件非常有价值的事

如果,多一些企业和程序员能真正用好UML和好的软件过程,那么中国赶上国外软件业就不是一句空话。

回复
ArchangelQin 2002-05-17
允许出现一些反面论调,然后大家讨论得出正确结果,这样才是辩证唯物主义。万万不可人云亦云,权威并不一定是真理!
回复
kaikaihe 2002-05-16
工具是为人服务的,人永远属于第一位!
回复
hury 2002-05-16
其实作为一个技术人员,没有必要去为这些文人的论断费心伤神,掌握使用工具的技巧是人类的第一进步,工具有优有劣,关键是我们如何将他用好,我们不崇尚一位的方法论,我们不求最好,但求更好。无论如何,UML是思想,不是纯粹的方法,也是从面向过程的设计到面向对象设计方法的最佳进化,谁能提出更佳的方法呢?未来也许有更好的,但我认为,至少目前它是真正值得推荐的......
回复
笑面佛_正版 2002-05-11
什么呀,怎么这么长,看不完呀.
回复
rolt 2002-05-11
目前网友评论

gigix 回复: 谁的硬伤?

--------------------------------------------------------------------------------
精彩!
02/05/10 15:16 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

joor 回复: 谁的硬伤?

--------------------------------------------------------------------------------
uml肯定是好东西,我从发现他时就直觉他是我们未来的方向,目前我学习uml已经2个多星期了,开始有了一些初步的了解。我的认识是:如果中国的程序员要摆脱一个是龙,三个是虫的这种局面,uml是最好的工具。
02/05/10 15:26 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

mouri think今天这是怎么了?

--------------------------------------------------------------------------------
好象肝火很盛的样子,争论这些东西有用吗?

你说的那篇文章是谁写的?
02/05/10 17:25 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

baipangpang UML是有许多问题,但本质上思路是合理的

--------------------------------------------------------------------------------
本人没有看过《程序员》这篇文章。不喜欢没有论据地乱打棍子。但Think也不需要过激反应。
不要照搬、独立思考、具体问题具体研究。
02/05/10 17:58 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

grantlee 回复: 谁的硬伤?

--------------------------------------------------------------------------------
think肝火太旺,任何事物都有人说他不好,不必在意,只要自己用好就行了。
不过本坛子的目的是弘扬UML,和别人争论也在所难免。
我最近一直在忙于运用UML,一方面与客户沟通,一方面指导程序员工作,感觉非常好,算是用实际行动来声援think吧。:)
02/05/10 19:31 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

colinluo 回复: 谁的硬伤?

--------------------------------------------------------------------------------
作者批评UML又何妨?我建议高展仿效大唐的CDMA向国际化组织申请新的标准,用作者多年的心血为国争光,总是批评别人太浪费时间,应集中精力把自己的成果推销给Microsoft,Oracle,IBM,SUN,Borland,HL7等等,如果没人支持你,都支持UML,对不起我还使我的UML,我用的好好的,你三言两语怎么能说服大家,实践里面出真知,我用起来没什么不好?众多标准UML人气最旺,厂家支持最好,作者的新标准未得到有效的认可前,暂不考虑使用。
02/05/10 19:46 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

gyljp 回复: 谁的硬伤?

--------------------------------------------------------------------------------
每个人都有自己的一套,不能一棍了打死,个人觉得UML很符合OO思想,用得好坏全靠自己的经验。
02/05/10 22:17 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

machengzhang 不要忘记历史

--------------------------------------------------------------------------------
UML本身就是经过了历史的选择而剩下来的,如果不在继承的基础上发展,盲目批评UML,只能是重复历史的愚蠢,而不会超越历史!Enstein提出了相对论,可没有抛弃牛顿的经典力学呀!
02/05/10 23:26 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

caidehui 关于这篇文章

--------------------------------------------------------------------------------
有关这篇文章的情况,我知之甚祥。作者曾经希望能够由我来提出有关Rose使用中间的问题以及和PlayCase的有关对比。我的原意是Rose对目前我国企业进行企业模型分析支持有限,不能平滑过渡,因此提出了基于人、事、物三个视图和三个层次来重新组织企业建模过程,并且提出Rose实现时代码生成支持也有限,但能够生成框架,尽管有所不足,也能有所作用。只是Rose这几年本身的变化很小,应该是Rational本身战略的缘故。
众所周知,PlayCase在企业建模上,利用IDEF3,有所长处,对结构化系统开发的作用更是明显,但是对于OO或者UML很少涉及,并且由于作者使用Rose的时间少,误以为Rose和UML是一体的这就是非常偏颇了。Think也不必大动肝火,下面是我回复作者的EMail原文:

关于Rose和Playcase的比较:
**:
这几日由于感冒,没有来得及写这篇文章,敬请谅解。我在建模过程中使用的Case工具有多种,但最多的还是Rose,原因有几个:
1.Rose使用Use Case组织,架构驱动比较符合软件开发实际。
2.Rose对模型的组织,通过Rational Unified Process进行说明,层次感比较好,比较容易组织开发队伍进行开发。
3.软件开发过程中,大家比较认可的原型驱动、迭代开发、增量开发等也作为RUP的一部分重点推介,符合软件系统分析和设计的观点。

主要问题是:
1.目前中国企业的业务流程不能满足信息化的需要,必须要对这些流程进行优化,Rose在这方面没有什么作为。这和中国的国情有关系。
2.Rose不能很好的进行代码生成,原因是Rose基于UML,UML模型元素可以进行裁减,不能强制的认为哪些图要用来生成代码,这些图可能不存在,或者不完整,这是为了灵活性导致的功能丧失。

我使用PlayCase的原因是:
1.建立组织结构模型,主要目的是分清楚企业各职能部门的职责。
2.对一些复杂的业务流程进行建模,使用IDEF的流程图,比使用Rose的活动图建模更好一些,更直观一些

但是Playcase存在很多不如人意的地方:
1.它比较乱,没有层次感,感觉只是将很多部分拼凑在一起。
2.它对开发的组织没有分工和过程的概念,不能作为一个完整的Case使用。
3.对UML的支持实在有限,SD多于OO。这样要关注一些最新的设计理论和思想的应用就比较难了,这些思想包括:设计模式、组件技术、分析模式、多层体系结构等等。我想这主要是和这个软件本身并不关注软件设计和实现造成的。分析部分太多,设计和实现太少。

因此我一直想让二者具有可比性,而不可得。不知将从何处下手了。

以上只是我在系统分析设计过程中的一些想法,请多多指教。


Cai


以上只是说明,请大家认真鉴别。
02/05/10 23:42 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

idlecrook 回复: 关于这篇文章

--------------------------------------------------------------------------------
《程序员》上的文章我还没有来得及看,所以不敢妄说,同时也提醒诸位不要把还没有弄清楚的东西拿去发表,以便闹出用声纳装置接收电磁波的笑话(来自新浪新闻)。我就单说rose和UML:
UML:
UML是一种标准的图形化建模语言,它是面向对象分析与设计的一种标准表示。UML不是一种可是化的程序设计语言,而是一种可视化的建模语言;UML不是工具或者知识库的规格说明,而是一种建模语言规格说明,是一种表示的标准;UML不是过程,也不是方法,但允许任何一种过程和方法使用它。虽然UML只是一种标准而不是一种方法,但是它却对支持他的方法(或者过程)提出了要求(这个要求来自于成功的经验):支持用例驱动(use-case driven)、以体系结构为中心(architecture-centric)以及递增(incremental)和迭代(iterative)地开发。
Rose:
由于rose跟rup同出一家,并且rose是rup指定的建模工具,所以可能会有人把rose和rup混为一谈:),"Rose使用Use Case组织,架构驱动比较符合软件开发实际"只是UML对支持他的方法的要求,rup满足了这个要求而已。个人认为就UML制图方面,rose对UML的支持已经相当不错了,他对特定软件过程的支持也值得大家研究一番,其中重要的是如何利用work bench插件发布自己的软件过程。至于利用rose声称代码框架来说,我认为他对双向工程的支持已经基本能满足我的要求了,虽然有时不是很稳定:)
02/05/11 09:48 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

Dr.OO 话语权太重要了,错误的东西说了1000遍,就有可能变成“伪真理”,如果听不到正确的声音。

--------------------------------------------------------------------------------
所以,要争取宣传阵地——媒体!

02/05/11 13:34 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

Dr.OO 看了原文的论点,完全是站不住脚的,作者行文非常武断而且情绪化,根本不是一种科学的态度,说得不客气一点,简直是“胡言乱语”!不经过科学的调查就轻下妄语,不知他们哪里来得胆量。《程序员》居然刊出这样的文章,令人遗憾而后怕!

--------------------------------------------------------------------------------
所以,支持think的反击,让正确的声音来得更猛烈些吧!
02/05/11 13:49 酷帖! 臭帖! 回复
酷帖评价: 臭帖评价:
返回页首

Dr.OO 最近,好象出现了一股“反UML”的暗流,不知背后是否另有原因,提醒大家警惕!

--------------------------------------------------------------------------------

回复
发动态
发帖子
研发管理
创建于2007-08-27

1176

社区成员

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