ELEC5620 Week 08 模型组织与敏捷实践讲课总结

Posted on In , Word count in article: 5.7k Reading time ≈ 21 mins.
ELEC5620 Week 08 讲课总结：命名空间、可见性、包、Model 与 Model Library，import/access/merge 语义及例题，智能健康 agent 包图；瀑布与敏捷、Scrum 三角色三清单三会议、Backlog、估算、燃尽图、站会与回顾；Tutorial 8 包图、部署图、Jira 与用户故事，Lab 8 要点。

ELEC5620 Week 08 讲课总结：Model Organisation + Agile Model Practice

课程：ELEC5620 — Model Based Software Engineering，Semester 2 2026 讲师：Dong Yuan 来源：讲义 PDF 7 Model Organisation.pdf（19 页）+ 8 Agile Model Practice.pdf（28 页）+ ELEC5620-TUT-08.pdf（38 页）+ ELEC5620-Lab-Note-8.pdf（2 页）。本周无转录稿。

本周覆盖： 1. 模型组织：命名空间、可见性、包、Model、Model Library、包关系（import / access / merge） 2. 敏捷与 Scrum：瀑布 vs 敏捷、Scrum 三角色/三清单/三会议、Backlog、燃尽图、回顾 3. Tutorial 8：包图、部署图、Jira、用户故事；Lab 8：敏捷仪式与用户故事

相关笔记：Week 07 行为建模｜Stage 2 要求（Jira 敏捷证据）

Part A：Model Organisation

一、为什么要组织模型

软件建模路线中的第三步：如何结构化模型（Model Organization）——即如何划分你的模型。关键概念：

名字与命名空间、可见性、包、模型（Model）、模型库（Model Library）、命名空间关系。

二、名字与命名空间

2.1 名字

  • UML 名字是字符串，没有预定义字符集或长度限制："Alice"、"R2->D2"、"4 Sale"、"Ceлић"、"多音字" 都合法
  • 空名字也是合法的名字

2.2 命名空间

Namespace：一组被拥有的模型元素的集合，这些元素可以通过名字识别。

  • 例：一个 Class 的特性（属性、操作）构成一个命名空间
  • UML 中很多东西都是命名空间：Package、Class、State、Behaviour 等

一般规则（profile 可进一步约束）：

规则 例子
命名空间中的名字不一定唯一（但推荐唯一） 两个同名但参数不同的操作（重载）；类的一个操作和一个属性同名
命名空间可以嵌套 ⇒ 层次（限定）名 用 :: 分隔：System::CoolingSubsystem::ACUnit

三、可见性

命名空间拥有的命名元素都有可见性：该元素能被其他模型元素（可能在其他命名空间中）引用的能力。

符号 可见性 含义
+ public 对所有能访问其命名空间的元素可见
- private 只在拥有它的命名空间内可见
# protected 只对其扩展命名空间中的元素可见（如类的属性对所有子类可见）
~ package 只对同一个包中的其他元素可见

（和 Week 5 类图可见性一致，这里是从命名空间角度给出的一般定义。）

四、包、Model、Model Library

4.1 包

  • Package 是把模型各部分分组的手段
  • 包通常不建模任何东西——类似文件系统的文件夹
  • 包是一种命名空间：可以把其他包的 public 元素导入到本包命名空间（类似编程语言里的 external 声明 / import）

例：Sales 包含 Customer、Order；Warehouse 包含 Location、Item，以及嵌套的 Stock Item、Order Item。

包含关系的两种等价画法：① 把元素画在包框内；② 用命名空间包含符号（圆圈加十字 ⊕，在容器端）连线。

问：为什么不用“黑菱形”（组合）表示包含？ 答：黑菱形用于运行时包含（所有者删除时部件随之删除，Week 5），而包包含是设计时的命名空间包含，两者语义不同。

4.2 Model

  • 只是一种特殊的包，与其他包没有实质语义差别
  • 多一个属性：viewpoint（呼应 Week 4：一个 model 可以对应一个视点）
  • 图形上用三角形图标区分
  • 通常是顶层包，但也可以被包含在另一个包里

