第二部分：MDE 技术框架 1（元建模和建模）

元建模的"相对性"：模型 / 元模型 / 元-元模型

元建模是相对的——元建模的概念是相对于元模型和模型而言的；元模型是相对于模型而言的。 这是因为当一个模型 A 是从某个元模型 B 实例化而来时，A 又可以作为另一模型 C 的元模型使用——以递归的方式进行。

• 元建模：从建模语言的角度来理解模型元素并构造相应元模型的过程
• 元建模目标：构造元模型
• 建模目标：构造模型
• 元模型：相对于模型而言处于建模语言的层次
• 元-元模型：定义元模型的元模型

元模型层次与"建模语言族"

元模型层次定义了一个坐标体系，用于规定模型所处的抽象级别。每一种建模语言族都有一个特定的元模型层次——例如，MOF 为四层结构（OMG 标准），Ecore 和 KM3 为三层结构（学术/工业实践）。 最高层的元模型用于为建模语言族提供最终解释，并具有自解释的能力——即元-元模型自身符合自己。

• 元-元模型体系：指同一个建模语言族所形成的系统
• 每一个元-元模型体系具有一个特定的元模型层次
• 元-元模型体系有一个唯一的根，即元-元模型，该元-元模型也同时规定了这个体系的最终解释
• 例如：MOF 元-元模型体系、KM3 元-元模型体系、Ecore 元-元模型体系

• 建模语言族：由特定元-元模型所定义形成的建模语言家族
• 之所以需要建模语言族，是为了扩展语言的能力
• 在 MDA 框架下，MOF 定义了元-元模型的根，UML / CWM / QVT 等语言规范都可以由 MOF 给出解释——因此包括 MOF 在内的所有语言都可以看作同一个语言家族

• 建模语言族的形成依赖于元建模——不同的建模语言是通过同一个元-元模型进行定义的
• 建模语言的定义过程实际上就是元建模过程
• MDE 需要多种不同的建模语言：UML（统一建模语言）、MARTE / SysML（领域特定建模语言 DSL）
• 建模语言的定义和扩展都需要元建模的支持

MOF 2.0 的设计理念与"尴尬关系"

MOF 与 UML 的关系是 MDE 学术界最经典的"先有鸡还是先有蛋"问题——MOF 通过复用 UML 2.0 Infrastructure 的基础库来定义自身。换句话说：

• ① 易于定义和扩展现有的及新的元模型和软件基础设施的模型
• ② MOF 模型本身更模块化、更可重用
• ③ 使用模型重构来提高模型的可重用性
• ④ 确保 MOF 2.0 是技术平台无关的，并且可以实际映射到多种技术平台
• ⑤ 模型的正交性（关注点分离）——模型和服务/实用工具分离
• ⑥ MOF 2.0 用 MOF 自身来建模反射机制，而不是只把反射规定为一组技术特定的接口
• ⑦ MOF 2.0 建模"标识符"的概念
• ⑧ 通过更好的 MOF "Capabilities" 打包，在不同元层上重用建模框架和模型包

• EMOF（Essential MOF）：MOF 的精简子集——为简单元模型提供直接映射到实现（JMI、XMI）的框架；只支持简单概念
• CMOF（Complete MOF）：MOF 的完整版——用于指定 UML2 等复杂元模型；由 EMOF + Core::Constructs 合并而来

MOF 的四层元模型结构

OMG 标准的四层元模型体系是 MDA 框架的核心骨架。MOF 与 UML 在这一节里的关系被讲清楚了——MOF 在 M3 是元-元模型，UML 在 M2 是元模型；但 MOF 自身又是从 UML 2.0 Infrastructure 的 Core 包复用而来——这就是"尴尬关系"的根源。

MOF 的两种复用机制：包引入 vs. 包合并

MOF 通过复用 UML 2.0 Infrastructure 的 Core 包来定义自身，这一节讲清它如何复用——靠的是包引入（Package Importing）和包合并（Package Merging）两种复用机制。

