IBM Rational 架构管理软件模型结构指南,第 1 部分: 基本原则

本文涵盖与您组织模型内容的方式和构造模型储存库的方式相关联的术语、概念、原则以及最佳实践,并且将它们应用到基于 IBM® Rational® Eclipse 的 UML 建模产品中。

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

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



2008 年 7 月 03 日

关于本文

本文是系列文章(共四篇)的第 1 部分,同时也是其它各部分的基础。系列文章的其他几个部分为根据特定处理过程风格进行建模提供了指导方针,而本文(系列文章的第 1 部分)则是定义了其他各部分内容将有使用到的概念和术语。本文还将关注点放在对建造模型的考虑上,从而为团队建模的努力提供支持。那些考虑应当提醒您无需考虑您所选择采取的特定建模风格。


基本概念和术语

Eclipse、IBM® Rational® Application Developer、或者 IBM® WebSphere 产品® 都是 Rational Application Developer 的前身,熟悉这些软件的读者或许已经对本文中所使用的某些术语有一定的了解。

工作区、项目、项目类型

您也许已经了解到,在 Eclipse 中,文件存在于项目之中,而那些项目可以是各种各样的类型(或者按照 Eclipse 的说法,项目具有 natures(类型或种类),这些项目是在工作站中被组织和管理的。出于本文讨论的需要,并不是 Rational Application Developer 和基于 Eclipse 的 Rational UML 建模工具中可供使用的所有项目类型都会被详细的解释。我们首要关注的是项目的两个类别:

  • UML 项目,是指包含一个 UML 模型的项目。
  • 执行项目,包括专门的项目类型,例如:Enterprise 项目、Enterprise Java™Beans(EJB)项目、Web 项目、Java™ 项目和 C++ 项目。

模型

IBM Rational Unified Process(RUP)将模型定义为:“一个问题或者解决方案域从某个特定角度来看待的一个完整的规范。”一个问题域或者一个系统可能由反应该域或者该系统的不同侧面的若干模型所指定。举例来说,传统的 RUP 指导提出了基于 UML 模型的一个指定集合:

  • 业务分析模型
  • 业务用例模型
  • 用例模型
  • 设计模型
  • 分析模型(有可能被包含在设计模型之中)
  • 实施模型
  • 部署模型
  • 数据模型

此外,RUP 是针对非特定性的工具的。因此,对于 RUP 来说,一个模型就像是餐巾纸或者白板上面的图画,它是建模工具中的某样东西,甚至是一个想象中的图画。从 RUP 的角度来看,模型就是一个与物理概念相对的逻辑概念,此处我们将采用这种观点。

在讨论中所涉及到的产品的上下文环境中,模型主要是两种通用类型: 概念的以及具体的

  • 概念的模型用来表现和操作想法。典型的 UML 模型就是最好的例子。概念的模型并不是被机械的绑定到一个可执行实现上。请注意:有一些产品,比如 IBM® Rational Rose® RealTime™,它支持在运行环境下对 UML 模型的执行、调试和测试。这样的 UML 模型就被认为是具体的。
  • 具体的模型表现一种方式,图像化的描述和直接操作那些能够被机械的呈递到一个普通的可执行文件的执行产品。Java 模型和 C++ 模型就是最好的例子。在根本语义为 3GL 的时候,具体的模型还可以被简单的看做代码模型。具体的模型的另一个类别是基于声明语言的。一个很好的例子就是直接操作 SQL 数据定义语言的物理数据模型。

在讨论所涉及到的产品中,您将主要通过图和 Eclipse Project Explorer 同模型进行交互作用。

注释:
概念的和具体的模型之间的区别是与 Object Management Group(OMG)Model Driven Architecture(MDA,模型驱动架构)所产生的独立于平台的和特定平台的模型之间的区别所不同的。一个模型可以是特定平台的,同时还是概念的。

模型文件(用于模型的存留机制)

我们所讨论的产品以文件的形式存留模型。在 Eclipse 中,文件被看作是一种资源类型。资源可能在 Eclipse 环境中具备额外的属性和行为,因此资源不可能仅仅是文件。此处所描述的建模文件被作为 Eclipse 资源被执行。因此,当您在本文或者其他出版物中看到术语建模资源的时候,它就意味着建模文件。)

广泛地讲,软件支持两种类型的建模文件:

  • 概念的 UML 模型文件被储存在 Eclipse 项目中,其扩展名为 .emx 和 .efx (这两者之间的区别将在稍后进行详细的介绍)。这些文件包含两种类型的内容:
    • UML 语义元素(类、活动、关系等等);
    • UML 符号元素,它们已经被写入到描述 UML 语义元素的图中(这些图还有可能描述了其他语义域中的可视化引用,例如 Java、C++、或者 DDL)。
  • 具体的建模文件(例如 Java、C++、DDL)也被存储在 Eclipse 工作区中的 Eclipse 项目中,并且包含混合的语义和符号信息,但是在这种情况下,语义和符号内容被更加清晰的描绘出来;
    • 具体的模型语义元素位于执行产品之中。举例来说,在 Java 环境中,语义模型是以 Java 源代码文件的集合形式被连续地储存的。(当您运行该工具时,语义模型作为一个 ava Abstract Syntax Tree 贮存在内存中。)
    • 每一个图都被储存在其自身的文件中。图标文件可以使用不同的扩展名,但是通常都使用 .dnx。具体的建模图可能使用 UML 符号,也可能使用其他的符号(举例来说,IDEF1X 或者信息工程学符号用于数据的可见,或者 IBM 属性符号用于设计网络等级)。

这些模型结构指导方针主要是关于如何构造概念模型的产品和内容的。您能够在其他资源中找到用于组织具体模型(亦即执行项目)的内容的指导方针,例如 Rational Software Architect、Rational Application Developer 以及 Eclipse 中的帮助文档。在某种程度上,具体模型的组织是受到 Eclipse 项目类型约定的影响的。然而,关于解决方案的逻辑组织的一个通用原则正如本文中关于团队开发和模型管理的考虑 一节中所描述的那样,既适用于概念的模型,也适用于执行的产品。

在讨论所涉及到的产品中,您将主要通过 Eclipse Project Explorer 同建模文件进行相互作用。

UML 模型文件:逻辑单元和片断

有时,UML 模型过于庞大,以至于不得不将它们保存在较小的片段中。进一步地,当模型团队共同工作于高度相关的模型内容时,内容和所有权的问题就必须加以管理。为了处理这些因素,讨论所涉及的产品提供两种方式将 UML Models 的逻辑内容划分到物理存储(存留)容器中:

  • 逻辑单元
  • 片断

