基于架构的软件开发 （ABSD）

ABSD是架构驱动的，强调由商业，质量和功能需求的组合驱动软件架构设计。

ABSD强调用视角与视图描述软件架构，用用例与质量场景描述需求。

ABSD有三个基础，即功能分解，架构风格的选择，以及软件模板的使用。

1 架构需求

1.1 需求获取

架构需求获取来自三个方面，即系统的质量目标，系统的商业目标，系统开发人员的商业目标。

1.2 标识构件

（1）生成类图

（2）对类进行分组

与其他隔离的类形成一个组，由概括关联的类组成一个附加组，由聚合或合成关联的类组成一个附加组

（3）把类打包成构件

把类簇打包成构件，这些构件可以分组合并成更大的构件

1.3 架构需求评审

由分析人员，客户，设计人员，测试人员组成小组，检查需求是否真实，类的分组是否合理，构件的合并是否合理

2 架构设计

2.1 提出软件架构模型

选择一个合适的架构风格，该模型为将来的实现和演化建立了目标

2.2 映射构件

把已标识的构件映射到架构中，将产生一个中间结构，它只包含适合架构模型的构件

2.3 分析构件的相互作用

2.4 产生软件架构

当决定了关键构件之间的相互作用后，就可以在中间结构的基础上进行精化，得到软件架构

2.5 设计评审

邀请独立于系统开发的外部人员对架构进行评审

3 架构文档化

主要输出结果是架构规格说明书和质量设计说明书

4 架构复审

安排由外部人员包括用户代表和领域专家参加的复审

5 架构实现

5.1 分析与设计

在架构说明书中，已经定义了系统中构件与构件之间的关系，构件接口约束对外唯一代表了构件，所以可以从构件库中直接查找符合接口约束的构件

5.2 构件实现

必要时开发新的满足要求的构件

5.3 构件组装

5.4 系统测试

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

6 架构演化

6.1 需求变化归类

对需求变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的需求变动，在后续工作中将创建新的构件来对应

6.2 制定架构演化计划

6.3 构件变动

修改，增加或删除构件，要对修改和增加的构件进行功能性测试

6.4 更新构件的相互作用

6.5 构件组装与测试

6.6 技术评审