• «import»：引入 public 元素（对所有用户可见）
• «access»：引入 private 元素（仅引入包内部可见）
• 引入后的模型元素可见性保持不变

• 包合并实际上等价于两个步骤的复合：
• ① 把包合并转换为相同 source/target 的包引入
• ② 通过泛化（Generalization）让新模型从 target 模型获得相应特征
• 这是 MOF 通过"组合两个更简单的机制"来定义复杂语义的标准套路

Ecore 的 3 层结构：把 M3 和 M2 合二为一

Ecore 是 Eclipse Modeling Framework (EMF) 元模型体系的根。EMF 是 Eclipse 平台官方支持的顶层项目，用于提供在 Eclipse 平台上进行建模的支撑。 EMF 是目前几乎所有 Eclipse 建模工具的基础——如 IBM Rational Rose、Topcased、Papyrus 等都基于或支持 Ecore。

• 核心部分通过 Structural Features（结构特征）和 Behavioral Features（行为特征）两大模块定义
• Structural Features 定义结构相关的元模型：类元、属性、数据等
• Behavioral Features 定义行为相关的元模型：操作及与操作相关的关联等
• Ecore 是通过多个模型图进行定义的——多图定义可以隔离关注点、降低整体定义的复杂性

看模型图的"两层"技巧：从叶子看 + 从分支看

Ecore 是用多个模型图定义的，如何读懂这些图就是元建模工程的基本功。这一节给出原讲义的两层技巧——先从叶子入手，再以分支叶子为中心。

• 如果模型图中有继承树，则尽量从继承树的最低端（叶子节点）开始看
• 然后沿着继承树从下往上的顺序依次看各个节点模型
• 如果有多个分支，分别处理多个分支——选择分支的先后顺序可以先从层次多的入手
• 最后综合多个分支理解整棵树的模型

• 以某个分支叶子节点为中心，沿着继承树从下往上理解模型
• 着重从继承关系理解模型图——继承是共性的抽取（从下往上看）
• 关注点分离：从一个分支开始理解模型时尽量不要联系其它分支

Ecore 五大构造块：Kernel / Structural / Classifiers / Operations / Packages

Ecore 元模型本质上由五大图谱组成，每张图描述一个独立的关注点。这一节按从底到顶的顺序铺开这五张图。

EReference 的 3 个核心标志：containment / container / resolveProxies

EReference 与 EAttribute 都继承自 EStructuralFeature，两者最大的不同是：EReference 对应复杂类型（引用其他类），EAttribute 对应简单类型（基本类型）。 这一节讲清 EReference 最独特的三个标志——理解它们就理解了一半 Ecore。

• eReferenceType：与 EAttribute 的 eAttributeType 类似——引用与 eType 相同的 EClassifier，但被转换为 EClass（派生引用）
• eOpposite：表示双向关联的反向——双向关联由两个 EReferences 组成，每个引用把对方定义为 eOpposite

• containment：表示整体-部分关系（whole-part relationship）——更"强"的关联
  规则：① 对象不能直接或间接包含自己的容器；② 一个对象最多有一个容器；③ 对象的生命周期随容器结束
• container：派生属性——如果 containment 关系是双向的，则反向引用的 container 属性为 true
• resolveProxies：与 EMF 的资源模型的持久化相关——当资源被加载时，其他资源中持久化的被引用对象用代理表示；当首次访问时，资源被加载并返回真实对象

Ecore 与 MOF 的对比：3 层 vs 4 层

讲完 Ecore 后，自然要回答"Ecore 与 MOF 到底有什么本质区别"。原讲义的结论：Ecore 不止是 EMF 的元-元模型，同时还扮演了建模语言的角色——它不是单纯模仿 MOF，而是选择了不同的抽象点。

KM3 的设计动机：14 类的极简主义

KM3（Kernel MetaMetaModel）是 AtlanMod group 设计的元-元模型。它的设计目的是"为 DSL 提供一个简单的元模型定义方案"。 KM3 比 MOF 1.4（28 类）和 Ecore（18 类）更精简——只包含 14 个类，只保留其他元-元模型最核心的概念。

