很多开发者可能将软件工程的UML模型仅作为“考试题目”。其实这些理论本身都是其他领域fork出来的字系统，尤其是咨询与制造领域，还是值得看一下的。

背景

软件工程的常见模型

即使上述图在软件理论中常见，但是网上脱离理论的真实案例讨论似乎不多，本文加以介绍真实场景。

软件设计本应该是类似写作的思考工作，写作有两种方法，一种是先提纲后详细，另一种是想到哪写到哪。然而软件工程是教条主义，它把人当作流水线中的可替换元件，它要求设计中必须满足抽象到具体的流程，在你拥有相关经验的情况下是可以的。

常见的图有哪些

• 高阶思路分层类：

  • 场景用例图
  • MindMap/WBS(Work breakdown structure)
  • 原型图（Prototype）

• 落地方案与设计阶段：比如Controller级别的API设计

  • UML活动图：伪代码级别的细节设计
  • UML序列图/泳道图/通讯图：多个服务间的交互细节
  • UML状态机图：建议直接枚举为数字逻辑；大部分场景建议用BPM流程替代UML状态机

• 大数据与运营

  • 数据流向图：DFD/N2图（N2 Chart）
  • ER图：设计数据的概念模型（后续还有逻辑、物理设计）

• 物理部署：部署图，这里也涉及到az/dc/firewall等配置

• PERT图：设计完成后，干活的安排与计划。软件BOM清单也可能使用。

其他

• 不实用的：UML的类图/对象图/组件图，并不是反对这些图，而是这些图应该是生成的，而不是手绘的
• 甘特图：一般是落地为报表/汇报，不推荐实时录入

有哪些免费的绘图工具

• 基于DSL编码的方案：PlantUML/Kroki等方案
• 基于GUI编辑的：draw.io，Excel

图详细介绍

类图

以下为log4j，slf4j，log4j2，logback间的关系。在传统的Controller项目可能用不上，给模版后，改下模版开始搬砖就可以。在更高阶的设计中可能需要。

即使开发人员有很多年的Java经验，其抽象能力也可能非常弱----通常现象就是一个BaseService里面塞数千行代码。

如果你是高级设计师，那么在让初级开发人员编码时，不妨暂时禁止其开发Base服务，等到代码定型后转测前再抽出时间做抽象。

用例图（高阶）

用例图在高阶设计时使用，这里重要的难题给“本体（ontology）”下定义。它取决于市场调研或者战略分析的目标决定，甚至领导拍脑袋决定，比如需要知道它的用户是谁，做了什么，需要什么。

“本体”一般分为两种思考方式

• 内涵：一般指抽象，比如边界，状态，方向等。而不是“规格约束（spec）”，比如“它必须有4个轮子”，“它必须用Docker构建”
• 外延：一般指穷举的能力，辅助你去通过MECE等方法去枚举场景。

在思考的过程中需要逻辑链的广度遍历与碰撞（比如他人的质疑），它必然是从“发散”到“层化”的过程，最终用例图会转化为MindMap/WBS。

用例图的媒介并不重要，我个人的习惯是跟第一个带我的人学的，他被日企Fanuc的Excel模版给固化了，因此我的习惯也被第一个人给固化了，全部文档均用Excel整理还更快。

DFD图（比如大数据领域）

这个图主要用于大数据场景（APM/运营/时序/知识管理等）

含义大致如下

• 外部实体：自然人或者法人。长方形
• 加工：动作，比如验收，合并，flink算子任务等，左右必须都有节点。圆形。可以分解为子加工
• 线条：数据流，被加工的物体，数据结构，比如订单/书籍。数据流是数据从信息系统的一个部分移动到另一个部分的路径
• 数据库：数据存储，比如文件/数据库

这里的设计方法对大数据的项目很有作用，比较类似flink里的算子。

注意事项：

• 总体上不实用，实际上商用大数据的低代码工具更偏好使用类似PERT/Serverless的流程图，比如Airflow
• 没有明确的时间描述能力（比如被动综合/机械时间），而只有数据的流向
• 可以将“数据库”手绘为明确的ER图，但是“导出SQL”的功能会丢失。

此外还有N2图，它和DFD类似。

ER图（数据库设计）

