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的第一大硬伤。

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

   图 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) 

我想很多读者(包括我自己)对这篇文章非常不满，主要是因为： 1 作者对UML及其产品缺乏足够了解和实际使用经验，所指的所谓“硬伤”，很多并不是UML的问题，而是对基于UML产品的错误理解。例如：“采用UML的Use Case 图来描述组织结构，它只能描述到岗位职责，对岗位职责中的工作步骤无法描述” UML本身主要是用于REQUIREMENT和HIGH-LEVEL DESIGN，如你希望描述工作步骤，使用UP中USE CASE TEMPLATE即可 2 作者对UML的许多评价偏激，“上不着天、下不着地、一盘散沙“，近于全盘否定，就是当年批判GOTO时恐怕也没到这种地步 

twinsant124 (2002-5-17 10:28:23) 

1、文章的论点：关于UML，我可没有啥敢维护的，我是UML的初学者^_^，犯不着一上来就维护这么一个只不过是工具的东西；关于什么全程建模，咋更不敢放什么厥词了，偶可没有高老师对自己都不熟悉的东西大加批判，点人家死穴的勇气和魄力。 2、作者写技术论文的作风：作为国内很有名的软件过程专家，请注意自己的言行可能造成初学者的迷茫和彷徨，三思而行，文章之道也。 


waterusage (2002-5-17 9:25:11) 

很多人不是在驳斥高展的论点，而是在批评他的PLAYCASE，批评他的为人了。 本来还是一个技术上的争论，现在就成了闹剧。 该收场了吧？吵完以后，谁也得不到好处。 但是，肯定也有人旁观了这场争论后，再使用UML时，多留了一个心眼。 

rayking (2002-5-17 8:58:14) 

从高先生以前写的文章看，所用的手段都是比较传统的。UML其实比较年轻，正是为了弥补数据流图（所谓的“地”）和业务流程图（所谓的“天”）等的不足而产生的。UML当然有缺点，这些缺点在几乎所有UML书籍里都有提及。希望高先生自己先用一下UML，相信会喜欢上她的。 

softdance (2002-5-16 23:08:54) 

高先生批评UML本着学术自由的原则没错，高先生的PlayCase我用过在也还算不错，而且我也相信大部分的同志也绝对不是攻击PlayCase这种工具本身，那高先生错在何处啊，何以招致如此多人群起而攻之。在这我只想说一句话：你可以批评大象皮糙肉厚，身体笨重，行走缓慢不如你的骡子外观漂亮，身轻体健，奔跑如飞，我保证没人说你什么，但是如果你批评大象不如你的骡子鼻子长牙俏,我同样可以保证保险公司都不敢保你。点穴要点死穴才能要人命，希望高先生下一次能准一点。 

softdance (2002-5-16 22:56:59) 

高先生批评UML本着学术自由的原则没错，高先生的PlayCase我用过在也还算不错，而且我也相信大部分的同志也绝对不是攻击PlayCase这种工具本身，那高先生错在何处啊，何以招致如此多人群起而攻之。在这我只想说一句话：你可以批评大象皮糙肉厚，身体笨重，行走缓慢不如你的骡子外观漂亮，身轻体健，奔跑如飞，我保证没人说你什么，但是如果你批评大象不如你的骡子鼻子长牙俏,我同样可以保证保险公司都不敢保你。点穴要点死穴才能要人命，希望高先生下一次能准一点。 

washine (2002-5-16 20:39:35) 

什么是好的建模工具？我认为其本身有多精辟或有多深奥并不重要，重要的是是否简单易懂。 为什么要建模呢？就是要越来越生动，便于理解，说得难听点，最好让傻瓜也一看就懂。 建模是给谁看的呢？并不是给软件设计者和项目经理看的，它是连接开发人员和客户的桥梁。 成功的建模应该具备极强的沟通能力及连贯性，条理清晰且容易接受。在这一点上UML明显先天不足（说老实话有很多程序员都看不懂更别说客户了）。从某种意义上说UML过于专业，熟悉面向对象的软件设计师或许能体会它的精妙，但从一般的客户及普通程序员来讲，他们需要的是一个生动的模型，而这个模型或许并不是UML。 国人有能力有魄力推出有价值的东西，我们为何不站出来给予支持呢？哪怕它仅有一个优点，也胜过一味地跟随。全程建模有他的可取之处，肯定也有许多不足之处（比如不够面向对象），但一般人（包括不懂设计的程序员）却更容易看懂它。我们要讨论的不是要用谁，摒弃谁，而是哪种方法更适合项目开发，给出更佳的效率。对任何事物都不要一棍子打死，难道就不能让它们共存么？ 

wangqiyy (2002-5-16 17:17:45) 

