Debian apt提示Media change？处理cdrom源并切换国内镜像一劳永逸
2026/9/30 7:55:31
第 1 章后半段我读了两遍才理清。它把"架构与软件生命周期"和"4+1 视图模型"两件事塞在一节里，中间还穿插了构件、连接件这些到第 7 章才展开的概念。第一遍读的感受是：每句话都对，但不知道要拿来干什么。
后来发现，这节其实只回答一个问题：一份架构，怎么描述才算说清楚了。生命周期解决的是"什么时候做架构"，4+1 视图解决的是"做完往哪写"。想明白这两句，第 1 章剩下的内容就不散了。
一、架构设计卡在生命周期的哪一环
教材把软件生命周期切成六段，架构在每个阶段干的活是不一样的：
| 阶段 | 架构相关的活动 | 这阶段做错了会怎样 |
|---|---|---|
| 需求分析 | 从需求模型（用例）提炼出架构的约束与质量目标 | 架构做得再漂亮，做的是别的东西 |
| 设计 | 架构设计在这，产出构件划分、连接件、约束 | 后面所有返工的源头都在这 |
| 实现 | 按架构模型把构件一个个写出来或复用已有构件 | 构件接口跟架构对不上，集成时才发现 |
| 构件组装 | 用连接件把构件接起来，形成系统 | 连接件选型错了（比如该用消息队列却直连） |
| 部署 | 把构件装到物理节点上，物理视图在这落地 | 部署拓扑撑不住性能目标 |
| 后开发 | 架构的演化与维护，对应第 10 章 | 架构腐化，改一处坏三处 |
这张表最值得记住的是两句话：架构设计在设计阶段，但输入来自需求分析、约束到部署和后开发才兑现。选择题里问"架构设计属于哪个阶段"，答案在设计阶段，不会是需求分析阶段——需求阶段只产出需求模型，架构模型是设计阶段的产出物。
还有个容易踩的点：需求分析阶段的模型是架构设计的输入，不是架构设计本身。有些题目会把"用例模型"描述成架构模型的一部分来迷惑你，用例是需求侧的东西。
二、4+1 视图：五个视角，各画给谁看
4+1 视图是 Kruchten 在 1995 年提出的，教材第 1 章直接引用了它作为架构描述的标准做法。它说的是：一份架构从五个角度看，才说得完整。
| 视图 | 关注什么 | 主要面向谁 | 常用 UML 图 |
|---|---|---|---|
| 逻辑视图 | 系统对外的功能、业务概念与对象结构 | 最终用户、业务方 | 类图、对象图、状态图、顺序图 |
| 开发视图 | 代码的组织：包、子系统、库、构件划分 | 开发人员、项目经理 | 包图、构件图 |
| 进程视图 | 运行时的并发、同步、通信、性能与吞吐 | 系统集成人员 | 活动图、顺序图、通信图、时序图 |
| 物理视图 | 软件装在哪台机器上、网络拓扑、节点间通信 | 系统工程师、运维 | 部署图 |
| 场景（+1） | 用典型用例把前四个视图串起来验证 | 所有涉众 | 用例图、活动图 |
那个"+1"是场景，也叫用例视图。它特殊在不是第五个平行的视角，而是用来验证前四个视图的工具：拿一个典型业务流程跑一遍，看逻辑视图里的对象、进程视图里的线程、物理视图里的节点能不能对上。对不上就说明架构描述有缺口。
我一开始就把它当成"第五个视图"去背，结果做题时遇到"哪个视图用于验证其他视图的一致性"，直接选错。答案是场景。
三、视图和图不是一回事（对照表）
这是第 1 章和第 3 章 UML 最容易搅在一起的地方。视图是描述架构的角度，UML 图是表达视图的工具，两者不是一一对应的。
| UML 图 | 主要服务于哪个视图 | 会不会被别的视图借用 |
|---|---|---|
| 类图、对象图 | 逻辑视图 | 开发视图偶尔会用 |
| 包图、构件图 | 开发视图 | 部署阶段看构件部署位置 |
| 顺序图、通信图 | 进程视图 | 逻辑视图描述对象交互时也用 |
| 活动图 | 进程视图 | 场景描述业务流时常用 |
| 状态图 | 逻辑视图 | 进程视图描述状态迁移时也会出现 |
| 部署图 | 物理视图 | 基本专用 |
| 用例图 | 场景视图 | 需求阶段也用，注意阶段归属 |
所以遇到"某视图用什么图描述"，答案往往是一组图而不是一张图。反过来问"顺序图描述哪个视图"，标准答案是进程视图，但逻辑视图里也会用——碰到这种题，判断依据是"主要服务于谁"，选最贴近的那个。
四、易混辨析：两对长得最像的视图
真正让我丢分的是这两对。它们名字差得远，实际内容很容易张冠李戴。
第一对：逻辑视图 vs 开发视图
| 维度 | 逻辑视图 | 开发视图 |
|---|---|---|
| 回答的问题 | 系统是什么、能做什么 | 代码怎么摆、谁负责哪块 |
| 基本单元 | 类、对象、业务概念 | 包、子系统、库、模块 |
| 面向涉众 | 用户、业务方 | 开发人员、项目经理 |
| 看不懂的后果 | 不知道系统干嘛的 | 不知道代码在哪、怎么分工 |
| 一句话区分 | 讲业务 | 讲代码组织 |
区分方法很土但有效：逻辑视图里的东西业务方能看懂（订单、账户、库存），开发视图里的东西只有开发能看懂（order-service 包、common-utils 库）。题目里出现"子系统划分"“包结构”"复用"这类词，八成在说开发视图。
第二对：进程视图 vs 物理视图
| 维度 | 进程视图 | 物理视图 |
|---|---|---|
| 回答的问题 | 运行时谁在跑、怎么并发通信 | 软件装在哪、机器怎么连 |
| 基本单元 | 进程、线程、消息队列、锁 | 节点、服务器、网络链路 |
| 关注质量属性 | 性能、并发、吞吐、可伸缩性 | 可用性、可靠性、部署成本 |
| 典型图 | 活动图、顺序图、时序图 | 部署图 |
| 一句话区分 | 讲运行 | 讲机器 |
一个记忆锚点：进程视图是软件的运行时，物理视图是硬件的分布。题目里出现"线程"“并发”“同步”“死锁"走进程视图；出现"服务器”“节点”“机房”"网络拓扑"走物理视图。
五、这个点怎么考，论文能不能用
先说考频判断，基于我做几遍历年练习题的印象（不针对具体某一次考试）：
- 综合知识：稳定出现，一年至少一次，题型固定——给你一段描述问属于哪个视图，或者问某视图面向谁。属于送分题，但前提是你真分得清。
- 案例分析：很少单独考，但 2019 年之后案例里出现过"补充架构描述缺失的视图"这类问法，属于低频但一旦遇到就是送分。
- 论文：这是 4+1 视图真正值钱的地方。论文评分里"描述你设计的架构"是必写的段落，很多人写不出来或者写成技术栈清单。
论文里的用法我试过，确实好用：在"架构设计"那一节，用四个视图分四小段铺开——逻辑视图写系统的功能划分与关键类；开发视图写模块分层和团队分工；进程视图写并发模型和异步消息；物理视图写部署拓扑和容灾。四段下来 800~1000 字，内容全是架构语言，比写"我们用了 Spring Cloud"像样得多。
再补一句：场景视图在论文里也别浪费，可以拿它写"我用典型业务流程验证了四个视图的一致性"，这一句能顺带体现你做过架构评审，阅卷老师会看。
六、怎么记住
我自己的口诀是十个字：
逻辑讲功能，开发讲包，进程讲并发，物理讲机器，场景把四个串起来。
配一张速查表：
| 我听到这些词 | 对应视图 |
|---|---|
| 类、对象、业务概念、功能 | 逻辑视图 |
| 包、子系统、模块、复用、分层 | 开发视图 |
| 线程、进程、并发、同步、消息 | 进程视图 |
| 节点、服务器、部署、网络拓扑 | 物理视图 |
| 用例、典型流程、验证一致性 | 场景视图（+1） |
第 1 章到这里就收尾了。它的价值不在于记住多少概念，而在于给你一个坐标系：后面第 7 章讲架构风格，其实是在讲逻辑视图和开发视图可以有哪些套路；第 13 章层次式架构，本质是开发视图的一种；第 14 章云原生，讲的又是物理视图和进程视图。
下一篇进入第 2 章计算机系统基础知识，从 CPU 结构、存储器层次和总线开始。这章知识点密集但考得不深，我会重点标出哪些是真考点、哪些扫一眼就行。