ELEC5620 Lab 1–6 总结：从选题到运行时对象模型

Posted on Edited on In , Word count in article: 3.9k Reading time ≈ 14 mins.
ELEC5620 Laboratory 1–6 的完整路线图：从组队、One-Person AI Company 选题与需求规模约束开始，依次完成 Ad-Hoc、Feature-Oriented、Use Case 三类需求建模，经过 checkpoint、设计原则与视点分析，进入架构模式、类图和运行时对象图。 附跨 Lab 溯源链、交付物检查表和常见失分点。

ELEC5620 Lab 1–6 总结：从选题到运行时对象模型

课程：ELEC5620 — Model-Based Software Engineering，Semester 2 2026
来源：ELEC5620-Lab-Note-1.pdf 至 ELEC5620-Lab-Note-6.pdf（共 7 页）
配套阅读：One-Person AI Company 项目指南｜需求范例拆解｜Stage 1 评分标准与 Lab 3

先说结论：Lab 1–6 不是六次互不相关的练习，而是一条连续的项目建模流水线。每周的结果都应该成为下一周的输入：

真实问题与团队 → 项目需求 → 需求模型 → 架构原则与视点 → 架构模式与类图 → 运行时对象模型

一、六次 Lab 的整体路线图

Lab 教学周 核心问题 应形成的主要产出
Lab 1 Week 2 我们是谁，要解决什么真实问题？ 团队、1–2 个候选题目、项目初稿、协作约定
Lab 2 Week 3 题目可行吗？Agent 角色与功能规模够不够？ 3 分钟 pitch、tutor 反馈、≥3 个 AI 角色、功能分工
Lab 3 Week 4 如何从不同角度把需求说明白？ Ad-Hoc requirements、Feature model、Use cases
Lab 4 Week 5 需求是否成熟？用什么原则和视点指导架构？ Checkpoint 反馈、细化后的 use cases、设计原则、viewpoint analysis
Lab 5 Week 6 系统采用什么架构模式？静态结构是什么？ 架构设计、模式选择与 rationale、class diagram(s)
Lab 6 Week 7 类在实际运行时如何实例化与协作？ Object diagram(s)、具体对象值、运行时关系与 collaboration

这条路线可以压缩成一条可追踪链：

Problem / Company Goal
        ↓
Project Requirements
        ↓
Ad-Hoc → Feature Model → Use Case
        ↓
Design Principles + Viewpoints
        ↓
Architectural Patterns + Components
        ↓
Class Diagram
        ↓
Object Diagram / Runtime Collaboration

任何一步与上一步断开，都会让最终报告看起来像“一组彼此无关的 UML 图”，而不是一个有设计逻辑的系统。

二、Lab 1（Week 2）：组队、选题与项目文档

2.1 先建立团队

Lab 1 首先要求成员介绍自己的背景、兴趣、Agentic AI / LLM 经验、可贡献的技能，以及希望在本学期学习的方向。随后组成 3–5 人小组，并加入 Canvas 中与 lab 时间对应的 group；小组名称采用 lab time + group number 的格式。

这里真正要解决的不是“凑够人数”，而是让团队技能覆盖项目所需的不同方面。至少要提前知道谁更适合负责：

  • 需求与项目文档
  • UML 与架构建模
  • LLM / agent workflow
  • 后端、工具调用和数据
  • 前端、演示与整合

2.2 选题必须围绕真实问题

小组要讨论一个利用 Agentic AI 协作解决复杂问题或任务的软件项目。官方建议：

  • 准备 1–2 个候选题目，保留比较和调整空间；
  • 明确软件要解决的 real-world problem；
  • 说明需要什么类型的 LLM，以及 LLM 为什么能显著增强 agent；
  • 保持与 One-Person AI Company 主题的强关联；
  • 思考对目标行业的影响，例如简化流程、提高效率或提供新方案；
  • 可以参考现有 LLM 应用，但最好面向澳大利亚的相关挑战，并具有行业吸引力。

