UML实际状况报告
　

---

最近有文章“驳UML三大“硬伤”论，觉得文章只是从技术角度来评价别人
的论点，并没有从客观实际来看问题。目前在中国的实际状况确实存在
着"UML上不着天，下不着地，一盘散沙"。产生这个现象有几个原因。

1 UML深奥难懂。 客观世界是复杂的，UML为了实现对复杂世界的精细描述，
用了太多的概念，术语，太多类型的diagram。用UML做出的设计上至用户，
下至程序员都不懂，所以UML上不着天，下不着地的现象当然就存在了。

2 UML容易使人入误区，最近我听说用Rational Rose做设计挺好的，于是我
下载了Rational Rose试用版。Rational Rose里有一个sample. 于是我就用
这个Rational写的Sample来考察这个UML工具。这个Sample说的是有一个POS
系统，现在要加一个电子商务的功能。怎样用ROSE来实现。首先笔者认为所
增加的这个功能是非常简单的，但是Rational却把这个简单的问题复杂化了。
用了很多复杂的图来实现这个电子商务功能的设计。一个好的设计工具应该
把复杂的问题清晰化。而Rational这个Sample却做得正相反。特别是做到与
VB编码连接的那部分练习的时候，步骤太多，太复杂了，实在受不了!!!
连Rational的Sample也会出现如此的现象，难怪UML容易使人入误区了。

3 UML现在还不能完全代替文字描述。

4 据微软的一个报告称在软件项目开发中用户界面的设计和编码占到总开发
时间的70%。笔者对这一点深有感触。在一般商业管理软件开发中笔者认为
数据建模和用户界面是最重要的，很少有复杂的业务逻辑需要用UML之类的
图才能表达清楚。往往是用户界面方面花了不少时间。而UML仅仅是用来画diagram的，在最重要的用户界面设计方面无所作为。我不知道为什么这种
技术被称为UML, 在我看来应该称为"UMD"(Unified Modeling Diagram)更为
合适。叫Language太抬举它了。"UMD"应该是作为系统设计的辅助工具才是
它的合适位置。

 回复: UML实际状况报告
　

---

静下心来，化点时间好好地学习以下UML。你也许会有不同的感受。顺便说以下，如果可能去问一问UML的使用专家。你会有不一样的认识。

1.
对于用户和程序员的理解问题，可以分开来说明。
用户基本上只要理解需求说明书，加上用例图。如果需要用户参与需求分析
过程，需要培训用户过于用例的基本知识！
程序员理解UML也要有个过程，这些东西应该是以后大学生的必修课。能够
看懂就可以了。
最高层次是能够使用UML自由表达思想。
2.花费时间
按照你的说法，花费时间少的就不重要，花费时间多的就是最重要。
建筑大楼花费最多时间的是添砖加瓦，设计占有的工作量（人年）和添砖加瓦
相比还是比较少的。但是你不能说，我们只要添砖加瓦，设计不重要，不需要
什么工具和图纸就可以搞出来了，设计师还要那么麻烦去画图纸干吗！
设计和施工虽然密切相关，但是两者技能大不一样的。
恕我直言，你做的项目基本上是简单的应用软件系统，恐怕没有多少技术难度，而且基本上是每个项目全部重新来。就是说不属于软件密集型的项目，即使项目金额很大，在计算机行家眼里也是小项目。

没有实际用过，别说这么多话好不好？四条没一条对的。连标题也有问题，你什么时候去搞的社会调查？竟然叫做”实际状况报告“.

 请你摆事实，讲道理。
　

---

你只会下判断，不会讲道理吗？我做了近20年IT，10多年的设计。做过数
百万的软件单子。还有无数的我认识的同行在软件开发企业中。难道没有
资格发布实际状况报告？据我所知因为使用UML而导致开发失败的软件企业
远远不止一家。请问贵公司有用UML设计出来的著名产品吗？说出来让大家
听听看.

 谢谢你的观点，不过我认为...（学术领域也应打假）
　

---