4.3 Model Library

  • 只是带特殊标签 «modelLibrary» 的包，没有特殊语义
  • 用于建模可复用的模型片段

五、包关系（重点）

5.1 设计时视图中的包关系

flowchart BT
    EK[ExtendedKernel] -- "«merge»" --> K[Kernel]
    K -- "«import»" --> U["«modelLibrary» UtilityClasses"]
    T[Top] -- "«import»" --> EK
    EK -- "«import»" --> U

5.2 «import» 语义（例题）

X                         Y
├── A                     ├── +C
├── B                     ├── -D
└── C                     └── +E
X ──«import»──▶ Y

导入后，命名空间 X 包含哪些名字？

A、B、C、Y::C、E——但没有 D。而且 Y::C 和 E 并不被 X 拥有（只是可以用名字引用）。

解释：

  • D 是 private，不能被导入
  • Y 的 C 与 X 自己的 C 重名 → X 自己的 C 优先，Y 的 C 只能用限定名 Y::C 访问
  • E 没有冲突，直接以 E 可见
  • 导入只是名字可见，不改变所有权

5.3 «access» 语义（例题）

H ──«import»──▶ X ──«access»──▶ Y
H: F             X: +A, +B, -C     Y: +C, -D, +E
  • «access» = 私有导入：被导入的名字在 X 中以 private 可见性存在
  • X 包含：A、B、C、Y::C、E —— D 仍然不行（Y 中是 private）
  • H 包含：F、A、B ——不包含 Y::C 和 E（它们在 X 中是 private 的，不会被 H 的 import 传递过去）；X 的 -C 也不会被导入

«import»（public import）的名字会被传递导入；«access»（private import）的名字不会。 讲义在两个问句后面打了问号，答案就是这条规则。

5.4 元素导入（Element Import）

  • 可以只导入单个元素，而不是整个包
  • 导入的元素可以被赋予局部别名和局部可见性：
    • X ──«import» {-C}──▶ Y::C：把 Y 的 C 以私有可见性导入 X
    • X ──«import»──▶ Y::E，在 X 中显示为 +Y::E：以公有可见性导入
  • 注意讲义标的 “same class”：别名只是另一个名字，指向的仍是同一个类

5.5 «merge»

  • X ──«merge»──▶ Y：把 Y 的内容合并进 X
  • 例：X 有 A、D；Y 有 A、B、C；合并后 X 有 A（两者的 A 合并成一个）、B、C、D
  • 与 import 的区别：import 只是引用名字（不拥有），merge 是把定义并进来（产生合并后的元素）
关系 名字可见 传递 所有权 / 内容
«import» public ✓ 不拥有，只引用
«access» private ✗ 不拥有，只引用
«merge» — — 同名元素合并为一个，内容被并入

5.6 注释（Comment）

可以附在任何模型元素上（如 “Created by: B. Selic, On: Aug. 2010” 连到 Stack），纯信息性，无特殊语义。

六、Agentic AI 的包图：智能健康 agent

功能：理解症状、查询可用医生和排期、预约、发送提醒和随访。

包 类
Patient Interaction MobileAppUI、ChatBotInterface、ReminderService
Core Agent BeliefManager、GoalManager、IntentionScheduler
Health Data & Profile PatientProfile、SymptomHistory
Appointment Booking —
Doctor & Schedule Management —
Generic User Data —

依赖：

flowchart LR
    PI[Patient Interaction] -- "«import»" --> CA[Core Agent]
    CA -- "«import»" --> HD[Health Data / Profile]
    AB[Appointment Booking] -- "«import»" --> DS[Doctor & Schedule Mgmt]
    HD -- "«merge»" --> GU[Generic User Data]

读法：交互层用核心 agent，核心 agent 用健康数据；健康数据把通用用户数据合并进来（扩展通用的用户定义）；预约模块使用医生排期模块。这是一个分层结构（Week 5 的 Layering 模式）在包图上的体现。

Part B：Agile Software Process Model Practice

七、从瀑布到敏捷

