软件架构设计

核心概念与架构过程

· heleyang
软件架构设计 期末复习
目录

# 02 核心概念与架构过程

**一句话框架：**软件架构不是方框图本身，而是用高层设计决策组织系统的重要元素、外部可见属性及其关系，从而平衡利益相关者诉求并控制风险。

# 三个容易混淆的词

概念 关注点 答题关键词
Structure 结构 元素及静态关系 组成、连接、层次
Architecture 架构 关键结构加运行关系、属性与演进约束 高层、关键决策、难以更改
Design 设计 从高层到细节的全部方案活动 架构设计是设计中的高抽象层环节

# 为什么架构重要

  • **质量基础：**促进或阻碍性能、可用性、安全性、可修改性。

  • **早期约束：**服务边界、通信和部署方式越晚改越贵。

  • **沟通媒介：**让用户、管理者与开发团队讨论同一结构。

  • **复用抽象：**成熟决策可迁移到同类系统。

# 架构师职责：不是只画图

职责 实际含义 典型问题
协调利益相关者 在用户变化诉求与开发成本、可维护性之间达成妥协 哪个质量目标优先？
软件工程能力 用成熟实践组织设计、实现与验证 方案如何实施？
技术判断 理解选型影响而非追逐技术名词 选择会绑定哪些约束？
风险管理 识别早期决定失败的代价并准备缓解方案 最贵的失败点在哪里？

# 4+1 视图：从不同角度看同一系统

视图 回答的问题 记忆钩子
逻辑视图 系统主要职责和对象如何组织 做什么
进程视图 运行时并发、交互与通信如何发生 怎么跑
物理视图 软件元素如何部署到硬件/节点 跑在哪
开发视图 代码模块和开发组织如何安排 怎么造
用例 / 场景 如何用实际需求贯通各视图 为什么这样看

**简答题写法：**先写“视图用于隐藏不相关信息、突出关注点”，再列出四个视图的职责，最后说明 use case 串联并验证这些视图。

# 画图题示例：4+1 视图具体怎么画

UML 落笔原则：先用用例图确定一个关键场景作为“+1”，再围绕它分别画逻辑视图的类图、开发视图的组件图 / 包图、进程视图的时序图 / 通信图、物理视图的部署图；每张 UML 图都标出与该用例对应的元素、关系与验证点。

视图 图中具体画什么 UML 图型 答题标注
+1 场景 Actor“学生”完成“选课并支付”的主流程，可补登录/支付失败扩展场景 Use Case Diagram
用例图		 作为四视图追踪起点
逻辑视图 Course、Enrollment、Payment 等领域类、职责和关联 Class Diagram
类图		 回答“系统做什么”
开发视图 Web UI、Enrollment Module、Payment Adapter、Repository 等代码单元依赖 Component / Package Diagram
组件图 / 包图		 回答“代码怎么组织”
进程视图 学生请求经 Gateway、选课服务、支付服务、消息队列的运行时交互 Sequence / Communication Diagram
时序图 / 通信图		 标性能与可用性验证点
物理视图 客户端、负载均衡、应用容器、数据库与消息节点的部署映射 Deployment Diagram
部署图		 标冗余与故障隔离

  1. **选场景：**先把题目中的核心用户任务写成一条可执行场景，例如“学生选课并完成支付”。

  2. **画 +1：**画 Use Case Diagram / 用例图：放入 Actor、系统边界与“选课并支付”用例，可标注失败或退款扩展场景。

  3. 补四图：按“职责 → 代码 → 运行 → 部署”顺序补四张 UML 图：依次使用类图、组件图、时序图、部署图表达元素和关系。

  4. **连验证：**在过程/物理视图旁标注性能、可用性或安全性的验证点。

  5. **收束说明：**用一句话说明同一场景如何在四个视图中保持一致。

# 除了 4+1：Module / C&C / Allocation 三类视图怎么画

