ELEC5620 Week 04 架构设计与建模（上）讲课总结

ELEC5620 Week 04 讲课总结：Architectural Design and Modeling（Part 1）

课程：ELEC5620 — Model Based Software Engineering，Semester 2 2026 讲师：Dong Yuan 来源：讲义 PDF 4 Architectural Design and Modeling (part 1).pdf（55 页）+ ELEC5620-TUT-04.pdf（27 页）+ ELEC5620-Lab-Note-4.pdf（1 页）。本周无转录稿。

本周覆盖（讲义目录的前四节；第五节“架构设计模式”在 Week 5 的 Part 2 讲）： 1. Software Architecture（preliminaries）：42010 定义、架构原则、设计空间、演化 2. Key Analysis Issues：视点与视图、4+1、Siemens、质量属性分析 3. Key Design Issues：计算模型（MoC）、控制与功能、设计综合 4. Key V&V Issues

相关笔记：Week 01 软件架构导论｜Week 03 需求建模｜Lab 1–6 总结

---

一、软件架构预备知识

1.1 回顾：架构腐化

Architectural decay：通过看似微小的修复和修改，系统架构被逐渐侵蚀。成因：难以感知架构、难以强制执行架构决策。 为避免腐化，至少必须能够轻松识别软件架构及其背后的设计意图。

讲义再次用 SystemC 代码“一团乱麻”的图说明：Architecture is about understanding——既理解问题也理解解决方案；理解需要抽象 ⇒ 建模。

1.2 IEEE 42010 的核心定义（修订版）

术语	定义
Architecture	“系统在其环境中的基本概念或属性，体现在其元素、关系以及设计和演化的原则中”
Architecture description	“用来表达架构的工作产品”

注意区分：architecture 是系统的属性，architecture description（AD）是描述它的文档/模型。我们画的 UML 图属于 AD。

关键词拆解（与 Week 1 的版本略有不同，这里是 42010 修订版）：

关键词	含义
“fundamental”	抽象——无关信息被隐藏或移除
“elements…relationships”	同时涵盖结构和行为
“principles of its design and evolution”	详细设计的指导方针（和规则）

一个架构描述 = STRUCTURE（结构）+ BEHAVIOR（行为）+ ARCHITECTURAL PRINCIPLES（原则）。

1.3 架构原则

全系统范围内成立的一般设计原则/不变量。

讲义例子：

• “在被认为关键的组件中，不得存在单点故障”
• “系统中的故障恢复通过级联的多级重启实现”
• “在最高层描述中，任何组件的生命周期都定义为经过一系列显式运行模式的过程”
• “组件的模式切换总是由该组件指定的外部控制器驱动”

后两条原则直接对应本周后面的“控制与功能分离 / 集中控制”。写项目的 design principles 时可以仿照这种“shall / always / no”的句式。

1.4 架构缩小设计空间

• 架构是约束和指导详细设计的高层设计
• 通过减少设计选择来促进一致性、降低复杂度

例如选择“单机方案”或“分布式方案”就排除了大片解空间。

架构即宪法（Architecture as a Constitution）：宪法是国家或组织的根本法，定义治理的基础准则，限制并指导下位法（细化）的制定——讲义认为这可能比“建筑”更贴切的类比。

1.5 架构与演化

架构对系统支持演化的能力有根本影响：当新需求到来时，如果当初选了“单机方案”，就可能落不到“分布式”的解上。

例子：点对点 vs 松耦合

flowchart LR
    subgraph P2P[Point-to-point]
        A1[A] --- X1[X]
        A1 --- B1[B]
        A1 --- C1[C]
        B1 --- X1
        B1 --- C1
        C1 --- X1
    end
    subgraph MED[Mediator]
        A2[A] --- M[Mediator]
        B2[B] --- M
        C2[C] --- M
        X2[X] --- M
    end

点对点： 个组件最多 条连接，加一个新组件要改 处；Mediator：每个组件只连 mediator，加一个组件只加 1 条连接——更易演化。

1.6 架构的四项核心活动

活动	内容
ANALYSIS	理解领域和要解决的问题
DESIGN	发明问题的解决方案
IMPLEMENTATION	实现设计
VALIDATION AND VERIFICATION	(a) 解决的是对的问题（validation）；(b) 问题解决得对（verification）

---

二、关键分析问题

2.1 三个分析问题

