系统架构设计师学习之路（23）

5.2 基于架构的软件开发方法

5.2.1 体系结构的设计方法概述
基于体系结构的软件设计（ABSD）方法，是体系结构驱动，是指构成体系结构的商业、质量和功能需求的组合驱动的。使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这就意味着需求抽取和分析还没有完成，就开始了软件设计。
ABSD的三个基础：
（1）功能的分解
（2）通过选择体系结构风格来实现质量和商业需求
（3）软件模板的使用
ABSD方法是递归的，且迭代的每一个步骤都是清晰地定义的。因此，不管设计是否完成，体系结构总是清晰的，这有助于降低体系结构设计的随意性。
5.2.2 概念与术语
1.设计元素
在最顶层，系统被分解为若干概念子系统和一个或若干个软件模板。
在第二层，概念子系统又被分解成概念构件和一个或若干个附加软件模板。
2.视角与视图
考虑体系结构时，重要的是从不同视角来检查。例如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。选择特定视角或试图也就是逻辑视图、进程视图、实现视图和配置视图。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能性等。
3.用例和质量场景
用例已成为推测系统在一个具体设置中的行为的重要技术，用例被用在很多不同的场合，用例是系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求。
使用用例捕获功能需求的同时，我们通过定义特定场景来捕获质量需求，并称之为质量场景。在一般的软件开发过程中，我们使用质量场景捕获变更、性能、可靠性和交互性，分别称为变更场景、性能场景、可靠性场景和交互性场景。
质量场景必须包括预期的和非预期的。非预期场景可能不能真正实现，但它们在决定设计的边界条件时很有用。
5.2.3 基于体系结构的开发模型
传统的软件开发过程可以划分为从概念直到实现的若干阶段，包括问题定义、需求分析、软件设计、软件实现及软件测试等，软件体系结构的建立位于需求分析之后，概要设计之前。
ABSDM模型把整个基于体系结构的软件过程分为体系结构需求、设计、文档化、复审、实现和演化等6个子过程。
5.2.4 体系结构需求
1.需求获取
需求一般来自三个方面：
（1）系统的质量目标；
（2）系统的商业目标；
（3）系统开发人员的商业目标。
2.标识构件
过程：生成类图、对类进行分组、把类打包成构件。
3.架构需求评审
组织一个由不同代表（如分析人员、客户、设计人员、测试人员）组成的小组，对体系结构需求及相关构件进行仔细审查。
审查内容：所获取的需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理等。必要时，可以在“需求获取-标识构件-需求评审”之间进行迭代。
5.2.5 体系结构设计
1.提出软件体系结构模型
2.把已标识的构件映射到软件体系结构中
3.分析构件之间的相互作用
4.产生软件体系结构
5.设计评审
5.2.6 体系结构文档化
绝大多数的体系结构都是抽象的，由一些概念上的构件组成。让系统分析员和程序员去实现体系结构，还必须得把体系结构进行文档化。
文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证体系结构设计和提炼或修改这些设计所执行预先分析的基础。
体系结构文档化的输出结果：体系结构规格说明和测试体系结构需求的质量设计说明书。
5.2.7 体系结构复审
体系结构设计、文档化和复审是一个迭代过程。从这个方面来说，在一个主版本的软件体系结构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。
复审的目的：标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能和性能的要求等。
5.2.8 体系结构实现
整个实现过程是以复审后的文档化的体系结构说明书为基础的，每个构件必须满足软件体系结构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内给出的，每个构件上工作的实现者是看不见的。
5.2.9 体系结构的演化
体系结构演化是使用系统演化步骤去修改应用，以满足新的需求。主要有6个步骤:
1.需求变化归类
2.制订体系结构演化计划
3.修改、增加或删除构件
4.更新构件的相互作用
5.构件组装与测试
6.技术评审