[重写]《软件方法》全流程引领AI第1章-1.3为什么要使用标准建模语言(202610更新)

DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

第1章 ABCD工作流

牵着你走进傍晚的风里，看见万家灯火下面平凡的秘密。

《情歌唱晚》；词：黄群，曲：黄群，唱：曹崴；1994

1.1 利润＝需求－设计

1.2 建模工作流

1.3统一建模语言UML

1.3.1 UML的诞生

本书的建模主要使用UML（Unified Modeling Language，统一建模语言）。UML是由OMG（对象管理组织）维护的一个软件建模表示法标准。

在1.2中，我们阐述了A→B→C→D的推导是不可避免的，但具体如何推导，有各种不同的做法，这些做法可以称为“方法”。甚至只要愿意，每个人都可以创造自己的“方法”，无非是有的正确，有的错误，有的高效，有的低效。

有一些“方法”被成体系地归纳出来，并向业界推广，这些可以称为“方法学”。软件开发方法学中的很多概念借用了其他学科的术语。像“流程建模”、“需求”等术语在计算机出现之前就已经存在，而且含义和今天软件开发中使用时的含义差不多。

早期的软件开发方法学较多关注D-设计工作流，即所谓的“程序设计方法学”。后来，随着软件的规模和复杂度增加以及竞争的加剧，上游的ABC工作流逐渐得到重视。从整体趋势上看，受到方法学关注的工作流的顺序和A→B→C→D的推导顺序刚好相反，D→C→B→A。

下一个受到关注的是C-分析工作流，最开始的一批方法学可以统称为结构化分析设计（SAD）方法学，主要的手段是数据流分解以及实体-关系建模：

●SADT（1973，即后来的IDEF0）

●DeMarco（1978）

●Yourdon/Constantine（1978）

●Gane/Sarson（1979）

●SSADM（1983）

●James Martin等人的IE（Information Engineering，1980年代）

……

然后，OOAD（面向对象分析设计）方法学相继出现：

●Booch（1982）

●Jacobson OOSE（1987）

●Rumbaugh OMT（1987）

●Shlaer/Mellor（1988）

●Wirfs-Brock责任驱动设计（1989）

●Coad/Yourdon OOA（1990）

●Martin/Odell OODA（1992）

……

以上列表按年份排列，不涉及流行程度。括号中的年份是目前找到的最早公开文献的年份，不限于书籍，因此，有的年份可能会比在其他地方看到的要早。

这时出现了一个问题：冒出来的方法学太多了，而各个方法学的术语、符号又不统一。

UML规范[1]中也记录了这段历史：

The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the "method wars."

（在1989-1994年间，已识别到的建模语言从不足10种增加到50多种。许多面向对象方法的使用者发现，难以在任何一种建模语言中寻求完全的满足，这助长了所谓的“方法学战争”。）

图1-8展示了同一张UML类图在不同方法学中各自的符号表示。可以看到，三角形符号在OMT方法学中表示泛化，在Coad/Yourdon方法学中却表示关联，Coad/Yourdon方法学中泛化用的是类似铃铛的形状。

图1-8不同方法学图形比较

类似这样的差异造成了混乱，使开发人员无从选择，也妨碍了方法学的推广。

1994年，两位已经在Rational公司工作的方法学家James Rumbaugh和Grady Booch开始合并OMT和Booch方法。在1995年10月的OOPSLA'95会议上，他们首次公开发布UML的前身——Unified Method 0.8。

★花絮：Unified Method 0.8并非OOPSLA'95的正式论文，而是在Rational公司组织的附属活动中发布的。

★花絮：由于Unified Method和后来的（Rational）Unified Process名字有点接近，不了解这段历史的人可能会把二者搞混，以为Unified Method是后来的Rational Unified Process（Rational 统一过程，RUP）。Martin Folwer《分析模式》的某个中译本就犯过类似错误[2]。Rational Unified Process是过程，源自Ivar Jacobson的Objectory过程；Unified Method（即后来的UML）是建模语言。

随后，Ivar Jacobson带着他的OOSE方法学加入了Rational公司，一同参与合并工作。这项工作造成了很大的冲击，因为在此之前，各种方法学的拥护者觉得没有必要放弃自己已经采用的表示法来接受统一的表示法。

