基于架构的软件开发 (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 技术评审


©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页