【软考系统架构设计师全链路通关实战】第 21 篇：软件架构建模：4+1 视图与架构描述语言

本系列定位：以软考系统架构设计师（高级）考试为主线，语言无关的架构方法论视角，覆盖官方教程（第二版）全部 20 章考点，按「综合知识 → 案例分析 → 论文」三科组织，每篇含考点精讲 + 真题规律 + 应试技巧 + Mermaid 图解。

---

本篇你将学到

• 4+1 视图模型的完整框架：逻辑视图、开发视图、进程视图、物理视图与场景视图的分工
• 每个视图对应哪类利益相关者、使用哪种建模图示——综合知识必考的配对题
• 架构描述语言（ADL）的三要素：构件、连接件、架构配置
• 架构文档化：架构规格说明与架构质量属性说明，以及「文档写给谁看」
• 多视图之间的一致性问题与检查思路
• 智联云商「一页纸架构」实践：用五张简图一次画全 4+1 视图

第 20 篇说过：架构是一组结构，不是单一结构。既然是一组，就需要多个视角分别描述——这正是 4+1 视图模型要解决的问题。

---

考点热力表

考点	综合知识	案例分析	论文
4+1 视图与利益相关者配对	★★★ 必考配对/选择题	★★ 补图题常以某视图出题	★★ 论文建模段落的骨架
各视图采用的图示类型	★★ 高频概念题	★★ 补图题判断视图类型	★
ADL 三要素（构件/连接件/配置）	★★ 常考	☆	★ 偶用
架构文档化（两类说明）	★ 偶考	★★ 案例问「应产出什么文档」	★★ 论文提及文档化管理
视图一致性	★ 偶考	★ 偶现	★ 体现深度的加分点

---

一、为什么需要多个视图：盲人摸象问题的工程解法

任何一张单一的架构图都只能展示系统的某一个侧面。给运维看的部署图对业务分析师毫无意义；用类图向客户讲解系统等于对牛弹琴。1995 年，Philippe Kruchten（RUP 的主要作者）提出 4+1 视图模型，用五个互补的视图共同描述软件架构，成为事实上的架构描述标准框架。

先建立总框架图，再逐个展开：

五视图的关系记住一句话：场景视图是粘合剂——它用一组重要用例把其余四个视图串起来验证完整性，这就是「+1」的含义。没有场景，四个视图可能各自成立却拼不出一个能跑的系统。

二、五个视图逐一详解

2.1 逻辑视图：功能如何分解给用户看

面向对象的分解视角，回答「系统向最终用户提供了哪些功能，这些功能如何组织」。

• 服务对象：最终用户、业务分析师
• 图示手段：用例图、类图、对象图（逻辑概念层面）
• 分解单位：功能模块、业务对象、领域服务
• 关键问题：功能职责的划分是否清晰、领域概念是否正确

智联云商例子：逻辑视图中的「订单管理」是一个业务概念，包含下单、支付回调、取消、退款等功能，以及订单、订单项、支付单这些业务对象之间的关系。

2.2 开发视图：代码如何组织给程序员看

软件在开发环境中的组织，回答「代码怎么分层分包、模块怎么划分、有哪些公共组件」。

• 服务对象：程序员、开发管理人员
• 图示手段：模块图、包图、组件图
• 分解单位：模块、包、子系统、类库、第三方依赖
• 关键问题：模块划分、分层规则、编译依赖、代码复用

逻辑视图的「订单管理」在开发视图中落地为订单模块的包结构：api（对外接口）、service（业务逻辑）、dao（数据访问）、model（领域对象），并依赖公共的支付网关组件。

2.3 进程视图：并发与同步给系统集成师看

系统的运行时视角，回答「系统有哪些并发执行单元，它们如何通信与同步」。

• 服务对象：系统集成师、性能优化人员
• 图示手段：进程/线程图、通信图、时序图（侧重交互时序）、状态图
• 分解单位：进程、线程、任务、消息队列
• 关键问题：并发度、同步机制、死锁风险、负载分布、容错切换