Rational公司的这三位方法学家被大家称为“三友”（Three Amigo）。1996年，三友开始与James Odell、Peter Coad、David Harel等来自其他公司的方法学家合作，吸纳他们的成果精华。1997年9月，所有建议被合并成一套建议书提交给OMG。1997年11月，OMG全体成员一致通过UML，并接纳为标准。

1.3.2 UML诞生之后

UML发布后，带来的第一个变化体现在软件开发书籍上。

首先，出现了一大批介绍和讲解UML语言及其应用的书籍。这部分书籍之前当然是不存在的，属于纯增长。

讲解软件开发方法学的书大量增加。有了UML这个标准载体，UML诞生前出版的、较有名气的方法学著作，陆续出现了用UML表示的新版本——有的书可能会起一个和上一个版本差别较大的新名字。此外，还出现了很多之前没有的方法学著作。

特别要说的是，这些方法学著作不仅涉及“C-分析”和“D-设计”，其中一部分著作还聚焦于“B-需求”和“A-业务建模”。

虽然UML的出现源于面向对象分析设计的“方法学战争”，但UML诞生后，之前的一些聚焦于“B-需求”和“A-业务建模”的著作，也在新版本中引入了UML。

这可能归功于Ivar Jacobson。UML从他的方法学引入了“用例”，使得“B-需求”的讨论有了入口。Jacobson扩展了他的方法学，通过业务工人、业务实体等概念把面向对象应用于组织的建模（A-业务建模）。

同时增加的还有软件过程书籍，最亮眼的主题是Rational Unified Process。此外，还有一些***Process，声称在保持RUP的“用例驱动”、“架构为中心”、“迭代和增量”核心思想的同时，改良了RUP。这些过程书籍或多或少和UML都有些关系，在讲述软件过程的同时，不可避免会涉及UML以及以UML为载体的方法学。

随后，UML也进入了各个主题的软件开发书籍。例如，一本主题为Java编程的书，里面如果提到建模，UML是最常见的表示法。

第二个变化，建模工具的数量和种类出现了爆炸性的增长。

维护UML标准的角色（OMG）、根据标准制作建模工具的角色（工具厂商）、使用工具开发软件的角色（建模人员）这三个角色被分离，给市场带来了活力。

关于UML建模工具的内容，后面有专门的章节叙述。

第三个变化，很多行业选择使用UML来表示它们的标准。

以下是本书作者阅读过的一些用UML表示的标准，它们一直在生效而且近几年更新过。

图1-9 使用UML表达的行业标准（部分）

由于不少标准需要付费才能获得全文，作者无法逐一阅读各个行业的相关标准，甚至连图1-9列举的一些标准的全文也未能读到。作者也未检索到包含类似图1-9内容的文献——覆盖多个行业，集中列举使用UML的行业标准。

因此，图1-9列举的只是作者目前搜集到的部分，远非完整清单，感兴趣的读者可以在此基础上进一步探索，如有需要补充的内容，麻烦告知我。

软件业也是一个行业，UML算是软件建模领域的“行业标准”。2005年，UML 1.4.2被ISO接纳为ISO/IEC 19501:2005。2012年，UML 2.4.1被接纳为ISO/IEC 19505-1:2012和ISO/IEC 19505-2:2012。标准的最近一次复审是2025年。

2011年，中华人民共和国发布统一建模语言国家标准GB/T 28174。标准的最近一次复审是2022年。

UML的最新版本是OMG于2017年12月通过的UML 2.5.1[3]，此后，到目前为止，还没有进一步的更新。作者个人的观点，原因可能有：

（1）从1997-2017年这诞生后的20年时间里，UML经历了多次更新和升级，已经趋于稳定。能解决的问题基本解决，解决不了的，可能需要大动手术才行了。

（2）OMG把更多精力投入UML的扩展——SysML，把建模的关注范围从软件工程扩展到系统工程。自SysML 1.4被ISO接纳成为ISO/IEC 19514:2017之后，OMG继续发布SysML 1.5（2017年）、SysML 1.6（2019年）、SysML 1.7（2024年）。

2025年9月，系统工程建模语言新版本SysML v2发布。SysML v2不再像SysML v1一样只是UML的扩展，而是另起炉灶，可以看作考虑了上面所说的（1）和（2）。

以上仅为作者个人观点，并无官方言论作为依据，仅供参考。

UML的将来如何？我们得先说一下其他话题，再回来看这个问题。