下列属性将一个逻辑单元(LU)描述为被可用软件所支持的(在该软件的后续版本中,这些约定和限制有可能会发生变化):

  • 在软件的用户界面中,LU (逻辑单元)被称作 UML Model。因此,当您执行 New > UML Model 操作时,您实际上正在创建一个 LU。
  • UML Model (以及 LU)是在 File 菜单和 Project Explorer 菜单中能够通过命令被“打开”和“关闭”的 UML 内容的最小单元。(也可以通过在 Navigator 视图中选择它从而打开一个片断,但是这样做将会导致打开包含该片断的 LU。)
  • 每一个 LU (逻辑单元)都具有一个根结点元素,亦即最顶部的包。根结点元素逻辑上包含(拥有或者是其双亲结点)其他的 UML 元素,而这些元素依靠根结点来为容器和名称空间提供它们的需求。因此,在这点上,一个根结点的行为就同任何一个其他的 UML 包一样。然而,根结点的一个特殊属性就是它还将关于 LU 的信息作为一个整体加以储存,例如:
    • 处理 LU (逻辑单元)时有效的 UML 功能的集合;
    • 应用到 LU (逻辑单元)的 UML 剖面。
  • 一个 LU (逻辑单元)被保存为一个扩展名为 .emx 的文件中(请参见图 1 所示)。
  • 最小集情况下,扩展名为 .emx 的文件存储着根结点元素。它还有可能保存着其他的元素,但是有可能将任意一个在逻辑上归根结点元素所拥有的 UML 分类器或者图看作是一个被储存在一个单独的 .efx 文件中的片断。
  • UML Model (逻辑单元)总是作为最顶层的结构出现在 Project Explorer 视图中。换句话说,在当前的 Rational 用户界面中,逻辑单元不能够被可视化的排列为逻辑层次。有可能通过使用 <ElementImport><PackageImport> 关系来创建层次结构。虽然如此,由于一个 UML 模型/逻辑单元总是作为最顶层的条目出现,所以这些将不会被反映为其在 Project Explorer 中所描述的层次。

此外,软件支持模型片断的概念,它具有如下这些属性:

  • 片断被保存在一个扩展名为 .efx 的文件中。
  • 尽管片断被独立的存储,但是在逻辑容器和名称空间方面,它还是完全依赖所属的逻辑单元。
  • 否则,就像逻辑单元一样,片断能够包含逻辑模型的一个子集。
  • 与逻辑单元所不同的是,一个片断并不是必须定义一个逻辑容器结构或者一个名称空间。实际上,一个片断能够在 UML 分类器或者图层次上被定义。举例来说,一个片断有可能仅仅包括一个类、一个组件、或者一个活动,但是一个片断还可能在包层次上被定义,这种情况下,它将同一个名称空间相对应,并且有可能包含其他的元素。但是,再一次强调,由这样一个片断所定义的整个结构仍然是其所属逻辑单元的一个子结点。
  • 由于这一容器个名称空间依赖性的存在,所以一个片断不能够在上下文环境之外被打开。换句话说,要打开一个片断,您就必须打开它所归属的逻辑单元。

在讨论所涉及的产品中,您能够创建多个逻辑单元(作为 UML 模型)。您能够在一个项目中创建一个或者多个逻辑单元,并且同一个工作区中的多个项目能够包含逻辑单元。在同一时间,任何数量的逻辑单元都能够被打开并进行编辑。被包含在不同的逻辑单元中的元素之间的关系可以被定义。

Rational XDE 和 Rational Rose 的移植

Rational XDE 支持一个多模型的范例,它同 Rational 架构管理软件的使用类似。它还支持非常类似 Rational 片断但却被称作子单元的东西。

在 Rational Rose 中,与 Rational XDE 和 Rational 架构管理软件所不同的是,每次只能打开一种模型。因此,在模型之间共享内容的唯一方式就是将内容隔离到 .cat 文件中,然后将该 .cat 文件放置到多个模型里。Rational Rose 还使用 .cat 文件作为一种划分模型储存库的机制。因此,在 Rational 的术语中,Rose .cat 文件能够既被用作逻辑单元,也被用作片断。

正如前面所提到的,您是通过图以及 Project Explorer 同 UML 模型的逻辑内容进行交互作用的。UML 模型是被连接起来的,那些被包含在逻辑单元和片断(模型的逻辑内容)中的元素虽然出现在 Project Explorer 中,但是实际的 .emx 和 .efx 文件(物理存储机制)却并不是如此。以下两点就是非常重要的原因:

  • 多个逻辑单元的使用作为一种物理划分模型内容的方式是逻辑上不透明的。也就是说,您之所以能够清楚的看到 Project Explorer 中反映的逻辑单元,是因为他们总是出现在顶层条目中。
  • 分段的使用作为物理划分模型内容的方式在逻辑上是透明的。也就是说,默认情况下,您看到片断的任意一个指示的唯一方式就是同片断相符合的 UML 元素在 Project Explorer 中被装饰为突出的字体(请参见图 1)。

到目前为止,我们已经讨论了逻辑单元和片断,它们是模型划分的机制。在 团队开发和模型管理的考虑 小节中,我们将讨论如何在模型划分策略中使用这些机制。

这些属于的使用:模型、建模文件、逻辑单元、以及模型/逻辑单元

在上一小节中,我们根据 RUP 将模型定义为一个逻辑结构。然后我们定义了建模文件,并且将逻辑单元精确定义为对逻辑模型内容的单元进行物理存储的机制。在软件的当前版本中,当您创建、打开、关闭、重命名、删除、或者联合“UML 模型”的时候,您实际上是对逻辑单元执行那些操作。在未来的版本中,将逻辑单元组成到虚拟的容器层次中将成为可能,并且“UML 模型”的符号和逻辑单元将变得可以区分。由于当前设计融合了 UML 模型和逻辑单元的概念,所以我们使用精确的术语模型/逻辑单元来指代当前被执行的逻辑单元。这确保您在叙述中遇到模型或者 UML 模型时,能够清晰的理解其逻辑意思,它是与模型/逻辑单元相对的。

以下就是我们如何在这些模型构成指导方针的剩余部分中使用这些术语:

建模文件:除非进一步的限制(例如,作为一个“具体的建模文件”),它通常都被命名为扩展名为 .emx 或者 .efx 文件。

逻辑单元:当把逻辑单元作为一个物理上划分模型的逻辑内容的工具的时候被使用。

模型或者 UML 模型:当讨论通用模型,尤其是 UML 模型的时候被使用,纯粹是从逻辑上来对待。

模型/逻辑单元:当把逻辑单元作为您在用户界面中创建、打开、关闭、重命名、删除、或者联合“UML Models”时被操作的物理产品时被使用。

将模型分派给各个项目

正如我们已经提到的,Eclipse 支持项目的若干种类型,并且讨论所涉及的产品都支持两种模型:

  • UML 模型(概念模型的一个类型)保存为逻辑单元;
  • 具体模型(各种各样的类型)保存为 Eclipse 项目,它包括:
    • 各种各样的文件类型,它们包含基于若干特定技术的样式(例如:网络图)或者 Abstract Syntax Trees (例如:Java™)的语义信息;
    • 扩展名为 .dnx 的文件,它们包含符号信息以及参考的语义元素(换句话说,即是图)。

