基于架构的软件开发方法
- 基于架构的软件开发方法（ABSD）
- 概述
- 概念与术语
- 开发模型
- 体系结构需求
- 体系结构设计
- 体系结构文档化
- 体系结构复审
- 体系结构实现
- 体系结构的演化
基于架构的软件开发方法（ABSD）
基于体系结构的软件设计 (Architecture-Based Software Design，ABSD) 是一种软件开发方法。
强调在开发过程中首先定义系统的体系结构，然后根据这个体系结构来实现系统。它有助于确保系统的结构和设计与业务需求保持一致。
概述
ABSD方法是由体系结构驱动的，即指由构成体系结构的商业、质量和功能需求的组合驱动的。使用
ABSD 方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求抽取和分析还没有完成（甚至远远没有完成），就开始了软件设计。
设计活动的开始并不意味着需求抽取和分析活动就可以终止，而是应该与设计活动并行。特别是在不可能预先决定所有需求时（例如，产品线系统或长期运行的系统），快速开始设计是至关重要的。
ABSD方法有3个基础。第1个基础是功能的分解。在功能分解中， ABSD方法使用已有的基于模块的内聚和耦合技术；
第2个基础是通过选择体系结构风格来实现质量和商业需求。
第3个基础是软件模板的使用，软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，体系结构总是清晰的，这有助于降低体系结构设计的随意性。
概念与术语
- 设计元素
ABSD 方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。
ABSD方法中使用的设计元素如下图。
在最顶层，系统被分解为若干概念子系统和一个或若干个软件模板。在第2层，概念子系统又被分解成概念构件和一个或若干个附加软件模板。 - 视角与视图
考虑体系结构时，要从不同的视角(Perspective) 来观察对架构的描述，这需要软件设计师考虑体系结构的不同属性。 - 用例和质量场景
用例已经成为推测系统在一个具体设置中的行为的重要技术，用例被用在很多不同的场合，用例是系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求。
在使用用例捕获功能需求的同时，人们通过定义特定场景来捕获质量需求，并称这些场景为质量场景。质量场景必须包括预期的和非预期的场景。
开发模型
ABSD模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化共6个子过程，如下所示。
体系结构需求
需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
需求过程主要是获取用户需求，标识系统中所要用到的构件。体系结构需求过程如下图。
- 需求获取
体系结构需求一般来自3个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。 - 标识构件
上图中虚框部分属于标识构件过程，该过程为系统生成初始逻辑结构，包含大致的构件。这一过程又可分为3步来实现。
第1步：生成类图。生成类图的 CASE 工具有很多，例如 Rational Rose 2000能自动生成类图。
第2步：对类进行分组。在生成的类图基础上，使用一些标准对类进行分组可以大大简化类图结构，使之更清晰。一般地，与其他类隔离的类形成一个组，由概括关联的类组成一个附加组，由聚合或合成关联的类也形成一个附加组。
第3步：把类打包成构件。把在第2步得到的类簇打包成构件，这些构件可以分组合并成更大的构件。 - 架构需求评审
组织一个由不同代表(如分析人员、客户、设计人员和测试人员)组成的小组，对体系结构需求及相关构件进行仔细地审查。
审查的主要内容包括：所获取的需求是否真实地反映了用户的要求；类的分组是否合理，构件合并是否合理等。必要时，可以在“需求获取一标识构件一需求评审”之间进行迭代。
体系结构设计
体系结构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。
体系结构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用已有系统的设计过程。
- 提出软件体系结构模型
在建立体系结构的初期，选择一个合适的体系结构风格是首要的。在这个风格的基础上，开发人员通过体系结构模型，可以获得关于体系结构属性的理解。此时，虽然这个模型是理想化的（其中的某些部分可能错误地表示了应用的特征），但是，该模型为将来的实现和演化过程建立了目标。 - 把已标识的构件映射到软件体系结构中
把在体系结构需求阶段已标识的构件映射到体系结构中，将产生一个中间结构，这个中间结构只包含那些能明确适合体系结构模型的构件。 - 分析构件之间的相互作用
为了把所有已标识的构件集成到体系结构中，必须认真分析这些构件的相互作用和关系。 - 产生软件体系结构
一旦决定了关键构件之间的关系和相互作用，就可以在第2阶段得到的中间结构的基础上进行精化。 - 设计评审
一旦设计了软件体系结构，必须邀请独立于系统开发的外部人员对体系结构进行评审。
体系结构文档化
主要产出两种文档，即架构(体系结构)规格说明，测试架构(体系结构)需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。
体系结构复审
从体系结构开发模型的图中可以看到，体系结构设计、文档化和复审是一个迭代过程。从这个方面来说，在一个主版本的软件体系结构分析之后，要安排一次由外部人员（用户代表和领域专家）参加
的复审。
复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。
体系结构实现
“实现”就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。体系结构的实现过程如下图。
虚框部分是体系结构的实现过程。
整个实现过程是以复审后的文档化的体系结构说明书为基础的，每个构件必须满足软件体系结构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内给出的，每个构件上工作的实现者是看不见的。
体系结构的演化
构件开发过程中，用户的需求可能还有变动。在软件开发完毕正常运行后，由一个单位移植到另一个单位，需求也会发生变化。在这两种情况下，就必须相应地修改软件体系结构，以适应已发生变化的软件需求。体系结构演化过程如图。
- 需求变化归类
首先必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对应这部分变化的需求。 - 制订体系结构演化计划
在改变原有结构之前，开发组织必须制订一个周密的体系结构演化计划，作为后续演化开发工作的指南。 - 修改、增加或删除构件
在演化计划的基础上，开发人员可根据在第1步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的构件进行功能性测试。 - 更新构件的相互作用
随着构件的增加、删除和修改，构件之间的控制流必须得到更新。 - 构件组装与测试
通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的体系结构。然后对组装后的系统整体功能和性能进行测试。 - 技术评审
对以上步骤进行确认，进行技术评审。评审组装后的体系结构是否反映需求变动、符合用户需求。如果不符合，则需要在第2到第6步之间进行迭代。
在原来系统上所做的所有修改必须集成到原来的体系结构中，完成一次演化过程。
