系列第 3 篇。本篇讲 ABSD —— 软考系统架构设计师「体系结构设计方法」这一章的核心考点也是定义型选择题最密集的一节。一、先说结论ABSD 到底解决什么问题一句话记住它的定义ABSD 是由体系结构驱动的即由构成体系结构的商业、质量和功能需求的组合驱动。这句话里有个容易被忽略的信息点——驱动的来源是「商业 质量 功能」三类需求的组合不是只看功能需求。考试里如果把商业需求或质量需求从驱动因素里摘掉就是错的。它要解决的真实痛点是什么传统做法是「先把需求分析做完再开始设计」。但在产品线系统或长期运行的系统里需求根本不可能一次性定完——等你把所有需求收集齐窗口期早就过了。ABSD 的应对方式是设计活动从项目总体功能框架明确就开始此时需求抽取和分析还没有完成甚至远远没有完成。这里有个必须记住的边界容易记错的点正确表述设计提前开始 ⇒ 需求分析可以停了错。设计开始不意味着需求分析终止两者应该并行适用场景不可能预先决定所有需求时如产品线系统、长期运行系统快速开始设计至关重要ABSD 方法的三个特点也是它的三条「命门」自顶向下—— 从系统整体往下切递归细化—— 每一层都用同样的方式再切一刀迭代—— 且迭代的每一个步骤都是清晰定义的。这三点带来一个直接后果教材原文是这么说的不管设计是否完成体系结构总是清晰的有助于降低体系结构设计的随意性。「降低随意性」这五个字是选择题里描述 ABSD 价值时最常出现的标准答案。二、三大基础拆 · 选 · 套ABSD 有三个基础这是本章最高频的送分点也是最高频的送命题。基础记忆动词教材原话要点1功能的分解拆使用已有的基于模块的内聚和耦合技术2通过选择体系结构风格来实现质量和商业需求选注意是实现质量和商业需求不是只实现功能3软件模板的使用套软件模板利用了一些软件系统的结构口诀拆 · 选 · 套顺序本身就是逻辑链不拆功能就谈不上选风格没选定风格模板也无处安放。所以顺序不会记反。三个基础各自还有几个细节点基础一「功能的分解」关键词是「已有的基于模块的内聚和耦合技术」。也就是说 ABSD 不发明新的分解理论它直接沿用软件工程里成熟的内聚/耦合度量。基础二「选择体系结构风格」这里的目的写得很明确——「实现质量和商业需求」。上一篇文章讲过架构风格是质量的载体ABSD 把这件事正式写进了方法论基础里。基础三「软件模板的使用」这里的「模板」不是 Word 模板而是可复用的软件系统结构——包括这类元素在共享服务和底层构造上如何交互以及属于这类元素的功能例如「每个元素必须记录某些重大事件」「每个元素必须为运行期间的外部诊断提供测试点」。三、递归细化设计元素怎么一层层长出来ABSD 是一个自顶向下、递归细化的方法软件系统的体系结构通过该方法得到细化直到能产生软件构件和类。它用的设计元素只有三类按层展开层级输入产物最顶层系统若干概念子系统 一个或若干个软件模板第 2 层概念子系统概念构件 一个或若干个附加软件模板递归终止—能产生软件构件和类这一节有三个高频错点错点一把「自顶向下」记成「自底向上」。选项里出现自底向上直接排除。错点二第 2 层产物写成「构件」。教材原文是「概念构件」——带概念二字表示它还在概念层没落到实现层。只有递归终止时才产出软件构件和类。错点三以为模板只在顶层出现。看表格第二列——每分解一层都会携带一次模板顶层叫「软件模板」第 2 层起叫「附加软件模板」。记忆锚点每切一刀必拿一次模具。四、两种视角与四个视图这是本章最反直觉、也最容易失分的部分。先说两种视角。它的反直觉之处在于展示的东西和判断的东西不是同一类东西。视角展示判断静态视角功能组织质量特性动态视角并发行为行为特性看到的是「结构」推断出的却是「属性」——这中间是跨的。记忆口诀静质动行谐音静止动行。静态视角 → 质量特性动态视角 → 行为特性。网上大量博客把这条写成「静态视角判断功能动态视角判断并发」正好把因果两端掉了包。这是本篇最需要警惕的一处。再说四个视图。ABSD 设计了四个特定视图可以和 RUP 的 41 视图对照记忆ABSD 视图RUP 41 视图记忆锚点逻辑视图逻辑视图名称相同进程视图进程视图名称相同实现视图开发视图写代码的地方 → 实现 ≈ 开发配置视图部署视图机器怎么摆 → 配置 ≈ 部署关键理解锚点ABSD 把 RUP 41 里的「用例视图」抽掉了。为什么因为用例在 ABSD 里不是一种视图而是需求捕获的手段——它被挪到了需求侧不在视图体系里。这条经常被出成「ABSD 有几个视图」的选择题。逻辑视图还有一个细节考点它记录的是设计元素的功能和概念接口。功能定义了它在系统中的角色而这个角色包括功能、性能等。陷阱 A是「概念接口」不是实现接口陷阱 B角色里「性能」也算别只填功能。五、需求怎么被捕获用例 质量场景ABSD 的输入侧是「双通道」的捕获手段捕获什么用例功能需求质量场景质量需求也就是说功能需求靠用例描述质量需求靠质量场景描述。两者缺一不可——这也是 ABSD 强调由商业、质量和功能需求组合驱动的落地方式。质量场景分四类口诀变 · 性 · 靠 · 交口诀字场景类型变变更场景性性能场景靠可靠性场景交交互性场景造句串记「系统变更时性能要靠得住还得交互好。」更重要的一个考点是质量场景必须同时包含两类类型例子用途预期场景每年用户增长 10%常规预估相当于体检非预期场景每年用户增长 100%决定设计的边界条件相当于极限压测两条铁律质量场景必须同时包括预期的和非预期的——只写预期就是错的非预期场景决定的是「边界条件」不是功能范围也不是用户规模。六、六阶段开发模型从需求到演化前面五节是概念与术语这一节是过程。教材把它拆成六个阶段每个阶段都有明确产物。阶段核心动作关键产物① 体系结构需求需求获取 → 标识构件 → 需求评审构件清单② 体系结构设计提出模型 → 映射构件 → 分析交互 → 产生体系结构 → 设计评审软件体系结构③ 体系结构文档化编写两份文档体系结构规格说明 质量设计说明书④ 体系结构复审外部人员参加评审风险清单、缺陷清单⑤ 体系结构实现分析设计 → 构件实现 → 组装 → 测试可运行系统⑥ 体系结构演化需求变化归类 → 制定演化计划 → 增删改构件 → 组装测试演进后的架构阶段① 体系结构需求标识构件的三步「标识构件」是这个阶段的技术核心分三步走生成类图教材提到可用 Rational Rose 这类工具对类进行分组依据隔离性、继承性、聚合性等聚类把类打包成构件合并类簇形成可复用构件最后是需求评审要求多角色参与含客户、测试员验证需求真实性及构件划分的合理性。阶段③ 文档化输出两份文档这是常考的数量考点是两份不是一份文档作用体系结构规格说明对构件的形式化描述作为开发契约质量设计说明书用于测试体系结构需求验证非功能需求文档编写的三条原则从使用者视角编写、及时更新分发、保证完整性开发者手上的必须是最新版。阶段④ 复审必须由外部人员参加这是最容易被出题的点复审要安排一次由外部人员参加的评审人员构成是「用户代表 领域专家」。为什么必须外部因为要标识潜在的风险以及尽早发现架构设计中的缺陷和错误——内部人员容易陷入自己的设计假设。复审要检查的内容包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件划分是否合理、文档表达是否明确、构件设计是否满足功能与性能要求等。补一个过程关系架构设计、文档化和复审是一个迭代过程——复审不通过就回到前序阶段修订不是单向流水线。七、ABSD、SAAM/ATAM 与 ADD 的分工学到这里容易和上一篇混淆。三者不是竞争关系而是分工关系方法类型解决的问题ABSD设计方法怎么从需求造出一个架构SAAM / ATAM评估方法造出来之后这个架构行不行ADD属性驱动设计设计方法同样强调质量属性场景但以驱动因子与质量属性战术为核心组织流程一句话区分ABSD 和生产车间SAAM/ATAM 是质检车间。ABSD 与 ADD 的共同点是都采用自顶向下、递归、迭代的方式差别在于 ABSD 更完整地定义了三大基础功能分解、体系结构风格、软件模板而 ADD 把重心放在质量属性场景与高优先级驱动因子上。考试频次上 ABSD 明显更高ADD 了解定位即可不必死磕步骤。八、10 条选择题陷阱清单以下每条都是能直接排除选项或锁定答案的判据。陷阱正确判据1说 ABSD 是「自底向上」自顶向下递归细化出现自底向上直接排除2把「用例分析 / 场景分析」列为三大基础之一三基础只有功能分解、选择体系结构风格、软件模板。用例是需求捕获手段3说「静态视角判断功能特性」静态 → 质量特性动态 → 行为特性。这是最高频反向陷阱4把逻辑视图说成记录「实现接口」记录的是概念接口5质量场景只列预期场景必须含预期 非预期6说非预期场景决定「功能范围」决定的是边界条件7顶层产物说成「概念构件」顶层产概念子系统第 2 层才产概念构件顺序不可颠倒8说模板只在顶层有每层都有顶层「软件模板」第 2 层「附加软件模板」9说文档化只输出一份文档两份体系结构规格说明 质量设计说明书10说复审由项目内部人员完成必须外部人员用户代表 领域专家九、考前速记卡一句话总纲ABSD 三基础拆·选·套递归下切每层带模板两种视角静质动行四个视图需求双捕获用例 质量场景六阶段过程四条记忆钩子拆 · 选 · 套—— 三大基础的动作链静质动行—— 静态看质量、动态看行为变 · 性 · 靠 · 交—— 四类质量场景实现≈开发、配置≈部署—— 四视图对齐 RUP 41记忆宫殿盖一栋楼拆房间功能分解→ 选建筑风格体系结构风格→ 拿标准模具软件模板 从整栋楼切到楼层、再切到房间每切一层都拿一次模具递归 每层模板 看图分两种看法——平面图看质量、动线图看行为静态 / 动态视角 专业图纸共四张逻辑、进程、实现、配置 甲方提需求分两块——要什么功能用例、极限条件下不能塌质量场景 最后走完六步流程需求 → 设计 → 文档 → 复审 → 实现 → 演化。十、下一篇预告ABSD 讲的是「一个系统怎么从需求长出架构」。但企业做产品线时面对的不是一个系统而是一族系统——它们共享同一批领域需求架构也高度相似。下一篇讲DSSA特定领域软件架构它和 ABSD 是什么关系、参与角色有哪几类、三层次模型怎么划分、建立过程分几步走。这一节同样是定义型考点密集区和本篇合起来正好覆盖「体系结构设计方法」这一章的完整考法。系列文章软件架构风格5 大一级 12 种二级一图归位 判型三步法架构评估方法 ATAM 与 SAAM四阶段 9 步 效用树 四类判定ABSD 基于架构的软件设计三大基础 递归细化 六阶段模型本篇DSSA 特定领域软件架构预告