IBM Rational 架构管理软件模型结构指南

您组织模型内容的方式,以及构成模型的存储的方式是建模实践成功与否的最大的决定因素。在本系列文章中,您将了解到,在将这些内容应用于基于 IBM® Rational® Eclipse® 的 UML 建模产品时,与这些内容相关的术语、概念、原则和最佳实践。以及对于与许多建模方法(例如,传统的 IBM® Rational® Unified Process(RUP®)、用于面向服务的架构(service-oriented architecture,SOA)的业务驱动的开发,及模型驱动的系统开发(Model Driven Systems Development)相应的模型内容和组织的建议。

本文(包含英文及其他语言)是专门为支持使用 Rational Software Architect (RSA) 产品,并且对 Rational 统一过程(Rational Unified Process,RUP)中的 RSA 使用指导感兴趣的用户准备的。如果您使用的是 Rational Software Modeler (RSM),您同样也能在本文中找到有用的内容,不过需要注意部分内容只反映在 RSA 中才能使用,而在 RSM 中不能使用的功能。

关于本系列

这些模型结构指南包括四篇文章:

  • 第 1 部分 介绍了不针对任何一个建模风格的基本信息,并且还着重于考虑构造支持团队建模工作的模型。
  • 第 2 部分 提供了针对传统的 IBM® Rational Unified Process®(RUP®)建模风格的指导。
  • 第 3 部分(尚未发表)提供了针对用于 SOA(面向服务的架构)的业务驱动的架构(在本系列中有时称为 BDD4SOA)的建模风格的指导。
  • 第 4 部分(尚未发表)提供了针对模型驱动的系统开发(Model Driven Systems Development,MDSD)的建模风格的指导。

预期的读者

这些模型结构指南主要面向支持统一建模语言 2.0(UML 2)建模的 IBM ®Rational® 产品的用户。在本文出版时,那些产品包括 IBM ®Rational® Software Architect、IBM® Rational® Systems Developer 和 IBM® Rational® Software Modeler。在这些指南中,我们将把这样的产品共同称为“在讨论的产品”或者简单地称为“软件”。这些指南主要着重于与创建一组新模型,或者重构现有的一组模型相关的问题。

次要的读者是那些使用 IBM® Rational® Rose 或 IBM® Rational® XDE,并计划将那些模型移植到在讨论的产品上的人。这类读者可能会发现这些指导在重构所导入的模型,或者在导入模型之前重构 Rational Rose 或 Rational XDE 模型方面有帮助。

注意:
如果您使用 Rational Software Modeler,您将会觉得本文有用,但一些部分只反映 Rational Software Architect 和 Rational Systems Developer 中的功能。

范围和目的

本系列中的指导介绍了许多如何组织概念性的 UML Model 工件和内容的东西。它还提供了关于那些工件的内部组织结构的具体指南,并且介绍了这三个基本的建模方法:

  • 传统的 IBM® Rational Unified Process®(RUP®),或非正式的简称 C-RUP
  • 用于 SOA(面向服务的架构)的业务驱动的开发,有时候称为 BDD4SOA
  • 模型驱动的系统开发(Model Driven Systems Development,MDSD)

本系列中的指南无意限制您的思维。它们意图帮助您了解如何使用软件的功能来简化对您最好的过程。这些文章中介绍的模型结构是指南,不是强制的。举例来说,不论您是否决定遵照传统的 RUP 建模风格,BDD4SOA 风格,或另一个风格是您必须决定的。更详细地说,不论您是否选择在任意那些方法中构建一个特别的模型,这也应该是对您自己的开发过程的考虑。它们可以(可能应该)是具体项目的决策,或相反,是企业宽度的决策。另外,请您认识到 RUP 本身不是一组严格的过程规则。它是一个过程框架,您可以在其中制定过程定义,这些定义从非常正式的,或“重型的”,到非常灵活的,或“轻量的”。

您对于如何使用 UML Modeling 的选择也可以从非常正式的到非常不正式的。您可能选择将您的模型视为在构建阶段要严格遵守的正式的架构图。或者您可能将您的模型视为提出设计概要的示意图,但在将工程付诸实现时就是一次性的。在讨论的产品可以支持您到任一这些过程和建模工作的末尾。它们还能够让模型不仅成为蓝图,而且还能作为自动生成实现的重要部分时所参照的规范。这种基于模式的工程(Patterns-Based Engineering,PBE)方法涉及使用模型到模型和模型到代码的转换。PBE 可以引入关于模型结构的特殊关注。

注意:
对于转换的设计常常是期望作为输入的 UML 模型可以符合特殊的 UML 语法或“文法”。由于使用了 UML 概要文件和定制的约束条件而实施这样的文法,—— 实际上,使用基于 UML 的专用领域的语言 —— 但它还只是内部发布的一组风格上的协定。如果您要使用模型和转换来练习 PBE,那么使用搜索项,例如 patternstransformations 在 IBM ® developerWorks ® 上的 Architecture 架构专区 上寻找关于 Rational PBE 的参考资料。

最后,本系列是模型的组织的指导,不是开发模型的详细内容的指导。要了解关于开发 Rational 模型的内容的具体工具的技术,请查看其他参考资料:

  • 产品文档(教程、示例,内带的帮助)
  • RUP 配置中的工具顾问
  • 与 Rational 相关的参考资料,参见 IBM developerWorks

必备知识

第 1 部分针对那些不熟悉建模概念的人。一些段落假设您已经熟悉一般的团队开发的概念和问题。其他段落假设您熟悉具体的软件配置管理(software configuration management,SCM)解决方案,但再说一次,这些讨论是针对那些还不具备这些知识的人。

第 2、3,和 4 部分假设您对统一建模语言(Unified Modeling Language,UML)有一定了解。如果您熟悉 表 1 中罗列的 UML 2 的元素,那么理解那些部分应该不会有什么困难。这些部分还假设您熟悉在讨论的产品的一些基本的操作概念。如果您不了解,那么您可以通过阅读那些产品的“Welcome”页中的“Overview”部分(特别是标题为“Different modeling approaches for different process philosophies”的 Welcome 小册子)来获得足够的背景知识。如果您原来了解 Rational Rose 或 Rational XDE,那么阅读 developerWorks 上的名为“The New IBM Rational Design and Construction Products for Rational Rose and Rational XDE Users”(参见 参考资料)的文章也是有帮助的。

表 1. UML 2 元素
图类型通常与此类型的图相关的语义元素
用例参与者,用例
类,接口,协作
组件组件、子系统、端口、提供和所需的接口的概念
活动活动、划分、控制流、对象流、动作节点(Initial、Final、Action、Accept Event)、控制节点(Fork、Merge、Decision)、对象节点(Central Buffer、Object、Data Store)、和插脚(Input、Output、Value)
序列、通信
部署节点、工件、通信路径
组合结构部件、端口、连接件
状态机不需要详细的知识
多样的关联、依赖性、泛化、角色

排版上的约定

可能令那些从 IBM® Rational® Rose 或 IBM® Rational® XDE 转移过来的读者感兴趣的讨论在边栏中强调出来。

这些文章一贯地将 UML 元模型中定义的元素类型的名称大写(例如,Package、Component,或 Class),从而将它们与那些术语的各种普通含义区别开来。

注意:对于 Rational Software Architect Version 6 的用户来说,相应较早的 V6 的文章(英语和其它语言)也可下载到。如果您是 Rational Software Modeler V6 的用户,那么您也会发现文章是有用的,但应该知道,一些部分反映了只在 Rational Software Architect 而不在 Rational Software Modeler 中的功能。


相关主题

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=318267
SummaryTitle=IBM Rational 架构管理软件模型结构指南
publish-date=07032008