ELEC5620 Week 02 模型驱动软件工程导论讲课总结

Posted on In , Word count in article: 5.3k Reading time ≈ 19 mins.
ELEC5620 Week 02 讲课总结：Agentic AI 的五个组成与项目主题；MBSE 的问题—前提—结果：Brooks 的本质与偶然复杂度、抽象与模型、建模四目的、设计时与运行时视图、MBE 的抽象与自动化及四类机会；Vibe coding 与 MBSE 对比、五种 MBSE 风格；Tutorial 2 智能鞋店 use case 与 UML 工具。

ELEC5620 Week 02 讲课总结：Introduction to Model Based Software Engineering

课程：ELEC5620 — Model Based Software Engineering，Semester 2 2026 讲师：Dong Yuan（School of Electrical and Information Engineering） 来源：讲义 PDF 2 Introduction to MBSE.pdf（43 页）+ ELEC5620-TUT-02.pdf（30 页）+ ELEC5620-Lab-Note-2.pdf（1 页）。本周没有转录稿，以下内容以讲义和 tutorial 为准，不包含课堂口述。

本周覆盖： 1. 项目主题背景：从 LLM 到 Agentic AI，One-Person AI Company 2. MBSE 导论：The Problem（复杂度）→ The Premise（模型与 MBE）→ The Results（工业案例） 3. Vibe coding 与模型驱动的关系 4. Tutorial 2：抽象 vs 自动化、智能鞋店 Use Case 示例、UML 工具

相关笔记：Week 01 软件架构导论｜项目指南｜需求范例（Healthcare）｜Lab 1–6 总结

一、项目主题背景：从 LLM 到 Agentic AI

1.1 AI 概念的层级

讲义第 3 页用一组同心圆说明概念的包含关系：

近几十年 IT 的发展路线：Cloud → Big Data → AI/5G → IoT/Edge Computing，并且 XaaS（Everything as a Service） 成为交付和使用应用的主要方式。

概念 讲义定义
Generative AI LLM 生成文本、图像等内容
Agentic AI 高度自主的系统，在大多数有经济价值的工作上超过人类；拥有类人的认知能力（相对于只做特定任务的 Narrow AI）

Agentic AI 的应用领域：个人效率助手、自主研究 agent、客服、智能家居编排、金融与市场分析、供应链管理、医疗助手、教育培训、软件开发自动化等。

1.2 一个 Agent 的五个组成部分（重点）

组成 含义
Perception（感知） 解释环境中的数据，理解目标
Reasoning & Planning（推理与规划） 决定朝目标前进的下一步
Action & Executing Tasks（行动与执行） 在数字或物理世界里与其他系统/agent 交互
Feedback Loops（反馈回路） 自我评估与调整
Memory（记忆） 存储知识、状态和过往经验

做项目时，每一个“AI 角色”都可以按这五项去检查：它从哪里获得输入（perception）、怎么决定下一步（planning）、能调用哪些工具/服务（action）、怎么校验自己的输出（feedback）、记住什么（memory）。这五项很自然地对应到后面的类图属性和组件接口。

1.3 编程范式：从面向对象到面向 Agent

讲义标题是 From Object-oriented to Agent-oriented，列出三个好处：

好处 说明
Useful Interface 与人自然交互
Strong Capability 在极少人工干预下运行
Useful Architecture 直观的编程范式

讲义在这一页特别标注了 “Abstraction of Agent! Modelling!”：agent 本身就是一种抽象，而这门课要做的就是对它建模。

1.4 Agentic AI 框架

框架 特点 适用场景
LangGraph 基于图的 agent 执行控制流 高复杂度的 agent 工作流
AutoGen（Microsoft） 多 agent 对话编程 需要反复消息交换的系统；可与 OpenAI Assistant、LlamaIndex、LangChain 集成
Llama-Index 开源数据框架，把私有/领域数据接到 LLM RAG、知识库类应用

1.5 One-Person AI Company 与风险

定义与 Week 1 相同：一位创始人拥有并主导公司，AI agent、软件和专业外包在创始人控制下完成可重复的工作；创始人负责判断、关系和问责。（详见 Week 01 第六节。）

讲义提醒项目中要注意的 伦理、安全、隐私 问题：

  • 负责任地使用，防止虚假信息（misinformation）
  • 处理敏感数据和个人信息：防止生成文本中意外泄露；对敏感信息做脱敏（masking）
  • 确保 LLM 应用公平、无偏见