7.1 传统瀑布模型

开发活动（随时间） 团队（人）
把工作分成阶段 每个阶段一个独立的专家团队
每个阶段工作从一个团队传给下一个 团队之间的交接需要协调——用“文档”
所有阶段结束后得到可发布的软件 每个团队完成后被分到新产品

7.2 敏捷的核心思想

思想 含义
Adaptive（自适应） 团队和过程在“连珠炮式变化”面前保持灵活
Iterative / incremental（迭代/增量） 分阶段产出可工作的产品——一组不断增长的“已完成、可工作的软件”
People-oriented（以人为本） 团队组织和过程支持优秀的人——人是项目成功最重要的因素

主要特征：保持小规模；频繁交付部分完成的软件；经常与客户沟通；写的代码多于文档；全队一起学习。例：每 4 周产出一个新的可发布产品。

7.3 敏捷实践

短的定时（timeboxed）迭代、持续集成、每日单元测试、定期回顾、开发者与客户（或客户代理）直接沟通、单一的功能与任务列表、短期估算、信息辐射器（information radiators）、重构。

不是每个实践都必须用——必须的是敏捷价值观。

7.4 常见疑问

问题 讲义回答
文档还重要吗？ 仍然重要；但如果它是唯一的沟通方式就不好。真实可运行的代码比文档更有价值（更少歧义）；文档容易遗漏、容易误解
开发计划还要吗？ 也重要，但格式不同：计划由“迭代”组成；每次迭代团队都有机会融入学到的东西，而不是遵循一个不适应的计划

7.5 为什么敏捷重要 & 有多难

  • 世界变了：大量功能可能只会增加客户成本；新技术不断出现；新玩家入场；新需求加入——“Small is Beautiful”
  • “Don't do Agile, be Agile”：只是“分迭代开发”不够。敏捷是关于：保持过程轻量、每次迭代有真实进展、沟通（尽可能面对面）、早而频繁地主动收集客户输入、愿意对过程做小调整

7.6 敏捷中的需求过程

  • 没有“标准方式”；可以是常规的需求文档，但更好是轻量的——基于用户故事
  • 每次迭代细化一小组功能需求（高优先级行为）
  • 对关键需求，在写需求的同时写验收测试

与本课的关系：MBSE 的模型和敏捷并不矛盾——Week 1 讲义就说过 “UML is not helpful to coding in many cases (e.g., Agile). But it is a good language for communication.” 模型在敏捷中更多扮演沟通和约束 agent 的控制面角色（Week 2）。

八、Scrum

8.1 概述

  • 自 1990 年代初就存在；结构非常简单（3 个角色，3 个会议）；不像其他方法那么“极端”
  • 名字来自橄榄球的 scrum——带态度的会议，需要好的团队合作

8.2 Scrum 元素（三三三）

THREE Roles THREE Lists THREE Meetings
Product Owner Product Backlog Planning（Release & Sprint）
Scrum Master Sprint Backlog Daily Scrum
Team Member Impediments List Sprint Review

（另外每个迭代结束还有 Retrospective；Scrum Guide 见 scrum.org。）

8.3 三个角色

角色 职责
Product Owner 对投资回报率负责；在整个开发期间对团队可用；回答所有需求问题；与客户交流、理解其优先级；保持 Product Backlog 最新
Scrum Master Scrum 规则的守护者；教练；清除障碍；在迭代期间阻止外部干扰；既是老师也是裁判
Team Member 做所有艰苦工作的人；经验技能各异（一两个有架构/设计经验，一两个懂测试策略）；每个人都准备好做自己专长以外的事（测试、设计新界面……）；正常团队 5–9 人，同地办公

8.4 Product Backlog 与 Sprint

  • Product Backlog：构建产品所需的全部特性和子特性——多次迭代的“计划”；按优先级（对客户的价值）排序；任何时候都可以往里加东西
  • Sprint：一次 Scrum 迭代，包含2–4 周内要完成的任务和产出
    • 开始时每个成员都清楚自己要做什么
    • 管理层不应往 Sprint 里加新的产出——新项应加到 Product Backlog
    • 足够重要的新项会在下一个迭代完成