你提出的用户和程序员的理解问题应该分开来说明很好。但我还是认为用户
不大可能接受用UML设计出来的东西。UML从一开始就是陷阱。例如Use Case
Diagram. 照字面上理解应该是使用案例图，是用来说明每一个使用案例的。
其实这种图根本不是用来说明使用案例的，而是用来说明使用者的角色和
系统功能关系的。而真正的每个功能的使用案例图是Activity Diagram
(活动图). Activity Diagram是真正用来说明系统功能的处理流程的。
总之UML从一开始就易入误区。让客户接受还要费不少口舌呢。所以我们目
前的做法是一般的功能需求用文字描述，碰到复杂的流程用Visio画个业务
流程图。这样用户更能接受些。

UML让人费解这个问题本身反映了这个技术还不成熟。好的技术应该具备清晰
的概念。容易让各方人士快速接受。

关于花费时间问题，你的提法很好，我也同意花费时间多的不一定是最重要
的。但是UI设计，是在整个产品设计中最具成败的因素。用户不管你后台是
否用了你自以为了不起的技术，他们要看的只是你的用户界面，看你的用户
界面是否实现了他们需要的功能；看你的用户界面是否易于操作。我想说的
是用户界面是软件产品开发中最花时间，而且是最重要的。而UML恰恰在这
方面无所作为。

UML只能是作为软件设计的辅助工具，主要是用来画Diagram的。虽然有些UML
工具（例如Rose）可以把Diagram和程序，数据库建库脚本连接起来。但做得
远远不够。当前中国有些人鼓吹UML是万能的设计工具。看来在学术领域也应
该打假。

 如果你能把我的4个论点驳倒，我就服了你。
　

---

请看我的新作：学术领域也应打假。

"例如Use Case Diagram. 照字面上理解应该是使用案例图，是用来说明每一个使用案例的。"
这完全是望文生义，用这种东西来批UML，和“莫须有”有什么两样？

“UML让人费解这个问题本身反映了这个技术还不成熟。好的技术应该具备清晰
的概念。容易让各方人士快速接受。 ”
现在讲OO的书基本都采用UML代替以前形形色色的OO符号系统，UML的接收程度很广啊。不能因为你自己不容易接受，就一定说其它人也不容易接受啊。

UML的创造者从没有宣称过要用UML包打天下。你不能因为奔驰车不能飞就说它不是好车吧。而且说UI最重要也太过分了。用户最关心的永远是功能。而UML恰恰是为了更准确、有效地实现用户需要的功能。如果你是面对着只关心UI的用户做了20年IT，那我很有理由怀疑你这20年IT经验的价值。

UML不是万能的，也有缺点，当然也是可以批评的。但也得批对地方。而且要批UML至少也得懂UML吧？不懂，那只能是胡批了。

一般软件带的Sample都比较简单，包括很多书上的也是这样。因为Sample的目的是为了演示某些概念、功能等等。如果问题太复杂，会显得喧宾夺主。所以这些Sample往往会有“杀鸡用牛刀”的感觉。但估计也只有爱钻牛角尖或存心找茬的人才不理解这一点吧？

如果有人只看了Rose的sample就敢来批UML，这学术领域是该好好打一打假了。

你摆个事实出来嘛,经验那么丰富!态度决定一切,你对UML最初抱的是什么态度?

有时间能否交流一下功能需求描述文档的写法??

正确性可能只有1%。

呵呵，现在1-2百万的项目都不一定是大项目的，特别是对应用型的项目。而且这样的项目开发人员一般现在的配置不超过5-10人，如果要举例子，那应该同时说明项目的管理程度，人员配置。还有你觉得OO开发有没有什么比较好的方法？

 老兄，不要动不动就学术，敢问什么是学术？
　

---

之所以会出现你说的这些现象，主要的问题我觉得是你的理解，对工具的看法不对。
任何工具都有之擅长和不擅长的，你说的UI设计，当然用UML是不合适的，RUP建议使用UI的原型，然后根据客户的反馈重新设计。
再说Use Case使用，谁说Use Case是图表？很多经典的书都是配有详尽的文字描述。

查一句：微软的用户界面是谁做的？微软？

