IBM Rational 架构管理软件模型结构指南,第 2 部分: 经典的 Rational 统一过程

本文面向那些有兴趣将传统的 IBM® Rational Unified Process® (RUP®)中总结出来的建模指导方针应用到 IBM® Rational® Software Modeler、IBM® Rational® Systems Developer 或者 IBM® Rational® 中的用户。您将掌握这些产品是如何对 RUP 定义的模型类型进行支持的;用于模型组织和团队建模的 RUP 建模风格的执行;以及 RUP、用例、分析和设计模型的业务价值、组织和内容。

Bill Smith (smithtw@us.ibm.com), Rational 产品经理, 模型驱动开发, IBM 

Bill Smith 是 IBM Rational 中的 Architecture Management 产品线的一名产品经理。他一直活跃于软件开发和建模领域长达二十五年,过去的七年是在 Rational。



2008 年 7 月 03 日

关于本文

本文描述了如何表现 IBM® Rational Unified Process® (IBM® Rational® Software Modeler、IBM® Rational® Systems Developer 或者 IBM® Rational® Software Architect 中的 RUP® 模型产品,今后将其简称为“讨论所涉及的产品”或者“该软件”)。本文还为那些产品的一个子集的内部组织结构提供了指导方针。为了帮助您理解您所购买的产品,它还尝试解释每一种产品的业务价值,但是,它并不试图进行如下工作:

  • 重新叙述产品的概念上的基础;
  • 提供对它们的扩展描述;
  • 描述过程和技术,用来指定它们的详细语义或者图内容。

本文中的各小节涵盖以下这些主题:

  • 讨论所设计的产品是如何为 RUP 所定义的模型类型提供支持的;
  • 用于模型组织和团队建模的 RUP 建模风格的执行;
  • 哪些东西值得建模;
  • 以下三种 RUP 模型的业务模型、组织和内容:
    • 用例模型(解决方案)
    • 分析模型(解决方案)
    • 设计模型

目标读者群

本文(系列文章的第 2 部分)面向那些有兴趣将经典的 Rational 统一过程中总结出来的建模指导方针应用到讨论所涉及的产品之中的读者。

注释:
这一用于模型组织的面向 RUP 的、用例驱动的方法并不是唯一有用的方法。模型结构指导方针也在不断发展,它用于面向模型组织的 SOA (面向对象的体系结构)风格的业务驱动的开发(有时也被称为 BDD4SOA),以及模型驱动系统开发(即面向 MDSD 的 RUP)。

经典的 RUP 模型结构指导方针

在若干年前 IBM 收购 Rational Software 之时,它就开启了将 RUP 向其他 IBM 过程框架靠拢的进程,并且考虑到诸如 SOA 和业务过程建模的出现对 RUP 进行了扩展。在那之前,由 Rational 统一过程(Terry Quatrani、Jim Conallen、Eric Naiburg、Robert Maksimchuck 等撰写书籍对这一概念进行了详细阐述)所提供的建模指导方针保持了相当长时间的稳定性。这一指导方针描述了一组模型,诸如:用例模型、分析模型和设计模型,它们表现了系统的问题和解决方案域上良好定义的透视图。这种方法偏离了用例是首先被创建的建模产品,并且几乎任何一种类型的技术体系结构都必须在此被使用的这一过程。模型的这个集合的效用已经在许多现实世界的项目中被证明。我们现在将这种建模方法和风格称之为“通用的”或者“经典的” RUP 建模指导方针。


如何在基于 Rational Eclipse 的 UML 建模工具中实现 RUP 模型类型

在 RUP 中,模型都是特定类型的,例如:UML 用例模型、UML 分析模型、或者数据模型等。讨论所涉及的产品并不实际地将类型分配到 UML 模型。因此,RUP 模型到这些产品的映射主要是一个用法约定的问题,例如下列这些例子:

  • 如何为您的模型/逻辑单元取名;
  • 应用到它们的剖面;
  • 创建它们时所包含的内容。

讨论所涉及的产品包括少量的模型模板,您能够在创建模型/逻辑单元时使用这些模板。其中有一些模板提出了符合 RUP 的一种特殊的模型类型和模型组织方法。当您创建新的模型/逻辑单元时您会遇到这些模板,并且您能够将新的模型建造在这些模板的基础之上。

图 1 描述了新模型向导的页面。在页面的左侧,您能够看到一些标准的模板。在页面的右侧,您能够看到还有可能将您自己所设计的模型作为一个模板或者起始点。

图 1. New UML Model 向导
New UML Model 向导

表 1 显示了通常被使用的 RUP 模型类型,以及它们如何在讨论所涉及的产品中被实现。本文下面所提供的信息假定您使用这些被描述的映射和方法。

注释:
用于 Use-Case(用例)、Analysis(分析)、以及在后面小节中出现的 IT Design Models(设计模型)的内部组织的指导方针符合在讨论所涉及的产品所提供的标准模型模板中被定义的组织结构。这些模板所表现的绝不是组织这些模型的唯一方式。在决定如何组织您的模型的逻辑内容时,应当将许多因素都考虑进来。

表 1. RUP 模型通常使用的类型
RUP 模型在讨论所设计的产品中的实现方式
Business Use Case Model (业务用例模型)模型/逻辑单元基于一个标准的 Blank Model (空白模型)模板,并且同 Business Modeling (业务建模)剖面一起被应用。根据 RUP 业务用例模型的指导方针限制内容。

模型/逻辑单元基于一个用户定义的模型,并且同 Business Modeling (业务建模)剖面一起被应用。根据 RUP 业务用例模型的指导方针限制内容。
Business Object Model (业务对象模型)模型/逻辑单元基于一个标准的 Blank Model (空白模型)模板,并且同 Business Modeling (业务建模)剖面一起被应用。根据 RUP Business Object (业务对象)模型的指导方针限制内容。

模型/逻辑单元基于一个用户定义的模型,并且同 Business Modeling (业务建模)剖面一起被应用。根据 RUP Business Object (业务对象)模型的指导方针限制内容。
(解决方案) Use-Case Model (用例模型)模型/逻辑单元基于一个标准的 Use-Case Model (用例模型)模板。根据 RUP Use-Case Model (用例模型)的指导方针限制内容。

模型/逻辑单元基于一个用户定义的模型。根据 RUP Use-Case Model (用例模型)的指导方针限制内容。