它主要可以通过概念设计、逻辑设计和物理设计实现。在真实项目中，可能看了个大概需求，就上来直接设计SQL表了（即物理设计），这时问题来了，抽象与具体哪个更优先？

在软件理论中，要求设计数据库时一般从抽象到具体；而在事实搬砖中不一定要符合教条，比如大数据/AI场景中，聚合多个野生的实体数据源，经过清洗抽象最终整理为维度数据的场景，就是自下而上的。

ER图设计阶段也需要完成索引的设计。

ER图的局限

ER图只能承载“元组运算/域运算”的关系演算，工程上有如下缺点

• 难以承载“表对表同步”这种常见流程（即数据血缘）的绘制与分析，但是这两张表一般是有时间关系的。
• 难以承载“微服务场景”的跨表关联问题，这里我们是用Navicat的颜色区分的。
• 需要枚举所有用例场景后才能设计，否则一定会重构

参考阅读：关系式模型的实质

高阶设计的输出流程

下面是个人在通用软件的主要交付件介绍，大部分项目并不需要拼天赋，而是体力活，做好分类和枚举就可以。

尤其注意的是，千万不要认为“高阶设计”是指单纯地先抽象接口与类图，再写实现类。高阶只是指对经验世界的抽象（或者投影），一定需要先经验再理性，先实现后抽象，以防加太高的思考杠杆（比如过度设计）。除非你的设计是“重复劳动”。

参考阅读：某软硬件架构师的一些思考

管理类型图表

CMMI成熟度模型

这种模型核心就是判断你的工作是否是可复制的“泰勒化”，它永远只在高阶的PPT汇报中。小公司用不上，大公司推广落地到小组也阻力重重。而在真实搬砖小组中，主要依靠“语境”方案。

目前业界仍然缺少缺少较好的IT工具。

项目管理(PERT图)

PERT图本质是一个有向图，可以帮你估算复杂且需要多人共同完成的动作依赖关系，在复杂的部署变更场景中可能使用。这个在LeetCode中是Hard的Graph BFS问题。在半导体设计的STA阶段也需要使用。

比如我在深航的宣传册里，发现航空领域从零开始也是这样

有一天，没有事先通知，港中旅派了一个人，是留英回国，在英国大不列颠航空公司工作的资深工程师，到我办公室，说来了解深航筹建进展，问我这一段干什么？我把这张网络图给他看了。他说明白了，说在英美搞大工程都要这样，叫PERT（Program Evaluation and Review Technique），这样很好。回去向港中旅汇报了，误会消除。

再举例如下，假如我需要从零部署一个“Linux工作站”，那么变更动作分解可以参考如下

注意此图中

• 节点含义是“关键事件/任务/活动”，即作为一个function（即动作，需要名称，输入与输出）
• 有向线条表示“时间消耗”，而不要把步骤细节放线条中
• 它是一种过程式的流程，更加类似ansible，而不是类似 terraform 来描述每个阶段希望达到的状态

再比如我要从零做一个中低规模的项目

此绘图流程要求项目被充分地分解，类似泰勒所谓的“标准化原理“，分析成本是很高的。真实工具中（比如微软AzureDevOps）均不支持这种图的遍历方案，大部分还是人工分解为树状结构。

有的领导习惯让你完成看似简单，实际实施过程中一堆坑的项目，这时就考虑用PERT来分解。

这个分解依赖关系的能力是后天学习的，一定需要掌握。日常生活中使用Excel/PPT绘图即可，有强迫症可以使用PlantUML，但是效率的确不高

项目管理（gantt图）

这种管理手段在大型项目中可能存在，它本质上也是报表呈现的作用。

但是对于10人左右的小组的日常管理，基本还没见过能真正用起来的，因为估算/倒排能精确到周就不错了，事实上大家还是心安理得的照着人月神话的反例搞。

附录

软件工程的形而上

软件工程通过降低偶然性换取确定性，是泰勒式的教条主义。如果需要更高阶的设计思路，可以参考“数码物（Digital Objects）/技术物”的概念，而非经典“自然物”的概念。

参考书籍

• 《论数码物的存在》
• 《存在与时间》
• 《递归与偶然》
• 管理类的可以参考《PMBOK》或者《NASA系统工程》