问题	内容
Requirements identification and specification	要构建什么、为什么（Week 3 的内容）
Stakeholder viewpoint identification	关注点（concerns）及其概念化
Domain identification and partitioning	把问题分解为概念和技术上同质的区域

2.2 视点与视图（定义必会）

术语	IEEE 1471 定义
Viewpoint（视点）	识别一组关注点以及用来描述架构以回应这些关注点的表示技术
View（视图）	从一组相关关注点的角度对整个系统的表示；是把某个视点应用于特定系统的结果

A view is what you see through a viewpoint. 类比：viewpoint 是“模板/镜头”（比如“部署视点：用部署图描述节点和制品”），view 是“用这个镜头拍到的这张照片”（比如“我们系统的部署图”）。

2.3 设计时 vs 运行时视点

	Design-time view	Run-time view
内容	系统规格说明的静态组织（在设计仓库中）	执行中的程序创建的实例的动态组织
例子	类 A、B、C 之间的关联、多重性 0..*、0..1、«import»	对象 a:A、b1:B、b2:B、c1:C…c3:C 及其链接

两者形式上耦合，但截然不同！ —— 类图里一个 0..* 关联，在运行时可能是 0 个、3 个或 1000 个链接。

2.4 选哪些视点？

目前对“什么是一套合适的视点”还没有共识——可以自定义，也可以用现成方案。两个著名的：Kruchten 的 “4+1” 和 Siemens 模型（Hofmeister, Nord & Soni）。

2.5 贯穿例子：Agentic healthcare system

患者问：“我从昨天开始头疼发烧，该怎么办？”

flowchart LR
    A[Patient reports symptoms] --> B[Triage assesses risk] --> C[Information is retrieved] --> D[Appointment or escalation] --> E[Clinician reviews and records]

Agents：Triage Agent、Health Advice Agent、Appointment Agent、Emergency Agent。

“一张把所有 agent 画在一起的简单图是不够的。” —— 这就是需要多视图的理由。

2.6 Kruchten 的 4+1 视图（重点）

从不同利益相关者（终端用户、开发者、项目经理等）的视点描述系统。4 个视图描述系统 + 1 个视图描述需求；完整的系统规格 = 各视图的并集。

视图	回答的问题	内容	UML 图	主要关注者
Logical View	系统的主要职责和概念组件是什么？	系统功能；抽象设计模型（类、关联、子系统）	类图、顺序图	终端用户（功能）
Development (Implementation) View	软件实现如何组织？	开发环境中实现制品（包、可执行文件）的组织	包图	程序员、软件管理
Process View	系统运行时发生什么？	并发（任务、线程、进程）和相关交互	活动图	系统集成者（性能、可扩展性）
Physical (Deployment) View	软件在哪里执行？	运行时制品到平台/计算节点的映射；性能、可扩展性、可靠性	部署图	系统工程师
+1 Scenario (Use-Case) View	驱动架构的关键 use case	连接四个视图	use case 图/场景	所有人

Agentic 医疗系统在各视图中的样子：

Logical View —— 逻辑组件

类别	组件
Agents	TriageAgent、HealthInformationAgent、AppointmentAgent、EscalationAgent、FollowUpAgent、ClinicalDocumentationAgent
Shared services	PatientRecordService、AuthenticationService、SchedulingService、NotificationService
External tools	Electronic Health Record、Hospital Appointment System、SMS/Email、Medical Knowledge Base

Development View —— agentic 软件不只有代码

传统模块	Agentic 应用还包括
源代码、配置、库	Agent 代码、Prompts、Tool definitions、Guardrails、Policies、Workflow definitions、Model configurations、Knowledge sources、Schemas、Human approval rules

一般用 .yaml 定义 prompts、规则，用 .json 定义数据 schema。所以包图里应该有 prompts/、policies/、tools/ 这样的包。

Process View —— 并发与协调

• 并发执行：Triage Agent 同时做 Retrieve EHR context、Retrieve medical knowledge、Check available appointments，然后做 Triage Decision
• 协调问题：Appointment Agent 说“你的预约是明天上午 10 点”，Follow-up Agent 却又问“需要我帮你预约吗？”——两个 agent 状态不一致
• ⇒ 需要一个 Communication Service；Process view 涉及同步和共享状态

flowchart TD
    S([Request]) --> F[fork ━━]
    F --> E[Retrieve EHR context]
    F --> K[Retrieve medical knowledge]
    F --> A[Check available appointments]
    E --> J[join ━━]
    K --> J
    A --> J
    J --> T[Triage Decision]

Physical View —— 敏感数据放在哪里