“Be careful if these happen in your project!” —— 在需求里把这些写成非功能需求 / guardrail，后面的架构和 Stage 1 报告都会用到。

二、The Problem：复杂度

2.1 软件工程的基本图景

软件工程就是把问题域里的需求实现到解决方案域里，再回到问题域去验证。

2.2 敌人：复杂度

  • 现代软件系统的复杂度接近生物系统，形成 system of systems
  • 复杂度在系统规划、架构设计和开发中都会造成问题和错误 → 项目失败、延期、超预算
  • 构建复杂系统总是伴随犯错和遗漏需求的风险
  • 人类在处理过多细节时天生容易出错

2.3 Fred Brooks：本质复杂度 vs 偶然复杂度

出处：F. Brooks, The Mythical Man-Month（1995）。

Essential complexity（本质复杂度） Accidental complexity（偶然复杂度）
来源 问题本身固有 实现技术或方法带来
能否消除 不能被技术或技巧消除；简单方案无法充分解决问题 可以避免/减少
例子 医疗诊断流程本身的规则多、例外多 计划和项目管理无效、实现技术不匹配或不成熟

软件工程的主要任务之一：想办法把偶然复杂度降到最低。 基本手段：提高开发所用技术的抽象层次（raising the level of abstraction）。

讲义在这里放了 Margaret Hamilton（“软件工程之母”）站在 Apollo 软件打印稿旁边的照片（1969），说明“软件工程”这个学科的由来就是为了应对这种规模的复杂度。

2.4 SystemC 例子：代码 vs 模型

讲义给出一段 SystemC 代码（producer 模块循环 10 次写 out1，consumer 模块累加 in1 并打印 Sum），问：“Can you see what this program is about?” —— 读代码很难一眼看出结构。

对应的 UML 模型只有：

flowchart LR
    A["«sc_method»<br/>a1:Producer"] -- "out1 → link1 «sc_link_mp» → in1" --> B["«sc_slave»<br/>b1:Consumer"]
    S((start)) --> A

一个生产者对象通过一条链接把数据推给一个消费者对象，start 端口触发生产。“Can you see it now?” —— 这就是抽象的价值：同样的信息，模型让人立即理解结构。

三、The Premise：抽象与模型

3.1 抽象 ⇒ 模型

Abstraction is forgetting (some) details.（抽象就是忘掉（部分）细节。）

3.2 抽象层次

在高级语言（HLL）之上再加一层模型，让问题域到实现之间的“跨度”变小。讲义引用 Alan J. Perlis：

“A programming language is low level when its programs require attention to the irrelevant.”（当程序要求你关注无关的东西时，这门语言就是低级的。）

3.3 什么是模型

一个模型：

特征 关键词
是系统某部分功能、结构、行为的表示 representation
是系统的简化 information, abstraction, specification
能代替真实系统回答问题 inference, prediction
为某个目的而用 planning, design, risk analysis, testing

3.4 工程师为什么要建模（四个目的，必背）

目的 说明
To understand 理解现有或期望的（复杂）系统及其环境的关键特征
To predict 通过分析模型来预测系统的关键特征
To communicate 把理解和设计意图传达给别人（以及自己）
To specify 规定系统的实现（模型作为蓝图）

3.5 工程模型与视图

Engineering model：对某个系统的选择性表示，针对一组给定的关注点（concerns），准确而简洁地捕获其所有本质属性。

讲义用建筑类比：建筑师视图、施工方视图、设计师视图、电工视图、水管工视图——我们不会一次看到全部；我们看到的东西被调整成人能理解的样子。这就是后面 Week 4 viewpoint / view 概念的雏形。

3.6 软件模型：设计时视图与运行时视图

Software model：用某种建模语言描述的、关于某个软件的工程模型，表示： 1. Design-time views：软件规格说明的结构和内容（例如类图里 A、B、C 的关联与多重性 0..*、0..1、«import»） 2. Run-time views：软件执行时的结构和行为（例如 Left/Right 两个对象之间 m1–m4 的消息序列）

讲义强调：很多建模语言的首要动机，就是更清晰地表示执行中的软件。

3.7 现代 MBSE 开发风格：模型逐步精化成系统

模型可以持续精化直到应用被完全规定 ⇒ 模型本身变成了它所建模的系统。

