ELEC5620 Week 05 架构设计模式与结构建模（上）讲课总结

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

ELEC5620 Week 05 讲课总结：经典架构模式（管道过滤器、共享数据、分层、SOA、MVC）、LLM 工作流、BDI、agent 与服务的取舍、ReAct/Planner–Executor/Supervisor–Worker 等 agent 模式及选型；结构建模基础：对象与链接、分类器、多重性、泛化、组合聚合、接口、依赖与约束；Tutorial 5 类图与 Lab 5。

ELEC5620 Week 05 讲课总结：Architectural Design Patterns + Modeling Structure（Part 1）

课程：ELEC5620 — Model Based Software Engineering，Semester 2 2026 讲师：Dong Yuan 来源：讲义 PDF 4 Architectural Design and Modeling (part 2).pdf（25 页）+ 5 Modeling Structure part 1.pdf（44 页）+ ELEC5620-TUT-05.pdf（31 页）+ ELEC5620-Lab-Note-5.pdf（1 页）。本周无转录稿。

本周覆盖： 1. 经典架构模式：Data-flow、Shared-data、Layering、SOA、MVC 2. Agentic AI 的架构模式：LLM 工作流、BDI、agent vs 服务、控制架构、agent 结构模式与选型图 3. 结构建模基础：值/对象/链接、类型与实例、分类器、关联与多重性、泛化、组合/聚合、接口、依赖、约束 4. Tutorial 5：类图记号；Lab 5：架构模式选择 + 类图

相关笔记：Week 04 架构设计（上）｜Lab 1–6 总结

Part A：架构设计模式

一、什么是架构设计模式

Architectural design pattern：定义一组元素类型和关系类型，它们协同工作以从某个视角（视点）解决特定问题。

三要素：

要素	含义
Context	反复出现的常见情境
Problem	在该情境下出现的问题
Solution	对反复出现的设计问题的可复用解法

为什么重要：通用问题的通用解——抽象、最小改动、通用结构。

二、五种经典架构模式

模式	Context	Problem	Solution	优点	缺点
Data-flow（pipe-and-filter）	变换离散数据项的流	划分为可复用、松耦合、交互简单的组件	对数据流进行逐级变换；数据进入系统后一次流过一个组件直到终点	容易拔插和替换 filter	交互性有限
Shared-data	多个组件需要共享和操作数据	多个独立组件访问数据	数据访问者通过共享数据存储通信；三要素：通信、数据定义、数据操作协议	保证数据完整性和可靠性	可扩展性
Layering	需要独立开发和演化系统的部分	模块化切分以支持独立开发与演化	把提供内聚服务集合的模块分组为层；层间接口定义良好（例：Transport / Network / Link）	降低复杂度，提高模块化、复用性和可维护性	如何定义层？
SOA	多个服务提供者；服务消费者只需了解服务的使用方式	支持分布式组件的互操作	由分布式组件和服务提供者组成的集合，通过总线（BUS）连接（例：Train、Ferry、Customer Management）	抽象、复用、松耦合	管理服务元数据
MVC	UI 是交互式应用中最常修改的部分；需要从数据存储取数据显示给用户；希望界面修改与系统其余部分分离	如何把 Web 应用的 UI 功能模块化，使各部分可以单独修改？	把领域建模、展示、基于用户输入的动作分成三个类	关注点分离	（讲义未列）

2.1 MVC 三部分

部分	职责
Model	管理应用领域的行为和数据；响应对其状态的查询（通常来自 View）；响应改变状态的指令（通常来自 Controller）
View	管理信息的显示
Controller	解释用户的鼠标和键盘输入，通知 Model 和/或 View 做相应改变

flowchart LR
    U([User]) -- input --> C[Controller]
    C -- change state --> M[Model]
    C -- select view --> V[View]
    V -- query state --> M
    V -- display --> U

Web 应用框架（如 Spring MVC、Apache Struts）内置 MVC 等设计模式，目的是减轻 Web 开发中常见活动的开销（例如请求路由、表单绑定、模板渲染、会话管理、数据访问）。

三、Agentic AI 的架构模式

3.1 使用 LLM 的基本工作流（三阶段）

