ELEC5620 Week 07 行为建模讲课总结

Posted on 2026-11-03 In Course Notes , ELEC5620 Word count in article: 5.9k Reading time ≈ 21 mins.

ELEC5620 Week 07 讲课总结：UML 因果模型、主动与被动对象、RTC 语义与优先级反转、同步与异步通信；动作六类；活动图、顺序图与组合片段、通信图、交互概览图；状态机的事件、动作顺序、守卫、junction 与 choice、层次与正交区域；健康与理财 agent 例子，Tutorial 7 与 Lab 7。

ELEC5620 Week 07 讲课总结：Modelling Behavior

课程：ELEC5620 — Model Based Software Engineering，Semester 2 2026 讲师：Dong Yuan 来源：讲义 PDF 6 Modeling Behavior.pdf（57 页）+ ELEC5620-TUT-07.pdf（50 页）+ ELEC5620-Lab-Note-7.pdf（1 页）。本周无转录稿。

本周覆盖： 1. 基本行为概念：因果模型、主动/被动对象、RTC 语义、同步/异步通信 2. Actions（六类） 3. Activities：活动图记号、泳道 4. Interactions：顺序图、通信图、交互概览图 5. State Machines：事件、动作顺序、守卫、伪状态、层次与正交 6. Agentic 例子（智能健康 agent、智能理财 agent）+ Tutorial 7 + Lab 7

期末考是 modeling-based（见 Week 01），本周的三种行为图是最可能被要求“给定场景画图”的内容，务必会画。

相关笔记：Week 06 复杂结构｜Stage 1 评分标准

一、基本行为概念

1.1 UML 的因果模型（事情是怎么发生的）

离散事件驱动的计算模型：一个相互通信的对象网络
所有行为都源于对象（All behaviours stem from objects）
UML 既描述单个对象的行为（如对象内部的状态机 s1→s2），也描述对象间（系统）行为（对象之间的消息交互）

事情如何发生：

一个动作由一个对象执行
动作可能改变一个或多个变量或槽的内容
如果是通信（消息）动作，它可能：调用另一个对象的操作，或向另一个对象发送信号
然后执行后继动作——由控制流或数据流决定

1.2 UML 2 运行时语义的分层

┌───────────── Activities │ Interactions │ State Machines │ ... ─────────────┐
│                     Behavioral Semantic Base                                │
│        Actions          Flow-Based Behavior Semantics                       │
├─────────────────────────────────────────────────────────────────────────────┤
│   Object Existence        Inter-object Comms                                │
│                     Structural Semantic Base (Objects)                      │
└─────────────────────────────────────────────────────────────────────────────┘

所有高层行为形式（活动、交互、状态机）都建立在动作之上，而动作建立在对象之上。

1.3 主动对象 vs 被动对象

Active object：一旦被创建就开始执行其分类器行为，直到行为完成或被外部对象终止才停止。它在何时响应其他对象发来的消息，完全由它自己的行为规格决定。记号：类框左右两边画双竖线。

	Passive object	Active object
何时响应	每当其操作（或接收）被调用时	只在执行 “receive” 动作时
并发	调用可能并发 ⇒ 可能冲突！	并发运行；消息先进消息队列，按调度策略选择事件
例子	`obj:C` 被 a1 调 `setA(1)`、被 a2 调 `getA()` 同时发生	`active:A` 的队列里有 `reqA`、`reqB`，一次处理一个

1.4 Run-To-Completion（RTC）语义（重点）

两次 “receive” 动作之间到达的消息都被排队，只在下一次 receive 时才考虑处理。 - 简单的“一次只做一件事”方法 - 避免并发冲突

RTC 在 agentic 软件中（讲义例子）：agent 从 LLM 收到一个计划，然后：

验证提议的工具动作
记录工具请求 ID
安排异步工具执行
进入 WaitingForTool 状态

问：在这些更新过程中用户发送了 Cancel。如果取消在 agent 状态更新到一半时被处理，会发生什么？