模型/逻辑单元基于一个标准的 Blank Model (空白模型)模板。根据 RUP Use-Case Model (用例模型)的指导方针限制内容。
(解决方案) Analysis Model (分析模型)模型/逻辑单元基于一个标准的 Analysis Model (分析模型)模型。根据 RUP Analysis Model (分析模型)的指导方针限制内容。

模型/逻辑单元基于一个用户定义的模型。根据 RUP Analysis Model (分析模型)的指导方针限制内容。

模型/逻辑单元基于一个标准的 Blank Model (空白模型)模板。根据 RUP Analysis Model (分析模型)的指导方针限制内容。

模型/逻辑单元基于一个标准的 Enterprise IT Design Model (企业级 IT 设计模型)模板。使用 <分析> 包来包含根据 RUP Analysis Model (分析模型)的指导方针限制的分析层的内容。
User Experience Model (用户体验模型)模型/逻辑单元基于一个标准的 Blank Model (空白模型)模板。根据由用户经验建模配置(被包括在 IBM® Rational® Method Composer 配置中)所提供的指导方针限制模型。

使用 IBM® Rational® Software Architect 或者 IBM® Rational® Application Developer 中的 Web Diagram Editor (网络图编辑器)或者 Java™ Visual Editor (Java 可视化编辑器)。
Design Model (设计模型)对于 IT 来说:模型/逻辑单元基于一个标准的 Enterprise IT Design Model (企业级 IT 设计模型)模板。根据 RUP Design Model (设计模型)的指导方针限制内容。

对于 IT 或者系统来说:模型/逻辑单元基于一个标准的 Blank Model (空白模型)模板。根据 RUP Design Model (设计模型)的指导方针限制内容。

对于 IT 或者系统来说:模型/逻辑单元基于一个用户定义的模型。根据 RUP Design Model (设计模型)的指导方针限制内容。
Implementation Model (实施模型)并不被 UML 所支持。使用 3GL 特定的 Code Modeling (代码建模)功能。

使用一个 UML Design Model (设计模型),但是使用一个带有“置换 UML 元素”选项的转化来生成代码,从而设计模型成为一个混合模型,反映出执行层的内容。
Deployment Model (部署模型)模型/逻辑单元基于一个用户定义的模型。根据 RUP Deployment Model (部署模型)的指导方针限制内容。

模型/逻辑单元基于一个标准的 Blank Model (空白模型)模板。根据 RUP Deployment Model (部署模型)的指导方针限制内容。
Data Model (数据模型)使用逻辑的和物理的数据模型作为由 IBM® Rational® Data Architect 提供的支持。

组织 RUP 模型

在第 1 部分中,我们描述了团队建模的关注以及强壮的体系结构强壮的所有权的法则。在使用 RUP 建模风格时,这些法则仍然十分重要,但是 RUP 风格还引入了您必须加以处理的其他一些直交的关注。

再次求助代码库的使用来描述这一点,我们来考虑一个三层的应用程序体系结构。您可能会将这样一个代码库划分到几个被强壮拥有的模块中,依靠的就是应用程序功能性的考量。这从本质上反映了 图 1 中的方法,即解决方案被分解到若干公共的效用、服务、应用程序及其模块之中。

然而,这并不是划分的唯一方式,而且它可能并不支持使得开发人员拥有专门技能集合的强壮的所有权。举例来说,根据相应的三层体系结构进一步将应用程序模块进行划分也可能是一种明智的选择。(尤其是,当开发人员专攻于客户端和服务器端的开发时,所有权有可能更加依赖层次而非应用程序的功能,但是强壮的体系结构的法则仍然要求您在划分时必须对这两种关注都要给予注意。)

RUP 引入了关于模型组织的一组关注,但是不同的 RUP 模型并不符合一种解决方案体系结构的层次。相反,它们符合抽象的不同层次,而这些抽象正是您在开发过程中可能需要表现的。这表明 OMG Model-Driven Architectures (MDA,模型驱动体系结构)在抽象的不同层次上,主动提出了一个相似的层次划分。表 2 显示了 RUP 方法和 MDA 方法的粗略对比情况。

表 2. 对比 RUP 模型类型和 MDA 模型类型
RUP 模型类型MDA 模型类型目的和注释
Business Use-Case Model (业务用例模型) Business Analysis Model (业务分析模型)CIM显示解决方案的业务驱动需求和不依赖于计算的表示法。
Solution Use-Case Model (解决方案用例模型) Solution Analysis Model (解决方案分析模型) User Experience model (用户经验模型) Logical Data model (逻辑数据模型)PIM显示解决方案的依赖于计算但是独立于平台的解决方案需求和表示法。
Solution Design Model (解决方案设计模型)PIM 或者 PSM或者显示解决方案的独立于平台的表示法,或者显示被标注为特定平台关注的表示法。解决方案设计模型可能从 PIM 发展到 PSM (在 situ 中)。
Implementation model (实施模型) Physical Data model (物理数据模型) Deployment model (部署模型)PSM将特定平台的关注引入解决方案的设计中。

就如同开发实现代码的人员可能专注于客户端或者服务器端的开发一样,那些开发模型的人员也有可能专注于业务需求分析、解决方案需求工程学、解决方案分析、解决方案设计、信息设计等等。 当处理抽象层的细节设计时,可能有一种强烈的需要将设计模型的组织对准到代码基础的组织(特别是如果代码生成被使用时更是如此)。表 3 提出在为一个 RUP 建模实践计划模型划分策略的时候,区分优先次序的各种关注。

表 3. 模型内容所有权策略
对于这些 RUP 模型类型来说所有权策略基于这些关注之上
Business Use-Case Model (业务用例模型) Business Analysis Model (业务分析模型) 共享的和共同的内容的隔离;

技能的专门化;

问题空间(例如:部分、工作流程、策略启动等)的面向业务的组织细分。
Solution Use-Case Model (解决方案用例模型) Solution Analysis Model (解决方案分析模型) User Experience Model (用户经验模型) Domain Model (域模型),也被称作 Reference Information Model (引用信息模型)或则 Logical Data Model (逻辑数据模型) 共享的和共同的内容的隔离;

技能的专门化;

功能性(例如:应用程序、工作流程、模块等)的面向解决方案的细分。
Solution Design Model (解决方案设计模型) Physical Data Model (物理数据模型) Implementation Model (实施模型) 共享的和共同的内容的隔离;