讲义例子：producer 先是一个带 start/out1 端口的构件 → 精化出状态机 NotStarted --start / generate_data()--> Started → Started 再细化为子状态 St1 → St2 → 最终动作 generate_data() 对应到 for (i=0;i<10;i++) out1 = i;。

stateDiagram-v2
    [*] --> NotStarted
    NotStarted --> Started : start / generate_data()
    state Started {
        [*] --> St1
        St1 --> St2
    }

3.8 软件的独特之处

软件模型和被建模的软件共享同一种介质——计算机，而计算机恰好是我们最先进、最通用的自动化技术。 因此软件有一个独特性质：可以把模型直接演化成实现，而不需要在专业知识、工具或方法上出现根本性的断层。

对比：建筑的图纸和真实的楼是两种介质，图纸永远不会“变成”楼；软件模型却可以被生成为代码。

四、Model-Based Engineering（MBE）方法

4.1 定义与两大支柱

MBE：一种系统与软件开发方法，其中软件模型扮演不可或缺的角色。 基于两个经过时间检验的思想：(1) ABSTRACTION（抽象） 和 (2) AUTOMATION（自动化）。

讲义的图：左边是“建模语言的领域”——一个三状态状态机 S1 --e1/action1--> S2 --e2/action2--> S3 --e3/action3--> S1；右边是“工具的领域”——自动生成的 switch (state) { case '1': action1; newState('2'); ... } 代码。

Tutorial 2 把这张图解释得更直白：

Abstraction Automation
方向 细节 → 更清晰的模型 精确的模型 → 工具产出
输入 大量实现细节（code、data、system behaviour） 重要的状态、角色和关系
输出 一个“什么才重要”的清晰视图 代码、测试、仿真、检查
服务对象 帮人理解 帮工具执行

Tutorial 原话：Abstraction helps people understand; automation helps tools act. 本周的 Use Case 图主要支持抽象和沟通，而不是直接生成代码。

4.2 Platform Independence（平台无关）

  • 非常理想的目标：关注点分离（专注系统的功能与行为）+ 可移植性
  • 一个“平台无关”的应用可以 «deploy» 到 Platform 1…N
  • 讲义抛出的思考题：“平台无关”是否意味着设计应用时可以忽略平台问题？ —— 答案是否定的：性能、并发、资源、部署约束都和平台有关；平台无关是把平台相关的决策分离出来、在合适的层次处理，而不是假装它们不存在。（这与 Week 4 的 deployment view 呼应。）

4.3 MBE 的四类机会

机会 要点
Code Generation（代码生成） 用计算机自动化大幅降低当前编程语言的偶然复杂度；讲义提到可以用先进 AI 模型来生成；状态机 → switch 代码。图中特意标了一个 BUG：如果状态机本身更复杂（嵌套状态 Started{St1,St2}），简单的 switch 生成就不够了 → “更高级的建模语言怎么办？”
Exploiting Formal Methods（形式化方法） 建模语言的构造可以设计得比编程语言行为更规整（better behaved），所以能用形式化方法（状态机、Petri 网；model checking、theorem proving）；对编程语言做不到，因为其语义复杂度太高。前提：建模语言需要形式化语义
Model Execution（模型执行） D. Harel：“Models that are not executable are like cars without engines.” 关键能力：Controllability（启动/停止/减速/加速/驱动执行）、Observability（以模型形式查看执行和状态）、Partial model execution（执行抽象和不完整的模型）。目标是可执行规格说明，克服纸面规格的局限
Model Transformations（模型转换） 用途：模型视图（抽象与精化）、域到域转换（如 UML → 排队网络模型）、模型到代码（代码生成）。标准：OMG QVT（Queries, Views, and Transformations）；需要一套类似编译原理的模型转换理论

Tutorial 2 还列出了“已成熟能力 vs 新兴机会”：

Established capabilities Emerging opportunities
代码与测试生成 AI 辅助建模
仿真与可执行模型 生成式架构探索
模型转换 Digital threads 与 digital twins
需求可追溯 跨工具互操作
一致性检查与验证 持续的模型—运行时反馈

The shift：模型正在变得互联、自适应、AI 支持，覆盖整个系统生命周期；既有方法仍是基础。

五、Vibe Coding vs MBSE（本周与 AI 时代最相关的部分）

5.1 自然语言 vs 建模语言

Natural Language（Vibe coding） Model-based software engineering
意图存在哪里 对话式 prompt 里 结构化、有版本的模型里
Agent 产出 代码（控制较少） 代码（受显式的结构与行为约束）
最适合 小范围、快速学习、低后果 会演化、要集成、带风险的大系统