解答思路：可能出现不一致状态——例如工具请求已经发出、但请求 ID 还没记录，取消后无法撤回那个工具调用；或者状态被置为 Cancelled 后又被后续步骤改成 WaitingForTool。RTC 保证 Cancel 被排队，等这一轮反应完整结束（状态一致地进入 WaitingForTool）后再处理，此时 agent 知道要取消哪个请求。

讲义列出的其他设计决策：

保持反应短小（keep reactions short）——RTC 期间不能响应其他消息，长反应会阻塞
把 LLM 输出当作需要验证的输入（treat LLM output as input to validate）
定义边界（define the boundary）——哪些步骤属于一次原子反应

1.5 RTC 的问题：优先级反转

消息优先级：实时系统中，消息可能有不同优先级，高优先级事件需要优先处理（甚至打断低优先级消息的处理）
Priority inversion（优先级反转）：高优先级消息不得不等待低优先级消息的情况
RTC 容易产生优先级反转——但仅限于高、低优先级事件由同一个对象处理的情况（而不是整个系统）
如果高优先级事件到达另一个准备好接收它的主动对象，那么其他主动对象对低优先级事件的处理可以被打断：Active1 处理 lo 时被挂起，Active2 处理 hi

1.6 UML 通信类型

	Synchronous（call and wait）	Asynchronous（send and continue）
形式	同步调用操作	向 reception 发送信号；异步调用操作（丢弃任何回复）
发送方	等待方法执行完、收到 reply	发送后立即继续
顺序图记号	实线 + 实心箭头；返回为虚线	实线 + 开放箭头

二、为什么要对 agent 的行为建模

“帮我做一个能安排就医的智能健康 agent”——这句话留下了大量未指定的行为：

病历数据不可用或过期时怎么办？
预约进行中用户取消怎么办？
agent 怎么区分预约失败和预约成功但响应丢失？
较旧的症状摘要比较新的晚处理完怎么办？

模型给开发者和编码 agent 一个共享的地方，在这些问题变成不一致的代码之前解决它们。 建模工作量应与不确定性成正比（Keep the modeling effort proportional to the uncertainty）。

三、Actions（动作）

Action：一个命名元素，表示活动中的单个原子步骤，在该活动中不再分解。 Activity：由动作组成的行为。记号：圆角矩形，名字通常是动词或动作名词。

用途：建模细粒度的行为现象，操作和访问 UML 实体（对象、链接、属性、操作），如 create link、write attribute、destroy object。UML 标准定义了：一组动作及其语义；把动作组合成更复杂行为的方法。

类别	例子
Communication actions	send、call、receive
Object actions	create、destroy、reclassify、start
Link actions	create、destroy、read、write
Structural feature actions	read、write、clear
Variable actions	read、write、clear
Exception actions	interrupt、error

四、Activities（活动图）

4.1 定义

Activity：参数化的行为，表示为动作的协调流；包含活动节点（action、object、control），由活动边连接。

4.2 讲义例子：Order Processing

flowchart LR
    I([order: input param]) --> R[Receive order] --> F[Fill order] --> S[Ship order] --> C[Close order]
    R --> SI[Send invoice] --> INV[/Invoice/] --> MP[Make payment] --> AP[Accept payment] --> C
    X>cancel request] -.interruptible region.-> CO[Cancel order]

契约：«precondition» Order entered、«postcondition» Order complete
可中断区域（Interruptible Region）：在区域内任何时候收到 cancel request 就跳到 Cancel order
输入参数：order

4.3 基本记号

元素	记号	含义
Activity / Action	圆角矩形	一组动作 / 一个任务
Control/Data Flow	箭头	执行顺序 / 对象流
Initial Node	实心圆	开始
Activity Final	牛眼（圆中实心圆）	终止整个活动的所有流
Flow Final	圆中叉	只终止这一条流
Decision / Choice	菱形，一入多出	带守卫，只走一条
Merge	菱形，多入一出	合并不同的决策路径
Fork	粗横线，一入多出	分成并行流
Join	粗横线，多入一出	并行流汇合（等全部到达）
Object Node	矩形（可含状态 `[state]`）	对象
Pin	动作边上的小方块	动作的输入/输出对象