与从业多少年无关，也与有多少业内朋友无关。关键是要拿出有说服力的论据来。因为你写的“实际状况报告”（这种报告都是调查报告)，就不应该出现诸如“笔者认为”或“比如”之类的主观性造句。而应该是说--有多少企业在使用uml，使用情况怎样，有多少项目的失败原因被证明是与使用uml有关的，以及具体是uml的那些弊病导致了失败。同时还要说明有没有成功的，说明时也不能主观臆断说我没有听说过就说没有，而要说在我调查的这若干家企业中，没有一家使用成功。这样才有说服力。你的文章有些观点也有些道理，但却不能归罪于uml，宰牛才需宰牛刀。我本人是反对不管什么都用uml的，但也反对将uml说的一无是处,uml有它的适用范围。我个人认为，在大中型项目中，以及在学术交流中，适当使用uml会有非常好的效果。

 请你不要断章取意来评论, 你是UML专家还是UML Fans?
　

---

“例如Use Case Diagram. 照字面上理解应该是使用案例图，是用来说明每
一个使用案例的。” 这完全是望文生义，用这种东西来批UML，和“莫须有”
有什么两样？

任何人学东西都是从概念开始的，望文生义也是通常人的习惯。你总不能在
向你的客户推荐产品时说：“我们供应白色粉笔，其实我们的白色粉笔不是
用来在黑板上写字的那种笔，而是用来装粉笔的容器。您看您还要我们的
白色粉笔吗？”

UML的接收程度很广？恐怕只是在自以为高深的设计人员中间吧。当然我
没有全盘否定UML的意思。UML在表达复杂的业务流程方面还是挺有用的。
问题是现在UML实际作用被UML工具厂商无限夸大，在广大技术人员中产生
了误解。由于这些UML工具厂商的鼓吹，在中国造就了大量的不懂UML的
UML Fans，对说UML说不好的人群起而攻之。正是这些Fans对UML最狂热。

我说UI最重要，没说过我的客户只关心UI。你曲解我的意思了。
说到UI重要你就不高兴了，还说怀疑...。哈哈，气急败坏了吧。你当然
有“急”的道理，因为那是UML够不到的地方。

你说我不懂UML? 那我怎么知道UML能做什么，不能做什么？怎么知道
Use Case Diagram究竟是用来干什么的?

看来你是UML专家了，老说人家胡批。那请你还是基于摆事实，讲道理的
原则吧。

因为目前的项目以形象工程为主，主要是领导说了算，领导最能说上话的地方就是UI。

可以说，领导是最大最重要的风险承担者，其它人的要求可以忽略不计。只有满足了领导的要求，才能拿到钱，这样项目才能算成功（拿不到钱的项目不能算成功吧？）。

好象某大牛（记得就是搞VB那个互动式编程的）曾说过，对某些客户来说，软件产品就是界面。从这个角度来看，UI的成功是有决定意义的。

据消息称，中国电子政务的预算已过万亿，嘿嘿，大伙看着办吧。

“UML让人费解这个问题本身反映了这个技术还不成熟。好的技术应该具备清晰
的概念。容易让各方人士快速接受。”

概念是可以很清晰，各方人士不一定能快速接受。

另外，易学性和易用性还是有差别的。比如说photoshop不易学，学会了用起来效率可高了。Unix与Windows的差别也可以从这方面进行探讨。总之，易学的不一定易用，易用的不一定易学。
　

 实践与中国特色
　

---

UML在软件建模领域是一大贡献！
但在实施过程中确实存在着很多问题，我有看过高展和UMLChina的讨论，觉得各有其理。
1. UML深奥难懂。 关于这一点不知该如何评论。以我自己的经验，我学了UML很长时间，最少有半年多，但确实不敢说很熟练。也进行过UML的推广，但对于应用中问题有时也无能为力。UML在概念方面的强化确实使很多人有些望而生畏。UML的最大的语言特色就是它的图形化，图形化方面UML做的确实不错，类图，USE CASE图等都比较容易理解，但想精确的描述也并不是容易的一件事。 有很多人说，UML本身很庞杂，但就看使用者了。 但往往使用过程中会出现交流不畅的问题。这些问题可能是使用带来的，但UML不可逃脱责任。 UML必须结合一定的软件过程来使用吗？ 那么如果我使用XP，AM，怎么结合UML？UML的灵活使用是需要探讨的。
2. UML使人进入误区。 UML本身的很多概念和图形化建模过程如果清楚，那么应该不是很容易进入误区。那个Sample我没有接触，不敢发表评论，但我看过UMLchina的很多例子，觉得在UML表达设计方面还是很简明易懂的。我觉得我使用中最大的误区是：很多图在表示我们的设计时不是很到位，这是最大问题。需要协助很多方法去表述。有时觉得用UML图表示困难的时候，就会采用Visio或者白板（最好的设计工具！） 来替代。我不喜欢拘泥在一种工具，工具是有限的，思维是无限的。特别是我更不喜欢被一种工具带入某种误区！