关键判断：不要从“我们想用哪个模型”出发，而要从“现实中哪一段工作值得由多个 agent 协作完成”出发。

2.3 Lab 1 文档至少覆盖六项

根据 Project Description，项目初稿应包括：

  1. Project scenario：项目场景与问题背景；
  2. Key functionalities：关键功能概览；
  3. Intended users or beneficiaries：目标用户或受益者；
  4. Member roles and responsibilities：每位成员的角色与职责；
  5. Collaboration rules：协作、沟通与冲突解决方式；
  6. Objectives, scope and significance：目标、范围、意义，并突出 Agentic AI 的作用。

Lab 1 的理想结果不是一份很长的报告，而是一份全组都同意的 company brief + team charter。它将成为后续需求建模的地基。

三、Lab 2（Week 3）：可行性确认与需求规模

3.1 三分钟 pitch 只回答两个问题

小组需要向其他组进行 3 分钟题目介绍，重点回答：

  1. 它解决什么真实世界问题？
  2. 公司中的哪些角色应由 AI agent 执行或替代？

在展示前，应先与 tutor 讨论候选题目的可行性，确认它符合课程项目目标。三分钟很短，所以 pitch 不应堆功能，而应讲清楚：问题 → 角色 → agent 协作带来的价值。

3.2 两条硬性规模要求

Lab 2 明确写出：

  • 应用必须包含 至少 3 个不同的 AI 角色，并承担主要 stakeholder 或 business function；
  • 每位成员必须独立实现至少 2 个 core features + 1 个 optional feature。

因此，最低功能规模取决于组员人数：

组员数 Core features 下限 Optional features 下限 每人合计
3 人 6 3 9
4 人 8 4 12
5 人 10 5 15

容易误解的地方：三个 agent 不能只是同一个聊天机器人换三个名字。它们需要有不同职责，并在工作流中真正传递信息、委派任务、验证结果或进行升级处理。

Lab 2 结束时，建议形成一张最小责任矩阵：

AI 角色 业务职责 Core features Optional features 负责人
Agent A … … … Member 1
Agent B … … … Member 2
Agent C … … … Member 3

四、Lab 3（Week 4）：三种需求建模方法

Lab 3 引入三种互补方法。它们不是三选一，而是从模糊想法走向可验证需求的三个层次。

方法 作用 应回答的问题
Ad-Hoc Approach 用灵活、非正式的方式先描述和分析需求 我们在这个具体场景里到底需要什么？
Feature-Oriented Approach 把初始需求系统化地细化为功能和属性 系统必须具备哪些明确能力？
Use Case Approach 从用户或外部系统的交互角度定义需求 谁在什么条件下，通过哪些步骤实现什么目标？

官方给出的关系可以概括为：

Ad-Hoc 提供初始、灵活的需求定义 → Feature-Oriented 把它细化为具体特性 → Use Case 验证这些特性是否符合用户期望和交互。

4.1 三种模型必须互相对应

假设初始需求是“当行程预算超限时，系统应帮助用户调整方案”，三种方法不应该各写各的：

  • Ad-Hoc requirement：描述预算超限的业务情境、约束和期望结果；
  • Feature model：包含 Budget Monitoring、Alternative Search、Negotiation、Human Approval 等特性；
  • Use case：描述用户、Planner Agent 与 Budget Agent 如何协作完成调整。

这条需求之后还应继续成为 activity、interaction 和 state machine diagram 的来源。Lab 3 与 Stage 1 评分项的详细对应，见 Stage 1 评分标准拆解。

五、Lab 4（Week 5）：Checkpoint、设计原则与视点分析

5.1 Checkpoint 是一次方向校准

首先向 tutor 展示当前进展，检查需求是否：

  • 符合课程目标；
  • 可实现，而不是范围无限扩大；
  • 足够完整，能够支撑后续建模；
  • 清楚体现 One-Person AI Company 和 agent collaboration。