Activity final vs flow final 是常考易错点：前者结束整个活动（包括其他并行分支），后者只结束到达它的那条分支。

4.4 泳道（Activity Partitioning）

活动分区：把具有共同特征的动作分组
通常对应组织单元或业务参与者
分区准则由建模者决定，可以多维：讲义例子横向分 Sydney / Newcastle，纵向分 Company（OrderDepartment、Accounting）/ Customer

4.5 Agentic 例子：智能健康 agent 预约（活动图）

泳道：Patient / Agent / Scheduling System

flowchart TD
    subgraph Patient
        P1[Request appointment]
        P2[Select preferred time slot]
    end
    subgraph Agent
        A1[Analyze symptoms]
        A2[Suggest self-care advice]
        A3[Retrieve doctor availability]
        A4[Present options to patient]
        A5[Confirm booking with doctor system]
        A6[Notify patient]
    end
    subgraph SchedulingSystem[Scheduling System]
        S1[Return available slots]
        S2[Send confirmation]
    end
    P1 --> A1 --> D{severity}
    D -- if mild --> A2
    D -- if need doctor --> A3 --> S1 --> A4 --> P2 --> A5 --> S2 --> A6

五、Interactions（交互）

5.1 概念

交互关注协作实例之间通过消息的通信
需要事先定义协作结构作为交互的上下文（Week 6 的协作/角色就是这个上下文）
三种具体记号：顺序图、通信图、交互概览图

5.2 顺序图

顺序图捕获消息从一个对象到另一个对象的时间顺序。

元素	说明
Interaction Frame	`sd ATM-transaction` 外框
Lifeline	一个对象或一个 part；顶部方框 + 向下的虚线
Message	从发送者到接收者的箭头；垂直位置表示顺序
Interaction Occurrence	`ref CheckPin`：引用另一张图里定义的交互
Combined (in-line) Fragment	`alt [chk = OK] … [else] …`

ATM 例子：

sequenceDiagram
    participant client
    participant atm
    participant dbase
    client->>atm: insertCard
    Note over client,dbase: ref CheckPin
    alt chk = OK
        Note over client,dbase: ref DoTransaction
    else
        atm->>client: error("badPIN")
    end

其中 sd CheckPin：atm → client: askForPIN；client → atm: data(PIN)；atm → dbase: check(PIN)；dbase → atm: result(chk)；atm → client: result(chk)。

5.3 通信图

用带序号的消息显示对象之间的交互；强调结构关系而非时间轴
例：RedundantSystem 中 client --1: query--> arbiter --2a/2b: get--> backup1 / backup2（2a、2b 表示并发）

	顺序图	通信图
强调	时间顺序	对象之间的链接结构
顺序表示	垂直位置	消息序号（1、2a、2b…）

5.4 交互概览图

提供控制流的概览，流的节点是交互（ref Authorization、内联的 sd 片段、ref DoMore）
包含初始节点、流终止、活动终止、决策、合并、fork、join 节点——即“活动图的外壳 + 交互作为节点”

5.5 Agentic 例子：智能健康 agent 预约（顺序图）

sequenceDiagram
    participant patient
    participant agent as agent: booking
    participant system as system: booking
    patient->>agent: Provide symptoms & request
    agent->>agent: Analyze symptoms
    alt chk = need doctor
        Note over patient,system: ref Make booking
    else chk = mild
        agent-->>patient: Provide self-care advice
    end

sd Make booking：agent → system: Request appointment / available slots；system → agent: Return slots；agent → patient: Present slots；patient → agent: Select slot；agent → system: Confirm booking；system → agent: Send Confirmation；agent → patient: Notify patient。

六、State Machines（状态机）

6.1 事件

