内容


利用 Rational Software Architect 定义应用程序架构,第 1 部分

构想架构

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 利用 Rational Software Architect 定义应用程序架构,第 1 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:利用 Rational Software Architect 定义应用程序架构,第 1 部分

敬请期待该系列的后续内容。

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

简介

有许多种方法都可以提供可定制的最佳实践,帮助企业可靠地提供优质软件。敏捷软件开发是目前的主流,其核心原则之一是采用迭代和增量的方法。本文从一个软件架构师的角度出发,重点介绍一些具体活动,并假定读者精通敏捷实践和迭代开发(有关 IBM agility@scale、IBM Practices、OpenUP 和 Rational Unified Process 的更多信息,请参阅 参考资料 部分)。

本文的主要目的是说明 Rational Software Architect 8(以下简称 RSA)如何有助于架构性思考和记录。RSA 是一个协作式设计平台,可以提供高品质的架构。RSA 帮助您在不同抽象的层次定义模型,在软件工程中可以利用它来支持行业最佳实践。

架构分析:构想和发展架构

架构分析是一组活动,可以构建和完善系统的软件架构。如果反复进行架构分析,这种思考有助于发现和解决在软件开发过程中的问题,无需大量前期的架构工作。架构分析活动对每一个软件密集型系统都很重要。不管教条式的敏捷开发教导员可能会说什么,没有架构分析,就不可能有成功的软件开发。

架构分析发生在两个不同的地方。首先,在项目的开始,它通常被称为迭代 0,或冲刺 0。在此初始迭代过程中,软件架构师希望根据大量已知的需求限制、架构限制、决策和目标来构想架构。架构构想并不是一个漫长而繁琐的活动。根据系统的复杂性,通过有限时间的迭代,完成此构想可能只需要几天甚至几个小时的时间。

作为一个软件架构师,您通常需要按照以下步骤来勾勒出您的软件密集型系统的目标架构:

  1. 确定重要的需求:对架构产生重大影响的关键功能性和非功能性需求
  2. 确定候选架构:基于架构限制和目标的系统高层架构
  3. 定义初始部署模型:表示表该系统的部署节点的拓扑
  4. 定义域模型:关键业务实体和它们之间的关系。

一旦您已经完成初始技术愿景,您就可以在健全的架构基础上构建您的系统。在每次迭代中,开发团队都会发现新的技术挑战和新的改进机会。那些扮演软件架构师角色的专业人员需要作出新的架构决策。这就是持续架构改进是软件密集型系统开发的关键的原因。架构不是那种预先创建、然后撇下不管的东西。架构思考是软件开发的一部分,贯穿项目的始终。

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

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

迭代活动将在本系列的第 2 部分中介绍。

图 1. 迭代和增量架构分析
架构分析,它的任务和活动
架构分析,它的任务和活动

虽然本文不包括审查活动,但任何有经验的从业人员都知道,必须定期验证架构,以验证它与团队的要求和需求是一致的。所以,您需要一个有效的机制来捕获架构,并与不同的利益相关者就架构进行沟通。

使用视图描述架构

用于描述架构的一个成熟的、被广泛采用的方法是,使用了视图和视角。视图是从一组关注或兴趣的视角对整个系统的表示。从利益相关者的视角来看,视图解决系统的所有关键或重要的方面。由于一个系统通常有多个利益相关者,需要若干个视图来概括所有利益相关者的关注事项。

在 1995 年,Philippe Kruchten 提出了一个用于描述软件密集型系统架构的模型:软件架构的 4 +1 视图模型(有关详细信息,请参阅 参考资料)。在“4+1”模式中的大部分概念已包含在开发流程中,如 IBM Rational Unified Process (RUP) 或 OpenUP。最近,IEEE 1471 标准化了视图的定义,以解决一个软件体系结构的多个利益相关者的关注事项(请参见 参考资料 部分,了解有关 IEEE 1471-2000 / ISO 42010 的更多信息)。

在原始“4+1”模型中,使用了五个视图提供系统的全面描述,如图 2 所示。

图 2. 4+1 架构视图模型
所有视图都与 4 加 1 模型中的场景相关
所有视图都与 4 加 1 模型中的场景相关

在“4+1”模型中,每个视图解决一组特定的利益相关者的关注事项,让各利益相关者都能从软件架构中找到他们所需的东西。该模型是可定制的。根据项目的复杂性,您可能只需要建议视图的一个子集。该模型也是可扩展的,所以您可能希望添加其他视图,从不同的视角来形容你的架构。请注意,通常可以将额外的视图折叠成现有视图的子类别。

在表 1 中,每行代表一个视图及其相应的受众、领域和模型。

