UML三大硬伤

UML三大硬伤

撰文/高展
程序员杂志2002年第5期

本文从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的深入剖析，取长补短而建立了全程建模方法，所以理所应当向相关的面向对象大师们表示敬意。
    本文在写作过程中得到了战复东先生的热情帮助，在此表示感谢。

=======================================================以下为很多的评论：

tata1 (2002-6-17 16:40:37)

感想：高展先生的文章已引起不小的风波，有人认同，有人迟疑，有人反对。我认为，我们每个人都应该感想高先生，是他与作为“软件开发标准技术”的UML唱了反调，他敢于挑起一场风波，而这场风波早应该发生了。软件开发是一个技术研究与应用实践紧密结合的过程，程序员必需具备科学的研究精神，辩证的思考问题而不是沉迷于某项新技术，新思想的玩弄，或迷信于某个理论的说法。如果伽利略不敢否认亚里士多得，如果爱因斯坦不敢否认牛顿，那么今天会是怎么样呢？我敢肯定，即使那些拥护UML的人对UML也不全是很精通的。为什么所谓标准就无澥可击了，聘什么认为老外做的东西就是好的？中国软件应该发起一场革命，铲除那些形而上学，教条主义的思想，建立统一的正确的认识。用哲学的发展，全面，辩证的思想来认识问题，认识软件工程。

tata1 (2002-6-12 16:10:18)

UML手册已经说明UML是一个建模符号体系，不适合完成全过程的设计应用。所以，高先生说UML“上不着天，下不着地，一盘散沙”有点偏激了。我认为，UML确实存在使用，普及困难的问题。UML加上RUP后，内容太多，还要学习面向对象技术，确实使软件开发难度很大。一个设计思想或设计工具的运用主要是为了缩短开发周期，提高代码的利用率，可维护性等方面。所以我非常同意高先生的全程建模思想，我最近也产生了一些类似的构想。我希望理想的设计工具如下：一：归纳各软件开发阶段的问题，和解决问题的方法和技巧，指导性地分析设计。二：有层次，有联系的表达各阶段，各模块，各对象等元素的构成。三：和代码保持同步。即设计到代码的正反向功能。 ... 我的Mail:kmbaojun@msn.com 欢迎讨论

zy422 (2002-6-11 10:15:19)

我是一个有个编程经验多年的人，我也用 ROSE 来设计个一些东西，但我感觉到 ROSE 在给程序员一个交代时做得很不够，应为程序员最关心的是这个函数要做什么事、怎么在这个函数里做，函数里到底要使用到设计的那些类和函数，这 ROSE 实在是做得不好，所以现在我们公司里的程序员一般都不看 ROSE 图，靠和设计人员直接交流来完成对设计要求的认识。我希望 ROSE 在以后的版本中能做一些好的，能和程序员交流的工具或表达视图。 UML 还有很长的一段路要走，我真正用好了的只有类设计，其他的我实在是用不好了。我个人的观点，实用的就是好的，管它是面向对象还是面向过程，关键是要大家都用，都能够用好,多能方便的使用。对于 UML 我认为它站得太高了，现在很多人都还不能用好。

gale (2002-6-7 14:38:57)

3boy说的不错，但离题了，希望不是枪手，更不要顾左右而言它让我们重新看一下问题,作者说的是：UML的三大硬伤抛开工具，考虑一下思路这个UML三大硬伤的认识是错误的，理由我在前面的贴子已经描述过了我希望大家能就这“三大硬伤”提出意见，而不要偏离主旨 1,再驳“上不着天” 有什么形式化的方法能对问题域进行信息无损的描述？？？理论上还没有，目前走在业界前面的，是国际标准的，就是UML了 XX建模方法我不熟悉，没有发言权，但....这个不是国际标准 2，再驳“下不着地” XX建模方法有类和对象级的表达语法吗？反正在这篇文章里没有看到哎，我也不行，做不出自己的建模方法来，我“五十步笑百步” 3，再驳“一盘散沙” 昨日在《程序员》上拜读了高先生的《XX建模方法》不用我说，各位明眼的人就能看的出哪种方法的形式化推导关系更严密了