智联云商例子：订单服务进程内部用线程池处理 HTTP 请求；下单后通过消息队列异步通知库存与积分服务；定时任务进程执行超时关单。这些并发单元与消息交互就画在进程视图里。

2.4 物理视图：部署映射给运维看

软件到硬件的映射，回答「进程与数据物理地分布在哪些节点上，网络如何连接」。

• 服务对象：系统运维人员、部署实施人员
• 图示手段：部署图
• 分解单位：物理节点（服务器、容器、网络设备）、通信链路
• 关键问题：部署拓扑、资源容量、网络带宽、可用性冗余（主备、集群、多机房）

智联云商例子：应用部署在两个应用节点做负载均衡，数据库一主一从，静态资源走 CDN，消息队列独立节点。

2.5 场景视图：用例把四个视图串起来

也叫「用例视图」。它从用户视角挑选一小组关键场景（用例），把逻辑、开发、进程、物理四个视图中的元素串联一遍，验证「这个架构组合起来真的能支撑核心业务」。

• 服务对象：所有利益相关者（用户与开发团队的公共语言）
• 图示手段：用例图、时序图（场景实现路径）
• 关键问题：架构元素之间的协作能否走通关键路径

智联云商的锚点场景是「用户下单」：前端（物理视图的接入层）→ 订单模块（开发视图）→ 订单进程（进程视图）→ 涉及订单、库存、支付对象（逻辑视图）。一个场景，四个视图的元素全部出场。

四个主视图 + 场景的对照总表（这张表就是配对题的答案）：

视图	描述视角	服务对象	图示手段	关键词
逻辑视图	功能分解	最终用户	类图/对象图/用例图	功能、业务对象
开发视图	软件模块组织	程序员	模块图/包图/组件图	分层、模块、复用
进程视图	运行时并发	系统集成师	进程图/时序图/状态图	并发、同步、通信
物理视图	软硬件映射	运维人员	部署图	节点、部署、网络
场景视图	用例串联	全体（+1）	用例图/时序图	验证、粘合

考试干扰项惯用手法：把「部署图」配给逻辑视图、把「运维人员」配给进程视图、把场景视图说成「可有可无的辅助视图」。用上表做锚，逐项排除。

理解 4+1 视图还有一层更深的价值：它本质上是一份沟通地图。实践中大量架构沟通失败，根源不是图画画得不好，而是「拿错了图见错了人」——给客户看包结构、给运维看类图，都是典型的「视图错配」。把五视图的配对关系内化成条件反射后，你在任何架构汇报场合都能先问自己两个问题：眼前这位听众属于哪类利益相关者？我应该出示哪个视图、用哪个抽象层次的语言？这两个问题答对了，技术方案的通过率会显著提升。案例分析题同样受益：题干描述某系统的某个侧面（如「系统的并发执行单元与消息交互」「软件到硬件节点的映射」），你要能立刻反查出这是进程视图还是物理视图，再按对应视图的图示规范补图——补图题的第一步永远是对视图类型的正确判定，判错了视图，图画得再标准也拿不到分。

另外一个考纲内的细节：五视图的详略程度是可裁剪的。4+1 是框架不是教条——对纯单体小系统，进程视图可以简化甚至并入开发视图；对无独立部署的类库项目，物理视图可以省略。但场景视图永远不该省，因为它承担着「验证其余视图拼起来能不能跑」的职责。裁剪的判断标准是「该视图服务的利益相关者是否真实存在」：某类干系人不存在，对应视图就可以弱化；反之，只要有运维介入，物理视图就必须严谨。这个「按读者裁剪视图」的思想，与前文文档化部分「写给谁看」的表格一脉相承，也是架构思维区别于画图工具思维的分水岭。

从应试角度再给一个提醒：4+1 视图与后续考点的勾连非常紧密，孤立背诵性价比低。逻辑视图与开发视图是第 25 篇 ABSD 架构设计阶段的核心产出；进程视图里的并发与同步直接呼应第 04 篇进程管理；物理视图的部署拓扑是第 41 篇云原生容器化改造的对象；场景视图的用例思想来自第 12 篇 UML 用例图，质量属性场景（第 30 篇）又是对它的深化。复习时建议以「五视图」为索引做一次跨篇串联：每张视图背后站着哪些已学概念、又将服务哪些后续考点，把这张勾连网在纸上画一遍，整个架构核心模块的骨架就立起来了——这正是第 02 篇强调的知识地图法在灵魂模块的首次实战。

