门户首页
MDE 高级讲义 · 第一部分 · 导论

第一部分：导论（MDE 背景）

这一讲从"过去 50 年软件开发的抽象层次演进"讲起——机器码 → 汇编 → 3GL → 面向对象 → 中间件——落到 OMG 四标准（UML/MOF/XMI/CWM）与 MDA 框架，再解释从 MDA 到 MDE 的术语跃迁。讲清楚"为什么要做 MDE"，是后面元建模和模型转换部分的前提。

生成时间：2026-09-22 · 版本 v0.2（v0.2 在 v0.1 基础上融入《模型驱动工程-导论与元建模-深度调研报告-2026.09》要点：OMG 2025 治理变更 + MDA 四标准现状核验 + SysML v2/KerML 引入 + MDE 挑战的实证现状 + LLM×MDE 双向赋能）· 原始讲义 55 张幻灯片 · 整理为 5 篇 11 卡片 7 图 5 表 · 生成 Agent：MiniMax Code (LLM: MiniMax-M3) · 载体：agentsoft-research-platform teaching-web-platform · 来源：南京大学张天《软件方法学》课程 2025 秋季 + 配套深度调研报告 2026.09
← 返回 MDE 模块入口 下一篇：第二部分 · 元建模和建模 → 姊妹：UML 架构建模专题

概览

3
抽象阶段
4
OMG 核心标准
4
四层元模型
2001
MDA 推出年
项目说明
本页定位MDE 模块第一部分，回答「为什么」——MDE 怎么来的、要解决什么问题、它的术语怎么从 MDA 演化到 MDE
前置知识了解任意一门面向对象语言、一段 3GL 编译器输出与运行时的工作机制；不必懂建模或元模型
读完会什么 能复述过去 50 年软件抽象层次的三阶段演进；能说出 OMG 四标准（UML/MOF/XMI/CWM）的分管与协作；能区分 MDA、MDE 与"以模型为中心软件开发"；能用自己的话讲清 M3/M2/M1/M0 四层结构
不讲什么不讲具体建模工具、不讲元建模的工程方法（这在第二部分讲）；不讲模型转换（这在第二部分 3 讲）

第一篇 · 压力与进步：过去 50 年的抽象层次演进

第一篇 · 抽象层次的代价与回报（第 1 章）
这一篇回答"为什么软件开发一直在升抽象层次"——它不是某个天才的偏执，而是"质量 / 成本 / 生命周期"三要素反复失衡逼出来的工程共识。
第 1 章 · 1 模型 + 1 视图

经济可行性变量与软件产业发展

软件开发的经济可行性取决于"在何种程度上开发出质量和生命周期与开发成本相匹配的软件系统"——三要素中的任何一项"溢出"都会破坏经济性。 而软件产业的整体可行性是对生产成本、质量和生命周期进行权衡和平衡的结果——这就是为什么"当现有方法不再能适应不断增长的需求时，新的方法就会被提出"。

核心论点
  • 三要素平衡是软件工程的根本问题——质量、生命周期、成本三者构成三角张力
  • 每次抽象层次的提升，都把三角推向新的平衡——但每一次提升也都带来新的挑战
  • "提高抽象层次"是过去 50 年最有效的工程共识（Stephen J. Mellor, MDA Distilled, 2004）
三个抽象阶段
  • 以机器为中心的计算：0/1 指令 → 汇编语言（仍是机器导向）
  • 以应用为中心的计算：3GL（FORTRAN/COBOL → C/Pascal → Smalltalk/C++）+ 操作系统 + 虚拟机
  • 以企业为中心的计算：基于组件开发 + 分布式计算 + 中间件（CORBA / J2EE / .NET）
  • 新的压力……（这一波的下文就是 MDE）
关键引文（Stephen J. Mellor, 2004）："过去的 50 多年里，人们利用'提高解决问题的抽象层次'处理软件开发的问题已经取得了两个较为显著的进展：开发出了具有较高抽象层次的程序设计语言；能够在更高抽象层次上实现软件复用。"
第 2 章 · 1 模型 + 1 反例