3boy (2002-6-7 9:31:32)

我觉的以上的言论太过偏激了，火药味太过于浓厚了，软件分析的目的是为了让大家都弄明白一个目的，那就是 “你该做什么？你要做什么？或则你要其别人做什么？”，而所谓的Rational产品，以及高先生的Playcase包括其它的一些建模工具都充其量和word差不多，只不过使用方便一些而已，“人”的因数还是最重要的，这就是对系统分析设计人员的素质要求。我觉的我们不能“神话”建模工具，而忽略了人，即使我们没有好的“画图”工具只要有人在，我们甚至可以“手绘”全部工作流，以上的争论好像就在讨论“画图板”的优劣，而不是在探讨软件工程真正的要旨，我觉的应该讨论的是“如何让大家都明白，你要做什么，我能为你做什么，你有些什么可以为我而提供的，你是这样的吗？。。。。。” 软件工程是一个不确定标准的学科，不确定的原由是，每个人都有自己的主张，不管主张的好坏，至少要知道你在为谁分析，你的对象是如何的，如果你画的东西别人都不理解，或者他们要花费很大的代价去理解，我认为那就是失败的方法，那么我们就必须寻求其他的途径去让人理解。 “我的三大忠告” 1、“条条大路通罗马” 2、“能解决问题的方法才是好方法” 3、“好的画家，即使没有丰富的颜料，和优良的画笔，依旧可以做出优秀的传世之作”

3boy (2002-6-7 9:26:54)

我觉的以上的言论太过偏激了，火药味太过于浓厚了，软件分析的目的是为了让大家都弄明白一个目的，那就是 “你该做什么？你要做什么？或则你要其别人做什么？”，而所谓的Rational产品，以及高先生的Playcase包括其它的一些建模工具都充其量和word差不多，只不过使用方便一些而已，“人”的因数还是最重要的，这就是对系统分析设计人员的素质要求。我觉的我们不能“神话”建模工具，而忽略了人，即使我们没有好的“画图”工具只要有人在，我们甚至可以“手绘”全部工作流，以上的争论好像就在讨论“画图板”的优劣，而不是在探讨软件工程真正的要旨，我觉的应该讨论的是“如何让大家都明白，你要做什么，我能为你做什么，你有些什么可以为我而提供的，你是这样的吗？。。。。。” 软件工程是一个不确定标准的学科，不确定的原由是，每个人都有自己的主张，不管主张的好坏，至少要知道你在为谁分析，你的对象是如何的，如果你画的东西别人都不理解，或者他们要花费很大的代价去理解，我认为那就是失败的方法，那么我们就必须寻求其他的途径去让人理解。 “我的三大忠告” 1、“条条大路通罗马” 2、“能解决问题的方法才是好方法” 3、“好的画家，即使没有丰富的颜料，和优良的画笔，依旧可以做出优秀的传世之作”

gale (2002-6-3 11:07:14)

1，技术是不分国界的，你用手在白板上画UML图是无需支付任何费用给US的 2，不要动不动就把技术问题上升到政治和民族主义 3，“拿来主义”，英美都能虚心拿去中国的火药制造枪炮来打中国，你难道不能学美国的 UML来打败US的软件产业？？！！ 4，作为中科院的人物，讲话是要负很大责任的，因为你的错误讲影响千千万万的人如果你错了并且是个权威，你将造就“十年浩劫”！！

chinakid (2002-6-3 10:06:48)

我想不通！为什么高展先生一说UML不好，就有人跳出来大骂，为什么，为什么？难到美国人的东西就不能批评吗？难倒中国人的智慧就比美国人差吗？中国人，不要轻易低下你高贵的头！

gale (2002-6-1 0:38:51)

