ARTICLE · 1213595
考前八页纸[软件架构设计]
软件架构设计，把风格表背下来就完事？
软件架构设计
软件复用 · 构件与中间件 · 架构概念 · 4+1 视图 · 架构风格 · ABSD · DSSA · 产品线
系统架构设计师 · 考前冲刺
📦 8 Parts + Conclusion
👉 滑动
PART 01
软件复用
复用四步
PART 02
构件与中间件
八大优点
PART 03
架构概念
发展历程 · ADL
PART 04
4+1 视图
五个视角
PART 05
架构风格
五大类 · 13 空
PART 06
ABSD
6 个子过程
PART 07
DSSA
垂直域 · 水平域
PART 08
软件产品线
双生命周期
PART ///
写在最后
易错速查
从「复用」讲起，到「产品线」收尾
「软件架构设计」是八页纸里分支最多的一页——脑图从「软件复用」开始，一路铺到构件、中间件、架构概念、4+1 视图、架构风格、ABSD、DSSA，最后落在软件产品线上，整整八个主题。
这一页一共挂了 13 组题、21 个空。真正拉分的是两块：一是架构风格的四选一判断（题干描述一个场景，让你挑风格），二是 ABSD 六个子过程的顺序与产出物。
所以这篇按脑图的八个分支拆成八部分：软件复用 → 构件与中间件 → 架构概念 → 4+1 视图 → 架构风格 → ABSD → DSSA → 产品线。每部分后面紧跟本节的案例，表和图的对应关系照原样还原。
01
PART
软件复用与构件复用
SOFTWARE REUSE
什么是软件复用
★ 软件复用【重用】是多次不同的软件开发过程中重复使用相同或相似【软件元素】的过程。
脑图里给「软件元素」列了六项，注意它们不全是代码：
需求分析文档 · 设计过程 · 设计文档 · 程序代码 · 测试用例 · 领域知识
复用的历史发展线路
脑图把复用的演进画成一条从左到右的线，同时标出它跨越的两个时代：
函数库
类库 → 构件库 → 服务库
线路上另标出「框架【多个类的组合】」，它和库的区别在于：库是「被调用」，框架是「反过来调用你」。
复用的两个维度
水平复用
不分行业领域，通用。
垂直复用
分行业领域，专用。
构件复用的四个步骤
脑图用了四张几乎相同的表来强调同一件事：构件复用的顺序是检索与提取 → 理解与评价 → 修改 → 组装，每一步的具体内容分别在下面四张表里展开。
检索与提取构件
1、基于关键字的检索
特点：树形或有向无回路图结构。
2、刻面检索法
特点：利用 Facet 描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。
例如：分多个刻面——1、应用领域；2、使用环境；3、功能
3、超文本检索法
特点：按照人类的联想思维方式任意跳转到包含相关概念或构件的文档。
理解与评价构件
1、要复用构件，准确地理解构件至关重要。特别是对构件修改使用时。
2、为达到目的，必须要求构件的开发过程遵循公共标准。
3、一般构件库的文档中全面而准确地说明以下内容：
构件的功能与行为、相关的领域知识、可适应性约束条件与例外情形、可以预见的修改部分及修改方法。
修改构件
1、理想状态是直接复用构件库中现成的构件，但大多数情况下，必须对构件进行或多或少的修改，以应对新需求。
2、为了减少构件修改的工作量，要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。这样，复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍不足以使构件适用于新系统，复用者就必须借助设计信息和文档来修改构件。
3、构件库中若无可修改使用的构件，则按新需求开发构件，并存入构件库。
组装构件
组装的三种方式
1、基于功能的组装：采用子程序调用和参数传递的方式将构件组装起来。
2、基于数据的组装：仍然是传统的子程序调用与参数传递。但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如，Jackson 系统开发方法。
3、面向对象的组装：如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则，必须以基类为父类，生成相应的子类，以满足新系统的需求。
+ 构件组装失配问题
1、由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配；
2、由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配；
3、由于系统成分对全局体系结构的假设存在冲突引起的失配等。
要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。
本节案例（2 道）
哪种是典型的水平式重用（答案 B）
软件重用可以分为垂直式重用和水平式重用，（ ）是一种典型的水平式重用。
A 医学词汇表
B 标准函数库
C 电子商务标准
D 网银支付接口
答案B。水平式重用不分行业领域、讲究通用，标准函数库正是「放之四海皆可用」的那一类；医学词汇表、电子商务标准、网银支付接口都绑定在特定行业上，属于垂直式重用。
哪种不属于构件组装技术（答案 C）
构件组装是指将库中的构件经适当修改后相互连接构成新的目标软件。（ ）不属于构件组装技术。
A 基于功能的构件组装技术
B 基于数据的构件组装技术
C 基于实现的构件组装技术
D 面向对象的构件组装技术
答案C。组装方式只有三种——基于功能、基于数据、面向对象，正好对应上一节 STEP 4 里列的三条；「基于实现」是本题凭空造出来的干扰项。
02
PART
构件与中间件技术
COMPONENT & MIDDLEWARE
构件的三个定义
定义 1
软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
定义 2
构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能。
定义 3
构件是一个独立发布的功能部分，可以通过其接口访问它的服务。
对象 · 构件 · 模块的特性对比
脑图把三者并排放在一起，考点集中在「有没有可见状态」这一列上：
模块的特性
结构化开发的产物。
对象的特性
1、一个实例单元，具有唯一的标志；
2、可能具有状态，此状态外部可见；
3、封装了自己的状态和行为。
构件的特性
1、独立部署单元；
2、作为第三方的组装单元；
3、没有（外部的）可见状态。
⚠ 一句话记住这一列
对象「状态外部可见」，构件「没有可见状态」。凡是题干里出现「独立部署」「第三方组装」「无外部可见状态」，答案往构件上选。
构件系统架构特性
构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。
构件框架是一种专用的体系结构（通常围绕一些关键的机制），同时，也是一组固定地作用于构件层次机制的策略。
概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则。
构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。
一个原子构件是一个模块和一组资源。
模块是一组类和可能的非面向对象的结构体，比如过程或者函数。
资源是一个类型化的项的固定集合。
资源这个概念可以包含代码资源，进而包含模块。问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其他的资源。在「纯对象」的方法中，资源是外部化的不可改变的对象——不可改变是因为构件没有持久化的标志，而且复制不能被区分。
图里还给「构件」补了一句解释：指为构件提供支持的环境和工具，负责管理构件的生命周期及其运行时行为。往下三层是原子构件 → 一组资源（配置数据、数据库、文件系统等）／一个模块（一组类或结构体）。
中间件是什么
中间件是一类构件；
中间件是一类系统软件。
它横在「应用程序 1／2／3」和「操作系统／硬件平台」之间，起到简化结构、屏蔽差异、利于复用的作用。
采用中间件技术的优点
面向需求。即设计师集中精力于业务逻辑本身。
业务的分隔和包容性。应用开发人员可以按照不同的业务进行功能的划分，体现为不同的接口或交互模式。
设计与实现隔离。构件对外发生作用或构件间的交互，都是通过接口进行的，构件使用者只需要知道构件的接口，而不必关心其内部实现，这是设计与实现分离的关键。
隔离复杂的系统资源。架构很重要的一个功能就是将系统资源与应用构件隔离，这是保证构件可复用甚至「即插即用」的基础，与中间件的意图也是一致的。
符合标准的交互模型。中间件则实现了架构的模型，实现了标准的协议。
软件复用。中间件提供了构件封装、交互规则、与环境的隔离等机制，这些都为软件复用提供了方便的解决方案。
提供对应用构件的管理。基于中间件的软件可以方便地进行管理，因为构件总可以通过标识机制进行划分。
⚠ 编号说明
原图这一节的编号由 (5) 直接跳到 (7)，没有 (6)。本页照原样保留，考试时按「七大优点」记即可。
中间件分类（8 类）
通信处理（消息）中间件
可靠、高效、实时跨平台通信，eLink，MQSeries
事务处理（交易）中间件
事务分发，负载均衡，Tuxedo
数据存取管理中间件
为虚拟缓冲存取、格式转换、解压等带来方便
Web 服务器中间件
有负载均衡、缓存、安全性等功能
安全中间件
如：加密，认证等
跨平台和架构的中间件
解决跨平台问题，如：CORBA
专用平台中间件
为特定应用领域设计领域参考模式，建立相应架构
网络中间件
功能包括网管、接入、网络测试、虚拟社区和虚拟缓冲等
三大构件标准
CORBA
跨平台和架构的中间件标准
J2EE【EJB】
会话 Bean：实现业务逻辑，负责完成服务端与客户端的交互
实体 Bean：实现 O/R 映射，简化数据库开发工作
消息驱动 Bean：处理并发与异常访问
DNA2000
微软的构件标准
03
PART
软件架构概念
WHAT IS ARCHITECTURE
架构的本质
1、软件架构为软件系统提供了一个结构、行为和属性的高级抽象。
2、软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。
脑图把「结构／行为／属性」三个词各展开了一句例子，考卷上一般只考这三个词本身：
1. 结构
软件结构中，我们可能会有用户界面、订单处理系统和库存管理系统等组件。这些组件如何分布和协作，例如用户界面调用订单系统来处理购买请求。
2. 行为
行为描述了软件在实际操作中的动态过程。例如，当用户点击「购买」按钮时，系统如何验证库存、创建订单、处理支付，并最终确认订单。
3. 属性
属性涵盖软件的性能（如页面加载速度）、可靠性（系统处理订单的稳定性）、和安全性（如用户数据的保护措施）等。
架构的作用
1、软件架构是项目干系人进行交流的手段。
2、软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
3、软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
架构所处位置
架构设计就是需求分配，即将满足需求的职责分配到组件上。
脑图把它摆在「需求分析」与「软件设计」之间：需求分析在前，架构设计居中，软件设计在后。软件架构也就等于软件体系结构。
架构发展历程
无架构阶段 —— 汇编语言
萌芽阶段 —— 程序结构设计
初级阶段 —— 统一建模语言
高级阶段 —— 4+1 视图
ADL 架构描述语言
ADL 是这样一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。
ADL 的三个基本元素
构件：计算或数据存储单元。
连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。
架构配置：描述体系结构的构件与连接件的连接图。
脑图给了一段 ADL 示例（管道-过滤器写法）：
USES p1 PROTOCOL Unix-pipe
USES sorter INTERFACE Sort-filter
CONNECT sorter.output TO p1.source
USES p2 PROTOCOL Unix-pipe
CONNECT sorter.input TO p2.sink
常见的 ADL 语言：Aesop、MetaH、C2、Rapide、SADL、Unicon 等。
04
PART
架构的 4+1 视图
4+1 VIEWS
先分清两个词：视角与视图——从不同的视角来检查，所以会有不同的视图。同一套系统，站在最终用户、程序员、系统工程人员的位置上看，得到的就是不同的四张图，再加一张把它们串起来的「场景」。
架构的「4+1」视图
逻辑视图
最终用户：功能需求
开发视图
编程人员：软件管理
进程视图
系统集成人员：性能、可扩充性、吞吐量等
物理视图
系统工程人员：系统拓扑、安装、通信等
场景
居中，把其余四个视图串起来
UML 的「4+1」视图
同一套思想换成 UML 的说法，名字和元素都换了，考卷上经常两组混着考：
逻辑视图（logical view）
系统分析、设计人员 —— 类与对象
实现视图（implementation view）
程序员 —— 物理代码文件和组件
进程视图（process view）
系统集成人员 —— 线程、进程、并发
部署视图（deployment view）
系统和网络工程师 —— 软件到硬件的映射
用例视图（use-case view）
最终用户 —— 需求分析模型
脑图还给五个视图各配了一句话，按顺序背下来就很稳：
1. 逻辑视图
主要关注系统的功能性需求；帮助开发者理解系统的业务功能和各部分之间的关系；它描述了系统的功能如何被软件的各个模块和组件实现，通常使用类图、包图等来表达。
2. 开发视图
也称为实现视图，关注软件的物理实现和源代码的组织；它描述了软件的层次结构，模块的组织方式，以及这些模块如何分布在开发环境中；通常使用组件图和包图来表示。
3. 进程视图
描述了系统的动态方面，如并发和同步机制；它关注系统如何运行，各个进程或线程的交互和通信；使用活动图或顺序图来展示。
4. 物理视图
描述了系统的部署配置，即软件部件如何映射到硬件上；关注软件的物理分布和硬件的选择；部署图用于表示这一视图。
5. 场景
场景用来展示系统的具体用例或用户故事；它是用例视图的一部分，通常通过用例图和序列图来描述用户如何与系统交互。
05
PART
软件架构风格
ARCHITECTURAL STYLES
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
五大架构风格总表
这是整页最核心的一张表，大类名字和子风格必须能对上号：
数据流风格【Data Flow】
批处理【Batch Sequential】、管道-过滤器【Pipes and Filters】
调用/返回风格【Call/Return】
主程序/子程序【Main Program and Subroutine】、面向对象【Object-oriented】、分层架构【Layered System】
独立构件风格【Independent Components】
进程通信【Communicating Processes】、事件驱动系统（隐式调用）【Event system】
虚拟机风格【Virtual Machine】
解释器【interpreter】、规则系统【Rule-based System】
以数据为中心【Data-centered】
数据库系统【Database System】、黑板系统【Blackboard System】、超文本系统【Hypertext System】
数据流风格
批处理
前一步的处理结果是后一步的输入内容【数据驱动】。数据分步处理，一步步往下走。
管道-过滤器
数据经「管道」在各「过滤器」之间流动，每个过滤器各做一段加工。
两者怎么区分（一句记）
批处理序列：大量整体数据、无需用户交互。
管道-过滤器：流式数据、弱用户交互。
管道-过滤器（数据流风格）的优缺点，脑图单独列了一张表：
优点
1、松耦合【高内聚-低耦合】；
2、良好的重用性/可维护性；
3、可扩展性【标准接口适配】；
4、良好的隐蔽性；
5、支持并行。
缺点
1、交互性较差；
2、复杂性较高；
3、性能较差（每个过滤器都需要解析与合成数据）。
典型实例
传统编译器、网络报文处理。
调用/返回风格
主程序/子程序
面向过程：主函数调用子函数，子函数返回执行结果。
面向对象
对象的方法调用。
分层架构
层与层之间的方法调用。
分层架构风格另有一张优缺点表，考点在「并不是每个系统都方便分层」这一条：
优点
1、良好的重用性，只要接口不变可用在其它处；
2、可维护性好；
3、可扩展性好，支持递增设计。
缺点
1、并不是每个系统都方便分层；
2、很难找到一个合适的、正确的层次抽象方法；
3、不同层次之间耦合度高的系统很难实现。
特点
各个层次的组件形成不同功能级别的虚拟机；多层相互协同工作，而且实现透明。
独立构件风格
进程通信【Communicating Processes】
构件之间直接交互，紧耦合。
事件驱动系统（隐式调用）【Event system】
构件之间不直接交互，由事件管理机制触发事件、通知执行、返回执行结果，松耦合。
优点
1、松耦合。
2、良好的重用性/可修改性/可扩展性。
缺点
1、构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。
2、数据交换的问题。
3、既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。
特点
系统由若干子系统构成且成为一个整体；系统有统一的目标；子系统有主从之分；每一子系统有自己的事件收集和处理机制。
虚拟机风格
解释器：可以灵活应对自定义场景；缺点是复杂度较高；适用于需要「自定义规则」的场合。
规则系统（以规则为中心）：在解释器的基础上增加经验规则；适用于专家系统。
基于规则的系统构成
规则集、规则解释器、规则/数据选择及工作内存，一般用在人工智能领域和 DSS（决策支持系统）中。
数据流：知识库 → 事实集/工作内存 → 规则集 → 触发数据 → 规则/数据选择 → 被选择的规则与被选择的数据 → 规则解释器 → 输出与更新
以数据为中心（仓库风格）
数据库系统
特点：以数据为中心
黑板系统
优点：可更改性和可维护性；可重用的知识源；容错性和健壮性
缺点：测试困难；不能保证有好的解决方案；难以建立好的控制策略；低效；开发困难；缺少并行机制
特点：在以数据为中心的基础上，使用中心数据触发业务逻辑部件
典型实例：语音识别、模式识别、图像处理、知识推理
超文本系统
以数据为中心的另一类子风格
闭环控制架构（过程控制）
脑图画了两套控制回路：开环控制系统（给定值 → 控制器 → 执行器 → 被控对象 → 被控量）和闭环控制系统（多一个「反馈环节」，把反馈量送回比较器）。
√ 适合于嵌入式系统，用于解决简单闭环控制问题。
经典应用：空调温控，定速巡航。
C2 风格
C2 架构的基本规则
√ 构件和连接件都有一个顶部和一个底部。
√ 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
√ 一个连接件可以和任意数目的其他构件和连接件连接。
√ 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
本节案例（3 组 13 空）
架构风格判断 · 第一组（5 空）
这一组是「给场景、选风格」的典型套路，原图的答案标注是：虚拟机、数据流风格、隐式调用（事件驱动）、解释器、过程控制（顺序与题干一一对应）。
01 Java 程序可以做到「一次编写，到处运行」，从架构风格上看符合（ ）风格的特点。
02 在网络通信中，进行包的解析，一般先进行包头的分离，然后进行报文解析及后续处理，根据这一特点，选用（ ）风格最合适。
03 某公司欲开发一个基于图形用户界面的集成调试器。该调试器的编辑器和变量监视器可以设置调试断点。当调试器在断点处暂停运行时，编辑程序可以自动卷屏到断点，变量监视器刷新变量数值。针对这样的功能描述，采用（ ）的架构风格最为合适。
04 某游戏公司欲开发一个大型多人即时战略游戏，游戏设计的目标之一是能够支持玩家自行创建战役地图，定义游戏对象的行为和之间的关系。针对该目标，公司应该采用（ ）架构风格最为合适。（四选一：管道-过滤器、隐式调用、主程序-子程序、解释器）
05 某公司承接了一个开发家用空调自动调温器的任务，调温器测量外部空气温度，根据设定的期望温度控制空调的开关。根据该需求，公司应采用（ ）架构风格最为合适。（四选一：解释器、过程控制、分层、管道-过滤器）
逐条对应：Java 的跨平台靠「解释执行字节码」，属虚拟机风格；包的分离与解析是典型的数据逐级加工，属数据流风格（管道-过滤器）；调试器断点触发卷屏与刷新，是「一个事件触发多个响应」，属隐式调用（事件驱动）；玩家自定义地图与对象行为，需要「规则由外部描述、运行时解释」，属解释器；调温器测温度、控开关，是标准的闭环回路，属过程控制。
架构风格判断 · 第二组（3 空）
01 某公司欲开发一个语音识别系统，语音识别的主要过程包括分割原始语音信号、识别音素、产生候选词、判定语法片断、提供语义解释等。每个过程都需要进行基于先验知识的条件判断并进行相应的识别动作。针对该系统的特点，采用（ ）架构风格最为合适。（四选一：解释器、面向对象、黑板、隐式调用）
02 某公司欲开发一个漫步者机器人，用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性，机器人接受任务后，需要根据自身状态和外界环境进行动态调整，最终自动完成任务。针对这些需求，该机器人应该采用（ ）架构风格最为合适。（四选一：解释器、主程序-子程序、隐式调用、管道-过滤器）
03 Windows 操作系统在图形用户界面处理方面采用的核心架构风格是（ ）风格。
原图的答案标注是：黑板、解释器、事件驱动。语音识别的多个知识源围绕共享数据协作，是黑板系统的教科书例子；机器人按任务描述动态调整，走解释器；Windows 的图形界面处理是事件驱动（隐式调用）的标志性场景。
编译器的架构设计场景（5 空，答案 A、C、A、B、D）
「编译器」是一种非常重要的基础软件，其核心功能是对源代码形态的单个或一组源程序依次进行预处理、词法分析、语法分析、语义分析、代码生成、代码优化等处理，最终生成目标机器的可执行代码。考虑以下与编译器相关的软件架构设计场景：
传统的编译器设计中，上述处理过程都以独立功能模块的形式存在，程序源代码作为一个整体，依次在不同模块中进行传递，最终完成编译过程。针对这种设计思路，传统的编译器采用（1）架构风格比较合适。
随着编译、链接、调试、执行等开发过程的一体化趋势发展，集成开发环境（IDE）随之出现。IDE 集成了编译器、连接器、调试器等多种工具，支持代码的增量修改与处理，能够实现不同工具之间的信息交互，覆盖整个软件开发生命周期。针对这种需求，IDE 采用（2）架构风格比较合适。IDE 强调交互式编程，用户在修改程序代码后，会同时触发语法高亮显示、语法错误提示、程序结构更新等多种功能的调用与结果呈现，针对这种需求，通常采用（3）架构风格比较合适。
某公司已经开发了一款针对某种嵌入式操作系统专用编程语言的 IDE，随着一种新的嵌入式操作系统上市并迅速占领市场，公司决定对 IDE 进行适应性改造，支持采用现有编程语言进行编程，生成符合新操作系统要求的运行代码，并能够在现有操作系统上模拟出新操作系统的运行环境，以支持代码调试工作。针对上述要求，为了使 IDE 能够生成符合新操作系统要求的运行代码，采用基于（4）的架构设计策略比较合适；为了模拟新操作系统的运行环境，通常采用（5）架构风格比较合适。
（1）
A. 管道-过滤器
B. 顺序批处理
C. 过程控制
D. 独立进程
（2）
A. 规则引擎
B. 解释器
C. 数据共享
D. 独立构件
（3）
A. 隐式调用
B. 显式调用
C. 主程序-子程序
D. 层次结构
（4）
A. 代理
B. 适配
C. 包装
D. 模拟
（5）
A. 隐式调用
B. 仓库结构
C. 基于规则
D. 虚拟机
原图给出的答案序列是A、C、A、B、D。（1）源码在独立模块间依次传递，是管道-过滤器；（2）多个工具围绕共享数据进行信息交互，是数据共享；（3）改代码同时触发高亮、报错、结构更新，是隐式调用；（4）让既有代码适配新目标，用适配；（5）在现有操作系统上模拟另一套运行环境，靠虚拟机。
06
PART
基于架构的开发方法 ABSD
ARCHITECTURE-BASED SOFTWARE DESIGN
概念与三个基础
√ ABSD 方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。
ABSD 方法的三个基础
第一个基础是功能的分解。在功能分解中，ABSD 方法使用已有的基于模块的内聚和耦合技术；
第二个基础是通过选择架构风格来实现质量和业务需求；
第三个基础是软件模板的使用。
⚠ 两个「捕获」别搞反
√ 用例用来捕获功能需求、特定场景用来捕获质量需求。很多题就是把这两个词互换来设坑。
开发过程 1：六个子过程
架构需求
架构设计
架构文档化
架构复审
架构实现
架构演化
图里还标了两条回路：架构评审不合适会回到架构设计（0:M），架构复审后又回到架构文档化（0:N）。
架构文档化的输出
架构文档化过程的主要输出结果是架构规格说明和测试架构需求的质量设计说明书这两个文档。
文档的完整性和质量是软件架构成功的关键因素。关于文档的三大注意事项：
√ 文档要从使用者的角度进行编写
√ 必须分发给所有与系统有关的开发人员
√ 且必须保证开发者手上的文档是最新的
架构复审的目的
架构复审的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误。
开发过程 2：需求与设计
架构需求过程
需求获取（对应「需求库」）→ 生成类图 → 对类进行分组 → 把类打包成构件 → 需求评审
其中「生成类图 → 对类进行分组 → 把类打包成构件」这一串就是图里标注的「标识构件」。
架构设计过程
提出架构模型 → 映射构件 → 分析构件相互作用 → 产生架构 → 设计评审
开发过程 3：实现与演化
架构实现过程
复审后的文档化的架构 → 分析与设计 → 构件实现 → 构件组装 → 系统测试 → 架构演化
「构件实现」「构件组装」两步都要从「构件库」里取件。
架构演化过程
需求变化归类 → 架构演化计划 → 构件变动 → 更新构件的相互作用 → 构件组装与测试 → 技术评审 → 演化后的架构
本节案例（2 组 6 空）
用什么描述架构／功能需求／质量需求（3 空，答案 B、C、D）
在基于体系结构的软件设计方法中，采用（ ）来描述软件架构，采用（ ）来描述功能需求，采用（ ）来描述质量需求。
第 1 空：A 类图和序列图 B 视角与视图 C 构件和类图 D 构件与功能
第 2 空：A 类图 B 视角 C 用例 D 质量场景
第 3 空：A 连接件 B 用例 C 质量场景 D 质量属性
原图答案：B、C、D。架构用「视角与视图」描述；功能需求靠「用例」捕获；质量需求靠「质量场景」捕获——这三句是 ABSD 的基本盘，背下来直接得分。
ABSDM 的六个子过程（3 空，答案 A、A、C）
ABSDM（Architecture-Based Software Design Model）把整个基于体系结构的软件过程划分为体系结构需求、体系结构设计、体系结构文档化、（ ）、（ ）和体系结构演化等 6 个子过程。其中，（ ）过程的主要输出结果是体系结构规格说明和测试体系结构需求的质量设计说明书。
第 1 空：A 体系结构复审 B 体系结构测试 C 体系结构变更 D 体系结构管理
第 2 空：A 体系结构实现 B 体系结构测试 C 体系结构建模 D 体系结构管理
第 3 空：A 体系结构设计 B 体系结构需求 C 体系结构文档化 D 体系结构测试
原图答案：A、A、C。六步完整顺序是 需求 → 设计 → 文档化 → 复审 → 实现 → 演化，所以前两空都是 A；第三个空问谁输出「规格说明 + 质量设计说明书」，答案是体系结构文档化。
07
PART
特定领域软件架构 DSSA
DOMAIN-SPECIFIC SOFTWARE ARCHITECTURE
定义：特定领域软件架构以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，支持一个特定领域中多个应用的生成。
三个组成部分
领域参考模型
高层次的抽象模型、描述该领域的关键概念及其关系，帮助开发团队准确理解领域问题和需求。
比如：在医疗信息系统领域，参考模型可能会定义病人、医生、治疗、药物、诊断等实体及其相互作用。
参考需求
基于参考模型定义的，描述软件系统需要满足的功能性和非功能性的条件。
比如：参考需求可能包括数据隐私包含、高可用性、用户界面易用性、数据准确性等。
参考架构
基于参考模型和参考需求定义的软件架构蓝图，通常包括软件结构组成、技术选型、设计模式。
比如：采用微服务架构，使用加密技术，采用特定中间件和数据库技术等。
垂直域与水平域
垂直域：相同领域，深入。
水平域：不同领域，平移。
参与 DSSA 的四类人员
1、领域专家
有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。
2、领域分析人员
领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。
3、领域设计人员
领域设计人员应由有经验的软件设计人员来担任。
4、领域实现人员
领域实现人员应由有经验的程序设计人员来担任。
建立过程的五步（以 MMORPG 为例）
1. 定制领域范围（定义领域范围）
这一步骤涉及确定和界定软件架构将要处理的具体领域。对于 MMORPG 来说，领域范围包括游戏的基本互动模式、玩家角色的行为机制、虚拟世界的环境设定以及玩家之间的交互。这一阶段的目的是精确定义游戏的主题和基本架构需求，如支持大规模多人在线互动和高度的自由度。
2. 定义领域特定的元素
在这一步中，我们详细定义游戏中的核心元素，包括角色的各类属性（如等级、生命值、魔法值）、技能系统（如技能树、技能效果）、NPC（非玩家控制角色）和怪物的行为模式，以及游戏内的经济系统。这些元素是游戏体验的关键部分，需要精心设计以确保游戏的可玩性和长期吸引力。
3. 定义领域特定的设计和实现需求约束
此步骤涉及到制定满足领域需求的设计和实施细节。这包括确保游戏服务器能够处理高并发用户连接、数据同步的实时性、以及游戏安全性（防止作弊）。此外，需求约束还包括对软件质量的要求，如系统的可扩展性、可维护性和故障恢复能力。
4. 定义领域模型和架构
基于上述定义的元素和需求，设计游戏的总体架构。这可能包括选择适用于 MMORPG 的分布式架构，定义客户端和服务器之间的交互协议，以及实现数据存储和处理的方式。架构设计应支持游戏的快速迭代和未来的功能扩展。
5. 产生和搜集可复用的产品单元
开发过程中，识别并创建可以在游戏中复用的组件，如聊天引擎、角色动画控制系统、敌人行为脚本等。这些组件可以在当前和未来的游戏项目中重复使用，以提高开发效率和降低成本。
DSSA 基本活动及产出物
领域【分析】 → 建立领域模型
领域【设计】 → 获得 DSSA
领域【实现】 → 开发和组织可复用信息（各种构件）
DSSA 的三层次模型
领域开发环境
领域架构师使用；向下输出参考结构、参考需求、架构、领域模型、开发工具
领域特定的应用开发环境
应用工程师使用；向下输出实例化的架构
应用执行环境
操作员使用
08
PART
软件产品线
SOFTWARE PRODUCT LINE
产品 · 产品线 · 产品集
1. 产品（Product）
一个软件产品是指一个单独的、完整的软件系统或服务，它被设计来满足特定的业务需求或用户需求。每个产品都具有独立的功能，并能够为用户提供价值。
2. 产品线（Product Line）
软件产品线指的是一系列相关联的产品，它们共享一组核心资产（如代码库、技术架构、用户接口组件等）。这些产品通常在市场定位、基本功能或用户体验上有相似性，但也各自具有独特的特性。产品线通过复用核心资产降低成本，提高效率。
3. 产品集（Product Portfolio）
产品集是指一个组织提供的所有产品的集合，包括多个产品线。这些产品可能涵盖不同的市场领域或技术领域。产品集的管理涉及到战略层面的考虑，如产品之间的定位、市场分布、资源分配和风险管理。
三者之间的关系，脑图给了一段说明：
· 从产品到产品线：在共享的核心资产基础上，扩展出多个产品，逐步发展出满足不同需求的多个产品。
· 从产品线到产品集：多个产品线集合起来构成一个更广泛的产品集，每个产品线专注于特定的市场需求或技术领域，而产品集则提供跨产品线的综合解决方案。
· 产品集管理：在最高层面，组织需要管理其产品集，以确保公司资源得到最优配置，并且各产品线和产品之间能够相互支持和补充，实现业务战略目标。
双生命周期
领域工程（由现有系统需求驱动）
领域分析 → 领域设计 → 领域实现
依次产出：领域需求模型、领域架构、领域可复用构件
应用工程（由新系统需求驱动）
需求分析 → 系统设计 → 系统实现 → 新系统
应用工程所需的「领域需求模型／领域架构／领域可复用构件」直接来自领域工程
建立方式
基于现有产品
演化方式：基于现有产品架构设计产品线的架构，经演化现有构件，开发产品线构件。
革命方式：核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集。
全新产品线
演化方式：产品线核心资源随产品新成员的需求而演化。
革命方式：开发满足所有预期产品线成员的需求的核心资源。
组织结构与成功因素
组织结构类型
★ 设立独立的核心资源小组
★ 不设立独立的核心资源小组
★ 动态的组织结构
要成功实施产品线，主要取决于以下因素
★ 对该领域具备长期和深厚的经验
★ 一个用于构建产品的好的核心资源库
★ 好的产品线架构
★ 好的管理（软件资源、人员组织、过程）支持
产品线演化的四条路径
★ 将现有产品演化为产品线
★ 用软件产品线替代现有产品集
★ 全新软件产品线的演化
★ 全新软件产品线的开发
///
LAST
写在最后：这一页最容易混的四组
QUICK RECAP
三个「无状态」与「有状态」：对象有外部可见状态，构件没有，模块只是结构化开发的产物。
两套 4+1：架构那套讲「给谁看」（用户／编程／集成／系统），UML 那套讲「画什么」（类与对象／代码文件／线程并发／硬件映射）。
两种「复用」：水平是跨行业、通用（函数库），垂直是绑行业、专用（医学词汇表、网银接口）。
ABSD 与 DSSA：ABSD 是一次开发的方法（需求→设计→文档化→复审→实现→演化），DSSA 是面向一个领域的资产建设（分析→设计→实现）。
⚠ 风格判断题的三个动作
第一步抓动词：题干说「一次编写到处运行」「自定义规则」→ 虚拟机；说「依次传递」「解析合成」→ 数据流；说「触发」「通知」「刷新」→ 隐式调用；说「反馈」「期望值」「控制开关」→ 过程控制。第二步排干扰：题目给了四选一范围，先把明显不搭的划掉。第三步看是否共享数据：几个知识源围着一份中心数据干活，就是黑板。
✦ 这一页的复习重心
这一页分支多、图多，但真正的考点集中在四处：五大架构风格与子风格的对应、架构风格判断的四选一、ABSD 六个子过程的顺序与产出物、DSSA 与产品线的基本概念与人员／组织。把 21 个空连着做两遍，这页就算过关了。
架构风格的分，不在背名字，在把场景读到动词上。
我是 violetdream，一个正在陪你把软考架构啃完的人。
这页纸的内容来自「架构考前八页纸」，共 8 篇，这是第 6 篇。下一篇进入软件工程。
既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。
THANKS FOR READING
