UML存在性说明

Published: 20 Sep 2018 Category: SE

在阅读《UML for Java Programmers》一书时,看到一段阐述软件模型必要性的文字,觉得不错,抄录如下——

UML 的误用和滥用已经给相关的软件项目造成了极大的危害。

为什么用模型?

为什么工程师要建造模型(models)?
为什么航天工程师要建造航天器的模型?
为什么桥梁工程师要建造桥的模型?提供这些模型的目的是什么?

这些工程师建造模型来查明他们的设计是否可以正常工作。航天工程师建造好了航天器的模型,然后把他们放入风洞中了解这些航天器是否可以飞行。桥梁工程师建造桥的模型来了解桥能否接立起来。建筑工程师建造建筑的模型了解客户是否喜欢这种建筑模样。通过建立模型来验证事物是否可工作。

模型意味着它们必须是可被检验的。为了检验它,如果一个模型没有一个可用的检验标准,它是相当糟糕的。如果你不能评估一个模型,这个模型是没有价值的。

为什么航天工程师不马上建造一个飞机然后去试飞呢?为什么桥梁工程师不立即建造一座桥然后看它是否可以接立起来呢?因为航天器和桥的造价比模型昂贵多了。当模型比我们实际建造的东西划算多了的时候,我们用模型来研究设计。

为什么给软件建模?

一个 UML 图可被检验吗?它比创建、检验这个软件更划算吗?对于这两个问题,这个答案是无法像航天工程师和桥梁工程师那样清楚地了解境况。没有一个检验一个 UML 图的 固定标准。我们能够观察它、评估它,然后应用原则和模式于它,但是最后的评估仍然是相当主观的。画 UML 图比编写软件花费更少,但不是重要的因素。当然,改变一个 UML 图比修改源代码容易多了,用UML是不是有意义呢?

如果使用UML没有什么意义的话,我就不会写这本书了。不过,以上举例说明UML的易用是误用了。当我们需要通过检验确定某些东西的时候,或是使用 UML 来检验比编码来检验更划算的时候,我们就使用 UML。

举一个例子,我有一个特定设计的主意,我需要通过我的团队中的开发人员来考虑它是不是一个好主意去检验,因此,我在白板上画出了一个 UML 图,然后询问队友们的反馈。

我们为什么应该在编码前构造一个全面的设计?

桥梁工程师、航天工程师和建筑工程师都画设计图,为什么呢?因为画一个房子的设计图一个人就可以了,而建造它需要五个或更多人。区区十来个航天工程师能画一个飞机的设计图,而需要上千人去建造它。绘制设计图不需挖掘地基、浇注混凝土和嵌上窗户。简而言之,预先计划一个建筑物远比没有计划的情况下试图建筑它更划算。丢弃一张有错误的设计图花不了多少钱,而拆卸一栋失败的建筑物却要花不少的钱。

另外,软件中的裁剪也不是那样彻底,比编写代码更划算的编制 UML 图的裁剪也不是特别地彻底。实际上,许多项目团队在 UML 图上花费了比编写代码本身更多的时间。弃用一个图比弃用代码是不是更划算,这也不一定。因此,在编写代码前去创建一个全面的 UML 设计作为一个有价值、有效的选项,也是不一定的。

有效地使用 UML

显然,无论是桥梁工程师、航天工程师还是建筑工程师都无法为软件开发打一个比喻。 我们无法愉快地使用 UML 那些用于设计图和模型的规则。因此到底我们什么时候、为什么应当用UML 呢?

人员之间传达

UML 在软件开发人员之间传达设计概念是非常方便的。在一小群开发人员中,许多事情可在一个白板上进行。如果你有一些主意需要传达给其他人员,用UML可能是非常好的。

UML用于表达集中的设计思想相当不错,举一个例子,在图Figure 2-1(一张类图)中的图描述得 非常清楚,我们知道 LogiServlet 实现了 Servlet 接口,并使用了 UserDatabase。很明显, LoginServlet 需要 HTTPRequest类和 HTTPResponse 类。很容易想像一群开发者围站在一块白板前为一张这样的图讨论的情景。实际上,这张图清楚地描述了代码的结构。

另一方面,在表达算法细节时 UML 不是特别理想。考察一下在 Listing-2-1(冒泡排序代码)中的这个简单的冒泡排序代码,表达这个简单的模块用 UML 不是令人非常满意。

