利用 Rational Software Architect 定义应用程序架构,第 2 部分: 迭代优化架构

本系列介绍了创建模型的技术,这些模型有助于指定和沟通软件密集型系统的架构。本系列展示了一个虚构公司 Yummy Inc. 的 Online Catering 架构的拟定。使用迭代的方法,它描述了在使用 IBM® Rational® Software Architect 来指定软件密集型系统时所必需的关键架构活动。在该系列的第 1 部分中,我们将重点放在勾勒架构以及根据开发需求调整技术愿景的典型任务。第 2 部分将介绍如何使用 Rational Software Architect 对架构进行迭代优化。这两篇文章都假定读者熟悉基于迭代开发的方法。

Jean-Louis Marechaux, 软件工程师, IBM

Jean-Louis Marechaux 的照片Jean-Louis Maréchaux 是加拿大 IBM Rational 的软件工程师,他的主要兴趣包括软件架构、Java EE 技术、SOA 和 Agile 软件开发实践。他过去发表过多篇有关这几个主题的文章,并在 2010 年与人合著了 Practical Guide to Distributed Scrum。在加入 Rational 部门之前,Jean-Louis 是 IBM Global Services 部门及其他 IT 组织的 IT 架构师,他在那里参与了应用程序的架构和设计工作。



2012 年 3 月 09 日

下载 Rational® Software Architect 试用版  |  在线试用 Rational® System Architect
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

架构构想是一个灵活的最佳实践,可以概述用于指导软件密集型系统的开发和测试的技术决策。软件架构师通常使用以下步骤来勾勒软件密集型系统的目标架构(请访问本系列第 1 部分,参阅 参考资料 部分):

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

但架构思考并不是一次性的活动。它是经验丰富的敏捷团队融入其开发工作的一项持续性工作。在您的团队逐步构建系统的过程中,您会发现新的技术挑战,并制定出新的架构决策。

以下架构活动通常在开发迭代过程中执行:

  1. 优化架构机制:可以满足在第一步中确定的架构性重要需求的技术概念。
  2. 优化设计元素:架构性重要设计元素
  3. 优化部署架构:部署单元和拓扑

以迭代的方式优化架构

像我们了解的那样,通常您并不需要为系统的所有部分指定设计。就像项目中的其他部分一样,只有某项工作会为您带来价值时,您才会执行它。但软件密集型系统的某些部分必须比其他部分指定得更详细。这可能是因为某些组件非常难以理解和实现,或者因为它们影响了其他子系统的关键元素。有些组织需要制定更详细的规定,然后才能将开发转交给业务合作伙伴或地理分布的开发团队。有些团队必须更仔细地指定并记录他们的架构,以满足合规要求。

优化架构机制

可用的电子书

从作者的博客文章下载电子书 "Evolutionary architecture with Rational Software Architect v8"。

如果您的团队需要指定一个组件的设计,那么您可以从定义架构机制开始实现该目的。

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

为了获得更好的可视化表示,可以选择将这些类与一个分析构造原型 (stereotype) 相关联。使用 Boundary 构造原型来代表一个类,作为系统的接口。使用 Control 类描述一个组件,执行对其他类的控制。使用 Entity 构造原型指定承载数据的类。

这些分析构造原型的图形表示如图 1 所示。

图 1. 分析构造原型
三个不同的分析构造原型

图 2 显示的分析构造原型适用于系统的一个重要需求。在 Yummy Inc. 的示例中,订单业务涉及一些元素(分析类),如顾客、菜单和支付处理。

图 2. 订单包的分析元素
以树型视图显示的 Ordering 包及其元素

在确定分析类(参见图 2)之后,您可能还需要定义某些重要需求的静态和动态方面。

这一步的目的是,为每个重要场景定义其静态和动态两个方面。Rational Software Architect 通过提供一个用例实现模板来帮助架构师完成这项任务。