表 1. 架构视图
视图受众领域模型
逻辑设计人员用例实现分析模型
设计模型
流程集成商性能
可扩展性
并发
部署模型
设计模型
实施程序员软件组件实施模型
部署部署经理物理节点部署模型
场景所有人功能性需求用例模型
用户故事
业务流程
数据
(可选,或作为逻辑视图的一部分)
数据专家
数据管理员
数据持久性数据模型

注:
传统上,流程视图对于应用程序并不是很重要,因为平台在本地处理线程。然而,您可以部署模型中选择记录一些并发问题,也可以在设计模型中记录一些通讯机制(同步和异步)。

准备工作区

在启动 RSA 之前,请确保您已经安装了一套最基本的工具,以支持架构师工作。使用 Installation Manager 验证已选中 “Architect – Standard(架构师 - 标准)” 选项,如图 3 所示。预定义的配置文件支持 UML 和拓扑建模功能,您执行本文中提出的各项任务时需要这些功能。

图 3. 标准架构师配置文件
安装过程中的安装配置文件选项
安装过程中的安装配置文件选项

下一步是创建一个新的工作区。要做到这一点,需要启动 RSA 并指定一个存储目录(图 4)。

图 4. Workspcae Launcher 窗口
启动工具创建一个新的工作区:Yummy2011
启动工具创建一个新的工作区:Yummy2011

RSA 提供了许多不同的透视图来定义 Workbench 窗口中视图的初始设置和布局。在进行下一项工作之前,请确认 Modeling 透视图已打开(图 5)。

图 5. Open Perspective 窗口
Open Perspective 窗口
Open Perspective 窗口

RSA 带有不同的预定义 UML 模型模板。在 Modeling Perspective 中,您可以根据需要添加任意数量的模型,以记录您的系统架构(图 6)。

图 6. UML 模型模板
分析和设计模型模板的列表
分析和设计模型模板的列表

每个模板都专用于一个特定架构目的。通常情况下,定义系统的每个方面(记得“4+1”视图模型),您需要使用 Use-Case、Analysis 和 Design 模型。在本例中,我们还创建了一个架构愿景的草图和一个指定部署目标环境的拓扑。因此,Yummy Inc. 工作区包含以下模型(图 7)。每个模型都基于不同的 RSA 模板。

图 7. 用于描述 Online Catering 系统架构视图的模型
Online catering 模型的树型视图
Online catering 模型的树型视图

请注意,我们可能已决定使用在 RSA 模板中提供的其他类型的模型,如 BPMN 模型(业务流程)或 Services 模型 (SOA)。

现在您的 RSA 工作区已准备就绪,您需要执行我们在前面提到的几项活动。让我们来说明 RSA 如何在架构分析的每一个步骤中帮助您。

构想架构

作为软件架构师,您需要构想最初的架构,并制定指导开发和测试的架构决策。这项工作依赖于在类似系统中收集的经验,以及约束架构和用于架构的问题域。您的结论应该产生可以与团队沟通架构的信息。

确定重要需求

您在架构构想中要完成的首要任务之一就是确定对于架构有重要影响的需求。作为一名架构师,您的职责是确保目标架构是​​适用的,可以满足用户需求。因此,您需要检查用例、业务流程或用户信息,确定那些对架构可能产生重大影响的需求。经验丰富的架构师通常会与项目经理或产品所有者密切合作,向他们灌输产品库中各项目对架构的影响。他们会影响产品库的优先顺序,从而尽快解决技术上的不确定性。

在 RSA 中,Use-case 模型包括 Yummy Inc. 的已确定需求(图 8)。

图 8. Online Catering 系统的需求
Ordering Menus 需求包及其元素

确定重要需求并没有通用的规则。具体操作取决于您的环境、技术框架和项目团队。某个团队认为对架构有巨大影响的需求对于另一个团队而言可能是微不足道的需求。要求显示一个简单的项目列表的需求对架构的影响可能不是很大。但是,如果该需求是通过一个异步服务调用来获得业务合作伙伴的项目,那么您就必须确保您的架构中有支持该需求的管道。

在我们的 Yummy Inc. 示例中,模型分为多个面向功能的包。每个包中都含有相关的用例和操作员(跨领域操作员被划分到多功能包中)。通过用例图说明需求(图 9)。当然,在业务流程图或用户故事中,可能已捕获了相同的信息。

图 9. Order Menus(菜单)用例图
菜单用例及相关的操作员
菜单用例及相关的操作员

定义候选架构