它还依赖:
  • 对于具备多种技能的开发人员的团队来说,关注功能性的细分以及强内聚性和低耦合性的法则。
  • 对于具备专门技能的开发人员的团队来说,它可能必须首先关注体系结构的层次,目标执行技术等,因此将功能性的细分放到次要的所有权的考量(技能仍然是首要的体系结构的考量)。在讨论所设计的产品中,不同于早期的 Rational 建模产品,实施模型是由一个代码基础和代码的图所组成的。
Deployment Model (部署模型) 根据 Design Model (设计模型)进行调整;

根据基础结构资产(机器、网络等)的所有权进行调整。

另一个关注就是不稳定性,这是在开发计划中所通常遇到的。特别是在“绿色领域”开发项目的早期迭代中,您可能会根据您对应当如何命名以及什么才是最佳的功能分组的理解,频繁地重新分解。

在一个面向 RUP 的建模过程中,在用例模型的组织和分析模型之间往往是一种非常强壮的关系(至少在过程的早期是这样的),这是因为 RUP 为基于一个 Use-Case Model(用例模型)的内容移植一个 Analysis Model(分析模型)的内容提供了一个相当机械的过程。因此,您使用以下这些操作来播种 Analysis Model(分析模型):

  • 一个 <Use-Case Realization> 协作(拥有一个或者多个交互)和一个面向每一个用例的 <Control> 类;
  • 一个面向每一个用例的 <Boundary> 类和 Actor 关系;
  • 任何数量的 <Entity> 类,它们多半来源于对用例描述中名词的一个分析,或者来源于一个与模型的开发。

优势:出于这些原因,它提出将分析内容保存在和用例相同的包中(这暗示它们位于同一个模型中),例如:

  • 能够使得完成某些用例分解任务变得更加容易(例如:对包进行重新命名或者对用例进行重新分组);
  • 能够更加容易的看到分析内容是如何需要改变以反映其它类别的用例分解的(例如:更加容易的看到一个用例实现的名称 [UML Collaboration] 或者 <Control> 类应当何时被改变以反映用例被重新命名了)。

折衷:并不通过一位业务分析师将它自己贡献给用例的强壮所有权,不通过一位系统分析师或者软件架构师贡献给分析内容的强壮所有权。因此,您可能会决定通过几次迭代配置用例和分析内容,直到稳定为止,然后将分析内容分解到它自己的模型/逻辑单元中(同反映用例模型的一个包结构一起)以适应由软件架构师提供的强壮所有权。然后,您可能将分析内容同反映用例内容的一个包结构一起,移动到它自己的模型/逻辑单元之中。

RUP 模型的优势和折衷

在第 1 部分中,我们给出如下建议:“最好的建模指导方针就是这样做能够识别出业务的价值。”正如您从本文中所看到的,RUP 提出了许多不同类型的模型,来反映一个问题域或者被提议的解决方案的抽象的不同的方面和层次。这是因为 RUP 被证明至少能够在某些情况下增加价值。问题是:“是否在每一种情况下都能够增加价值呢?”答案是:“不是。”

下一个问题随之而来:“我如何知道在我所处的情况中是否能够增加价值呢?”这个问题的答案并不能够被准确地预知。尽管粗略地讨论建模的价值,或者详细地讨论每一个 RUP 模型的价值并不属于本文的范围,但是我们将尝试着探究一个 RUP 模型类型应当何时被使用。表 4 提出哪些潜在的值点是用于每一个 RUP 模型类型的,创建和维护它们的成本如何,以及您能够使用什么来作为替代。通常来说,添加价值的声明是直截了当的,但是至少以下列两种不同的方式来考虑可追溯性表现潜在的业务价值仍然是十分重要的:

  • 依从性
  • 影响力分析
表 4. 各种 RUP 模型的优势、折衷和选择性
RUP 模型类型优势、折衷和选择性
Business Use-Case Model (业务用例模型)优势:
  • 较好的理解业务问题、需求和改进的潜能;
  • 在业务中或者跨业务的同出资方有效地沟通业务问题和潜在解决方案;
  • 可能地,向下追溯(例如:向基于知识库的需求,或者业务分析模型,或者二者皆是)。

折衷:

  • 模型的开发和维护;
  • 可能地,业务用例模型内容到向下需求和模型的同步;
  • 可能的,向下追溯联接的创建和维护。

选择性:

  • 业务文档(报告、陈述);
  • 业务过程模型。
Business Analysis Model (业务分析模型)优势:
  • 更好的理解业务解决方案的需求、特性和开销;
  • 可能地,向下追溯(到基于知识库的需求和解决方案用例模型)。

折衷:

  • 模型的开发和维护;
  • 可能地,业务分析模型向上游和下游需求和模型的同步;
  • 可能地,追溯联接的创建和维护。

选择性:

  • 业务文档(报告、陈述);
  • 业务过程模型。
Solution Use-Case Model (解决方案用例模型)优势:
  • 更好的理解解决方案的需求;
  • 有效的同项目出资方沟通解决方案的范围和需求;
  • 可能地,向上追溯(例如:到基于知识库的需求或者业务分析模型);
  • 可能地,横向追溯到其他的模型和产品(用户经验模型、原型代码、测试实例);可能地,向下追溯到其他的模型(包括代码);
  • 可能地,自动生成下游模型的内容(涉及到自定义工具的开发);
  • 可能地,自动生成测试实例的大致轮廓。

折衷:

  • 模型的开发和维护;
  • 可能地,将解决方案用例模型同步到上游(例如:业务分析)和下游(例如:解决方案分析模型)的模型;
  • 可能地,上游和下游或者横向追溯性联接的创建和维护;
  • 可能地,自定义工具的开发。

选择性:

  • 规范文档;
  • 原型。
Solution Analysis Model (解决方案分析模型)优势:
  • 更好的理解导致在提交代码之前能有更好的体系结构选择的解决方案需求和特性;
  • 可能地,向上追溯(例如:到解决方案用例模型);
  • 可能地,向下追溯到其他的模型(包括代码);
  • 可能地,自动生成下有模型的内容(涉及到自定义工具的开发);或者发展到设计模型。

折衷:

  • 模型的开发和维护;
  • 可能地,将解决方案用例模型同步到上游(例如:解决方案用例模型)和下游(例如:设计模型或实施模型)的模型;
  • 可能地,上游和下游追溯性联接的创建和维护;
  • 可能地,自定义工具的开发。