阶段	内容
1. Data preprocessing / embedding	存储私有数据供以后检索：文档切块 → 过 embedding 模型 → 存入向量数据库
2. Prompt (context) construction / retrieval	用户提交查询时构造 prompt：开发者写死的 prompt 模板 + few-shot 示例 + 从外部 API 检索的信息 + 从向量库检索的相关文档
3. Prompt (context) execution / inference	提交给预训练 LLM 推理（商用 API 或开源/自训练模型）；有些开发者在这一阶段加上日志、缓存、校验等运维系统

flowchart LR
    D[Private docs] --> CH[Chunk] --> EM[Embedding model] --> VDB[(Vector DB)]
    Q([User query]) --> PC[Prompt construction]
    VDB --> PC
    API[External APIs] --> PC
    T[Template + few-shot] --> PC
    PC --> LLM[LLM inference] --> O([Answer])
    LLM -.-> LOG[logging / caching / validation]

讲义还给出“简单 AI agent 工作流”（每一步都依赖 LLM）和一篇综述论文（Deng et al., 2024）中的 AI agent 软件架构图（PDF 中为图片）。

3.2 BDI（Belief–Desire–Intention）模型

BDI 是设计 agentic AI 架构中广泛使用的智能 agent 理论框架。

组件	含义
Beliefs (B)	agent 的动态心智模型：关于环境、自身和其他 agent 的知识；可能包含事实、感知或推断（可以不完整或不确定）
Desires (D)	驱动行动的目标：agent 希望达到的世界状态；是动机态度，不一定能同时全部实现
Intentions (I)	承诺的行动计划：agent 在信念和约束下决定承诺去实现的那部分 desires；指导具体计划和行动

BDI 工作流：

$感知环境、更新信念$

3.3 不是每个服务都应该成为 agent（决策树）

flowchart TD
    Q1{Does the task require<br/>contextual judgment?}
    Q1 -- NO --> S[Use a deterministic<br/>service or workflow]
    Q1 -- YES --> A[Use a bounded agent<br/>with explicit tools]
    A --> Q2{High-impact action?}
    Q2 -- YES --> P[Add approval + policy]

Agent 候选：分诊（triage）、澄清（clarification）、规划（planning）
Service 候选：认证（authentication）、通知（notification）

项目里常见的错误是“所有东西都是 agent”。认证、发邮件、写数据库这类不需要上下文判断的功能，应该是确定性服务。

3.4 能力不决定控制（Capabilities do not determine control）

同样的功能特性（患者交互、风险评估、临床检索、记录访问、排期），可以有两种控制架构：

	Workflow-controlled	Supervisor-controlled
结构	Collect → Assess → Book 的固定顺序	一个 Supervisor 协调 Triage、Records、Booking
特点	可预测的执行	动态顺序，显式协调者

这与 Week 4 的“控制与功能分离”一脉相承：功能决定有哪些组件，控制架构决定它们按什么顺序、由谁协调。

3.5 面向 agent 的结构模式

模式	结构	适用/优点
Single-Agent Tool-Use	解释请求 → 选工具 → 执行 → 评估结果 → 回复	架构简单、通信开销低
ReAct（Reasoning + Acting）	Thought → Action → Observation → Thought → Action …	动态环境、复杂和探索性任务
Planner–Executor	规划与执行分离：Planner → 任务计划 (t1, t2, t3 …) → Executor	更好的任务分解、便于监控
Supervisor–Worker	一个 agent 协调多个专业 agent	复杂应用、清晰的控制结构、便于治理
Micro-Agent Architecture	每种 AI 能力（规划、推理、感知、行动）实现为松耦合的 micro-agent，通过消息/事件（pub-sub、消息总线）通信	机器人、交易 bot、智能家居中的多 agent 协作
Cognitive Layering	Perception Layer（感知与预处理）/ Reasoning Layer（规划、推理、LLM）/ Action Layer（API/执行器）	感知、思考、行动清晰分离
Blackboard	agent 把中间结果、假设或目标贴到共享“黑板”上，其他 agent 观察并贡献	复杂环境中的问题求解（排程、自动驾驶）

推理与规划模式：

模式	内容	例子
Deliberative–Reactive Hybrid	反应式 agent（快速响应）+ 审慎式 agent（规划推理）	聊天机器人：FAQ 快速回答，复杂问题深度推理
Goal–Plan Hierarchy	目标分解为子目标分配给 agent，每个 agent 用 BDI 模型	企业工作流自动化