状态图通过有限状态转移展示设计系统某部分的离散行为；用于描述事件驱动的行为
Event = 系统中瞬时的状态变化：
- message event：对象收到操作调用或信号
- change event：系统配置变化（如 when(temp > 30)）
- time event：在指定时间发生（如 after(1sec)）
Event occurrence = 事件的实例，发生在某个时刻，没有持续时间

6.2 基本记号

元素	记号
Initial pseudostate	实心圆
State	圆角矩形（如 `Ready`）
Transition	箭头，标签 `trigger [guard] / behavior`（如 `stop / ctr := 0`）
Final state	牛眼

6.3 Entry / Exit 动作与执行顺序

entry/ lamp.on(); exit/ lamp.off(); —— 一种动态断言机制：只要处于 LampOn，灯就一定亮
顺序规则：exit 动作在转移动作之前，entry 动作在转移动作之后

讲义例子：LampOn { entry/lamp.on(); exit/printf("exiting"); }，LampOff { entry/lamp.off(); exit/printf("exiting"); }，转移 LampOn --off/printf("to off")--> LampOff，以及 LampOff 上的自转移 off/printf("needless")。

情况	动作序列
LampOn 收到 off	`printf("exiting")` → `printf("to off")` → `lamp.off()`
LampOff 再收到 off（外部自转移）	`printf("exiting")` → `printf("needless")` → `lamp.off()`

自转移也会先退出再进入，所以 exit 和 entry 都会执行。

6.4 守卫

转移的条件执行；守卫是布尔谓词，必须无副作用
例：Selling 状态收到 bid：[value < 100]/reject → Unhappy；[value >= 200]/sell → Happy；[(value >= 100) & (value < 200)]/sell → Unhappy
守卫应互斥且完备，否则可能出现多个转移同时使能或没有转移可走

6.5 Junction vs Choice（常考）

	Junction（静态条件分支）	Choice（动态条件分支）
记号	实心小圆点	空心菱形
守卫何时求值	在转移被执行之前全部求值	到达 choice 点时才求值
用途	只是画决策树的图形捷径	守卫可以依赖转移前半段动作计算出的结果
例子	`bid` 后按 `value` 分支	`bid / gain := calculatePotentialGain(value)` 之后按 `gain` 分支

判断：守卫用到的变量是不是在这条转移的前半段才被计算出来？ 是 → 必须用 choice。

6.6 层次状态机

逐级应对复杂度：状态可以分解为子状态机。

stateDiagram-v2
    [*] --> LampOff
    LampOff --> LampOn : on/
    LampOn --> LampOff : off/
    LampOff --> LampFlashing : flash/
    state LampFlashing {
        [*] --> FlashOn
        FlashOn --> FlashOff : 1sec/
        FlashOff --> FlashOn : 1sec/
    }
    LampFlashing --> LampOn : on/
    LampFlashing --> LampOff : off/

LampOff { entry/lamp.off() }，LampOn { entry/lamp.on() }，FlashOn { entry/lamp.on() }，FlashOff { entry/lamp.off() }
Group transition（组转移）：从复合状态 LampFlashing 边界出发的 off/、on/ 转移，无论当前处在 FlashOn 还是 FlashOff 都会触发——避免为每个子状态各画一条
默认转移：进入 LampFlashing 时走向内部初始伪状态 → FlashOn
触发规则：两条或多条转移可以有同一个触发器（例如子状态里的 on/ 和外层的 on/）——内层（更深的）转移优先

6.7 完成转移

由完成事件触发，当直接嵌套的状态机终止时自动产生
例：Committing { Phase1 → Phase2 → final } 结束后，没有标触发器的转移自动走到 CommitDone（隐式触发器）

6.8 复杂动作顺序例题（必会）

S1 { entry/en1; exit/exS1 }                S2 { entry/enS2; H* }
  └ S11 { entry/en11; exit/exS11 }           └ S21 { entry/enS21; exit/exS21 }
E1/act1 : S1 → S2           E2/act2, E3/act3 为另外两条转移（E3 从 S21 指向 S2）

