UML的三大“硬伤”

2008-04-09 04:02:51来源:互联网 阅读 ()

新老客户大回馈,云服务器低至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图描述的职责细化流程

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:UML用例建模的慨念和应用

下一篇:四种网络游戏外挂的设计方法