选择性:

  • 规范文档;
  • 原型。
User Experience Model (用户经验模型)优势:
  • 更好的理解解决方案的需求;
  • 有效的同项目出资方沟通解决方案的范围、需求和用户经验特性;
  • 可能地,向上追溯(例如:到基于知识库的需求和/或业务分析模型);
  • 可能地,横向追溯到其他的模型和产品(用例或者解决方案分析模型、原型代码、测试实例);
  • 可能地,向下追溯到其他的模型(包括代码);
  • 可能地,自动生成下游模型的内容(涉及到自定义工具的开发);
  • 可能地,自动生成测试实例的大致轮廓(涉及到自定义的工具开发)。

折衷:

  • UX 建模风格和 UML 剖面的设计、开发和维护;
  • UX 模型的开发和维护;
  • 可能地,将解决方案用例模型同步到上游(例如:业务分析)和下游(例如:解决方案分析)的模型;
  • 可能地,上游和下游追溯性联接的创建和维护;
  • 可能地,自定义工具的开发。

选择性:

  • 规范文档;
  • UX 草图(Rational 业务伴侣工具);
  • 原型,
Domain Model (域模型),也被称为 Reference Information Model (引用信息模型)或者 Logical Data Model (逻辑数据模型)优势:
  • 更好的理解现实世界中的业务域;
  • 为教授业务域提供培训帮助;
  • 改进数据库的设计;
  • 可能地,向下追溯(例如:解决方案分析或者设计模型);
  • 可能地,播种下游的模型,例如:解决方案分析或者设计模型(涉及到自定义工具的开发);
  • 可能地,从域模型中播种逻辑数据模型(在 Rational Data Architect 中已经存在的工具),反之亦然;
  • 在业务中或者跨业务的同出资方有效地沟通业务问题和潜在解决方案;
  • 有效的沟通信息综合和联合问题,支持数据控制的努力。

折衷:

  • 模型的开发和维护;
  • 可能地,将域模型同步到数据模型或者下游的软件模型(解决方案分析或者设计);
  • 解决方案用例模型的内容到上游(例如:业务分析)或者下游模型(例如:解决方案分析模型);
  • 可能地,上游和下游追溯性联接的创建和维护;
  • 可能地,自定义工具的开发。

选择性:

规范文档。

Solution Design Model (解决方案设计模型)优势:
  • 无须提交代码就能够描述和评价可选性设计方法的机会;
  • 更好的理解导致在提交代码之前能有更好的体系结构选择的解决方案需求和特性;
  • 可能地,向上追溯(例如:到解决方案用例模型或者解决方案分析模型);
  • 可能地,向下追溯到代码;
  • 可能地,自动生成代码(使用自定义的转化或者由谈论所设计的产品中提供的标准转化)。

折衷:

  • 模型的开发和维护;
  • 可能地,同步到上有的模型或者需求;
  • 可能地,同步到代码;
  • 可能地,上游和下游追溯联接的创建和维护;
  • 可能地,自定义工具的开发。

选择性:

  • 规范文档;
  • 原型;
  • 代码模型和代码。
Physical Data Model (物理数据模型)优势:

以图的模式探索和检查一个解决方案的执行,并且有助于理解该执行。(在维护阶段尤其有价值,并且作为项目成员被加以使用。)

折衷:

图的维护。

Solution Implementation Model (解决方案实现模型)优势:

以图的模式探索和检查一个解决方案的执行,并且有助于理解该执行。(在维护阶段尤其有价值,并且作为项目成员被加以使用。)

折衷:

图的维护。(尽管 Browse 图能够许多价值,并且无需进行维护。)

Solution Deployment Model (解决方案部署模型)优势:

有助于理解部署解决方案的需求和开销,这在需求、设计和执行阶段十分有用。

折衷:

模型的维护。

所有的模型类型优势:

同各种各样的项目出资方更有效的进行沟通;

是解决方案管理框架的基础;

同依从性相关的文档(特别是从需求到执行的追溯性的改进)。


RUP 用来模型的内部组织的指导方针

讨论所设计的产品提供了根据一个用例模型模板创建一个新的模型/逻辑单元的选项。(您还能够创建您自己的模型/逻辑单元作为模板来使用。)

标准的用例模型模板

这些模板有可能定义了在进行用例建模时被典型使用的 UML 功能的一个特定子集(换句话说,当基于该模板处理模型时,调色板和下拉菜单仅会包含那些被关注于用例建模的人所共同使用的 UML 元素)。模板还贡献了一组默认内容,如图 2 中所描述的那样。对于如何使用 Use-Case Building Blocks 和搜索字符串的内容已经超出了本文的范围,但是模板中的注释提供了相关的用法说明。

图 2. 被包括在讨论所设计的产品中的用例模型模板的默认内容
被包括在讨论所设计的产品中的用例模型模板的默认内容

模板倾向于按照驱动模型组织的技术对功能性进行逻辑划分。(这一倾向性出现在作为一个用例模型的首要的编译块的 ${functional.area} 包模板的使用中。) 图 3 描述了由这一倾向性所鼓励的用例模型组织类别的小例子。

图 3. 根据功能性划分组织的用例模型的实例
根据功能性划分组织的用例模型的实例

正如在 组织 RUP 模型 一节中所讨论的那样,这并不是进行逻辑划分的唯一可行的方法。选择这种方式的原因主要是:

  • 在团队成员处理用例模型的时候,它通常能够较好地映射到劳动关注的分割。
  • 这种方法最有机会产生一种用例模型组织,当组织采用功能模块的强壮所有权的时候,它能够很好的映射到 Design(设计)和 Implementation(执行)模型(尽管它们还有可能反映层次的考量,但是设计和实施模型的组织最经常反映的仍然是功能性分解和组件关注)。如果您期望使用转化来播种抽象的每一个更低一层的话,这将被证明是尤其重要的。如果您要将播种内容生成到一个基于用例模型的 Analysis(分析)模型或者 Design(设计)模型中,那么将那些模型中的包结构(或者至少是类似的结构)排列起来需要的仅仅是转化开发和配置。

模板还提出了以下这些组织技术的使用:

  • 使用顶层包来广泛地捕获被授权或者通用的 Actors(即那些参与到多个面向功能性的包的一组用例中);
  • 使用 <perspective> 包来捕获描述跨功能区域的视图的图(但是模型的语义元素仍然由功能区域所组织)。

