原子标签索引：[概念×14 | 机制×4 | 流程×6 | 分类×4 | 判据×3 | 数据×3 | 案例×1] 上游：第5章（软件工程基础） 下游：第8章（质量属性与架构评估）、第10章（架构演化维护）、第12～16章（各架构实践）

标准表述

• Bass、Clements 和 Kazman 定义：软件体系结构是指系统的一个或多个结构，结构中包括软件的构件、构件的外部可见属性以及它们之间的相互关系。
• 体系结构并非可运行软件，它是一种表达。
• 软件体系结构设计考虑设计金字塔的两个层次：数据设计和体系结构设计。
• 体系结构描述语言 ADL 对"连接子"的重视是区分 ADL 与其他建模语言的重要特征之一。
• 典型 ADL：UniCon、Rapide、Darwin、Wright、C2 SADL、Acme、xADL、XYZ/ADL、ABC/ADL。
• 多视图体现关注点分离的思想。
• 典型多视图方案：4+1 模型（逻辑、进程、开发、物理视图+统一场景）、Hofmeister 4 视图（概念、模块、执行、代码）、CMU-SEI Views and Beyond（模块、构件和连接子、分配视图）。
• 体系结构失配问题由 David Garlan 等人在 1995 年提出，指待复用构件对最终系统体系结构和环境的假设与实际状况不同导致的冲突。
• ABSD 方法由体系结构驱动的，指由构成体系结构的商业、质量和功能需求的组合驱动；设计活动可在需求抽取和分析尚未完成时开始，并与需求活动并行。
• ABSD 方法三个基础：功能分解、通过选择体系结构风格实现质量和商业需求、软件模板的使用。
• ABSD 是自顶向下、递归细化的方法。
• 用例用来捕获功能需求；质量场景用来捕获质量需求，且必须包括预期的和非预期的场景。
• ABSD 模型把基于体系结构的软件过程分为 6 个子过程：体系结构需求、设计、文档化、复审、实现、演化。
• 体系结构需求一般来自三个方面：系统的质量目标、系统的商业目标、系统开发人员的商业目标。
• 标识构件三步：生成类图 → 对类进行分组 → 把类打包成构件。
• 体系结构文档化的主要输出是两个文档：体系结构规格说明和测试体系结构需求的质量设计说明书。
• 体系结构复审目的：标识潜在风险，及早发现设计中的缺陷和错误。
• 体系结构风格定义一个系统家族，即定义一个词汇表（构件和连接件类型）和一组约束。
• SAAM 由 CMU-SEI 的 Kazman 等人提出（教材记为 1983 年），是最早形成文档并得到广泛使用的软件架构分析方法，主要分析可修改性。
• 软件复用类型包括机会复用（发现即复用）和系统复用（开发前规划）。
• 复用基本过程三阶段：构造/获取可复用资产 → 管理资产（构件库）→ 选择/定制/组装资产。
• DSSA 是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。
• DSSA 基本活动三阶段：领域分析（产出领域模型）、领域设计（产出 DSSA）、领域实现（组织可重用信息）。
• 参与 DSSA 的人员四角色：领域专家、领域分析人员、领域设计人员、领域实现人员。
• DSSA 建立过程五阶段：定义领域范围、定义领域特定元素、定义领域特定的设计和实现需求约束、定义领域模型和体系结构、产生/搜集可重用的产品单元；过程是并发的、递归的、反复的（螺旋模型）。

蒸馏笔记

概念

• 构件：软件系统中相对独立的有机组成部分（最初称模块）。
• 连接子：构件间的互联机制，逐渐独立出来成为与构件同等级别的实体。
• ADL：支持构件、连接子及其配置描述的语言。
• 多视图表示：从不同视角描述系统体系结构，组织多个视图描述整体 SA 模型。
• 视角/视图：静态视角（逻辑视图）判断质量特性；动态视角（进程视图）判断系统行为特性。
• 用例/质量场景：用例捕获功能需求；质量场景捕获质量需求（变更/性能/可靠性/交互性场景）。
• 体系结构失配：复用构件的假设与实际状况的冲突，含构件失配、连接子失配、全局假设冲突三方面。
• 中间件：遵循特定构件标准，为构件互联提供支持并提供公共服务（安全、命名等）。
• 动态软件体系结构：运行时刻发生改变的体系结构，分软件内部执行导致和外部请求重配置两类。
• SA 重建：从已实现的系统中获取体系结构的过程，输出一组体系结构视图。
• ABSD：基于体系结构的软件设计方法，商业/质量/功能需求组合驱动，递归且迭代。
• 软件产品线：共享公共的、可管理的特性集，以公共核心资产集成开发的一组软件密集型系统。
• 构件库：存储和管理可复用构件的必要设施；两个关键问题是构件分类和构件检索。
• DSSA 领域划分：垂直域=特定系统族的通用架构；水平域=多个系统族中功能区域的共有部分。

机制

• 需求→架构转换关注两个问题：如何根据需求模型构建 SA 模型、如何保证模型转换的可追踪性。
• 实现阶段弥合 SA 与实现鸿沟三途径：引入程序设计语言元素 → 模型转换逐步精化 → 封装底层细节做大粒度构件组装（需中间件支持）。
• 构件组装阶段研究两点：支持连接子实现（UniCon 内建 Pipe/FileIO/ProcedureCall 等）、检测并消除体系结构失配。
• 中间件支持连接子的优势：跨平台交互遵循工业标准（CORBA/J2EE/COM）保证通信完整性；公共服务能力保证最终系统质量属性。
• SA 对部署的作用：提供高层体系结构视图描述软硬件模型；基于 SA 模型分析部署方案质量属性。

流程