• 目的：为 DSL 的定义提供一个相对简单的解决方案——尤其是领域定义元模型（Domain Definition Metamodel）
• 特性：KM3 是一种专门的文本语言用于指定元模型（包括 MOF 元模型）
• 风格：类似于 OMG 标准的"风格"，但更简化
• 应用：KM3 是模型转换语言 ATL 的基础；是 Eclipse Modeling 官方版本的重要插件
• 结构：KM3 也是 3 层（与 Ecore 类似）

KM3 的形式化基础：一阶谓词逻辑

KM3 不只是"14 类的极简设计"，它还给了形式化的元模型定义——这让它能在工具链中被验证。这一节用一阶谓词逻辑定义 KM3 的核心概念。

• 一个有向多重图 G=(N_G, E_G, T_G) 由有限节点集 N_G、有限边集 E_G、和映射 T_G: E_G → N_G × N_G（边到源/目标节点）组成

• 一个模型 M = (G, ω, μ) 是一个三元组：
• G = (N_G, E_G, T_G) 是一个有向多重图
• ω 本身是一个模型（称为 M 的参考模型），关联一个图 G_ω = (N_ω, E_ω, T_ω)
• μ : N_G ∪ E_G → N_ω 是一个函数，把 G 的元素（节点和边）关联到 G_ω 的节点
• 注：μ 既不是单射也不是满射——这意味着多个模型元素可以共享一个元模型元素

• Definition 3：元-元模型是其自身参考模型的模型（self-conforming）
• Definition 4：元模型是其参考模型是元-元模型的模型
• Definition 5：终止模型是其参考模型是元模型的模型

• DSL 是一组协调的模型——每个模型贡献其定义的一部分
• 一个给定的模型可以规约以下方面之一：
• · 领域定义元模型（Domain Definition Metamodel）
• · 具体语法（Concrete Syntaxes）
• · 执行语义（Execution Semantics）
• · DSL 上的其他操作（Other Operations on DSLs）

SimpleKM3：核心两谓词 + 8 条公理

KM3 的形式化定义用两个核心谓词 + 8 条公理来描述SimpleKM3——这是 KM3 的极简子集，只含 classes 和 references。

• Node(x, y)：节点 x ∈ N_G 通过函数 μ 与节点 y ∈ N_ω 关联
• Edge(x, y, z)：节点 x 和 y 之间的边通过函数 μ 与节点 z ∈ N_ω 关联

• 1. Node(class, class)
• 2. Node(reference, class)
• 3. Node(features, reference)
• 4. Node(type, reference)
• 5. Edge(class, features, features)
• 6. Edge(features, reference, type)
• 7. Edge(reference, type, features)
• 8. Edge(type, class, type)

• ① 元元素唯一性 (Metaelement uniqueness)：μ 作为函数，对给定模型节点只能关联单一元元素
• ② 节点的元元素是 class (Node metaelements are classes)：用作另一个节点元元素的节点必须有 class 作为其元元素
• ③ 边的元元素是 reference (Edge metaelements are references)：边只能存在于节点之间，必须有 reference 作为其类型
• ④ 边的目标 (Edge target)：由 reference z 类型的边只能以节点 y_t 为目标，如果 z 的类型是 y_t
• ⑤ 边的源 (Edge source)：由 reference z 类型的边只能以节点 x_t 为源，如果 z 是 x_t 的 feature
• ⑥ 引用类型唯一性 (Reference type uniqueness)：一个 reference 有唯一的类型

SimpleKM3 的扩展：Opposite + Inheritance

SimpleKM3 只支持 classes 和 references——不够用。原讲义展示了如何通过增量添加新节点和边来扩展支持 Opposite（双向引用）和 Inheritance（继承）。这是 MDE 元建模的典型做法。