Rational XDE 和 Rational Rose 的移植

这一用例模型组织指导方针在某种程度上修正了早期的 RUP 指导方针,它为活动者创建一个顶层的包,并且为用例创建另一个顶层的包。 然后,按照模型对大小和复杂性的要求,您将使用低层的包来建立如图 4 中所示的基于 XDE 实例的面向功能性的分组。

图 4. XDE 样例
XDE 样例

用例模型的内容

为如何编写良好的用例提供详细的指南已经超出了本文论述的范围。然而,下面是关于除了活动者和用例之外,应当被包括进用例模型中内容的简要讨论。

推荐的:在模型根部创建一个主体图,描述模型的其他包,并且支持深入到那些包及其相应的图中。

推荐的:在每一个用例包中,包括一个描述该包的用例、其中的任何关系、以及参与其中的活动者的图。如果数量巨大的话,那么可能会用到一个以上的图。

推荐的:在文档域中描述每一个用例的主体的和可选的流程,如图 5 中所示。(例子中的格式是通过使用一个丰富的文本格式(RTF)编辑器为一个描述的用例创建文本模板来完成的,然后将该模板复制并且粘贴到用例描述域中。)

图 5. 在一个用例的文档属性中捕获用例流程的描述
在一个用例的文档属性中捕获用例流程的描述

可选的:当用例的复杂性保证它时,添加一个 Activity(活动)图并且组合它以反映用例的全部活动流程(请参见 图 6 所示)。基本原理:这有助于显示符合每一个流程(主体的、可选的、或者异常的)的条件,并且有助于确保所有不同的流程最终汇聚于一点。(语义上,添加一个活动图将导致由用例元素所拥有的活动元素的增加,并且图处于活动之下)。

可选的:对用例的每一个指定流程(主体的、可选的、以及异常的)建模一个黑盒的实现:

  1. 向用例添加一个 Opaque 行为,并且向它提供流程的名称。
  2. 向它添加一个序列图(语义上,添加一个序列图将导致由 Opaque Behavior 所拥有的交互元素的增加,并且图处于交互之下)。
  3. 为每一个交互实例组成一个序列图(或者 Communication 图)。

Rational XDE 和 Rational Rose 的移植

在 UML 1 中,您使用的是一个协作实例而不是 Opaque Behavior 来达到这一目的。

这些 Opaque 行为实例不应当同我们在后面小节中所描述的分析层或者设计层用例的实现相混淆。后者是用例的白盒实现,它描述的是解决方案中的内部元素之间的交互。这里所提到的 Opaque 行为(请参见图 6 所示)是 Actors 和系统之间的严格的黑盒交互。它们为非技术性的出资方提供了一幅关于用户是如何同系统进行交互的高层次的图画。这些 Opaque 行为可以帮助您识别被要求作为执行一部分的不同的视图(屏幕或者页面)。它们还将通过将名字分配到语义模型元素(Opaque 行为)在形式上建立用例的不同流程(场景)的命名。

图 6. 拥有一个活动的用例的实例
拥有一个活动的用例的实例

可选的:如果您遵循 RUP 的指导方针来识别您的体系结构中重要的视图,特别是如果您保持一个软件体系结构文档的话,那么请您添加一个顶层的 <perspective> 包来包含那些描述重要用例的用例图。您可能希望将这个包命名为体系结构的用例视图。此外,您也可以将它放置到一个体系结构总体模型中。


RUP 分析模型的内部组织的指导方针

分析模型表现了解决方案的第一步。它是从需求出发,到达最终设计的必经之路。它关注于捕获关于业务域的信息,并且在接近业务的较高抽象层上展示候选的解决方案元素。这里正是分析类和分析级用例实现的场所。它贯穿建模用例实现的整个过程(主要使用次序图),您开始发现解决方案所需要的实际的设计类。特别地,这些类将符合您在次序图中所需要的生命线。这也是一条能够基于用例模型的内容被应用到提出分析模型内容的首要规则(通用指导方针)。我们将在稍后对这些内容进行解释。

在 RUP 中,无论分析模型是否应当独立于设计模型被维持是根据具体的项目来决定的。您将根据是否坚信单独维持分析模型的价值能够保证投入的时间来做出相应的决定。下面这些因素将是您需要加以考虑的:

  1. 正如在前面的 组织 RUP 模型 一节中所讨论到的,在项目的早期阶段,内容是高度不稳定的(或者说在任何时刻用例和分析模型都是由同样的人员来执行),在和用例模型一样的模型/逻辑单元内部维护分析内容。应用 RUPAnalysis 剖面进行建模,并且使用带有 <analysis> 关键字的包将分析内容从用例内容中分离出来。此后,您可能会将分析层的内容提取到一个单独的模型/逻辑单元之中,它在那里将以我们所描述的任何一种方式被管理。
  2. 创建一个独立于用例模型的分析模型(它位于自身的逻辑模型之中,基于分析模型的模板)。然后,使用一个手动的过程或者模型到模型的转化来创建单独的设计模型中的分析元素的提纯版本。您可以选择是单独维护分析模型还是将它丢弃。
  3. 进行同样的操作,不同的是让分析模型在适当的位置发展到设计模型。(实际上,RUP 提到了您可以选择在设计模型中创建分析类和分析层的用例实现,然后将它们直接发展到它们的设计格式中。)此处,您通过使用分析类启动用例实现的建模,然后随着时间的推移,对它们进行提纯,以便真正的设计接口以模型要求的行为承担起这一角色。
  4. 在和设计模型相同的模型内部可以结合第二和第三中选项来维护一个分析模型。通过这种方法,正如设计模型被发现的那样,您能够创建包,并且保存一些纯粹的分析透视图。为了这样做,您需要将分析内容隔离到应用关键字 <analysis> 的包中。

标准的分析模型的模板

讨论所涉及的产品提供基于分析模型模板创建一个新的模型/逻辑单元的选项。(您还能够创造您自己的模型/逻辑单元来作为模板使用。)这些模板可能定义了 UML 功能的一个特定的子集,在进行分析建模时会典型地用到它们。换句话说,当处理基于模板的模型时,调色板和下拉菜单中仅仅包含为那些关注分析的人员所共同使用的 UML 元素。

此外,RUPAnalysis 剖面被用于那些从模板中创建出来的模型/逻辑单元,并且这些模板贡献了一组默认的内容集合,如图 7 中所示。(对于分析编译块的内容和搜索字符串是如何被使用的相关解释,超出了本文的范围,但是包含在模板中的注释将提供相关的使用说明。)

