谁的硬伤?
rolt 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