《软件构架实践》阅读笔记04

    开始ADD。我们已经介绍了构架驱动因素。ADD依赖于对驱动因素的识别，确定了所有的驱动因素后，ADD就可以开始了。当然，在设计中关键的构架驱动因素可能会发生变化，或者是因为更好的理解了需求，或者是因为需求发生了变化。

ADD步骤。

（1）       选择要分解的模块。要分解的模块通常是整个系统。该模块要求的所有输入都应该是可获得的（限制条件、功能需求和质量需求）。

（2）       根据这些步骤对模块进行求精：

A． 从具体的质量场景和功能需求集合中选择构架驱动因素。这一步确定了对该分解很重要的事务。

B． 选择满足构架驱动因素的构架模式，根据可以用来实现驱动因素的战术创建（或选择）模式，确定实现这些战术所需要的子模式。

C． 实例化模块并根据用例分配功能，使用多个视图进行表示。

D． 定义子模块的接口。该分解提供了模块和对模块交互类型的限制。对于每个模块，将该信息编写在接口文档中。

E．  验证用例和质量场景并对其进行求精，使它们成为子模块的限制。这一步验证重要的内容没有被遗忘，并使子模块为进一步分解或实现做好准备。

（3）       对需要进一步分解的每一个模块重复上述步骤。

构架设计必须按需求分析进行，但不需要在需求分析完成后在开始构架设计。实际上，在确定了关键的构架驱动因素后，就可以开始构架设计了。当设计了构架的足够多的部分后（再次说明一下，必要等到构架设计完成是），就可以开发骨架系统了。该骨架系统是在上面进行迭代开发（以及其在任何一个交付点的能力）的框架。将演变交付生命期作为软件开发生命期模型中的“一流”模型进行了说明。其目的是支持具有上市时间压力且产品的功能具有不同优先级的组织，因为它能够是该组织将产品的任意一次迭代发布出去。当与骨架系统的构造结合在一起，并关注使用结构时，就可以 实现某次产品发布中的特性，以最大化对市场的影响。

转载于:https://www.cnblogs.com/xiaoabu/p/6416788.html