对照经典模式：Blackboard ≈ Shared-data，Cognitive Layering ≈ Layering，Micro-Agent ≈ SOA/事件驱动，Supervisor–Worker ≈ Week 4 的星形集中控制。考试时如果被问“这个 agent 模式对应哪个经典模式”，可以这样类比。

3.6 模式选择：任务不确定性 × 协调需求

讲义最后一页的二维图：

	低任务不确定性	高任务不确定性
高协调需求	Hierarchy、Supervisor–worker	Blackboard、Peer-to-peer
低协调需求	Workflow、Single-agent tool use	ReAct、Planner–executor

Pattern choice follows uncertainty and coordination. 任务越不确定，越需要 agent 自主推理（ReAct/Blackboard）；需要协调的组件越多，越需要显式的协调结构（Supervisor/Hierarchy）。

解题思路（给场景选模式）：先判断任务是否需要上下文判断（不需要 → 服务/工作流）；再判断不确定性高低和参与者数量，落到上表的象限；最后说明控制放在哪里（workflow 还是 supervisor）以及高影响动作的审批点。

Part B：结构建模（Part 1：基础概念）

四、为什么建模结构

4.1 代码 vs 模型

Code is intended for machines. Models are intended for people.

模型方法的两大特征（Week 2 回顾）：Key Feature 1：ABSTRACTION，Key Feature 2：AUTOMATION。

讲义提出问题：如果建模语言是编程的未来，它们长什么样、如何被定义？ 提示：这不是图形语法 vs 文本语法的区别——关键在于语义（Week 10 元建模会回答）。

4.2 UML 作为贯穿例子

最广泛教授和使用的软件建模语言，由 Booch、OMT、OOSE 等方法统一而来
原本用于描述性模型，也支持规定性（如可执行）模型

本课软件建模路线：建模结构（W5–6）→ 建模行为（W7）→ 组织模型（W8）→ 定义建模语言（元建模，W10） → 特化建模语言（W11）。

4.3 什么是结构建模

结构建模处理占据空间（最终是物理空间）、具有状态并可能有行为的实体的表示。

具体包括：

设计时的类
运行时的实例（如对象）及其关系（如链接）
这些运行时实体的规格（如结构化类、协作）及关系的规格（如关联）

UML 中的两类结构实体：Elementary（基础） 和 Structured（结构化，用于建模架构，Week 6）。

五、基础结构概念

5.1 值、对象、对象身份、链接

概念	定义	要点
Value	普遍、唯一、不变的信息表示	数字、字符、字符串、符号；如 7、VII、“seven” 表示同一个值；要在程序中使用必须存进某个“容器”
Value container	存储值的物理空间	可动态创建和销毁；可限定只存某类型的值；存的值可以改变或移除（空容器）
Object	具有唯一身份、符合某个 Class 类型的复杂值容器	可拥有属性槽（存属性值的容器）；可执行行为（操作）；身份在生命周期内不变，但类型可以变（type reclassification）
Object identity	对象创建时获得、终生不变、区别于所有其他对象的内在属性	即使属性值或类型改变，身份也不变
Link	存储对象标识符的值容器元组（link ends），符合某个 Association 类型	可动态创建销毁；可能有身份（有些链接本身是对象）；两种：链接端由被链接对象拥有 vs 由链接自身拥有

对象身份的例子：prince : Adult，1958 年 name = "Prince"，1993 年 name = "The Artist Formerly Known As Prince"——属性值变了，还是同一个对象。

“点”记号（dot notation）：关联端上的小黑点表示ClassA 拥有一个以 ClassB 为类型的特性（即链接端由对象拥有，相当于 ClassA 有一个指向 ClassB 的属性）。

5.2 模型与被建模事物（M1 vs M0）

要区分模型和它所建模的东西——我们常对两者用同一个词（比如 “Batmobile”）。

层	例子
M1：The Model	Batmobile 玩具（模型）
M0：The Modeled World	真实的 Batmobile

关系：模型 «represents» 真实事物。（M0/M1 的编号在 Week 10 元建模的四层架构中会继续出现。）

5.3 类型、实例、分类器