3。 UML本来就没有想代替文字描述，试着看一下RUP的模板文档就知道UML的真正作用所在了。UML作为模型而存在，与文档相互依存。

4。界面设计确实是一个非常关键的点，在项目的实施过程中，UML很难准确的把我界面的迁移，这个确实是个问题。

 回复: 请你摆事实，讲道理。
　

---

同意。
这么多不同的声音，我觉得大家不要一概而论。：）

希望大家举出更多的使用中的例子，并加以评论，空谈理论是没有什么用的，UML好于不好不是一个人两个人能说出来的，但应用UML确实是可各抒己见。

 我喜欢vindey写的文章，Rose_Rose写得也太...(你是UML专家还是UML Fans?)
　

---

我喜欢vindey写的文章，有学术探讨的精神。其他有些人的文章我嗅到了
一股对UML盲目崇拜的狂热。我没有全盘否定UML的意思。UML在表达复杂
的业务流程方面还是挺有用的。但UML只是用来画Diagram的，作用有限。
问题是现在UML实际作用被UML工具厂商无限夸大，在广大技术人员中产生
了误解。由于这些UML工具厂商的鼓吹，在中国造就了大量的不懂UML的
UML Fans，对向UML说不好的人群起而攻之。看来这些Fans对UML还真有
股宗教狂热。

 思想才是关键
　

---

UML只是一种符号体系，在它背后的是什么？
是一种思想，一种世界观，一种文化思潮。
如果您没有或不理解或不赞同这种思想，世界观和思潮，那么，
您根本就没有进入合适的参照系来评价UML.

与其指责UML，不如指责面向对象；
因为，UML是至今为止表达面向对象的最佳形式体系。

与其指责面向对象，不如指责您自己的思想跟不上时代；
因为，面向对象是至今为止最自然、最科学、最流行的信息化描述方式。

与其指责，不如学习；
因为指责阻止您开阔视野，提高认识水平，学习让您进步，愉快。

 回复: 请你摆事实，讲道理。
　

---

老兄，我终于发现问题出在哪里了，
20年的IT经验！
老天啊，难怪，20年前是不是结构化盛行的时期！
老前辈，我对您非常景仰，如果需要转变观念的话，请找我。
我只有10年的IT经验，也受了结构化思想的益很深，
不过，我受面向对象的益更深些。

另外，如果您把视野扩大一点，不只是局限在国内的成功软件，您会发现什么？
也许您在用的大部分软件都是OO的，包括这个论坛。
您可以找我交流，真的，
不然，我劝您准备改行去做项目管理咨询，那个领域非常需要您这种人才。

 回复: UML实际状况报告
　

---

UML重设计，需要的是设计思想，没有好的设计就不会有好的产出。开发应该在设计的基础上，就如同先设计图纸再有施工、建设！

看了大家的很多论点
套用一句话，事物都是两面的，有好地，也有坏的
一定要有一个结论？好像没必要。大家扬长避短就行了
还有，花更多的时间在学习上，比做这些争论要好地多
个人感受，谈不上说教。如果觉得不中听，可以当作没看到。
希望这里能多一些实际的讨论，解决一些问题。

讲个简单的故事吧！
从前有两个人为一个简单的问题而打赌，争持不下，请某老者评理。老者却故意颠倒黑白。持正确意见者当然不乐意，老者对他说：你不过就是输了点钱嘛！让他错一辈子吧，以后别人告诉他正确意见他也永远不会接受了！