请记住这些用于将模型分配到项目的指导方针:

  1. 具体的模型自我照看,大体上:【具体的模型】 = 【Eclipse 项目】;
  1. 当您将 UML 模型用于谈论所设计的产品所提供的 Java、C++、或者 C# 转化时:
    • 如果您使用该转化来迭代的运用 UML-to-3GL 的转化,或者如果您既使用前向的也使用反转的转化以及 Reconcile 功能的化,那么请将模型/逻辑单元放到和相应的具体的模型(生成的代码)分离开的 Eclipse 项目中。
    • 如果您使用转化来置换元素,并且您通常使用混合建模(在同一张图中既描述 UML 元素也描述 3GL 元素),将模型/逻辑单元以及生成的代码放置到同一个 Eclipse 项目中。这种情况下,只有设计内容(类层次的建模)应当在这些模型/逻辑单元中,并且其他内容(用例、分析、设计层次的迭代或者状态建模等等)应当在其他的 Eclipse 项目中的单独的模型/逻辑单元中。举例来说,使用不同类型的多个 Eclipse 项目(例如:Java、Web 和 Enterprise Java™Beans (EJBs))可以有特定的约定来包含一个企业级 Java 解决方案的执行。
  1. 否则(当转化没有进行的时候),您能够将同特定的具体模型紧密关联的概念(UML)模型放置在同一个 Eclipse 项目中的一个名为 Conceptual Models 的文件夹中。这反映出架构的高度功能性内聚原则,这是模型构造指导方针主题的再现。
  2. 通常来说,Eclipse 项目的目的之一就是作为配置管理的一个纹理粗糙的单元。因此,如果一个特殊的模型/逻辑单元被一个特殊的从业者组织起来支持强大的所有权的话,那么它就应当成为一个单独的 Eclipse 项目。关于这一主题的变量出现在这种情况下:一个单个的从业者强有力的拥有一组和特殊的功能关注相联系的模型/逻辑单元,但是那个从业者模型的关注横过周期并且希望使用单独的模型/逻辑单元用于指定该功能关注的用例、分析、以及设计层次的建模。在这种情况下,将那些多个模型/逻辑单元放置到一个单独的、面向功能性的 Eclipse 项目中,并且将所有的用于整个开发周期的概念模型一起放置到那个项目中是有意义的。。然而,先前的指导方针是关于使用转化的,如果可以适用的话,它将优先与这个指导方针。
  3. 模型/逻辑单元反映的是共同的关注,它们必须被若干其他的高内聚、低耦合的模型/逻辑单元所引用,并且应当被放置到 封装那些共同关注的 UML 项目之中。举例来说,如果一个用例模型被多个项目的内容所引用,那么它就不应当存在于任何一个引用项目中。相反地,它应当存在于其所拥有的项目中或者聚集了大量其他共同关注的项目中。

Rational XDE 和 Rational Rose 的移植

操作的 Rational Rose 和 Rational XDE 理论包括迭代地重定义设计模型直到达到一个相当于代码层次的抽象的实践,然后使用代码模型同步技术保持该模型的语义同代码本身相一致。因此,举例来说,在 Rational XDE 中,实施模型不仅作为项目中的代码和图存在,而且作为包含 UML 语义的代码模型文件存在,并且独立于执行产品被存储。大体上,这些反映了代码语义冗余的副本,在 UML 中被表达。进一步地,在 Rational XDE 的 Java 版本中,由于这一规则的影响,UML Java 代码模型必须位于和 Java 代码同一个项目之中。

讨论所涉及的产品并不支持 Rational Rose 和 Rational XDE Autosync 模式。相反地,在抽象的代码级上,您仅需描画直接描述代码语义的图(使用类似 UML 的符号)。再次强调,这就是我们所说的具体的建模。

UML 模型的类型

在讨论所涉及的产品中,UML 模型的字体是被加重键入的,但是您能够一种使用多个模型/逻辑单元的约定。您能够下列两种方式中的任意一种建立不加重的键入:

  • 以一个空白的模型/逻辑单元开头,并且仅仅根据您如何命名它和您放入其中的内容(包括您将应用何种 UML 剖面)对其建立类型。
  • 根据预先定义的同模型的一个特殊类型相对应的模板创建一个模型/逻辑单元。讨论所涉及的产品为本文所描述的模型类型提供了一组默认的模型模板。。您还能够将您自己的模型/逻辑单元创建为模板来使用。

任何一种方式,被称作模型的“类型”都实际上是关于命名和模型/逻辑单元内容,以及别应用到其中的 UML 剖面的约定。举例来说,该工具将不会阻碍一个模型/逻辑单元,根据约定,它就是一个来自和包含实现了用例的类(RUP 指导方针将考虑成为分析和设计模型的一部分)的用例模型。

基本概念总结

假设您有若干个团队在处理一组应用程序,它们是构成一个大型的、集成的卫生保健提供者网络的组成部分,它们被选中用来(未必真实的)开发大多数关键的应用程序。在这种情况下,下列因素(其他许多因素也有可能)必须被考虑进来:

  • 若干团队处理核心的或者共享的功能,它们被多个解决方案所使用:
    • 暴露和维持卫生保健应用程序中所使用的编码词汇量的一致性的服务;
    • 反映访问使用该应用程序的关键实体(病人、提供者、付款人等)的服务;
    • 控制哪一个系统用户访问应用程序的哪一个特性的共享的应用程序。
  • 一些团队处理 Laboratory Information System (实验室信息系统,LIS)解决方案的各种子系统,它们负责以下任务:
    • 处理实验室服务指令;
    • 管理和返回实验室结果。
  • 一个处理 Radiology Information System (X 光信息系统,RIS)解决方案的团队将负责以下任务:
    • 处理 X 光服务指令;
    • 管理和返回 X 光结果;
    • 安排 X 光服务。

图 1 举例说明这些团队可能采取的一些划分其模型以反映其对特定功能性的所有权的方式。目前为止,我们忽略了概念模型类型是什么的问题,并且我们并不试图展示相应的执行项目可能是什么样子。相反地,我们需要将焦点关注在他们可能选择的不同的模型划分策略上。

图 1. 不同团队可能的分割模型的方式的实例
不同团队可能的分割模型的方式的实例

重要注释
简要起见,图 1 显示了单个工作区中的所有项目。在一个现实世界的情况中,每一支团队都是不一样的。举例说明,假设在 Radiology 和 Laboratory 系统之间不存在直接的依赖关系,处理 LIS 和 RIS 团队的工作区中就有可能仅仅包括共享的 Eclipse 项目,并且他们依靠这些项目添加他们自己的 Eclipse 项目。一支拥有共享代码词汇表的团队的工作区有可能仅仅包括一个在其自己的 Eclipse 项目中的核心功能模型/逻辑单元。此外,LIS 团队还将它的多个模型/逻辑单元分配到它自己的 Eclipse 项目中,从而使得那些资源能够被处理,并且配置信息能够作为独立的单元被更加有效的管理。