默认自带的模板(图 3)有一个记录静态方面 (Participants) 的类图,以及记录动态行为的一组序列图(Basic Flow、Alternative Flow 等等)。

图 3. Order Menus 功能的用例实现模板
Order Menus 包

每个图分别解决组件的一个不同方面。类图(图 4)描述在用例实现(动态)中所涉及的所有类,而序列图(图 5)则说明它们之间的交互(动态)。

图 4. Order Menus 功能的类图
类和关系
图 5. Order Menus 功能的序列图
菜单的操作流

在结束此步骤时,您已利用 UML 模型开发了系统的一些重要需求实现。当您需要描述软件密集型系统的静态结构和某些组件的行为时,这是架构中的一个重要组成部分。

由于 Design Model 仍然是与技术无关的,所以您可以将它重用为多种实现的起点。

优化 Design Model

当您定义好您想如何在分析模型中实现重要需求之后,就可以深入研究组件的具体设计了。

虽然 Design Model 是抽象的,但 Design Model 必须更接近于实际实现。软件架构师通常需要确定与实现解决方案所用的技术相关的一套目标和约束。Design Model 通常不是从头开始开发的,而是从您已经定义的分析模型演变而来(参见图 2 和图 3)。

在我们的示例中,Yummy Inc. Online Catering 是使用 Java EE 平台开发的。数据持久性利用了 Java Persistence API(参见 参考资料),应用程序逻辑通过 Session Beans 实现,而交付服务的访问则通过 Web 服务实现。

在架构和设计中,广泛采用的最佳实践是:定义解决方案的不同层次,以及它们如何相互关联。Java EE 的 n 层架构在各层次之间促进了关注点的分离。

在 Rational Software Architect 的 Architectural Layers 透视图中,设计模板提供了一个视图,供您定义层与层之间的依赖关系(图 6)。

图 6. Online Catering 系统的 Architectural Layer Dependencies 视图
Online Catering 应用程序的层次

利用已定义的架构层次,软件架构师可以生成设计的第一次迭代。Rational Software Architect 设计模板为该活动提供了一个预定义的结构。组件规范通常包含用来与组件进行交互的接口和数据(图 7)。它通常是软件架构师需要定义的第一个方面的内容。对于每个组件而言,需要指定它操纵的数据和接口(包括可用的操作),这是很重要的。

图 7. Online Catering 系统的设计包
属性和操作

请注意,因为在这个阶段已选定实现平台,所以我们可通过特定技术信息来丰富设计模型。在我们的示例中,持久性对象都标有一个JPA 构造原型,用于确定如何将对象模型映射到数据库。

对于软件密集型系统的某些组件,您可能会更详细地指定设计。请记住,只有在可以帮助您的团队实现和交付应用程序的情况下,才可以在设计中添加细节。在图 8 中,已针对特定目标创建了详细的类图。团队希望使用由 Rational Software Architect 提供的一些转换,根据设计模型生成 Java 代码(有关转换的更多信息,请参阅 参考资料 )。

图 8. 用于代码生成的一些详细的类图
支持代码生成的构造原型

为某些组件创建具体设计并不总是软件架构师的责任。根据项目团队的规模和技能,可以相应地将软件设计师承担的任务分配给一个或多个不同的人,如高级开发人员(架构、设计和开发之间的界限有时并不那么清晰)。

优化部署架构

架构师负责建立满足业务需求的系统。软件密集型系统的重要方面之一是,如何在物理架构上部署它们。初始部署模型通常是在构想架构时定义的(请参阅 参考资料 部分,访问本系列第 1 部分)。随着项目的进展,架构师会优化部署架构,以整合与生产环境相关的非功能性需求和约束。

利用 Rational Software Architect 的部署规划工具,您可以创建拓扑来显示信息技术资源之间的关系。您还可以规划和验证部署场景(有关利用 Rational Software Architect 实现部署规划和自动化的更多信息,请参阅 参考资料 部分)。

