D
dbbdggdbbdgg3
Unregistered / Unconfirmed
GUEST, unregistred user!
谁的硬伤？
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
目前网友评论
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”的暗流，不知背后是否另有原因，提醒大家警惕！
--------------------------------------------------------------------------------
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
目前网友评论
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”的暗流，不知背后是否另有原因，提醒大家警惕！
--------------------------------------------------------------------------------