在这一场景中,我们将看到如下这些结果:

  • 处理 RIS 的团队已经选择不对他们的模型进行划分。也许这反映出在这个团队中,一个人完成了所有的建模工作,而其他人负责编写代码。
  • 处理 LIS 的团队已经选择通过使用多个模型/逻辑单元进行划分。也许这反映出 LIS 架构是非常健壮的,并且由大量高度粘着的子系统所组成,所以,团队的个体成员很少需要看到他们所“拥有的”整个 LIS 内容的上下文环境中的内容。
  • 处理共享功能的团队已经在他们的划分策略中使用了模型/逻辑单元片断。也许这是因为他们一旦排外地使用了片断划分,单个的模型/逻辑单元就将被证明为并不方便作为发布该模型的基础。或者,也许他们的选择仅仅反映出他们关于逻辑容器结构深度的偏好,并且他们能够以此组织模型的内容。

团队开发和模型管理的考虑

Rational XDE 和 Rational Rose 的移植

Rational Rose 和 Rational XDE 中的 Model Explorer 仅仅提供了 UML 模型的一个逻辑视图;而在讨论所涉及的产品中,Project Explorer 使您能够在一个视图中看到模型的各种各样的逻辑视图(UML、Java、Web 等)。

在不考虑规范是一组文档、一组模型、还是一个代码库的情况下,对协作工作在任何类型规范的团队来说,最根本的挑战就是:控制变化。

通过基于文档的规范,团队有如下几种选择:

  • 那些被包括在一个共同文档中的负责一个规范的特定方面的团队顺序地开展他们的工作。只需打开变化跟踪功能并且将文档从一个贡献者传递到下一个贡献者。周期性地,某些职权回顾并且接受或者拒绝改变来建立一个基线。
  • 贡献者并行地工作。为了建立基线,职权必须对所有贡献者共享的文档执行一个多文档的合并(要么使用词汇处理器的功能,要么使用配置管理工具的文本合并功能)。
  • 规范被划分到多个被个体的团队成员所强壮拥有的文档中,这些团队成员能够并行的工作而无须为合并创建一个需要。但是通常(为了避免创建规范的某些部分的多于副本)可能有一个被指派的公共内容的强壮所有者,他根据其他团队成员的要求做出变化。另外,也可以是公共的片通过使用一个合并策略被加以管理。

在每一种情况中,必须存在一种关于文档版本如何被保存、保护以及合并和调解,以及这些操作的执行频率的策略。

对于一个代码库来说,存在相似的问题。然而,在源文件中使用变化追踪并不是我们的选项(代码编辑器和 IDE 不是用于那些操作的)。因此,当源代码并不是被强壮的拥有的时候(相反,它们被多个团队成员所同时处理),团队就必须依赖于配置管理系统的增量追踪和文本合并功能。通常,代码库也引入处理多个版本或者并行地表现不同发布版本的同一段代码流的挑战。将某些变化从一个流移动到另一个流的任务在某些情况下也能够通过一个配置管理工具的合并功能来负责。

模型能够和代码一样表现所有的挑战,特别是在模型开始表达被代码所表达的详细方法的时候。模型更加抽象,所以相比之下可能不能胜任变化管理方法,也许更加接近规范文档所实践的内容。但是模型还能够表现它们自己的特殊挑战:

  • 模型中的链接(互相依赖)的数量和方向性较之代码基础来说更加复杂。
    • 代码将仅仅通过引用名称供应者来执行一个依赖,模型执行关系作为实际的语义元素(例如:Association、Generalization、Realization)。这些元素必须被小心地管理以避免模型的过度紊乱。
    • 模型较之代码支持一个更加丰富的关系类型的集合。因此,举例来说,不仅会出现一个模型元素使用或者专用于另一个元素的情况(类似于一个 Java 类可能使用或者扩展另一个 Java 类),而且模型元素还有可能重新定义另一个元素(在抽象层方面)。
    • 模型语义元素通常可能被多个描述全部规范的不同方面的图所引用。
  • 在模型中,移动分解的变化会产生严重的影响,这是因为包和命名空间容纳和在代码中相比被更加严格地指定。在模型中它通过实际的逻辑链接以一种持久(静态)的方式被完成;相反,在代码中它被编译引擎所动态地操作。
  • 引起问题的另一个原因就是那些模型经常首先使用类元素(例如:联合和抽象),在代码中它们仅仅是通过名称被引用。这些元素必须被小心地加以管理,否则它们就会导致模型的紊乱。

当您的实践涉及到模型文件的当前团队开发(共享的所有权)时,在要去合并的文件中会导致不协调的变化。这种环境下可能出现的并行开发处理过程包括以下这些例子:

  • 一个用来检查非专有访问的建模文件。
  • 一个在多个从业者的开发流中并行处理的建模文件。

如果出现某些变化同另外一个变化相冲突的情况,那么合并就被认为是重要的,这是由于某个人必须决定哪一个冲突的变化应当获胜。(一个不重要的合并是指不协调的变化并不发生冲突,并且模型合并工具能够在没有人为干涉的情况下执行合并操作。)讨论所涉及的产品提供强大的功能来支持重要的和不重要的模型合并,但是重要的合并能够表现为了调解它们,个体所进行的重要的工作。

贴士
当明确叙述一个模型组织策略以帮助团队建模的时候,应当把避免重要模型的合并作为首要目标。

团队建模:通用法则

在进入关于模型组织技术的讨论之前,我们必须首先讨论指导一套模型划分策略的通用法则。请记住我们的目标是避免重要的合并,主要的法则有两条:强壮的架构和强壮的所有权。它们相互关联,即只有强壮的架构才能使强壮的所有权变得可能。

法则一:强壮的架构

在本文中,强壮的架构主要是指分解。在此处所应用的架构分解的法则同驱动面向对象的开发、基于组件的设计、以及面向服务的架构中的法则是一样的。

  • 努力做到最大化的功能内聚性。
  • 努力做到最大化的业务功能耦合性。
  • 首先将那些必须保持紧密联系的事物放在一起,然后将各个分组分割开来。

如果您得出的分解过于详细的话,那么依赖您的模型(请记住:强壮的架构和强壮的所有权是共进退的),您可能希望将那些细节合并到更加紧密的集合中(在 UML 建模中,这就意味着 Package)。

总是有一些东西必须被许多分解单元触碰到(在某些情况下是所有单元)。将那些东西合并到共同的子范畴或者组中,并且反复进行这一过程,从而使得在迭代初期包括的一些偏差能够稳定下来。

还有一个时间元素。随着您对解决方案的理解从较为抽象变为较为具体,您对架构(以及模型)这一最佳的组织的感觉也会不断发展。相应地,计划重新分解(重新组织)一个正在进行的基础。

如果您看到您的解决方案和所有事物都表现出高度的相互依赖和紧密的联系,那么就意味着您真的不能分解这个问题。您只有以下两种选择:

  • 将该项目分配给一支非常小的团队,团队各个成员之间都能够非常积极的进行沟通,使得每个人都知道别人所做的改动对整个系统可能带来的影响(根据您的建模工作应用敏捷的开发法则)。
  • 准备好执行大量重要的合并。

一种观察面向模型的强壮架构的好方式就是检查在代码库中出现的架构有多么强壮。此处,我们清晰的看到首先稳定普通片然后分层特殊片的法则。考虑一个假定的面向基于 Java™ 2 Platform Enterprise Edition (J2EE) 技术的架构的解决方案,如图 2 中所描述的那样。