问题	答案（讲义）	解释
处于 `S1::S11`，发生 E1	exS11 → exS1 → act1 → enS2 → enS21	先由内向外退出（S11 再 S1）→ 转移动作 → 由外向内进入（S2 再其默认子状态 S21）
处于 `S2::S21`，发生 E3	exS21 → act3 → enS2 → enS21	退出 S21；S2 没有定义 exit 动作；转移动作 act3；重新进入 S2 和 S21

$由内向外由外向内$

6.9 正交区域

用来捕获同一实体的不同并发视角：Person 的 age（Child → Adult → Retiree）和 financialStatus（Poor ↔︎ Rich）是同时成立的两个描述
如果不用正交区域，就要做状态笛卡尔积：个状态（Child-Poor、Child-Rich…）；用正交区域只需个
语义：区域并发执行；所有正交区域检测相同的事件并同时响应（实践中通常是某种交错）。例：legalStatus 区域 LawAbiding --robBank/--> Outlaw，financialStatus 区域 Poor --robBank/--> Rich——一个 robBank 事件同时触发两个区域的转移

⚠️ 正交区域的并发是“不同视角”的并发，不应该用来建模并发对象！ 对象并发的语义与区域并发不同。讲义原话：“不幸的是，大多数建模者都是这么用的——不要掉进这个陷阱。”

6.10 Agentic 例子：智能健康 agent 预约（状态机）

stateDiagram-v2
    [*] --> Idle
    Idle --> Analysing : Req received / provideSymp()
    Analysing --> AdvisingSelfCare : If mild
    Analysing --> MakeBooking : If need doctor
    state MakeBooking {
        [*] --> QueSchedule
        QueSchedule --> PresOptions : Slot received
        PresOptions --> confBooking : Choice received
    }
    MakeBooking --> Idle : Booking confirmed / prepareNotice()
    AdvisingSelfCare --> Idle

各状态的 entry/exit（讲义）：Idle { entry/initialize(); exit/waitForReq() }；Analysing { entry/analyse(); exit/decision() }；Advising Self-care { entry/genAdvice(); exit/delivAdvice() }；Make Booking { entry/connetSchSys(); exit/notifyPatient() }；QueSchedule { entry/reqSlots(); exit/recSlotList() }；PresOptions { entry/showSlot(); exit/getChoice() }；confBooking { entry/sendReq(); exit/recRes() }。

七、小结与综合例题

7.1 四种行为形式

形式	用途
Actions	细粒度操作
Activities	控制流和数据流的计算模型
State machines	事件驱动的计算模型（单个对象）
Interactions	事件驱动的系统行为（对象间）

尽管不同，它们共享共同的语义基础：面向对象——所有行为源于对象的动作。 Tutorial 6 的说法：Actions 和 Activities 用于微观行为，State Machines 和 Interactions 捕获宏观行为。

7.2 综合例题：Smart Financial Advisor Agent

场景：agent 帮客户规划投资组合——收集财务目标和风险偏好 → 分析当前市场数据 → 生成投资建议 → 用户批准后通过 Brokerage System 执行交易 → 跟踪组合表现并发通知 → 处理异常（市场崩盘、交易被拒）。

为什么比健康例子复杂：持续监控（循环）、集成多个外部系统（Market API、Brokerage）、分支（批准/拒绝/替代方案）、异常处理。

解答要点（讲义给出的关键信息 + 展开）：

活动图：泳道 Client / Smart Financial Advisor Agent / Market Data API / Brokerage System

flowchart TD
    subgraph Client
        C1[Provide goals & risk preferences]
        C2{Approve?}
    end
    subgraph Agent[Smart Financial Advisor Agent]
        A1[Analyze client profile]
        A3[Generate recommendations]
        A4[Present options to client]
        A5[Revise / offer alternatives]
        A6[Track portfolio performance]
        A7[Notify client]
        A8[Handle exception]
    end
    subgraph Market[Market Data API]
        M1[Return market data]
    end
    subgraph Broker[Brokerage System]
        B1[Execute trade]
        B2{Trade accepted?}
    end
    C1 --> A1 --> M1 --> A3 --> A4 --> C2
    C2 -- no --> A5 --> A4
    C2 -- yes --> B1 --> B2
    B2 -- no --> A8 --> A7
    B2 -- yes --> A6 --> A7 --> A6

