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的深入剖析，取长补短而建立了全程建模方法，所以理所应当向相关的面向对象大师们表示敬意。

　　本文在写作过程中得到了战复东先生的热情帮助，在此表示感谢。

原文转自：http://www.ltesting.net