图 2. 基于 J2EE 解决方案的假设的架构
基于 J2EE 解决方案的假设的架构

Rational XDE 和 Rational Rose 的移植

如果您是一位 Rational Rose 或者 Rational XDE 的使用者,您可能经历过重要的模型合并的困难。幸运的是在 Rational 架构管理软件中重要的合并远比以前简单。保存模型的方式使得为合并片断而保持更丰富的上下文成为可能。它还拥有更加出色的比较-合并工具:

  • 后端合并引擎的速度是 Rational XDE 后端速度的 10,000 倍(是的,的确是一万倍)。
  • 它还实现了诸如复合增量(通过图对变化进行分类,并且将大的图表示合在一起使得组或者原子操作得以进行的一组机制)、模型完整性保护、原子性、以及层叠增量处理等技术。这些降低了合并破坏模型文件的可能性。
  • 可视化的图合并 GUI 能够用来解决布局和化解冲突。

这里,我们看到 Java™ 平台标准版本(Java SE)的 API 是十分稳定的。Java 2 平台企业级版本(J2EE)的 API 的稳定性也基本接近 Java SE。它们都是被所有的服务和应用程序所使用。在基本的 J2EE 框架之上,我们看到类似用于“共同的”数据和共同的效用的访问层的东西。同样地,它们也是被所有的服务和应用程序所使用,所以它们独立于服务和应用程序,并且在项目的早期就稳定下来。在这些之上,还有一个共享的或者公共的服务层(如果您喜欢的话,也可以称之为组件)。这些依赖于下面的层以及所有使用它们的应用程序,所以,理想情况下,在应用程序被建造在它们之上之前,它们十分地稳定。

这些法则以一种通用的简单易懂的方式转化为模型。但是当涉及到代码时,直观上(至少是在开发人员看来)架构中的提供者(提供了其他部分的用户需要使用的东西)就是接口(API),而消费者(使用那些被提供的东西)就是执行。在模型中,并没有这种区别。受到 UML 元模型的约束,任何一个模型元素都可能成为一个提供者、消费者、或者两者兼备。这取决于建模团队建立模型管理和相互依赖的约定。

法则二:强壮的所有权

不顾专门技能集合的问题,在您已经建立强壮的架构分解之后,将强壮的架构组件的所有权映射到个体的从业者上应该被证明是非常简单易懂的。当模型管理的每一个单元都能够被一个从业者专有地进行处理的时候,潜在的介绍冲突就被限定在那些需要跨单元关系的地方(图中的其他依赖、关联、描述的重定义或者使用,等等)。当强壮的所有权存在的时候,无论组织单元是否由整个模型/逻辑单元或者一个模型/逻辑单元中的包所组成,也不论这些包是否被配置为片断,合并大多都是价值不高的,因此是快速的和相对无痛的。同样说法适用于每一个组织单元都能够在同一个位置被一支小型团队专有地处理的情况,团队成员能够调整他们的努力来避免他们的子单元中冲突变化的引入。

Rational XDE 和 Rational Rose 的移植

另外一个不同之处就是 Rational Rose,由于它缺乏对多个逻辑模型的支持,所以鼓励(实际上是强迫)组织模型的实践进入到单一逻辑模型内的一组层级中。因此,Rational Rose 用户有可能试图尝试和 Rational 架构管理软件中相同的方式来保持他们的“舒适地带”。但是不对新的 Rational 软件的新增的灵活性进行探索,将导致较少的 Rational 团队建模经验的获得。

团队建模:模型划分

基本概念和术语一节 中,您学习到 Rational 架构管理软件提供两种方式划分 UML 模型的物理持续性:模型/逻辑单元和片断。(重要提示:如果您错过那一部分的话,那么现在请您回过头去阅读它。)这一小节回答了以下这些问题:

  • 我应当何时划分?
  • 在划分时,我应该使用多个模型/逻辑单元还是片断作为机制?

做出这些决定的影响因素包括:

  • 模型大小和复杂性。模型由于其大小或者其逻辑容纳(包)结构的深度而变得不实用,所以必须将它们划分到多个模型/逻辑结构或者片断,以提供操作的执行性能和便利性(例如:报告)。
  • 模型组织。那些强壮的架构和所有权的模型相比之下不需要划分。模型组织的架构强度也可能影响一个配置管理解决方案的选择,这是第三个影响因素。
  • 配置管理(CM)软件的选择。某些 CM 工具较之其他工具能够支持对模型的高度划分。
  • 转化的使用。某些转化的设计反映了那些可能影响模型划分决定的约束条件。举例来说,讨论所涉及的某些产品中提供的标准 Java-to-UML 转换只允许一个模型/逻辑单元作为它的目标。因此,如果需要分别转化多个 Java 项目,最好是为每个项目都建立一个单独的模型/逻辑单元。

实际上,我们可以很容易的预期出于大小和复杂性的原因,模型何时需要被划分。对于用户社区中使用的机器来说,当文件增长得过大的时候就需要进行划分。举例来说,达到 30MB 的模型对于 1GB 内存的机器来说将变得非常难以处理。一个划分的指导方针是:任何时间有 5-10MB 的模型在内存中运行。另一种可选方案就是升级内存,这样做所带来的好处就不仅仅是针对建模的。一个 2GB 内存的机器几乎能够使每一项 Eclipse 操作都变得更加快速。同时这样做也进一步加速了大型模型的执行。

处于团队原因划分模型也是一个不足的讨论。只要当您所创建的模型文件(模型/逻辑单元或者片断)能够既被专门的处理(在任意时间点上只有一个团队成员核对文件),并且也被隔离(大多数变化都能够在不需要访问其他的包含相关模型元素的文件的情况下进行)的情况下,才试图这样做。这是处于折衷的考虑。划分缩小了在合并期间可以使用的逻辑上下文的范围。随着逻辑上下文的减少,人工调解器在作出合并决定的时候就必须更加依赖臆测。简而言之,更少的划分对于合并来说意味着更好的上下文环境。

有一个问题经常会被提及:是否能够通过将模型划分到多个模型/逻辑单元或者片断中来避免重要的合并呢?答案是:不可以。

然而,这个“不可以”中也包括如下这层含义:如果您使用一个能够有效地支持锁定安排的 CM 解决方案的话,那么物理划分就能够作为避免合并的一种手段。它还限制了您所能进行的扩展。举例来说,当处理一个离散的划分时,您就不能在没有核对和修改需要该操作来更新的每一个其他划分的情况下执行一个重命名操作。

架构互相依赖是一种逻辑现象,而不是一种物理现象。当您将一个模型划分到多个模型/逻辑单元或者片断的时候,元素的互相依赖仅仅表现为跨文件的引用而非文件内部的引用。这并不意味着可以更加容易的解决冲突(实际上是更加困难了)。当您引介跨文件的引用时,您同时也引介了潜在的破损点(请参见工具条)。

