《软件方法》2023版第1章：1.3 统一建模语言UML
1.3 统一建模语言UML
1.3.1 UML的历史和现状
UML（Unified Modeling Language，统一建模语言）是由OMG（对象管理组织）维护的一种软件建模表示法标准。
在1.2中，我们阐述了A→B→C→D的推导是不可避免的，但具体如何推导，有各种不同的做法，这些做法可以称为“方法”。甚至只要愿意，每个人都可以创造自己的“方法”，无非是有的正确，有的错误，有的高效，有的低效。有一些“方法”被归纳出来，并向业界推广，这些可以称为“方法学”。
最开始的软件开发方法学重点关注的是D部分，即所谓的“程序设计方法学”。后来，才逐渐在方法学中加入前面的部分，大致的添加顺序和推导的顺序刚好相反，→C→B→A。其中的很多概念借用了其他学科的术语。像“流程建模”、“需求”等术语在计算机出现之前就已经存在，而且含义和今天软件开发中使用时的含义差不多。
本书不想花很多篇幅来回顾这些方法学中的概念的历史，感兴趣的读者可自行搜索相关论文，例如Kolligs 等人写的“The Origins of Requirements”[Kolligs 2021]。
20世纪60-80年代，有名的软件方法方法学有：功能分解、数据流、E-R（实体-关系）等。
进入20世纪90年代，OOAD（面向对象分析设计）方法学开始受到青睐，许多方法学家纷纷提出了自己的OOAD方法学。流行度比较高的方法学有Booch、Shlaer/Mellor、Wirfs-Brock责任驱动设计、Coad/Yourdon、Rumbaugh OMT和Jacobson OOSE。其中，Jacobson的方法学添加了用例、业务工人、业务实体等概念，为OOAD方法学扩展了业务建模和需求部分。
这种百花齐放的局面带来了一个问题：各个方法学有自己的一套概念、定义和标记符号。
例如现在UML中的操作（Operation），在不同方法学各有叫法，这些叫法有：责任（Responsibility）、服务（Service）、方法（Method）、成员函数（Member Function）……
同一个类图，不同方法学也有各自的符号表示，如图1-7所示。在图中，我们可以看到，同样一个三角形符号，在OMT方法学中表示泛化，在Coad/Yourdon方法学中却表示关联，Coad/Yourdon方法学中泛化用的是类似铃铛的形状。
类似这样的差异造成了混乱，使开发人员无从选择，也妨碍了方法学的推广。
图1-7 不同方法学图形比较
1994年，Rational公司的James Rumbaugh和Grady Booch开始合并OMT和Booch方法。随后，Ivar Jacobson带着他的OOSE方法学加入了Rational公司，一同参与合并工作。这项工作造成了很大的冲击，因为在此之前，各种方法学的拥护者觉得没有必要放弃自己已经采用的表示法来接受统一的表示法。
Rational公司的这三位方法学家被大家称为“三友”（three amigo）。1996年，三友开始与James Odell、Peter Coad、David Harel等来自其他公司的方法学家合作，吸纳他们的成果精华。1997年9月，所有建议被合并成一套建议书提交给OMG。1997年11月，OMG全体成员一致通过UML，并接纳为标准。
从2005年起，UML被ISO接纳为标准。ISO/IEC 19501相当于UML 1.4.2，ISO/IEC 19505相当于UML 2.1.2。2012年，ISO继续接纳UML 2.4.1为ISO/IEC 19505-1:2012 和ISO/IEC 19505-2:2012，接纳OCL 2.3.1为ISO/IEC 19507:2012。
2011年，中华人民共和国也发布了统一建模语言国家标准GB/T28174。
UML的最新版本是OMG于2017年12月通过的UML 2.5.1，相关网址：https://www.omg.org/spec/UML/。
OMG还和各种行业标准组织如DMTF、HL7等结盟，用UML表达行业标准。
UML诞生已经超过25年，在软件开发表示法标准上已经获得了胜利。随便打开一本现在出版的软件开发书，里面如果提到建模，使用的标准符号基本都是UML。
另外，以UML为契机，掀起了一股普及软件工程的热潮，在UML出现后的几年，不但有关建模的新书数量暴增，包括CMM/CMMI、敏捷过程等软件过程改进书籍数量也出现了大幅度增长。制定UML标准的角色（OMG）、根据标准制作建模工具的角色（UML工具厂商）、使用UML工具开发软件的角色（开发人员）这三种角色的剥离，也导致建模工具的数量和种类出现了爆炸性的增长。而之前的数据流等方法从来没有像面向对象分析设计方法一样，出现UML这样的统一表示法，从而带动大量书籍和工具的产生。
最开始一批UML书籍，基本上由方法学家所写。最近几年，以“UML”为题的新书大多为高校教材或普及性教材。这并不是说UML已经不重要，而是没有必要再去强调，焦点不再是“要不要UML”，而是要不要建模、如何建模。
根据UMLChina的统计，UML相关工具最多时达168种。经过市场的洗礼，现在还在更新的还有几十种，有商业工具，也有免费或开源工具。隔一段时间，UMLChina会整理最近的UML工具更新情况，发布在http://www.umlchina.com/url/tools.html。
1.3.2 使用UML的理由
在开发团队中，不乏刻意排斥UML的人。这些人如果只是不使用UML，改为使用其他标准的图形表示法（如BPMN），那倒没有什么好说的——但仔细观察可以发现，绝大多数情况下并非如此，这些人要么使用自编的“图形表示法”，要么使用文本，甚至有的人只强调“口头交流”。
当然，通过UML、自编图形、文本、语音等形式都可以交流软件开发中的各种逻辑，但背后的效率是不一样的。
1.3.2.1 听觉 vs. 视觉
回忆一下我们在学生时代做听力题和阅读理解题的过程，就可以体会到，相对于听觉，视觉传递信息的效率更高，而且可以传递更复杂的信息。正常情况下，把模型表达成视觉信息，不管是文本还是图形，比起语音信息来说是更好的选择。非正常情况，视觉无法使用的时候，例如开车或者累得眼睛睁不开，这时用语音来见缝插针，通过听觉利（zhà）用（gān）建模人员的生产力，也不是不可以。
如果有人以“敏捷”为理由，特别推崇“口头交流”，排斥文档或图形，很可能是遮羞布，背后的脓包是此人没有能力剖析复杂逻辑，试图通过这种方式来遮掩。
有的开发团队动不动就开会，你一嘴我一嘴，场面看起来热热闹闹，其实沟通的效果不好，更谈不上思考的深度和知识的沉淀。对比一下街坊老大爷下象棋的热闹和职业棋手比赛时的沉静就知道了。
1.3.2.2 文本 vs. 图形
相对于只有自上而下顺序的文本（包括自然语言文本和编程语言文本），能够朝四个方向扩展的平面图形（如果有三维模型就更好了）更容易让建模人员看出领域概念之间的联系。例如，图1-8和图1-9的内容，如果没有图形的帮助，通过文本一行一行地构造和阅读模型，人脑的负担非常重。
图1-8 餐饮领域的类图
图1-9 计算器的状态机图，摘自Practical UML Statecharts in C/C++[Samek 2008]
说到这里，又不可避免地要提醒，故意选择文本的形式来表达领域知识，有可能也是一种遮羞布。图1-8和1-9的内容如果用文本表达，可能会得到很多页文本——这就有了理由：因为工作量太大了，所以很多地方无法做深入的思考，可以原谅！
1.3.2.3 自编图形 vs.标准图形
事实上，纯口头交流甚至纯文本交流是很少见的。除非要交流的问题极其简单或者其他同事对这样的人极其容忍，否则他至少也得随意画几张“草图”来传达自己的意思——自编的图形才是比例最大的存在。
这样的人之所以用自编的图形，往往并不是因为他看出了UML有哪些不足，然后用自己的表示法弥补了这些不足，而是要遮掩背后的一些脓包。
脓包一：利益绑架
项目中，有人画了张自编的图形，然后往往会伴随这样的招呼，“来，我给大家讲讲！”。这意味着项目要依赖于“我”头脑中的隐式知识——要是“我”不给大家“讲讲”，大家就不理解“我”画的图的意思，项目就玩不转了。于是，“我”在团队里的地位就提高了，大家得哄着“我”捧着“我”，领导不敢轻易开掉“我”，“我”离职领导还要挽留。这在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现得更明显。
★花絮：开发人员让我看他的模型时，如果开口说“我先来给你讲讲”，我都会拦住，“如果还需要你先讲讲，说明你所想的没有体现在模型中”。
脓包二：遮羞
因为符号是“我”自创的，所以这个图的解释权归“我”所有。如果有其他同事质疑图上什么地方画得不对，“我”就有了充分的躲闪空间——“你理解错了，这个图形不是你以为的那个意思。你以为我画的是鹿，其实这是马，在我的规范里面，马就是鹿的意思，鹿就是马的意思”。
如果使用了标准的表示法，例如用UML画了一个状态机图，其他人就有得说了，“好像手册上不是这样说的”，“我看那个书上不是这样说的”，这不就尴尬了嘛。
自编图形未必是看起来十分简陋的白板草图，也有看起来比较精致的。例如，来自某项目的图1-10。
图1-10 自编图形示例
其实，抛弃标准符号和建模工具带来的便利，用绘图工具或幻灯片工具画出这样的图，所花费的时间往往还要更多。但是，有意思的是，有的人画这样的图，还以“敏捷”为理由。
注意，上面说的只是“看起来比较精致”，其实内容还是很粗陋的，仅仅是把一些动词、名词的罗列成一个个形状，各个形状之间的关系基本没有，读者可以把图1-10和图1-8、图1-9对比。
1.3.2.4 挑破乱七八糟图的脓包
我们甚至可以“抛开事实（具体领域知识）不谈”，仅从“一致性”这一点入手，就可以挑破这种自编“乱七八糟图”的脓包。
自编“乱七八糟图”的画图者，很可能并没有归纳过各种形状的定义，只是凭感觉随意使用，或者即使归纳了，也不会像标准语言这么严谨，所以，大概率会产生“不一致”的问题。
我们就以图1-10为例。
图1-10中，同样被称为“平台”的东西，有着不同的形状和颜色，如图1-11。
图1-11 图1-10的不一致示例1
我们再来看中间这些方框，如图1-12。
图1-12 图1-10的不一致示例2
先看图1-12的最顶上3个方框，它们形状一样，长度一样，但有的叫“层”，有的叫“模型”，有的叫“队列”，这些概念可不是一个级别的。
（可能的辩解）也许在颜色中暗示？
再来看方框里的命名。最上面4行的命名，基本上都是“名词+动词+名词”结构，例如“消费信贷+统一前置+层”、“额度+管控+模型”，最下面2行的方框，命名是“名词+动词”结构，例如“消费业务+管理”、“流程+控制”。
（可能的辩解）你没脑子吗，自己脑补一个尾巴不行吗，“……模型”、“……层”、“……功能”、“……队列”、“……AI赋能领域驱动设计革命性创新微服务功能模块组件分布式大数据数智化平台”。
还有，名称同样是“模型”，颜色也有多种……
读者可以尝试从“一致性”着手，看看身边的同事画的“乱七八糟图”有没有这方面的问题。
可能有人会问：难道用UML来画就没有这个问题吗？
有的，例如，建模人员故意往用例的圈圈里乱填东西，有的填名词，有的填动词，有的填形容词，但这是违反UML相关的规范或指南的，其他人可以看出问题，批评和纠正。刚才说的情况是没有规范或规范模糊，这两者是不一样的。
用法律类比：精确严谨的法律条文并不能保证没有人违法，但至少大家有共识，什么是违法，什么不是。而另一种情况则可能是，孪生兄弟张三和张四做了同样的事情，张三违法，张四不违法，理由？不知道。
1.3.2.5 基本共识上的沟通
符号标准并不是随便哪个人拍脑袋定下来，然后毫无道理地强迫大家接受。符号背后往往隐含着我们对某个学科的一些基本共识。
如图1-13，最上一行的积分符号“∫”，幼儿园小朋友也能画出这样的形状，但其所代表的知识可能需要上到大学才能理解。如果要懂得为什么是这样一个符号，还需要了解数学史中莱布尼茨、傅立叶等人的贡献。图1-13中间一行的五线谱小豆芽和横线，最下一行的小人圈圈和框框，也是如此。
图1-13 符号背后隐含基本共识
这意味着，学习建模符号标准并非硬生生把形状记住后照葫芦画瓢就行，还要学习背后的一些建模知识。但是，开发团队成员咬咬牙，花费一些精力跨过这个门槛是值得的，因为一旦有了基本共识，会大大提高沟通的效率和深度。在严谨建模思维的追问之下，有意无意遮掩的脓包也会被强制露出——这也是一些“高手”潜意识里不愿意直面UML的深层原因。★花絮：面对一个棋局，下一步怎么走？在业余棋手看来到处都是正确答案，在职业棋手眼里，值得讨论的选项只有两三种，因为职业棋手针对一些东西形成了共识，大大减少了思考中的浪费。
★花絮：有的开发人员的“十年工作经验”实际上是“一年工作经验用了十年”，一直在热热闹闹的民工层次徘徊，没有积累和成长。
不过要注意一点：使用UML沟通仅限于软件组织内部，UML模型不是用来和涉众沟通的！这个道理以及和涉众沟通的技能将在第7章详细叙述。
1.3.3 SysML
SysML是系统工程建模的一种表示法标准。它是由INCOSE（国际系统工程协会）和OMG（对象管理组织）以UML为基础，进行系统工程方面的扩展后推出的。其目的和UML类似：统一系统工程的建模语言。
UML是信息系统的建模语言。“信息系统”的意思是该系统只负责处理信息：信息流进来，经过系统的处理，变成信息流出去，但是，信息系统不能处理物质流、能量流。
SysML相当于把“UML”扩展到各种类型的系统，这些系统可以处理各种各样的物质流、能量流。因此，SysML和UML不冲突，也不存在取代的关系。
我用刘慈欣的小说《流浪地球》举个例子。
太阳即将在400年内发生氦闪变成红巨星，人类社会怎么办？
众多科学家经过大量研究，得到一个解决方案：给地球装上发动机，驱动地球飞向比邻星（夭寿啦！正好三体舰队迎面飞来，嘭！）。
******
小说《流浪地球》原文：
地球发动机安装在亚洲和美洲大陆上，因为只有这两个大陆完整坚实的版块结构才能承受发动机对地球巨大的推力。地球发动机共有一万二千台，分布在亚洲和美洲大陆的各个平原上。
……
在六千米处，我们见到了进料口，一车车的大石块倒进那闪着幽幽红光的大洞中，一点声音都没传出来。
……
“重元素聚变是一门很深的学问，现在给你们还讲不明白。你们只需要知道，地球发动机是人类建造的力量最大的机器，比如我们所在在华北794号，全功率运行时能向大地产生一百五十亿吨的推力。”
******
“地球发动机”是一个巨大的系统，横跨多个学科，能源、材料、建筑、物流、人员管理……。
其中用来描述和处理信息的信息系统可能只占其中的一小部分，UML不适合描述“地球发动机”，SysML可以。
通过SysML不断把“地球发动机”分解成各个Block，Block又分为小Block，可能会得到其中一个Block叫“发动机中控系统”，这是一个信息系统。该系统其中一个功能可能是：根据接收到的测量参数值（可能有上万个），计算地球发动机下一步的最佳行动。我用SysML的块定义图画了图1-14，只是简单展示，我也不知道地球发动机应该分成哪些Block。
图1-14 地球发动机的分解
图1-14中的“发动机中控系统”这个信息系统，就适合用UML来建模。
听起来SysML描述的系统比UML描述的信息系统大，是不是意味着SysML更复杂？
其实恰好相反。在对UML和SysML都有所掌握之后，您会发现使用SysML比使用UML更容易。
使用SysML建模时，更多的是“描述”，而在使用UML建模时，除了“描述”之外，更重要的是“构思”。
像上面说的“根据接收到的测量参数值（可能有上万个），计算地球发动机下一步的最佳行动”，这个事情人也可以做到，因为计算的方法就是人指定的嘛，只不过人算得慢而且容易出错，所以用信息系统来做。
也就是说，我们需要把人脑总结出来的各种知识转移到信息系统中，并用它来取代人脑来做计算。信息系统的一切，包括规则如何表达，数据如何组织，各个部分的耦合、内聚等等，都需要我们一个一个构思。
非信息系统的建模并没有“取代人脑”的压力。当然，不是说非信息系统就没有难度。
像《流浪地球》原文提到的“重元素聚变”，我用SysML画了一张活动图，如图1-15。可以看到，这个过程处理的是物质和能量，原料和催化剂进来，变成能量出去。
图1-15 重元素聚变过程
打问号的地方，例如聚变过程的各个步骤应该怎么进行，催化剂是哪些，这些难题都需要各个学科的科学家去攻克。不管是SysML还是UML都是搞不定这个的。
科学家们研究出成果之后，可以用SysML来描述和帮助验证，涉及到人脑思考的地方，可以用UML来帮助构造信息系统取代人脑思考。
目前正式的SysML最新版本是1.6。2023年七月，OMG通过了SysML V2的β版本。
从目前的信息看，SysML V2有很大的变革，特别是大刀阔斧地清理术语。UML虽然把各种建模“方言”统一成“普通话”，但仍然做了一些妥协，留有各种冗余的尾巴。衍生自UML的SysML也不可避免存在冗余的问题。如果SysML大胆迈出这一步，把非必要的术语全部清理（和领域驱动设计圈子热衷造词形成鲜明对比），也许能促进UML做出类似变革。
OMG的SysML规范：https://www.omgsysml.org
UMLChina公众号文章精选（20231125更新）按ABCD工作流分类
[高阶+]12月4-6晚8点企业应用架构模式新解-网络公开课