• 意义：双向导航需要 Opposite Reference 的支持——通过 class 获得 features，但无法对给定 feature 得到对应的 class
• 新增定义：
• 9. Node(opposite, reference)
• 10. Edge(reference, opposite, features)
• 11. Edge(opposite, reference, type)
• 新增约束：
• · Opposite uniqueness（opposite 唯一性）
• · References work in pairs（reference 必须成对）
• · Opposite references have opposite extremities（opposite 引用的两端互换）

• 思路：Inheritance 针对 Class 而言，因此需要对 Class 增加描述 inheritance 的 reference
• 先定义描述 supertype 的语义以及 Node
• 再定义相应的 reference
• 新增定义：
• 17. Node(supertypes, reference)
• 18. Edge(class, supertypes, features)
• 19. Edge(supertypes, class, type)

• 挑一个你想建模的小领域（电商订单 / 学校选课 / 图书馆借书），用 KM3 的 14 类 + SimpleKM3 的 6 条公理+Opposite+Inheritance 扩展，写出这个领域的元模型
• 对照原讲义 161-162 页的 "Families" / "Persons" 例子，看看你写的版本和它们的差距在哪里

MOF / Ecore / KM3 三家取舍的全景对比

MOF 2.5.1 的版本演进与"为什么工业用 Ecore 而不用 MOF"

讲义讲授的是 MOF 2.0（讲义 p.18-21）。OMG 规范目录中，MOF 当前正式版本为 2.5.1（2016-10），并提供 CMOF/EMOF 的 OCL 约束文件与 MOF.xmi 机器可读文件。

EMF 2.44.0 生态全景（2026-09）——讲义 p.65"几乎所有 Eclipse 工具"具体指哪些

讲义 p.65 说"几乎所有 Eclipse 建模工具基于（或支持）Ecore"。本调研基于 Eclipse 官方发布记录核验： EMF Ecore Core Runtime feature 2.44.0（构建时间戳 20260704-1256，随 Eclipse 2026-09 同步发布）、EMF 2.47.0 发布线；Maven Central 上 org.eclipse.emf.ecore 最近发布为 2026 年 2 月。"几乎所有 Eclipse 建模工具基于 Ecore"这一判断在 2026 年依然成立，且生态已扩展为：

KM3 的出处 + Atlantic Zoo（230+ 元模型）——讲义没说的工程生态

讲义 p.152-156 介绍 KM3 的设计哲学"14 类极简"。本调研补充 KM3 的学术出处与生态：

• Atlantic Zoo：ATL 官方的开源 KM3 元模型库，收录 230+ KM3 元模型，同时提供 MOF、UML、Prolog、SQL、GME 等"镜像 zoo"
• ATL 转换库：KM3 to Measure、KM3 to Metrics、KM3 to OWL、KM3 to Problem、KM3 to XML 等——这些是课程设计"元模型处理"实验的最佳素材库
• ATL 维护方：OBEO 与 AtlanMod（INRIA），代码托管于 github.com/eclipse-atl/atl，最新稳定版本 4.9.0（2023-12）

• KM3 不支持操作（operation），因此没有参数与相关结构
• KM3 的 StructuralFeature 比 Ecore 的 EStructuralFeature 简单（不支持默认值、defaultValueLiteral、derived 属性）
• 但 KM3 支持 subsets 与 derived unions
• KM3 的 Metamodel 没有 URI 命名空间定义，语言标识仅依赖名称——在跨工具交换场景下这是 KM3 的明显短板，也解释了为何 ATL 生态最终仍以 Ecore 作为运行时表示

feature ID 设计动机 + nsURI 元模型身份——讲义没说透的 Ecore 设计

讲义 p.99-100 提到 feature ID 与 container class，但没讲它们为何存在。本调研补充两个对"Ecore 是面向 Java 的实现"至关重要的设计细节：

• EMF 代码生成的 feature ID 模式 → 抽象语法必须考虑实现层的兼容性
• nsURI 是元模型演化的最小代价点 → 让学生在实验中亲历一次"破坏性升级"