1.3.3 为什么要使用UML（或某个类似的标准建模语言）

前面说了，内容是最重要的。如果一个人所表达的ABCD工作流内容是有道理的，他用口头方式、文本方式还是图形方式表示，是一个次要问题。

我们在这一节，先抛开内容不谈，比较不同的表示形式。

我把软件开发过程中发生的行为用UML序列图归纳如图1-10：

图1-10 归纳软件开发过程中发生的行为

在图1-10中，我简单把序列图生命线上的实例归为两个类的实例：人员和AI。读者可以理解为：人员涵盖了各类软件开发人员、各类涉众……，AI涵盖了软件开发人员打交道的各类形态的工具和环境——缺省认为其中都有AI的成分。

在图上，我把行为分为5类：

①人员的思考

②人员和人员的交流

③人员和AI的交流

④AI和AI的交流

⑤AI的思考

接下来，我们将比较在进行这5类行为时不同表示形式的优劣。

比较时，我们主要结合两个维度来比较：一个是介质，另一个是规范程度。

介质可以分为（人类）听觉介质、（人类）视觉介质和电子介质。视觉介质还可以进一步分为文本和图形。

注意，我在给介质分类时，是按感知方式分类的，还特地在听觉介质和视觉介质前面加了一个“（人类）”，并非简单表达成“语音”、“文本”、“图形”……。

下面的例子可以帮助理解：

张三说了一段话，李四听在耳朵里，这是听觉介质的直接传递；

张三说了一段话，通过微信发送语音给李四，李四播放收到的语音。这个场景里，听觉介质被（微信）转换成电子介质，电子介质传递，再被（微信）转换成听觉介质。

UML模型文件存储在电脑中，这是电子介质；通过建模工具（例如Enterprise Architect）在屏幕上显示（或打印）一张类图，相当于把电子介质转换成视觉介质。二者不能混为一谈。电脑旁的人员可以直接感知的是显示（打印）的图形，并不能直接感知UML模型文件这个电子介质。

★一些不太常见的场景本书暂不讨论。例如，丧失听力和视觉仅有触觉的障碍人士也有权利担任软件开发人员，视觉介质还可以拓展到三维模型，等等。

规范程度可以分为无规范、有规范但非形式化以及（半）形式化。

无规范：随心所欲，无约定的规范，符号与用词的解释权掌握在表达者大脑中。常见例子如随口聊天、随手涂鸦。

此处的“约定”、“规范”指软件开发相关的“约定”、“规范”。一个人在用汉语的标准语法谈论软件开发时，用语可以随意漂移——这还是属于无规范。后面章节所批评的领域驱动设计圈子话语，存在大量这样的例子。

有规范但非形式化：遵循某些约定或模板，但这些约定或模板可能并非从严密的元模型推敲得来，很容易出现冗余或矛盾。常见例子如团队自编的文档规范、图形规范。

（半）形式化：有严格定义的元模型、抽象语法和明确的语义约束。目前情况下，对于ABC工作流来说，形式化程度能做到让建模工具或AI稳定解析就够了，不要求完全的形式化（能够做严格的定理推算、形式化验证和机器编译等）。

★UML（以及SysML v1）整体上只能算半形式化，这和其兼容并包的初衷有关，无法把所有构造纳入同一个完整的数学体系。后来用于补充UML的OCL，以及另起炉灶的SysML v2，可以称为形式化语言。

介质和规范程度是两个不同的维度。

文本可以是随意写下的大白话，可以是按照模板编写的规约——但依然使用自然语言，也可以是形式化表达式。

图形可以是随手画的框框箭头，也可以是遵循UML规范的模型。

甚至听觉介质也能传递形式化内容，例如逐字念出一个表达式，只不过，通过声音表达的括号、层次和符号等，辨认难度大。

1.3.3.1 行为①人员的思考

===待续====

UMLChina公众号精选（20261008更新）

AI时代如何选择UMLChina服务（2026版）：建模引领AI

软件建模能力分步改进指南（2026版）

新增SysML v2水蒸馏器-几十套UML/SysML建模视频-全程字幕[202609]

[更换案例为：降血脂设备]SysML v2和CATIA Magic 2026全程实例剖析网络公开课--10月19-22日每晚8点

[本体 FDE]一个人的软件工程-《软件方法》全流程引领AI-第19期

作者微信：umlchina