某些划分方式通常是不可避免的。当您必须进行划分时,您可能会在是选择模型/逻辑单元还是选择片断作为物理划分机制而踌躇。请您将下列这些关于模型/逻辑单元和片断的基本要点熟记于心:

  • 片断保存了模型的分级容纳结构的外貌,反映在 Project Explorer 之中。
  • 模型/逻辑单元作为分割的顶层容器出现在 Project Explorer 之中,并且不能够(在此时)被嵌套在其他的逻辑容纳结构中。
  • 片断会放缓 CM 系统,这是因为它必须处理更多的文件。
  • 片断还会放缓某些模型处理操作,例如报告。但是它们也能够加速另外一些操作。
  • 片断能够被合并,但是当您合并它们的时候,您将不能获得多少关于模型上下文的信息,并且冲突的改变增加了合并后模型不一致的可能性。
  • 模型/逻辑片断的使用通常提供相当数量的上下文在并行期间支持容易理解和安全的合并,除非出于某些原因,您将模型制作得很小(例如:当您试图使用模型来打包 UML 内容的位时,而您将这些内容视作可重用的资产)。
  • 一个模型/逻辑单元合并机制同 IBM® Rational® ClearCase® 远程客户端用户接口共同存在。它恢复了用于广泛分布的冲突改变的上下文,但是也减缓了合并的处理过程。
  • 模型/逻辑单元可以很好地被 Unified Change Management (UCM)机制所支持;相反,片断则存在限制。
  • 模型/逻辑单元处理所有的 ClearCase 用户接口和命令行;相反,片断则存在限制。

将这些因素考虑进来,进一步思考以下这些作为更可取的选项:

  • 如果团队位于同一个位置并且更加倾向于避免合并(特别是当模型非常大的时候),那么请您考虑使用带有动态视图的、共享一个综合流、并且保留校验的 Rational ClearCase,并且将该模型划分为片断。
  • 如果团队是地理上分布的,那么请您考虑以下一种选择:
    • 使用 IBM® Rational® ClearCase MultiSite®,每个位置都有一个主要的模型/逻辑单元,并且通过 UCM 在中心进行合并。
    • 使用 Concurrent Versions System (CVS),模型被划分为多个模型/逻辑单元。
    • 使用 CVS,模型被划分为片断。这要求强壮的所有权来尽可能地避免合并的发生,这是由于任何合并都将同很少的上下文一起被执行。

跨建模文件的引用

只要两个建模元素存在与不同的建模文件之中,并且您创建了它们之间的联系,那么您就创建了一个跨建模文件的引用。由于建模文件(扩展名为 .emx)暴露在主机操作系统的文件系统中,并且能够被移动、重命名,但是却不能在 Eclipse 环境之外被修改,所以这些引用反映了破损量的潜在点。然而,只要建模文件总是在 Eclipse 环境中被修改和管理,并且在您不妨碍这些指导方针的前提下,您就能够避免破损量。

只要您处理(编辑)一族建模文件(亦即一个彼此引用的建模文件的集合),您就能够试图将那一族中的所有建模文件呈现在工作区中。这并不严格的意味着一族中的所有建模文件都贮存在同一个项目中。 虽然如此,通常来说还是使用单个项目能够确保所有的模型都被呈现出来,这是因为在典型的 CM 工作流程中,所有的建模文件都在同一个项目中一同转化。但是如果由于您并没有访问您的“消费者”所建立的模型而导致这样做并不奏效的话,那么您就不能假设在做出变化时您能够重新代理所有依赖于您的其他内容。因此,将元素从一个资源(扩展名为 .efx 或者 .emx 的文件)移动到另一个资源的代价对于您的消费者来说是十分昂贵的。Rational 架构管理软件为这一操作提供了支持,但是它仍然会消耗您的消费者宝贵的时间,这是因为他们必须运行 Validation (确认),点击每一个断掉的引用,并且逐一进行修复。

将模型元素从一个片断移动到另一个片断会破坏跨文件对被移动元素的引用。出于这个原因,将共同模型(那些有许多其他面向功能的模块所共享的)组织为非片断的模型/逻辑单元是一个非常好的想法。由于共同模型内容大小的原因,这并不可行,某些从业者已经创建出了被称为“接口”的模型/逻辑单元。这些模型/逻辑单元独立于其他的消费者需要引用的特定元素的共同内容。

场景

我们来看一下目前为止我们所讨论的关于团队建模的每一件事情是如何应用到特定场景中的。我们将根据第一条法则来组织场景:在模型被强壮的设计之后,强壮的所有权是否就被实践了呢?第二项考虑将是:什么是 CM 解决方案?

良好设计的模型架构:

模型特征:

  • 包结构反映出高度的功能内聚性、低耦合性、以及强壮的个体从业者所有权。
  • 被多个功能区域所使用的包(因此许多从业者作为消费者或者共同所有者)被独立于强壮的所有权内容,较早的稳定下来,并且被处理过程的约定所紧紧的控制起来。

按照从最佳到最劣的排序,典型的最佳包括:

  1. 使用一个单独的非片断的模型/逻辑单元。合并将会发生,但是重要的合并应当极少出现,即使它们出现时,也将是在一个完整的模型上下文环境中。
  2. 将一族多个模型/逻辑单元和跨文件的引用结合起来使用。合并将会较少的发生,而上下文关系仍然适度紧密。
  3. 使用一个单独的模型/逻辑单元和有细密纹理的片断。使用一个配置管理解决方案(例如 ClearCase 并且以一种共享的、动态的观点来看待强制保留校验的综合流),它有效的控制了文件(片断)的改变。
  4. 使用一个配置管理系统,例如 ClearCase 或者 CVS,它们能够同步整个工作区,并且允许当那个层上发生冲突时(尽管可能性很小)对个体的片断进行合并。

设计并不十分良好的模型架构:

模型特征:

  • 包是高度相互以来的;
  • 相关的关系并没有被强壮的分组或者所有。

按照从最佳到最劣的顺序:

  1. 使用一个带有细密纹理片断的单独的模型/逻辑单元,结合一个锁定变化文件(片断)的配置管理解决方案,例如 ClearCase 并且以一种共享的、动态的观点来看待强制保留校验的综合流。
  2. 使用一个单独的成碎片的模型/逻辑单元。使用带有私有视图的 ClearCase (静态的或者动态的)。实践 UCM 并且交付用于保持每一个从业者的私有副本的完整性。UCM 还提供了原子性交付,从而那些失败的合并能够被轻易的收回。随着冲突集大小的增长,合并变得越发具有挑战性和冗长。它将在综合中增长,尽可能频繁的进行一体化。
  3. 使用一族许多内部相关的模型/逻辑单元。合并将是十分复杂的,而且用于那些合并的上下文关系并不密切,但是模型/逻辑单元的足迹将会更小,并且冲突更加不频繁。再一次指出,频繁的结合降低了文件层次上冲突改变的可能性。

我们再次进行一下总结:

将模型划分到多个文件中并不如将模型逻辑地组织起来使得多个从业者并行的工作于一个模型文件上而不引起冲突变化那样重要。如果下列这些条件存在的话,那么强壮的架构和强壮的所有权将是成为强大生产力的关键因素:

  • 如果您缺乏强壮的架构,或者您具备强壮的架构但是却缺乏强壮的所有权,那么您将经历那些无论多少模型划分也无法减轻的频繁的重要合并。
  • 如果您拥有强壮的架构和所有权,那么您将大大减少(但并不能完全消除)重要合并的频率。您不能完全消除的原因在于总是存在组件的相互依赖性。上述共同的元素是一个例子,尽管它是唯一的例子。