虽然这位老者有失忠厚，但是他是对的。

1、有些人天生是不撞南墙不回头的人，你告诉他错了，只会让他恼怒。搞不好还会引来人身攻击，什么半瓶醋啦之类的结论等等！“与不能言者言谓之失言”，我就屡屡失言。

2、既然有人能够只“下载了Rational Rose试用版”、“用这个Rational写的Sample来考察这个UML工具”就能够写报告，就能够知道UML的缺陷，那些去RATIOANL上了培训又用了一年多的人却还不知道，足见水平相差太远！哪里有资格批评。

我好心地忠告大家，再也不要随便批评他的报告了！
当然，也许这又是一次失言。

 Rational的UML工具是真金白银, 还是商业炒作?
　

---

在本栏讨论中终于有人跳出来为Rational说话了, Rational做为一家UML主
力厂商, 正在力推UML成为主力设计工具, 让UML介入软件设计的各个阶段,
并且试图把UML与编码连接起来, 实现UML Dragram与编程的无缝连接等.
但UML先天不足, 不足以担当起主力设计工具. 于是Rational就用一个
办法--吹嘘.

吹嘘的结果还真造就了不少Fans. Rational居然把UML图比做建筑图纸. 建筑
图纸能够描述建筑物的各个方面. 但是UML的Diagram最多只能描述软件的逻辑
关系. 并不能描述软件的各个方面. Rational为了能自圆其说, 还想出一整套
"办法"来实现, 还办什么培训. 叫嚷UML软件设计需要长期培训才能学会. 借
此大赚培训费. 让广大信徒长期套牢在UML里.

吹嘘的结果只能制造IT泡沫. 一旦神话破灭, 自会遭到唾弃. 你们可以看看
这个Rational公司在美国Nasdaq的表现吧! Rational公司在美国Nasdaq的代
码是RATL. 请到http://finance.yahoo.com或www.msn.com上查看. 其他软件
公司还真有点真金白银, 比如Oracle公司的Oracle数据库是一个公认的比较
好的数据库, 但Oracle也存在吹嘘产品功能的现象, 最终被客户识破. 看来
西方IT业普遍存在着吹嘘产品和技术的功能的现象.

我有多年用Visio画流程图的经验, 对UML也是了解的, 很清楚知道UML能做
什么,不能做什么. 惊闻有人到Rational参加"一年"的培训, 还掌握不到软
件设计的"真谛". 更不相信UML需要2年小成的神话.

总之UML只能做为辅助设计工具还是可以的, 成为主力设计工具还不行, 靠
吹嘘来造就信徒更要反对. 高展的论点是正确的， UML本来就是一个上不
着天、下不着地的东东。

 确实，很多著名软件都不是用UML的
　

---

例如，Windows, Linux等等
使用OO的著名软件业有不少：Solidworks，Office等等，但是不知道他们是否用UML

1 UML深奥难懂。--当然，否则怎麽说明复杂的事务
2 UML容易使人入误区：例子是演示使用方法的，我见过for wsock,for ole,for j2ee....各版本的hello world程序，是不是因为hello很简单，那些技术就都....
3 UML现在还不能完全代替文字描述:一个可被证明逻辑完备的语言永远不可能 完全代替自然语言描述
4 微软是对的，你也是对的，uml也是对的。一个以界面为主的应用，你就该把大部份时间用到界面上。

 Rational的UML工具是真金白银, 也有商业炒作
　

---

谈点自己的看法.以前用传统的软件工程,有些问题存在.(譬如开发文档是厚厚一摞,可是对于接手继续开发没有什么帮助)接触UML后感觉它能解决那些问题,所以就学到现在.如果以后发现UML在使用中存在的问题,可能继续找寻其他的解决途径.就好象高考,虽然有弊端种种,但至少到目前为止,还没有更好的解决办法.
Rational的培训确实贵,$300/天人
吹嘘,那里都有,它只是一种手段.关键是背后的利益在驱动