三、架构描述语言（ADL）：三要素

架构描述语言（Architecture Description Language）是在形式化语言基础上设计的专用语言，用于对软件架构进行形式化描述与分析。学界提出过多种 ADL（如 Wright、UniCon、C2、Rapide、Aesop 等），考试不考具体某种，考的是它们共同的三要素：

要素	内容	说明
构件（Component）	计算或数据存储的独立单元	定义接口与计算语义，是架构的基本功能块
连接件（Connector）	构件间交互的建模单元	过程调用、消息传递、事件广播、管道、共享存储——连接件本身也是「一等公民」，有接口与语义，不只是「一条线」
架构配置（Configuration）	构件与连接件的拓扑结构	描述它们如何组合成完整架构，约束其连接方式，可用于分析系统的整体性质（如是否有死锁、是否可扩展）

ADL 与第 20 篇的「架构 = 构件 + 连接件 + 约束」直接对应：架构配置承担了「约束」的表达。ADL 的价值在于可形式化分析——因为描述是精确的，才能对架构做一致性检查、死锁分析、性能推导。但 ADL 也因形式门槛高、与主流编程语言脱节，未在工业界大规模普及，实务中普遍用「非形式化的建模图 + 自然语言文档」替代——这个评价类的表述在案例分析中出现过，值得记一句。

UML 与 ADL 的关系也常被提及：UML 是通用建模语言，并非为架构描述专门设计，缺少对连接件的一等公民支持，但凭借工具生态成为工业界事实标准；ADL 精确但小众。一句话：UML 赢在工程，ADL 赢在严格。

关于 ADL 三要素，再补一个选择题层面的辨析技巧：题目常给出一段对某元素的描述让你判断它是构件、连接件还是架构配置。判断的钥匙在连接件上——多数干扰项都埋在这里。例如「远程过程调用」「共享缓冲区」「事件广播通道」「管道」这些描述的都是交互机制，无论它看起来多么像一个实体（比如消息中间件是一个软件产品），在架构描述层面它们都归为连接件；而「订单处理单元」「价格计算引擎」这类承担计算或数据职责的单元才是构件。至于架构配置，识别特征是「整体性」词汇：拓扑、组合方式、连接约束、全局性质。还有一类反向题问「ADL 与一般编程语言的差异」，标准答案落在两点：ADL 描述的是抽象层次更高的系统结构（构件接口与交互，而非算法与数据结构的实现），且具备可形式化分析能力（能对配置做一致性、死锁、性能等性质推导）——这两点也是「为什么有了编程语言还需要 ADL」的教科书式回答。

四、架构文档化：两类核心说明与「写给谁看」

架构文档化是 ABSD（第 25 篇）六步骤之一，产出两类核心文档：

1. 架构规格说明（Architecture Specification）：对架构本身的结构化描述——用 4+1 视图（或裁剪后的多视图）描述构件、连接件、配置及设计决策，回答「架构是什么样」。
2. 架构质量属性说明（质量规格说明）：描述架构如何满足质量属性需求——性能指标、可用性目标、安全等级、可修改性要求及其设计战术（与第 30、31 篇质量属性衔接），回答「架构凭什么满足质量要求」。

文档化中最重要的问题不是「写什么」，而是「写给谁看」：

读者	最关心的视图	文档化要点
客户 / 业务方	场景视图、逻辑视图	用业务语言，少出现技术术语
开发人员	开发视图	分层规则、模块接口、依赖约束必须明确
运维人员	物理视图	部署拓扑、容量、扩缩容方式
项目管理者	全部概览 + 进程视图	依据模块划分做分工与估算