图 7. 讨论所设计的产品中包括的分析模型模板的默认内容
讨论所设计的产品中包括的分析模型模板的默认内容

和用例模型模板相类似,分析模型模板倾向于将功能逻辑的划分为驱动模型组织的技术。(这一倾向将 ${functional.area} 包模板的使用表现为用例模型的主要编译块。)图 8 中描绘了由这一倾向所鼓励的分析模型组织类别的小例子。

图 8. 一个分析模型中的高层组织的实例
一个分析模型中的高层组织的实例

正如在 组织 RUP 模型一节中所讨论到的,逻辑划分的方法不止一种。您需要根据如下这些因素选择模板的使用:

  • 当一组人员共同处理分析模型时,它通常能够较好的对应劳动力划分的关注。
  • 如果您希望使用个性化的转化来从用例模型中播种分析模型的话,那么它能够向上对应授权模板的用例模型组织。
  • 这种方法最有机会产生一种分析模型组织,当它被用在鼓励功能性模块的强壮所有权的组织中时,它能够很好的映射到 Design(设计)和 Implementation(执行)模型(尽管它们还有可能反映层次的考量,但是设计和实施模型的组织最经常反映的仍然是功能性分解和组件关注)。如果您期望使用转化来播种抽象的每一个更低一层的话,这将被证明是尤其重要的。

模板还提出了其他一些组织技术的使用:

  • 将分析元素(模板类)分割到每一个功能性区域包的子包中;
  • 使用 <perspective> 包来捕获描述跨功能性区域视图的图(当模型的语义元素仍然被功能性区域所组织的时候)。