问题：完整的患者记录应该发给外部 LLM 吗？

• 可识别数据 → 私有环境；去标识化上下文 → 外部 LLM
• 混合模型部署：私有模型 → 敏感任务；云模型 → 一般任务
• 数据位置和模型位置是架构决策。

+1 Scenario View：一个场景是贯穿四个视图的纵切面——哪些组件参与（Logical）、涉及哪些实现模块（Development）、运行时执行什么（Process）、在哪里执行（Physical）。

2.7 架构分析：质量属性问题

核心问题：这个架构能满足重要需求吗？

质量属性	架构问题
Safety	不安全的 agent 动作能否被阻止或升级？
Privacy	哪些 agent 能访问患者信息？
Security	谁能调用医疗工具？
Reliability	某个 agent 失败时会发生什么？
Availability	故障期间患者能否访问关键服务？
Performance	一个请求多快能被分诊？
Scalability	能否支持上千患者同时交互？
Auditability	能否重建某个动作发生的原因？
Maintainability	改一个 agent 是否会影响其他 agent？
Explainability	重要决策能否被追溯？

这张表可以直接当作项目报告里“architecture analysis”一节的模板：每个属性写“问题 → 在哪个视图里回答 → 采用的机制”。

2.8 Siemens 视点

视点	内容	元素
Conceptual View	面向应用的组件规格：功能与互连	Components、Connections、Topology
Module View	把概念组件分组为开发环境实体	Modules、Subsystems、Layers
Execution View	模块映射到平台相关的运行时实体（线程、进程）和硬件	Runtime entities
Code View	模块视图实体到实际平台实体的分配与部署	—

2.9 视点选择的共同点

尽管各方案不同，有三个共同元素：

1. 分成多个视图
2. 区分运行时与开发（设计）时：Process / Execution view vs Implementation / Module / Code views
3. 把部署作为单独的关注点（以支持复用）：Deployment view、Execution/Code view

4+1	Siemens（大致对应）
Logical	Conceptual
Development	Module / Code
Process	Execution
Physical	Execution（硬件映射）/ Code

---

三、关键设计问题

3.1 三个设计问题

• 选择计算模型：在给定领域中事情是怎样发生的？
• 架构中的控制：control vs function
• 设计综合：视点选择与定义、系统设计原则、系统分解、组件定义

3.2 计算模型（Model of Computation, MoC）

MoC 解释整个系统的行为如何由各组件的行为产生；定义计算组件如何执行、通信、同步、交换数据的规则；是软件设计中定义组件如何计算和通信的抽象框架。

两大类：

MoC	组件是什么	什么触发执行	系统行为
Structure-dominant	互连的对象，是状态和行为的容器，对刺激做出反应（响应可能依赖于状态，即历史刺激）	收到消息/刺激；组件（作为 actor）异步收发消息	各组件响应的复合；个体响应通常用某种行为主导 MoC 描述
Behaviour-dominant: Procedural（控制流）	算法片段/函数	前驱组件完成	组件执行的（偏）序复合；计算建模为输入到输出的函数
Behaviour-dominant: Data flow（数据流）	函数式变换	输入数据可用	执行顺序由数据可用性决定；允许细粒度并行

讲义的数据流例子：设计房屋平面图 → 并行设计水管、电路、门窗 → 建房——三个设计任务都只依赖平面图，可以同时进行。

选择主导 MoC 是首要的架构决策，取决于应用特征和需求。

同一组件、不同 MoC（Triage Agent 例子）：

MoC	执行方式
Procedural	Retrieve EHR → Retrieve knowledge → Check appointments → Triage Decision，全部顺序执行
Data flow	三个检索并发执行，数据都到齐后触发 Triage Decision
Structure-dominant（事件驱动）	组件通过事件总线响应事件

Agentic AI 的 MoC 选择：

• Agent 通常做：感知、推理与规划、行动、协调
• 需要支持异步交互、并发、模块化的 MoC
• Structure-dominant：用于自治、并发、多 agent 交互——AI agent = 组件/actor
• Data flow：用于串联推理/感知/行动函数
• 区分 agent 级和系统级 MoC：不要把单个 agent 的推理循环和整个软件架构的计算模型混为一谈

3.3 架构中的控制

Control：使系统进入期望的运行状态，并在面对各种计划内和计划外的干扰时保持在该状态所需的（额外）机制和动作。

软件系统中的控制包括：

