【软考系统架构设计师】第五章 ABSD方法（知识点必知必会）

【软考系统架构设计师】第五章 ABSD方法（知识点必知必会）

一. ABSD基本概念

1）ABSD的定义

1. 基于架构的软件设计ABSD是一种架构驱动方法。
2. ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。不管设计是否完成，架构总是被清晰的定义的，这样有助于降低架构设计的随意性。
3. 在建立软件架构的初期，选择一个合适的架构风格是首要的，在此基础上，开发人员通过架构模型，可以获得关于软件架构属性的理解，为将来的架构实现与演化过程建立了目标。

2）ABSD的三个基础

01. 功能的分解

1. 使用已有的基于模块的内聚和耦合技术。

02. 架构风格的选择

1. 通过选择架构风格来实现质量和业务需求

03. 软件模版的重用

1. 软件模版利用了一些软件系统的结构。
2. 软件模版是一个特殊类型的软件元素，包括描述所有这些类型的元素在共享服务和底层构造的基础上如何进行交互。
3. 在软件产品线系统中，软件模版显得格外重要。

3）ABSD的强调内容

1. 强调由商业、质量和功能需求的组合驱动软件架构设计。
2. 使用ABSD方法，设计活动可以从项目总体功能框架明确就开始。
3. 它强调采用视角和视图来描述软件架构，采用用例和质量场景来描述业务需求。

4）ABSD方法的输入与输出

01. ABSD输入

1）抽象功能需求（变化的需求和通用的需求）
2）用例（实际功能需求）
3）抽象的质量和业务需求
4）质量因素（实际质量和业务需求）
5）架构选项
6）约束
这些输入也是需求阶段的假定输出。

02. ABSD输出

1. 三个视图的概念构件的集合，包括能够产生每个概念构件的假定，软件模版的集合，和那些已经作出具体实现的决策。
2. 简单来说，ABSD方法的输出就是软件构件的设计。

二. 基于架构的开发模型的六个过程

1. 主要是获取用户需求，标识系统中所要用到的构件。如果以前有类似的系统架构需求，我们可以从需求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。
2. 架构需求又包含了三个方面，必要时可以在需求获取，标识构件，需求评审之间进行迭代。

1）架构需求

01. 获取需求

1. 架构需求一般来自三个方面：系统的质量目标，系统的业务目标，系统开发人员的业务目标。
2. 主要定义开发人员必须完成的软件功能，使用户能够完成他们的任务，从而满足业务上的功能需求，与此同时还要获得软件质量属性，满足一些非功能的需求。

02. 标识构件

1. 分为三步来实现：生成类图，对类进行分组，把类打包成构件。

03. 需求评审

1. 对架构需求和相关构件进行仔细审查，审查的内容主要包括了所获取的需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理。

2）架构设计

• 如果要开发的系统能够从已有的系统中导出大部分，则可以使用已有系统的设计过程。

01. 提出架构模型

1. 在设计初期，开发人员通过架构模型可以获得关于架构属性的理解，所以在初期选择一个合适的架构风格是首要的。

02. 映射构件

1. 把在架构需求阶段已经标识的构件映射到架构中
2. 将产生一个中间结构，这个中间结构只包含那些能明确适合架构模型的构件。

03. 分析构件的相互作用

1. 为了把所有已标识的构件集成到架构中，必须认真分析这些构件的相互作用和关系。

04. 产生架构

05. 设计复审

1. 一旦设计了软件架构，我们必须邀请独立于系统开发的外部人员对架构进行评审。

3）架构文档化

01. 架构文档化的概念

• 绝大多数的架构都是抽象的，由一些概念上的构件组成，要让程序员和系统分析师去实现架构，还必须得把架构进行相应的文档化。

02. 架构文档化的输出

1. 架构需求规格说明
2. 测试架构需求的质量说明书。

03. 架构文档化的其他概念

1. 架构文档是用户和开发者之间的一个协约。
2. 文档的完整性和质量是软件架构成功的关键因素。
3. 文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的。

04. 架构文档的原则

1）文档要从使用者的角度进行编写
2）必须分发给所有与系统有关的开发人员
3）应该保持架构文档的即时更新，但更新不要过于频繁。
4）架构文档中描述应该尽量避免不必要的重复
5）每次架构文档修改都应该记录进行修改的原则。
6）架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性。

4）架构复审

01. 架构复审的概念

1. 架构复审是基于架构开发中一个重要的环节。
2. 架构设计、文档化和复审是一个迭代的过程。
3. 架构复审过程中，通常会对一个可运行的最小化系统进行架构评估和测试。

02. 架构复审的目的

1. 标识潜在的风险，以及尽早发现架构设计中的缺陷和错误
2. 包括架构能否满足需求，质量需求是否在架构设计中得到体现，层次是否清晰，构件的划分是否合理，文档表达是否明确，构件的设计是否能够满足功能和性能的要求。

03. 架构复审的参与者

1. 在架构复审过程中，主要由用户代表与领域专家决定架构是否满足需求、质量需求是否在设计中得到体现。
2. 从这个方面来说，在一个主版本的软件架构分析之后，要安排一次由外部人员 (用户代表和领域专家）参加的复审。

5）架构实现

1. 要符合架构所描述的结构性设计决策，分割成规定的构件，按规定的方式进行交互。
2. 整个架构实现过程以复审后文档化的架构说明书为基础，每个构件必须满足软件架构中说明的对其他构件的责任。
3. 在执行完以下的四个步骤之后，就进入架构的演化。

01. 分析与设计

02. 构件实现

03. 构件组装

04. 系统测试

1. 包括单个构件的功能性测试和被组装的应用整体功能和性能的测试。

6）架构演化

• 只要需求会有相应的变化，就势必会去修改相应的软件架构。
• 使用系统演化步骤去修改应用，以满足新的需求。

01. 需求变化的归类

目的是让变化的需求与已有的构件进行对应。
对找不到的构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对应这部分变化的需求。

02. 架构演化计划

在改变原有结构之前，开发组织必须制订一个周密的体系结构演化计划，作为后续演化开发工作的指南

03. 构件变动

根据需求来决定是否修改或删除原有的构件，增加新构件。
在演化计划的基础上，开发人员可根据在第1步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的构件进行功能性测试。

04. 更新构件之间的相互作用

随着构件的增加删除和修改，构件之间的控制流必须得到更新。

05. 构件组装与测试

丢组装好的系统的整体功能和性能进行测试，形成新的架构。

06. 技术评审

评审架构是否反应需求变动，符合用户需求

07. 演化后的架构

三. ABSD开发的过程中可能遇到的问题

1. 在架构需求获取过程中如何对捕获的架构需求进行筛选和优先级排序；
2. 在架构复审过程中如何解决评审人员的意见不一致问题；
3. 在架构实现过程中如何根据项目组实际情况选择开发语言与开发平台
4. 在架构演化过程中如何筛选并处理用户的需求变更，等等。