企业官网建设流程全解析

系列第 3 篇。本篇讲 ABSD —— 软考系统架构设计师「体系结构设计方法」这一章的核心考点，也是定义型选择题最密集的一节。

一、先说结论：ABSD 到底解决什么问题

一句话记住它的定义：

ABSD 是由体系结构驱动的，即由构成体系结构的商业、质量和功能需求的组合驱动。

这句话里有个容易被忽略的信息点——驱动的来源是「商业 + 质量 + 功能」三类需求的组合，不是只看功能需求。考试里如果把"商业需求"或"质量需求"从驱动因素里摘掉，就是错的。

它要解决的真实痛点是什么？传统做法是「先把需求分析做完，再开始设计」。但在产品线系统或长期运行的系统里，需求根本不可能一次性定完——等你把所有需求收集齐，窗口期早就过了。

ABSD 的应对方式是：设计活动从项目总体功能框架明确就开始，此时需求抽取和分析还没有完成（甚至远远没有完成）。

这里有个必须记住的边界：

ABSD 方法的三个特点，也是它的三条「命门」：

1. 自顶向下—— 从系统整体往下切；
2. 递归细化—— 每一层都用同样的方式再切一刀；
3. 迭代—— 且迭代的每一个步骤都是清晰定义的。

这三点带来一个直接后果，教材原文是这么说的：

不管设计是否完成，体系结构总是清晰的，有助于降低体系结构设计的随意性。

「降低随意性」这五个字，是选择题里描述 ABSD 价值时最常出现的标准答案。

二、三大基础：拆 · 选 · 套

ABSD 有三个基础，这是本章最高频的送分点，也是最高频的送命题。

口诀拆 · 选 · 套，顺序本身就是逻辑链：不拆功能就谈不上选风格，没选定风格，模板也无处安放。所以顺序不会记反。

三个基础各自还有几个细节点：

基础一「功能的分解」：关键词是「已有的基于模块的内聚和耦合技术」。也就是说 ABSD 不发明新的分解理论，它直接沿用软件工程里成熟的内聚/耦合度量。

基础二「选择体系结构风格」：这里的目的写得很明确——「实现质量和商业需求」。上一篇文章讲过架构风格是质量的载体，ABSD 把这件事正式写进了方法论基础里。

基础三「软件模板的使用」：这里的「模板」不是 Word 模板，而是可复用的软件系统结构——包括这类元素在共享服务和底层构造上如何交互，以及属于这类元素的功能（例如「每个元素必须记录某些重大事件」「每个元素必须为运行期间的外部诊断提供测试点」）。

三、递归细化：设计元素怎么一层层长出来

ABSD 是一个自顶向下、递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

它用的设计元素只有三类，按层展开：

这一节有三个高频错点：

错点一：把「自顶向下」记成「自底向上」。选项里出现自底向上直接排除。

错点二：第 2 层产物写成「构件」。教材原文是「概念构件」——带"概念"二字，表示它还在概念层，没落到实现层。只有递归终止时才产出软件构件和类。

错点三：以为模板只在顶层出现。看表格第二列——每分解一层，都会携带一次模板：顶层叫「软件模板」，第 2 层起叫「附加软件模板」。

记忆锚点：每切一刀，必拿一次模具。

四、两种视角与四个视图

这是本章最反直觉、也最容易失分的部分。

先说两种视角。它的反直觉之处在于：展示的东西和判断的东西，不是同一类东西。

看到的是「结构」，推断出的却是「属性」——这中间是跨的。

记忆口诀：静质动行（谐音"静止动行"）。静态视角 → 质量特性；动态视角 → 行为特性。

网上大量博客把这条写成「静态视角判断功能，动态视角判断并发」，正好把因果两端掉了包。这是本篇最需要警惕的一处。

再说四个视图。ABSD 设计了四个特定视图，可以和 RUP 的 4+1 视图对照记忆：

关键理解锚点：ABSD 把 RUP 4+1 里的「用例视图」抽掉了。为什么？因为用例在 ABSD 里不是一种"视图"，而是需求捕获的手段——它被挪到了需求侧，不在视图体系里。这条经常被出成「ABSD 有几个视图」的选择题。

逻辑视图还有一个细节考点：它记录的是设计元素的功能和概念接口。功能定义了它在系统中的角色，而这个角色包括功能、性能等。

• 陷阱 A：是「概念接口」，不是实现接口；

• 陷阱 B：角色里「性能」也算，别只填功能。

五、需求怎么被捕获：用例 + 质量场景

ABSD 的输入侧是「双通道」的：