概念	定义
Type	对共享同类属性的一类实体的规格（模型），如 `Adult { name: String, gender: [M,F] }`
Instance	类别中的个体成员，如 `Alice : Adult { name = "Alice", gender = F }`
Classifier	对一组实体的规格，这些实体 ① 共享一组特征，② 可按某些特征的性质被分类（划分）为子集合（如人按性别分男女，按年龄分成人和儿童）

关系：Adult（类型，M1）«represents» 概念类别 Adults（M0）；Alice : Adult（实例规格，M1）«instanceOf» Adult，并 «represents» 个体 Alice（M0）。

UML 中的分类器种类：Classes、Associations、AssociationClasses、DataTypes、Enumerations、Interfaces、Behaviors（Activities、Interactions、StateMachines）、Signals、UseCases、Collaborations、Components、Nodes 等。所有分类器都可以作为类型。

5.4 类与关联

概念	定义
Class	对一组具有相同特性和行为的对象实例的规格
Association	对一组链接的规格，这些链接的各端分别符合相同的类型

类是对象集合的规格，关联是链接集合的规格——两者都是分类器。

关联端名的含义：Adult (parents, 1..2) —— (children, 0..*) Child。Karl.children 表示 Karl 的“孩子集合”，Cory.parents 表示 Cory 的“父母集合”。用 OCL 写：Karl.children->includes(Cory)。

5.5 多重性与修饰

记号	含义
`1..2`	下界 1，上界 2
`0..` 或 ``	0 到无限
`0`	元素缺失
`name : String [1..*]`	属性也可以有多重性

多重性修饰符：

修饰	含义	默认
`{unique}` / `{nonunique}`	集合中没有两个元素值相同	unique = true
`{ordered}` / `{unordered}`	元素有序	unordered（ordered = false）

组合起来：{unique, unordered} = Set（默认），{unique, ordered} = OrderedSet，{nonunique, unordered} = Bag，{nonunique, ordered} = Sequence。

5.6 泛化 / 特化

UML 中分类用 Generalization 关系建模——子集—集合关系（Child ⊂ Person，Adult ⊂ Person）
Generalization set（泛化集）：同一个类可以按多个分类准则划分，如 Person 按 age 分 Adult/Child，按 gender 分 Males/Females
泛化箭头表示一种图形操作：超类的所有特性也出现在子类中（如 CorporateAccount 继承 BankAccount 的 /customers、credit()、debit()，再加上自己的 owner : CorporateCustomer）

关联特化：

BankAccount  [accounts 1..*] ——— [customers 1..*]  BankCustomer
     △                                                 △
CorporateAccount [C-accounts 1..*] ——— [owner 1]  CorporateCustomer   ← 约束收紧（1..* → 1）
PersonalAccount  [P-accounts 1..*] ——— [owners 1..*] PrivateCustomer

更精确的规格：父关联端标 {union} /accounts、{union} /customers（派生的并集），子关联端标 {subsets accounts}、{subsets customers}——表示子关联的链接是父关联链接的子集，父关联是所有子关联的并。

5.7 组合、聚合、关联类

关系	记号	语义
Composition（黑菱形）	实心菱形在整体端	所有权；“删除”语义：所有者被移除时，其拥有的元素一起被移除。例：`Person ◆—— name: String`；部件端的多重性最多为 1（`0..1` 或 `1`）
Aggregation（白菱形）	空心菱形在整体端	用户自定义的“弱”所有权（如在 UML profile 中）；标准 UML 中语义与普通关联相同
Association class	关联线上用虚线挂一个类	关联本身有属性：`Person (1..) —— (0..) Company`，关联类 `Job { salary }`

关联类的替代方案：把 Job 建成普通类，Person 1..* —— 0..* Job 0..* —— 0..* Company。好处是避免关联类语义的复杂性（如写约束）；代价是需要额外约束把两条关联的链接耦合起来（同一个 Job 必须对应同一对 Person–Company）。

考试易错：关联类意味着同一对 (Person, Company) 至多一个 Job（因为链接由端点对唯一确定）；用普通类代替时同一对可以有多个 Job。

5.8 类的记号