1，“上不着天” 错，UML中的 Business Use Case Model 和 Business Object Model就是干这个的。最少现在还没有比UML描述业务更通用，更清楚的 2，“下不着地” 又错，Rose可以生成代码，再加上 XDE与Visual Studio.NET的集成 3，“一盘散沙" 还是错，Business UC Model--》Business UC Realizations--》Business Object Model Business Worker --》; Actor --》 Use Case --》Use Case Realization --》Analysis Model --》 Design Model --》Imp model 都是有严密的推导关系的什么“专家”？？！！纯粹是误人子弟！！补充：好像牛顿先生说：“我之所以伟大是因为站在巨人的肩膀上” 软件开发领域里“巨人的肩膀”就是前人工作的结果和经验 US的软件比中国强原因之一是国人（我也是）都喜欢重新发明轮子 UML是一个标准，不是R$的产品，你要是真有水平应该提交UML2.0给OMG，而不是自己闭门造车弄个什么XX建模方法出来。建议高先生好好看看UML+RUP+UCM这整个的思想体系，真正研究上一年再发表点有趣的文字。

gale (2002-6-1 0:22:04)

1，“上不着天” 错，UML中的 Business Use Case Model 和 Business Object Model就是干这个的。最少现在还没有比UML描述业务更通用，更清楚的 2，“下不着地” 又错，Rose可以生成代码，再加上 XDE与Visual Studio.NET的集成 3，“一盘散沙" 还是错，Business UC Model-->Business UC Realizations-->Business Object Model Business Worker --> Actor --> Use Case -->Use Case Realization -->Analysis Model --> Design Model -->Imp model 都是有严密的推导关系的什么“专家”？？！！纯粹是误人子弟！！PlayCase版权费的驱动＋浅薄＋无耻

kjxia (2002-5-29 15:15:13)

我想csdn给我们提供的是一个技术论坛，作用是大家可以在这里进行交流和讨论，通过交流可以解决一些实际问题，或是达到开阔视野、增长知识的目的，有不同的观点自然可以提出，但目的是为了探讨，有些用户把对别人观点的不认同转化为了莫名的人身攻击，这是很令人痛心的。

ysmstoneman (2002-5-25 16:10:43)

呵呵,我懂得中国的软件为什么比不上国外的了。建议那些搞人身攻击的“同志”们，或持反对观点比较强烈的“专家”们都去看看《谁动了我的奶酪》这本书。记着，“我们都在害怕变化”。 UML强大，难道它就真的没有缺点了吗？是啊！如果我精通Delphi，我真希望其他的开发工具都她吗的消失。但它们消失了吗？没有，C#出来了，什么.net出来了，据说什么以色列的魔术师之类的东东也出来了，………………不知道以后还有什么东东…… 我知道原来我错了，是我没有适应那么快的变化，IT这行确实变得太快，永远都有新东西出现，那应该是好事，要不，这世界上的技术怎么会发展的那么快呢？长期以来，分析工具一直是我国的空白，高展先生好不容易弄出了PLAYCASE（也许不是他一个人的功劳，但怎么说中国也出了这么个东东了），就因为这篇文章，用得着把人家骂成那样吗？

hostoop (2002-5-22 17:45:10)

不管是UML还是其它的什么，它都只是个工具，是用得好还是用得差，靠的是用工具的人。每个工具在不同的领域有不同的作用，我不会用VB来写硬件驱动程序，也不会用汇编语言写财务软件。我现在在Linux环境下用C语言写邮件服务器程序，如果按照高先生的思路，我是不是该出来写写”VB的三大硬伤“、”Windows的X大硬伤“？

2001sky (2002-5-21 13:28:50)

真正成功的软件是不依靠什么UML和PLAYCASE的系统分析的作用就是把客户的意思传达到程序员那里系统分析就是一个调制解调的过程如果你行，用WORD就可以了如果你要蒙人，用什么都不行什么样的人可以做系统分析？没有做出过成功软件（客户满意，代码稳定）的人永远没资格做系统分析，博士也不行请不要攻击任何工具，他不是万能的，只是一个助手

asp_boy (2002-5-21 8:57:20)

不知道分析员是不是都是高高在上的，还是在CSDN中的特产。只要提出一个不能被多数人接受的观点，就会被骂得狗血淋头。争论是一定会有的。但如果指人，这与市井流氓有什么区别？有人说“PLAYCASE那玩意纯熟垃圾”，想必他能设计一个比PLAYCASE更好的玩意，如果设计不出，也应该指出PLAYCASE的不足。空口说白话，谁不会说啊。最后一点， PLAYCASE是免费的，却有人说“鄙人初次接触PlayCase, 就发现PlayCase有许多优点......高展先生，您的PlayCase卖了几套了？”。可见，很多人都是推崇自己正在使用的工具。存在偏见的人不会是好的分析员。

