本文出自于 Rational Edge:本文概述了对 RUP SE 体系架构框架新近的改进,一个对应 IBM
Rational Unified Process,或 RUP 的系统工程插件的必要部件。它解释了在框架的主要组件下面的概念:实例观点和模型等级。
在超过五年的时间里,IBM Rational 客户已经将对应 IBM Rational Unified Process
的系统工程插件 —— 还通称为 RUP SE —— 应用到他们的程序中。在此时间段内我们学到了许多经验并改变了一些插件的关键部分,包括体系结构框架。本文提供一个关于框架的最新观点1,反映出我们通过客户和约发现的正在进行的改进。
RUP SE 体系结构框架为构建可靠的体系结构提供以下支持:
- 关注的分离。设计者可以单独满足每组涉众的关注。
- 关注的集成。通过要求在多个关注集合上使用公共的设计部件集,框架实施集成。
- 系统分解(不同于功能分解)。框架提供允许进行并行开发的结构级别。
表 1 说明了 RUP SE 体系结构框架,按列表示观点且按行表示模型级别(参见工具条“RUP SE 插件的定义”)。
表 1:RUP SE 体系结构框架
模型级别 |
模型视点 |
业务参与者 |
逻辑的 |
信息 |
物理的 |
过程 |
几何的 |
环境 |
角色定义
活动建模 |
UML 产品
环境图
UML 用例
图规范 |
包含扩展产品数据的
UML
企业数据视图 |
领域相关的
视图(例如,电机的 S 极) |
|
领域相关的
视图(例如为交通工具的公路建模) |
分析 |
UML
将系统划分为人、机器
活动
建模及仿真 |
UML 产品逻辑分解 |
产品数据概念模式(IBM
Rational Rose Real-time 或 IBM Rational RequisitePro 中的
UML) |
UML 产品局部视图 |
UML 产品过程视图(静态图) |
参数化的
几何模型
布局 |
设计 |
操作员
指导
帮助文件
工作流和事务管理 |
软件组件设计 |
产品数据方案 |
ECM 设计 |
详细的
过程视图、时序图 |
MCAD 设计 |
实现 |
硬件、软件配置 |
|
重要的是要记得框架是简单的一种描述下面体系结构模型的方法,其仍保留了一个内聚的、一致的存储库。框架中多重的、重叠视图表示该模型的子集。
模型级别是一种用类似的细节级别分组工件的方法。环境级别将整个系统视为一个单一的实体:黑盒子。其不处理系统的内部元素。
在分析级别上,我们开始见到系统的内部元素,在相对高的级别上描述领域元素。根据我们所处视点不同,这些元素进行着变化。例如,在逻辑视点中,我们创建子系统来表示抽象的,高级的功能元素。抽象更少的元素由子系统的子系统或类来表示。在物理视点中,我们创建地点来表示功能分布的位置。
设计级别是我们获取将推动实现的设计决策的地方。在从分析到设计的过程中,我们将子系统或类和位置变换为硬件、软件和工作人员设计。这不是直接的映射,我们正在做出一个关于如何指定子系统和类中表现功能的设计决策。分解成这些设计决策是出于对补充需求和由位置所表示的分布的考虑。结果的设计必须实现所有来自分析级别的规范。换句话说,当我们在分析级别上设计系统时,我们是在创建设计级别必须满足的需求。
实现级别是我们获取有关对于实现技术选择的决策地方。我们可以为内部实现指定商业产品(例如,通信中间件软件产品或者对应一块硬件的模型或零件
#)或者物品。此外,从设计级别到实现级别是一个变换,但此次映射更加直接。对于设计级别的工作人员,是映射到具有规定的技能集合的职业规范。然后,我们可以通过雇佣具有恰当技术集的人(类似于选择具有某些功能的商业产品)或者培训个人以学到所需的技能(类似于进行内部实现)来实现规范。
表 2 描述了框架中表示的模型级别。
表 2:RUP SE 体系结构框架中的模型级别
模型级别 |
表示 |
环境 |
系统黑盒子 —— 换句话说,系统及其参与者 |
分析 |
系统白盒子 —— 形成概念化方法的按照每个视点进行的初始系统划分 |
设计 |
在硬件、软件和人员上的分析级别的实现 |
实现 |
设计模型到具体配置的实现 |
|
视点使框架用户不仅可以分别地处理不同涉众的关注而且还可以维持一个下面设计的完整,一致的表示。我们最初的最小集合的视点随着时间增长了。另外,我们已经证实大多数开发工作不需要每一个视点。实际上,没有有限集合的视点。视点是处理程序涉众需求的机制。每个程序都有一组独特的涉众,且因此有一组独特的适当的视点。我们利用一般的术语(例如那些在框架中确定的)来识别一个类型的视点,而每个视点的具体内容由涉众对特殊开发工作的独特关注所驱动。尽管如此,框架中的视点描述是有用的,因为它们可以使我们概括地谈论方法。
我们还了解到特殊的视点也许不是在所有模型级别上都有用。例如,硬件开发人员是一类(内部的)关心系统内硬件的功能和分布的分配的程序涉众。然而,在分析模型级别上,关于在哪里实现功能的决策
—— 在硬件、软件或工作人员那里 —— 还没有做出。所以在分析级别上就不需要硬件视点。然而,如果系统涉及实际的硬件开发,那么,我们在更具体(低级)的模型级别上就的确需要硬件视点。
表 3 描述了框架中表示的实例视点。
表 3: RUP SE 体系结构框架中的实例视点
视点 |
表示 |
关注 |
协作实体 |
工作人员 |
系统工作人员的任务和责任 |
工作人员活动、人类或系统交互、人的行为规范 |
工作人员 |
逻辑 |
按照那些合作提供所需要行为的
UML 子系统的集合进行的系统逻辑分解 |
- 充足的系统功能以实现用例
- 系统扩展性和可维护性
- 内部复用
- 好的内聚性和连通性
|
子系统 |
物理 |
物理部件的系统和规范的物理分解 |
充足的系统物理特性以存储功能并满足补充需求 |
位置 |
信息 |
系统存储和处理的信息 |
- 充足的系统功能以存储数据
- 充足的系统吞吐量以提供及时地数据访问
|
存储库 |
几何学 |
物理部件之间的空间关系 |
工艺性、可达性 |
组件 |
过程 |
执行计算元素的控制线程 |
对支持并发性及可靠性需求的处理的充足划分 |
过程 |
|
虽然不同的体系结构需要不同的视点集,但是几乎所有的都需要逻辑和物理视点。
根据经验和我们从应用 RUP SE 方法的客户那里收获的反馈,RUP SE 方法还将继续发展改进。RUP SE 体系结构框架发生的重要变化已经使其成为更加有用的在体系结构模型中获取开发工件的机制。虽然框架不可能识别每个程序中所需的独特视点,但是它提供了可以简化个别程序需求的一般化视点描述。
随着我们继续得到参与者的贡献,RUP SE 的内容将更加详细。如果您想要发送建议或反馈,请使用下面的“文章评分”部分的评论框。
1 本文没有讲述 RUP SE 的所有细节或其应用程序。要对功能有更深的了解,请参见 Murray Cantor
的 The Rational Edge 系列:
- 您可以参阅本文在 developerWorks 全球站点上的
英文原文
|