UML三大硬伤

《程序员》高展专栏——UML三大“硬伤”(2002年第5期)

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

UML三大“硬伤”

编者：此文在《程序员》发表后，引发了UML支持者的激烈讨论

  讨论文章见：UML 谁的硬伤 http://www.youkuaiyun.com/develop/Article/13/13680.shtm

  这种热烈的技术争论其实越多越好，但很重要的一点讨论者需要"独立思考并勇敢丢出论点。"

 

撰文/高展

   本文从UML建模连贯性方面存在的问题，以管理软件开发为例，针对与UML模型衔接的上游、下游、模型内部关系三个方面，分析了采用UML建模造成的三大隔阂，希望与众多建模爱好者共同探讨。
   在国内的公开报道中，几乎众口一致地充斥着对统一建模语言UML（Unified Modeling Language）的褒奖，即便有公开抱怨也只是怪自己无法理解三位UML创始人的深不可测，怪自己的水平不够，没有料到UML本身存在着种种问题。本文作者只在北京大学计算机系的同行那里发现了他们撰文对UML的有效性提出了质疑。与公开报道相左，业界私下流行观点形象地说明了UML存在问题为软件开发设置的障碍，那就是“上不着天、下不着地、一盘散沙”：
  （1）“上不着天”这种隔阂使建模结果无法与用户沟通确认所谓的需求，埋下了软件危机的祸根；
  （2）“下不着地”这种隔阂使千辛万苦得到的建模结果无法指挥程序员编码，最后得到的软件与用户期望的结果很远，返工、误工、烦恼无穷；
  （3）“一盘散沙”这种隔阂让建模图形之间的关系凌乱不堪，建模过程千辛万苦，建模结果很难自圆其说。
   这三大隔阂造成的建模硬伤使UML辜负了人们的殷切期望，“高不成、低不就”说明了UML建模在软件生命周期中步履蹒跚，“一盘散沙”说明了UML在建模内容中并未实现Unified的原旨，图 1是UML存在问题的可视化表达。

图 1 采用UML描述的建模结果“分崩离析”

   诚然，掌握UML很容易谋到一份很好的系统分析员工作，但用它却很难做好系统分析员的分内工作，使用UML肯定可以100%蒙住用户，因为用户对满篇的建模图表只有招架之功，绝无理解反驳之力，使用UML也几乎可以100%蒙住软件公司老板，因为老板不是系统分析员，不知道使用UML进行建模的千辛万苦，系统分析员无法向老板反映UML存在的问题，因为这样很容易招致水平不高的责难。
一、UML上不着天——与用户/领域专家无法沟通获得真正的需求
   所谓“上不着天”是指使用UML建模后很难与处于软件开发上游的企业用户沟通，因为UML的表达方式与上游用户的行业知识相差甚远，用户一看见满篇的软件工程术语与符号就发怵，根本无法理解使用UML所描述的业务流程，也难以真正理解UML所陈述的需求，与业务专家交流无工而返，导致软件大厦一开始就建立在沙子上，需求不清不楚，没完没了的胡子工程就此落下病根，这种情况造成了软件开中的第一个隔阂，是UML的第一大硬伤。

   对企业用户来讲，他们关心的是如何在其组织结构、业务流程、业务信息的描述基础上，定位企业的宏观管理水平的需求和微观管理操作的需求。

1 UML难以完整全面地描述企业的分工结构
   图 2是采用全程建模方法组成结构树描述的企业分工组成，它以直观、彻底、一目了然的方式将一个企业按层次地展现为部门、岗位、职责、步骤、直至原子步骤，如“核对数量、核对规格、签字、填写入库日期”等。

图 2 采用全程建模方法描述的分工组成结构可以细化到原子级工作步骤

   图 3是采用UML的Use Case 图来描述组织结构，它只能描述到岗位职责，对岗位职责中的工作步骤无法描述。对业务的描述粗枝大叶，结果需求也是粗枝大叶，但用户往往不知道需要特别重视这一点，更不知道这种粗枝大叶会给项目带来灾难。这是纠缠不清的胡子工程问题点之一。

图 3 采用UML描述的分工组成结构至多只能描述到职责级

2 UML难以从宏观把控业务流程的完整与准确
   图 4是用全程建模方法顺序图描述的业务协作流程——“采购”，它将业务事件序列与业务活动有机地集成在一个图形中，用户可以直观地判断软件开发人员描述的业务流程是否正确、完整。

图 4 采用全程建模方法的顺序图描述业务协作流程

    图 5与图 6分别用UML顺序图和活动图描述的业务协作流程——“采购”，问题其一是用户需要左一眼、右一眼、上一眼、下一眼地对照两张图，费时费力，检查两种图时在所难免地会出现遗漏、不一致；问题其二是UML顺序图缺少条件分支的表达方法，表达内容不完整；问题其三是UML顺序图和活动图从形式上到内容上不存在等价关系。
    使用UML描述业务流程很难让人放心，因为描述业务流程时产生的遗漏、不一致、不完整，同样会给项目带来灾难。这是纠缠不清的胡子工程问题点之二。

