UML 真的有用吗

这是一个在知乎程序员业界被广泛讨论的一个问题。这篇文章以一个初学者的视角聊一聊浅显的理解。

第一次接触UML图是在大二春季学期的Software EngProject的课上，这门课的核心任务是小组4人合力开发一款麻将游戏。这个项目的初期提交中要求提供UML的设计，具体上是绘制用例图，时序图，类图。说实在的，第一次接触UML很陌生，我们浅显的理解为教授想要检验UML学习的成果，让我们将课上学得的方法得以练习。我们小组成员随即将这些制图任务一一认领，期间几乎没有对图设计的沟通，总是各自为战。在写这篇文章之前，我特地回顾了一下我们的第一次制图，按照现在的标准，只能是漏洞百出，用例沉余，include/extend关系混乱，时序图只有一张，笼统的用一句话就可以表示出来。虽然类图结构完整，但也和我们完成的源代码大相径庭。好在当时的这门课程似乎更加看重功能的实现，一个混乱不堪的时序图似乎没有对成绩造成多大的影响。同时我们小组四人的能力尚可，分工也算明确，项目的开发进展也很顺利。如今回想，当时的提交的用例图仅仅使得第一个里程碑的任务量增加了，对后续的工作没有实质性的帮助。至此，UML无用的概念在我心中已然存在。

但是由此得出UML无用的观点显然是毫无道理的，因为我并没有真正利用UML。时间来到大三上，铺天盖地的项目迎面而来，既有熟悉的软件领域，也有一些陌生的计算机领域（图形学）。面向对象设计，web开发和软件工程方法学的课程中都有或多或少的UML图的使用经历。我想以OOD这门课的经历，聊一聊我的真实UML使用经历。

首先，我想交代一下这门课的背景，希望读者可以设身处地的理解我的感受。OOD的课程项目是团队（5-8人）共同设计和完成一个 This project will involve the design and implementation of a software system for the management of events,their details and tickets. This will be a web-based application built using the spring-boot framework。如果遵循我的开发惯例，我们的团队应该会按照功能划分为若干子小组（如场馆管理，票务管理），并选定一名开发能力较强的同学用较短的时间完成项目的初始版框架，一遍后续人员开发的标准接近统一。但是说实在的，就文章前述提到的麻将项目来说，这个开发方案在项目代码的架构和优美度上是差劲的，尽管最终的功能可以在多次调试修复下得以完善。其中的一个问题就在于，如果后续的开发者要符合前期开发者的开发思路，那么他就需要理解前期开发者设计源代码架构的思路。我认为若仅仅是在观察源代码的情况下，各阶段开发者的思想很难统一，只有对代码进行演示讲解，才有机会让开发的思路和架构接近一致。我们在这里先忽视团队成员水平差异的因素（有这个因素存在，开发思路的一致性维持的难度会大大提升。

回到演唱会系统上，这门课教授设计了Requirements Analysis, Analysis, Design, Implementation四个阶段的提交。在前三阶段甚至没有任何有关代码的工作需要提交，而是完全专注于用例图，时序图，类图的绘制工作。起初我们看到这样的任务是吃惊的，任务划分如此不平衡吗，真正重要的代码核心工作竟然放在最后，而且完成的时间也和前面几个阶段的任务相同。当我们团队坐在一起商讨这件事情时，质疑声首先发出，”我们直接开始代码工作吧，这些设计工作临时补充”，“按部就班完成吧”，不同的观点出现。最终我们决定，先按照教授要求试一试，实在来不及开发在中间再开始也可以。

作图的过程也是困难的，因为是多人开发，我们仍然想力求标准的统一化，但是在检索了大量资料后，我们发现根本不可能统一，用例的种类（详尽程度），时序图绘制的详细程度（数据库，边界等信息是否考虑）。好在教授给出了每一阶段的具体示例，我们只需要以他的为标准即可。此时我们也意识到了，UML图是团队沟通的工具，在一个统一标准的UML图绘制中，团队成员之间的想法被轻易捕获，系统设计和功能设计都在统一的标准下进行。用例图完整的捕获系统需求，时序图理解明确系统的动态行为，类图辅助设计了系统的结构。在此基础上，我们一致认为在前期的铺垫后，后续的代码开发工作自然水到渠成。显而易见我们不会经历重复的功能设计，不统一的任务执行流程（如删除账户时使用一个控制组件进行管理，删除场馆时对数据库直接进行操作）。

这就是我的UML实践。总结下来UML的好处是图片清晰的收集并展示系统需求，方便团队内部的沟通和交流，辅助编程工作。我认为好处是显而易见的，更多的我想聊一些反思。

首先我想引出第一个问题：UML真的帮助我们节省了沟通时间成本吗？对于我们的团队是是否定的，制定统一的绘制标准，在团队内对各种UML的绘制标准的统一，在描述同一个需求时，究竟使用哪种方式绘制这个图。沟通的成本在前期暴增，对于团队内都具备代码能力情况下，面向一个精美的代码而不是一个精美的图进行开发交流会不会是一个更好的选择。如果团队成员更换，我想这又将增加一次确定标准的沟通环节。另外，在实际的软件开发中，如何面对的需求的变更，我们应该先改图还是改代码。所以我不认为在沟通成本上UML图有很大优势，反之若出现过度设计，需求频繁变更的问题反而拖慢了开发进度。

第二个问题，UML图的表达能力有限。绘制者当然可以把所有的设计思路添加到UML中，但是此时的UML已经变得晦涩难懂，那么为什么不直接修改代码。在我们的项目开发中，用一句话能沟通清楚的功能，可能需要一张图来表示，需要20条UML语句表示。所以，UML适合更高层的设计和交流，在具体的编程者身上，面对面的沟通，在代码中使用注释也会是很好的功能。但是这个高层也仅限于能看懂UML图的高层，若是甲方的抽象需求，可能需要精美的PPT了。

第三个问题，图很有用，但UML图绘制很复杂。UML是一种语言，他依赖文本生成图，缺少了创作时的随心所欲。每当我在绘制UML图是（尤其是用例图），为了获得优美的排版，我时常需要频繁的更改绘制语句。如果需要这些图，使用真正的图片化绘制工具，或者干脆手滑（如果好看的话），随之而来的绘图灵感就不会因UML绘制语言的繁琐而打扰。知乎下有一个回答很好：“画图有用不等于UML有用”。

最后，尽管我提出了三个值得反思UML是否有用的问题，但是绘制UML图的过程近乎一个完美的软件开发工作流程，从需求分析，顶层架构，代码设计。在跟随着这套思路做开发的过程中，软件的轮廓是清晰的，工程师的思想可以建议的落实在程序上，用户的需求也会得到满足。对于是否有UML的替代工具，无论是BPMN，DSL，还是遵循敏捷方法的建模（白板绘图）都有支持者与反对者，选择适合自己开发团队的工具，适合项目背景和需求的方法和工作流程才是当务之急。

最后再引用知乎的一个回答：“编程带给人的快乐，无非是巧妙的设计构思的成就感，代码只是媒介”