《软件方法》2023版：1.4 应用UML的建模工作流，源代码就是设计的真相
1.4 应用UML的建模工作流
1.4.1 概念
我用类图表示建模工作流相关概念如图1-16。
图1-16 建模工作流相关概念
图1-16左侧灰色部分定义了“游戏规则”，右侧则是在“游戏规则”上“玩游戏”的结果。
显然，只是看这个类图不能很好理解相关概念。我用对象图展示本书推荐的“游戏规则”如图1-17。
图1-17 建模工作流相关概念的对象图（图形较大，点开看或访问原图http://www.umlchina.com/book/1pics/fig1_017.png）
图1-17中，除了最左侧的“工作流类型”之外，都是可以变化的。可以替换“表示元素”。例如，系统用例规约改为用活动图表达，则图1-17的相应部分可以改为图1-18。
图1-18 系统用例规约改为用活动图表达
可以替换“表示法”。例如，把UML换成其他表示法或自创的表示法，那么图1-17左起3到5列都要修改。可以替换“方法学”，例如，受“少林功夫+唱歌跳舞”启发，创造出“浑元形意太极+革命性创造划时代洞见领域驱动设计敏捷精益方法学”，但仍然使用UML表示法，那么图1-17左起2、3列需要修改。
1.4.2 工具箱
从图1-17可以看出，本书重点使用的UML图形只有4种：用例图、类图、序列图和状态机图。
UML 2.5包含的图形一共有14种，如图1-19所示的树上的叶结点。
图1-19 UML图形（根据UML2.5规范绘制）
经常会有人有意无意地误导，让人以为使用UML建模需要画这么多图，顺势攻击“UML笨重”。其实，应该把UML看作一个工具箱。工具箱里面有各种工具，建模人员只需要根据当前所开发系统的特点，从这个工具箱中选择合适的工具就可以，并不需要“完整地”使用UML。
这和编程语言类似。很多人说“我用Java”，其实只是用Java的一小部分，而且很长时间内也只会用这一小部分。
经常有学员问：潘老师，能不能给一个案例，完完整整地实施了整套UML？这是一种误解，这样的案例不应该有。这相当于问：有没有一本经典的小说，把字典里所有的单词都用上了？有一些建模工具自带的案例模型会造成误解，一个模型里把所有的UML图都给用上了，但这是工具厂商出于展示其工具建模能力的目的而提供的，不可当真。
1.4.3 使用UML建模的工作流步骤
图1-17中“工件形式”一列所列出的图就是本书推荐的在建模工作流ABCD中的UML用法，我用活动图进一步表示建模的步骤如图1-20。本书的内容就是按照图1-20的顺序讲述。
图1-20 使用UML的ABCD建模工作流步骤
从图1-17和图1-20可以看出，本书重点使用的UML图形只有4种：用例图、类图、序列图和状态机图。
图1-21列出了其他可选的用法。
图1-21 可选和推荐的建模元素用法（●表示推荐使用，√表示可以使用 ）
从图1-17和图1-21可以看出，设计工作流的建模，推荐做法是不用UML表达，而是用相应实现平台的表示法表达，即所谓的“源代码”（目前大多是文本形式）。考虑了具体平台实现的类图、序列图、状态机图等，其中包含的信息和“源代码”差不多，没有必要花费精力去画设计工作流的UML图再编码，因为这样做没有带来任何增值。
建模过程中，我们写的每一个字，画的每一张图，都应该能带来增值，否则就没有必要写它或者画它。这一点，本书后面还会不断提到。
更合理的做法是，做好分析工作流，把领域逻辑放进分析模型中，然后再结合实现平台的特点，选定一条分析和设计之间有规律的映射套路，通过建模工具或者人力搬砖把分析按照套路映射到设计。
这时，即使要画设计的类图、序列图等，也只需要挑选典型的类、典型的用例来展示映射的套路，不需要把分析模型的内容都结合实现平台画一遍。
像Rhapsody（当前的全名是IBM Engineering Systems Design Rhapsody）这样的建模工具，可以和各种开发环境集成，配置好后就可以通过正向工程从类图、状态机图生成可执行的代码。开发人员甚至可以做到只需要编辑和调试UML模型，不需要在编码环境中编辑和调试。图1-22是用Rhapsody工具绘制的某个模型（洗碗机）的运行时状态机图，粉红色标出了当前的状态。类图和状态机图的背后有真实的C++代码。
图1-22 Rhapsody下的运行时状态机图
同样，如果需要设计工作流的UML图来搞形式主义充场面，可以通过建模工具对源代码或数据库做逆向工程，生成设计工作流的各种UML图。如图1-23，就是用建模工具UModel对某个C#类的某个操作做逆向工程生成的序列图。可以看到，这张序列图涉及到很多类的协作。图的右侧放大了一个小片段，勉强让读者能够阅读。
图1-23 从代码逆向工程得到的UML序列图
以上提到的选择映射套路、正向逆向工程等内容，本书在设计工作流的章节再详述。
1.4.4 关于“源代码就是设计”的歪曲和真相
1.4.4.1 Jack Reeves的文章
1992年，Jack Reeves在“C++ Journal”上发表了一篇名为"What Is Software Design（什么是软件设计）”的文章。
Jack Reeves文章中的观点有：
（1）根据他的观察，软件开发生命周期中，唯一满足工程标准的软件文档是源代码清单。
——这是正常的。当时（1992年），除了源代码所使用的编程语言之外，软件开发生命周期中其他产出很难谈得上有什么严格的语法和语义规则。
（2）软件开发的一切都是设计过程的一部分。编码是设计，测试和调试是设计，平时我们称为“软件设计”的东西也是设计。
——这是要求从“设计”的高度来看编码，不是说代码能编译运行就行。
（3）C++是很有表达力的软件设计语言。
——要从“设计”的高度来看编码，编程语言要有好的表达力，例如C++。毕竟是发表在C++ Journal上的文章嘛。
整体来看，Jack Reeves的文章没有太偏激的观点。即使存在问题，也是前文提到的普遍缺少A、B工作流知识的问题。
1.4.4.2 Robert C. Martin的修饰
"What Is Software Design”一开始并没有广为流传。
2002年，Robert C. Martin在他的书“Agile Software Development, Principles, Patterns, and Practices”第1版中附上了这篇文章，并在前面加了个大标题“The Source Code Is the Design（源代码是设计）”。
这是第一个“小心思”。
Robert C. Martin这本书的书名也包含着“小心思”。书中主要讲的是面向对象设计的一些方法（原理、原则和模式），这些方法并非Robert C. Martin首先提出，和“敏捷”提倡的“过程”也没有必然关系，但Robert C. Martin把它们称为“敏捷**”，很容易让开发人员误解，这些东西是“敏捷”人士提出来的。
图1-24 “Agile Software Development, Principles, Patterns, and Practices”的目录
最近一些年的领域驱动设计伪创新走的也是这条路线，背后的操盘者们也是来自同一个圈子。
2007年，Robert C. Martin在第2版“Agile Principles, Patterns, and Practices in C#”中，也附上了Jack Reeves的文章，但名字改成了“What Is Software（什么是软件）”
1.4.4.3 中文翻译的误导
Robert C. Martin书的第1版中译本《敏捷软件开发：原则、模式与实践》中，把“The Source Code Is the Design”翻译为“源代码就是设计”。
“是”和“就是”有微妙的差别，“是”表达的是从属关系，“就是”隐含着相等关系。
马铃薯是草本植物：马铃薯∈草本植物
马铃薯就是土豆：马铃薯=土豆
源代码是设计：源代码∈设计或源代码⊂设计
源代码就是设计：源代码=设计
从上面列出的观点（2）可以看出，Reeves的文章中并没有这个意思。
文章"What Is Software Design”目前可在以下地址获得：
https://www.developerdotstar.com/mag/articles/PDF/DevDotStar_Reeves_CodeAsDesign.pdf
感兴趣的读者可以去下载阅读。
另外，以上只是说Reeves的意思被歪曲了，但没有说Reeves本来的意思就一定是对的。类似这样的观点，往往都存在前文提到的普遍问题：缺少对A和B工作流的认识。
**********
关于“source code（源代码，代码）”，有的开发人员也存在误解。
计算机运行的是二进制指令，源代码是程序员需要理解和编辑的最低形式模型——编辑完这个，后面的事情就可以交给计算机了！
中文翻译“代码”中的“代”字就体现了这个意思，用更方便理解和编辑的符号来“代替”原来的指令。从这一点看，编码就是一种最低形式的建模工作，源代码也是“模型”。
这个最低形式模型是随着时代的发展不断变化的，如图1-25所示。
图1-25 “源代码”的发展历程
最开始，程序员在纸带或卡片上打孔来表达0和1，这可不是“代码”了，就是“码”本身。
后来发现这样太累了，于是发明了一些助记符，这就是汇编语言。
有的开发人员凡尔赛，“这些我不太懂唉，我是做底层的，用C编码”，可是C语言却被归类为“高级语言”，因为类似C这样的语言出现的时候，大多数程序员编辑的是汇编语言，C相对于汇编来说，当然很高级。
今天的一名企业应用程序员，需要编辑的可能有HTML、CSS、JavaScript、Java、配置脚本、SQL等，这些就是当前常见的“源代码”的形式。
如果人脑只需要编辑UML模型就可以实现系统，不需要编辑Java、C#等文字形式代码，那么UML模型就相当于“源代码”。
因此，不存在什么“无代码”、“低代码”，人最终需要编辑的那个东西就是“代码”。
★很多（15+）年前，一位CTO向我展示他们的软件，说不用编码就可以为不同的客户定制。我问他怎么做到的，回答“只需要改配置文件里面的各种信息就行！”。其实那个配置文件就是一种“代码”。
UMLChina公众号文章精选（20231125更新）按ABCD工作流分类
[高阶·架构师]12月18-22晚8点分析设计高阶（原“剔除伪创新的领域驱动设计”）
[高阶+]12月4-6晚8点企业应用架构模式新解-网络公开课