软考体系里系统架构设计师这个科目我一直觉得第七章“系统架构设计基础知识”是被很多人低估的一章。我当年备考的时候第一遍翻教材感觉这一章内容既散又抽象全是概念看完好像什么都记住了合上书又什么都说不出来。后来刷真题才发现这一章是隐性的大分值章节上午选择题经常出下午论文题里的架构风格、架构评估、ADL这些概念也是绕不开的理论基础。这一章如果你只是死记硬背会很痛苦但如果你用“解决什么问题”的视角去理解会发现它就是软件架构领域的地基。这篇文章我尽量用考证人的语言把这些基础知识点串起来讲清楚顺便聊聊我在备考和实际项目里的体会希望能帮你少走些弯路。1. 第七章在软考体系里的定位为什么它这么重要这一节我们先说清楚两件事第七章到底考什么以及为什么值得你花大精力去搞懂它。很多备考的朋友容易犯一个毛病觉得架构设计是很虚的东西不如多刷几道计算题来得实在。但等你真正进了考场或者真的开始做架构设计的时候就会明白这一章的内容贯穿了整个软考高级科目的始终。1.1 考纲定位与分值分布系统架构设计师考试分三科综合知识上午选择题、案例分析下午第一场、论文下午第二场。第七章“系统架构设计基础知识”主要对应的是综合知识科目但在案例分析和论文科目中也会以不同形式出现。从历年的考题分布来看这一章在上午选择题里的分值通常在5到10分之间浮动覆盖的知识点非常广。我统计过近五年的真题出现频率最高的几个考点分别是软件架构风格的概念与分类、典型架构风格的辨析、架构描述语言、41视图模型、基于架构的软件设计方法ABSD、特定领域软件架构DSSA、架构评估方法SAAM和ATAM。其中架构风格相关的内容几乎每年必考有时候上午的选择题会接连出2到3道。论文科目更是如此。系统架构设计师历年论文题目里直接要求“论基于架构的软件设计方法的应用”“论软件架构风格的选择与应用”“论软件架构评估”这类题目的频率相当高。如果你第七章的基础概念都没有真正理解面对论文题的时候会发现自己连“质量属性”“架构视图”“ATAM”这些基本术语都用不准确论文很容易写成假大空的堆砌。1.2 这一章的核心概念框架先搭骨架再填肉我备考时踩过最大的坑就是试图一上来就把所有概念都背得滚瓜烂熟。结果背了“仓库风格”忘了“解释器风格”背了“SAAM”忘了“ATAM”脑子里一团浆糊。后来我想通了一件事第七章整章的内容其实围绕着一个核心主线来展开那就是“架构设计到底是什么以及怎么设计、怎么评估”。这条主线可以拆成四个子问题架构长什么样答案是架构视图41视图模型和架构描述语言ADL。架构有哪些套路答案是架构风格数据流、调用返回、独立构件、虚拟机、仓库。架构如何设计出来答案是ABSD方法基于架构的软件设计。架构怎么保证是对的答案是架构评估SAAM和ATAM。你把这四个子问题作为骨架复习的时候每接触一个新概念就往对应的骨架上挂。这样你的知识是网状的而不是一堆孤立的点做题的时候提取起来也快得多。2. 软件架构风格五大流派逐个拆解架构风格这一块是整个第七章的重中之重也是上午考试出现频率最高的考点。我觉得这部分内容与其说是技术不如说是“方法论”和“设计经验总结”。考试不会要求你写代码但一定会要求你判断某个场景该用哪种风格或者从描述中识别出这是哪种风格。2.1 五大类架构风格的基础分类教材中把架构风格分成了五大类每大类下面还有若干子风格。这里我先给一张总览表把基本框架列出来后面再逐个细说。大类子风格核心思路典型应用数据流风格批处理、管道-过滤器数据像流水一样经过处理单元编译器、数据处理流水线调用/返回风格主程序-子程序、面向对象、层次结构通过调用关系组织系统传统应用系统、分层架构独立构件风格进程通信、事件驱动隐式调用构件之间通过通信或事件解耦GUI系统、消息中间件虚拟机风格解释器、规则系统用软件模拟硬件/规则引擎脚本引擎、业务规则系统仓库风格数据库系统、黑板系统共享数据源各方通过数据协作数据管理系统、专家系统这张表不是让你背的而是给你一个对照的框架。你在复习的时候每看到一个场景描述第一反应应该是“它属于哪一类”然后再去想具体的子风格。这样做题效率会高很多。2.2 数据流风格管道-过滤器与批处理的取舍先讲数据流风格因为这个风格最容易理解。核心思想就是“数据像水流一样经过一个又一个处理单元”。管道-过滤器Pipe-Filter风格里每个处理步骤是一个过滤器过滤器之间通过管道连接数据从管道流入过滤器处理完再流向下一个过滤器。这个风格最大的优点是过滤器之间完全解耦每个过滤器可以独立修改、替换、复用而且多个过滤器可以并行处理性能潜力大。典型的例子就是编译器前端词法分析、语法分析、语义分析、代码生成本质上就是一个管道-过滤器链。批处理Batch Sequential风格和管道-过滤器很相似区别在于批处理中每一步是完整的、原子的前一步处理完整个数据集后结果才交给下一步。它更古老、更简单但灵活性和并行度都不如管道-过滤器。考试里经常出的题目是给出一个系统描述问你“最适合采用哪种风格”。这时候你要学会区分如果处理步骤之间是顺序的、数据流式的选数据流风格如果描述里强调“每个步骤可以独立替换、并行执行”倾向管道-过滤器如果强调“批量处理、步骤间要有清晰边界”倾向批处理。这些都是实战中总结出来的判断技巧比死记硬背定义有用得多。2.3 调用/返回风格从主程序-子程序到分层架构调用/返回风格是现实中用得最多的架构风格也是大家最熟悉的。它的核心是“通过调用关系组织系统”。主程序-子程序风格是最原始的形式把系统分解成主程序和若干子程序主程序控制调用顺序子程序完成特定功能。优点是结构化好、模块划分明确缺点是主程序像个中枢一旦业务逻辑变化频繁主程序会变得越来越臃肿维护成本直线上升。面向对象风格在子程序思想基础上强调把数据和对数据的操作封装在一起形成对象。对象之间通过消息通信。它的优势是对现实世界的建模能力强代码复用率高。但它也有一个副作用就是对象之间的调用关系可能非常复杂一旦系统规模变大对象之间的关系网让人难以维护。层次结构风格——也就是我们常说的分层架构——把系统按照抽象级别从上到下划分成若干层每一层只依赖它的下一层不能跨层调用。最常见的就是经典的三层架构表现层、业务逻辑层、数据访问层。我在实际项目里用分层架构最多它的优点非常明显每一层的职责单一清晰可以独立开发、测试、替换。比如换数据库只要数据访问层的实现变了上层不需要动。缺点是严格分层可能导致性能损耗因为每次请求都要穿过多层的调用链。考试里常考“哪一种风格最符合某一层只与其相邻层通信”这个描述你只要抓住分层架构“相邻层通信”这个特征就能快速定位。2.4 独立构件风格进程通信与事件驱动独立构件风格强调系统的组成部分是独立的构件构件之间不直接调用而是通过通信机制或事件机制协作耦合度极低。进程通信风格构件是独立的进程通过进程间通信如消息传递、远程调用来协作。这里你需要知道它常见于分布式系统。举个例子微服务架构本质上就是一种进程通信风格每个服务是独立进程服务之间通过HTTP或消息队列通信。这种风格的优点是故障隔离性好一个服务挂了不会拖垮整个系统缺点是通信开销大分布式调试困难。事件驱动隐式调用风格构件不直接调用另一个构件的接口而是发布事件或订阅事件。当某个事件发生时系统自动通知所有订阅了该事件的构件。GUI程序里的按钮点击事件、消息中间件里的发布/订阅都是这个思想。这种风格的最大优点是构件之间的解耦非常彻底新增一个构件只需要订阅事件不需要改其他构件的代码。最大缺点是系统行为难以预测因为你不知道一个事件触发后到底哪些构件会响应特别是事件链复杂的时候排错非常头疼。我有个实际工作中的案例之前维护过一个老旧的报表系统所有模块直接互相调用后来加需求越来越痛苦。架构师引入了一个消息中间件把核心模块之间的直接调用全部改成事件发布/订阅系统的可扩展性立刻就上来了。考试里如果遇到“系统对可扩展性要求高模块之间不希望有强耦合”这种描述优先考虑事件驱动风格基本不会错。2.5 虚拟机风格解释器与规则系统的应用场景虚拟机风格的核心思想是用软件来模拟一个“虚拟的执行环境”在这个环境里程序可以动态执行。这听起来有点抽象但它的应用非常广泛。解释器风格系统包含一个解释器它读取程序代码通常是脚本或字节码逐条解释并执行。Java的JVM、Python解释器、正则表达式引擎都是解释器风格的典范。这种风格的优点是可以实现跨平台程序在解释器之上运行与底层硬件无关运行时可以动态修改行为。缺点是执行效率低比原生编译慢很多。规则系统风格把业务逻辑写成规则系统运行时根据输入数据和规则库进行匹配执行匹配到的规则。典型应用是业务规则引擎比如银行的风控系统、电商的优惠券系统。这种风格的场景特征非常明确业务规则频繁变化、专家系统、决策支持系统。考试题如果描述“业务规则经常变不想频繁重编译系统”答案就锁定规则系统风格。回顾我在实际系统里遇到的场景绝大多数业务系统并不需要虚拟机风格因为它太“重”。但当你遇到“需要动态执行脚本”“需要灵活配置规则”这些具体需求时虚拟机风格就是绕不开的最佳解。2.6 仓库风格从数据库系统到黑板系统仓库风格的独特之处在于所有构件共享一个中心数据源构件之间不直接交流而是通过读写中心数据源来协作。这就像一家人共用同一个冰箱每个成员都从冰箱里取食材、往里放食材但成员之间不需要直接打招呼。数据库系统风格是仓库风格最典型的代表多个应用程序共享一个数据库通过SQL操作数据。这种风格在业务系统里无处不在好处是数据集中管理、一致性容易保证坏处是数据库成了系统的瓶颈而且一旦业务逻辑分散在各个应用里数据和流程的耦合关系会越来越混乱。黑板系统风格则更高级一些多个独立的“知识源”构件在一个共享的黑板上读写信息通过黑板协调工作。典型的应用是语音识别系统、图像识别系统因为这类问题没有一个单一的算法能够解决需要多个算法协作、逐步推理。考试里如果出现“多个专家系统协作、逐步逼近问题解”这种描述你就可以选择黑板系统。我在备考阶段总结过一个选型技巧仓库风格的核心特征是“数据为中心”如果题目里反复强调“共享数据”“多个应用访问同一数据源”那多半是仓库风格。不过要留意的是架构风格的选择往往不是非黑即白真实系统通常是多种风格的混合体考试里说的“最适合”是相对而言的。3. 架构视图从不同视角看同一栋建筑“架构视图”这个知识点本质上解决的是架构设计中的沟通问题。试想一下一个系统有几十个模块、上百个类、复杂的部署环境怎么可能用一张图说清楚所以我们需要从多个视角来描述架构每个视角只关注一个侧面。3.1 41视图模型逻辑、开发、运行、物理与场景视图41视图模型是Philippe Kruchten提出来的也是软考教材的必考内容。这里的“4”指的是四种基本视图“1”指的是场景。每个视图都从一个不同的视角刻画系统逻辑视图Logical View从系统功能角度描述主要面向最终用户和系统分析人员刻画系统的对象模型、功能模型。画出来通常是类图、对象图。它回答的问题是“系统提供哪些功能”。开发视图Development View从软件开发者的角度描述关注代码的组织结构比如模块划分、包结构、分层。它回答的问题是“系统如何组织和开发”。运行视图Process View从系统运行时的角度描述关注进程、线程、并发、同步、通信等问题。它回答的问题是“系统如何运行”。物理视图Physical View从系统部署的角度描述关注软件如何部署到硬件节点上以及网络传输。它回答的问题是“系统部署在哪”。场景视图Scenarios也就是“1”的部分它把四个视图串联起来通过几个关键的业务场景验证这些视图是否一致、是否满足需求。我自己的理解是41视图模型就像是建筑行业里的平面图、立面图、结构图、水电图虽然画的是同一栋楼但每张图服务的对象不同。架构设计不是只画一张“完美的架构图”而是要把这些视图都考虑周全。软考里这个知识点经常考的是“某个视图对应哪些参与者”“某个视图使用什么建模工具”最好的记忆方式就是抓住每个视图回答的核心问题。3.2 架构描述语言ADL用形式化语言表达架构架构描述语言ADLArchitecture Description Language是一种专门用来描述软件架构的形式化语言。普通程序员可能平时接触不到但在软考里是一定要了解的考点。ADL的核心要素有三个构件Component、连接件Connector和架构配置Architectural Configuration。构件是系统中的计算单元连接件是构件之间的交互关系和通信机制架构配置则是把构件和连接件按照一定规则组合起来的整体结构。你可以把ADL理解成“用编程语言写架构”只不过它描述的对象不是程序逻辑而是架构的静态结构和动态行为。常见的ADL包括Wright、Acme、AADL架构分析和设计语言等。软考里不需要你掌握某个具体ADL的语法但你需要理解ADL能够做什么它可以对架构进行形式化建模、验证架构实现与设计的符合性、支持架构的自动分析和生成。我记得有一道经典真题描述的是一个系统需要“对架构进行严格验证防止不匹配的连接”选项里给出了几个方法正确答案就是“用ADL描述架构”。因为ADL的特点就是精确性和可验证性。遇到这类型的题目你只要抓住“精确描述、支持验证”这个关键词判断起来就很容易了。4. 从需求到架构ABSD设计方法与DSSA知道了架构有哪些风格和视图接下来就是核心问题架构到底是怎么设计出来的这一节讲两个内容一个是基于架构的软件设计方法ABSD一个是特定领域软件架构DSSA。这两个考点在选择题和论文里都属于重点。4.1 ABSD需求驱动、迭代式的架构设计方法ABSDArchitecture-Based Software Design是一种以架构为核心、贯穿整个软件生命周期的设计方法。它的最大特点可以用四个字概括“需求驱动”。也就是说架构不是凭空想象出来的而是从功能需求和约束条件推导出来的。ABSD的过程可以拆成六个步骤需求分析收集功能需求、质量属性需求和约束条件。这里的质量属性包括性能、可用性、安全性、可修改性等它们对架构设计的影响往往比功能需求更大。确定设计策略根据需求确定采用的架构风格、开发策略等。比如一个高并发系统会考虑事件驱动或微服务风格一个对性能要求苛刻的实时系统可能选数据流风格。进行架构设计将系统分解为模块、构件确定它们之间的关系。这一步会产出架构文档和架构视图41视图模型在这里开始发挥作用。架构建模用文字、图形或ADL来描述架构使架构可以被记录、沟通和分析。架构文档化把架构设计结果写入SAD软件架构文档这是很多人忽视但极其重要的一步。不写文档的架构设计到项目后期就是一团乱麻。架构复审组织评审团队对架构进行评估判断其是否满足质量属性要求。这一步就是架构评估第5节会详细讲。这里要特别强调ABSD强调了架构设计和需求之间的紧密关系。实际项目里最常见的失败原因就是一开始需求没搞清楚草草地定了一个架构结果后期需求一变架构推倒重来。软考论文里经常考“论基于架构的软件设计方法的应用”你写论文的时候一定要把“需求如何指导架构”“架构如何迭代”这条主线讲透。4.2 DSSA把特定领域的经验沉淀为架构DSSADomain-Specific Software Architecture中文翻译为特定领域软件架构。它解决的是另一个问题同一个领域中相似的系统其实有大量共性能不能把共性抽象出来形成一套可复用的架构模板DSSA的核心思想是“站在巨人的肩膀上”。比如电商系统有商品、订单、用户、支付这些核心模块订单生命周期在不同电商系统里大同小异。如果你做过一个电商系统再做第二个、第三个的时候完全可以基于一套DSSA来搭建而不是从零开始。DSSA有三个组成部分领域模型描述领域中稳定的概念和关系、参考需求归纳领域中所有系统的共同需求、参考架构定义功能如何映射到构件和执行环境。此外还需要定义标准数据格式、协议规范来保证不同实现之间的兼容性。考试里经常出一个判断什么活动属于DSSA的“领域分析”阶段领域分析就是研究一个领域内的多个已有系统识别它们共性和变化性的过程。比如考察多个银行的网银系统发现它们都有“账户管理”“转账汇款”“交易记录”这些共有的功能模块这就是领域分析。记住“共性/可变性分析”这类词汇一出现多半就是DSSA相关题目。5. 架构评估如何判断架构好不好架构设计做得再好也需要有方法去判断它是否满足需求。这就是架构评估的内容。软考在这一部分主要考查两个方法SAAM和ATAM。在我个人看来这两个方法不仅是考点更是实际架构工作中非常实用的沟通工具。5.1 为什么架构评估如此重要宁可前置评审也不后端返工架构评估的核心价值在于“提前发现风险”。架构是系统的骨架如果骨架搭歪了后面做再多的精细化设计也无力回天。与其等到系统上线后发现性能瓶颈、扩展性差不如在架构设计阶段就组织评估用较低的成本发现潜在问题。我在实际项目中见过太多反面案例架构没有经过评估就进入开发等系统上线后用户量一上来数据库连接池爆了、服务之间调用超时、缓存设计不合理各种问题集中爆发最后只能花几倍的时间做架构重构。如果在架构阶段引入一次正式的架构评估很多问题是可以提前暴露的。5.2 SAAM从场景出发的架构分析方法SAAMSoftware Architecture Analysis Method即软件架构分析方法是最早的开放式架构评估方法之一。它的核心载体是“场景”。SAAM的操作思路大体如下开发场景团队根据系统的关注点性能、可修改性、安全性编写一组典型的使用场景和变更场景。描述架构用架构视图把当前的设计表达出来。分类场景把场景分成直接场景即当前架构已经支持的功能和间接场景需要修改架构才能支持的功能。评估场景的交互分析每个场景对架构各个部分的影响识别出架构中承担过多职责的构件。形成结论综合评估架构对各类场景的支持程度给出结论。SAAM最看重质量属性是“可修改性”和“可扩展性”。因为场景中很大一部分是描述的可能的变更比如“如果未来要新增一种支付方式系统需要做哪些改动”。如果在评估中发现一个很小的变更会导致大量构件需要修改说明架构的模块化程度差需要调整。5.3 ATAM将质量属性权衡分析融入架构评估ATAMArchitecture Tradeoff Analysis Method即架构权衡分析法是目前使用最广泛的架构评估方法。它比SAAM更进了一步不仅评估架构能否满足质量属性还重点关注多个质量属性之间的“权衡”。为什么需要权衡因为在真实系统中很多质量属性是互相矛盾的。比如追求高性能往往就要损失一定的可修改性追求高可用性往往要牺牲一部分成本或性能。ATAM的核心贡献就是让这种权衡显性化、可讨论。ATAM评估过程可以概括为几个阶段收集场景从涉众客户、用户、开发者、运维人员等那里收集一系列场景表达他们对系统质量属性的期望。建立效用树把系统的质量属性目标按“效用-质量属性-属性细化-场景”的层级组织成一棵效用树每个叶子节点就是一个具体场景并标注优先级和风险等级。分析架构途径针对效用树中的高优先级场景分析架构通过什么机制架构途径来满足它判断是否存在风险点。识别权衡点当发现同一个架构决策对多个质量属性“有得有失”时就找到了一个权衡点。权衡点出现的地方就是需要架构决策的地方。考试里喜欢考察ATAM中的“效用树”概念。你需要知道效用树的根是“效用”往下是第一层质量属性性能、可用性、安全性、可修改性等再往下是属性细化比如性能分为延迟、吞吐量最底层是具体场景。我建议你亲手画一棵效用树画一遍自然就记住了层级关系。另外ATAM还有一个高频考点区分“风险点”“非风险点”和“权衡点”。风险点是指架构方案存在潜在问题的决策比如“数据库没有做读写分离并发高时可能成为瓶颈”权衡点是指影响多个质量属性的决策比如“为了性能引入缓存但会降低数据的一致性”。这几个词在真题里反复出现一定要掌握准确。5.4 架构评估在考试中的典型考法与应对这一部分单独拿出来说说考试怎么应对。上午选择题里SAAM和ATAM的考点集中在“方法的核心特点”“评估步骤”“相关术语定义”。比如“以下哪个方法侧重对场景进行直接场景和间接场景的分类”答案就是SAAM再比如“效用树是哪个评估方法的核心工具”答案就是ATAM。下午论文题里架构评估可以作为论文的一个章节来写。如果你抽到“论架构评估”这道题建议结构是第一段写项目背景和你的角色第二段写架构评估方法选型与步骤第三段写评估中发现的典型问题第四段写评估对项目的影响和收获。关键是要把场景、效用树、风险点、权衡点这些工具真的用起来写出你“如何操作”和“发现了什么”而不是空谈概念。论文最忌讳的就是把名词倒背如流却没有一个真实的评估案例支撑。我有一次参与一个较大规模的重构项目架构评估时用了ATAM开了三轮评审会。第一轮收集了二十多个场景第二轮画效用树才发现干系人之间对“性能优先还是可修改性优先”根本没有达成一致这才是真正的问题。后来架构决策在权衡点上有意识地做了取舍才避免后面反复推倒重来。这种实战经验写进论文里比背定义有价值得多。6. 备考策略、常见误区与高频易错点前面把第七章的知识点过了一遍最后这部分我以自己的备考经历给大家总结一下复习策略、常见误区和那些容易踩坑的易错点。6.1 备考优先级抓大放小先主干后细枝第七章的内容虽然多但复习的性价比差异很大。我建议你按优先级来安排复习时间第一优先级必考且高频架构风格的定义、分类与辨析41视图模型ATAM。这三块几乎年年考一定要吃透。第二优先级中频ABSD设计流程、DSSA的组成、SAAM与ATAM的比较。这些考的频率也不低尤其是ABSD的步骤历年论文经常拿它来出题。第三优先级低频具体ADL的语法、某个具体架构风格的历史发展。这类内容能理解更好实在记不住也不必强求因为分值占比太低。我见过很多考生花大量时间去背各种ADL语言的细节结果最基础的架构风格分类都没有搞明白考试时在简单题上丢分非常可惜。备考一定要学会抓大放小。6.2 常见误区不要死记硬背要理解原理第七章最大的误区就是“背定义”。这一章不是纯文科内容即使有些概念看起来像是定义也需要你理解背后的“为什么”。举一个例子层次结构风格要求“每一层只与其相邻层通信”。如果你只是背这句话考试时遇到“某层需要跨层调用数据访问层是否违背分层架构原则”这种变体题你可能就懵了。但如果你理解了分层架构的初衷是“降低层间依赖、便于独立修改”你就知道跨层调用虽然有时是不得已而为之但它确实破坏了分层的优势是需要慎重决策的。我备考时的做法是每学完一种风格就尝试回答三个问题这种风格解决什么问题它的优缺点是什么如果需求变化会出现什么问题用这三个问题去检验自己比单纯刷题有效得多。6.3 高频易错点速查表与实战建议最后我整理了一张第七章高频易错点速查表方便大家在冲刺阶段反复对照。易错点常见错误正确理解管道-过滤器与批处理两者混为一谈管道-过滤器支持并行和增量处理批处理是数据集整体逐步流转仓库风格与数据流风格都涉及数据容易混淆仓库风格的中心是共享数据源构件通过数据协作数据流风格的中心是数据流动处理事件驱动与进程通信都涉及通信事件驱动强调隐式调用和订阅机制进程通信强调的是进程间显式通信41视图的“4”和“1”记不住哪四个视图逻辑、开发、运行、物理加场景视图串联ATAM效用树结构把根节点记错根节点是“效用”第二层是质量属性风险点与权衡点概念混淆风险点是可能带来问题权衡点是同时影响多个质量属性、需做出取舍DSSA与ADL记混两者的核心内容DSSA是特定领域的可复用架构模板ADL是描述架构的语言SAAM与ATAM的侧重点区分不清SAAM侧重场景分析ATAM侧重质量属性权衡第七章的知识体系核心就是“风格、视图、方法、评估”四个关键词。我在备考复习时每天晚上睡前会在脑子里过一遍这四个关键词然后尝试用自己的话向“空气”解释一遍。坚持一段时间后我发现这些概念真的从“书上的知识点”变成了“自己的理解”。软考的含金量在于它逼着你建立起系统性的架构思维这一步做好了不管考试还是实际工作都会受益很多。这篇内容是我备考过程中的一些复盘希望对正在备考的朋友有所启发。如果你在复习第七章时有什么拿不准的地方可以回到教材里再看对应的章节带着“它想解决什么问题”这个问题去读效果会完全不一样。祝大家都能顺利通过软考。
系统架构设计师备考：第七章架构设计核心知识点精讲
软考体系里系统架构设计师这个科目我一直觉得第七章“系统架构设计基础知识”是被很多人低估的一章。我当年备考的时候第一遍翻教材感觉这一章内容既散又抽象全是概念看完好像什么都记住了合上书又什么都说不出来。后来刷真题才发现这一章是隐性的大分值章节上午选择题经常出下午论文题里的架构风格、架构评估、ADL这些概念也是绕不开的理论基础。这一章如果你只是死记硬背会很痛苦但如果你用“解决什么问题”的视角去理解会发现它就是软件架构领域的地基。这篇文章我尽量用考证人的语言把这些基础知识点串起来讲清楚顺便聊聊我在备考和实际项目里的体会希望能帮你少走些弯路。1. 第七章在软考体系里的定位为什么它这么重要这一节我们先说清楚两件事第七章到底考什么以及为什么值得你花大精力去搞懂它。很多备考的朋友容易犯一个毛病觉得架构设计是很虚的东西不如多刷几道计算题来得实在。但等你真正进了考场或者真的开始做架构设计的时候就会明白这一章的内容贯穿了整个软考高级科目的始终。1.1 考纲定位与分值分布系统架构设计师考试分三科综合知识上午选择题、案例分析下午第一场、论文下午第二场。第七章“系统架构设计基础知识”主要对应的是综合知识科目但在案例分析和论文科目中也会以不同形式出现。从历年的考题分布来看这一章在上午选择题里的分值通常在5到10分之间浮动覆盖的知识点非常广。我统计过近五年的真题出现频率最高的几个考点分别是软件架构风格的概念与分类、典型架构风格的辨析、架构描述语言、41视图模型、基于架构的软件设计方法ABSD、特定领域软件架构DSSA、架构评估方法SAAM和ATAM。其中架构风格相关的内容几乎每年必考有时候上午的选择题会接连出2到3道。论文科目更是如此。系统架构设计师历年论文题目里直接要求“论基于架构的软件设计方法的应用”“论软件架构风格的选择与应用”“论软件架构评估”这类题目的频率相当高。如果你第七章的基础概念都没有真正理解面对论文题的时候会发现自己连“质量属性”“架构视图”“ATAM”这些基本术语都用不准确论文很容易写成假大空的堆砌。1.2 这一章的核心概念框架先搭骨架再填肉我备考时踩过最大的坑就是试图一上来就把所有概念都背得滚瓜烂熟。结果背了“仓库风格”忘了“解释器风格”背了“SAAM”忘了“ATAM”脑子里一团浆糊。后来我想通了一件事第七章整章的内容其实围绕着一个核心主线来展开那就是“架构设计到底是什么以及怎么设计、怎么评估”。这条主线可以拆成四个子问题架构长什么样答案是架构视图41视图模型和架构描述语言ADL。架构有哪些套路答案是架构风格数据流、调用返回、独立构件、虚拟机、仓库。架构如何设计出来答案是ABSD方法基于架构的软件设计。架构怎么保证是对的答案是架构评估SAAM和ATAM。你把这四个子问题作为骨架复习的时候每接触一个新概念就往对应的骨架上挂。这样你的知识是网状的而不是一堆孤立的点做题的时候提取起来也快得多。2. 软件架构风格五大流派逐个拆解架构风格这一块是整个第七章的重中之重也是上午考试出现频率最高的考点。我觉得这部分内容与其说是技术不如说是“方法论”和“设计经验总结”。考试不会要求你写代码但一定会要求你判断某个场景该用哪种风格或者从描述中识别出这是哪种风格。2.1 五大类架构风格的基础分类教材中把架构风格分成了五大类每大类下面还有若干子风格。这里我先给一张总览表把基本框架列出来后面再逐个细说。大类子风格核心思路典型应用数据流风格批处理、管道-过滤器数据像流水一样经过处理单元编译器、数据处理流水线调用/返回风格主程序-子程序、面向对象、层次结构通过调用关系组织系统传统应用系统、分层架构独立构件风格进程通信、事件驱动隐式调用构件之间通过通信或事件解耦GUI系统、消息中间件虚拟机风格解释器、规则系统用软件模拟硬件/规则引擎脚本引擎、业务规则系统仓库风格数据库系统、黑板系统共享数据源各方通过数据协作数据管理系统、专家系统这张表不是让你背的而是给你一个对照的框架。你在复习的时候每看到一个场景描述第一反应应该是“它属于哪一类”然后再去想具体的子风格。这样做题效率会高很多。2.2 数据流风格管道-过滤器与批处理的取舍先讲数据流风格因为这个风格最容易理解。核心思想就是“数据像水流一样经过一个又一个处理单元”。管道-过滤器Pipe-Filter风格里每个处理步骤是一个过滤器过滤器之间通过管道连接数据从管道流入过滤器处理完再流向下一个过滤器。这个风格最大的优点是过滤器之间完全解耦每个过滤器可以独立修改、替换、复用而且多个过滤器可以并行处理性能潜力大。典型的例子就是编译器前端词法分析、语法分析、语义分析、代码生成本质上就是一个管道-过滤器链。批处理Batch Sequential风格和管道-过滤器很相似区别在于批处理中每一步是完整的、原子的前一步处理完整个数据集后结果才交给下一步。它更古老、更简单但灵活性和并行度都不如管道-过滤器。考试里经常出的题目是给出一个系统描述问你“最适合采用哪种风格”。这时候你要学会区分如果处理步骤之间是顺序的、数据流式的选数据流风格如果描述里强调“每个步骤可以独立替换、并行执行”倾向管道-过滤器如果强调“批量处理、步骤间要有清晰边界”倾向批处理。这些都是实战中总结出来的判断技巧比死记硬背定义有用得多。2.3 调用/返回风格从主程序-子程序到分层架构调用/返回风格是现实中用得最多的架构风格也是大家最熟悉的。它的核心是“通过调用关系组织系统”。主程序-子程序风格是最原始的形式把系统分解成主程序和若干子程序主程序控制调用顺序子程序完成特定功能。优点是结构化好、模块划分明确缺点是主程序像个中枢一旦业务逻辑变化频繁主程序会变得越来越臃肿维护成本直线上升。面向对象风格在子程序思想基础上强调把数据和对数据的操作封装在一起形成对象。对象之间通过消息通信。它的优势是对现实世界的建模能力强代码复用率高。但它也有一个副作用就是对象之间的调用关系可能非常复杂一旦系统规模变大对象之间的关系网让人难以维护。层次结构风格——也就是我们常说的分层架构——把系统按照抽象级别从上到下划分成若干层每一层只依赖它的下一层不能跨层调用。最常见的就是经典的三层架构表现层、业务逻辑层、数据访问层。我在实际项目里用分层架构最多它的优点非常明显每一层的职责单一清晰可以独立开发、测试、替换。比如换数据库只要数据访问层的实现变了上层不需要动。缺点是严格分层可能导致性能损耗因为每次请求都要穿过多层的调用链。考试里常考“哪一种风格最符合某一层只与其相邻层通信”这个描述你只要抓住分层架构“相邻层通信”这个特征就能快速定位。2.4 独立构件风格进程通信与事件驱动独立构件风格强调系统的组成部分是独立的构件构件之间不直接调用而是通过通信机制或事件机制协作耦合度极低。进程通信风格构件是独立的进程通过进程间通信如消息传递、远程调用来协作。这里你需要知道它常见于分布式系统。举个例子微服务架构本质上就是一种进程通信风格每个服务是独立进程服务之间通过HTTP或消息队列通信。这种风格的优点是故障隔离性好一个服务挂了不会拖垮整个系统缺点是通信开销大分布式调试困难。事件驱动隐式调用风格构件不直接调用另一个构件的接口而是发布事件或订阅事件。当某个事件发生时系统自动通知所有订阅了该事件的构件。GUI程序里的按钮点击事件、消息中间件里的发布/订阅都是这个思想。这种风格的最大优点是构件之间的解耦非常彻底新增一个构件只需要订阅事件不需要改其他构件的代码。最大缺点是系统行为难以预测因为你不知道一个事件触发后到底哪些构件会响应特别是事件链复杂的时候排错非常头疼。我有个实际工作中的案例之前维护过一个老旧的报表系统所有模块直接互相调用后来加需求越来越痛苦。架构师引入了一个消息中间件把核心模块之间的直接调用全部改成事件发布/订阅系统的可扩展性立刻就上来了。考试里如果遇到“系统对可扩展性要求高模块之间不希望有强耦合”这种描述优先考虑事件驱动风格基本不会错。2.5 虚拟机风格解释器与规则系统的应用场景虚拟机风格的核心思想是用软件来模拟一个“虚拟的执行环境”在这个环境里程序可以动态执行。这听起来有点抽象但它的应用非常广泛。解释器风格系统包含一个解释器它读取程序代码通常是脚本或字节码逐条解释并执行。Java的JVM、Python解释器、正则表达式引擎都是解释器风格的典范。这种风格的优点是可以实现跨平台程序在解释器之上运行与底层硬件无关运行时可以动态修改行为。缺点是执行效率低比原生编译慢很多。规则系统风格把业务逻辑写成规则系统运行时根据输入数据和规则库进行匹配执行匹配到的规则。典型应用是业务规则引擎比如银行的风控系统、电商的优惠券系统。这种风格的场景特征非常明确业务规则频繁变化、专家系统、决策支持系统。考试题如果描述“业务规则经常变不想频繁重编译系统”答案就锁定规则系统风格。回顾我在实际系统里遇到的场景绝大多数业务系统并不需要虚拟机风格因为它太“重”。但当你遇到“需要动态执行脚本”“需要灵活配置规则”这些具体需求时虚拟机风格就是绕不开的最佳解。2.6 仓库风格从数据库系统到黑板系统仓库风格的独特之处在于所有构件共享一个中心数据源构件之间不直接交流而是通过读写中心数据源来协作。这就像一家人共用同一个冰箱每个成员都从冰箱里取食材、往里放食材但成员之间不需要直接打招呼。数据库系统风格是仓库风格最典型的代表多个应用程序共享一个数据库通过SQL操作数据。这种风格在业务系统里无处不在好处是数据集中管理、一致性容易保证坏处是数据库成了系统的瓶颈而且一旦业务逻辑分散在各个应用里数据和流程的耦合关系会越来越混乱。黑板系统风格则更高级一些多个独立的“知识源”构件在一个共享的黑板上读写信息通过黑板协调工作。典型的应用是语音识别系统、图像识别系统因为这类问题没有一个单一的算法能够解决需要多个算法协作、逐步推理。考试里如果出现“多个专家系统协作、逐步逼近问题解”这种描述你就可以选择黑板系统。我在备考阶段总结过一个选型技巧仓库风格的核心特征是“数据为中心”如果题目里反复强调“共享数据”“多个应用访问同一数据源”那多半是仓库风格。不过要留意的是架构风格的选择往往不是非黑即白真实系统通常是多种风格的混合体考试里说的“最适合”是相对而言的。3. 架构视图从不同视角看同一栋建筑“架构视图”这个知识点本质上解决的是架构设计中的沟通问题。试想一下一个系统有几十个模块、上百个类、复杂的部署环境怎么可能用一张图说清楚所以我们需要从多个视角来描述架构每个视角只关注一个侧面。3.1 41视图模型逻辑、开发、运行、物理与场景视图41视图模型是Philippe Kruchten提出来的也是软考教材的必考内容。这里的“4”指的是四种基本视图“1”指的是场景。每个视图都从一个不同的视角刻画系统逻辑视图Logical View从系统功能角度描述主要面向最终用户和系统分析人员刻画系统的对象模型、功能模型。画出来通常是类图、对象图。它回答的问题是“系统提供哪些功能”。开发视图Development View从软件开发者的角度描述关注代码的组织结构比如模块划分、包结构、分层。它回答的问题是“系统如何组织和开发”。运行视图Process View从系统运行时的角度描述关注进程、线程、并发、同步、通信等问题。它回答的问题是“系统如何运行”。物理视图Physical View从系统部署的角度描述关注软件如何部署到硬件节点上以及网络传输。它回答的问题是“系统部署在哪”。场景视图Scenarios也就是“1”的部分它把四个视图串联起来通过几个关键的业务场景验证这些视图是否一致、是否满足需求。我自己的理解是41视图模型就像是建筑行业里的平面图、立面图、结构图、水电图虽然画的是同一栋楼但每张图服务的对象不同。架构设计不是只画一张“完美的架构图”而是要把这些视图都考虑周全。软考里这个知识点经常考的是“某个视图对应哪些参与者”“某个视图使用什么建模工具”最好的记忆方式就是抓住每个视图回答的核心问题。3.2 架构描述语言ADL用形式化语言表达架构架构描述语言ADLArchitecture Description Language是一种专门用来描述软件架构的形式化语言。普通程序员可能平时接触不到但在软考里是一定要了解的考点。ADL的核心要素有三个构件Component、连接件Connector和架构配置Architectural Configuration。构件是系统中的计算单元连接件是构件之间的交互关系和通信机制架构配置则是把构件和连接件按照一定规则组合起来的整体结构。你可以把ADL理解成“用编程语言写架构”只不过它描述的对象不是程序逻辑而是架构的静态结构和动态行为。常见的ADL包括Wright、Acme、AADL架构分析和设计语言等。软考里不需要你掌握某个具体ADL的语法但你需要理解ADL能够做什么它可以对架构进行形式化建模、验证架构实现与设计的符合性、支持架构的自动分析和生成。我记得有一道经典真题描述的是一个系统需要“对架构进行严格验证防止不匹配的连接”选项里给出了几个方法正确答案就是“用ADL描述架构”。因为ADL的特点就是精确性和可验证性。遇到这类型的题目你只要抓住“精确描述、支持验证”这个关键词判断起来就很容易了。4. 从需求到架构ABSD设计方法与DSSA知道了架构有哪些风格和视图接下来就是核心问题架构到底是怎么设计出来的这一节讲两个内容一个是基于架构的软件设计方法ABSD一个是特定领域软件架构DSSA。这两个考点在选择题和论文里都属于重点。4.1 ABSD需求驱动、迭代式的架构设计方法ABSDArchitecture-Based Software Design是一种以架构为核心、贯穿整个软件生命周期的设计方法。它的最大特点可以用四个字概括“需求驱动”。也就是说架构不是凭空想象出来的而是从功能需求和约束条件推导出来的。ABSD的过程可以拆成六个步骤需求分析收集功能需求、质量属性需求和约束条件。这里的质量属性包括性能、可用性、安全性、可修改性等它们对架构设计的影响往往比功能需求更大。确定设计策略根据需求确定采用的架构风格、开发策略等。比如一个高并发系统会考虑事件驱动或微服务风格一个对性能要求苛刻的实时系统可能选数据流风格。进行架构设计将系统分解为模块、构件确定它们之间的关系。这一步会产出架构文档和架构视图41视图模型在这里开始发挥作用。架构建模用文字、图形或ADL来描述架构使架构可以被记录、沟通和分析。架构文档化把架构设计结果写入SAD软件架构文档这是很多人忽视但极其重要的一步。不写文档的架构设计到项目后期就是一团乱麻。架构复审组织评审团队对架构进行评估判断其是否满足质量属性要求。这一步就是架构评估第5节会详细讲。这里要特别强调ABSD强调了架构设计和需求之间的紧密关系。实际项目里最常见的失败原因就是一开始需求没搞清楚草草地定了一个架构结果后期需求一变架构推倒重来。软考论文里经常考“论基于架构的软件设计方法的应用”你写论文的时候一定要把“需求如何指导架构”“架构如何迭代”这条主线讲透。4.2 DSSA把特定领域的经验沉淀为架构DSSADomain-Specific Software Architecture中文翻译为特定领域软件架构。它解决的是另一个问题同一个领域中相似的系统其实有大量共性能不能把共性抽象出来形成一套可复用的架构模板DSSA的核心思想是“站在巨人的肩膀上”。比如电商系统有商品、订单、用户、支付这些核心模块订单生命周期在不同电商系统里大同小异。如果你做过一个电商系统再做第二个、第三个的时候完全可以基于一套DSSA来搭建而不是从零开始。DSSA有三个组成部分领域模型描述领域中稳定的概念和关系、参考需求归纳领域中所有系统的共同需求、参考架构定义功能如何映射到构件和执行环境。此外还需要定义标准数据格式、协议规范来保证不同实现之间的兼容性。考试里经常出一个判断什么活动属于DSSA的“领域分析”阶段领域分析就是研究一个领域内的多个已有系统识别它们共性和变化性的过程。比如考察多个银行的网银系统发现它们都有“账户管理”“转账汇款”“交易记录”这些共有的功能模块这就是领域分析。记住“共性/可变性分析”这类词汇一出现多半就是DSSA相关题目。5. 架构评估如何判断架构好不好架构设计做得再好也需要有方法去判断它是否满足需求。这就是架构评估的内容。软考在这一部分主要考查两个方法SAAM和ATAM。在我个人看来这两个方法不仅是考点更是实际架构工作中非常实用的沟通工具。5.1 为什么架构评估如此重要宁可前置评审也不后端返工架构评估的核心价值在于“提前发现风险”。架构是系统的骨架如果骨架搭歪了后面做再多的精细化设计也无力回天。与其等到系统上线后发现性能瓶颈、扩展性差不如在架构设计阶段就组织评估用较低的成本发现潜在问题。我在实际项目中见过太多反面案例架构没有经过评估就进入开发等系统上线后用户量一上来数据库连接池爆了、服务之间调用超时、缓存设计不合理各种问题集中爆发最后只能花几倍的时间做架构重构。如果在架构阶段引入一次正式的架构评估很多问题是可以提前暴露的。5.2 SAAM从场景出发的架构分析方法SAAMSoftware Architecture Analysis Method即软件架构分析方法是最早的开放式架构评估方法之一。它的核心载体是“场景”。SAAM的操作思路大体如下开发场景团队根据系统的关注点性能、可修改性、安全性编写一组典型的使用场景和变更场景。描述架构用架构视图把当前的设计表达出来。分类场景把场景分成直接场景即当前架构已经支持的功能和间接场景需要修改架构才能支持的功能。评估场景的交互分析每个场景对架构各个部分的影响识别出架构中承担过多职责的构件。形成结论综合评估架构对各类场景的支持程度给出结论。SAAM最看重质量属性是“可修改性”和“可扩展性”。因为场景中很大一部分是描述的可能的变更比如“如果未来要新增一种支付方式系统需要做哪些改动”。如果在评估中发现一个很小的变更会导致大量构件需要修改说明架构的模块化程度差需要调整。5.3 ATAM将质量属性权衡分析融入架构评估ATAMArchitecture Tradeoff Analysis Method即架构权衡分析法是目前使用最广泛的架构评估方法。它比SAAM更进了一步不仅评估架构能否满足质量属性还重点关注多个质量属性之间的“权衡”。为什么需要权衡因为在真实系统中很多质量属性是互相矛盾的。比如追求高性能往往就要损失一定的可修改性追求高可用性往往要牺牲一部分成本或性能。ATAM的核心贡献就是让这种权衡显性化、可讨论。ATAM评估过程可以概括为几个阶段收集场景从涉众客户、用户、开发者、运维人员等那里收集一系列场景表达他们对系统质量属性的期望。建立效用树把系统的质量属性目标按“效用-质量属性-属性细化-场景”的层级组织成一棵效用树每个叶子节点就是一个具体场景并标注优先级和风险等级。分析架构途径针对效用树中的高优先级场景分析架构通过什么机制架构途径来满足它判断是否存在风险点。识别权衡点当发现同一个架构决策对多个质量属性“有得有失”时就找到了一个权衡点。权衡点出现的地方就是需要架构决策的地方。考试里喜欢考察ATAM中的“效用树”概念。你需要知道效用树的根是“效用”往下是第一层质量属性性能、可用性、安全性、可修改性等再往下是属性细化比如性能分为延迟、吞吐量最底层是具体场景。我建议你亲手画一棵效用树画一遍自然就记住了层级关系。另外ATAM还有一个高频考点区分“风险点”“非风险点”和“权衡点”。风险点是指架构方案存在潜在问题的决策比如“数据库没有做读写分离并发高时可能成为瓶颈”权衡点是指影响多个质量属性的决策比如“为了性能引入缓存但会降低数据的一致性”。这几个词在真题里反复出现一定要掌握准确。5.4 架构评估在考试中的典型考法与应对这一部分单独拿出来说说考试怎么应对。上午选择题里SAAM和ATAM的考点集中在“方法的核心特点”“评估步骤”“相关术语定义”。比如“以下哪个方法侧重对场景进行直接场景和间接场景的分类”答案就是SAAM再比如“效用树是哪个评估方法的核心工具”答案就是ATAM。下午论文题里架构评估可以作为论文的一个章节来写。如果你抽到“论架构评估”这道题建议结构是第一段写项目背景和你的角色第二段写架构评估方法选型与步骤第三段写评估中发现的典型问题第四段写评估对项目的影响和收获。关键是要把场景、效用树、风险点、权衡点这些工具真的用起来写出你“如何操作”和“发现了什么”而不是空谈概念。论文最忌讳的就是把名词倒背如流却没有一个真实的评估案例支撑。我有一次参与一个较大规模的重构项目架构评估时用了ATAM开了三轮评审会。第一轮收集了二十多个场景第二轮画效用树才发现干系人之间对“性能优先还是可修改性优先”根本没有达成一致这才是真正的问题。后来架构决策在权衡点上有意识地做了取舍才避免后面反复推倒重来。这种实战经验写进论文里比背定义有价值得多。6. 备考策略、常见误区与高频易错点前面把第七章的知识点过了一遍最后这部分我以自己的备考经历给大家总结一下复习策略、常见误区和那些容易踩坑的易错点。6.1 备考优先级抓大放小先主干后细枝第七章的内容虽然多但复习的性价比差异很大。我建议你按优先级来安排复习时间第一优先级必考且高频架构风格的定义、分类与辨析41视图模型ATAM。这三块几乎年年考一定要吃透。第二优先级中频ABSD设计流程、DSSA的组成、SAAM与ATAM的比较。这些考的频率也不低尤其是ABSD的步骤历年论文经常拿它来出题。第三优先级低频具体ADL的语法、某个具体架构风格的历史发展。这类内容能理解更好实在记不住也不必强求因为分值占比太低。我见过很多考生花大量时间去背各种ADL语言的细节结果最基础的架构风格分类都没有搞明白考试时在简单题上丢分非常可惜。备考一定要学会抓大放小。6.2 常见误区不要死记硬背要理解原理第七章最大的误区就是“背定义”。这一章不是纯文科内容即使有些概念看起来像是定义也需要你理解背后的“为什么”。举一个例子层次结构风格要求“每一层只与其相邻层通信”。如果你只是背这句话考试时遇到“某层需要跨层调用数据访问层是否违背分层架构原则”这种变体题你可能就懵了。但如果你理解了分层架构的初衷是“降低层间依赖、便于独立修改”你就知道跨层调用虽然有时是不得已而为之但它确实破坏了分层的优势是需要慎重决策的。我备考时的做法是每学完一种风格就尝试回答三个问题这种风格解决什么问题它的优缺点是什么如果需求变化会出现什么问题用这三个问题去检验自己比单纯刷题有效得多。6.3 高频易错点速查表与实战建议最后我整理了一张第七章高频易错点速查表方便大家在冲刺阶段反复对照。易错点常见错误正确理解管道-过滤器与批处理两者混为一谈管道-过滤器支持并行和增量处理批处理是数据集整体逐步流转仓库风格与数据流风格都涉及数据容易混淆仓库风格的中心是共享数据源构件通过数据协作数据流风格的中心是数据流动处理事件驱动与进程通信都涉及通信事件驱动强调隐式调用和订阅机制进程通信强调的是进程间显式通信41视图的“4”和“1”记不住哪四个视图逻辑、开发、运行、物理加场景视图串联ATAM效用树结构把根节点记错根节点是“效用”第二层是质量属性风险点与权衡点概念混淆风险点是可能带来问题权衡点是同时影响多个质量属性、需做出取舍DSSA与ADL记混两者的核心内容DSSA是特定领域的可复用架构模板ADL是描述架构的语言SAAM与ATAM的侧重点区分不清SAAM侧重场景分析ATAM侧重质量属性权衡第七章的知识体系核心就是“风格、视图、方法、评估”四个关键词。我在备考复习时每天晚上睡前会在脑子里过一遍这四个关键词然后尝试用自己的话向“空气”解释一遍。坚持一段时间后我发现这些概念真的从“书上的知识点”变成了“自己的理解”。软考的含金量在于它逼着你建立起系统性的架构思维这一步做好了不管考试还是实际工作都会受益很多。这篇内容是我备考过程中的一些复盘希望对正在备考的朋友有所启发。如果你在复习第七章时有什么拿不准的地方可以回到教材里再看对应的章节带着“它想解决什么问题”这个问题去读效果会完全不一样。祝大家都能顺利通过软考。