之前所显示的 图 8 描述了一些用于组织分析模型的技术,它们基于由分析模型模板所鼓励的通用方法。这一方法的细微变化之处被描述在 图 9 之中。(这一描述是基于讨论所涉及的产品的 版本 6 的,它在其 Project Explorer 视图中被用作不同的图标。不同之处在于,一个顶层的包已经被用于从分析类中隔离用例的实现。在那个顶层包中,您看到和面向功能性的顶层包相匹配的一组子包。隔离用例实现的潜在优势在于它使得您在无需影响用例实现组织的情况下分解顶层包结构。这样做的原因是(特别地,如果分析模型将会在原处发展到设计模型的话)用于类的包组织或许将需要发展,从而它不再同最初为用例所建立的包组织相匹配了。

图 9. 分析模型高层组织的异种
分析模型高层组织的异种

根据您的情况,有理由引入命名约定的使用,它将预期由多个独立的组所创建的模型内容的合并和重用,甚至包括不同业务中的组。如果这是一个关注点的话,那么请您考虑使用图 10 中所描述的反向的 Internet 域命名约定(同样也是基于讨论所涉及的产品的版本6的)。请注意,这可能并不是关于建模的一个本质上的大的关注点,但是如果您采用将您的分析模型在原处发展到域模型这一方法,并且期望在设计层重用或者业务综合的话,那么您可能就会希望首先以这种方式做好计划。采用这一方法的另一个潜在的好处就是,由于它可能很好的映射到从分析和设计中所生成的代码的组织,所以它可能使得在此之后的模型到文本(代码)的转化的配置变得简单。

图 10. 使用反转的 Internet 域命名空间约定的实例
使用反转的 Internet 域命名空间约定的实例

分析模型的内容

有若干种方式来发现分析类。一种方式是绘制建议用例实现的次序图。您将发现什么生命线是您所需要的。通常来说,每一条生命线都表现了一个候选的分析类。当您以这种方式发现类时,您可能在分析模型的用例实现包中创建它们,但是并不让它们一直留在那里(举例来说:您可能将它们收回到在前面图中所描述的面向功能性的包中)。

对于发现分析类的另一种有用的方法是:播种分析模型,其中具有以这些指导方针为基础的类:

  • 对于每一个用例来说(在用例模型中),向分析模型中添加一个 <control> 类。控制类反映了同用例相关联的业务逻辑。(在后面的设计中,它们还将映射到诸如会话管理这样的关注。);
  • 对于每一个 Actor 用例关系来说(在用例模型中),向分析模型中添加一个 <boundary> 类。这个 <边界> 类表现了解决方案和行动者之间、或者解决方案和某些外部系统之间的接口。和一个行动者相对应的 <boundary> 类可能最终映射到一个或者多个设计和执行中的用户接口;相反,和一个外部系统相对应的 <boundary> 类可能最终映射到设计和执行中的某种类别的适配器层。
  • 通过诸如 CRC 卡片分析或者用例描述的单词分析这样的过程,确定额外的 <control> 类(动词)和 <entity> 类(名词);
  • <entity> 类的其他潜在源包括域模型、逻辑数据模型、控制数据模型、以及业务术语表;

不论您是如何发现分析类的,您都几乎能够肯定的认可对于您的原始功能包结构的改变是必须的。关于分析模型内容和分析模型组织发展的建议如下:

推荐的:分析模型应当包含分析层的用例实现,它描述了用例在分析类的协作方面是如何执行的。每一个用例实现(由一个 UML 协作来表现)都对应用例模型中的一个 UML 用例。它很有可能拥有和那个用例相同的名字,以及那个用例的出处和实现关系(请参见前面的 图 8 所示)。

推荐的:对于任何一个您感觉应当被建模为一个分析层实践的用例流程(正如前面在用例模型中所建立的),向协作中添加一个次序图来表现该流程的实现。它将自动添加一个 UML 交互作为次序图的所有者。请参见图 11 所示。(请注意:在图 11 中,某些参数选择透露出 UML 语义内容的许多细节,例如所有权。默认情况下,这些内容是出现在 Project Explorer 之中的。您可能必须调整您的参数选择设置来得出同这个视图相类似的视图。)

图 11. 拥有序列图的协作(用例实现)
拥有序列图的协作(用例实现)

建议的:在您为一个用例流程创建次序图之后,您可以在 Project Explorer 中选择它自己的 UML 交互,并且向它添加将一个 Communication Diagram (通讯图)。新的通讯图将随着次序图中的分析类的实例被自动地移植。

建议的:从每一个用例实现(UML 协作)中创建一个实现依赖关系,并且从用例模型中创建相应的用例(请参见图 2 所示)。由于您使用诸如 Topic Diagrams (主题图)和 Traceability Analysis (追溯分析)这样的特性来理解您的模型中的追溯关系,所以您确实需要将描述追溯关系的表永久地保存下来。因此,您能够使用某些类型的一次性图来创建这些关系。例如:

  1. 向协作中添加一个形式自由的图。
  2. 将协作拖动到那个图上面。
  3. 同样,将用例拖动到它上面(有可能来自另外一个不同的模型)。
  4. 拖动依赖关系。
  5. 最后,在 Project Explorer 中将该图从协作中删除。

建议的:为每一个用例实现包括一个参与图(参与者图)来显示参与到实现中的分析类(也就是说,出现在描述用例实现的交互图中的分析类的实例),以及支持交互图中所描述的协作的那些类之间的相互关系。这其中可能既包括实体类也包括数据传递对象类。请参见图 12 所示。

图 12. 一个用例实现参与图的实例
一个用例实现参与图的实例

RUP 设计模型的内部组织的指导方针

讨论所涉及的产品为创建一个基于企业级 IT 的设计模型模板提供了选项。当确定将业务应用程序作为目标的时候,这些就是您能够用来用作设计(或者是用作分析)的模板。您还能够创建您自己的模型/逻辑元素作为模板来使用。

标准的企业级 IT 设计模型模板

这些模板可能定义在设计建模时被典型使用的 UML 功能的一个特定的子集(换句话说,当基于模板处理模型时,调色板和下拉菜单中仅仅包括那些关注设计的人所共同使用的 UML 元素)。此外,一个企业级的 Java™Beans (EJB)转化剖面被用于从这些模板中所创建的模型/逻辑单元,并且该模板贡献了默认内容(请参见图 13)。解释 Design Building Blocks 内容和搜索字符串是如何被使用的已经超出了本文的范围,但是模板中所包括的注释为您提供了关于这些内容的用法说明。

图 13. 讨论所涉及的产品中包括的一个企业级 IT 设计模型模板的默认内容
讨论所涉及的产品中包括的一个企业级 IT 设计模型模板的默认内容

正如在前面的 组织 RUP 模型 一节中所讨论的那样,此处所描述的方法并不是唯一被考虑的方法。举例来说,在您的开发团队内部的资源专门化的本性可能建议您将重点放到作为模型组织驱动器的体系结构层次上面(而不是功能性的分解上面)。

图 14 描绘了用于组织设计模型的技术,基于由企业级 IT 设计模型模板所鼓励的通用方法。

图 14. 设计模型的高层组织
设计模型的高层组织

以下就是相关的技术及其异种:

  1. 将规范从执行设计中分离出来(例如接口和被支持的交互模式)。它显示了顶层包、被命名的设计合同和执行设计的作用。这一技术的另一种可选方案是将规范和执行设计放置到单独的模型/逻辑单元之中。
  2. 使用低层的包来建立面向功能性的分组。
  3. 在分组语义模型元素的包中放置图,这些图为该分组提供了指定的视图,但是并没有从分组外面描述元素。这一指导方针适合于基于业务域的面向功能性的子集的、基于一个体系结构层次的、或者基于其他的分组。将默认图命名为和包或者组件本身相同的名字,并且将其组合起来显示包的内容的总体情况。这样做的结果是将图同其所描述的内容拉得更近了,从而使得导航和理解该模型变得更加容易。
  4. 请考虑使用在设计模型中反向的 Internet 域名。其中原因在于:
    1. 首先,这样做能够避免妨碍特定语言的执行:
      • 涉及到多个模型驱动的应用程序综合的场景(特别是公司间的合作);
      • 复用的场景;
    2. 这将简化后面所进行的转化到执行的配置(源-目的位置和名称对应)。
  1. 请在选择包名时,考虑其在目标执行平台上的有效性,从而避免命名空间映射的潜在混乱。(大多数情况下这只是意味着:不要在名字中使用下划线之外的空格符号或标点符号。)
  2. 请考虑小写字母来命名包,从而更好的区别包名和包中的类名。
  3. 请考虑为接口和组件或者实现它们的类使用不同的名称。可以使用 ILoanLoan 或者 LoanLoanImpl 作为接口和执行的名字。在模型中这并不是必须的,但是在生成的代码中这往往是一个好主意。因此,在此处的得当操作能够为您后续的转化配置工作节省大量的精力。

如果您选择不维护一个单独的分析模型,但是希望维护该设计模型中抽象的分析层上的某些内容,并且您希望在设计模型上使用模型-文本(代码)的转化,那么请考虑将分析层的内容(从代码中并不一定意味着被代码所生成)从被套用为 <analysis>(这样的包将被转化跳过)的包中隔离出来。

  1. 使用 <perspective> 包中的图来捕获设计元素的高层的横切视图。基本原理:在将模型的语义元素组织到面向功能性的分组中的同时,提供横视图、体系结构重要内容的视图、以及诉诸不同类型的出资方的视图。

贴士:
承认“设计模型的的包结构将随着时间而发展”这一点是非常重要的

RUP 实践中设计模型的最初组织通常或多或少的直接符合任何一个上游用例或者分析模型的组织。(分析类的包经常被进行的大的分解,从而更好的支持重用和不可预期的功能需求的变化。)然而不幸的是,该组织应当不断发展以反映您是如何将您的体系结构结构到组件和服务之中的。这一方法通常能够为打包复用资产提供最佳的潜能。它还是从设计到项目集合的最直接的映射,以及能够保留从该设计(代码、元数据、文档)中生成的执行产品的文件夹。

当然,另外一些可选的方法也可以作为一个最后阶段的组织(在某些情况下甚至更为可取)。例如,如果您将目标定位基于 Java™ 企业级平台的网络应用程序,那么设计的组织可能会期望关于 J2EE 项目的 Rational 软件体系结构和应用程序开发的约定(请参见补充说明)。

Rational 约定

不严格地说,这些 Rational 约定:

  • 每个应用程序或者服务或者主子系统的 Enterprise Project(企业级项目);
  • 对于每一个企业级项目来说,网络项目用于表示层次和多个 EJB 项目(EJB 项目通常和组件、服务或者较小的子系统相对应,并且典型隔离的 EJB 项目被用于每个组件或者子系统的会话 EJB 和域实体 EJB 层)。
  • 用于任何暴露为网络服务的服务的额外的网络项目;
  • 可选的:任何数量的支持效用类、所有权架构组件等的 Java 项目。

特别地,您可能选择定义同体系结构层相对应的顶层设计包(表示和业务,并且将业务作为会话和域的子层)。这显然不是一种和平台无关的方法,因此只有当您清楚地知道您所设计的解决方案将不会在 J2EE 平台之外被执行的前提下,这种方法才是可取的。

这显然不是一种和组织无关的方法,因此只有当您清楚地知道您所设计的解决方案将不会在企业级 Java 之外被执行的前提下,这种方法才是可取的。但是更一般地,当编译多个层的应用程序时,经常是开发人员的专业技术以及劳动力的划分同表示和业务层相对应。因此再一次强调您能够选择使用一种同那些体系结构层次相对应的顶层包,并且您还应当能够通过在配置代码生成器转化时付出额外的努力,从而将设计的组织映射到一组目标项目和文件夹中。(您能够使用被称为映射模型的一类特殊的配套模型来定义特别复杂的映射。)但是通常来说,当您考虑根据特殊的体系结构而不是根据功能的内聚性、松散的耦合性、以及强壮的所有权来组织模型的时候,请小心使用。

设计模型的内容

对于那些内容应当贮存在设计模型中,并没有什么必须遵守的规则。您对设计的一个特定方面进行建模的方式(不论您是否对建模一个特定方面感到烦恼),应当是一种建模方法将会添加多少业务价值的功能。从建模中获得最大的收益意味着为使用一组小型的但却是极富表现力的表示法定义一个指导方针(也许是 UML 剖面),这些表示法被用于生成大多数执行的个性化转化之中。对于执行的外包开发来说,谁的目标更加明确的指向对其提供支持的设计合同,一个在 UML 层上更加详细的表示法可能就会更加适当一些。

由此我们可以说,被下列说明所建议的方法对于那些计划对固定数量的设计细节建模的任务来说,是被证明为有用的。图 15 中描绘了一个在线拍卖服务的过程中设计模型,在一个较高的层次上显示了其内容的概况。这一设计模型是分析模型的一个适当的发展。

图 15. 部分完成的一个在线拍卖服务的设计模型
部分完成的一个在线拍卖服务的设计模型

在图 16 中,请注意用于一个 ListingService (列表服务)的使用合同被表示为一个接口。(分析类的包经常被进行重大的分解,从而更好的支持复用和无法预料的功能性需求变化。)相应的实现合同由一组设计层的用例实现来指定。(其他成分可能仅参与到一个系统用例中,并且他们的实现合同可能位于一个用例实现中。)此处请注意,与分析层的用例实现显示了分析类之间的协作关系所不同的是,设计层的实现显示了较不抽象的设计元素之间的协作关系。

图 16. 被建模为一个接口和设计层用例实现的设计契约
被建模为一个接口和设计层用例实现的设计契约

在图 16 和 17 中,请注意数据传递对象(DTO)已经被包括为执行设计的一部分。这些 DTO 作为被提供操作的参数类型,并且还有可能映射到执行结构上,例如一个 XML 计划或者服务数据对象(SDO)。对于那些没有被设计分配的组件来说,您可以选择将特定执行的数据传递对象(例如:实际中的 Java 类)仅仅用作作为操作参数的类型的规范。然而,对于类似我们这个 ListingService (列表服务)的可分配服务来说,强制规定服务的操作不能引用本地地址空间中的对象,这意味着在规范中被定义的 DTO 必须被用来表现消息的有效载荷。在我们这个 ListingService (列表服务)的例子中,DTO 实际上被定义用来符合一组被定义为假定的工业标准的一部分的消息规范(请参见前面的 图 16)。

图 17. 一种使用具有 Methods 的 Classes 表现执行设计的方法
一种使用具有 Methods 的 Classes 表现执行设计的方法

Rational XDE 和 Rational Rose 的移植

在早期的 UML 版本中,用例实现的指导方针是为每一个用例和一个迭代使用一个协作Instance (协作实例),并且为实现的每一个重要流程使用一个 Sequence Diagram (顺序图)。在讨论所涉及的产品中,您应当经常能够使用一种迭代和图,这是因为 UML 2 顺序图现在支持用于选择执行路径的符号。

同样地,在 UML 2 中,不再存在协作实例。相反地,存在协作Use (协作使用),它要求一个协作作为它的类型。因此,在讨论所涉及的产品中,使用协作来反映用例的实现。

指定执行设计的一种可能的方法正如前面的 图 17 中所显示的那样,使用包含操作的简单的类来定义执行结构。这种方法对于使用 UML 1 创建的设计模型来说非常的典型。

第二种可能的方法有可能更加适合图 18 中所显示的 UML 2 的目标,您能够看到 Components (组件)被使用并且它并不拥有 Operations (操作),相反,它拥有行为(在这种情况下,即是一个 Interaction 交互)。

Figure 18. 另一种使用自带行为的组件表现实现设计的方法
另一种使用自带行为的组件表现实现设计的方法

其他 RUP 模型的指导方针

同解决方案用例、解决方案分析和设计模型相比,其他的 RUP 模型需要说明的内容就少得多了:

  • Business Use Case (业务用例)
  • Business Analysis (业务分析)
  • Deployment (部署)
  • Information (信息)
  • Implementation (执行)

Rational 体系结构管理软件并不包括面向这些的模型模板。通常来说,强大所有权的法则应当驱动这些模型的组织。

  • 业务用例和业务分析模型的组织很类似解决方案层的副本。
  • 讨论所涉及产品中的实施模型包括 Eclipse 项目和代码以及元数据产品,还有反映那些产品的图。因此,执行体系结构将直接决定执行模型组织的形态。
  • 部署模型的组织典型的具有很少的上游和下游的牵连。只需要完成您的情况中最有意义的事情。例如:
    • 产品配置的规范已经从测试配置的规范中分离出来。
    • 概述(族、数据中心或者企业的)被保持在 <perspective> 包中。
    • 讨论所涉及的产品将包和关键字的结合用作一种专攻和分类节点和产品的方法。一种更加复杂的方法是开发一个专门的 UML 剖面,它定义了适当描述和记录在您自己的环境中所使用的资源类型的专门的模式和性质。

参考资料

学习

获得产品和技术

讨论

条评论

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, Architecture
ArticleID=318305
ArticleTitle=IBM Rational 架构管理软件模型结构指南,第 2 部分: 经典的 Rational 统一过程
publish-date=07032008