最值得在 checkpoint 主动问 tutor 的问题包括：项目范围是否合适、agent 的职责是否真的不同、功能数量是否满足每人要求、关键 use case 能否支撑后续三类行为图。

5.2 细化 Use Cases

Use case 需要准确表示系统的 functional requirements，并清楚定义用户与系统之间的交互。至少应检查：

  • Actor 和目标是否明确；
  • Preconditions / trigger 是否成立；
  • Main flow 是否有完整的起点和终点；
  • Alternative / exception flow 是否覆盖失败与人工升级；
  • Postconditions 是否可以验证；
  • 是否与 feature model 和项目目标一致。

5.3 在画架构前先写 Design Principles

Lab 4 给出的例子包括：

  • Separating control from function：控制逻辑与业务功能分离；
  • Centralizing control：在适合的情况下集中协调；
  • 选择合适的 Model of Computation（MoC）。

设计原则不是口号。每条原则都应能约束后续决策，例如：“所有高风险输出必须经过独立验证 agent 或 human approval”，就会影响组件划分、消息流和状态设计。

5.4 Viewpoint Analysis

设计原则确定后，选择合适的 viewpoint model，例如 4+1 View Model，再从特定视点分析架构。核心是让不同 stakeholder 看到自己关心的系统属性，而不是试图用一张图解释全部内容。

视点示例 关注内容
Logical 核心功能、领域对象、职责划分
Process 并发、通信、运行时协作与控制流
Development 模块、包、代码组织和团队分工
Physical 部署节点、外部服务、网络与基础设施
Scenarios（+1） 用关键 use cases 验证其他视点是否一致

六、Lab 5（Week 6）：架构模式与类图

6.1 选择模式，而不是堆砌模式

Lab 5 要求基于合适的 architectural design patterns 完成系统架构。候选包括：

  • 通用架构模式：Layered Architecture、MVC、Service-Oriented Architecture、Shared-Data；
  • Agent-oriented patterns：ReAct、Planner–Executor、Supervisor–Worker、Blackboard、Cognitive Layering。

官方明确说明：不需要使用所有模式，只选择与系统最相关的模式。 对每个选中的模式，应回答三件事：

  1. 它解决什么架构问题？
  2. 在本系统中如何落地到具体组件、职责和交互？
  3. 它的优势、限制和 trade-offs 是什么，如何满足 functional / non-functional requirements？

例如，一个多 agent 系统选择 Supervisor–Worker，并不等于画一个 Supervisor 框。还要说明：任务如何拆分、worker 如何选择、失败如何重试、结果如何合并、何时升级给人类，以及集中式 supervisor 带来的单点故障和性能权衡。

6.2 Class Diagram 的四类检查项

类图表示系统的 design-time static structure。Lab 5 要求覆盖：

  1. Classes and relationships：主要类，以及 association、generalization、aggregation、composition；
  2. Interfaces：接口及其实现关系；
  3. Multiplicity：每条 association 的多重性；
  4. Attributes and methods：与职责相符的属性和方法。

常见失分点：把架构组件图直接当类图；只画类名不画关系；漏掉 multiplicity；把 aggregation 与 composition 随意混用；接口与具体实现没有区分。

类图应当能够反向解释 use case，也应能向前支持 Lab 6 的对象实例化。如果一个关键 use case 中出现的重要职责在类图里找不到承担者，说明模型之间已经断链。

七、Lab 6（Week 7）：Object Diagram 与运行时协作

Lab 6 从“系统有哪些类”推进到“某个具体时刻，系统中实际存在哪些对象，它们怎样连接”。

Class Diagram Object Diagram
描述类型和规则 描述某个时刻的具体实例
TripPlanner plannerSydney:TripPlanner
属性定义 budget: Money 具体值 budget = AUD 2500
关联允许哪些对象相连 当前场景中哪些对象真的相连
设计时静态结构 运行时快照与 collaboration

