ELEC5620 Week 10 元建模讲课总结

Posted on In , Word count in article: 4.7k Reading time ≈ 17 mins.
ELEC5620 Week 10 讲课总结：模型与元模型、建模语言的抽象语法/具体语法/语义、MOF 与 OMG 四层架构、UML 元模型片段与关联实例化练习、模型存储与图的关系、静态与动态语义及 fUML、agentic 软件元模型；Tutorial 10 的 RAG 与 LangChain/LangGraph 工具调用循环。

ELEC5620 Week 10 讲课总结：Meta-Modeling

课程：ELEC5620 — Model Based Software Engineering，Semester 2 2026 讲师：Dong Yuan 来源：讲义 PDF 10 Meta-Modeling.pdf（47 页）+ ELEC5620-TUT-10.pdf（19 页）。Week 10 文件夹中没有单独的 Lab Note（文件头写 “Week 10: Laboratory 9” 的 Lab Note 9 放在 Week 9 文件夹，已在 Week 09 中总结）。本周无转录稿。

本周覆盖： 1. “Meta” 游戏：模型、被建模事物、元模型 2. 建模语言的核心组成：具体语法、抽象语法、语义 3. 元模型、MOF、OMG 四层架构 4. UML 规格格式、元模型片段、模型存储、练习 5. 语义：静态/动态、定义方法、fUML 6. UML 元模型选读：命名空间、依赖、约束、类型实例、分类器、结构与行为 7. Agentic 软件的元模型 8. Tutorial 10：RAG 与 LangChain

相关笔记：Week 05 结构建模基础｜Week 08 模型组织

一、“Meta” 游戏

1.1 这不是一只烟斗

讲义借用 Magritte 的画 La Trahison des images：

  1. 问：这是一只烟斗吗？
  2. 答：不，这是一只烟斗的图画。（注意：我们在用一张图来描述一张图）
  3. 再问：这是“一只烟斗的图画”吗？——画框里的画（被建模的东西）vs 外面的说明（模型）

层层嵌套的“关于……的描述”就是 meta 的含义：元模型是描述模型的模型。

1.2 模型与被建模事物

与 Week 5 一样：Batmobile 玩具（模型，M1）«represents» 真实 Batmobile（被建模世界，M0）。我们常对两者用同一个词，要小心区分。

1.3 地铁图：模型与建模语言

  • 里昂地铁图是一个模型
  • 问：用来规定这个模型的（建模）语言是什么？
  • 答：图例（Legend）——Light rail line、Metro line、Station、River 各自的画法。图例就是元模型（它定义了这种图里可以出现哪些概念、怎么画）

二、建模语言的核心组成（重点）

classDiagram
    class ModelingLanguage
    class ConcreteSyntax
    class AbstractSyntax
    class SemanticsDomain
    class ConcreteSyntaxMapping
    class SemanticsMapping
    ModelingLanguage "1" --> "0..*" ConcreteSyntax
    ModelingLanguage "1" --> "1" AbstractSyntax
    ModelingLanguage "0..1" --> "1..*" SemanticsDomain
    ConcreteSyntaxMapping --> ConcreteSyntax
    ConcreteSyntaxMapping --> AbstractSyntax
    SemanticsMapping --> AbstractSyntax
    SemanticsMapping --> SemanticsDomain
组成 含义 例子（UML）
Abstract Syntax（抽象语法） 语言的概念、特性和相互关系——与表示法无关 Class、Attribute、Association……
Concrete Syntax（具体语法） 记号：图形、文本、表格 类画成三栏矩形，泛化画成空心三角
Concrete Syntax Mapping 具体语法 ↔︎ 抽象语法的映射 “三栏矩形”表示一个 Class
Semantics Domain（语义域） 意义所在的领域 运行时对象、链接、执行轨迹
Semantics Mapping 抽象语法 → 语义域的映射 一个 Class 表示一组具有相同特性的对象

一种语言恰好一个抽象语法，但可以有多个具体语法（图形、文本）——这就是 Week 5 提示“不是图形 vs 文本语法的问题”的答案：建模语言的本质在抽象语法和语义。

讲义特别提醒：这张图本身就是用 UML（一种建模语言）在描述建模语言——这就是 META MODELING。

