des迭代结构_第2部分：迭代完善体系结构
使用Rational Software Architect定义应用程序架构
内容系列：
此内容是＃在系列的一部分＃： 定义使用Rational Software Architect应用架构
该内容是该系列的一部分： 使用Rational Software Architect定义应用程序体系结构
请继续关注本系列中的其他内容。
构架构想是一种敏捷的最佳实践，概述了指导软件密集型系统的开发和测试的技术决策。 软件架构师通常使用以下步骤来概述软件密集型系统的目标体系结构（请参阅参考资料部分以访问本系列的第1部分）：
- 确定重大要求
- 定义候选架构
- 定义初始部署模型
- 定义领域模型
但是架构思考不是一次性的活动。 经验丰富的敏捷团队将其整合到他们的开发工作中是一项持续的工作。 随着团队逐步构建系统，您将发现新的技术挑战，并且需要做出新的体系结构决策。
通常在开发迭代期间执行以下架构活动：
- 完善体系结构机制：满足第一步中确定的对体系结构有重要要求的技术概念。
- 完善设计元素：具有建筑意义的设计元素
- 完善部署架构：部署单元和拓扑
反复完善架构
请了解，通常不需要为系统的所有部分指定设计。 就像项目中的所有其他内容一样，只有在它带来一些价值的情况下，您才进行操作。 但是，软件密集型系统的某些部分必须比其他部分更详细地指定。 可能是因为某些组件更难以理解和实施，或者是因为它们影响了其他子系统的关键元素。 一些组织在将开发移交给业务合作伙伴或地理位置分散的开发团队之前，需要更详细的规范。 一些团队必须更仔细地指定和记录其体系结构，以满足法规要求。
完善架构机制
当您的团队需要指定组件的设计时，您可以从定义实现该组件的架构机制开始。
此阶段的目标是定义实现系统的重要需求所需的分析类。 换句话说，您要确定满足特定业务需求所需的所有元素。
为了获得更好的视觉表示，您可以选择将这些类与分析构造型相关联。 使用Boundary原型来表示充当系统接口的类。 使用Control类来描述对其他类进行控制的组件。 使用实体构造型来指定承载数据的类。
这些分析刻板印象的图形表示如图1所示。
图1.分析原型
图2显示了分析刻板印象，因为它被应用于系统的重要需求。 在Yummy Inc.的示例中，订购业务需求涉及几个元素（分析类），例如客户，菜单和付款处理。
图2.订购包的分析元素
确定分析类别后（图2），您可能还需要定义一些重要需求的静态和动态方面。
然后，对于每个重要场景，此步骤的目的是定义其静态和动态方面。 Rational Software Architect通过提供用例实现模板来帮助架构师完成此任务。
默认情况下，模板（图3）带有用于记录静态方面的类图（参与者）和用于动态行为的一组序列图（基本流，替代流n…）。
图3. Order Menus功能的用例实现模板
每个图都针对组件的不同方面。 类图（图4）描述了用例实现中涉及的所有类（动态），而序列图（图5）则说明了它们之间的交互（动态）。
图4. Order Menus功能的类图
图5. Order Menus功能的序列图
在此步骤的最后，您已经使用UML模型开发了一些重要的系统需求实现。 当您需要描述软件密集型系统的静态结构和某些组件的行为时，它是体系结构的重要组成部分。
由于分析模型仍然与技术无关，因此您可以将其用作几个实现的起点。
完善设计模型
在定义了如何实现分析模型中的重要需求之后，您就可以开始研究组件的具体设计了。
虽然分析模型是抽象的，但设计模型必须更接近实际的实现。 软件架构师通常会确定与用于实施解决方案的技术相关的一组目标和约束。 设计模型通常不是从头开始开发的。 它是您已经定义的分析模型的演变（图2和图3）。
在我们的示例中，Yummy Inc.在线餐饮是使用Java EE平台开发的。 数据持久性利用Java Persistence API（请参阅参考资料 ），使用会话Bean实现应用程序逻辑，并通过Web服务完成对交付服务的访问。
在体系结构和设计中，被广泛采用的最佳实践是定义解决方案的不同层以及它们之间的相互关系。 Java EE n层体系结构鼓励各层之间的关注点分离。
在Rational Software Architect的Architecture Layers透视图中，设计模板提供了一个视图，您可以在其中定义各层之间的依赖关系（图6）。
图6.在线餐饮系统的体系结构层依赖关系视图
定义了架构层后，软件架构师将生成设计的第一个迭代。 Rational Software Architect设计模板为该活动提供了预定义的结构。 组件规范通常包含用于与组件交互的接口和数据（图7）。 通常，这是软件架构师定义的第一个方面。 对于每个组件，指定其操作的数据及其接口（包括可用的操作）非常重要。
图7.在线餐饮系统的设计包
请注意，由于在此阶段已经选择了实现平台，因此可以使用特定于技术的信息来丰富设计模型。 在我们的示例中，持久性对象用JPA构造型标记，以标识对象模型如何映射到数据库。
对于软件密集型系统的某些组件，您可能决定进一步指定设计。 请记住，只有在设计可以帮助您的团队实施和交付应用程序时，才将细节添加到设计中。 在图8中，已经创建了详细的类图，并牢记了特定的目标。 团队希望使用Rational Software Architect提供的一些转换从设计模型中生成Java代码（有关转换的更多信息，请参阅参考资料 ）。
图8.代码生成的详细类图
为某些组件创建详细设计并不总是软件架构师的职责。 根据项目团队的规模和技能，可以将软件设计者角色分配给一个或多个不同的人，例如高级开发人员（架构，设计和开发之间的界限有时不清楚）。
完善部署架构
架构师负责创建满足业务需求的系统。 软件密集型系统的一个关键方面是如何将它们部署在物理体系结构上。 通常，在构想架构时会定义初始部署模型（请参阅参考资料部分，以访问本系列的第1部分）。 随着项目的进行，架构师会优化部署架构，以合并非功能性需求和与生产环境相关的约束。
使用Rational Software Architect部署计划工具，您可以创建拓扑来显示信息技术资源之间的关系。 您还可以计划和验证部署方案（请参阅参考资料部分，以获得有关使用Rational Software Architect进行部署计划和自动化的更多信息）。
Rational Software Architect帮助实现不同抽象级别的部署分析。 您可以创建逻辑拓扑，以在其中捕获有关软件密集型系统的操作体系结构的决策（图9）。 在逻辑拓扑中，您以高度抽象的角度描述了系统。 您可以指定应用程序组件的组织和连接方式，以及它们的放置和托管位置。 请注意，代表解决方案的单位并非总是从头开始创建，而是从UML元素派生而来，以实现更好的可追溯性。
图9. Online Catering系统的逻辑拓扑示例
架构师还可以定义拓扑以描述应用程序的部署方式。 这种类型的模型描述了应用程序的特定，完整的部署实例以及在其上部署该应用程序的特定基础结构（图10）。
图10. Online Catering系统的详细部署模型示例
逐步建立系统
致力于交付软件密集型系统的团队必须始终牢记，工作软件是进度的主要衡量标准。 开发应用程序所需的活动不在本文的讨论范围之内，但重要的是要记住，成功的团队将架构和设计集成到了他们的开发工作中。
持续的架构思想是开发工作的一部分，团队不应在不考虑更改将如何影响整个应用程序的情况下编写新代码或修改现有代码。 修改现有的代码，一个流行的技术被称为重构（见相关主题关于重构以获得更多信息）。 Rational Software Architect提供了一组丰富的工具来促进代码开发和重构。 您可以使用重构辅助来更改代码的结构（图11）。 您还可以使用体系结构发现功能来识别应用程序代码中的模式和反模式（图12）。 这两个功能都可以帮助您编写更好的代码并在软件开发的早期阶段发现问题。
图11. Rational Software Architect中的重构帮助
图12.识别模式
如果您在架构思考活动中创建了一些模型，则还可以决定将其转换为代码。 Rational Software Architect附带了一组转换以生成Java代码，Java EE元素或SOA构件（图13）。 您还可以从现有源代码生成模型。
图13. Rational Software Architect中的转换
在逐步构建系统时，您将创建符合在体系结构思考活动期间做出的设计决策的工作软件。
Summary
敏捷方法论促进采用短迭代来逐步构建系统。 如果“大型设计”（参见BDUF的相关主题 ）已被证明是瀑布模型中普遍采用的一种无效方法，那么这并不意味着必须在敏捷项目中禁止架构和设计活动。 设计必须是故意的和紧急的。 这样做是有意的，因为在项目开始时，您会根据产品积压（架构设想）来预期一些技术需求。 之所以出现，是因为在开发迭代期间，您会根据团队发现的新技术挑战来适应和丰富设计。
在本系列的第1部分中，我们集中于典型任务，概述了体系结构，并使技术愿景与开发需求保持一致。 在第二部分中，我们描述了在开发迭代期间如何完善体系结构。 在整个项目生命周期中，Rational Software Architect提供了模型模板，以从不同的角度指定软件密集型系统的体系结构（图14）。
图14.各种架构视图的模型
架构思维是不断的努力，经验丰富的敏捷团队将其整合到他们的开发工作中。 它并不总是导致形式图。 请记住，如果UML在您的上下文中不是正确的方法，那么没有什么会像使用白板那样阻止您使用Rational Software Architect草图。 Rational Software Architect草图不像UML图表那么正式，但是对于您的特定项目，它们可能是不错的选择。