《UML三大硬伤》的16条硬伤

除了Think在“谁的硬伤”一文中列举之外，Dr. OO又列举出了“三大硬伤”一文的16条错误。我代他转贴到CSDN。

 <o:p></o:p>

 <o:p></o:p>

1） “图 3是采用UML的Use Case 图来描述组织结构，它只能描述到岗位职责，对岗位职责中的工作步骤无法描述。”<o:p></o:p>

活动图用来描述执行算法的工作流程中涉及的活动。活动状态代表了一个活动：一个工作流步骤或一个操作的执行。
活动图的用途是对人类组织的现实世界中的工作流程建模。
活动图也可以包含动作状态，它们是原子活动。
[UML参01]

实际上活动图很像大家熟悉的一种功能更强的流程图。

所以对于“岗位职责中的工作步骤”是完全可以描述的。
此处，留给作者作为练习。<o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

2）“UML根本无法从微观上描述业务信息的操作过程，只能等到编程时再由有经验、责任心强的程序员去了解，”<o:p></o:p>

在业务建模阶段，UML通过活动图、交互图可以很好地描述信息的操作过程，说明实体、Worker之间的数据、消息交换内容和顺序，怎么叫“根本无法”？<o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

3）“所谓“下不着地”是指费尽心力地使用UML建模后，很难让处于软件开发下游的程序员直接接受去编程，因为UML的表达方式不直接支持详细设计，程序员还得费尽周折地琢磨如何把建模结果转换成程序代码”<o:p></o:p>

什么叫不支持“详细设计”？
难道OOD围绕类的设计不是详细设计？感觉他不懂OO。

现在的UML Tools都支持框架代码，甚至可以根据模式生成（比如Rose, TogetherJ）；在实时UML领域，有的还支持从UML的状态机直接生成可执行代码。

作者再一次混淆了UML语言和UML工具的差别。

所以，以上完全是瞎说。这一点对程序员的误导最大。<o:p></o:p>

 <o:p></o:p>

4）“另外，UML没有对系统级、模块级接口的考虑，这在大型复杂系统开发重视不可想象的”<o:p></o:p>

这一点又是大错特错！

UML的核心思想就是Model driven architecture，而从System到Architecture到Subsystem到Component，强调的都是接口(interface)的设计

接口也是OO的核心思想。<o:p></o:p>

 <o:p></o:p>

5） “UML建模图形之间的内部联系十分松散”？<o:p></o:p>

原文：
“1 状态转移图中，事件与外部Actor、Class、Package等无关；
2无法从语法上建立状态转移图与顺序图的联系；
3 无法从语法上活动图应与顺序图在流程描述关系；
4 协作图和顺序图中与Message相伴的参数与类图无关。
”

错在何处：
1、难道事件不是来自外部类、Actor及其所在的包吗?
UML状态图中事件有几种类型：
信号事件、调用事件、改变事件、时间时间等。
其中信号和调用事件都是与对象相关的。

原句不知从何而来？似乎是使用某种工具的体会？

2、不知何意？什么叫“语法上”
是UML语法，还是实现代码的语法？想建立何种联系？

原句含义指向不清。

3、不知何意？什么叫“语法上”
是UML语法，还是实现代码的语法？想建立何种联系？

原句含义指向不清。


4、该现象只与具体UML工具的实现有关，比如Rose已经实现了，UML的定义是完整的，完全是软件的功能不同而已。

总结：

在已经出版大量UML规范文献和中文书籍的情况下，作者再一次把UML工具的某些现象说成了UML语言的问题，在全文中都不加任何区分，可见概念不清。

OO理论是一个有序、统一的整体，从这些非常局部细节的现象（基本上是实现的差异）根本得不出UML“建模图形之间的内部联系十分松散”、“一盘散沙”的结论，相反UML是高度统一，有非常严格的结构、定义和描述的。<o:p></o:p>

 <o:p></o:p>

6）疑点：图 4 采用全程建模方法的顺序图描述业务协作流程<o:p></o:p>

仔细看了一下，无非是把UML的顺序图和活动图画在一张图中，似乎更乱。<o:p></o:p>

 <o:p></o:p>

7) "UML顺序图缺少条件分支的表达方法，表达内容不完整"<o:p></o:p>

错！

分叉的画法见《UML参考手册》第334页图13-162“具有过程控制流的顺序图”

即使作者用的旧版软件不能画，也有替代的方法。
而且这本书是1年之前出的，当时很轰动，不会不知道吧。
不做调查就下结论，过于草率！<o:p></o:p>

 <o:p></o:p>

8） “使用UML描述业务流程很难让人放心，因为描述业务流程时产生的遗漏、不一致、不完整，同样会给项目带来灾难。这是纠缠不清的胡子工程问题点之二。”<o:p></o:p>

这明明是UML使用者的问题，又怪到UML身上，犯了概念不清的毛病。
UML业务流程的建模可以不遗漏、很一致、很完整，你自己学不好、用不好，这能怪谁呢？<o:p></o:p>

 <o:p></o:p>

9）“问题其三是UML顺序图和活动图从形式上到内容上不存在等价关系”<o:p></o:p>

作者概念不清，估计UML规范看得太粗心大意了。

形式上，顺序图和交互图等价；活动图是一种特殊形式的状态机（图），用于对计算流程和工作流程的建模[UML参01]。

作者硬要把顺序图和活动图拉上等价关系干什么？

但其实顺序图和活动图在语义上是存在联系的（不是等价）：活动图描述对象内部的计算步骤，类似于流程图；顺序图则描述对象之间的消息交换。所以，它们两者之间是互补的。<o:p></o:p>

 <o:p></o:p>