7.1 Step 1：从类图选择实例

  • 回顾 Lab 5 的 class diagram；
  • 找出关键场景中真正参与运行的类；
  • 为每个类创建具体命名的 object；
  • 给关键 attributes 填入能解释该场景的具体值。

对象命名通常采用：

objectName:ClassName

例如：

request42:TripRequest
plannerSydney:PlannerAgent
budgetGuard:BudgetAgent
operatorJoey:HumanOperator

7.2 Step 2：用对象关系表现 collaboration

对象图不能只是把类名改成带下划线的对象名。它要呈现：

  • 当前场景中的 object links；
  • 哪些对象交换信息或共同完成任务；
  • 运行时关系是否符合类图中的 association 和 multiplicity；
  • agent collaboration pattern 在具体场景中如何出现。

最适合画对象图的是一个有代表性的运行时瞬间，例如“Planner 已生成方案、Budget Agent 判定超支、系统等待 Human Operator 批准替代方案”。具体值和连接会让抽象架构变得可检查。

八、跨 Lab 的完整溯源矩阵

阶段 输入 输出 一致性检查
Lab 1 真实问题、团队能力 项目场景、范围、用户、功能初稿 Agentic AI 是否不可替代？范围是否可控？
Lab 2 候选题目 AI 角色、功能数量、成员分工 ≥3 个不同 AI 角色？每人 ≥2 core + 1 optional？
Lab 3 项目需求 Ad-Hoc、Feature、Use Case 模型 三类需求是否互相映射？
Lab 4 需求模型 细化 use cases、原则、视点 原则是否约束设计？视点是否服务 stakeholder？
Lab 5 原则、视点、use cases 架构模式、组件、类图 模式是否有 rationale？类能否承担 use case 职责？
Lab 6 类图、关键场景 对象图、运行时 collaboration 实例、属性值、链接是否符合类图？

一条需求的纵向检查方式

挑一条关键需求，从头到尾追问：

它来自哪个真实问题？
→ 属于哪个 feature？
→ 由哪个 use case 实现？
→ 受到哪些 design principles 约束？
→ 在哪个 architecture pattern 中运行？
→ 由哪些 classes 承担？
→ 在具体场景中实例化为哪些 objects？

如果每个问题都能明确回答，模型之间才真正具有 traceability。

九、最容易踩的七个坑

  1. 先选模型，再找问题：结果通常只是普通聊天应用套了一个 LLM API。
  2. 三个 agent 只有名称不同：角色没有独立职责，也没有真实协作或交接。
  3. 功能数量与组员人数不匹配：忽略每人 2 core + 1 optional 的最低要求。
  4. 三类需求模型互不对应：Ad-Hoc、Feature 和 Use Case 各自描述不同系统。
  5. 设计原则停留在口号：没有影响组件边界、控制方式、异常处理或人类审批。
  6. 为了显得复杂而叠加模式：列出多个架构模式，却没有说明各自解决的问题和 trade-offs。
  7. Object Diagram 只是 Class Diagram 的复制品：缺少具体对象名、属性值、场景和运行时链接。

十、Lab 1–6 完成检查表

项目与团队

需求与架构

结构模型

总结

Lab 1–6 的核心不是“每周多画一张图”，而是逐步把一个真实问题变成可解释、可追踪、可实现的系统设计：

Lab 1–2 决定做什么、谁来做；Lab 3 说明系统必须做什么；Lab 4 决定用什么原则和视点观察它；Lab 5 定义它的架构与静态结构；Lab 6 证明这些结构在具体运行场景中如何成立。

最终交付的质量，取决于这条链是否连贯。单张图画得漂亮但彼此无法追踪，价值有限；每个模型都能解释上一步并支撑下一步，才真正体现 Model-Based Software Engineering。