┌──────────────────────────────────────────────┐
│ CorporateAccount                              │
├──────────────────────────────────────────────┤
│ +/customers : BankCustomer                    │  ← “/” 表示派生属性
│ +owner : CorporateCustomer                    │
│ #bankPrefix : String = "0613" {readOnly}      │  ← 默认值 + 属性约束
├──────────────────────────────────────────────┤
│ +credit(amount: Amount)                       │
│ +debit(amount) : Boolean                      │
│ +«signal» alarm()                             │  ← «signal» 表示信号接收
└──────────────────────────────────────────────┘
        accounts 0..*  ●————————  1 branch  BankBranch

关联端的黑点表示该端由 CorporateAccount 拥有（即 CorporateAccount 有一个 branch 属性）。运行时：obj2:CorporateAccount —link<obj2,obj1>— obj1:BankBranch。

5.9 接口

和类一样定义一组特性，但只有声明 ⇒ 接口不能有实例
可以被分类器 realize（实现）：实现者必须为所有接口特性提供（直接或间接的）实现
可以被分类器 use（使用）：表示该分类器需要某个实现了该接口的对象的服务——一种解耦手段

例：Pilot --«uses»--> «interface» JetEngineControl { thrust, status, accelerate(), decelerate(), reverseThrust(), ignite(), powerDown() }，由 RollsRoyceEngine 和 GEEngine realize。

简写记号：棒棒糖（lollipop，提供接口）与插座（socket，需要接口）。注意：lollipop 不表示接口实例，而是“接口 + 实现关系”的组合。

5.10 依赖与约束

概念	内容	记号
Dependency	非正式陈述：一个或多个 client 以某种方式需要 supplier；supplier 的变化会影响 client；语义很松，可以特化（用户自定义名如 `«manufacturedBy»`）	虚线 + 开放箭头，从 client 指向 supplier（`Car --«manufacturedBy»--> Factory`）
Constraint	为命名空间中的元素捕获语义；可用形式语言（OCL）或自然语言	行内 `size : Integer {size >= 0}` 或附注（note 连到元素）

六、Agentic AI 的基础结构建模

讲义给出三条建模建议：

清晰定义 Agent 抽象：基类 Agent 捕获共同属性（state、knowledge base、goals、environment model）和方法（perceive()、reason()、act()、communicate()）；专门 agent（ChatbotAgent、PlannerAgent、RobotAgent）继承基类；正确使用泛化避免重复
建模 agent 能力：感知（输入处理、NLP、传感器）、推理（规划、推断、学习）、行动（API 调用、执行、回复）——可建成独立的类或接口，由 agent 通过组合/关联使用
建模交互与通信：用 Message 或 Protocol 类（如 FIPA ACL、REST API）表示通信通道；用关联表示协作或监督；多个 agent 协作时用多重性（1..*）

讲义中的类图片段（文字还原）：

classDiagram
    class Agent {
        <<abstract>>
        name: string
        memory: Memory
        plan(goal)
        act()
        observe()
    }
    class Tool {
        <<interface>>
        execute(input)
    }
    class WebSearch {
        provider: string
        execute(query)
    }
    class Orchestrator {
        agents: Agent[]
        dispatch(goal)
    }
    class Memory {
        items: Item[]
        recall(query)
    }
    class ResearchAgent {
        depth: number
        synthesize()
    }
    class AgentRun {
        status: Status
        start()
        finish()
    }
    class Step {
        output: string
        complete(result)
    }
    Agent ..> Tool : uses
    Tool <|.. WebSearch
    Orchestrator o-- "0..*" Agent : groups
    Agent --> "1" Memory : holds
    Agent <|-- ResearchAgent
    Orchestrator ..> AgentRun : creates
    AgentRun *-- "1..*" Step : owns

这张图同时用到了抽象类、接口实现、泛化、聚合、组合、依赖和多重性，是一张很好的“检查自己会不会画所有记号”的模板。

七、Tutorial 5 要点与解答思路

7.1 类图的组成与用途

类图是所有面向对象方法的核心建模工具：描述系统中对象的类型及其静态关系
用途：展示分类器的静态结构；为其他结构图提供基本记号；开发者和业务分析师都可用

类 = 结构特性（attributes，对象“知道”什么，即状态）+ 行为特性（operations，对象“能做”什么）。三栏：类名 / 属性（name : Type，映射到成员变量）/ 操作（op(param : Type) : ReturnType，映射到方法）。

7.2 关系记号速查

