des迭代结构_第2部分：迭代完善体系结构

构架构想是一种敏捷的最佳实践，概述了指导软件密集型系统的开发和测试的技术决策。 软件架构师通常使用以下步骤来概述软件密集型系统的目标体系结构（请参阅参考资料部分以访问本系列的第1部分）：

1. 确定重大要求
2. 定义候选架构
3. 定义初始部署模型
4. 定义领域模型

但是架构思考不是一次性的活动。 经验丰富的敏捷团队将其整合到他们的开发工作中是一项持续的工作。 随着团队逐步构建系统，您将发现新的技术挑战，并且需要做出新的体系结构决策。

通常在开发迭代期间执行以下架构活动：

5. 完善体系结构机制：满足第一步中确定的对体系结构有重要要求的技术概念。
6. 完善设计元素：具有建筑意义的设计元素
7. 完善部署架构：部署单元和拓扑

反复完善架构

请了解，通常不需要为系统的所有部分指定设计。 就像项目中的所有其他内容一样，只有在它带来一些价值的情况下，您才进行操作。 但是，软件密集型系统的某些部分必须比其他部分更详细地指定。 可能是因为某些组件更难以理解和实施，或者是因为它们影响了其他子系统的关键元素。 一些组织在将开发移交给业务合作伙伴或地理位置分散的开发团队之前，需要更详细的规范。 一些团队必须更仔细地指定和记录其体系结构，以满足法规要求。

完善架构机制

有电子书

从作者的博客文章“ 使用Rational Software Architect v8的演化架构 ”下载电子书。

当您的团队需要指定组件的设计时，您可以从定义实现该组件的架构机制开始。

此阶段的目标是定义实现系统的重要需求所需的分析类。 换句话说，您要确定满足特定业务需求所需的所有元素。

为了获得更好的视觉表示，您可以选择将这些类与分析构造型相关联。 使用Boundary原型来表示充当系统接口的类。 使用Control类来描述对其他类进行控制的组件。 使用实体构造型来指定承载数据的类。

这些分析刻板印象的图形表示如图1所示。

图1.分析原型

图2显示了分析刻板印象，因为它被应用于系统的重要需求。 在Yummy Inc.的示例中，订购业务需求涉及几个元素（分析类），例如客户，菜单和付款处理。

图2.订购包的分析元素

确定分析类别后（图2），您可能还需要定义一些重要需求的静态和动态方面。