什么是UML UML入门到放弃系列

1.定义

        UML-Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。

2.UML的三个级别

        《UML精粹》一书中把这三个级别称为概念级、规格说明级和实现级。

2.1 概念级

        概念级的图示和源代码之间没有很强的关联。它们更多是和人的语言相关的。概念级的图示可以作为一种速记方法，用于描绘存在于人类问题领域中的概念和抽象。因此，它们不必遵循强的语义规则，其含义可以是模糊的，通过解释来确定。

2.2 规格说明级

        规格说明级的图示与源代码之间有很强的关联。实际上，规格说明级图示的目的就是要能够转换成源代码。

2.3 实现级

         实现级图示是要描绘已有的源代码。

        其中，规格说明级和实现级这两个级别的图示必须得遵循某些规则和语义。这样的图示非常明确并且有着大量的规范。

3.软件模型

        模型需要具备两个特点，即可测试可评估。如果模型不具备这两个特点，那它便没有存在的意义。为什么要建模型?那你可以联想一下航天工程师为何不直接造飞机，然后试飞呢？结构工程师为何不是直接建大桥，然后看看它是否能够不倒？答案很简单，飞机和桥梁比模型造价高多了。当模型比构建的真实实体便宜很多时，我们就会用模型来研究设计。这个观点在软件的建模上同样适用。

        接下来我们思考两个问题UML图是可测试可评估的么？与代码相比它更加便宜么？事实上我们无法给出一个明确的答案，或者说无法像航天工程师以及结构工程师那样在绝大多数场景下都能给出肯定的答案，这是因为软件建模的性价与具体的应用场景相关。

        我们来看UML是否具备模型的特点，即可测试可评估。很遗憾，测试在UML图方面，并没有严格的标准，同时模型的评估最终仍然是主观的。那么性价比呢，客观的说大多数情况UML图的绘制比编写代码代价要小一点，但是并没有小多少。事实上，经常出现更改源代码比更改图示更加容易的情况。

        说了这么多，你们是不是认为我在陈述一个伪命题，或者说UML图就是个鸡肋。这么说对了一半，因为UML确实很容易被误用，当硬性规定“必须图示一切”，这样的规则还不如没有规则。大量项目时间和精力会被浪费在绘制没人会看的图示上面，这时候UML图就是一个鸡肋。但如果用在与团队同步大型系统的结构时，脉络图就是一个非常适合的选择。所以恰当而有效的使用UML图是非常重要。

4.UML的应用场景

        那么我们什么时候应该使用UML图呢？我们把这个问题更加细化一点，写代码之前是否需要做好详细设计？我们都知道在建筑行业，一个建筑师的设计图可以拿个及时甚至上百人来建造房子。在做设计图时，不需要挖地基、浇灌混凝土或者安装窗户。总之，设计的代价比直接建造的代价低很多。丢弃一个错误的设计，比拆除有问题的建筑代价也低很多。但是这样的性价比，在软件领域却不明显，绘制UML图比写代码代价更低根本不明显，事实上，许多项目团队在图示上花的时间已经远远超过了写代码。丢弃图示比丢弃代码成本更低，同样不明显。因此，我们并不鼓励在写代码之前画一份详细的UML图示。
        那么我们到底什么时候才应该使用UML图呢？大师马丁总结了一下的情形
可以画图的情况如下：

1. 几个人都需要理解设计的某个特定部分的结构，因为他们同时都要用到它。一旦所有人都理解，就停止。
2. 你希望团队能够达成一致，但是有两个或者更多的人不同意某个特定元素的设计。把讨论限定在一个时间盒内，然后选择一种决策的手段，比如投票或者公平裁判。在时间盒终止或者能够做出决策时，就结束。然后，擦掉图示。
3. 你想尝试一个设计想法，并且图示有助于思考。当你可以使用代码完成思考时，就停止。丢掉图示。
4. 你要向其他人或者自己解释代码某些部分的结构当通过浏览代码可以更好地进行解释时，就停止。
5. 接近项目的尾声，并且客户要求要把图示作为一部分文档提供给他们。

不要画图的情况如下：