三、元模型、MOF 与四层架构

3.1 元建模语言与 MOF

  • 元建模语言：用来规定建模语言的建模语言；这类模型叫元模型（Meta Models / Metamodels）
  • 广泛使用的标准化元建模语言：MOF（Meta Object Facility），由 OMG 标准化
  • MOF 实际上是 UML 的子集：
    • UML 结构建模（类模型）的子集
    • UML 模型组织概念的子集
    • 没有行为建模（这些模型只是规格）
    • 使用相同的记号

3.2 什么是元模型（定义必会）

Metamodel：规定建模语言抽象语法、并定义良构（well-formed）模型规则的模型，独立于具体语法。 - UML 的抽象语法包含 class、attribute、operation、association、dependency 等构造及它们之间的关系 - 元模型与模型是类—实例关系：每个模型都是元模型的一个实例 - 真实世界元素由模型描述，模型由元模型描述 - 在 MDSE 中，领域特定建模语言（DSL）由元模型定义，元模型是自动化、工具支持的模型处理的基础

3.3 Metaconfusion

说 “pipe” 时我们指的是哪一个？——真实的烟斗、烟斗的图画，还是“烟斗的图画”这个概念？ 元层次很容易混淆，所以需要明确的分层。

3.4 OMG 四层架构（必考）

层 名称 内容 例子 所在
M3 Meta-Meta-Model MOF Class(MOF) 建模工具
M2 Meta-Model UML、CWM 等语言定义 Class、Association 建模工具
M1 Model 用户模型 Customer { id }、CustomerOrder { item, quantity } 模型仓库
M0 Real Objects 运行时实例 <sawdust> <2 tons>、<lard>、<DeliIceCream> <5 tons>（内存中的 01011） 计算机内存、运行环境

层间关系：

（自描述）

MOF 用自己来定义自己（M3 的 specifiedBy 指回自身），所以不需要 M4。

判断层次的方法：问“它是什么的实例？”

东西 它是…的实例 所在层
某个订单对象 <DeliIceCream, 5 tons> CustomerOrder M0
CustomerOrder 类 UML 的 Class M1
UML 的 Class 概念 MOF 的 Class M2
MOF 的 Class MOF 自身 M3

四、UML 的规格与元模型

4.1 UML 语言规格的三部分

部分 内容 定义方式
Abstract Syntax 概念、特性及相互关系 MOF 元模型 + 附加约束（OCL）
Concrete Syntax 记号（图、文本、表格） UML 的具体语法定义不完整、是非正式的
Language Semantics UML 模型及其概念的意义 英语（+ fUML 模型 + 数学模型）

4.2 UML 元模型片段（简化）

classDiagram
    class Element
    class NamedElement {
        name : String
    }
    class DirectedRelationship
    class Generalization
    class Classifier
    class Feature
    class TypedElement
    class Class
    class Attribute
    class Operation
    Element <|-- NamedElement
    Element <|-- DirectedRelationship
    DirectedRelationship --> "1..*" Element : sources
    DirectedRelationship --> "1..*" Element : targets
    DirectedRelationship <|-- Generalization
    NamedElement <|-- Classifier
    Classifier --> "0..*" Generalization : generalizations
    Classifier --> "0..*" Feature : features
    Classifier <|-- Class
    Class --> "0..*" Attribute : attributes
    Class --> "0..*" Operation : operations
    Feature <|-- Attribute
    Feature <|-- Operation
    TypedElement <|-- Attribute
    TypedElement <|-- Operation

读法（讲义原话整理）：每个类都是可泛化的，并且是一个 NamedElement；类由属性和操作组成；属性和操作都是 TypedElement，有一个（基本）类型。

4.3 元建模能做什么

元建模定义用来构造模型的概念、关系和规则——为精确描述软件提供共享语言。

  • 定义建模概念、规定关系
  • 检查模型有效性，支持自动化
  • 元建模就是对模型建模
  • 支持模型复用、一致性和变更分析

4.4 模型是怎么存储的：图只是视图

一张类图：A { a1 : Integer }，B { get_a1() : Integer }，B 泛化 A。在模型仓库里它是一个对象网络（每个对象都是 M2 元类的实例）：