两种方式用的是同样的 agent。区别在于 agent 收到的是“短暂的对话”还是“持久的工程意图”。

5.2 Vibe coding 的两个问题

问题 描述
Intent drift（意图漂移） Vibe coding 能在几小时内把粗略想法变成原型或用户流程；但需求和假设会在会话之间消失
Architecture decay（架构腐化） Agent 能快速试探陌生的 API/框架/集成；但时间一长，agent 会做出局部看起来合理、却违反全局边界、接口和数据规则的修改

（architecture decay 的定义见 Week 01 4.3。）

5.3 MBSE 的答案：模型是 agent 的“控制平面”

  • Vibe coding 优化的是下一个输出，MBSE 优化的是整个生命周期——在全生命周期里减少歧义和失控的变更
  • 模型给编码 agent 一个持久的控制平面（durable control plane）
    • 模型约束“做什么”，agent 仍然决定“怎么做”
    • 模型捕获：能力、接口、数据 schema、状态、策略、非功能需求、验收标准
    • 模型不是放进文档档案的图片，而是 agent 可以读取、转换和验证的控制面

Keep the vibe for discovery. Engineer the system for delivery.（探索阶段保留 vibe；交付阶段要工程化。）

六、MBSE 的五种风格

横轴是时间（发展方向），纵轴是抽象层次与自动化程度：

风格 模型与代码的关系 口号
Code only 只有代码 “What's a model?”
Code Visualization 从代码可视化出模型 “The code is the model”
Round Trip Engineering 模型与代码双向同步 “Manage code and model”
Model-centric 从模型生成代码 “The model is the code”
Model only 只有模型 “Who cares about the code?” 
flowchart LR
    A[Code only] --> B[Code Visualization<br/>model ← visualize ← code]
    B --> C[Round Trip<br/>model ⇄ synchronize ⇄ code]
    C --> D[Model-centric<br/>model → generate → code]
    D --> E[Model only]

记忆方法：箭头方向从“代码 → 模型”（visualize）到“双向”（synchronize）再到“模型 → 代码”（generate）。越往右，抽象和自动化越高。

七、The Results：工业案例

某大型电信设备厂商使用 UML + Rational Technical Developer + Rational Unified Process：

系统 代码规模 工具生成比例
Radio Base Station 200 万行 C++ 87%
Network Controller 450 万行 C++ 80%

这是 “The Results” 部分唯一的证据：大规模工业系统中，绝大部分代码可以由模型生成。

八、Tutorial 2 要点与解答思路

8.1 回顾结构

Tutorial 2 把 lecture 归纳为 The Problem → The Premise → The Results 三段，与上文一致。然后用两个样例项目演示如何“从想法抽象到模型”。

8.2 样例一：Intelligent Healthcare Service Application

用“传统方式”写需求：Primary User Groups → Key Capabilities → Core Features → Optional Features，按 Patients / Doctors / Technical Team 三类用户分别列。完整拆解见 需求范例（Healthcare），这里不重复。

8.3 样例二：AI-Assisted Smart Shoe Store（本周重点例子）

问题：网购时很难选到合适的鞋——用户难以匹配用途、合脚偏好、风格和预算；通用描述和筛选器提供的指导太少。

服务：① 收集偏好 → ② 推荐合适的鞋 → ③ 解释每条推荐 → ④ 支持比较和购买。AI 支持决策，顾客做最终选择。

三步：从场景到模型到产出

步骤 内容
1. Detailed scenario 顾客需求：Size 7、Running、Neutral 风格、预算 $150……很多细节
2. Use case model（抽象） 只保留 actor、目标和系统边界
3. Tool-supported outputs（自动化） 需求清单、基础测试用例、原型流程、代码骨架——前提是模型足够清晰精确

Actor 识别

Actor 目标 相关活动
Customer 找到合适的鞋 输入偏好、比较选项、选择并下单
Store Adviser AI 不够用时提供帮助 审核困难请求、支持顾客
Store Admin 保持服务准确 管理商品、库存、已批准信息
Payment / Delivery Service 完成外部操作 处理支付、确认配送

Actor ≠ 人名。Actor = 相对于系统所扮演的角色。 Actor 在系统外部，与系统交互以达成目标。