shhao (2002-5-20 15:50:44)

我认为主要问题是作者未理解（当然更谈不上掌握）面向对象的思想和方法。

zhaott (2002-5-20 13:15:12)

工具不是主要的，主要的是人，是规格

telescope (2002-5-20 13:06:05)

一个老农拿鞭子敲敲拖拉机骂道，这东西没他妈我的驴好使，不懂人话，就算费点劲把它开起来，还不得把我的地压硬喽？驴一拉就走，这东西他妈不要说让我拉，就是驴也拉不动，然后还得花油钱，这是拖拉机的硬伤啊。

telescope (2002-5-20 13:04:30)

一个老农拿鞭子敲敲拖拉机骂道，这东西没他妈我的驴好使，不懂人话，就算费点劲把它开起来，还不得把我的地压硬喽？驴一拉就走，这东西他妈不要说让我拉，就是驴也拉不动，然后还得花油钱，这是拖拉机的硬伤啊。

blacktigers (2002-5-20 12:07:57)

推荐一篇文章：转载自企业工程论坛 http://www.ee-forum.org/ 标题：复杂系统的层级原理与模型驱动软件体系结构　作者：余彤鹰 2002-5-17 -------------------------------------------------------------------------------- 写在前面　　最近看到模型驱动在国内渐渐被更多的人注意，前几天又看到一些关于UML优劣和应用方面的争论。作为繁忙工作中的一种休息，从过往的研究笔记中整理一点东西放在这里，与大家交流。层级理论是构建复杂软件体系的基本原则　　诺贝尔奖获得者赫伯特 A. 西蒙曾论述到：“要构造一门关于复杂系统的比较正规的理论，有一条路就是求助于层级理论……我们可以期望，在一个复杂性必然是从简单性进化而来的世界中，复杂系统是层级结构的”。对于软件这样复杂的人造事务，发现层级和运用层级，是分析和构建的基本原则。软件的体系结构是层级的　　粗略地观察一下软件表述方式（语言）的发展：从穿孔纸带（机器的语言）开始，首先是汇编语言，然后是高级语言，再往后有面向对象语言和所谓第四代语言（FGL）出现……应当留意：每一代的语言并不是在“取代”前一代语言，而是用上一代语言来“写”下一代语言。在这个自然的进化过程中，西蒙所论述的复杂体系的层级特征清晰地出现了。　　进一步看，在由简单到复杂的进化道路上，软件的体系结构、软件开发的体系结构、软件开发工具的体系结构等等，都呈现出层级的特征。“好”的软件体系具有更加清晰的层级。一维语言之后是模型　　这里不想展开讨论这个问题，只是提出一些思考的结果。与自然语言类似，现有的“程序设计语言”是单维的，它的基本语法是以前后顺序为基础的。当系统的复杂程度提高时，用这样的语言精确描述复杂系统变得越发困难，更遑论有效地修改维护；可视化开发平台、代码管理工具（甚至某种意义上共享组件也可包括在内）等的出现对此是一种补充，但仍然不是最终的解决方法。软件描述体系进化到这里，面临着一次突变，将有新的物种出现，这个新物种可能就是模型。笔者认为，模型与程序语言主要的区别不在于图形化，也不在于抽象的程度，而在于表达方式突破了“单一顺序”的限制，最简单的例子就是二维表。模型可以更容易和直接地表达复杂的结构。模型和语言都是对系统的描述　　传统的编程语言和模型都是一种表述的体系，前者适合表述顺序过程，后者适合表述复杂结构。模型的必要性可以通过下面这个例子看出来：　　为了精确地复现，你可以用语言精确地叙述一个立方体，甚至10个立方体组合的形状，但你不会试图用语言描述一栋房子，适当的方式是用工程图纸。　　建立企业应用系统的情形可以从以上例子得到启发，企业系统要表述的，主要是复杂的结构，过程占的比重很小，因此，模型就变得更加重要乃至必要了。 OMG组织的MDA战略　　OMG最新的战略，是建立模型驱动体系架构（Model Driven Architecture, MDA），它的意义不是三言两语可以说清楚的，但从软件进化的角度来说，可能带有一种必然性，从上面的讨论，至少可以引申出两个理由：更有效地描述复杂系统的需要；系统复杂化带来的层级区分的需要。关于模型的几个分析要素　　笔者认为，以下特征对软件体系中模型的运用是十分重要，或者有特殊意义的：模型的时效性（time-effectiveness of model）：关于这一点最重要的区分在于，是“运行期模型”（Run-Time Model），还是开发期模型？这个区别，有点类似于解释的语言和编译的语言间的区别，但其意义却非同一般，笔者认为，“运行期模型”，揭示了模型驱动的本质。模型的可进化性（evolutionableness of model）：是否可以在系统的应用过程中，持续地适应应用环境与需求的变化，不断地由应用者或自适应地对模型进行改进？这是对模型“性能”的一种度量。模型的层级性（hierarchy of model）：正如语言有多个层次一样，没有理由认为模型只有一个层次，当系统足够复杂时，模型的层次划分将会是必要的。 UML和企业模型　　运用上面的要素分析一下，可以发现：　　UML是“紧贴”高级软件语言（例如C++）的模型体系，其时效是在软件生命周期的开发期间，而不是运行期间，其描述的层级是在软件的组件、对象一级，典型要素是软件中的对象，软件上一个操作的动作等。　　企业模型（比如ARIS, CIM-OSA, GERAM），典型的要素是组织，产品，过程等，它们是从企业的业务对象着眼的。二者在层级上有差距，而且企业模型追求的最终结果，是从“开发期模型”到达“运行期模型”，并且，笔者认为它最终应当是一种可进化的模型，这与UML的设计目标并不符合。　　它们两者间并不相互排斥，而应当考虑它们的“层接”。按照笔者的理解，OMG的MDA即使全面实现，也仍然不能做为或替代企业模型，但有可能成为企业模型的基础，这不是模型好坏或能力的问题，而是层级定位的问题。写在后面　　面向对象（Object Oriented, OO）作为软件体系结构方面的一种演进而出现，也曾经被一些人误解为对过程化语言（或面向过程的体系结构）的取代。笔者认为，尽管OO反应了一种世界观，是一种思维的方式，但并不代表一切；且从层级和进化的观点上，也不应当将它看作是对既有东西的一种简单的取代。模型或模型驱动同样如此，它可能是继面向对象之后，软件体系结构的又一个重大的进化，但不是用来取代面向对象或结构化设计。笔者在1998年撰写《迈向21世纪的企业信息技术应用》一文时，对于模型的地位和作用并没有今天这样的认识，现在我坚信，对于企业信息系统这样复杂的系统，要想做到有效、可控制地规划与构建乃至具有“柔性”、可在运行期间不断地调整，“模型”是必须的，而且，表达与构建复杂企业系统时所需的模型，可能是多层次的，所谓“通用企业平台上的专用执行系统”，就应当是一个由运行期模型驱动的系统。 --------------------------------------------------------------------------------