:Class {name="A"} ──attributes[1]──▶ :Attribute {name="a1"} ──types[1]──▶ :PrimitiveType {name="Integer"}
      ▲ targets[1]
:Generalization
      │ sources[1]
:Class {name="B"} ──operations[1]──▶ :Operation {name="get_a1"} ──types[1]──▶ :PrimitiveType {name="Integer"}

UML 图只是底层模型的选择性视图；模型是复杂的节点网络。

模型元素的两种创建方式：

  • 间接：在图中创建新元素
  • 直接：通过程序（API）或模型浏览器直接插入模型

图通常与模型分离——同一个模型元素可以出现在多张图里，也可以不出现在任何图里（这就是 Week 4 “view 只是模型的一个视图”在工具层面的体现）。

4.5 练习：关联的元模型实例（必会题型）

附加元模型片段：

DirectedRelationship ◁── Association ──ends (2)──▶ AssociationEnd
AssociationEnd ──target (1)──▶ Classifier
AssociationEnd : modifier : EndType, lowerBound : Integer, upperBound : Integer
AssociationEnd 也是 TypedElement
«enumeration» EndType { composite, aggregate, simple }

题目：把类图 A [a 0..1] ——— [b 0..2] B 表示为元模型实例（对象图）。

讲义解答：

flowchart LR
    AS[": Association"]
    EA["a : AssociationEnd<br/>lowerBound = 0<br/>upperBound = 1"]
    EB["b : AssociationEnd<br/>lowerBound = 0<br/>upperBound = 2"]
    CA[": Class<br/>name = A"]
    CB[": Class<br/>name = B"]
    AS -- ends --> EA
    AS -- ends --> EB
    EA -- target --> CA
    EB -- target --> CB

（两个端点的 modifier 都是 simple，因为没有菱形。）

解题方法：① 图上的每个“符号”找到对应的元类（框 → Class，线 → Association，线端 → AssociationEnd）；② 每个元类实例画成 name : MetaClass；③ 图上的文字（名字、多重性）填成属性槽；④ 元模型中的关联变成链接。如果题目里有黑菱形，对应端的 modifier = composite。

4.6 UML 具体语法：图的种类

UML Diagram
├── Structure Diagram
│   ├── Class Diagram          ├── Instance (Object) Diagram
│   ├── Package Diagram        ├── Deployment Diagram
│   ├── Composite Structure    ├── Collaboration Diagram
│   └── Profile Diagram
└── Behavior Diagram
    ├── Activity Diagram       ├── Statechart Diagram     ├── UseCase Diagram
    └── Interaction Diagram
        ├── Sequence           ├── Communication
        ├── Timing             └── Interaction Overview

注意：Use Case 图归在行为图下；Profile 图归在结构图下（Week 11 会用到）。

五、语言语义

5.1 静态语义与动态语义

Semantics = 语言语句的意义。

例：类图 Person { +name : String, +gender : eGender }，自关联 friends 0..*；Adult 特化 Person，有 voterRegNo : Integer，自关联 adultFriends 0..*。对应的文本：

class Person { public name : String; public gender : eGender }
class Adult specializes Person { protected voterRegNo : Integer }
含义
Static semantics 存在什么（结构）
Dynamic semantics 发生什么（行为）

同一个语义可以用图形或文本两种具体语法表达——再次说明具体语法不是本质。

5.2 如何规定语义

  • 用一种语义已经定义好的语言来规定语义
  • 计算机语言运行时语义的方法有很多：非正式自然语言描述最常见；以及 denotational（指称）、translational（翻译）、operational（操作）、axiomatic（公理）
方法 思路
Denotational 把每个构造映射到数学对象（如函数）
Translational 翻译到另一种语义已知的语言（如生成 Java）
Operational 定义一个解释器/抽象机如何一步步执行
Axiomatic 用逻辑公理/前后置条件描述

5.3 fUML（Executable UML Foundation）

  • OMG 标准，为有运行时表现的标准 UML 概念子集定义动态语义
  • 建模语言的语义可以写成用标准化可执行建模语言编写的程序——操作（解释）方法
  • fUML 本身的语义用公理方式定义
  • 呼应 Week 2 的 Model Execution：“不可执行的模型就像没有引擎的车”

六、UML 元模型选读