也就是说，功能需求靠用例描述，质量需求靠质量场景描述。两者缺一不可——这也是 ABSD 强调"由商业、质量和功能需求组合驱动"的落地方式。

质量场景分四类，口诀变 · 性 · 靠 · 交：

造句串记：「系统变更时性能要靠得住，还得交互好。」

更重要的一个考点是质量场景必须同时包含两类：

两条铁律：

1. 质量场景必须同时包括预期的和非预期的——只写预期就是错的；
2. 非预期场景决定的是「边界条件」，不是"功能范围"，也不是"用户规模"。

六、六阶段开发模型：从需求到演化

前面五节是"概念与术语"，这一节是"过程"。教材把它拆成六个阶段，每个阶段都有明确产物。

阶段① 体系结构需求：标识构件的三步

「标识构件」是这个阶段的技术核心，分三步走：

1. 生成类图（教材提到可用 Rational Rose 这类工具）
2. 对类进行分组（依据隔离性、继承性、聚合性等聚类）
3. 把类打包成构件（合并类簇，形成可复用构件）

最后是需求评审，要求多角色参与（含客户、测试员），验证需求真实性及构件划分的合理性。

阶段③ 文档化：输出两份文档

这是常考的"数量考点"，是两份，不是一份：

文档编写的三条原则：从使用者视角编写、及时更新分发、保证完整性（开发者手上的必须是最新版）。

阶段④ 复审：必须由外部人员参加

这是最容易被出题的点：复审要安排一次由外部人员参加的评审，人员构成是「用户代表 + 领域专家」。

为什么必须外部？因为要标识潜在的风险，以及尽早发现架构设计中的缺陷和错误——内部人员容易陷入自己的设计假设。

复审要检查的内容包括：架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件划分是否合理、文档表达是否明确、构件设计是否满足功能与性能要求等。

补一个过程关系：架构设计、文档化和复审是一个迭代过程——复审不通过就回到前序阶段修订，不是单向流水线。

七、ABSD、SAAM/ATAM 与 ADD 的分工

学到这里容易和上一篇混淆。三者不是竞争关系，而是分工关系：

一句话区分：ABSD 和生产车间，SAAM/ATAM 是质检车间。

ABSD 与 ADD 的共同点是都采用自顶向下、递归、迭代的方式；差别在于 ABSD 更完整地定义了三大基础（功能分解、体系结构风格、软件模板），而 ADD 把重心放在质量属性场景与高优先级驱动因子上。考试频次上 ABSD 明显更高，ADD 了解定位即可，不必死磕步骤。

八、10 条选择题陷阱清单

以下每条都是能直接排除选项或锁定答案的判据。

九、考前速记卡

一句话总纲：

ABSD =三基础（拆·选·套）+递归下切（每层带模板）+两种视角（静质动行）+四个视图+需求双捕获（用例 + 质量场景）+六阶段过程

四条记忆钩子：

1. 拆 · 选 · 套—— 三大基础的动作链
2. 静质动行—— 静态看质量、动态看行为
3. 变 · 性 · 靠 · 交—— 四类质量场景
4. 实现≈开发、配置≈部署—— 四视图对齐 RUP 4+1

记忆宫殿（盖一栋楼）：

拆房间（功能分解）→ 选建筑风格（体系结构风格）→ 拿标准模具（软件模板）； 从整栋楼切到楼层、再切到房间，每切一层都拿一次模具（递归 + 每层模板）； 看图分两种看法——平面图看质量、动线图看行为（静态 / 动态视角）； 专业图纸共四张：逻辑、进程、实现、配置； 甲方提需求分两块——要什么功能（用例）、极限条件下不能塌（质量场景）； 最后走完六步流程：需求 → 设计 → 文档 → 复审 → 实现 → 演化。

十、下一篇预告

ABSD 讲的是「一个系统怎么从需求长出架构」。但企业做产品线时，面对的不是一个系统，而是一族系统——它们共享同一批领域需求，架构也高度相似。

下一篇讲DSSA（特定领域软件架构）：它和 ABSD 是什么关系、参与角色有哪几类、三层次模型怎么划分、建立过程分几步走。这一节同样是定义型考点密集区，和本篇合起来，正好覆盖「体系结构设计方法」这一章的完整考法。

系列文章

1. 软件架构风格：5 大一级 + 12 种二级，一图归位 + 判型三步法
2. 架构评估方法 ATAM 与 SAAM：四阶段 9 步 + 效用树 + 四类判定
3. ABSD 基于架构的软件设计：三大基础 + 递归细化 + 六阶段模型（本篇）
4. DSSA 特定领域软件架构（预告）