chinakid (2002-5-20 9:41:02)

偶尔路过看到这些评论，我很气愤。一帮美国的走狗！ UML，CMM都是人家美国人定下的标准，可笑的是软件公司象哈巴狗一样，跟在美国人后面摇尾巴。高展的playcase我没有用过，但我知道一点：中国人从来不输给别人！！！！！政府能扶助制造自己的CPU，自己的操作系统，自己的Office软件，也可以再扶助一个建模软件！这样我们就不用再仰视别人的鼻息！！！美国人的一套Rose多少钱？赚去了中国人多少血汗钱？而高展的playcase是免费下载的！！！为国家安全和产业利益，政府都应该对自主开发的软件进行扶持！起来，挑战UML霸权！

bigbat (2002-5-19 21:25:25)

"UML 没有排斥任何特殊的软件开发方法或过程；它只不过标准化了标记法的格式。"Granville Miller 语不是UML的问题。是开发者对面向对象的方法掌握的问题。高先生的方法是可能是一种好方法。但你应弄清楚你只是其中的一种。不要弄不清楚问题的实质就大贬一通。我觉得你说的三个发面都不对！ 1“上不着天”这种隔阂使建模结果无法与用户沟通确认所谓的需求，埋下了软件危机的祸根； USE CASE 图是一种很好的用来表达用户需求的工具。何以“上不着天”？ 2“下不着地”这种隔阂使千辛万苦得到的建模结果无法指挥程序员编码，最后得到的软件与用户期望的结果很远，返工、误工、烦恼无穷； CLASS 图是程序编写的图纸。看着它就可以来写代码。coder 们不需要了解设计的全部就可以施工。何以“下不着地”？ 3“一盘散沙”这种隔阂让建模图形之间的关系凌乱不堪，建模过程千辛万苦，建模结果很难自圆其说。目前在 UML 规范中有九种图。重不同的视角反映需求。你的设计“一盘散沙”。UML有何罪之有？高先生你认真对待你的“惊世”高论。您是一位学者！！！！！！！