UI的设计问题你说的可能不是很正确。UI设计是很重要，但是UI不是系统设计的全部，而且它在设计中占有的比重和应用类型有关。UI设计并不是计算技人员的专长，这个设计在很多公司里面本来就是由专门的美工人员或者界面设计人员来完成的，所以才会出现MVC模式，让界面设计能独立于后台功能来进行。

至于说界面是不是一定要利用UML来进行设计，这个应该看你说是哪方面了，如果是界面逻辑，本质上仍然可以使用状态图或活动图表达，如果是美工和布局，显然不是建模工具所能描述的，界面设计人员应该采用他们认为正确的方法。所以这个只能是根据你的具体例子来说明。

对于文章中所讲到其它一些问题，实际上，其它人是不能明确说对或者不对的。（不过那些公司采用了UML设计，你在招聘广告上就可以略知一二了）因为不是针对具体的例子或者可以参照的对象，那你不觉得这种讨论只能是类似大专辩论赛吗。

不过还是可以先考虑这样的几个问题，首先有没有做过一个完整的OOA/OOD的设计，生成的文档是什么？然后，你的设计中业务需求文档和OOA/OOD文档相互之间是怎样对应的？最后就是你采用什么语言做coding。最后再对比某种OO设计方法中的表达元素，比如Booch，OMT，UML。

很多快速开发工具对界面的实现帮助很大，
如VB，Delphi, PB, C++ Builder, JBuilder,etc.
你说的开发方法在中国其实是最常见的，市场技术思维方面
的条件决定了大多数软件开发就是建立以数据库为中心的应用软件。

Martin Fowler说，很多人发现UI具有值得状态图刻画的行为。
用惯了PB/Delphi的程序员是不是觉得不可思议！
但是你想过如何设计手机的人机界面（MMI）吗?

UI的美观和方便性问题，确实是用户很关心的。
但是UI也是用户提出更改需求(CR)最多的地方，
所以UI的设计最好和系统其他部分分离，使得用户的
CR对整体系统的稳定性影响最小。专业的软件公司，
会有一些美工人员参与UI的设计，在JSP中UI和Control Logic
分离也是一种很好的实践。

当然任何东西都不可能是万能的！你也没有必要先假设UML是万能的，然后反驳之:>)
但是你说的所谓UC陷阱，我不敢苟同。本来UC Diagram和UC的说明还有需求说明书
是需求说明阶段的主要制品，没有让你靠UC Diagram独自打天下啦！
UML中的Activity Diagram的一个主要来源就是所谓的流程图！
算了，请你还是好好学习UML吧。

一些题外:很多小公司追求美工和编程能力的统一，不知道效果如何？
过分降低成本，快速挣钱，对内high personal turnover,对外部客户
不讲信用（公司很快消失，没有维护保障，造成客户很大损失）.其实这些
就是CMM1的症状。没有长远发展的积极性，可能是中国软件行业整体失败的
主要原因。这种环境下的个人和Boss，都盼着有免费的午餐,谈UML/RUP效果
又能如何？

用户那边有很多趣事，很多用户往往习惯于和程序员打交道，也许一边开始编程序
一边启发用户的需求，或者程序员全部作完了才发现用户根本不需要你实现的东西，而
用户需要的往往相差很大。
软件用户那边主要是传统产业的人员，有些40以上的实权人物往往不愿意学习很抵触computer。
这样的人，你还期望他们自己懂得需求分析系统分析的重要性吗？
如果你的客户主要是国有公司和政府机关，那你就不要把精力放在软件方面，当然如果不能
给客户代表旅游机会的话，也不用培训UC或者流程图了。
(上层是豆腐渣工程的关键，下层的系统使用者一般是图个电脑玩。)
　

 老兄，你怎么连UML范畴里的"Use Case Diagram"也不知道？
　

---

老兄：你怎么连UML范畴里的"Use Case Diagram"也不知道？
还反问我“谁说Use Case是图表？”, 请你把UML的基础知识再看一下。
就能知道UML里面是否有"Use Case Diagram"这种图。等看懂了再来批我
也不迟啊。

 呵呵，我也不是批你。。。
　

---

不要抠几个字眼。

那你就用你的“Diagram“来捕获需求吧。