顺序图：四个参与者（Client、Agent、MarketAPI、Brokerage）；用 alt [approved] / [rejected] 表示批准分支，用 loop [monitoring period] 表示持续跟踪，异常可用 alt [trade rejected] 或 break。

状态机（Agent）：Idle → CollectingProfile → Analysing → Recommending → AwaitingApproval；AwaitingApproval --approve--> Executing --tradeOK--> Monitoring；--reject--> Recommending；Executing --tradeRejected--> HandlingException；Monitoring 中 after(period)/checkPerformance() 自转移，marketCrash 事件 → HandlingException。

讲义强调：状态机关键是“define correct states”——状态应该是一段持续的条件（等待批准、监控中），而不是一个动作（“分析”这类瞬时动作更适合放在 entry 或转移上）。

八、Tutorial 7 要点与解答思路

8.1 活动图用来做什么

描述活动如何协调以提供服务（可在不同抽象层次）
适合：需要协调的操作、单个 use case 内事件之间的关系（尤其是活动可能重叠需要协调的）、多个 use case 协调组成业务工作流
使用步骤：通过业务工作流识别候选 use case → 识别 use case 的前后置条件 → 建模 use case 之间/内部的工作流 → 建模对象操作中的复杂工作流 → 在高层活动图中详细建模复杂活动

8.2 例题：Process Order（必练）

收到订单后分成两组并行活动：一边 Fill Order 并发货，另一边处理账单。Fill Order 一侧按条件决定配送方式：Overnight Delivery 或 Regular Delivery。最后并行活动汇合，关闭订单。

flowchart TD
    S((start)) --> R[Receive Order] --> F[fork ━━]
    F --> FO[Fill Order] --> D{delivery?}
    D -- overnight --> OD[Overnight Delivery]
    D -- regular --> RD[Regular Delivery]
    OD --> M[merge ━━]
    RD --> M
    F --> SI[Send Invoice] --> RP[Receive Payment]
    M --> J[join ━━]
    RP --> J
    J --> CO[Close Order] --> E((end))

关键得分点：fork/join 用于并行；decision/merge 用于条件；不要用 join 去合并 decision 的分支（会死锁——join 要等所有入边都到达，而 decision 只走一条）。

8.3 其他例题

Word Processor：打开软件 → 新建文件 → 以唯一名称保存 → 输入文档 → [需要图形] 打开图形软件、制作、粘贴 → [需要表格] 打开表格软件、制作、粘贴 → 保存 → 打印 → 退出（两个 decision，各自 merge）
Student Enrollment：申请人提交表单 → 注册员检查 → 表单合格 → 通知参加介绍会 → 帮助选课 → 要求缴纳首期学费（适合用 Applicant / Registrar 两条泳道）
Staff Expenses Submission、Meeting a new client：对比有泳道 vs 无泳道——泳道让“谁做”一目了然

8.4 顺序图记号

元素	说明
对象	方框内名字加下划线，三种写法：`myAccount`、`myAccount : Account`、`: Account`（匿名）
生命线	对象下方的虚线，表示对象存在
同步消息	实线 + 实心箭头（普通操作调用）
返回消息	虚线 + 开放箭头
异步消息	实线 + 开放箭头；信号是无回复的异步消息
创建/销毁	构造消息指向被创建对象的方框（画在更低的位置）；销毁用 X 结束生命线
斜箭头	表示消息需要一段时间才到达
Focus of control（激活条）	生命线上的细长矩形，上下边对齐操作的开始和结束
迭代	`*[for all order lines]`

8.5 组合片段（常考）