elkel (2002-5-19 19:31:36)

真好笑，作者根本不懂UML，拿着Rose胡画，还对UML妄加评论。恶心... 本人忍受胃痉挛的痛苦，读完此文。力图修正作者使用UML的错误，提醒初学者不要象他一样胡画。（其实我也是初学者:)）对于Playcase，我没用过，不敢妄加评论，以免犯与作者一样的错误。但我可以确定我今生今世都不会用它。西门吹雪忽然道：“你学剑?” 叶孤城道：“我就是剑。” 西门吹雪道：“你知不知道剑的精义何在?” 叶孤城道：“你说。” 西门吹雪道：“在于诚。叶孤城道：“诚?” 西门吹雪道：“唯有诚心正义，才能到达剑术的颠峰，不诚的人，根本不足论剑。” 好，现在开始切入正题 1. 图3，作者应该画的是用例图吧。首先，用例图不能用来描述企业的组织结构。其次，作者用包来表示企业和部门是胡画，包在C++和java中分别映射为namespace和package。另外，作者用用例表示职责，算沾了一点边，但是这仍然是错误的，用例应该代表业务过程中角色的行为。作者所提的“不能直观地将职责展开为步骤”，应该用协作图表示。以作者的观点看来，建模是以企业组织结构为中心，而UML的观点是以业务为中心。以企业组织结构为中心，就要根据企业组织结构建立业务流，以业务为中心，企业组织结构要适应业务流程。哪个合理，很明显。（扯的太远了） 2. 图5，作者的目的是描述业务流程吗？那么请用协作图吧，虽然顺序图和协作图可以互相转换，但它们是有区别的，顺序图是针对开发人员的，协作图才是针对领域专家的。 3. 图6，作者画了泳道吧？胡画！！角色的职责应该在这里表现，每一个泳道应属于一个角色，泳道内的活动就是角色的职责。这是活动图吗？起始和结束点在哪呢？作者提出的UML三大硬伤，更本不能成立，作者根本不懂UML。

grantguo (2002-5-19 14:59:52)

还是那句话：没有银弹。。。。软件开发过程中没有银弹啊。

kendy_yin (2002-5-19 11:24:16)

其实你未必要去评论uml的好坏，就象linux的爱好者去说windows的坏话一样。如果你的产品真的好地话，时间可以证明一切的。觉得还是多花点心事集他人之长，补己之短吧。希望能见到你更好的产品。其实我都不知道作者是写什么的，从上面评论看，你是不是playcase的作者呀？

maxsuy (2002-5-18 19:17:38)

作者的人品确实存在问题。 PLAYCASE我用过，我承认国内的公司能弄出这么一个东西确实不容易，可是你也犯不着这么咒骂UML吧。 PLAYCASE那玩意纯熟垃圾。做出设计来到最后呢，还是没有用。放厕所里都嫌PLAYCASE臭。