关系	语义	线型
Inheritance / Generalization	is-a；抽象类名斜体	实线 + 空心三角，从子类指向父类
Association	对等类之间的结构链接	实线
Aggregation	part-of；部分与整体生命周期独立	实线 + 空心菱形在整体端
Composition	特殊的聚合：整体销毁时部分也销毁，部分不能独立存在	实线 + 实心菱形在整体端
Dependency	一个类定义的改变可能导致另一个类改变（单向）	虚线 + 开放箭头
Realization	类实现接口	虚线 + 空心三角

关系名、角色与导航性（Spreadsheet 例子）：

关系名写在线中间，读出来要通顺：“Every spreadsheet contains some number of cells”、“an expression evaluates to a value”
角色写在关联端，描述该类在关系中扮演的目的：cell 与 expression 的关系中，expression 的角色是 cell 的 formula
导航性箭头：给定 spreadsheet 能找到它的所有 cells，但从 cell 不能确定它属于哪个 spreadsheet；给定 cell 能拿到 expression 和 value，反之不行

7.3 可见性

符号	可见性	同一类	子类	其他类
`+`	public	✓	✓	✓
`-`	private	✓	✗	✗
`#`	protected	✓	✓	✗
`~`	package	✓	✓（同包）	同包内 ✓

Tutorial 给出了 Order System、GUI、Hotel Management、ATM 等示例类图（PDF 中为图片）。

7.4 画类图的解题步骤

从需求/use case 中找名词作为候选类，动词作为候选操作
区分实体类（Patient、Appointment）、控制类（Orchestrator）、边界/接口（Tool、外部 API）
确定关系：is-a 用泛化；“拥有且同生共死”用组合；“包含但独立存在”用聚合；只是“用到”用依赖；其他用普通关联
每条关联都写多重性，必要时写角色名和导航方向
接口与实现分开；可见性符号不要漏
检查：每个核心 use case 的功能都能在某个类的操作中找到

八、Lab 5 要点

ELEC5620-Lab-Note-5.pdf（文件头 “Week 6: Laboratory 5”）：

Part One：架构设计与设计模式

识别相关模式：Layered、MVC、SOA、Shared-Data、Planner–Executor、Supervisor–Worker 或其他 agent 模式；说明为什么适合、解决什么架构问题
架构设计：展示模式如何应用；给出主要组件、职责、交互、整体控制流或数据流
Rationale：讨论所选模式的优点和局限，论证架构如何满足 FR 和 NFR

对 agent 系统可以考虑 ReAct、Planner–Executor、Supervisor–Worker、Blackboard、Cognitive Layering——不需要全用，选最相关的。

Part Two：类图——主要类及关系（关联、泛化、聚合、组合）、接口及实现、每条关联的多重性、每个类的属性和方法；注意 UML 记号正确。

详细的检查清单见 Lab 1–6 总结第六节。

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

模式三要素：context、problem、solution。
五种经典模式的优缺点：pipe-and-filter（易替换 / 交互弱）、shared-data（完整性 / 可扩展性）、layering（模块化 / 层难定义）、SOA（松耦合 / 元数据管理）、MVC（UI 最常改 → 分离）。
LLM 工作流三阶段：embedding → prompt 构造与检索 → 推理（+日志/缓存/校验）。
BDI：Beliefs（可不完整）→ Desires（可冲突）→ Intentions（承诺的子集）。
Agent vs 服务：需要上下文判断才用 agent；高影响动作加审批与策略。
能力不决定控制：workflow-controlled（固定、可预测）vs supervisor-controlled（动态、显式协调者）。
Agent 模式选型：低不确定低协调 → workflow/tool use；高不确定低协调 → ReAct/planner–executor；低不确定高协调 → hierarchy/supervisor–worker；高不确定高协调 → blackboard/peer-to-peer。
对象 vs 值：对象有不变的身份；值是普遍唯一不变的。链接是关联的实例，对象是类的实例。
M0 vs M1：模型与被建模的事物要区分。
多重性修饰默认值：unique = true，ordered = false。
组合 = 删除语义；聚合在标准 UML 中语义等同普通关联。
关联特化用 {subsets} / {union} 精确化；子关联可收紧多重性。
接口不能实例化；lollipop 不是接口实例。
依赖箭头从 client 指向 supplier；泛化箭头从子指向父；组合菱形在整体端。