Product Backlog 长什么样：一张简单的电子表格；所有 PBI（Product Backlog Items）按优先级排序；有些 PBI 是客户特性（一个界面、一个交互场景或 use case、一个报表、一个算法——比电信系统的“特性”小得多）；有些是对产品价值有贡献的内部任务。

PBI 能否是… 答案
一份设计文档？ 也许——但如果是没人读的文档，就不要（因为你是敏捷的）
一个早期 GUI 原型？ 当然可以

8.5 估算

  • 每个 PBI 都应有团队给出的估算工作量
  • 经理应该估算 PBI 吗？不，永远不应该。 估算必须来自团队，而且要现实
  • 经理和客户与 Product Owner 一起设定优先级；开发团队估算规模；即使经理和客户不喜欢估算，也不允许修改
  • 迭代内：团队把 PBI 拆成任务（“任务视图”只在迭代内使用）；任务列表灵活（可新增、合并、删除）；在 Task Board 上跟踪；用燃尽图跟踪进度

8.6 燃尽图

  • 跟踪当前迭代剩余的估算工作量
  • 应当每天下降；但如果发现遗漏或估错了难任务，可能上升——没关系，越早承认现实越好
  • 不要估得太悲观：否则燃尽图会在迭代结束前很早就降到 0（讲义中的第二张燃尽图）

（理想线）

实际曲线在理想线上方 ⇒ 进度落后；很早触底 ⇒ 估算过于悲观。

8.7 每日站会（Daily Scrum）

  • 每次迭代有两种“一次性”会议：开始时的 Iteration Planning，结束时的 Sprint Review
  • 另外每天一次 Daily Scrum：15 分钟，不能更长；每个人都发言：
    • “我昨天做了什么”
    • “我今天计划做什么”
    • “我遇到了哪些障碍”
  • 会上不解决问题——都放到会后
  • 目的：让问题和障碍对团队可见；障碍对经理是有价值的输入

8.8 回顾会（Retrospective）

  • 敏捷的重要思想：花时间反思和学习；迭代提供了自然的断点
  • 每次迭代结束开 Retrospective——“像事后剖析（post-mortem），但项目还没死”；一到两小时
  • 学习什么做得好、什么该改；不要用来指责成员或经理——专注于修复过程
  • AI 时代的补充：检查 AI 在哪里节省了工作量，又在哪里制造了调试、评审或维护工作

Retrospective Prime Directive（Norm Kerth）：无论我们发现了什么，我们理解并真心相信：在当时已知的信息、自身技能与能力、可用资源和所处情境下，每个人都尽了最大努力。 为什么有这条规则？回顾的目的是改进过程，不是追责。

8.9 敏捷与 vibe coding

环节 做法
工作分解与 backlog 细化 给 agent 有界的任务，带显式接口、约束和完成证据；提供具体示例、反例、相关上下文和禁止行为
Sprint 规划与评审 预测时把评审、评估、集成和返工的容量算进去；演示时同时带上代表性的 agent 结果、失败案例和运行成本；独立检查生成的代码和测试

8.10 Scrum 小结

Scrum 是以团队为中心的敏捷方法：短定时迭代；每次迭代产出对客户有价值的真实软件；每次迭代包括规划、开发、评审；所有估算由团队完成；Sprint 内用燃尽图跟踪；Product Owner 决定 backlog 优先级；Scrum Master 帮助执行规则；15 分钟每日站会。Stage 2 用 Jira 来支持 Scrum 管理。

总结：敏捷强调小型跨职能团队的迭代开发，而非孤立的瀑布阶段；每次迭代结束有“done”的功能；更好的沟通、更快的反馈；短周期缩短上市时间和达到质量的时间；Scrum 是最流行的敏捷方法，推动小型跨职能团队、短定时迭代、自适应计划、单一 backlog、频繁集成、测试自动化。

九、Tutorial 8 要点与解答思路