1. 过程要求。
2. 不画图会有负罪感或者认为这是好的设计师要做的事情。好的设计师是要写代码的。他们只有在必要时才画图。
3. 为了在编码前创建出面面俱到的设计阶段文档。这种文档基本上没有任何价值，却耗费了大量的时间。
4. 为了方便其他人编码，真正的软件架构师是要为自己的设计编码的。

下面将给出UML主要的几个具体应用场景:

4.1 与他人交流时可以使用UML

        使用UML在软件开发者间交流设计构想是非常方便的。一小组开发者站在一块白板前可以完成许多工作。如果你有一些想法需要和他人进行交流，UML是非常有用的。UML有助于交流清晰的设计想法。我们很容易就可以想象出一组开发人员站在一块白板前讨论着一幅类似图示的场景。事实上，图示非常清晰地表达了代码结构。另一方面，在交流算法细节方面，UML并不是非常合适。

4.2 大型系统的架构图

        架构图可以使得开发人员快速找到类与类之间的依赖关系，并提供一份关于整个系统结构的参考。这样的架构图是很有用的教学工具，任何团队成员都要能够立即在白板上画出这样一幅图来。

4.3 项目结束文档

        要编写需要保存的设计文档，最佳时机是在项目结束时，并把它作为团队的最后一项工作。这种文档会精确地反映出设计的状态，对团队非常有用。不过，仍有一些问题需要注意。UML图必须得经过仔细考虑。我们不需要厚达几千页的顺序图！我们想要的是那些描述系统关键要点的少量重要图示。充斥着大量混乱不堪、纠缠在一起的令人迷惑的线条和框框的UML图，是无法理解的。

5.要不要使用UML工具

        UML CASE工具可能非常有用，但也可能是昂贵的垃圾收集器。在决定购买并部署UML CASE工具时，一定要非常小心。

1. 难道UML CASE工具没有使得画图变得更容易一些吗？没有，它们使得画变得图更加困难了。要想熟练掌握工具，需要一个很长的学习曲线，即使掌握了，工具也相对更笨重，而白板则非常易于使用。开发者通常都已经非常熟悉白板。即使不熟悉，也基本上没有什么学习曲线。
2. 难道UML CASE工具并没有使得大团队在协作绘图方面更容易一些吗？有些情况下确实更容易。不过，绝大多数开发者和开发项目都不需要产出如此数量和复杂性的图示，多到需要一个自动协作系统来协凋。无论如何，都应该先用一个手工系统，当其显现出不堪负荷，并且此时唯一的选择就是自动化时，才是考虑购买UML图绘制协调系统的最好时机。
3. 难道UMLCASE工具并没有使得代码生成更加容易吗？画图，生成代码，然后使用生成的代码，所涉及的工作量之和很可能不比直接写代码的成本更低。如果说有收益的话，也不会是一个数量级，甚至不会是2倍。开发者知道如何编辑文本、使用IDE。从图示生成代码听起来像是个好主意，但我很希望你在大把花钱之前先度量一下生产力方面的提升。
4. 那些本身就是IDE并且可以同时显示代码和图示的CASE工具如何呢？这些工具确实很酷。不过，总是显示UML图并没有多大意义。修改代码时图示会相应改变或者修改图示时代码会相应改变，实际上并不会带来多少帮助。坦白讲，我更愿意花钱买专注于更好地帮助我处理程序而不是图示的IDE，同样，在决定投入大笔资金之前，请先度量生产力的提高。简而言之，三思而后行。给团队装备一套昂贵的CASE工具也许有好处，但在购买这些很可能无人问津的东西之前，请先通过实验来验证它的好处。

6.总结

        不要试图一次就把软件系统整体架构用UML绘制出来，从最简单的行为开始，绘制一幅有关具体问题的简单顺序图或者协作图，然后根据需求不断的补充和扩展。

        在使用图示时非常重要的一点是要能够想象出代码。我们把图示作为代码的速记，而不是替代。如果在画图时不能想象出它所表示的代码，那么就是在构建空中楼阁。停止绘图，想一想该如何把它翻译成代码。千万不要为了画图而画图。必须时刻确保自己知道正在表达什么代码。

        UML是一个工具，不是最终结果。作为一个工具，它可以帮助思考和交流设计。如果少量使用，它会带给你巨大的好处。如果过度使用，它会浪费你大量的时间。使用UML时，少即是好。

引用

《敏捷开发》—— 罗伯特.C.马丁