• 基于体系结构开发模型（6 子过程）：需求 → 设计 → 文档化 → 复审 → 实现 → 演化。
• 体系结构需求过程：需求获取（三来源）→ 标识构件（类图→分组→打包）→ 需求评审；可迭代。
• 体系结构设计过程（迭代）：提出体系结构模型（选风格优先）→ 构件映射到架构 → 分析构件相互作用 → 产生软件体系结构 → 设计评审（独立外部人员）。
• 体系结构实现过程：以复审后的文档化说明书为基础，从构件库查找符合接口约束的构件（必要时开发新构件）→ 组装 → 测试（单构件功能测试+整体功能性能测试）。
• 体系结构演化 6 步：需求变化归类 → 制订演化计划 → 修改/增加/删除构件 → 更新构件相互作用 → 构件组装与测试 → 技术评审（不合规则 2～6 步迭代）。
• SA 重建四类方法：手工重建、工具支持的手工重建、查询语言自动建立聚集、其他技术（如数据挖掘）。
• DSSA 基本活动：领域分析（定义边界→识别信息源→建领域模型）→ 领域设计（派生 DSSA，含变化性方案）→ 领域实现（开发/提取可重用信息）；反复、逐渐求精。

分类体系

• 软件架构风格六大类（考频极高，封闭集合）： | 风格类别 | 子风格 | 构件/连接件要点 | |---|---|---| | 数据流 | 批处理 | 处理步骤为独立程序，前一步结束下一步才开始，数据整体传递 | | 数据流 | 管道-过滤器 | 构件=过滤器，连接件=管道；数据源源不断产生时适用 | | 调用/返回 | 主程序/子程序 | 单线程控制，过程调用作连接件，层次性调用 | | 调用/返回 | 面向对象 | 构件=对象封装数据与操作 | | 调用/返回 | 层次型 | 每层为上层服务、作下层客户；内部层接口只对相邻层可见 | | 调用/返回 | 客户端/服务器 | 两层 C/S"胖客户机"；三层 C/S 分表示层/功能层/数据层，"瘦客户机" | | 以数据为中心 | 仓库 | 中央数据结构+一组独立构件 | | 以数据为中心 | 黑板 | 适合复杂非结构化问题；传统应用：语音识别、模式识别 | | 虚拟机 | 解释器 | 仿真硬件执行，弥合程序语义与硬件语义差距；缺点执行效率低；典型例：专家系统 | | 虚拟机 | 规则系统 | 规则集、规则解释器、规则/数据选择器、工作内存 | | 独立构件 | 进程通信 | 构件=独立命名过程，连接件=消息传递（点到点/异步/同步/RPC） | | 独立构件 | 事件系统（隐式调用） | 构件触发/广播事件，注册的过程被自动调用；触发者不知道谁受影响 |
• DSSA 必备特征四条：严格定义的问题域和问题解域；普遍性；对领域构件组织模型的恰当抽象；具备领域固定的可重用元素。
• DSSA 三层次系统模型角色：领域构架师（领域开发环境）→ 应用工程师（领域特定应用开发环境）→ 操作员（应用执行环境）。

判据

• 两层 vs 三层 C/S 判据：应用逻辑驻留在客户机="胖客户机"；应用逻辑驻留在应用服务器、只留表示层="瘦客户机"。
• 黑板风格适用判据：复杂非结构化问题、需综合多种知识源求解。
• 体系结构复审触发判据：一个主版本的软件体系结构分析之后，安排由外部人员（用户代表和领域专家）参加的复审。
• 失配检测三来源判据：构件（基础设施/控制模型/数据模型假设冲突）、连接子（交互协议/数据模型假设冲突）、系统成分对全局体系结构的假设冲突。

数据

• 4+1 模型 = 逻辑视图 + 进程视图 + 开发视图 + 物理视图 + 统一的场景。
• 工业界多视图标准：IEEE 1471-2000（软件密集型系统体系结构描述推荐实践）、RM-ODP、UML、Zachman 框架。
• 典型 ADL 九种：UniCon、Rapide、Darwin、Wright、C2 SADL、Acme、xADL、XYZ/ADL、ABC/ADL。
• 复用资产十个方面：需求、架构设计、元素、建模与分析、测试、项目规划、过程方法工具、人员、样本系统、缺陷消除。
• 架构重要性八点（论述题素材）：满足品质、受益人达成一致、支持计划编制、指导开发、管理复杂性、为复用奠基、降低维护费用、支持冲突分析。

案例

• Debugger 断点事件例：编辑器和变量监视器注册 Debugger 的断点事件，断点触发时系统自动调用注册过程，Debugger 只声明事件不关心谁响应（7.3.6 节，事件系统风格）。

易错点 / 边界情况

• ADL 与其他建模语言的区分特征是"对连接子的重视"，不是对构件的描述能力。
• 现阶段 ADL 大多没有显式支持多视图。
• 架构设计可与需求分析并行（ABSD 的核心特征），需求活动并不因此终止。
• 事件系统（隐式调用）中触发者不知道哪些构件受影响、不能假定处理顺序，因此常辅以显式调用。
• 黑板风格属于"以数据为中心"类，不是独立构件类；仓库与黑板的区别在于独立构件对中央数据结构的触发方式（教材按问题求解模型区分）。
• SAAM 教材表述为"1983 年提出"（其他资料或写 1990 年前后，考试以教材为准）；它最初用于比较不同架构、分析可修改性。
• 机会复用 vs 系统复用：前者过程中发现即用，后者开发前规划——考试常考辨析。
• DSSA 领域设计产出的 DSSA 必须具有变化性（多选一、可选方案），因为它面向一组应用而非单个系统。
• 概念子系统和概念构件是 ABSD 设计元素的两个层次（顶层分解出概念子系统+软件模板，第二层分解出概念构件+附加模板）。