文档实践的两条原则：一视图文档化（每张视图配文字说明：图示、图外文字描述、两者互补）与覆盖利益相关者（读者缺位的需求不写进文档等于没写）。架构文档还要记录决策及理由（第 20 篇 ADR 思想的延续）——只画图不留理由的文档，半年后没人敢动。最后记住文档化的时机原则：文档应与架构活动同步产出而非事后补写——事后补写的文档天然失真，且起不到「过程沉淀」的作用；案例题问「文档管理存在的问题」时，「文档滞后于架构实际状态」是标准答案之一。

五、一页纸架构实践：智联云商的 4+1 视图

把智联云商 v1（单体分层，见第 20 篇 ADR-001）用五个简图各画一笔，体会视图间的「分工与翻译」。

逻辑视图（功能与业务对象）：

开发视图（模块与分层）：

进程视图（并发单元）：

物理视图（部署拓扑）：

场景视图（锚点用例：下单）：买家提交订单 → 订单模块校验并锁定库存（开发视图 order 包 / 进程视图 Web 进程）→ 生成订单与订单项（逻辑视图）→ 支付回调后消息异步通知积分服务（进程视图 MQ）→ 全部落在物理视图的应用节点与数据库主从上。一条场景线，四个视图的元素全部被点名。

视图间的一致性

多视图各自维护，最大的风险是彼此矛盾：逻辑视图说「支付是独立业务对象」，开发视图却把支付代码揉进订单模块；进程视图画了异步消息，物理视图却没给消息队列留节点。一致性检查的三条主线：

1. 元素可追溯：场景视图中的每个步骤都能落到其余视图的具体元素上（场景是验证器）。
2. 映射关系闭合：逻辑→开发（功能分给模块）、开发→进程（模块归入进程）、进程→物理（进程落到节点），链条上不许有「悬空元素」。
3. 变更联动：任何视图变更时同步评估其余视图的连带影响——这正是架构演化（第 27 篇）中文档维护的日常动作。

案例题若问「架构文档存在什么问题」，优先从「视图缺失」「文档未覆盖某类干系人」「视图间不一致」三点作答，命中率极高。

一页纸架构做完后值得复盘一次方法论收获。第一，画图顺序有讲究：实践中推荐的顺序是先逻辑视图（把领域概念钉死）、再开发视图（把概念映射成模块）、再进程与物理视图（把运行与部署形态定下来）、最后用场景视图回放验证——这个顺序本质上是「从问题域到解决方案域」的推进，跳步画图（比如上来就画部署图）最容易出现「部署拓扑很漂亮但撑不住任何一个核心用例」的空中楼阁。第二，每个视图只回答一类问题：一旦发现自己在逻辑视图里讨论线程数或在物理视图里讨论类的关系，就是视图越界了，越界的内容应剥离到正确的视图去——视图的纪律性与分层的纪律性同源，都是关注点分离。第三，五张图之间的连线关系本身就是设计信息：逻辑对象归哪个模块、模块跑在哪个进程、进程落在哪个节点，这三级映射每定一次，就是一次第 20 篇所说的「早期决策」。把这三条复盘写进论文的「架构设计过程」段落，比单纯罗列五张图的名字更有说服力——评卷人寻找的正是这种「我做过并且想过」的痕迹。

本篇小结

知识点	核心内容
4+1 模型	逻辑/开发/进程/物理四视图 + 场景做串联验证（+1）
视图配对	逻辑→用户→类图；开发→程序员→包图；进程→集成师→时序图；物理→运维→部署图
ADL 三要素	构件（计算单元）、连接件（交互一等公民）、架构配置（拓扑与约束）
架构文档化	架构规格说明 + 架构质量属性说明；文档必须覆盖全部利益相关者
一致性	场景可追溯、四层映射闭合、变更联动
智联云商	五张简图完成一页纸架构；下单场景贯穿四视图

---

下篇预告

第 22 篇：架构风格（一）：数据流与调用返回风格
管道-过滤器风格与批处理风格到底差在哪一句话上？编译器流水线、OSI 七层、三层架构分别是什么风格的化身？「题干描述→判断风格」的识别题怎么秒杀？架构风格六大门派的前两派登场。

---

如果本篇内容对你有帮助，欢迎点赞收藏！有任何疑问，欢迎在评论区交流。