pattern (2002-5-18 19:07:48)

作为一个又搞分析，又编码的软件工程师（存在于大多数有中国特色的软件公司）。有一条经验应该铭记在心：不要指望可以完全掌握用户的需求，大多情况下，业务领域专家也无法给你一个细化到原子级的需求。所以，才有object-oriented 软件工程的出现，才有增量开发方法，才有敏捷建模，这些都是告诉我们要顺应人的思维习惯，渐进开发，逐步挖掘需求，层次建模。软件工程与建筑工程有很多共通点，但他们有一个根本的不同就是：软件最终是可以被修改的，但你不会为一个不很合理的自动扶梯设计而修改造好的大楼，只能将就着用。所以建筑工程的需求可以被认为是确定的，而软件则是相反。

whack (2002-5-17 23:53:21)

呵呵，弄了半天才是一个软件的作者在说自己的软件比别人的好，怪不得口气和论述都是说得那么具有商业的味道。那我们也不妨来看看文中的几个技术的例子： 1。面向对象开发中和用户交流的关键描述工具是use case图。所以一个工具在这个阶段对用户最重要的就是构造use case描述（必要地时候也需要对一些重要的类或者包，以及相关的一些交互细节做某种程度的描述），通常component的构造细节在和用户交流过程中通常用到得很少。那么use case图作者会怎么描述呢？从文章中的对一个需求的建模结果看，也是类似的一系列图形和符号描述方式，但是不同的是在作者的表达方式和uml有所不同，更重要的是作者列举自己的建模图例和uml的图例的时候，设计的程度是不一样的，作者的建模图例其实是uml中的“静态图（类，包等）+ 一些usecase + 一些时序图（或者顺序图）”，也就是说作者的图形里面其实是夹杂了uml中的好几种图形（当然是把uml的描述方式有所简化和变化），但是在列举uml的设计图形的时候，却缺少了类的动态成分的表达（也就是方法及其顺序），但是在uml中有很多的图可以更进一步细化类或者包的设计（序列图，交互图，conponent图等）。这反映了作者对于面向对象系统描述的理解不同，uml之所以把几种图形分别描述，一是当需求比较复杂的时候，几种图加在一起的方式可能会变得无法描述，因为一张图形可能变得已经画不下来了。二是uml的方式认为系统具有一系列的特性，不同的特性需要有专门的方式来分别描述。图形多看不过来，但是混合在一起，如果描述同样的细节程度，恐怕还是很长。 2。对于微观设计，那就要看是系统分析阶段还是系统开发了。系统分析的时候做很多细节，有必要吗？本来系统开发就是有很多细节要到系统实现阶段来进行的。而且同样的，对于任何一个小模块，同样地画出component 图，序列图，交互图（只不过粒度不同），想不出来这时候为什么不可以编码？所谓的伪代码不就是一种这些图形的文字描述方式吗？在描述留成的时候，其本质上是同构的（只不过伪代码是结构化的流程图方式来描述类或者方法的关系）。 3。实在弄不懂作者遗漏用户需求的意思，遗漏了用户功能是系统分析没做完的问题，和怎么描述实在联系不上。作者在某个流程上加了个注解，这是解决方法啊？ 4。作者认为uml中间的好几种图形和某些元素无关，或者不能转化为逻辑语句。这就是对uml的语法的理解问题了。这些图形用系统工具现在都可以直接生成c++或者java代码，那么语法转化还需要什么。 5。uml的描述方法里面还存在着某些复杂性或者戎余，包括rose工具对于某些图形的构造方法也存在着需要改进的部分，这些不用多讨论了，只要是软件或者标准，都是在不断进行版本修订中。看了一下原文我怎么有点儿怀疑作者到底用uml做了多少项目，如果是为了宣传产品，没有必要做那些并不特别的例子，有些例子就只有一个自己的分析结果，就来了个结论。要知道很多在编码过程中好像很“好看”的东西，构造成一个产品后，就成了一堆不能维护的零件了。大家都用自己“喜欢”的，结果却往往是不能用的。

andy2ray (2002-5-17 21:44:20)