6.1 命名空间元模型

  • 命名空间是包含一组可按名识别的 NamedElement 的模型元素
  • NameSpace 本身是 NamedElement，可以拥有其他 NamedElement
  • 每个 NamedElement 至多被一个 NameSpace 拥有
  • NameSpace 拥有 PackageImport；可以拥有 Constraints

6.2 依赖、约束、注释的元模型

元素 元模型要点
Dependency 一般地，任意两个 NamedElement 之间都可以画依赖（client、supplier 都是 NamedElement）
Constraint 通过 ValueSpecification（包含表达式的元素）表达；其所属命名空间可以是 Class、Package、Interface 等
Comment 可以附在任何模型元素上，在元模型根部（Element 拥有 ownedComment）

6.3 类型、实例与分类器

  • Type vs Instance：类型是一类实体的规格；实例是其中的个体（Week 5）
  • InstanceSpecification：建模对象及其他占据内存空间的东西的通用设施（对象图里的对象就是 InstanceSpecification）
  • Classifier：共享一组特征、可按特征划分为子集合（Week 5）；分类通过 Generalization（子集—集合关系） 建模

6.4 结构与行为的关系（元模型）

Classifier ──feature 0..*──▶ Feature
BehavioredClassifier ──ownedBehavior 0..*──▶ Behavior ──context 0..1──▶ BehavioredClassifier
Class, Actor, UseCase, Collaboration 都是 BehavioredClassifier
Behavior ◁── Activity        （flow-based 行为）
Behavior ◁── StateMachine    （event-driven 行为）
Behavior ◁── Interaction     （event-driven 系统行为）

这把 Week 7 的四种行为形式放进了元模型：行为本身也是分类器，被一个 BehavioredClassifier 拥有。

6.5 Classifier behaviour vs Method

Method Classifier behaviour
主要用于 被动对象 主动对象（如 Java Thread）
触发 调用 Operation（同步）或 Reception（异步）时 对象被创建时执行
元模型 BehavioralFeature (Operation \| Reception) ──method 0..*──▶ Behavior BehavioredClassifier ──classifierBehavior 0..1──▶ Behavior

（对应 Week 7 的主动对象 vs 被动对象。）

七、Agentic 软件的元建模

7.1 问题：一个方框不够精确

健康 agent：用户描述症状 → agent 收集相关信息、评估情况、选择下一步：

  • 缺少信息 → 追问
  • 适合居家护理 → 检索并解释指南
  • 需要医生评估 → 查找可用预约，预约前获得确认

问：画一个 “Book appointment” 方框，能说明何时允许预约、需要什么信息、预约失败怎么办吗？ —— 不能。⇒ 需要一种精确的建模语言。

7.2 健康 agent 类（M1）

HealthcareAgent
+goal : String
+maxSteps : Integer
+assessmentPolicyRef : String
+receiveSymptoms(report : SymptomReport)
+askFollowUpQuestion() : Question
+assessSymptoms() : AssessmentResult
+selectAction(result : AssessmentResult) : CareAction
+provideHomeCareAdvice() : Guidance
+findAppointments() : AppointmentList
+bookAppointment(slot : AppointmentSlot, consent : Confirmation) : BookingResult
+escalateToProfessional()

注意 bookAppointment 需要 consent : Confirmation 参数——“预约前获得确认”被写进了接口签名。

7.3 把这个类表示成 M2 元类的实例

M2 元模型（规格）：Class {name}、Attribute {name, visibility}、Operation {name, visibility}、Parameter {name, direction}、Type {name}。

M2 实例化（即用元模型对象描述 M1 的类）：

M1 元素 元模型实例
类 HealthcareAgent : Class { name = "HealthcareAgent" }
属性 goal goal : Attribute { type = "String", visibility = "+" }
属性 maxSteps maxSteps : Attribute { type = "Integer" }
属性 assessmentPolicyRef assessmentPolicyRef : Attribute { type = "String" }
操作 receiveSymptoms receiveSymptoms : Operation { visibility = "+" } ── report : Parameter ── SymptomReport : Type
操作 selectAction selectAction : Operation { return = CareAction }
操作 bookAppointment bookAppointment : Operation { return = BookingResult } ── slot : Parameter（AppointmentSlot : Type）、consent : Parameter（Confirmation : Type）

