对PlantUML们的评价-《软件方法》全流程引领AI-第1章 02

DDD领域驱动设计批评文集

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

《软件方法》各章合集

第1章 ABCD工作流-02

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-8所示。在图中，我们可以看到，三角形符号在OMT方法学中表示泛化，在Coad/Yourdon方法学中却表示关联，Coad/Yourdon方法学中泛化用的是类似铃铛的形状。

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

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

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”，而是要不要建模、如何建模。

1.3.2 使用UML（或某个标准建模语言）的理由

在开发团队中，不乏刻意排斥UML的人。这些人如果只是不使用UML，改为使用其他标准的图形表示法（如BPMN），那倒没有什么好说的——但仔细观察可以发现，绝大多数情况下并非如此，这些人要么使用自编的“图形表示法”，要么使用文本，甚至有的人只强调“口头交流”。

当然，通过UML、自编图形、文本、语音等形式都可以交流软件开发中的各种逻辑，但能达到的目的和付出的代价是不一样的。

1.3.2.1 听觉 vs. 视觉

回忆一下我们在学生时代做听力题和阅读理解题的过程，就可以体会到，相对于听觉，视觉传递信息的效率更高，而且可以传递更复杂的信息。正常情况下，把模型表达成视觉信息，不管是文本还是图形，比起语音信息来说是更好的选择。非正常情况，视觉无法使用的时候，例如开车或者累得眼睛睁不开，这时用语音来见缝插针，通过听觉利（zhà）用（gān）建模人员的生产力，也不是不可以。

如果有人以“敏捷”为理由，特别推崇“口头交流”，排斥文档或图形，很可能是遮羞布，背后的脓包是此人没有能力剖析复杂逻辑，试图通过这种方式来遮掩。

有的开发团队动不动就开会，你一嘴我一嘴，场面看起来热热闹闹，其实沟通的效果不好，更谈不上思考的深度和知识的沉淀。对比一下街坊老大爷下象棋的热闹和职业棋手比赛时的沉静就知道了。

1.3.2.2 文本 vs. 图形

相对于只有自上而下顺序的文本（包括自然语言文本和编程语言文本），能够朝四个方向扩展的平面图形（如果有三维模型就更好了）更容易让建模人员看出概念之间的联系。例如，图1-9和图1-10的内容，如果没有图形的帮助，通过文本一行一行地构造和阅读模型，人脑的负担非常重。

图1-9 餐饮领域的类图

图1-10 计算器的状态机图，摘自Practical UML Statecharts in C/C++[Samek 2008]

说到这里，又不可避免地要提醒，故意选择文本的形式来表达领域知识，有可能也是一种遮羞布。图1-9和1-10的内容如果用文本表达，可能会得到很多页文本——这就有了理由：因为工作量太大了，所以很多地方无法做深入的思考，可以原谅！

1.3.2.3 自编图形 vs. 标准图形

事实上，纯口头交流甚至纯文本交流是很少见的。除非要交流的问题极其简单或者其他同事对这样的人极其容忍，否则他至少也得随意画几张“草图”来传达自己的意思——自编的图形才是比例最大的存在。

这样的人之所以用自编的图形，往往并不是因为他看出了UML有哪些不足，然后用自己的表示法弥补了这些不足，而是要遮掩背后的一些脓包。

脓包一：利益绑架

项目中，有人画了张自编的图形，然后往往会伴随这样的招呼，“来，我给大家讲讲！”。这意味着项目要依赖于“我”头脑中的隐式知识——要是“我”不给大家“讲讲”，大家就不理解“我”画的图的意思，项目就玩不转了。于是，“我”在团队里的地位就提高了，大家得哄着“我”捧着“我”，领导不敢轻易开掉“我”，“我”提出离职领导还要挽留。这在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现得更明显。

★开发人员让我看他的模型时，如果开口说“我先来给你讲讲”，我都会拦住，“如果还需要你先讲讲，说明你所想的没有体现在模型中”。

脓包二：遮羞

因为符号是“我”自创的，所以这个图的解释权归“我”所有。如果有其他同事质疑图上什么地方画得不对，“我”就有了充分的躲闪空间——“你理解错了，这个图形不是你以为的那个意思。你以为我画的是鹿，其实这是马，在我的规范里面，马就是鹿的意思，鹿就是马的意思”。

如果使用了标准的表示法，例如用UML画了一个状态机图，其他人就有得说了，“好像手册上不是这样说的”，“我看那个书上不是这样说的”，这不就尴尬了嘛。

