专栏文章浅谈现实软件开发中的UML

Posted 2021-04-17 Elissa的吃喝玩乐随记

【这是我们专栏的第一篇文章，来自一位大三学长，欢迎大家各种投稿w】

【这个栏目的初衷希望给同学们提供更多思考问题的其他角度，很希望看到同学们思考的方向更全面，也可以给更多人科普更多各类计算机知识】

【正文部分】：

软件工程中充满了繁乱的术语，其中，UML是经常被软件工程师们谈及起的一个话题。在利物浦学习Year 2的CS课程的同学需要完成Software Engineering І（软件工程І）。其中该课的一个重点，就是教学生UML。

UML是一个用来在高层次对软件进行建模的语言（图当然也是一种交流的工具，就像语言）。可UML究竟特殊在哪里？为什么会有这么多人支持UML，以至于让它成为你们课程的一个重点？

作为图，UML当然能在设计过程中起到一个视觉上的辅助作用，可同时几乎所有的图也都有类似的效果（从视觉上辅助设计，以宏观角度观察模型）。这并不能算是UML的一个优势，只能说是它继承了图的性质。所以，作为建模用UML图被这么广泛地利用可能有这么两个原因：

• 作为通用语言，方便与其他开发人员交流模型

• UML图能够自动生成软件模型（即UML图能转换为代码），实现从图开始，以图为范式的编程

至于有人说UML是很好的思考工具，我认为那也仅仅对个人而言有意义，并不是对团队的所有人来说都是成立的（接下来会提到为什么），而软件开发是一件和团队紧密相关的事。

作为交流用的模型

用UML图的第一个原因很好理解：UML图制定了一系列的标准，似乎正好是提供给了程序员们一个通用的语言。然而，UML图的学习曲线并不平坦，这也是为什么学校指定的课程是让你们花一整个学期学习寥寥几个UML图。当你需要通过一本超过200页的书来教授如何使用一套图形符号的时候，他的学习曲线就不比新手入门像Java这样的编程语言了轻松多少了。这个问题同样使得普及UML变得困难。毕竟，UML并不像编程语言那样是编写程序的必经途径，普及他的难度无法和编程语言相提并论，那就更别提如何在软件工程中实用，成为开发人员共通的语言了。

注意，软件开发的过程中并不是只有程序员，还有一些从来没有学习过UML的领域专家。显然，并不是所有参与软件开发的人员都需要知道软件的模型：UI设计师不需要知道软件内部的细节，只需要负责UI相关的部分；游戏的音效设计师只需要考虑如何制造音效，而不需要考虑音效要如何以代码的形式嵌入到游戏模型里。因此UML图适合让开发人员用于和不同专业领域的人交流的这种说法，也是不成立的。

这其中唯一的例外是UML类图（Class Diagram），它能非常方便地让程序员了解全局的大致情况。当你仔细观察类图时，你会发现UML的类图只不过是Java程序的类（Class）的一个缩写，给他们画几个箭头来描述它们之间的关系罢了。在用Java这样的语言时，可以轻松地将程序以类图的形式呈现，来观察整个系统的全局。由于这种简单的设计能恰到好处地把握面向对象系统建立的模型，使得它的学习曲线变得低而平稳，实用价值大大提升。

逆向工程

现在来看看UML是否能够自动生成软件模型。一旦UML图能够用于生成代码，那就意味着图形本身可以被映射（map）到某一个程序语言里，从而让程序员可以直接用图来进行编程，然后再生成可以运行的代码。这种做法通常叫逆向制造（Reverse Engineering）。

我曾经发邮件问过这位讲师：当我分析完信息得到这个UML模型后，是不是有什么通用的模式可以让UML逆向制造？然而这个问题没能从他那得到一个回复。但后来我得知，虽然并不是所有的UML图都可以进行这种转换，但将类图转换成代码这个功能却早就实现了（比如Visual Paradigm就提供了这个功能）。类图受支持的原因很简单，因为它和那些以面向对象系统为主的程序语言之间的关系几乎是自然到显而易见的。对于其他种类的图来说，就没那么幸运了。不过，至少当下最流行的家伙们已经得到了很好的支持。

既然类图可以实现以图为范式的编程。我们下一个要考虑的问题应该是

如果以图为范式的编程是可行的，是否图要比代码更好？