9.1 包图

  • 用于结构化高层系统元素；可简化复杂类图（把类分组到包中）；组织包含图、文档和其他交付物的大系统
  • 包 = 逻辑相关 UML 元素的集合，画成带小标签的文件夹；名字写在标签上或框内；虚线箭头是依赖——如果一个包的变化可能迫使另一个包变化，后者依赖前者
  • 包图是层次嵌套的，嵌套包的原子模块通常是类图
  • 约束：系统内包名不能重复，但不同包中的类可以同名；包可以包含整张图、只有组件名，或什么都没有；完全限定名 Parent::Child

依赖的两种构造型：

构造型 含义
«import» 导入另一个包的功能（名字公开可见）
«access» 需要另一个包的函数帮助（私有引用）

（也可以用自定义构造型。）

9.2 例题：Track Order 包图

问题描述：网店的 Track Order 模块为客户订购的商品提供跟踪信息：客户输入跟踪序列号 → Track Order 查询系统并把当前物流状态更新给客户。

解题步骤：

  1. 识别包：Track Order；它要与 Order Processing 交互获取订单详情；拿到订单后要知道物流，需要 Shipping；还有 UI Framework
  2. 识别依赖：
    • Track Order 要从 Order Processing 获取订单详情，Order Processing 也要知道客户给的跟踪信息 → 双向 «access»
    • Track Order 从 Shipping 导入数据/功能 → Track Order --«import»--> Shipping
    • Track Order 依赖 UI Framework
flowchart LR
    TO[Track Order] -. "«access»" .-> OP[Order Processing]
    OP -. "«access»" .-> TO
    TO -. "«import»" .-> SH[Shipping]
    TO -. depends .-> UI[UI Framework]

9.3 部署图

  • 由节点及其关系组成；描述系统运行时结构：硬件配置及软件如何部署到网络结构中
  • 常用于理解分布式系统；一个系统模型通常只有一张部署图；是部署的静态视图
  • Node：运行时存在并运行的物理元素，代表计算资源——硬件或运行在其上的软件系统（64 位主机、Linux 操作系统、防火墙等）；画成三维立方体
  • Node instance：实例名 : 节点类型（下划线）
  • Node stereotypes：PC Client、UNIX Server、CD-ROM、Storage Device、Security Device 等，右上角有图标
  • Artifact：软件开发过程的产物（模型、源码、可执行文件、文档、测试报告、原型、用户手册……），记号是 «artifact» + 文档图标
  • Association：节点之间的连线，表示通信路径，带协议（如 HTTPS、JDBC）
  • Node as Container：节点可以包含其他节点、组件或制品

用途：可视化硬件拓扑；描述部署软件的硬件组件；描述运行时处理节点；对系统工程师非常有用；影响性能、可扩展性、可维护性、可移植性。

部署图 vs 组件图：组件图描述软件组件；部署图描述软件组件部署在什么硬件上。大多数 UML 图处理逻辑组件，部署图关注硬件拓扑。（对应 Week 4 的 4+1 Physical View。）

例题：订单管理系统部署视图：节点有 Monitoring、Modem、Cache server、Server；应用是部署在 Server 1/2/3 集群上的 Web 应用，用户通过互联网连接，控制流从集群中的 cache servers 流出。

Agentic 系统部署图写法（结合 Week 4 Physical View）：

«device» Patient Phone ──HTTPS── «executionEnvironment» Web Server (FastAPI)
                                      │ gRPC
                     «node» Private Agent Host ── hosts «artifact» agents.py, prompts.yaml
                             │ JDBC                        │ HTTPS (de-identified only)
                     «node» Database Server (EHR)     «node» Cloud LLM API

9.4 Jira、用户故事与 MoSCoW

  • Jira：Create Project → Scrum Template → Backlog & Board
  • MoSCoW：Must-have、Should-have、Could-have、Would-like-to-have（Won't have this time）

User story：敏捷中的工作单元——对软件特性的非正式、一般性解释：

As a <role (typical user)>, I want to <goal> so that <benefit>.

特点：比 use case 简单；从用户视角；聚焦用户；促进协作；驱动创造性方案；建立动力。