自编图形未必是看起来十分简陋的白板草图，也有看起来比较精致的。例如，来自某项目的图1-11。

图1-11 自编图形示例

其实，抛弃标准符号和建模工具带来的便利，用绘图工具或幻灯片工具画出这样的图，所花费的时间往往还要更多。但是，有意思的是，有的人画这样的图，还以“敏捷”为理由。

注意，上面说的只是“看起来比较精致”，其实内容还是很粗陋的，仅仅是把一些动词、名词的罗列成一个个形状，各个形状之间的关系基本没有，读者可以把图1-11和图1-9、图1-10对比。

有心的读者可以观察近年来被吹捧为“革命性创造”的领域驱动设计的文章，看看其中所画的图，看看会不会发现上面所批评的情况，简单罗列，无一致性。然而，为了掩盖逻辑上的不足，这些图的作者会把力气下在“美工”方面，因此，伪创新的图有时看起来比科研风格的图更赏心悦目，对外行来说更有吸引力。

1.3.2.4 挑破乱七八糟图的脓包

我们甚至可以“抛开事实（具体领域知识）不谈”，仅从“一致性”这一点入手，就可以挑破这种自编“乱七八糟图”的脓包。

自编“乱七八糟图”的画图者，很可能并没有归纳过各种形状的定义，只是凭感觉随意使用，或者即使归纳了，也不会像标准语言这么严谨，所以，大概率会产生“不一致”的问题。

我们就以图1-11为例。

图1-11中，同样被称为“平台”的东西，有着不同的形状和颜色，如图1-12。

图1-12 图1-11的不一致示例1

我们再来看中间这些方框，如图1-13。

图1-13 图1-11的不一致示例2

先看图1-13的最顶上3个方框，它们形状一样，长度一样，但有的叫“层”，有的叫“模型”，有的叫“队列”，这些概念可不是一个级别的。

（可能的辩解）也许在颜色中暗示？

再来看方框里的命名。最上面4行的命名，基本上都是“名词+动词+名词”结构，例如“消费信贷+统一前置+层”、“额度+管控+模型”，最下面2行的方框，命名是“名词+动词”结构，例如“消费业务+管理”、“流程+控制”。

（可能的辩解）你没脑子吗，自己脑补一个尾巴不行吗，“……模型”、“……层”、“……功能”、“……队列”、“……AI赋能领域驱动设计革命性创新微服务功能模块组件分布式大数据数智化平台”。

还有，名称同样是“模型”，颜色也有多种……

读者可以尝试从“一致性”着手，看看身边的同事画的“乱七八糟图”有没有这方面的问题。

可能有人会问：难道用UML来画就没有这个问题吗？

有的，例如，建模人员故意往用例的圈圈里乱填东西，有的填名词，有的填动词，有的填形容词，但这是违反UML相关的规范或指南的，其他人可以看出问题，批评和纠正。刚才说的情况是没有规范或规范模糊，这两者是不一样的。

用法律类比：精确严谨的法律条文并不能保证没有人违法，但至少大家有共识，什么是违法，什么不是。而另一种情况则可能是，孪生兄弟张三和张四做了同样的事情，张三违法，张四不违法，理由？不知道。

1.3.2.5 基本共识上的沟通

表示法标准并不是随便哪个人拍脑袋定下来，然后毫无道理地强迫大家接受。符号背后往往隐含着我们对某个学科的一些基本共识。

如图1-14，最上一行的积分表示法“∫”，幼儿园小朋友也能画出这样的形状，但其所代表的知识可能需要上到大学才能理解。如果要懂得为什么是这样一个表示法，还需要了解数学史中莱布尼茨、傅立叶等人的贡献。图1-14中间一行的五线谱小豆芽和横线，最下一行UML的小人圈圈和框框，也是如此。

图1-14 表示法背后隐含基本共识

这意味着，学习建模表示法标准并非硬生生把形状记住后照葫芦画瓢就行，还要学习背后的一些建模知识。但是，开发团队成员咬咬牙，花费一些精力跨过这个门槛是值得的，因为一旦有了基本共识，会大大提高沟通的效率和深度。在严谨建模思维的追问之下，有意无意遮掩的脓包也会被强制露出——这也是一些“高手”潜意识里不愿意直面UML的深层原因。

★面对一个棋局，下一步怎么走？在业余棋手看来到处都是正确答案，在职业棋手眼里，值得讨论的选项只有两三种，因为职业棋手针对一些东西形成了共识，大大减少了思考中的浪费。