**先纠正一个理解：**不是“质量属性画 4+1，架构画三类视图”。更稳的说法是：4+1 Views 和 Module / C&C / Allocation Views 都是组织架构文档的视图框架；**质量属性（Quality Attributes）**是分析目标，会贯穿这些视图。

# Module View / 模块视图

  • **画什么：**模块、包、类、组件、接口、职责和依赖。

  • **怎么画：**先画分层或包结构，再标出核心模块职责，最后画依赖方向。

  • 常用 UML：Package Diagram、Component Diagram、Class Diagram。

  • **对应质量属性：**可修改性、可维护性、可测试性。

# C&C View / 组件-连接器视图

  • **画什么：**运行时组件、连接器、请求/响应、消息、事件流、数据流。

  • **怎么画：**先找运行时元素，再标同步调用、异步消息或管道流，最后写清连接器语义。

  • 常用 UML：Component Diagram、Sequence Diagram、Communication Diagram。

  • **对应质量属性：**性能、可用性、可靠性、并发和通信开销。

# Allocation View / 分配视图

  • **画什么：**软件元素到节点、容器、云资源、目录、团队或运行环境的映射。

  • **怎么画：**先画外部环境和部署节点，再把服务/进程/容器放到节点上，最后标网络与存储依赖。

  • 常用 UML：Deployment Diagram，也可画容器部署图或云部署图。

  • **对应质量属性：**部署、伸缩性、安全性、可用性和运维复杂度。

**答题表述：**如果题目问 4+1 Views，按逻辑、开发、进程、物理和用例场景回答；如果题目泛问 architecture views / candidate views / views in documentation，可以用 Module View、Component-and-Connector View、Allocation View 组织答案。质量属性不单独等于某个视图，而是通过场景、效用树、设计决策和不同视图中的结构证据来验证。

  1. **题目问“代码怎么拆”：**画 Module View，突出模块职责、接口和依赖方向。

  2. **题目问“运行时怎么交互”：**画 C&C View，突出 runtime elements、connectors、同步/异步通信。

  3. **题目问“部署到哪里”：**画 Allocation / Deployment View，突出服务到节点、容器、数据库和网络区域的映射。

  4. **题目问“质量属性怎么保证”：**先写质量属性场景或效用树，再说明哪个视图能展示对应的结构证据。例如性能看运行时通信和并发，可用性看冗余与故障隔离，可修改性看模块依赖。

知识出处：sources/slides-ocr/2026-05-27/pdftotext-triage/SEI06_Attribute-driven_design_ver2_005_001_14795.txt:417, 855-862, 952-953 提到 Module、Component-and-Connector、Allocation、Concurrency 与 Deployment 等视图用于推理不同质量属性；复习纪要 sources/supplemental/2026-05-28/recording-review/软件体系结构复习课录音整理版.md:120-124 强调视图不是简单画图，而是按关注点表达架构元素、关系、职责和约束。

# 架构过程的主链

阶段 输入 输出
识别 ASR 业务目标、需求、约束、stakeholder 关注点 排序后的质量属性场景
架构设计 ASR、模式、tactics 与设计备选 候选结构与关键决策
架构文档化 结构与决策 视图、接口、理由与风险记录
架构评估 文档与优先场景 风险发现、修正建议与验证结果

# 架构决策文档要记什么

问题、上下文、最终决策、备选方案、选择理由、影响与权衡、状态、相关决策和验证方式

架构文档化 = Views + Beyond Views。

  • **Views / 视图：**表达系统结构与关注点，例如 4+1 Views、Module View、Component-and-Connector View、Allocation / Deployment View。

  • Beyond Views / 视图之外的信息：补充图表达不完整的内容，包括路线图、视图概览、视图间映射、设计原因、业务目标、驱动因素、术语表、约束、索引、关键设计决定 / ADR、质量属性、部署与演进说明。

**答题表述：**文档化不是只画视图，而是用视图表达结构，再用 Beyond Views 说明为什么这样设计、受哪些目标和约束驱动、不同视图如何对应、关键决定是什么，以及系统如何部署和演进。