这和 4.5 练习是同一种题型：把一个 M1 类“拆”成 Class/Attribute/Operation/Parameter/Type 的对象网络。

7.4 面向 agentic 软件的领域元模型（讲义最后一页）

这是一个为 agent 软件专门设计的 M2 元模型（即一种 DSL 的抽象语法）：

元类 属性 与 AgentType 的关系
AgentType — 中心元类
Goal statement : String、satisfactionCondition : String goals 1..*
Environment — environments 1..*
Policy predicate : String、version : String policies 0..*
Capability kind : CapabilityKind、effect : EffectKind capabilities 1..*；每个 Capability 关联一个 Tool
Tool implementationRef : String —
Reasoner kind : ReasonerKind reasoner 0..1
Behavior stopCondition : String behavior 1；由 steps 1..* 和 transitions 0..* 组成
Memory kind : MemoryKind memories 0..*
ExecutionPolicy maxSteps、timeoutSeconds、maxRetries : Integer executionPolicy 1
ApprovalPolicy validitySeconds : Integer、bindToArguments : Boolean 关联 HumanRole
Step <<abstract>> 子类：InvocationStep | DecisionStep | WaitStep | EndStep —
Transition guard : String、priority : Integer；source [1]、target [1] 指向 Step — 
classDiagram
    class AgentType
    class Goal {
        statement : String
        satisfactionCondition : String
    }
    class Capability {
        kind : CapabilityKind
        effect : EffectKind
    }
    class Tool {
        implementationRef : String
    }
    class Policy {
        predicate : String
        version : String
    }
    class Behavior {
        stopCondition : String
    }
    class Step {
        <<abstract>>
    }
    class Transition {
        guard : String
        priority : Integer
    }
    class ExecutionPolicy {
        maxSteps : Integer
        timeoutSeconds : Integer
        maxRetries : Integer
    }
    class ApprovalPolicy {
        validitySeconds : Integer
        bindToArguments : Boolean
    }
    AgentType --> "1..*" Goal : goals
    AgentType --> "1..*" Capability : capabilities
    AgentType --> "0..*" Policy : policies
    AgentType --> "1" Behavior : behavior
    AgentType --> "1" ExecutionPolicy : executionPolicy
    Capability --> "1" Tool : tool
    Behavior *-- "1..*" Step : steps
    Behavior *-- "0..*" Transition : transitions
    Transition --> "1" Step : source
    Transition --> "1" Step : target
    ApprovalPolicy --> "1" HumanRole

读这个元模型的意义： - Capability.effect : EffectKind（如 read / write / irreversible）+ ApprovalPolicy = Week 3 “把能力与权限分开”、“高影响动作要审批”的形式化 - ApprovalPolicy.bindToArguments = true 表示审批绑定到具体参数（批准的是“预约 10 点这个 slot”，而不是笼统的“可以预约”）；validitySeconds 表示审批有时效 - Behavior = Steps + Transitions(guard, priority) 本质上是一个状态机/流程图的元模型（Week 7） - ExecutionPolicy 把 maxSteps / timeout / maxRetries 变成必填的模型属性——agent 不可能“无限循环”而模型不报错 - 有了这个元模型，就能检查模型有效性（例如“每个 effect = write 的 Capability 必须有 ApprovalPolicy”可以写成 OCL 约束）并自动生成代码/配置——这正是“模型是 agent 的控制平面”（Week 2）的落地方式

八、Tutorial 10 要点：RAG 与 LangChain

8.1 RAG

Retrieval-Augmented Generation：把信息检索和生成式语言模型结合，构建更聪明的问答和内容生成应用；关键是利用外部知识库增强模型回答能力。

步骤 内容
Retrieval 从知识库/外部数据源检索与用户查询最相关的文档或片段
Generation 生成式模型（GPT、Claude 等）以检索内容为上下文生成更准确、相关的回答

8.2 LangChain 生态

库 作用
langchain-core 基础抽象与 LCEL（LangChain Expression Language）
langchain-community 第三方集成；部分拆成独立 partner 包（langchain-openai、langchain-anthropic…）
langchain 组成应用认知架构的 chains、agents、检索策略
LangGraph 把步骤建模为图的节点和边，构建有状态、多 actor 的 LLM 应用；可独立于 LangChain 使用
LangServe 把 chain 部署为 REST API
LangSmith 调试、测试、评估、监控 LLM 应用的平台