★有的开发人员的“十年工作经验”实际上是“一年工作经验用了十年”，一直在热热闹闹的民工层次徘徊，没有积累和成长。

不过要注意一点：使用UML沟通仅限于软件组织内部，UML模型不是用来和涉众沟通的！这个道理以及和涉众沟通的技能将在第7章详细叙述。

1.3.3 SysML

UML的另一个成就，就是把“统一建模语言”扩展到了系统工程。INCOSE（国际系统工程协会）和OMG（对象管理组织）以UML为基础，进行系统工程方面的扩展后推出了SysML（Systems Modeling Language，系统建模语言），目的是和UML相似：为了统一系统工程的建模语言。

UML是信息系统的建模语言。“信息系统”的意思是该系统只负责处理信息：信息流进来，经过系统的处理，变成信息流出去，但是，信息系统不能处理物质流和能量流——或者简单说就是能量流，因为物质是能量表现形式之一。

图1-15 信息系统和非信息系统（此图用SysML表达）

SysML可以建模处理能量（物质）流的非信息系统。将来能量（物质）、信息进一步大一统，SysML是可以取代UML的，但目前还不能。

关于系统工程、软件工程、SysML、UML的区别，我用刘慈欣的小说《流浪地球》举个例子。

太阳即将在400年内发生氦闪变成红巨星，人类社会怎么办？

众多科学家经过大量研究，得到一个解决方案：给地球装上发动机，驱动地球飞向比邻星（夭寿啦！正好三体舰队迎面飞来，嘭！）。

******

小说《流浪地球》原文：

地球发动机安装在亚洲和美洲大陆上，因为只有这两个大陆完整坚实的版块结构才能承受发动机对地球巨大的推力。地球发动机共有一万二千台，分布在亚洲和美洲大陆的各个平原上。

……

在六千米处，我们见到了进料口，一车车的大石块倒进那闪着幽幽红光的大洞中，一点声音都没传出来。

……

“重元素聚变是一门很深的学问，现在给你们还讲不明白。你们只需要知道，地球发动机是人类建造的力量最大的机器，比如我们所在在华北794号，全功率运行时能向大地产生一百五十亿吨的推力。”

******

“地球发动机”是一个巨大的系统，横跨多个学科，能源、材料、建筑、物流、人员管理……。

其中用来描述和处理信息的信息系统可能只占其中的一小部分，UML不适合描述“地球发动机”，SysML可以。

通过SysML建模，不断把“地球发动机”分解成各个Block，Block又分为小Block，可能会得到其中一个Block叫“发动机中控系统”，这是一个信息系统。该系统其中一个功能可能是：根据接收到的测量参数值（可能有上万个），计算地球发动机下一步的最佳行动。我用SysML的块定义图画了图1-16，只是简单展示，我也不知道地球发动机应该分成哪些Block。

图1-16 地球发动机的分解（此图用SysML表达）

图1-16中的“发动机中控系统”这个信息系统，就适合用UML来建模。

听起来SysML描述的系统比UML描述的信息系统大，是不是意味着SysML建模的难度更高？

目前来说并非如此。目前使用SysML建模时，更多的是“描述”，例如描述图1-16中“地球发动机”的各个部件及部件之间的关系。至于为什么地球发动机的部件和关系是这样的，这可能是其他各个学科的专家的工作成果。SysML建模人员只需要通过模型如实描述并验证。

我们再来看图1-16中的“发动机中控系统”。即使SysML建模人员已经通过SysML建模严谨地推导出信息系统的责任，包括输入什么信息，输出什么信息，从输入到输出计算的规则是怎样的，也就是说把B-需求都给描述清楚了，“发动机中控系统”这个信息系统的内部部件以及部件之间的关系依然是不确定的，需要“发动机中控系统”的开发人员自己构思和实现——100个团队可能有100个不同的构思。

“地球发动机”的部件以及部件之间的关系，可是其他专家团给出来的，并不需要自己构思。这一点就使得“发动机中控系统”的建模要比“地球发动机”更难。

当然，如果领导只是吩咐一句，做一个“地球发动机”，剩下所有工作都由SysML建模人员来做，那难度可就大了。

我们来看图1-16中的“反应堆”，《流浪地球》原文提到的“重元素聚变”应该属于“反应堆”的责任。我用SysML画了一张活动图，如图1-17。可以看到，这个过程处理的是能量（物质），原料和催化剂进来，变成能量出去（当然，还有废渣）。

图1-17 重元素聚变过程