Rational Software Architect 有助于在抽象的不同层次实现部署分析。您可以创建逻辑拓扑,从而捕获与软件密集型系统的运作架构有关的决策(图 9)。在逻辑拓扑中,您可以高度抽象地描述某个系统。您可以指定如何组织和连接应用程序的组件,将它们放置和托管在哪个地方。请注意,代表解决方案的单元并不总是从头开始创建的,而是从 UML 元素派生的,以便可以实现更好的可追溯性。

图 9. Online Catering 系统的逻辑拓朴示例
位置和节点

图 9 的大图

架构师也可以定义一个拓扑来描述如何部署应用程序。这种类型的模型描述了应用程序的具体、完整的部署实例,以及部署应用程序的相应具体基础架构(图 10)。

图 10. Online Catering 系统的详细部署模型示例
组件和服务器

图 10 的大图


以递增的方式构建系统

致力于交付软件密集型系统的团队必须始终牢记,可用的软件是进度的首要衡量标准。开发应用程序所需的活动已经超出了本文的范围,但您需要重点记住的是,成功的团队都将架构和设计融入了其开发工作中。

持续的架构思考是开发工作的一部分,如果没有考虑到变更对整个应用程序所产生的影响,那么团队不应该编写新的代码,亦不应该修改现有的代码。修改现有代码的一项流行技术称为重构(有关重构的更多信息,请参阅 参考资料)。Rational Software Architect 中提供了大量的工具集,有助于代码的开发和重构。您可以使用重构协助,改变代码的结构(图 11)。您还可以使用架构发现功能来确定应用程序代码中的模式和反模式(图 12)。这两种特性都可以帮助您编写更好的代码,并在软件开发的早期阶段发现问题。

图 11. Rational Software Architect 中的重构协助
重构菜单和重构选项
图 12. 确定模式
不同的架构发现选项

如果您已经在架构思考活动中创建了一些模型,那么您也可以决定是否将它们转换成代码。Rational Software Architect 自带了一组转换,可使用它们生成 Java 代码、Java EE 元素或 SOA 构件(参见图 13)。您还可以从现有的源代码中生成模型。

图 13. Rational Software Architect 中的转换
不同的转换选项

在您以递增方式构建系统的过程中,您将创建一些可用的软件,这些软件应符合在架构思考活动期间制定的设计决策。


结束语

敏捷方法促进了用来逐步构建系统的短迭代的采用。虽然主要在瀑布模型中采用的 Big Design Up Front(请参见 参考资源 了解有关 BDUF 的信息)已被证明是一个低效的方法,但这并不意味着必须在敏捷项目中禁止架构和设计活动。设计必须是有意识的和紧急的。说设计是有意识的,是因为在项目开始时,需要根据产品库预测一些技术需求(架构构想)。而说设计是紧急的,则是因为在开发迭代过程中,您会根据团队发现的新技术挑战来调整和丰富设计。

在本系列的 利用 Rational Software Architect 定义应用程序架构,第 1 部分:构想架构 中,我们将重点放在概括架构以及根据开发需求调整技术愿景的典型任务上。在第 2 部分,我们介绍了在开发迭代中如何优化架构。Rational Software Architect 为整个项目生命周期提供了模型模板,从不同的视角指定软件密集型系统的架构(图 14)

图 14. 适用于各种架构视图的模型
架构视图及相应的模型

架构思考是经验丰富的敏捷团队在其开发工作中进行的一项持续性工作。它并不总是产生正式的图表。请记住,在您的环境中,如果 UML 不是正确的方法,那么没有什么能够阻止您改用 Rational Software Architect 草图,就像您在白板上进行操作一样。与 UML 图相比,Rational Software Architect 草图没那么正式,但对于特定项目,它们可能是一个不错的选择。


下载

描述名字大小
Yummy RSA 模型Yummy2011.zip84KB

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=807898
ArticleTitle=利用 Rational Software Architect 定义应用程序架构,第 2 部分: 迭代优化架构
publish-date=03092012