UML建模过程中需要注意的几个问题-为什么要使用uml建模

在学习UML的过程中经常会遇到UML建模误区问题，这里和大家讨论一下，无论你遵从的是重量级的方法,比如EnterpriseUnifiedProcess(EUP)，还是轻量级的开发过程，如ExtremeProgramming(XP)，UML建模在软件开发中都是不可或缺的。

UML建模的误区

通过理解和避开UML建模的误区，你能够是得你自己、你的项目组和你的组织更加有效地进行软件开发。在揭示这些普遍存在误区的过程中，我已经表述了AgileModeling(AM)的许多原则。AgileModeling以前叫做ExtremeModeling(XM)。我希望我所给于你的是精神上的食粮。
--------------------------------------------------------------------------------
无论你遵从的是重量级的方法,比如EnterpriseUnifiedProcess(EUP)，还是轻量级的开发过程，如ExtremeProgramming(XP)，UML建模在软件开发中都是不可或缺的。但不幸的是其中充斥着各种谬误与迷思。这来自于各个方面，有从理论家错误的研究、数十年来信息技术领域内的文化沉积、软件工具开发商天花乱坠半的市场宣传以及象ObjectManagementGroup(OMG)和IEEE这类组织的标准。这个月，我要揭示UML建模中的误区，指出其相应的事实真相。

误区一：UML建模就等于是写文档

这很可能是其中***破坏力的一条，因为开发人员可以此为借口而完全放弃UML建模。许多优秀的软件开发人员会说他们不想把时间浪费在这些“无用的“文档上。他们沉溺于编码之中，制造着一些脆弱而劣质的系统。另外，甚至于许多尽责的开发人员现在也认为UML建模是一件讨厌的事，而不愿去学习相应的UML建模技术。

事实分析：“模型”与“文档”这二者在概念上是风马牛不相及的—你可以拥有一个不是文档的模型和不是模型的文档。一幅设计图就是一个模型，而不论是被画在餐巾纸的背面，或写在一块白板上，或在ClassResponsibilityCollaboration(CRC)卡片中，还是根据记录在报纸和便签纸上的流程图而生成的一个粗略的用户界面原型。虽然这些都不能说是文档，但他们却都是有价值的模型。

UML建模很象是作计划：作计划的价值在于计划编制的过程中，而非计划本身；价值体现在UML建模的活动中，而非模型本身。实际上，模型不是你系统中的一部分正式的文档，而且在完成它们的使命后可以被丢掉。你会发现值得保留的只有很少的模型，而且它一定是非常***。

误区二：从开始阶段你可以考虑到所有的一切

这种说法流行于二十世纪七十年代到八十年代早期，现今的许多经理都是在那个时候学习的软件开发。对这一点的迷信会导致在前期投入可观的时间去对所有的一切UML建模以期把所有一切都弄正确，试图在编码开始前就“冻结”所有的需求（见误区四），以致于患上“分析期麻痹症”–要等到模型非常***之后才敢向前进。基于这个观点，项目组开发了大量的文档，而不是他们真正想要得到的—开发满足需要的软件。

事实分析：怎么才能走出这个误区呢？首先，你必须认识到你不能考虑到所有的细枝末节。第二，认识到编码员可能会对UML建模者的工作不以为然（这是可能的，事实上UML建模者所作的工作在实际价值中只占很少的部分），他们或许会说模型没有反应出真实的情况。第三，认识到不管你的最初所作的规格说明书有多好，但注定代码会很快地与之失去同步，即便是你自己UML建模自己编码。一个基本的道理就是代码永远只会和代码保持一致。第四，认识到迭代法（小规模地UML建模，编一些代码，做一些测试，可能还会做一个小的工作版本）是软件开发的准则。它是现代重量级的软件开发过程（如EUP），以及轻量级（如XP)的基本原理。

误区三：UML建模意味着需要一个重量级的软件开发过程

走入这个误区（经常与误区一有联系）的项目组常常是连UML建模都彻底地放弃了，应为这样的软件开发过程对他们来说太复杂太沉重了。这不亚于一场天灾。

事实分析：你可以用一种敏捷的方式取而代之。关于用简单的工具进行简单地UML建模的详细内容可参看AgileModeling(AM)。而且，你可以丢弃你的模型当使命完之后，同样也可以很基本的方式进行UML建模（比如，从办公桌起来，来到白板前就开始构略草图）。只要你愿意，你就可以轻松地UML建模。

误区四：必须“冻结”需求

这个要求常常来自高级经理，他们确切地想知道他们从这个项目组能得到什么东西。这样的好处就是在开发周期的早期确定下需求，就可以确切地知道所要的是一个什么样的东西；缺点就是他们可能没有得到实际上所需要的（不全或错误的需求，译者）。

事实分析：变化总会发生的。由于优先级的变化和逐渐对系统有了更进一步的理解，都会引起需求的变化。与冻结需求相反，估计项目成功的风险，尽量去接受变化而且相应地采取行动，就象XP所建议的一样。

误区五：设计是不可更改的

如同误区四，要求每一个开发人员必须严格遵从“设计“，导致开发人员为了符合“设计“而作了错误的事情或以错误的方式作正确的事情。或者是简单地忽略了设计，否定了所有设计可能带来的好处。冻结了设计，你就不能从在项目进程中所学到知识进一步获益。另外一个很大的趋势就是开发出大量的文档而不是实际的软件，使用面向文档的CASE工具而不是能给项目带来实际价值的面向应用的工具。

事实分析：事实上，设计会经常根据开发人员和数据库管理员的反馈进行修改，因为他们是最接近实际应用的人，通常他们对技术环境的理解要好于UML建模者。我们必须的面对这样一个事实：人无完人，他们所作的工作也不可能尽善尽美。难道您真的想将一个并不完善的设计固定下来而不再去修改其中的错误吗？另外，如果需求并没有被冻结，其实就意味着你不能冻结你的设计，因为任何需求的修改势必影响设计。对之，正确的态度是：只要你的代码还在改动，涉及就没完。

【编辑推荐】