幸运的是讨论所涉及的产品较之其他任何一款建模工具能够更快的处理模型的合并。

图 3. 模型管理和划分考虑的总结
模型管理和划分考虑的总结

划分模型的技术

下列技术可以用于管理模型和划分模型:

  1. 在项目中创建一个新的模型/逻辑单元;
  2. 中断一个现已存在的模型/逻辑单元的包,使得这个包成为一个独立的模型/逻辑单元;
  3. 将两个已经存在的模型/逻辑单元合并到一个模型/逻辑单元中(该操作被称为融合);
  4. 将一个模型/逻辑单元划分到多个片断中;
  5. 吸收片断到模型/逻辑单元中(创建片断的逆过程);

完成这些操作所使用的特定的菜单、对话框和向导,请参见“帮助”一节。

其他实用的工具和技术

正如前面所提到的,当模型组织的每一个单元都能够被一个从业者专门进行处理的时候,引入冲突的潜力就被限制在那些需要跨单元关系的地方了(改进、使用或者其他的依赖、关联、图中的描述,等等)。在一个典型的模型中,许多跨单元的关系都是在表达问题或者解决方案的不同方面的多个图描述相同的语义元素的结果。下列技术对于最小化管理这些关系的种类来说是十分有用的:

查询驱动的图
同典型的图相比,无论您将您所希望描述的元素放到哪个地方,一个查询驱动的图的内容都将通过运行一个对当前状态模型内容的查询被决定移植该图,以反映自它上一次被查看以来所发生的语义学变化。查询驱动图而非手动绘制图的使用,能够降低可能发生的与图相关的合并冲突的数量。讨论所涉及的产品支持两种类型的查询驱动图:Topic Diagram (主题图)和 Browse Diagram (浏览图)。

  • 主题图:为创建一个主题图,选择一个主题模型元素或者元素的集合,然后定义那些您希望显示在图中的其他元素,基于它们同主题元素之间的关系的类型。当模型的语义内容发生变化时,描述变化的语义元素的主题图也随之进行调整。一个被命名的主题图的定义能够被保持,从而能够在任何时间都返回相同的查询。主题图能够在 UML 模型文件中被保持,但是它们还能够在 Eclipse 项目中被直接保持。它们被自动呈递的事实意味着它们能够被模型合并所忽略,因此从团队建模的观点来看将它们变成手绘的图是具有吸引力的选择。
  • 浏览图:这些类似于主题图,在那里您首先选择主题元素,然后定义管理将被描述的相关元素种类的过滤器。然而,浏览图并没有一个一成不变的定义。它们的目的是通过使您能够以图形的方式在模型中导航,推动对模型内容的发现和理解。在一个具有被选中的焦点元素的浏览图被呈递之后,您就可以双击任何一个相关的元素来创建另一个将那个元素作为焦点元素的浏览图。您还能够在浏览时重置关系过滤器。此外,您可以向前和向后导航被生成的浏览图的栈(或者导航回到主图),就如同名称中所暗示的那样。

架构总体模型
作为全部建模工作的一部分,您可能已经发现定义一个 Architecture Overview Model (架构总体模型)对于捕获您的架构的高层视图来说是十分有用的。该视图有助于您理解如何组织和划分您的其他模型(在其他可能的使用之中)。您创建这样一个模型的意义以及您影响它的方式随着您的项目的发展依赖于大量的因素,例如您的全面的开发处理过程和您对建模方法的选择(例如,一种基本的 RUP 方法或者业务驱动开发方法)。因此,任何关于它们使用的详细讨论都属于这些指导方针的特定风格部分。

Rational XDE 和 Rational Rose 的移植

在 Rational XDE 模型构造指导方针中,Implementation Overview Model (实现总体模型)被推荐作为一个提供执行的子系统层级的总体看法的设备。每一个子系统的细节随后在执行子系统的项目的代码模型中被指定。

Rational 架构管理软件中的 Architecture Overview Model 的目的有一些不同,它更多的面向将全部的软件架构理解为一个对规划模型划分和组织策略的帮助。(请注意:Implementation Overview Model 和 Architecture Overview Model 都不被传统的 RUP 识别。)

为了提供对这样一个模型可能影响的范围和抽象水平的直观印象,请考虑图 4 所示的情形。这幅图描绘了代码基础是如何被分割到模块中用于强壮的架构和所有权的。但是它还指出在一个 Architecture Overview Model 中您可能表达的架构总体看法的种类。

您还能够使用一个架构总体模型来勾画预期的工作区结构,如图 4 中所示。

图 4. 架构总体模型的实例
架构总体模型的实例

架构总体模型的另一个可能的用途是捕获您的解决方案的不同方面的信息图,例如图 5 中所示的一个拍卖系统的高度概念的图。

图 5. 一个拍卖系统的架构的图
一个拍卖系统的架构的图

当然,一个架构总体模型能够被用于这种目的的任何一个结合。您还能够将它用作一个从解决方案的细节模型中收集图的地方,从而您就能够描述那个解决方案的各种各样的架构的重要观点。更正式一点的说法是,您能够将其作为 RUP 软件架构文档的等价物。鉴于用作对讨论所涉及的产品中可用的模型进行组织的工具(例如支持多个带有跨文件引用和图链接的模型文件),它成为这样做的微不足道的因素(在下一小节“组织模型的逻辑内容的通用技术”中将描述这些工具)。举例来说,如果您希望创建一个呈现“架构的 4+1 视图”的模型的话,那么您可能需要沿着图 6 中所示的线索完成一些工作。

注释:
我们所展示的这个例子并没有一个用于过程处理视图的包,这是因为这个例子中的系统并不过多的以并发的方式呈现出来。

图 6. 描述架构的 4+1 视图的架构总体模型的可能的高级组织
描述架构的 4+1 视图的架构总体模型的可能的高级组织
  1. 创建一个模型/逻辑单元,并且用一组同 4+1 视图相对应的包移植它(<透视图> 在下一小节中还会对包加以描述)。
  2. 然后,在软件架构文档模型中使用以下方法创建图:
    • 使用 UML 语义元素从其他模型文件中创建图,并且它描述那些没有在其他模型文件中找到的但却是架构文档所需要的新的视图。
    • 创建由软件架构文档模型文件中的几何图形或者 ad-hoc 元素所组成的图。(这样的 UML 元素应当仅仅用于记录文档或者澄清分类,并且应当对于所描述的解决方案的实际执行不具备重要的语义学意义。)
    • 创建仅仅包含到其他模型文件中现已存在图的链接的图。如果架构文档模型文件同其他的模型文件一并被分发到读者的话,这一技术将会很好的发挥作用。(相反,如果架构文档将要被发布到网络的话,那么请遵循其他的方法。)

关于团队建模的其他信息