• 系统/组件的启动与关闭
• 故障检测/报告/恢复
• 系统管理、维护和资源供给（provisioning）
• （在线）软件升级

Control vs Function：

• 控制行为常被临时（ad hoc）处理，因为它不是主要功能——通常是事后塞进为功能行为优化的框架里
• 在高可靠系统中，多达 80% 的代码是控制行为！

两个重要观察：

1. Control predicates function（控制先于功能）：系统执行主要功能之前，必须先进入运行状态
2. 控制行为通常独立于功能行为：组件进入运行状态的过程，往往与其具体功能无关

3.4 基本设计原则

原则	做法
Separate control from function	把控制组件与功能组件分开；把控制接口与功能接口分开
Centralize control (decision making)	尽量把控制集中在一个组件里；控制策略（policy）放在控制组件中，控制机制（mechanism）放在被控组件内部

Policy vs mechanism：policy 是“何时、为何做”（决定重启哪个组件），mechanism 是“怎么做”（组件自己的 restart() 实现）。

3.5 核心架构模式：星形控制与递归控制

The Core Architectural Pattern：控制在中心的星形模式，带有独立的控制端口；所有控制策略从中心执行；外围是一组需要作为整体被控制/协调的组件。

The Recursive Control Pattern：控制器本身也可以像其他被控组件一样被控制 → 层次化；容易扩展到非常大的系统；简单，但能确保动态软件系统一致、高度可控。

flowchart TD
    TOP[Central Control] --> C1[Central Control]
    TOP --> C2[Central Control]
    C1 --> A1[Controlled 1]
    C1 --> A2[Controlled 2]
    C1 --> An[Controlled n]
    C2 --> B1[Controlled 1]
    C2 --> B2[Controlled 2]
    C2 --> Bn[Controlled n]

3.6 Agentic AI 中的控制与功能

Control design	Function design
执行控制：何时行动、优先做什么、一个任务追多久	输入处理、规划、推理、决策
自我监控、错误检测、恢复	在环境中执行变更
运行模式：reactive（反应式）、proactive（主动式）、deliberative（审慎式）	存储和回忆过往交互、上下文、学到的知识

应用到项目：一个 Orchestrator/Supervisor 组件放控制策略（路由、预算、审批、重试），各 agent 只暴露 start/stop/status 等控制端口 + 功能接口——这就是“星形控制模式”的 agentic 版本。

---

四、验证与确认（V&V）

	Verification	Validation
问题	“Are we building the product right?”	“Are we building the right product?”
标准	软件符合规格说明	软件做用户真正想要的事，满足客户期望和需求

关键 V&V 问题：

1. 选择合适的方法和工具：Testing、Inspection、Simulation、Formal verification（model checking、theorem proving、quality analysis 等）
2. 选择和定义测试用例：资源和时间有限，测什么？
3. 执行测试用例：如何优化测试运行（何时？如何？）

讲义结尾的笑话： > 理论是什么都知道但什么都不工作；实践是什么都工作但没人知道为什么；在我们实验室，理论和实践结合：什么都不工作，也没人知道为什么。 —— Validation or Verification?

（答案思路：“什么都不工作” 说明连规格都没满足 → verification 失败；而“不知道为什么”说明对问题本身都没理解 → 连 validation 都谈不上。）

---

五、Tutorial 4 要点与解答思路

5.1 如何做 Viewpoint Analysis（五步）

步骤	内容
1. Define Objectives and Scope	明确分析目标（理解架构/优化设计）；界定范围；识别利益相关者；定义与其关注点对齐的视点
2. Select Appropriate Viewpoints	按系统复杂度和需求选关键视点；确定每个视点的关注重点
3. Collect and Organize Information	从需求文档、设计规格收集数据；组织成可分析的形式（图）
4. Conduct Viewpoint Analysis	逐个视点详细分析（用 UML 等工具）；识别视点之间的交互和依赖，保证一致、无矛盾
5. Integrate Viewpoints	汇总成完整的架构描述；验证跨视点一致性并解决冲突

报告结构：Introduction（目的与范围）→ Viewpoint Analysis（逐视点结果）→ Issues and Recommendations → Conclusion；多用图，图要简洁突出重点。报告的作用：为开发和维护提供清晰指导，作为长期参考。

5.2 识别 Actor 的问题清单

谁使用系统？谁安装？谁启动？谁维护？谁关闭？哪些其他系统使用本系统？谁从系统获取信息？谁向系统提供信息？是否有事情在预定时间自动发生？（→ 时间/调度器也可以是 actor）

