ADD构架设计方法
Version 1.0
2008-12-10
本文为《软件构架实践》一书的学习笔记。
ADD(属性驱动的构架设计)是一种以质量属性实现为主要推动力的构架设计方法,它将功能实现放到了次要的位置上。
ADD的总体过程:选择要处理的对象(系统、子系统或模块),确定其需实现的功能和需满足的质量属性,选择能够实现这些质量属性的构架战术,根据战术设计构架,得到子模块,为子模块分配功能和应承担的总体战术中的部分,最后检查功能与质量属性是否都被满足。至此,子模块所需实现的功能及需承担的战术部分都已确定,然后选择子模块进行上述一样的处理,形成一个递归的分解过程。
ADD的开始:大体确定了构架驱动因素,构架驱动因素指对构架影响最大的需求——质量属性或功能;书中未提及后期确定的构架驱动因素更新对已有的构架设计部分的反馈过程;
ADD的输入:功能需求与限制,以场景描述的质量属性需求;
ADD的输出:模块分解视图及其他视需而定的视图的最初几个层次;
ADD的地位:可以被结合到其他开发方法中,替换掉那些方法的构架设计部分;
ADD的过程
1, 选择要分解的模块、系统或子系统,确定其限制因素,功能、质量属性、设计约束;
2, 确定构架驱动因素,ADD优先满足重要的需求;
3, 选择能实现质量属性的战术,依据战术选择构架模式(此处“模式”含义不同于我们常说的用于解决特定应用场景重复出现的问题的模式),确定子模块,目标是建立一个由“模块类型”组成的总体构架模型,它由选定的战术构造,并满足了驱动因素;
4, 实例化模块并根据用例分配功能;将模块类型实例化为模块,如将“关键性能计算”实例化为“障碍物检测”,将父模块的每个用例划分成子模块的一系列责任,并记录产生的信息交换;用视图表示构架,一般以模块分解视图为主,视需要引入其他视图;
5, 定义子模块接口,包括服务、交互模式等;
6, 验证用例与质量场景是否已得到满足,并为子模块的分解做好准备;质量属性被影响的几种情况:
a) 质量属性被分解所满足,如大容量需求被分发器与处理器构成的负载均衡方案所满足;
b) 各模块满足质量属性的一部分;
c) 分解对质量属性不产生影响,将其分配给某个子模块,如易用性分配给UI模块;
d) 分解与质量属性冲突,则可能需要重新考虑分解;
7, 选择子模块,重复上述过程;每次循环的结果:每个子模块拥有一组用例,接口,质量场景及限制的集合,依据这些进行下一轮的设计。
ADD(属性驱动的构架设计)是一种以质量属性为首要考虑的设计方法,强调在功能实现之前满足质量属性。该方法通过选择系统、子系统或模块,确定功能和质量属性需求,选择合适的构架战术,递归分解来设计构架。ADD过程包括确定构架驱动因素、选择构架模式、实例化模块、分配功能、定义接口、验证和子模块分解等步骤,确保功能与质量属性的平衡满足。

154

被折叠的 条评论
为什么被折叠?