打问号的地方，例如聚变过程的各个步骤应该怎么进行，催化剂是哪些，需要什么样的反应设备（1000万℃的高温啊！），这些难题都需要各个学科的专家去攻克。和这些难题相比，通过UML建模构思信息系统的内部结构的难度就不算什么了。

信息系统可以看作是人脑的替代。像上面说的“根据接收到的测量参数值（可能有上万个），计算地球发动机下一步的最佳行动”，这个事情人也可以做到，因为计算的方法就是人指定的嘛，只不过人算得很慢很慢，所以用信息系统来做。

也就是说，我们建造信息系统是要把人脑总结出来的各种知识转移到信息系统中，并用它来取代人脑来做计算。信息系统的一切，包括规则如何表达，数据如何组织，各个部分的耦合、内聚等等，都需要我们一个一个构思。

目前，非信息系统的建模还没有“取代人脑”的压力，SysML更多是描述和帮助验证。

SysML最新规范地址：https://github.com/Systems-Modeling/SysML-v2-Release，最新版本是2025年2月发布的。

从目前的信息看，SysML v2有很大的变革，特别是大刀阔斧地清理术语。UML虽然把各种软件建模“方言”统一成“普通话”，但仍然做了一些妥协，留有各种冗余的尾巴。衍生自UML的SysML也不可避免存在冗余的问题。SysML把非必要的术语全部清理（和领域驱动设计圈子热衷造词形成鲜明对比），这是非常值得期待的。

因为UML和SysML两者非常相似，学习了一个相当于学习了另一个。如果你的工作只是开发信息系统，那么学习UML就可以。如果你的工作确实涉及到开发信息系统和非信息系统，可以直接学习SysML。在碰到不好用SysML建模的问题时，再适当引入SysML所没有的UML元素。

一条双赢的路线是：SysML发展到足以覆盖现在的UML后，吞并UML，然后把自己改名为UML——比UML还统一的统一建模语言。商业领域就有类似例子，2005年，SBC电信以160亿美元收购AT&T，然后把自己更名为AT&T。

1.3.4 UML建模工具和文本UML建模

1.3.4.1 UML建模工具的统计

从2000年开始，UMLChina就在网站上提供UML建模工具的统计。最开始是链接到objectsbydesign，我们负责帮objectsbydesign把它的统计文章翻译成中文，现在仍然可以访问，地址为http://www.objectsbydesign.com/tools/modeling_tools_cn.html。

图1-18 objectsbydesign.com网页

图1-19 2000年和objectsbydesign合作的邮件

★Stuart当时为此翻译慷慨地支付了我$1000。现在，翻译一本《分析模式》，估计最终得到的稿酬也比这个多不了多少。

考虑到objectsbydesign.com的统计更新频率较慢以及信息覆盖面不够，2002年，UMLChina开始自行制作UML建模工具一览表，不定期发布。

图1-20是一份以pdf格式保存的2003年6月的一览表，共31页，摘自《非程序员》电子杂志。该文件的下载地址：http://www.umlchina.com/tools/umltools200306.pdf。

图1-20 2003年6月统计的UML工具一览表

图1-20 的文件共列了130款UML建模工具，根据我的记忆，这个一览表上收集的工具最多时达168款。目前，UML发布类似信息的主要渠道改成了UMLChina公众号，http://www.umlchina.com/url/tools.html，如图1-21。

图1-21 UMLChina公众号发布的工具更新统计

★以上统计仅针对涉及UML建模的工具，其他建模表示法也会有相应工具，不在统计范围之内。

★感兴趣的读者可以搜索“国产 MBSE”，看看能搜到多少国产建模工具。

1.3.4.2 本书使用的UML建模工具

本书中的模型图，如果是我为了讲解知识而画的，用的建模工具主要是Enterprise Architect，有的图会用到Rhapsody和MagicDraw。如果是截取其他人提供的模型图，可能还会涉及其他工具。

以上提到的工具仅是我个人的选择，本书不详细评价各款UML建模工具。以上这三款工具目前都是收费的，从常理看来，收费工具的体验比免费工具好。如果您基于各种考虑选择使用其他的建模工具，甚至是在纸上手绘，本书的绝大部分建模知识依然适用。

1.3.4.3 文本UML建模

近年来，文本建模（Textual Modeling，营销用语有Diagrams as Code等）工具是UML工具市场中增长最快的细分领域。

如果把“从文本生成UML模型”都可以看做文本建模，那么上个世纪的Rational Rose和I-Logix Rhapsody都已经可以把Ada、C++代码转成UML类图。我们把定义缩窄，把文本建模定义为“以获得A、B、C工作流UML模型为目的而提供文本”。