# 纪要补充：架构活动、文档化与演进作答

回到总结页：纪要可能考查方式索引 已把本知识点与相关训练题互链，复习时可从题型反查本节。

**考试用法：**架构过程题不要只背定义，要能按“识别依据 → 做出设计 → 记录文档 → 评估演进”说明架构活动如何服务质量属性与利益相关者。

考点 答题要点 落笔句式
架构活动四步 识别 ASR → 选择设计决定 → 输出架构文档 → 评估架构 先把质量需求场景化，再用设计决定处理驱动因素，最后用文档和评估让方案可沟通、可检查。
架构文档化 视图组合/排序、接口、设计决策、约束、风险、评估依据 文档不是截图集合，而是解释为什么这样设计、哪些约束必须遵守、哪些风险需要后续验证。
架构演进 时代需求/核心矛盾 → 解决的质量属性 → 牺牲点 → 新痛点 每种架构都来自当时最迫切的矛盾，迁移不是“更先进”，而是质量属性取舍发生变化。

**边界：**若补充资料提到考试后 AI 增强 / AI 原生架构，不纳入本页考试范围。

  • 问题、重要性、状态与最终决策。

  • 假设、约束、备选方案与论据。

  • 对质量属性的影响、风险与后续验证。

  • 决策之间可能存在约束、排除、启用、冲突、覆盖或备选关系。

**记忆句：**架构答题始终回到四个词：需求、取舍、视图、验证。

# 可直接背诵答案

# 英文题面常见问法

English prompt 答题要点
What is software architecture? Why is it important? 定义 → 利益相关者沟通 → 质量属性 → 早期关键决策 → 演进成本。
Explain the relationship between architecture, structure, and design. Structure 静态关系；Architecture 加入关键属性、运行时和约束；Design 是更广义活动。
What does a software architect do? 协调利益相关者、识别 ASR、做设计取舍、管理风险、输出和维护架构文档。
Describe the software architecture process. Identify ASRs → make design decisions → document architecture → evaluate architecture。
What should architecture documentation include? Views, interfaces, design rationale, constraints, risks, and evaluation evidence。

# 题 1：软件架构的定义与重要性

软件架构是系统的一组重要结构，包含软件元素、元素之间的关系以及元素的外部可见属性。它不是方框图本身，而是系统早期、关键且难以修改的一组高层设计决策。架构重要在于：它能够作为利益相关者沟通的共同媒介；能够促进或限制性能、可用性、安全性和可修改性等质量属性；能够降低后续演进中修改关键结构的成本；还可以形成可复用的抽象，为同类系统提供参考。

# 题 2：Architecture、Structure 与 Design 的区别

Structure 主要描述元素及其静态关系；Architecture 在结构基础上进一步关心外部可见属性、运行时交互、约束和演进中的关键决策；Design 是全部设计活动的统称，既包含架构层的高层决策，也包含模块、接口和算法等更细节的决定。因此，架构设计是设计的一部分，但并不是所有设计细节都具有架构意义。

# 题 3：4+1 视图

4+1 视图用于从不同关注点表达复杂系统。逻辑视图描述系统主要职责与结构；进程视图描述运行时并发和通信；物理视图描述软件元素到部署节点的映射；开发视图描述代码模块与组织方式；用例或场景作为“+1”，贯通并验证其他视图是否共同满足需求。

# 精选来源

  • 飞书考前复习纪要：关于架构定义、架构师职责、4+1 视图与架构活动的强调。

  • 上传资料：《扫描文档20260526_192514.pdf》（MinerU OCR）的 Software Architecture in General 与 Architecture Process 页面。

  • 内容补足：原始课件 `slides/01_Introduction.pdf` 与 `slides/09Architectural Decisions.pdf`；不以 `slides/readable_notes/` 的二次转写内容作为来源。

(注：内容由 AI 生成，请谨慎参考）