环境：Python 3.7+、虚拟环境、pip install langchain、pip install openai、export OPENAI_API_KEY=...；VSCode / Jupyter。

8.3 LangGraph agent：工具调用循环

  • 用 MessagesState；定义 Tools 节点（工具列表）和 Assistant 节点（绑定了工具的模型）
  • 添加 tools_condition 条件边：若 assistant 输出是工具调用 → 去 Tools；否则 → END
  • Tools 节点连回 Assistant，形成循环；只要模型还决定调用工具，循环就继续
stateDiagram-v2
    [*] --> Assistant
    Assistant --> Tools : tools_condition = tool call
    Assistant --> [*] : tools_condition = no tool call
    Tools --> Assistant : ToolMessage

ReAct 直觉：Act（模型调用工具）→ Observe（把工具输出传回模型）→ Reason（分析输出，决定再调工具还是直接回答）。这一架构通用，适用于多种工具。

用本课的语言说：这是一个状态机（Week 7），也是 Single-agent tool-use / ReAct 模式（Week 5），而 LangGraph 的“图”就是这个状态机的可执行模型（Week 2 的 model execution）。

8.4 LangChain 中的 RAG

Indexing（离线）：

  1. Load：用 Document Loaders 加载数据
  2. Split：Text splitters 把大文档切成小块（大块难检索，也放不进有限的 context window）
  3. Store：用 VectorStore + Embeddings 存储和索引

Retrieval and generation（在线）：

  1. Retrieve：用 Retriever 按用户输入检索相关块
  2. Generate：ChatModel/LLM 用包含问题 + 检索数据的 prompt 生成答案

（与 Week 5 的 “LLM 应用基本工作流三阶段” 一致。）

总结：RAG 专注于通过检索 + 生成提供准确信息；Agent 是解释复杂任务、促进交互、根据输入自动化行动的智能系统；LangChain 把两者集成起来。

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

  1. 元模型 = 描述模型的模型；地铁图的图例就是元模型。
  2. 建模语言四件套：抽象语法（概念与关系，唯一）、具体语法（记号，可多个）、语义域 + 两类映射。
  3. 元模型定义：规定抽象语法和良构规则，独立于具体语法；模型是元模型的实例。
  4. MOF：OMG 标准元建模语言，UML 的子集（类模型 + 模型组织，无行为），同样记号。
  5. 四层架构：M0 运行时对象 → M1 模型 → M2 元模型（UML）→ M3 元元模型（MOF，自描述）；判断层次问“它是谁的实例”。
  6. UML 规格三部分：抽象语法（MOF + 约束）、具体语法（不完整、非正式）、语义（英语 + fUML + 数学）。
  7. 图只是模型的视图；模型在仓库里是对象网络；可通过图或 API 创建元素。
  8. 元模型实例化题：框 → : Class，线 → : Association，线端 → : AssociationEnd {lowerBound, upperBound, modifier}。
  9. 静态语义 = 存在什么；动态语义 = 发生什么；四种语义定义方法：指称、翻译、操作、公理；fUML 用操作方法定义 UML 子集语义，自身用公理定义。
  10. NamedElement 至多属于一个 Namespace；依赖可以连接任意两个 NamedElement；注释可附于任意元素。
  11. 行为也是分类器：Activity（flow-based）、StateMachine（event-driven）、Interaction（event-driven 系统行为）。
  12. Method（被动对象，调用时）vs Classifier behaviour（主动对象，创建时）。
  13. Agentic 元模型：AgentType + Goal、Capability(effect)/Tool、Policy、Behavior(Steps + Transitions)、Memory、ExecutionPolicy、ApprovalPolicy/HumanRole——把有界自治写进语言。
  14. RAG：Load → Split → Store（离线）；Retrieve → Generate（在线）。LangGraph：Assistant ⇄ Tools 循环，tools_condition 决定去 Tools 还是 END。
  15. 易错：把 M1 的类说成 M2；以为具体语法决定语言；以为 MOF 包含行为建模。