OMG为UML定义了元模型、建模元素的语义和表示法，还定义了XMI（XML Metadata Interchange，XML元数据交换）标准用于各个工具厂商的不同建模工具之间的模型数据交换。这些标准一直沿用至今。

OMG曾在2004年发布过一个“UML Human-Usable Textual Notation”（https://www.omg.org/spec/HUTN/1.0/PDF），简称HUTN，试图提供统一的文本建模标准，但该规范未能继续下去。

以文本方式建模的非官方尝试，在这之前已经开始了。2002年，DiomidisSpinellis发布了UMLGraph（https://www.spinellis.gr/umlgraph/index.html），随后又有TextUML（始于2006年，https://abstratt.github.io/textuml/）、WebSequenceDiagrams（始于2007年，https://websequencediagrams.com）等。

★DiomidisSpinellis的书在国内有中译本的有《代码阅读》、《代码质量》。

★始于2001年的UMLet（https://www.umlet.com）比较难以归类。

目前最流行的应该是PlantUML（始于2009年，https://plantuml.com/），它是当前各个主流AI生成UML内容的缺省表示。其他类似文本建模工具还有：yUML、Mermaid、MetaUML、nomnoml、dotuml、ZenUML等。

现有的文本建模工具，绝大多数是基于Graphviz（始于1991年，https://graphviz.org）和DOT 语言的二次开发。

文本建模的优点

文本建模能够获得推行，主要原因是它降低了获得的门槛。

（1）web访问

比起类似于Enterprise Architect等点击、选择、拖动图形元素的建模界面，实现编辑文本然后渲染成图形的建模界面实现起来相当简单，何况有了Graphviz。

构造一款基于web的“建模工具”难度降低，使得文本建模工具普遍提供在线编辑器，这对于偶尔需要建模的开发人员来说十分便利，他们不需要额外安装软件，目前还都是免费的！

（2）和程序员常用的工具集成

文本建模时，模型的内容相当于另一门语言的代码，在编码环境、版本控制工具上的处理是一样的。这也使得文本建模在程序员群体中的曝光率大大增加。

★以上只是说“容易获得”，并没有说“容易使用”。比起Enterprise Architect等工具“所见即所得”的建模操作，编辑文字并不利于大脑的思考。这一点，在“1.3.2.2 文本 vs. 图形”中已提到。

文本建模当前存在的问题

（1）绘图而不是建模

目前的文本建模工具所做的其实是“绘图”：建模人员输入文本，工具把文本渲染成形状符合UML规范要求的图形，各张图（或各段文本）之间是独立的。

这样做实际上并不算建模。就像机械制图中的主视图、俯视图、侧视图都是描述同一个六角螺母一样，建模时，图只是从某个视角对某些模型元素的观察，不同图上的内容是有对应关系的。

注意，上面只是说目前文本建模工具存在这个问题，并没有说这个问题是由文本建模引起的。如果工具没有封装UML元模型的逻辑，只有图形处理的逻辑，都可能存在类似问题。

也就是说，界面是文本输入还是点击拖拽，并不是判断一个工具本质上是绘图工具还是建模工具的标准。A工具可能只有文本输入，文本输出，也不渲染图形，但它有可能是建模工具，因为它封装了UML元模型的逻辑；反之，B工具界面操作方便，图形在保持UML规范所要求形状的同时，用尽美工手段打磨得十分高大上，但它有可能仅仅是一款绘图工具。

如果本质上是当成图形来处理，还时不时会出现另一个问题：复杂图形（例如复杂状态机）的处理错误：不提供支持，或者无法渲染，或者得到的图形看起来违反语义。

（2）不统一

各个文本建模工具都有自己的语法，把PlantUML的脚本放到Mermaid工具中渲染，是得不到图形的。难道要再搞一个像XMI一样的交换标准？

过度吹捧文本建模的危险

上面讨论了文本建模当前的优缺点，建模人员可以在适合的场合下使用文本建模。如果有人（例如伪创新圈子）过度吹捧某个文本建模工具“敏捷”，很有可能是把它当成遮羞布了。学习了本书的内容后，你可以用《软件方法》提供的照妖镜去照一照他产出的各种工件，到处都是脓包的可能性非常大。

文本建模的将来

新版本的SysML同时支持文本表示法和图形表示法，完全可以覆盖现有的各种“文本建模”，而且足够严谨。这是一个努力的方向，即使SysML v2没有达到统一的目的，SysML v3再努力。