中间件分化（proliferation）→ MDA 的诞生

90 年代是中间件高速发展期，但"没有最终赢家"：CORBA、J2EE、.NET、COM/DCOM、WEB/SOAP 百花齐放。中间件分化（proliferation）导致企业业务逻辑与特定中间件平台实现技术的"绑定"——提升信息系统平台移植难度，加大了企业业务发展受制于某种平台技术发展的风险。 企业将为不同中间件应用系统的集成付出昂贵代价。

核心论点
  • 中间件分化暴露的三大问题：互操作性、可移植性、可重用性
  • OMG 在 1997 年起以 UML 为核心陆续颁布几个重要的技术无关建模标准
  • 2001 年，OMG 正式推出框架规范 MDA，整合 OMG 在建模领域发布的一系列标准
flowchart TB C["以企业为中心的计算
90 年代中间件高速发展"] C --> P["中间件分化 (proliferation)
CORBA · J2EE · .NET · COM · WEB
无最终赢家"] P -->|"暴露"| X["三大新挑战
互操作性 / 可移植性 / 可重用性"] X -->|"催生"| M["OMG 标准化应对（1997 起）
UML + MOF + XMI + CWM"] M -->|"2001 集成"| D["MDA 框架
Model-Driven Architecture"]
图 1 · 从中间件分化到 MDA 框架的因果链：90 年代异构性挑战 → OMG 标准化 → MDA 框架（整理自原讲义 19-22 页）
思考与讨论
  • 如果当年 CORBA 一统天下，今天的中间件生态会是什么样？MDA 还有诞生的必要吗？
  • 云原生时代（SaaS / 微服务 / K8s）是否又在"分化为新一轮中间件分化"？这一波的标准化会来自哪里？
参考：Frankel (2003), Mellor et al. (2004) 原文：原讲义 19-22 页

第二篇 · MDA 的主要思想与三层抽象

第二篇 · MDA 三层抽象（PIM / PSM / CIM）与软件生命周期（第 2 章）
这一篇回答"MDA 怎么工作"——核心是分离业务功能分析与实现技术，通过模型映射把 PIM 自动转化为多种 PSM，再求精到代码。
第 3 章 · 1 模型 + 1 视图

MDA 的核心思想：把业务与实现技术解耦

MDA 的主要思想是分离业务功能分析与设计和实现技术与平台之间紧耦合的关系，从而将技术与平台变化对系统的影响降低到最小程度。 它极大地加强了应用模型与领域模型在整个软件生命周期中的复用。

MDA 的三层抽象
  • PIM（Platform-Independent Model）：与实现技术和平台无关、描述系统设计层次的模型
  • PSM（Platform-Specific Model）：与具体实现技术和平台相关的应用模型
  • 映射规则：MDA 将 PIM 抽象出来，针对不同实现技术与平台制订多个映射规则
  • 反复求精：通过映射规则及辅助工具将 PIM 转换成 PSM，再将 PSM 不断求精直至形成最后代码
flowchart LR PIM["PIM
Platform-Independent Model
与平台无关的设计模型
· 业务功能
· 行为（OCL 约束 + Action Language）
· 用 OCL 表达前置/后置条件"] PIM -->|"标准映射规则
MDA 工具部分自动 + 部分手写"| PSM_CORBA["PSM (CORBA/CCM)
CORBA specific model"] PIM -->|"标准映射规则"| PSM_EJB["PSM (J2EE/EJB)
EJB specific model"] PIM -->|"标准映射规则"| PSM_XML["PSM (SOAP/XML)
XML specific model"] PIM -->|"标准映射规则"| PSM_NET["PSM (DCOM/.NET)
.NET specific model"] PIM -->|"标准映射规则"| PSM_WEB["PSM (WEB/WSDL)
WEB specific model"] PSM_CORBA -->|"MDA 工具生成
+ 人工补充"| CODE["最终代码"] PSM_EJB --> CODE PSM_XML --> CODE PSM_NET --> CODE PSM_WEB --> CODE
图 2 · MDA 的 PIM → 多个 PSM → 代码映射全景图（整理自原讲义 25-29 页）
MDA 带来的好处
  • 增强软件复用性——同一份 PIM 可派生出多种平台的实现
  • 增强软件可移植性——迁移只需替换映射规则，模型不变
  • 提高软件开发效率、降低成本——大量代码生成自动完成
  • 降低软件维护成本——业务变更只需改 PIM
  • 推动软件自动化进程——从手工编码转向模型驱动
课堂讨论
  • 为什么不是所有行业、所有项目都适合 MDA？什么样的项目不适合？
  • PIM 抽象到何种程度才算"平台无关"？抽象过度会不会反而失去商业价值？
原文：原讲义 23-34 页 参考：Raistrick et al. (2004), 《MDA Distilled》
第 4 章 · 1 模型 + 1 视图

MDA 的软件生命周期：迭代四阶段

MDA 软件开发生命周期与传统的瀑布模型不同——它分为需求分析、设计、实现、测试和发布几个阶段，每个阶段都是一个迭代过程，且每个阶段的输出都是下一阶段的模型输入。

四阶段生命周期
  • 需求分析阶段：输出 CIM（Computation Independent Model）——只关注业务领域，不涉及计算细节
  • 高层设计阶段：通过模型转换从 CIM 生成 PIM
  • 低层设计阶段：通过模型转换从 PIM 生成 PSM
  • 代码实现阶段：通过模型转换从 PSM 生成基于特定平台的系统实现代码
  • 迭代测试 + 发布：每阶段都伴随模型验证与一致性检查
flowchart LR CIM["CIM
Computation Independent Model
业务域 + 业务规则"] PIM["PIM
Platform-Independent Model
不绑定实现技术"] PSM["PSM
Platform-Specific Model
对应具体中间件"] CODE["系统实现代码
基于特定平台"] CIM -->|"模型转换
（高层设计阶段）"| PIM PIM -->|"模型转换
（低层设计阶段）"| PSM PSM -->|"模型转换
（代码实现阶段）"| CODE
图 3 · MDA 生命周期的四阶段模型转换：每个箭头都是一次"模型到模型"或"模型到代码"的转换（整理自原讲义 32 页）
关键洞察：MDA 不是"画 UML 图 → 直接出代码"——它强调模型到模型的转换（PIM→PSM）和模型到代码的转换（PSM→Code）都是一等公民。这意味着转换规则本身也需要被设计、被验证、被维护——这是后续"模型转换"讲义的引子。
原文：原讲义 32 页 参考：OMG MDA Guide v1.0.1 (2003)

第三篇 · MDA 的核心：四个 OMG 标准与四层元模型

第三篇 · 标准与元模型（MDA 的"骨架"）
MDA 是一个框架性标准，它的"骨架"由 OMG 在 1997 年起颁布的四个技术无关建模标准组成——本篇把它们与四层元模型体系一一对应。
第 5 章 · 1 模型 + 1 视图

OMG 四标准：UML / MOF / XMI / CWM

从 1997 年起，OMG 以 UML 为核心陆续颁布了几个重要的技术无关建模标准，2001 年整合为 MDA 框架。本节逐一介绍这四个标准的角色与分工。

标准英文核心职责
UML Unified Modeling Language 统一的通用面向对象分析和设计的图形化建模语言，致力于实现软件系统可视化、规范定义、构造、文档化建模。MDA 推荐但并不强制使用 UML——PIM/PSM 也可以用其他建模语言描述。
MOF Meta Object Facility 标准的建模与交换结构——是 OMG 元模型体系的根基，支撑模型在工具间传输、存储、变换、渲染、代码生成
XMI XML Metadata Interchange 基于 XML 的元数据交换标准格式——独立于任何开发商或技术；使模型可以在元模型层得到良好支持
CWM Common Warehouse Metamodel 数据仓库和业务分析领域的标准元模型——为异构软件系统间的元数据交换提供基于模型的方法
MOF 的核心定位（引用原文）：MOF 是模型的基础——MOF 模型可以被导出、跨网络传输、存储到仓库并检索、按不同格式渲染（包括 XMI）、转换、用于生成应用代码。
课堂思考
  • 为什么这四个标准是"框架性"而非"工具性"的？它们的真正价值是定义概念还是定义接口？
  • XMI 是不是过时了？现在模型序列化还常用 XMI 吗？（提示：想想 EMF 用什么格式持久化）
原文：原讲义 20, 35, 50-55 页 参考：OMG (2006), MOF 2.0 Core Specification
第 6 章 · 1 模型 + 1 视图

四层元模型体系：M3 / M2 / M1 / M0

MDA 把元模型分为 4 层，由 MOF 给出最终解释。这一节讲清楚每一层的角色，并通过一个具体例子（Customer / Order / 张三/李四）把四层串起来。

层次描述典型元素
M3 元-元模型（由 MOF 定义） MOF 类、MOF 属性、MOF 关联……（MOF 自身就是 M3 的实例）
M2 元模型（由 MOF 构造的实例） UML 类、UML 状态、UML 属性、UML 活动……
M1 模型（由 M2 元模型构造的实例） "Customer" 类、"Employee" 表……
M0 对象和数据（M1 模型构造的实例） 客户"张三"、员工"李四"、员工号"A2004"……
flowchart TB M3["M3 · 元-元模型层
MOF Class · MOF Attribute · MOF Association
（MOF 自身的元素）"] M2["M2 · 元模型层
UML Class · UML Attribute · UML State
（由 M3 元素实例化得到）"] M1["M1 · 模型层
Customer 类 · Order 类
（由 M2 元素实例化得到）"] M0["M0 · 对象层
客户「张三」· 订单「A2004」
（由 M1 元素实例化得到）"] M3 -.->|"<<instance of>>"| M2 M2 -.->|"<<instance of>>"| M1 M1 -.->|"<<instance of>>"| M0
图 4 · 四层元模型体系：每一层都是下一层的实例化结果，最底层的实例是真实业务对象（整理自原讲义 45-46 页）
关键洞察（"相对性"）：元模型与模型的概念是相对的——任何模型 A 若有另一模型 B 是它的元模型，则 B 又可以是某个模型 C 的实例模型。这就是"反射式建模"（reflective metamodeling）的根基。元-元模型（如 MOF）的特殊之处在于它是自身的实例（self-conforming）——这一性质保证体系可以无限扩展而不需要无穷回归。
课堂实训
  • 用 Java 类做比喻：java.lang.Class 是 M3，String.class 是 M2，"hello" 字符串对象是 M1 的实例吗？（提示：String 没有 prototype 字段——看看 String 的反射）
  • 设计一个"学生选课"系统的四层：M3 = Java 元类；M2 = Student/Course 类定义；M1 = 一个具体的选课系统对象图；M0 = 真实学生和课程的数据行
原文：原讲义 44-49 页 参考：Atkinson & Kühne (2003), "The Concept of a Metamodel"
第 7 章 · 1 模型 + 1 视图

OMG 四标准对四层元模型的"分管"

把 OMG 四标准与四层元模型叠在一起看，能看出每个标准分管哪一层——这是 MDA 框架最精巧的设计。

flowchart TB L0["M0 · 客观世界
Real Systems / Enterprise Computation / Information"] L1["M1 · 应用模型层
UML Models · CWM Models · XMI Models
（CIM / PIM / PSM 等具体建模结果）"] L2["M2 · 模型语言层
UML Meta-Model · CWM Meta-Model · XMI Meta-Model
（这些语言规范本身都是 M2 的元模型）"] L3["M3 · 模型语言定义层
MOF Meta-Meta-Model
（MOF 是所有语言规范的根）"] L3 -->|"定义"| L2 L2 -->|"实例化"| L1 L1 -->|"对应"| L0
图 5 · OMG 四标准对四层元模型的分管矩阵：MOF 在 M3，UML/CWM/XMI 在 M2，应用模型在 M1（整理自原讲义 51 页）
核心论点
  • MOF 在 M3——它是所有元-元模型语言的根
  • UML / CWM / XMI 在 M2——它们是具体的建模语言（元模型）
  • 应用模型在 M1——CIM、PIM、PSM 等
  • 现实系统在 M0——企业的真实业务对象
关键洞察：UML 在 M2 是因为它本身就是"建模语言的元模型"——UML Class 这个概念是定义你的 Customer 类应该长什么样的元语言；而你用 UML 画出来的具体 Customer 类就在 M1。这种"语言在第 2 层，语言写出来的东西在第 1 层"的分层，正是 MDA 框架能跨域复用的根本原因。
原文：原讲义 51 页 参考：OMG, "UML 2.0 Infrastructure Specification"

第四篇 · 从 MDA 到 MDE：术语的演化与核心思想

第四篇 · MDE 的核心思想与三大挑战
MDA 提出 5 年后，学术界用 MDE 这个术语取代了它——背后是研究视野从"框架标准化"扩展到"模型驱动的全部工程实践"。
第 8 章 · 1 模型 + 1 视图

MDE 的诞生：术语演化与核心思想

2005 年，模型驱动软件开发领域最重要的年会之一 UML series（International Conference on the Unified Modeling Language）正式更名为 MoDELS/UML series（International Conference on Model Driven Engineering Languages and Systems）。 2007 年，模型驱动工程这个术语正式出现在第 29 届 ICSE 年会的 FoSE（Future of Software Engineering）分会上——可以看作 MDE 成为模型驱动软件开发领域代名词的标志。

相关术语的并列
  • model-driven · 模型驱动
  • model-based · 基于模型
  • model-related · 与模型相关
  • model-engineering · 模型工程
MDE 的核心思想
  • 以模型为首要软件制品（software artifact）
  • 通过建模为问题域构造软件系统的业务模型
  • 然后依靠模型转换（model transformation）驱动软件开发
  • （半）自动地产生最终完备的应用程序
经典引文（Douglas C. Schmidt, IEEE Computer 2006）：模型驱动工程以模型为首要软件制品（software artifact），通过建模为问题域构造软件系统的业务模型（business model），然后依靠模型转换（model transformation）驱动软件开发，（半）自动地产生最终完备的应用程序。

Frankel (2003) 的补充视角：有学者认为模型驱动的思想，或者说以模型为中心的软件开发思想正是抽象层次提高到一定程度的一个自然而然的结果——这与第一篇"压力与进步"的论述遥相呼应。
原文：原讲义 37-39 页 参考：Schmidt (2006), Frankel (2003)
第 9 章 · 1 模型 + 1 视图

MDE 中"模型"的概念：广义与狭义

在 MDE 中，模型指的是为了分析或解决问题而对系统某些方面的抽象描述。"模型"这个概念在不同语境下有两层含义，需要区分清楚。

广义模型
  • 涵盖了软件系统的任意部分——需求、设计、文档、代码、部署、配置和测试用例等
  • 代码也可以看作软件系统的模型——它是对"系统应该如何工作"的另一种抽象描述
  • 广义模型让我们理解"为什么 UML 之外还有这么多建模语言"——因为建模对象不止是软件结构
狭义模型（MDE 默认含义）
  • 通常所指的 MDE 下的模型，更多的是狭义上的"设计草图"——即今天的开发模型
  • 狭义模型聚焦于"从分析到设计再到实现"这一段
  • 狭义模型背后是"系统应如何在某个平台上运行"的精确规范
flowchart TB WIDE["广义模型
需求 · 设计 · 文档 · 代码 · 部署 · 配置 · 测试用例
（涵盖软件系统任意部分）"] NARROW["狭义模型（MDE 默认）
PIM / PSM / 设计草图
（聚焦分析到实现的精确规范）"] WIDE -->|"聚焦于"| NARROW
图 6 · MDE 中的"模型"概念：广义涵盖一切软件制品，狭义聚焦"分析到实现"的设计草图（整理自原讲义 40 页）
课堂思考
  • 如果"代码也是一种模型"，那 MDE 是把代码抽象成更高层的模型，还是另外发明一种新的模型体系？这两者有什么本质区别？
  • LLM 代码生成时代的 MDE：模型不再只是结构图，还包括自然语言规约、训练数据、prompt——这算广义还是狭义？
原文：原讲义 40 页
第 10 章 · 1 模型 + 1 视图

MDE 的三大挑战：建模语言 / 关注点划分 / 模型操纵

Robert France 等将目前 MDE 工作中最重要和亟待解决的问题归结为如下几类挑战。MDE 不是已经解决了所有问题——它本身仍是一个研究中的范式。

挑战类别具体问题
建模语言的挑战 如何使建模语言支持在问题层面上进行建模
如何对模型进行严格的分析
关注点划分的挑战 对同一系统进行多视图建模（multi-view modeling）的结果——如何让不同视图保持一致？
模型操纵和管理的挑战 对模型转换的定义、分析和使用
维护模型元素间的可追溯性（traceability），以支持模型演化和双向工程
维护不同视点（viewpoint）之间的一致性
版本追踪——模型也是软件制品，需要版本管理
在运行期使用模型（models@runtime）——模型不只是开发期产物
关键洞察：三大挑战看似独立，其实是耦合的——建模语言决定关注点如何划分，关注点划分决定模型结构，模型结构又决定了模型操纵的难度。MDE 不是解决了"用模型代替代码"就完事，它的核心难度在于让模型成为一个可维护、可演化、可分析的一等软件制品。
课堂实训
  • 挑一个你熟悉的开源项目（Spring Boot / Django / Kubernetes 等），列出 3 个"维护模型元素可追溯性"的真实痛点
  • LLM 时代的 MDE："AI 生成的代码"和"AI 生成的模型"在可追溯性上有何区别？
原文：原讲义 41-43 页 参考：France et al. (2007), "Model-driven Development of Complex Software"

第一部分小结 · 从历史到标准再到挑战

第一部分小结 · 五个 takeaway
这一讲把"MDE 是什么、为什么"铺完了，下一讲（第二部分）开始讲"怎么用 MDE"——具体就是元建模和建模。
小结 · 5 条 takeaway

第一部分收尾：把"MDE 是什么"装进口袋

核心 takeaway
  • 历史观：过去 50 年"提高抽象层次"是软件工程的核心驱动力——机器 → 应用 → 企业三段演进，每段都把三角张力推向新的平衡
  • 标准化：中间件分化倒逼 OMG 在 1997-2001 年间颁布 UML/MOF/XMI/CWM 四标准 + MDA 框架
  • 核心思想：MDA 用 PIM/PSM/CIM 三层抽象分离业务与平台；MDE 把这一思想扩展为"以模型为首要软件制品 + 模型转换驱动"
  • 四层元模型：M3/M2/M1/M0 四层结构是 MDA 的骨架——MOF 在 M3，UML/CWM/XMI 在 M2，应用模型在 M1，真实系统在 M0
  • 三大挑战：建模语言、关注点划分、模型操纵——MDE 不是终态，而是持续演化的研究范式
下一讲预告：第二部分《元建模和建模》会回答"MDE 靠什么工具落地"——讲清 MOF / Ecore / KM3 三大主流元-元模型，看懂它们的取舍点。这是 MDE 从"标准"走向"工程"的关键一跳。
下一篇：第二部分 · 元建模和建模 → ← 返回 MDE 模块入口

第五篇 · 2026 调研深读：从讲义到前沿

第五篇 · 讲义没说透的，2026 调研补遗（第 11 章）
这一篇是 v0.2 增量——基于《模型驱动工程-导论与元建模-深度调研报告-2026.09》。把讲义停留在 2001 年视角的内容，更新到 2026 年现状：OMG 治理主体变更、MDA 四标准 2026 年官方状态、SysML v2/KerML 的工业落地、MDE 挑战的实证研究、LLM × MDE 的研究议程。
v0.2 增量 · 第 11 章

OMG 治理变更（2025 年 7 月 / 10 月）——讲义「800 多家成员」的现状

讲义 p.22 介绍 OMG「1989 年 4 月由 8 个公司发起，目前有 800 多家成员」——这一表述在 2025 年已经过时。本报告援引 OMG 与 EDM Council 的官方新闻稿：

关键变更（建议在课堂上明确修订）：
  • 2025-07-01：EDM Council 签署最终协议收购 OMG，合并后更名为 EDM Association；交易于 2025-10-01 完成资产收购
  • 合并后 EDM Association 拥有 700 余家企业与公共部门成员、8 个区域中心；OMG 的标准制定组织（SDO）及其社区（Digital Twin Consortium、AREA、CISQ 等）在新架构下继续运作
  • 讲义原表述宜更新为：「OMG 是 1989 年成立的标准联盟，2025 年 10 月起其资产与标准业务归入 EDM Association，UML/SysML/CORBA/BPMN 等标准由 OMG SDO 继续维护」
  • 对标准治理的潜在影响（是否会引入分层会员制、标准化节奏是否变化）在业界存在公开讨论，可作为课堂讨论议题
教学价值
  • 让学生看到 「标准组织 ≠ 永恒」——标准是产业共识的产物，产业重心转移会直接改写标准的归属
  • 引导学生关注标准的"已发布"与"当前活跃"的差异——OMG 目录中"formal"只表示曾正式发布过，不等于今天仍在维护
  • 为第二部分"为什么 Ecore 在工业上胜过 MOF"提供治理层面的解释
调研报告引用：[16] EDM Council/OMG 2025-07-01 合并新闻稿 + 2025-10-01 完成公告 深入：03-frontiers.html · 第一节"OMG 治理变更"
v0.2 增量 · 第 12 章

MDA 四标准 2026 年状态核验表——讲义没说的事实

讲义 p.50 列出 MDA 四大核心标准：UML、MOF、CWM、XMI。这些标准在 2026 年的官方状态与讲义讲述时（2001-2005）大不相同。本调研基于 OMG 官方规范目录核验如下：

标准讲义表述2026 年最新正式版本状态判断
UML 标准通用 OOAD 图形化模型语言 UML 2.5.1（2017-12，formal/17-12-05） 事实停滞但仍是基石；OMG 2026 Q2 议程设有 UML 2.6 修订任务组
MOF 标准的建模与交换结构 MOF 2.5.1（2016-10） 稳定维护；EMOF/CMOF 双轨结构延续，新增 Identifier、通用 Tag、泛型反射
XMI 信息交换的标准格式 XMI 2.5.1（2015-06） 稳定；ISO/IEC 19503（对应 XMI 2.0）、ISO/IEC 19509（对应 2.4.2）
CWM 数据仓库的标准 CWM 1.1（2003-03，唯一正式版本） 已实质停滞 20 余年，被后来的数据治理/知识图谱体系取代
QVT （元模型层次图中出现）模型转换语言标准 QVT 1.3（2016-06） 三语言结构（Relations/Core/Operational）未变；工业界更常用 ATL、Epsilon 等非 OMG 方案
CWM 的教学处理建议：建议把 CWM 作为"标准生命周期"的案例——一个标准即使技术上合理，也会因产业重心转移（数据仓库 → 大数据 → 数据湖仓 → 数据治理与知识图谱）而自然退场。
关键引文
  • OMG 目录"formal"状态只表示正式发布过，不表示" currently active"
  • 讲义应增加一句"本表数据基于 2026 年 9 月 OMG 规范目录核验"的脚注
  • QVT 是讲义第二部分后续"模型转换"将涉及的核心标准，本表将其一并列出
调研报告引用：[10][11][12][13][14] OMG 规范目录 深入：03-frontiers.html · 第二节"MDA 四标准现状"
v0.2 增量 · 第 13 章

MDE 三大挑战在 2026 年的实证现状——Störrle / Lano / Akthar 三项研究

讲义 p.41 引用 Robert France 把 MDE 挑战归为建模语言 / 关注点划分 / 模型操纵与管理三类。二十年后这些挑战解决了吗？近期三项实证研究给出了冷静的答案：

研究方法关键发现
Störrle (MODELS Companion '24) 对德国汽车工业 6 位资深专家的质性研究 MDE 确能兑现部分通用承诺，但行业特定因素（尤其是供应链管理与协同）才是决定采纳与否的关键；这解释了 MDE 采纳在行业间极不均衡
Lano, Alfraihi & Haughton (AMDE 2024) 基于 25 年 349 篇文献的系统综述 MDE 在质量与生产率上的收益得到公认，但所需投入的专业技能与工具可用性始终是最大障碍；敏捷 MDE 在汽车与电信领域取得了显著落地
Akthar 等 (ICSOFT 2024) 从业者问卷调查 约 75.1% 受访者在项目中使用系统建模，其中 56.3% 认为它确实简化了开发；同时指出模型质量、可扩展性、与既有系统的对齐是主要痛点
结论：讲义列出的三类挑战在 2026 年依然是"活着的"挑战——只是第三条中的"可追溯性/一致性/版本管理"已部分被工程化（模型比较与合并工具、模型仓库、SysML v2 的标准 API 见 §3.5），而第一条"在问题层面建模"正被 LLM 辅助建模重新激活。
课堂讨论议题
  • Störrle 的汽车行业研究说明"为什么同样的 MDE 在汽车业成功而在其他行业失败"——情境判断比技术崇拜更重要
  • 工业采纳的现实约束：工具可用性、专业技能、与敏捷/CI/CD 的融合、行业特定协同
  • LLM × MDE 双向赋能的新分工：「AI 造模型，形式化校验模型」
调研报告引用：[20][21][22] 三项 2024 年实证研究 深入：03-frontiers.html · 第三节"MDE 挑战的实证现状"
v0.2 增量 · 第 14 章

SysML v2 / KerML（2025 年 OMG 最终采纳）——MDA 家族最重要的新成员

这是本调研中最值得补进课程的前沿进展。讲义未涉及，但与第二部分"KM3 一阶谓词逻辑形式化"直接呼应。

关键时间线（v0.2 必须更新）：
  • 2025-07-21（新闻发布 / 正式规范 2025-09 发布），OMG 批准 SysML v2.0 规范最终采纳，同时采纳 KerML（Kernel Modeling Language）1.0（为 SysML v2 提供语义与语法基础）以及 SysML v2 API and Services 1.0（提供导航、查询、更新模型的标准服务）
  • 历时 7 年、80 余家机构参与
  • 相较 SysML v1 在精确性、表达力、一致性、可用性、互操作性、可扩展性六个方面全面提升
与本课程直接相关的三点
  • KerML 是全新的元模型（metamodel），其形式语义以一阶逻辑 + 4D 时空延展刻画——这是"元建模形式化"从论文走向工业标准的标志性事件，可与第二部分 KM3 的形式化定义（§7.3）对照讲授
  • SysML v2 提供互补的 textual 与 graphical 表示——"同一模型、两种具体语法"，正是讲义 §7.2 中"DSL 是一组协调模型的集合（领域定义元模型 + 具体语法 + 执行语义）"的工业级实例
  • 标准 API 与服务规范把"模型操纵与管理"这一讲义挑战（§3.3 第三条）标准化，是 MDE 从"工具为中心"走向"平台为中心"的关键一步
  • 产业侧已有多家工具厂商宣布支持（Ansys、Dassault Systèmes CATIA Magic、Celedon 等），INCOSE 亦设立 SysML v1→v2 迁移指导项目
flowchart LR K["KerML 1.0
Kernel Modeling Language
一阶逻辑 + 4D 时空延展
形式语义基础"] S["SysML v2.0
形式语法 + 图形记法
2025-09 OMG 最终采纳"] A["SysML v2 API and Services 1.0
导航/查询/更新标准服务
模型平台化基础"] K -->|"定义底层语义"| S K -->|"支撑"| A S -->|"通过"| A
图 7 · SysML v2 三件套：KerML 是语义地基，SysML v2 是用户语言，API&Services 是平台接口（整理自 OMG 2025-07-21 新闻稿）
调研报告引用：[15] OMG 新闻稿《SysML V2 Final Adoption》2025-07-21；正式规范 2025-09 深入：03-frontiers.html · 第四节"SysML v2 / KerML"