UML三位大师开宗明义，UML是一种语言，而不是方法，因此他本身不提供软件开发的过程指导。如果你不清楚或想获得在软件开发上的过程指导，可以参考RUP。这点不知高先生是否注意到？

111222 (2002-5-17 15:41:31)

写的很好，UML本来就是垃圾！

enlightenment (2002-5-17 15:22:06)

有句话是对的：尽信XX则不如无XX！

wuhan_wanhui (2002-5-17 14:14:50)

UML”三大硬伤”之我见 2002年第5期高展先生的文章《UML“三大硬伤“》以管理软件为实例，阐述了UML的三大硬伤，叙述的十分精彩。软件开发过程中的一些问题都被高先生提出，使我受益匪浅。但是高先生的许多观点，我不敢苟同。 UML是一种建模语言，语言是来供人们来交流，也就是供不同领域的人来交流的一个标准，就好像世界语。因此UML不是一种方法，UML建模和软件开发过程是两个不同的概念。UML适用于很多重软件开发过程。因此高先生有把用UML建模的软件开发过程和UML混淆的嫌疑，把软件开发过程中出现的硬伤归于UML，实属误解。 “上不着天”论。文中说，“建模结果无法于用户沟通确认所谓的需求”，“用户专家无法理解UML所描述的业务流程”。实际上业务流程是很细致的，以前我们用系统流程图直接处理这些业务流程，用户专家能得到很好的沟通。而现在用UML来描述业务流程，是不是有点赶时髦的嫌疑？软件开发过程中的问题并不是UML建模都能解决的，可以这么说用UML来描述业务流程曲解了建模的本义。三位大师的著作《UML参考手册》中说道，“模型从某一个建模观点出发，抓住事物最重要的方面而简化或忽略其他方面”，“ U M L是一个建模型语言，不是对开发过程的细节进行描述的工具”。可见建模是要抓关键和重要的东西，高展先生文中说到，“UML难以从宏观把控业务流程的完整与准确”，并举了UML不能描述到原子级工作步骤，这与建模的思想是相违背的，建模需要的只是到关键的一定层次（如文中所述的职责级），而不是详细的细枝末节。可以说这正是UML的精华之处，只关注重要和关键而不关心细节。详细的细节问题属于软件开发过程中的问题。 “下不着地”论。建模只是建立了一个模型，至于具体的详细设计、编码当然需要程序员去理解和思想。试想，模型和详细设计之间不存在这个隔阂的话，从事详细设计的软件蓝领都不要下岗了？UML存在的意义在于作为一种通用的建模语言，提供了一种建模者之间交流的标准，这当然也适用于上游的分析员和下游程序员之间的交流。UML其实也向下着地，着于这种相互之间的交流上。从模型转换到程序代码属于case工具的范畴，并不能说是UML的硬伤。再说现在Rational Rose对于模型到代码的转换工作已经取得令人惊喜的效果。

dearmite (2002-5-17 11:31:19)

看了这么多，想写点什么，其实我这两种工具都没用过，ROSE只是听说，不过，没下过鸡蛋，总还见过，别人用的时候，唉，我总是很羡慕！为什么？不是UML多么高、多么好，也不是他那东西真的能转换多少价值，因为他开的钱比我多！我们学这些、那些建模做什么，不是做事业，我们是为了钱！从文章的受益度讲，从文章的深度讲，我想这一点，高先生一定是最高分！但是问题是为什么IBM的OS/2没有比过MICROSOFT的Windows呢，因为市场！如果是我，boss让我又做建模，又做程序，那我一定不用UML，用高先生的东西没错！因为一切为了实用嘛，但是问题是，建模的人不写代码，写代码的人不建模，建模的人把关系搞好就能弄到钱，你的程序多好，你的公司通过cmm,但是你卖的程序真的用了CMM了么，不是！，都是为了多挣一点钱罢了，所以我只能以心灵上赞助高先生，如果我要学，我还是要学UML，因为这就是钱！全程建模大家一看就懂，那还了得，客户还能买单？他不懂就对了，这就是UML的最最高明之处！

SouthPole (2002-5-17 11:10:11)

我想很多读者(包括我自己