这里说的以图为范式的编程是说从程序开发开始开发者都一直在图的结构上活动，不向下到代码层面。这也是一个很泛化的问题，因为图并不一定只局限于UML的形式。可我们已经有一些“血淋淋”的例子证明图甚至于其他很多范式，都比不上在代码上直接开发要来得好。以图为代表的许多其他范式中最具有代表性的缺点之一就是开发效率。在Hackers News上关于UML的讨论(https://news.ycombinator.com/item?id=10379125)中提到了不少以图为基础的设计方法，也有不少有趣的例子，这其中就包含IBM的Rational Rose XDE(https://en.wikipedia.org/wiki/IBM_Rational_Rose_XDE)。Rational Rose XDE就是一款以图为基础的软件设计程序，最终被IBM停止维护：它坚持到第12年就彻底燃尽了。用了Rose XDE系统的开发者常常抱怨道：“这玩意儿实在太难用了！”。UML这样的图也不能保证模型的安全性和可维护性，这些都是程序员分内的事情，图无法负责，自然也没有相关的优势。

当然，完全以图作为语言进行开发是否会造成开发效率大打折扣还需要更多的证据，但现在电路设计已经从电路图走向HDL（Hardware-Description Language）这样的事实是否已经能给予我们一定的启示？以图为范式进行编程的复杂度可以猜测到是很高的。我们可以用像Scratch这样的类似物做比较：在Scratch上将逻辑结构拖拖拽拽显然对小程序是可行的，可程序一旦变得复杂，开发就容易变得低效了。

面向对象的模型（用类图创建出的模型）

综上来看，类图几乎成为了UML最重要的组成了。类图能很好的映射以面向对象系统为主的语言（比如Java、Python和C++），能很好的支持相互转换。虽然以图为范式编程不那么现实，但是我们还是可以用图来建立模型吧？

实际情况是，在多数情况下，使用所谓“面向对象思维”对信息进行建模并不见得总是什么好的方案。建模初用的模型一般都是方便你思考问题而用的模型，而现实世界却并不总有那么多问题适合套入到面向对象的模型中。

比如，当你描述“从冰箱里拿出大象”这一过程（程序）的时候，你可以轻松把整个过程分为打开冰箱，拿出食物，关上冰箱这三步。在C语言里，程序员要写的也无非就是就是表示这三步的三个函数：open_fridge_door, take_elephant_out及close_fridge_door。可这三个步骤倘若用“面向对象语言”来表述，就得把这三个步骤变成某个叫“冰箱”的对象的三个静态方法（static method），可想而知这种硬塞模型的做法是多么蹩脚（就好像生搬硬套设计模式（design pattern）让面向对象成为一滩烂泥一样）！这种问题是以面向对象系统为主的语言天生的，类图继承了这一问题，因此即使转换成类图也会如此的奇怪。

若用类图所用的“面向对象”的概念解释，这三个方法是“冰箱”对象的三个“行为（behavior）”。可现实中冰箱自己又怎么会“打开冰箱”，“拿出食物”，“关上冰箱”呢？面向对象编程所宣称的这三个“方法”是冰箱自身的”行为”的这种说法根本没法成立！

事实上，面向对象模型做的只不过是把相关的函数按“类”聚集在一起，放在一个叫“对象”的容器里罢了，而这么做其实是没有必要的，并且引入一定复杂度。这也是很多同学在学习Java或者其他以面向对象系统为主的语言时一直误解的事情：面向对象系统并不意味着所有东西都是对象，类只是相关物体的一种聚集，而它本身不是一个切实的物体。

你可能想，UML还有其他好几种图啊，其他的图难道不适合建模吗？比如活动图（Activity Diagram）、次序图（Sequence diagram）似乎就很合乎前面开冰箱例子的要求啊？当然，这些图在建模层面要比类图要好，但是回过头来，这些图你没法自动直接把你使用的图自动转换成代码，那你用UML辛辛苦苦画出来那个模型究竟有什么意义（尤其是他们已经没有特别理想的交流价值）？用别的图难道不是一样能做到用UML图能做到的事情（用来分析信息之间的关系）吗？普普通通的流程图早就可以做到了，UML图并没有带来什么优势，反而可能加深其他使用者的理解难度。

不过，类图不适合用在最初建模也不意味着它就没有价值。实际上，类图往往正是在正式开发后进行使用的。此时的类图已经和建模关系不大，而是更多作为一个将用代码写的程序抽象了的视角存在，正如我们谈UML作为交流用的模型时所说的一样。程序员在开发过程中仍然需要这样的一个宏观的视角来让他们掌握全局，这也是为什么类图是UML中活得最好的常青树。

总结……

在我眼里，UML图已经失去了它能够被使用的意义，只能留于一种形式存在。事到如今，UML图对软件开发行业又剩下多少意义呢？这个答案需要交给现实中的软件行业检验，需要时代的检验。我们能看到的是，在当下的开发市场上，除了类图外的其他UML图们的阳寿已经不多了。

是否当下程序语言的抽象能力已经足够好了，可以不需要图了呢？答案也是否定的，尤其对于大型且精密的系统来说，要从宏观的角度把握全局，图仍总是更好的选择，但是这个选择，如果不是类图，可以不需要在UML中挑选。一个团队内大家都更为熟悉的语言（可以是图），或者一个更定制化、更安全、专门为大型系统设计的语言可能更适合这样的角色。

【文章仅代表个人观点，如有相关交流想法，欢迎留言】