确定重要需求后,软件架构师要创建一个架构概述。如今,我们很少从头开始开发系统。我们丰富了现有的应用程序,将遗留的系统现代化,并重用和组装资产。架构师可以利用过去在类似系统方面的经验,确保能够同时考虑到目标和约束。候选架构既会考虑系统的功能性需求(用例、故事、业务流程),也会考虑系统的非功能性需求(可用性、性能、可扩展性等等)。

在我们的示例中,我们已经选择了一个 N 层架构(图 10),架构中的应用程序是基于 Web 的,可以通过 Web 服务从不同类型的客户端访问它(有关多层应用程序的更多信息,请参阅 参考资料

请注意,技术图(图 10)是在 RSA 中创建的,在该阶段完成此创建非常简单,在很短的头脑风暴会议中就能完成。该图显示了所涉及的主要组件,以及已确定的开发解决方案的技术堆栈。

图 10. Online Catering 系统的 N 层架构草图
Yummy Inc. Online Catering 应用程序的草图
Yummy Inc. Online Catering 应用程序的草图

图 10 的大图

定义初始部署模型

使用之前勾勒的架构概述,软件架构师现在可以画出部署模型的全图。它描述主要软件和硬件组件,以及它们在高层次如何互动。部署图考虑到部署环境的约束,并且是开发团队和基础加构团队之间良好的通信工具,可以实现两者之间的信息共享。

UML 规范提供了一组定义部署模型的元素。然而,UML 的部署部分已证明是功能有限的。因此,它没有得到行业的广泛采用,即使在密集型 UML 用户中也是如此。RSA 提供了大量的工具集来定义部署拓扑(逻辑、物理和部署实例)。RSA 拓扑非常强大,UML 部署模型则在以下方面显得有所不足:简单性、重用性和可追溯性(有关部署拓扑的更多信息,请参见 参考资源)。

部署图(图 11)显示了托管应用程序所需的不同硬件组件。RSA 自带了一些图库,可以使您的图表更有意义,它还允许您添加自己的图像来表示特定的模型元素。

图 11. Online Catering 系统的部署节点
Online Catering 应用程序的部署节点
Online Catering 应用程序的部署节点

图 11 的大图

定义域模型

对于业务应用程序而言,初始域模型可以帮助开发团队了解关键业务实体和它们之间的关系。软件架构师可以从功能性需求、用户素材或业务流程等各种来源获取信息。

在 RSA 中,有一种简单的方法可以捕获业务实体,那就是利用分析配置文件。此配置文件包含您可以应用于 UML 元素中的三个构造原型(图 12)。

图 12. UML 构造原型 (stereotype)
分析构造原型的三种可视化表示

Boundary 构造原型用于表示一个充当系统接口的类。Control 类描述一个执行对其他类的控制的组件。Entity 构造原型指定承载数据的类。

在这个阶段,您只需关心数据,所以只使用实体构造原型即可。重要的是,要捕获将实现的系统的所有词汇。这是下一步将要创建的 Analysis Model 的出发点。

由 RSA 提供的 Analysis Model 模板已预先架构好,并自带一个名为 Perspective overviews 的特殊包,用于收集与关键概念相关的信息(图 13)。

图 13. Online Catering 系统的 Perspective overviews
在线餐饮应用程序的分析包

作为软件架构师,您可以使用一个简单的类图(含关键业务实体)来捕获使用分析构造原型的域模型的第一稿(图 14)。

图 14. Online Catering 的域模型
在线餐饮域元素及其关系
在线餐饮域元素及其关系

还有其他可用来在 RSA 中定义域模型的选项。首先,您可以选择创建一个简单的草图来表示业务实体(图 15)。

图 15. Online Catering 的域模型草图
描述 Online Catering 域模型的简单草图
描述 Online Catering 域模型的简单草图

在 RSA 中,当您需要更正式的表示法时,可以将草图元素转换为 UML 元素,并且可以在生成的 UML 和初始草图之间保持可追溯性。另一个选项是创建一个数据图。在 RSA 中,您可以在一个图中创建表、列和键来表示您的数据,也可以连接到您的数据库,导入现有的架构。选择使用哪个选项来定义您的域模型其实取决于您的环境和项目团队的工作方式。不可能有完美的解决方案,但肯定有一个最适合您的解决方案。

结束语

在这个阶段,您已经为您的软件密集型系统架构定义了愿景。您应该了解哪些视图对利益相关者是有用的,确定对技术解决方案有重大影响的需求,然后据此勾勒出目标架构。在很短的时间内(迭代 0),您就可以在 RSA 中捕获与技术、部署和域模型相关的关键信息。

本系列的第 2 部分 中,您将看到如何使用 RSA ​​来优化您的软件密集型系统的架构。


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=800750
ArticleTitle=利用 Rational Software Architect 定义应用程序架构,第 1 部分: 构想架构
publish-date=03052012