如果您正在准备着手开始一项团队建模实践,那么由 Kim Letkeman 所撰写的发布在 developerWorks 上的“在 IBM Rational Software Architect 中比较和合并 UML 模型”(共七部分)将成为一份不可或缺的重要参考资料。其中,第 5 部分尤其具有价值(请参见:参考资源 一节)。第 1 部分到第四部分以及第 6 部分也十分具有价值,但是它们稍微有一些陈旧,并不能反映出 Rational 团队建模能力的最新进展,例如比较-合并的提高和对模型片断的支持。第 7 部分“Ad-hoc 建模:通过图融合两个模型”涵盖了两个个体独立的开发一个被提议的解决方案中的它们自己的模型,并且现在希望合并它们的场景(一种并不像您所想象的那么不普通的情况)。

如果您有兴趣阅读更多关于管理依赖以达到强内聚性和低耦合性的通用法则的内容,一个很好的资源就是:由 Rober C. Martin 撰写的 使用 Booch 方法设计 C++ 应用程序 (Prentice Hall,1995年),第三章,内聚性、闭合以及可重用性。


用于组织模型的逻辑内容的通用技术

组织 UML 模型的逻辑内容的主要工具就是模型/逻辑单元(正如上一小节中所讨论的那样)和 UML 包。UML 包主要用于两个目的:

  1. 通过对问题或者解决方案域中一个特定主题相对应的元素进行分组,逻辑上划分和组织模型信息。
  1. 分割不同类型的模型信息。例如:接口、执行、图等等:
    • 分组元素来定义和控制它们彼此之间的依赖关系;
    • 对为同一个模型提供不同视图的图进行分组;
    • 建立命名空间;
    • 用于模型元素;
    • 用于从模型元素中生成的执行产品(这种方法涉及到模型和执行语言命名空间之间的映射);
    • 用于单元的重用。

讨论所涉及的产品还支持另外的组织工具,它们主要有助于模型如何被导航以及图如何被分组。(一种导航功能,浏览图已经在上一小节中被讨论过。)

通过使用 <perspective> 包体现观点

我们希望看到元素以多于一种的方式被组织起来,您能够通过描述不同组织安排的图创建额外的包。这种技术能够被应用到需要反映模型内容的一个特殊视图的任何地方。讨论所涉及的产品通过提供一个<perspective>包模板作为它的 UML 基本剖面来支持这种技术。您能够将一个<perspective>考虑为用于模型驱动的系统开发或者 IEEE 1477-2000 观点的 RUP 的通用等价物。

<perspective>模板应用到包中完成了这样几件事情:

  • 可视化的将包识别为反映一个特殊的观点;
  • 支持一个模型验证规则,它警告您语义学元素何时被放置到 <perspective> 包中。
  • 指派那些应当由 Rational 转换绕过的包。

大多数情况下,<perspective> 包意味着仅仅保持那些描述基于不同组织关注或者应用程序观点的视图的图。然而,在一些情况下,您可能希望将语义元素放置到<perspective> 包中:

  • 为了防止那些元素被转化所处理。
  • 为了描述 <perspective> 中的行为。讨论所涉及的产品将行为(或者称作“机器”)图看作是“规范的”,这意味着这些图的内容必须全面的并且专有的反映拥有该图的 UML 语义元素的语义学:
    • 一个活动图必须被一个活动所拥有,并且必须全面的和专有的描述该活动的语义学;
    • 一个 Sequence (顺序)图或者 Communication (交流)图必须为一个 Interaction (交互)所拥有,并且必须全面的和专有的描述该 Interaction (交互)的细节;
    • 一个状态机图必须为一个状态机所拥有,并且必须全面的和专有的描述该状态机的语义学。
    因此,如果您需要在一个仅仅反映同一个特殊的透视图相关联的关注的抽象层上组成一个活动图的话,您就必须在您所希望表达的语义细节的<透视图>包中创建一个活动。

在这种情况下,我们忽略在<perspective> 包模板中验证规则关于语义内容的警告。

使用图间导航

在讨论所涉及的产品中,有两种机制支持图间的导航:

  • 您能够从 Project Explorer 中将一个图节点拖动到某个其他的“主机”图上面。然后,双击该主机图上面的图,就可以打开被引用的图。
  • UML 模型中的任何一个包都拥有一个默认的图。包中的默认图提供特殊的行为:如果您将包放置到任何模型中的任一个图上,然后双击该包的图标,就可以打开包的默认图。

注释:
您能够设置图的参数,以便无论何时您在模型中创建一个新的 UML 包,一个主图都会自动的被创建出来,并且作为那个包的默认图。讨论所涉及的产品的默认参数设置是为每一个新的包创建并且设置为默认图的一个自由格式的图。然而,默认的设置也能够被改变,以便其它类型的主图也能够被创建出来,并且并不被指派为包的默认图。也有可能将任意一个包中的另一个图指派为包的默认图。

这些机制支持下列组织指导方针,它们能够被应用到任何类型的模型中:

  • 组成每一个模型/逻辑单元的主图(或者其他的默认图)用来描述:
    • 模型/逻辑单元中的每一个顶层的包;
    • 贮存在模型/逻辑单元的根包中的任何一个其他图所对应的图的图标。换句话说,并不描述它自己对应于默认图的图标。
  • 组成每一个顶层包的主图(或者其他的默认图)用来描述:
    • 它所直接包含的图的图标所对应的包;
    • 它所直接包含的任何一个其他的图。
  • 为包的每个递降层级重复执行这一模式。

对什么进行建模,以及建模到何种程度

这一小节是本文中最短但却是最重要的部分。

当涉及到提供建模指导方针的时候,就会产生异常的紧张。那些刚刚接触建模的读者希望获得高度说明性的指导,以便他们能够快速的入门。但是这些指导将导致他们陷入比实际需要进行更多的建模的陷阱。

本系列的后面几篇文章将呈现相对说明性的指导,关于在处理一个特殊的建模风格时如何构造模型,例如:“经典的” RUP、用于 SOA 的业务驱动的开发、或者模型驱动系统开发。这些能够为读者提供一个宽截面的价值,但是重要的是一种最可能性的理解,而不是一组规则。这意味着“这就是您可能如何做”,而不是“您必须如何做”。

注释:
一个重要的例外就是您可能使用一个转化,它要求输入一个以非常特定的方式组成的模型。如果您将要使用这种转化的话,那么就请用高度说明性的指导来阐明、发布、以及培训团队成员,使他们懂得如何创建这样的源模型。

模型的许多价值存在于抽象的关注个别的关注点。建模的多少依赖于您需要理解的抽象水平、您的问题或者解决方案域、如何在您的开发过程中自动驱动、以及如何同项目的出资方进行沟通。最佳的建模指导方针就是:

只有在认识到业务价值的时候才进行建模

因此,本系列文章中特定风格的指导方针努力做到识别特定建模活动的业务价值,从而帮助您决定该指导方针在多大程度上适用于您的具体情况。

参考资料

学习

获得产品和技术

讨论

条评论

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=318284
ArticleTitle=IBM Rational 架构管理软件模型结构指南,第 1 部分: 基本原则
publish-date=07032008