5.3 识别 Use Case 的问题清单

• actor 想要系统提供哪些功能？
• 系统是否存储信息？哪些 actor 会创建、读取、更新、删除（CRUD）这些信息？
• 系统是否需要通知 actor 内部状态的变化？
• 是否有系统必须知道的外部事件？由哪个 actor 告知？

5.4 Use case 描述与事件流

完整 use case 描述一般包括：名称、简述、优先级、actors、前置条件、基本事件流、其他事件流、异常事件流、后置条件。

事件流	含义
Basic event flow	通常、预期的路径
Other event flows	因其他因素走的其他路径
Exception flow	异常情况和替代分支

前置条件：use case 开始时 actor 和系统应处于什么状态。

5.5 Use case 图技巧与注意事项

• 从 actor 的视角组织图
• 从最高层、最简单开始，再逐步细化
• 关注 “what” 而不是 “how”
• 注意事项：系统边界要清晰；避免 use case 过多；从执行者视角命名；注意描述的形式化程度；避免执行者名称不一致；避免 actor 与 use case 之间关系过于复杂；注意 use case 粒度；避免描述混乱；区分强制分解和功能分解（不要把一个 use case 机械地拆成一串步骤 use case）；避免客户看不懂；有些需求不适合用 use case 图描述（例如纯 NFR、算法细节）

---

六、Lab 4 要点

ELEC5620-Lab-Note-4.pdf（文件头 “Week 5: Laboratory 4”）：

Part	任务
1	Checkpoint：向 tutor 展示进度，确认需求与课程目标一致、可行且全面
2	Refine Use Cases：细化 use case，准确表示功能需求和用户—系统交互
3	Specify Design Principles：在画详细架构前写设计原则，如控制与功能分离、集中控制、选择合适的 MoC
4	Viewpoint Analysis：选择视点模型（如 4+1），按设计原则从特定视点分析系统架构

本周 lecture 的第三节就是 Lab 4 Part 3/4 的理论依据。更详细的交付物写法见 Lab 1–6 总结 第五节。

Design principles 写法示例（基于本周讲义句式）：

1. 控制与功能分离：Orchestrator 是唯一决定 agent 调度、重试与终止的组件；各 agent 只实现功能接口与标准控制端口。
2. 集中控制：所有审批策略（是否需要人工批准）在 PolicyController 中定义，agent 内部只实现执行机制。
3. 系统级 MoC 为 structure-dominant（agent 作为异步消息驱动的组件），agent 内部的检索—推理链采用 data flow。
4. 关键数据路径不得存在单点故障；可识别患者数据不得离开私有部署环境。

---

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

1. 42010：architecture = 系统在环境中的基本概念/属性，体现在元素、关系、设计与演化原则中；architecture description = 表达架构的工作产品。
2. 架构 = 结构 + 行为 + 原则；架构缩小设计空间，像宪法一样约束下位设计。
3. 点对点 vs mediator：后者松耦合，易于演化。
4. 四项核心活动：analysis、design、implementation、V&V。
5. Viewpoint vs view：视点 = 关注点 + 表示技术；视图 = 把视点应用到具体系统的结果。
6. 设计时 vs 运行时视图：形式上耦合但截然不同。
7. 4+1：Logical（类/顺序图）、Development（包图）、Process（活动图，并发）、Physical（部署图）、+1 Scenarios（连接四者）。完整规格 = 各视图之并。
8. Agentic 4+1 要点：Development view 包括 prompts/tools/guardrails/policies；Process view 要处理同步与共享状态；Physical view 决定数据和模型放哪里。
9. Siemens 四视点：Conceptual、Module、Execution、Code。共同点：分视图、区分运行时与设计时、部署单列。
10. MoC：structure-dominant（对象/actor、异步消息）vs procedural（前驱完成触发）vs data flow（数据可用触发，细粒度并行）；不要混淆 agent 推理循环与系统级 MoC。
11. Control：使系统进入并保持运行状态；高可靠系统中多达 80% 代码是控制；control predicates function；控制常独立于功能。
12. 两条原则：分离控制与功能；集中控制（策略在控制组件，机制在被控组件）；星形模式与递归控制模式。
13. V&V：verification = product right（符合规格）；validation = right product（满足用户）。
14. 易错：把 view 和 viewpoint 混用；Process view 用部署图（错，应是活动图/并发）；把 4+1 的“+1”当成第五个独立视图而非连接四者的场景。