操作符	含义
alt	多个备选片段，只执行条件为真的那个
opt	条件为真才执行；等价于只有一个分支的 alt
par	各片段并行执行
loop	可执行多次，守卫给出迭代依据
critical	临界区，同一时刻只能有一个线程执行
neg	表示无效的交互
ref	引用另一张图中定义的交互；框覆盖所涉生命线，可带参数和返回值
sd	包围整张顺序图
（还有 break、assert）

8.6 例题：Place Order（顺序图）

基础版：Customer、Order、Stock 三个对象——1–2 Customer 创建 Order；3 添加商品；4–5 对每个商品检查库存（loop）；6–8 若有货则加入订单（opt/alt）；9 返回；10–11 保存并销毁 Order。

扩展版：会员下单，按会员状态（VIP → courier，Ordinary → ordinary mail）选择配送——用 alt [VIP] / [else]；如果会员选择了通知选项，商店可选地发送确认——用 opt [notification requested]。

判断 alt 还是 opt：有两条及以上互斥分支 → alt；只有“做或不做” → opt。

九、Lab 7 要点

ELEC5620-Lab-Note-7.pdf（文件头 “Week 8: Laboratory 7”），本周聚焦三种行为图：

Part	图	要求
1	Activity Diagram	回顾 use case 和场景；挑选对系统功能关键的行为；画出控制流，展示决策、并发和信息流
2	Interaction Diagram（如顺序图）	识别重要场景中的关键对象及交互；表示对象随时间收发消息
3	State Machine Diagram	选择有复杂行为和状态变化的关键对象；定义状态和由特定事件触发的转移；突出导致状态变化的事件

做 Lab 7 的检查清单：

溯源：每张行为图对应一个具体 use case（Stage 1 评分要求 ad hoc 需求 → use case → 三张行为图的链条，见 Stage 1 评分标准）
一致性：顺序图里的生命线必须是类图/对象图中存在的类或对象；消息必须对应类的操作
活动图：用泳道区分 Patient / Agent / 外部系统；包含至少一个 decision 和一个 fork/join；人工审批点画成一个人类泳道里的动作
顺序图：用 alt 表示成功/失败分支，用 ref 拆分复杂子交互，异步工具调用用开放箭头
状态机：为 agent 的“运行”对象（如 AgentRun、Booking）建模，状态是持续条件（WaitingForTool、AwaitingApproval），包含取消、超时、失败转移；考虑 RTC
记号正确：exit → transition → entry；守卫无副作用；choice vs junction

十、本周考点速记 / 易错点

UML 因果模型：离散事件驱动、对象网络、所有行为源于对象；动作由对象执行。
主动 vs 被动对象：被动对象一被调用就响应（可能冲突）；主动对象只在 receive 时响应（消息队列）。
RTC：两次 receive 之间的消息排队，一次只做一件事 → 避免冲突；代价是优先级反转（仅在同一对象内）。
Agentic RTC：取消请求不能在状态更新一半时处理；反应要短；LLM 输出要验证。
同步 = call and wait（实心箭头）；异步 = send and continue（开放箭头）。
六类动作：communication、object、link、structural feature、variable、exception。
活动图记号：activity final（全停）vs flow final（一条停）；decision/merge vs fork/join；泳道。
交互需要协作结构作为上下文；三种图：顺序、通信、交互概览。
组合片段：alt、opt、par、loop、critical、neg、ref、sd（+break、assert）。
事件三类：message、change、time；事件发生没有持续时间。
动作顺序：exit（由内向外）→ 转移动作 → entry（由外向内）；自转移也会 exit 再 entry。
Junction（静态、预先求值）vs Choice（动态、到达时求值）。
组转移、完成转移、默认转移；内层转移优先。
正交区域 = 同一实体的不同视角，不要用来建模并发对象；避免状态笛卡尔积爆炸。
易错：用 join 合并 decision 分支；守卫有副作用；状态命名为动作；顺序图里的对象与类图对不上。