User persona：典型用户的虚构代表——详细档案，帮助团队理解目标用户的目标、需要、动机和行为。

例 1：Canvas 登录——需求：只有登录用户能看页面。

As a student, I want to be able to log in to Canvas USYD so that I can view the courses and assignments relevant to me.

例 2（练习）：“注册用户应能管理通知偏好，以控制何时、如何收到更新。”

参考答案：As a registered user, I want to be able to manage my notification preferences so that I can control how and when I receive updates.

Epic / Theme / Story：Theme（主题，跨 epic 的大目标）⊃ Epic（大的工作体，可拆成多个故事）⊃ User Story。

十、Lab 8 要点

ELEC5620-Lab-Note-8.pdf（文件头 “Week 9: Laboratory 8”），主题是敏捷项目管理：

Part 内容
1 熟悉敏捷：迭代开发、协作、响应变化；把任务组织成 sprint、跟踪进度。Stage 2 要用 Jira 做项目跟踪和任务管理
2 讨论四个敏捷仪式：Sprint Planning（排优先级、拆分任务、分配责任）、Daily Stand-up、Sprint Review（与利益相关者/tutor 评审）、Sprint Retrospective（什么好、什么不好、如何改进）
3 开第一次站会：自上次以来完成了什么、正在做什么、有什么障碍
4 在 Jira 中头脑风暴并管理用户故事：格式 “As a [user], I want [goal], so that [reason]”；每个故事定义 Definition of Done 并考虑如何测试（自动/手动）；用 MoSCoW 标签组织

用户故事 + DoD 示例（agent 项目）：

Story MoSCoW Definition of Done
As a patient, I want to describe my symptoms in chat so that I get a triage suggestion without waiting Must Triage agent 返回分级结果；急症关键词触发人工升级；有 3 个自动化测试覆盖 mild/doctor/emergency
As a clinician, I want to approve agent drafts before they are sent so that no unreviewed advice reaches patients Must 未批准草稿不能发送（有测试）；审批记录写入审计日志
As a patient, I want to receive appointment reminders so that I don't miss visits Should 预约前 24h 发送通知；手动测试截图

Stage 2 对 Jira 证据（迭代、燃尽图、用户故事、反馈闭环）的具体评分要求见 Stage 2 要求总结。

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

  1. 命名空间：拥有可按名识别的元素；可嵌套，限定名用 ::；名字不必唯一；空名合法。
  2. 四种可见性：+ public、- private、# protected（扩展命名空间）、~ package。
  3. 包 ≈ 文件夹，不建模任何东西；包含关系用 ⊕ 或嵌套，不用黑菱形（黑菱形是运行时包含）。
  4. Model = 带 viewpoint 属性的包（三角形图标）；Model Library = «modelLibrary» 包，无特殊语义。
  5. «import»：public 导入，private 元素不导入，重名时用限定名，导入不改变所有权，可传递。
  6. «access»：private 导入，不传递。
  7. «merge»：同名元素合并，内容并入。
  8. 元素导入可以设局部别名和局部可见性。
  9. 敏捷三思想：adaptive、iterative/incremental、people-oriented；“Don't do Agile, be Agile”。
  10. Scrum 三三三：Product Owner / Scrum Master / Team；Product / Sprint Backlog / Impediments；Planning / Daily Scrum / Review（+ Retrospective）。
  11. Sprint 2–4 周；Sprint 中不加新工作（加到 Product Backlog）；估算只由团队做，经理不能改。
  12. 燃尽图可以上升；太悲观会过早触底。
  13. 站会 15 分钟三问，不解决问题；回顾会不追责（Prime Directive）。
  14. 用户故事格式 As a / I want / so that；MoSCoW；DoD。
  15. 部署图：节点（立方体）、节点实例（下划线 name : Type）、制品 «artifact»、通信路径带协议；对应 4+1 的 Physical View。
  16. 易错：«access» 当成可传递；包依赖箭头方向画反（应从依赖方指向被依赖方）；Product Owner 和 Scrum Master 职责混淆。