[答疑更新]如何评价类似ZenUML这样的工具

zhoujing 2019-8-29 13:20

潘老师，最近有人推荐zen UML，貌似很强大，能从代码生成UML，这是一种画UML的新趋势吗？

UMLChina潘加宇:

20190901补：

有同学问怎样用比较好的问题——重点用在业务建模、需求和分析工作流就好。

群里前两天有同学发消息并贴了图，像这样用就挺好（虽然图不太对，应该没有那么多Business Actor，消息不应该是虚线……）

原答：

先说结论：

新趋势谈不上，而且用处不大。不过如果这样的工具能够流行起来，让程序员拥有一些建模的意识，然后在此基础上再去了解更有用的建模技能，那是很好的。不过，也要警惕变成"偷懒庇护所"。

从字符生成UML图形，这个能力很多UML工具都有——把已有代码逆向工程为类图、序列图。

下面两个图就是用EA和UModel逆向工程某个项目的代码得到的序列图

图1 使用EA在某个项目代码运行时录制的序列图

图2 使用UModel将某个项目源代码逆向生成序列图

类似ZenUML这样的工具的新意是，在一侧输入字符的同时，另一侧立刻就出现UML图形，毕竟图形比文本要漂亮，给人一种"我在建模耶"的高大上感觉。

类似的工具有不少，参见UMLChina整理的UML工具大全>>。

ZenUML只支持序列图，最流行的PlantUML支持很多图，不过ZenUML采用的语法更像主流编程语言的语法。

但是！

******************************

以下内容和ZenUML无直接关系，属于本问题回答的扩展。

就像上面说的，这样的工具给人一种"我在建模耶"的高大上感觉，很容易成为偷懒的庇护所，用来掩盖开发人员的懒惰和无能。

（1）没有增加（或减少）任何信息

可以比较一下问题所给的图的左右两侧，右侧比起左侧只是形式上的变化，并没有增加（或减少）什么信息，而且更占用空间。

软件开发中，增加的每一个字符，每一张图都应该凝结了新的思考结晶，否则就是废的，所以《软件方法》第1章推荐的工作流步骤中，不推荐画设计工作流的UML图形，UML图形用到分析模型为止，设计模型直接用源代码来表达，即"设计就是代码"。

关于增加（或减少）信息

增加信息举例：例如根据分析模型（只包含核心域知识），再选择好非核心域（即所谓"技术栈"，例如HTML+.....+ Spring MVC+.....+MySQL）以及相关配置，就能得到各个非核心域的"源代码"。当然，目前各种选择和搭配花样繁多，工具直接完全生成还不现实，现实的是分析模型+典型用例实现样例+人肉训练。

减少信息举例：从各种混合了核心域和非核心域知识的"源代码"中，提炼出仅包含核心域知识的分析模型。

（2）有可能掩盖了思维颠倒的脓包

关于思维颠倒，《软件方法》第1章有讲：

图3 《软件方法》第1章截屏

就怕有的开发人员根本没有能力做业务建模、需求、分析工作流的思考，干脆拍脑袋写了代码，代码当场转UML模型，然后就说我有图了，建模了，万事大吉了。

问题在于，你怎么知道这样的类、这样的责任分配就是合理的呢？有的人说不出理由的，经常用"我觉得"、"我打算"这样的词语来遮掩。

不只有新人是这样，有的挂着"资深架构师"头衔的开发人员也是如此。最近两年"领域驱动设计"重新成为时髦词语，我也沾光接了一些任务，听到“架构师”张嘴就是"我打算把**作为聚合根"……只能一声叹息。

图4 《软件方法》第1章截屏

什么时候能把"我打算"改成"我应该"就进步了。