10） “UML根本无法从微观上描述业务信息的操作过程，只能等到编程时再由有经验、责任心强的程序员去了解，这无疑于边盖楼边考虑在哪里开窗户，最后各种问题盘根错节，摁倒葫芦起了瓢。”<o:p></o:p>

前半句简直胡扯！

在业务建模阶段，UML通过活动图、交互图、类图可以描述几乎任何工作流步骤的细节信息，至少不比你的PAD少。

后半句借题发挥，谈错误业务分析失败的体会，博得同情，借机怪到UML身上。<o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

11）“采用UML无法对这种功能需求直观地定位，结果是开发人员好心好意地实现了电子签名，而客户却毫不领情，应为中国用户不相信计算机的签名，去掉这个功能也是一件麻烦事”<o:p></o:p>

此处更是荒谬！

你怎么知道UML不能描述到“原子工作步骤级”？
UML怎么不能“对这种功能需求直观地定位”？

我真弄不明白，“签字入库”和“签字需要手工”在UML的活动图上不是很容易表示吗？

后面半句明明是需求管理的问题，却要牵强附会。
我用UML画了一个“手工签字入库”的工作状态（原子步骤），开发人员怎么会去实现电子签名？
这是管理问题，与UML何干？

这段话，看出文章的思路是多么混乱！<o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

12）[05/21] “与现代编译器对接的是结构化程序设计，如伪代码、PAD（问题分析图），前者为80%的美国公司使用，后者为80%的日本公司使用。”<o:p></o:p>

毫不严谨!

难道Java、C++编译器不是现代编译器，知不知道还有面向对象设计？
为什么不说“与现代化编译器对接的是OOD”，而这似乎更符合主流。

两个80%是从哪里来的，有何依据？
是美国、日本的哪些类型的公司，即什么当中的80%？

含糊其词，说了等于白说，有糊弄嫌疑。<o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

13）“伪代码的优点是从语法结构上与通常的高级语言非常接近，PAD由于可视化的特点十分便于人的理解，在图 9中，全程建模方法建立了这两种详细设计的联系，可以轻松地将PAD转换成伪代码。”<o:p></o:p>

毫不掩饰地乘机推销！

澄清一个概念，伪代码毕竟不是真正的源代码，不能执行。
你把PAD“轻松地”转换成伪代码，有什么了不起，不也就是框架吗? 而且还不是真正的代码。
人家UML和UML工具比你更高明得多！
UML用详细设计的图形直观、一致地指导程序员编程，谁还需要用伪代码？
UML可视化模型其实可以完全取代伪代码。

UML工具可以把UML类图、状态图直接转换各种高级语言，甚至可立即执行的程序，估计全程建模工具还达不到吧。

这段话根本论证不了UML的“下不着地”，无非是吹嘘自己，结果却恰恰证明了全程建模方法的“下不着地”！<o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

14) 疑点：全文没有一处提到IDEF，而不少高手看出全程建模是基于IDEF的，为什么不老实说出来？<o:p></o:p>

结尾：
“本文对UML攻击颇多，实际上全程建模方法从UML及其前身OMT（Object Modeling Technique）获益匪浅，作者也是经过对OMT、OOSE、UML以及OOA/OOD的深入剖析，取长补短而建立了全程建模方法，所以理所应当向相关的面向对象大师们表示敬意。”

在这里点了一堆OO名字，却只字未提全程建模建立的核心来源——IDEF。

我看，全程建模是不是独创、发明、创新，甚至是不是所谓的方法论，都值得研究。<o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

15）[05/21] “UML是造成信息不对称的‘功臣’”<o:p></o:p>

信息不对称和一种作为表达工具的业务描述语言有什么必然联系？

如果甲乙双方沟通不畅，对概念、问题的看法不同，即使用再好的建模方法、图形，也可能出现理解不一致，需求分析错误等情况，因为无论什么建模语言都不过是建模者思维的一种反映。

你能保证全程建模方法丝毫不遗漏、无二义地反映甲方的业务和需求吗？笑话，
这不过取决于建模者与客户的沟通罢了。

这又是一个比较迷惑人的概念混淆问题。

“可以说UML为用户（甲方）与开发方（乙方）的信息不对称提供了“有力的手段”，双方都互占“便宜”，因为这种信息不对称不但表现在有关信息产品和信息技术的知识上，还表现在乙方对甲方的业务理解上。由于乙方对甲方的业务术语理解不一定全面和准确，有可能在乙方看来含义非常简单的一个业务功能在甲方的经典著作或国家标准中含义非常丰富，需要做大量的工作。这样在使用UML的情况下，乙方按照自己的理解与甲方签了协议，但真正实施时却必须按甲方的国家标准去实施，这种扯皮的事在项目实施过程中大量存在。在信息项目的对策模型中，很难说乙方就一定能在合同中处于优势。
”

你怎么知道甲方一定熟悉你的全程建模方法？他们不了解，同样可能存在信息不对称。
如上所述，这段话逻辑混乱，而且看不出几句话之间有何必然的因果联系，即使作者误认为UML不能业务建模成立，也得不出这样的结论。
如果把其中的"UML"换成“全程建模方法”我看也同样成立。

我们可以说，全程建模方法也是造成信息不对称的“功臣”。<o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

16) “由于信息化热潮的影响，许多公司纷纷进入IT项目建设市场，这些公司中难免有不少是属于鱼目混珠一类的，...<o:p></o:p>