UML 在创建大型软件结构的“路标图”(roadmaps)时是比较有用,这样的“路标图”给开发人员一个快速的手段,用来发现某一个类依赖于另外哪些类,并为整个系统的结构的提供了一个参考。

可是,任何一个团队成员应该可以在白板上画出这样一个图作为一个临时的布告。实际上,在五年前的开发的工作中,我从脑海里画出了有关一个系统的如上所示的图。这样的图记录了所有的开发人员必须记住的,可以用于有效地开发系统的相关知识。因此,大多数情况下,准备费力去创建和归档一大堆这们的文档基本没有什么意义,最好的方式,再说一次,就在白板上画图吧。

最后的文档

什么时候最适合创建一个设计文档呢?最好在团队所有的工作干完了,项目要结束了的时候。这样的文档真实地反映了一个团队工作结果的状况,它对接着即将开展工作的团队极有帮助。

不过,这里有一些缺陷。UML 图需要经过深思熟虑。我们不需要一个有上千页的序列图,相反,我们需要一个非常明显的描述了系统主要观点的图。没有 UML 图比一个由许多线和许多框纠缠在一起组成的混乱的图更糟糕的情况了,如图(Figure 2-5),千万不要这样做。

保留什么,舍弃什么?

养成舍弃 UML 图的习惯吧,最好,养成不要把图建立在能长期保存的介质上习惯。在一个白板或一个草稿纸上画它们,经常擦掉白板或丢弃草稿纸。一个原则就是不使用 Case工具或一个画图工具。这些工具只用一次即可,你的大多数 UML 图都是短命的。

但是有些图保存下来非常有用:

  • 表现你的系统中一个通用设计解决方案的图
  • 记录了复杂的协议,难以通过代码了解的图
  • 提供了比较少涉及到的系统范围内的“路标图”的图
  • 记录了比代码更易表述的设计意图的图

认真去辩认这些图是没有意义的,你一看到他们去明白了。没有必要预先建立这些图,如果你猜的话,你会猜错的。这些真正有用的图将用反复浮现出来,它们将一次次地在设计时出现在白板上或草稿纸上。最后将有一个人将最终确定的图制作一个长期保存的备份,把图放在一个每一个人能够访问得到的公共区域。

公共区域必须保持简洁和访问方便,把这些有用的图放在一个 Web 服务器上或一个网络知识库中是一个比较好的主意。不过,不要使用成千上万张图全堆积在一起。明辨出哪些图是真正有用的图和哪些是将会在下一次临时通知中被重新创建的图。保留那些非常价值、 能够长期保存的图。

……

图在同事间进行表达比较有用,它将帮你解决设计上的问题。你仅用一定数量的、需要的细节去完成你的目标。弄出一个充斥着修饰符号的图不是不可以,但是它是效能低下的。保持你的图简洁,UML 图不是源代码,也不能视作方法、变量和关系声明。

什么时候画 UML 图,什么时候停止

不要制定什么都必须画图的规则,这样的规则将比不用更糟糕。项目的大量时间和精力 将会被浪费在追逐那个根本没有人去读的图上。

什么时候画图:

  • 当许多人一起需要同时进行开发时,这些人需要都理解一个系统的特定部分的设计结构时,开始画图。当所有的人都已经声明理解了的时候,结束画图。
  • 当两个人或更多人不同意一个特定的元素如何设计的时候,你需要你的团队意见一致的时候,要找一个时间进行讨论做出决定,比如投票,或一个公正的宣告的方式进行,这时你需要画图。当决定做出来后,擦掉这些图。
  • 当你需要探讨一个设计的想法时,画图能够帮你更好的地思考。当你得到了能够帮助你完成思考的代码的要点的时候,扔掉这些图。
  • 当你需要向其他人或自己解释一部分代码的结构的时候,你可以画图。当你觉得其实最好看代码来进行解释的时候,停止画图。
  • 当项目快要结束,顾客需要你将图与其他文档一起提供的时候,你开始画图。

什么时候停止画图:

  • 不要因为觉得过程需要而画图。
  • 不要因为你有一个觉得一个好的设计者必须画图,不画图反而感觉有罪的想法而去画图。好的设计者只有在需要的时候才去编写代码和画图。
  • 不要在编码之前的设计阶段去为创建全面的文档而画图,这样的文档基本没有意义并且将会浪费大量的时间。
  • 不要为了其他人编码而去画图。真正的软件构架师将去实现自己的设计的编码。这样他们反而简单了。