3 UML无法从微观把控业务信息的操作过程
    图 7从微观上用全程建模方法PAD图描述了职责细化流程——库管员如何“入库”，它不仅描述了岗位职责展开的具体逻辑步骤，同时也描述了如何对业务信息进行操作，如对“入库单”的 “实际入库数量、入库日期”等栏目进行填写操作，对“入库单”的 “商品规格、采购数量”等栏目及“采购计划”的等“商品规格、计划采购数量”等栏目进行读取操作。

图 7 采用全程建模方法的PAD图描述的职责细化流程

    UML根本无法从微观上描述业务信息的操作过程，只能等到编程时再由有经验、责任心强的程序员去了解，这无疑于边盖楼边考虑在哪里开窗户，最后各种问题盘根错节，摁倒葫芦起了瓢。软件公司练就了不少救火高手，但不容否认的是充满了救火队员项目常常意味着灭顶之灾。这是纠缠不清的胡子工程问题点之三。

4 UML无法彻底全面描述用户的需求
    图 8是采用全程建模方法组成结构树进行功能定义，它可以细致到原子工作步骤级，比如“签字入库”仍然需要手工进行。

图 8 采用全程建模方法组成结构树进行功能定义

    采用UML无法对这种功能需求直观地定位，结果是开发人员好心好意地实现了电子签名，而客户却毫不领情，应为中国用户不相信计算机的签名，去掉这个功能也是一件麻烦事。
    另外常常发生的情况是开发软件遗漏了大量用户需要的功能，如用户需要计算机自动核对“采购计划”中的“计划采购数量”与“入库单”中的“计划采购数量”，如果需求定位没有细致到这种程度，程序员如果没有经验或责任心不强，自然会忘记这些，那么在测试阶段或者系统上线运行后用户肯定会发现要求修改，改来改去的麻烦又会特别多，反反复复修改的工作量极大地加大了软件公司的开发成本。这是纠缠不清的胡子工程问题点之三。

5 UML是造成信息不对称的“功臣” 
    可以说UML为用户（甲方）与开发方（乙方）的信息不对称提供了“有力的手段”，双方都互占“便宜”，因为这种信息不对称不但表现在有关信息产品和信息技术的知识上，还表现在乙方对甲方的业务理解上。由于乙方对甲方的业务术语理解不一定全面和准确，有可能在乙方看来含义非常简单的一个业务功能在甲方的经典著作或国家标准中含义非常丰富，需要做大量的工作。这样在使用UML的情况下，乙方按照自己的理解与甲方签了协议，但真正实施时却必须按甲方的国家标准去实施，这种扯皮的事在项目实施过程中大量存在。在信息项目的对策模型中，很难说乙方就一定能在合同中处于优势。
    由于信息化热潮的影响，许多公司纷纷进入IT项目建设市场，这些公司中难免有不少是属于鱼目混珠一类的，他们可以在报价中拚命地压低价格赢得标书，但在实际建设中却以各种手段欺骗用户，使用户蒙受巨大损失。还有一些很有名气的院校和公司承接IT项目建设业务之后，由于各种业务量太大，对其中一些中小项目投入精力不够，雇请一些新手作项目，囫囵吞枣，出了问题要么说用户当时没有说清楚，要么说用户水平太低不会用。
    即使乙方很勤奋，将方案做得很先进、很完美，充分考虑各模块的设置，也重视信息安全等问题，在使用UML的情况下，因为UML存在的种种问题，仍有可能因为乙方对甲方业务信息的理解能力不够，而使得乙方的方案和产品偏离甲方的真实需求。

二、UML下不着地——无法提供直接到位的素材指导程序员编程
    所谓“下不着地”是指费尽心力地使用UML建模后，很难让处于软件开发下游的程序员直接接受去编程，因为UML的表达方式不直接支持详细设计，程序员还得费尽周折地琢磨如何把建模结果转换成程序代码，这种情况造成了软件开中的第二个隔阂，是UML的第二大硬伤。
    与现代编译器对接的是结构化程序设计，如伪代码、PAD（问题分析图），前者为80%的美国公司使用，后者为80%的日本公司使用。伪代码的优点是从语法结构上与通常的高级语言非常接近，PAD由于可视化的特点十分便于人的理解，在图 9中，全程建模方法建立了这两种详细设计的联系，可以轻松地将PAD转换成伪代码。

图 9 采用全程建模方法PAD图描述的模块级流程与伪代码

    另外，UML没有对系统级、模块级接口的考虑，这在大型复杂系统开发重视不可想象的，图 10采用全程建模方法中数据汇总图自动描述的系统之间的接口。

