大日志文件拆分实战：从split命令到自动化轮转策略
2026/10/14 4:06:45
UML 是"一类语言"，重点是它有什么、能干什么，不是怎么画。但考试的重点在另一头。上午选择题爱考 UML 的分类口径（哪些是结构事物、图分几类），下午案例题几乎年年有一道 UML 补全。教材那两页纸撑不起这两个场景，所以下面按做题的口径重排了一遍。
四层骨架：事物、关系、图、视图
事物分四类，其中结构事物最多，也最好背混：
| 事物类别 | 数量 | 包含 | 一句话 |
|---|---|---|---|
| 结构事物 | 8 | 类、接口、协作、用例、主动类、构件、制品、结点 | 模型里最静态的名词部分 |
| 行为事物 | 3 | 交互、状态机、活动 | 描述动作和变化过程 |
| 分组事物 | 1 | 包 | 把上面的东西装进盒子 |
| 注释事物 | 1 | 注解 | 给模型加解释说明 |
结构事物那八个缩成一句口诀：“类接协用，主构制结”——类、接口、协作、用例，主动类、构件、制品、结点。前四个偏概念层，后四个偏物理和运行层。行为事物只有三个，用"交互触发状态机，状态机里跑活动"串一下就记住了。
关系教材只写了四种：依赖、关联、泛化、实现。这里先记下来，第四节会解释为什么做题时它变成了六种。
图这块有个坑。教材 2.6.2 列的是 UML 2.0 的 13 种图，但按 UML 2 的官方规范（对应国际标准 ISO/IEC 19505），图是 7 个结构图加 7 个行为图共 14 种，差的那一个是外廓图（profile diagram），它属于扩展机制，教材没单列。真遇到"UML 有几种图"这类题，先看选项给的是 13 还是 14，再判断它算没算外廓图。
| 类别 | 包含的图 | 数量 |
|---|---|---|
| 结构图（静态） | 类图、对象图、包图、构件图、组合结构图、部署图 | 6（算上外廓图是 7） |
| 行为图（动态） | 用例图、活动图、状态图，加交互四图：序列图、通信图、交互概览图、计时图 | 7 |
交互图是行为图下面的子类，四种：序列图、通信图、交互概览图、计时图。选择题爱出"下列不属于交互图的是"，干扰项基本是活动图或状态图。顺带一提，通信图在 UML 1.x 里叫协作图，状态图现在规范叫状态机图，看到旧名别发懵。
视图这块有个跨章呼应。教材给的 UML 五种视图是用例视图、逻辑视图、进程视图、实现视图、部署视图——这五个跟第1章讲的 4+1 视图模型是同一套东西：逻辑、进程、实现、部署是那个"4"，用例视图是那个"+1"。第1章站在架构描述角度讲它，第2章站在建模语言角度又列了一遍。两边合起来看，4+1 就不再是五个要死背的名词，而是"用哪些图去填哪个视图"：
| 视图 | 关注点 | 主要由哪些图承载 |
|---|---|---|
| 用例视图（+1） | 系统对外提供什么功能 | 用例图 |
| 逻辑视图 | 功能怎么组织成类和对象 | 类图、对象图、状态图、交互图 |
| 进程视图 | 并发、同步、通信 | 活动图、交互图（含计时图） |
| 实现视图 | 代码和构件的组织 | 构件图、包图 |
| 部署视图 | 软件跑在哪些硬件上 | 部署图 |
用例图：include 和 extend 的箭头方向最容易画反
用例图描述一组用例、参与者及它们之间的关系。参与者是系统外部的东西——人、组织、别的系统，还有定时器（定时任务也是参与者，这条常被漏掉）。
第一种常见错误是把系统内部模块画成参与者。判据只有一条：它在不在系统边界外面。数据库、消息中间件、缓存都是内部件，不算参与者。第二种错误是用例粒度失控。判据是"这个用例有没有给参与者一个可观察的结果"——"用户登录"有价值，"点击登录按钮"只是实现步骤，不是用例。
三种关系才是命题重点：
| 关系 | 什么时候用 | 箭头方向 | 题干里的判读词 |
|---|---|---|---|
| 包含 include | 多个用例抽出公共行为，基础用例一定会执行它 | 基础用例 → 被包含用例 | 必然执行、公共步骤 |
| 扩展 extend | 基本用例在特定条件下额外触发，可能不发生 | 扩展用例 → 基本用例 | 条件触发、可选分支 |
| 泛化 generalization | 多个用例结构和行为相似，抽象出父用例 | 子用例 → 父用例 | 特殊与一般 |
方向这块我绕了挺久，后来想通了一句话：箭头跟依赖走，谁依赖谁就指向谁。include 是基础用例离了被包含用例就不完整，所以基础用例依赖它，箭头指过去；extend 是扩展用例离了基本用例没有依附对象，所以扩展用例依赖基本用例，箭头指回来。两者方向恰好相反，出题人就爱在这儿做手脚。
还有一条常被忽略的边界规则：用例与用例之间只有这三种关系；参与者与用例之间只有关联；参与者与参与者之间只有泛化。选项里出现"用例与参与者是包含关系"直接排除。
类图：教材写四种关系，考题却是六种
教材 2.6.2 说 UML 的关系是依赖、关联、泛化、实现四种，但类图题里常见的是六种，多出来聚合和组合。这不是教材写漏了——在 UML 规范里，聚合和组合是关联的两种特殊形式，是关联在"整体-部分"语义上的细化。教材讲的是规范层面的四种，考试考的是类图层面的六种。
| 关系 | 语义 | 图示 | 生命周期 | 例子 |
|---|---|---|---|---|
| 依赖 | 一个事物变化影响另一个 | 虚线箭头 | 临时 | 方法参数里用到另一个类 |
| 关联 | 对象之间的长期连接 | 实线 | 无关 | 成员变量持有引用 |
| 聚合 | 整体-部分，部分可独立存在 | 空心菱形接实线，菱形在整体侧 | 不同 | 部门与员工 |
| 组合 | 整体-部分，部分不可独立存在 | 实心菱形接实线，菱形在整体侧 | 相同 | 订单与订单项 |
| 泛化 | 特殊与一般，即继承 | 实线加空心三角，三角指向父类 | — | 在线支付继承支付 |
| 实现 | 类与接口 | 虚线加空心三角，三角指向接口 | — | 订单服务实现支付接口 |
聚合和组合是钉子户，判据只有一句：整体没了，部分还能不能单独存在。员工脱离部门还能存在（调岗就是），所以是聚合；订单项脱离订单没有意义，所以是组合。别靠语感——"汽车与轮胎"看着像组合，但轮胎能拆下来装到别的车上，教材和多数答案按聚合算。
多重度也常考。1是恰好一个，0..1是零到一个，*或0..*是任意多个，1..*是至少一个。第一个数字是下界，"…"后面是上界，*代表无上界。
口诀给两条：关系强弱顺序"依赖最松、关联结实、聚合空心、组合实心、泛化继承、实现接口"；聚合组合判别"空心能独立，实心绑生死"。
时序图：案例题最高频，考的是消息不是流程
时序图也叫序列图、顺序图，是交互图的一种，强调消息的时间顺序。三个构件：生命线（对象下面那条竖虚线）、消息（对象之间横向的箭头）、激活条（生命线上那段窄矩形，表示正在执行）。
| 消息类型 | 图形 | 含义 |
|---|---|---|
| 同步消息 | 实心三角箭头的实线 | 发出后阻塞等待返回 |
| 异步消息 | 开放箭头的实线 | 发出后不等，继续往下走 |
| 返回消息 | 虚线箭头 | 从被调用方返回 |
| 自消息 | 指回自身的箭头 | 对象调用自己的方法 |
激活条不是装饰。同步调用的激活条是连续的，因为调用方在阻塞等；异步调用发出后激活条就断开了。给你四张图挑"正确表达同步调用"的那张，靠的就是这一点。
UML 2 还引入了组合片段表达分支和循环，案例题偶尔出现：
| 片段 | 等价的程序结构 |
|---|---|
| alt | if / else，多选一，走且只走一个分支 |
| opt | 单条件 if，可能整个不执行 |
| loop | 循环 |
| par | 并行执行 |
最常丢分的地方不是不会画，而是把业务流程画进去了。时序图画的是对象之间传递的消息，不是"用户点按钮→系统保存→返回成功"这种业务步骤。看到自己图上的消息名叫"填写表单"“点击提交”，基本可以判定画成了活动图。
三张图怎么分工，各自怎么下嘴
| 维度 | 用例图 | 类图 | 时序图 |
|---|---|---|---|
| 回答的问题 | 系统对外做什么 | 系统内部有什么 | 对象之间谁先发给谁 |
| 主要元素 | 参与者、用例、三种关系 | 类、属性、操作、六种关系、多重度 | 生命线、消息、激活条 |
| 上午选择题 | 三种关系辨析 | 关系强弱排序、聚合组合 | 消息类型、组合片段 |
| 下午案例题 | 补参与者、补用例、补关系 | 补类名、补关系 | 补对象名、补消息名、补消息序号 |
| 论文可用性 | 可作需求建模的论据 | 可作领域建模的论据 | 可作接口与调用链论证的论据 |
考频上我自己的判断：案例题里时序图出现最密，类图次之，用例图在上午题中更活跃。用例图的 include/extend/泛化、类图的聚合组合、时序图的消息类型，这三组是本块性价比最高的地方，练到条件反射就能拿分。
论文这块要泼点冷水：UML 本身不适合当论文主题，“论 UML 建模"这类题目基本不会出。但它是很好用的论据素材。写需求工程、写架构设计、写微服务拆分，正文里带一句"用用例图确认系统边界、用类图固化领域模型、用时序图验证跨服务调用链”，能撑住"我确实做过设计"这个印象。别写"我们用 UML 画了全套 14 种图"，那是自曝没干过。
第2章到这儿才算真正收尾（2.6 的建模语言这块补上了）。下一篇回到第3章，讲 TPS、MIS、DSS、专家系统、OAS、ERP 这几个典型信息系统怎么区分——那章的考点是给你一段业务描述，判断它属于哪一类系统。