各打50大板！ 1、人无完人，金无足赤。每一种软件工程方法都有其独到的特点和所要解决的问题，UML的方法着重业务模型的建立，而I2DEF的全程建模的思想确实不错，对于工具Rose和Playcase我都接触过。我认为UML主要在描述做什么，逐步逐步提升到怎么做，最后到内部的类，最后编程实现；而I2DEF的感觉就像是岗位责任书，每个角色各司其职，所有的责任和角色组成整个业务。如果单单使用某一表示方法，我还没有听说哪家公司成功过，例如Rational自己，它就有一系列产品（像什么Request之类的工具）支持，只有把这些都用上了，才有可能是解决软件工程问题的方法，而单独使用都是有缺陷的，Rose内部也是建议使用大量的文档嵌入来描述其细节和关系的。老实说，如果全部使用符合UML的工具来分析实现系统，我认为首先要解决的问题是成本（资金、时间），其次是思想的普及，只有深刻理解了UML的思想，才可能真正正确的是用它表示业务。 2、顺应潮流，如果和外界交流，用UML吧！英语比起我们的汉语，那算什么啊！原始的垃圾！但是老外都说，没办法，学呗！ 3、UML是发展的，它的存在是合理的。 4、与其在此争执孰是孰非，不如静下心，学习吧！ 

youyuan (2002-5-16 16:17:35) 

看到此君的文章不禁想起了冯小刚电影《大腕》中那个搜狗网的c*o,他说要想网站要想火就要雇一帮写手，谁火啐谁，谁火灭谁，它就像这种写手，哈哈哈，我看他是想造个轰动效果，借以让自己成名，无聊的很，我想uml的用况在诞生时就已经说得很清楚: Use Cases are a critical technique in developing an application. Within the UML Use Cases are used primarily to capture the high level user-functional requirements of a system. This long winded description is important because Use Cases cannot usefully be used to capture non-functional requirements. Nor can they usefully be used to capture "internal" functional requirements. Attempting either or both is a sure path to disaster for two reasons. Firstly because Use Cases are an informal and imprecise modelling technique. But then they were never intended to be anything else. Secondly because the other use that we make of Use Cases is to define the fundamental structure of our application. The Use Case is not only important as a unit of requirement definition but also as our unit of estimation and our unit of work. 

softdance (2002-5-16 12:20:58) 

C++三大死穴 看了高先生的三大硬伤犹如提壶灌顶，真是顿觉自己愚笨。我的PlayC++ 已经诞生五年有余了，但一直是皇上老婆没人要，让我沮丧不已。但与PlayC++相比，C++是伤痕累累啊，经我以及清华的一些同事对C++的深入研究发现它的三大死穴。 一. 运行效率无与轮比的差。C++虽然编译速度挺快，但是运行效率却是太差，据我反复测试在同样的操作环境中比PlayC++慢了3-5倍。 二. 语言表达不够简练，丰富。别的且不说，就说程序的开始,C++ 用的是Begin.... end 格式，而且变量的声明以及函数的格式都太死板一点不灵活，根本无法满足我们多变的编程风格。反观我的PlayC++用花括号：{}代表开始结束，变量可以随用随叫，多么简洁。 三. 不支持面向过程编程。尽管目前是面向对象的天下，但是还是有很多场合要用面向过程的方法进行开发，例如最近非常火爆的CASE工具PlayCase就是一款优秀的过程工具。但是C++这一点做的太差，彻底抛弃了他们，采用了纯面向对象的方式，据我深入研究，C++的任何类型都是类结构，这对于广大的面向过程爱好者是及不公平的。不过不用担心，现在PlayC++可以让你为所欲为，它支持面向对象同样也没有忘记面向过程，这样你就可以用面向对象的语言来开发面向过程的设计，你以前的方法都可以保留。 当然C++也不是一无是处，例如它的垃圾回收功能，数组的上下界自动检测。但这些功能的实现是要付出代价的。 本文对C++攻击颇多，实际上PlayC++从C++获益匪浅，鄙人也是经过对C++非常深入的剖析，取长补短而建立了PlayC++，能有今天的成就理所应当向相关的面向对象大师们表示敬意。 

wildhorseli (2002-5-16 9:40:03) 

首先声明，本人不会写程序，本人用过高先生的东东（只是一个工具）；本人以为，UML只是一种符号，表达一种思想，正如高先生的东东一样，只是为了大家方便，清晰；以OO为思想，目的是代码的复用，可读，效率，适应外界的变化（这是重点）；本人认为UML的表达确实不错，本人不会写代码，但从用例上来看，清晰的很，业务清晰的很，一切看起来很自然，最起码你能感觉到是面向对象；由此可见，UML不在UML，在OO的功底，但从另一方面UML完全适应OO并且很适应，PlayCase或其他，我觉得大家完全可以用word，当然高先生可以用wps（国产的），甚或用草纸一样做出大家都能理解的UML； 

zergcom (2002-5-15 18:22:49) 

什么样的人可以评论UML： 1。真正了解和熟悉UML的人，而不是仇视UML的人。 2。用UML真正做过应用的人，而不是纸上谈兵的人。 3。能提出更好方案的人，而不是吹毛求疵的人。 4。不是井底之蛙的人。 

hamzsy (2002-5-15 16:44:57) 