系统边界

  • Inside：收集偏好、生成推荐、解释与比较、管理商品信息、创建订单请求
  • Outside：Customer（选择）、Store Adviser（审核）、Store Admin（维护）、Payment/Delivery（处理）
  • 边界规则：AI 可以推荐和解释，但不做最终购买决定。

MVP 划分

Build first Add later
1 输入购物偏好 3D 虚拟试穿
2 获得鞋子推荐 社交购物 feed
3 查看理由与权衡 语音助手
4 比较推荐商品 高级会员计划
5 把选中的鞋加入购物车 自动购买

MVP 问题：这个助手能否帮助顾客做出更好的选鞋决定？只保留检验这一价值所需的功能。

Use Case 图（文字版）

flowchart LR
    C([Customer])
    SA([Store Admin])
    PS([Payment Service])
    subgraph S [AI-Assisted Smart Shoe Store]
        U1((Enter Preferences))
        U2((View Recommendations))
        U3((View Explanations))
        U4((Compare Products))
        U5((Add Shoe to Cart))
        U6((Manage Products & Stock))
        U7((Process Payment))
    end
    C --- U1
    C --- U2
    C --- U3
    C --- U4
    C --- U5
    SA --- U6
    PS --- U7

每条线表示一个 actor 参与一个系统目标。

解题思路（给定场景画 Use Case 图的通用步骤）：

  1. 读场景，圈出所有“谁”——区分系统内部的功能和外部的角色/服务
  2. 外部服务（支付、配送、第三方 API）也是 actor
  3. 画系统边界框，框里只放目标（动宾短语），不放 UI 步骤
  4. 用 MVP 问题筛掉非核心功能
  5. 写清楚 AI 的决策边界（推荐 vs 决定）

8.4 UML 工具对比

工具 优点 局限
UMLet 开源、简单、轻量、插件兼容 缺少代码生成、逆向工程等高级功能
draw.io 免费开源、云端/本地存储、通用、跨平台 不如专业工具精细
StarUML 专业级、代码生成与逆向工程、插件系统 收费（30 天试用，学生 7 折）

UMLet 操作：选模板 → 双击/拖拽插入元素 → 右键设置颜色/图层；多选后 Ctrl+G 分组、Ctrl+U 取消分组、对齐。draw.io 直接用 app.diagrams.net，可存云端。

九、Lab 2 要点

ELEC5620-Lab-Note-2.pdf 文件头写的是 “Week 3: Laboratory 2”，放在 Week 2 文件夹里。内容：

  • Part One：尽快组队；和 tutor 讨论选题可行性；每组 3 分钟 向其他组介绍选题，回答两个问题：解决什么真实问题？公司里哪些角色由 AI agent 执行或替代？
  • Part Two：参照需求范例思考自己的应用；至少 3 个不同的 AI 角色承担主要利益相关者或业务功能；每个组员至少独立实现 2 个核心功能 + 1 个可选功能。

详细的规模约束和 pitch 写法见 Lab 1–6 总结 第三节。

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

  1. Agent 五要素：Perception、Reasoning & Planning、Action、Feedback Loops、Memory。
  2. 本质复杂度 vs 偶然复杂度：前者来自问题本身、不能消除；后者来自技术/方法、可以减少。降低偶然复杂度的基本手段 = 提高抽象层次。
  3. 抽象 = 忘掉部分细节；模型 = 系统的简化表示，可代替系统回答问题，为特定目的服务。
  4. 建模四目的：understand、predict、communicate、specify。
  5. Engineering model 是“针对一组关注点的选择性表示”——不是把所有东西画出来。
  6. Design-time view vs Run-time view：前者是规格的结构（类、关联），后者是执行中的结构和行为（对象、消息）。
  7. 软件独特性：模型与软件同介质 ⇒ 模型可直接演化为实现。
  8. MBE 两大支柱：Abstraction（帮人理解）+ Automation（帮工具执行）。
  9. MBE 四机会：代码生成、形式化方法（需要形式化语义）、模型执行（可控、可观察、可部分执行）、模型转换（QVT）。
  10. Platform independence ≠ 忽略平台。
  11. Vibe coding vs MBSE：短暂对话 vs 持久工程意图；intent drift 与 architecture decay；模型约束 what，agent 决定 how。
  12. 五种风格：Code only → Code Visualization → Round Trip → Model-centric → Model only。
  13. 易错：Actor 是角色而不是具体人名；外部支付/配送服务也算 actor；Use Case 是目标，不是界面操作步骤。