图 10 采用全程建模方法中数据汇总图描述的系统之间的接口

三、UML一盘散沙——没有在细微之处建立建模图形之间的联系
    UML建模图形之间的内部联系十分松散，这种隔阂造成了UML的第三大硬伤，由于篇幅的关系，这种硬伤造成的潜在危害不再讨论，本文只是将“散沙”“罗列”如下：
1 状态转移图中，事件与外部Actor、Class、Package等无关；
2无法从语法上建立状态转移图与顺序图的联系；
3 无法从语法上活动图应与顺序图在流程描述关系；
4 协作图和顺序图中与Message相伴的参数与类图无关。

    虽然UML有这样那样的问题，不过UML也是从版本0.9发展到现在的1.4版，我们期待UML的升级，但在将要发布的2.0版中却没有“改过”的迹象。
    本文对UML攻击颇多，实际上全程建模方法从UML及其前身OMT（Object Modeling Technique）获益匪浅，作者也是经过对OMT、OOSE、UML以及OOA/OOD的深入剖析，取长补短而建立了全程建模方法，所以理所应当向相关的面向对象大师们表示敬意。
    本文在写作过程中得到了战复东先生的热情帮助，在此表示感谢。
————————————————
版权声明：本文为优快云博主「孟迎霞」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/amone/article/details/1877

 

这是Liu Junsong朋友给优快云的来信，我转贴在此

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

最近,在<<程序员>>杂志上发表了高展先生的一篇文章"UML的三大硬伤",认为它有"上不着天,下不着地,一盘散沙"的三大缺点,顿时一石激起千层浪,在网上有人激烈反驳"究竟是谁的硬伤?",详细的讨论信息在www.youkuaiyun.com网站上有具体的描述.
我看了双方的观点,觉得这个问题其实没有那么简单.
       UML有没有用呢?有.有没有缺点呢,也有.UML毕竟只是人创造出来的一种特殊的语言而已,又怎么会是完美的呢,它有一些缺点不是很正常的吗?那么高展先生自己写文章来批评它,难道不也是很正常的一件事情吗?无论他的具体观点对也好错也好,都是属于一种学术上的正常讨论,又有什么关系呢?
       我对高展先生的观点基本上是赞成的,但也不完全赞同.
UML在美国确实用的非常广泛,而用到中国确实处处碰壁,高展先生所描述的情况,虽然我没有亲眼所见,可是我认为这种情况确实是客观存在的.也就是说,在目前的情况下,完全采用UML来进行系统分析和描述,往往会产生"上不着天,下不着地,一盘散沙"的情况,最后把项目搞的一团糟.这种令人意外的情况的出现,不是偶然的,而是必然的.

《UML三大硬伤》的16条硬伤
原创gigix 最后发布于2002-05-23 17:39:00 阅读数 2445  收藏
展开
除了Think在“谁的硬伤”一文中列举之外，Dr. OO又列举出了“三大硬伤”一文的16条错误。我代他转贴到优快云。

 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

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

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

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

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

 

 

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

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

 

 

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

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

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

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

所以，以上完全是瞎说。这一点对程序员的误导最大。

 

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

这一点又是大错特错！ 

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

接口也是OO的核心思想。

 

5） “UML建模图形之间的内部联系十分松散”？

原文： 
“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是高度统一，有非常严格的结构、定义和描述的。

 

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

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

 

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

错！ 

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

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

 

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

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

 

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

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

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

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

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

 

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

前半句简直胡扯！ 

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

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

 

 

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

此处更是荒谬！ 

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

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

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

这段话，看出文章的思路是多么混乱！

 

 

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

毫不严谨! 

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

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

含糊其词，说了等于白说，有糊弄嫌疑。

 

 

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

毫不掩饰地乘机推销！ 

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

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

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

 

 

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

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

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

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

 

 

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

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

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

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

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

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

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

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

 

 

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

他们可以在报价中拚命地压低价格赢得标书，但在实际建设中却以各种手段欺骗用户，使用户蒙受巨大损失。还有一些很有名气的院校和公司承接IT项目建设业务之后，由于各种业务量太大，对其中一些中小项目投入精力不够，雇请一些新手作项目，囫囵吞枣，出了问题要么说用户当时没有说清楚，要么说用户水平太低不会用。” 

离题太远！ 

一会儿说竞标的事情，一会儿说项目管理的问题。这些现象是存在，但是跟UML的"硬伤”有什么必然联系？ 

难道是在暗示，有些“很有名气的院校和公司”在用UML欺骗客户？ 
即使用了全程建模方法，也是欺骗呀。 
或者，用了全程建模，新手就可以大胆地上了？ 

牵强附会，实在看不懂。
————————————————
版权声明：本文为优快云博主「gigix」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/gigix/article/details/2344