高先生的PLAYCASE早就开始用了，除非不得已，用户有要求，否则我是不会用UML的，可能是我没有很好的理解UML的缘故。高先生的观点我很容易接受，所以PLAYCASE也用的很顺畅。 UML确实很好，由于其是面向对象的，在分析时整体把握还可以，遇到一些细节时就有点力不从心了，而往往这些细节是项目成败的关键。——很少有软件整体把握出错的！高先生的话或许有些偏激，但您有没有具体的思考过是不是真象他说的那样“糟糕”。希望大家不要象许多老百姓那样给人“害怕新事物”的感觉。也难怪，国产软件在程序员中的地位确实比较低啊！但PLAYCASE绝对是国产中的精品，虽然她还没有长大！大家还是来多关心关心他吧，不要老是躺在别人的床上高枕无忧！ 

lwd2k (2002-5-15 13:20:56) 

原来作者是playcase的作者，在此表示敬意。我学习使用playcase，觉的简单易用，生成代码很好，所以一直有一个版本保存。但出于商业和拓展市场的需要，用户要求的文档应符合UML标准，其实Visio功能比Rose多，但由于介绍Rose的书多，所以就用了Rose. 对于分析工具来说，做为用户，分析员，程序员之间的交流工具，只要说清楚了问题，不必看是用了什么方法。但目前来说，本人非常相信UML，所以一直想弄好它. 

mach (2002-5-15 13:06:43) 

使用UML可以清楚的描述业务流程，但不是用序列图，而是活动图，对于高先生的全程建模我还不太理解，粗浅的认为大概就是标准的RUP过程加上其中作为选项的业务建模吧。至于用活动图描述业务流程，这是肯定可以的，而且很方便，用活动图可以非常清楚地定义工作流，不仅可以在业务层次上抽象，包括在其后的系统分析、设计过程中，可以继续细该活动图得到业务过程的具体实现方式。从高先生文章中的论述，和其对用例图、序列图的使用方法来看，可以断定，高先生对UML还不是太了解。至于Playcase，我只是下载过，不是很理解其中应用的方法论，因此没有资格对其进行评价。 

jnwen (2002-5-15 11:28:07) 

我觉得关键是语言还没有对信息流很好的支持,什么面向对象的建模方法都不好,面向过程的方法最自然. 

JohnYale (2002-5-15 10:40:32) 

平心而论，高先生的PlayCase是比较少见的优秀产品（至少在国内），肯定花费了高先生很大的心血，但不被市场认可，我们应该考虑这是什么原因？如果说国内公司不相信国内公司的产品尚可解释的话，可是世界上那么多大公司，为什么鲜有发现PlayCase的？PlayCase使用的IDEF(具体拼法已记不清了)，在国内只发现一本书予以介绍，与连篇累牍的介绍UML的书籍形成巨大反差，难道真的是整个IT业都错了？真理往往掌握在少数人手里？ 

HYhuyan (2002-5-15 9:30:13) 

众人皆醒我独醉 1.任何技术上的争论我们都应该支持； 2.任何带有利己目的的攻击我们都应该鄙视。 

fltwt (2002-5-15 9:13:07) 

只是觉得原作者还没有很好的理解UML。也没有真正的用过UML。从这篇文章中，看得出作者很推崇结构化，看不出面向对象。 UML的核心应该是建立在面向对象上的吧。用UML进行面向过程的系统设计开发，好象牛头不对马嘴。 

mis98zb (2002-5-15 8:28:54) 

不过RUP几大核心工作流之间的衔接、UML几大视图的演化，以及业务模型到实现模型的转化，确实很少有讲解的资料，这也使得现实中ROSE建模缺乏连贯性。 

JohnYale (2002-5-14 23:47:36) 

众人皆醉我独醒。高展先生为了推广 全程建模方法，几年来一直极力攻击UML, 其执着比麦克尼利有过之而无不及，在如今建模方面尚无完美方案的情况下，全程建模方法 无疑是当今世上绝无仅有的、至高至上的、无可匹敌的解决方案，是中国软件的代表，高展先生万岁万岁万万岁！！！ 2年（？）前，鄙人初次接触PlayCase, 就发现PlayCase有许多优点，但由于本人愚鲁，未能成功说服公司采用PlayCase（老板是蠢材？），致使公司现在一直使用Rose建模（边用边摸索），真是罪该万死。没有办法，市场决定一切。高展先生，您的PlayCase卖了几套了？ 

//www.csdn.net/develop/Article/13/13680.shtm CSDN是技术交流与传播的平台，我们鼓励技术的讨论与争论。 我们不会因为不同意别人的观点而删除任何文章，只会删除人身攻击和粗言秽语等有污视听的帖子。 

ripper (2002-5-14 21:27:48) 

使用UML描述业务流程很难让人放心，因为描述业务流程时产生的遗漏、不一致、不完整，同样会给项目带来灾难。这是纠缠不清的胡子工程问题点之二 看看这句话，再看看下面对比用的图，高展这老小子连顺序图是做什么的都没有搞明白就信口开河 

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