【IT168 技术文章】

         UML 2 中的阴和阳

　　在 UML 2 中有二种基本的图范畴：结构图和行为图。每个 UML 图都属于这二个图范畴。结构图的目的是显示建模系统的静态结构。它们包括类，组件和(或)对象图。另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。行为图的实例是活动图，用例图和序列图。

　　大体上的结构图

　　如同我所说的，结构图显示建模系统的静态结构。关注系统的元件，无需考虑时间。在系统内，静态结构通过显示类型和它们的实例进行传播。除了显示系统类型和它们的实例，结构图至少也显示了这些元素间的一些关系，可能的话，甚至也显示它们的内部结构。

　　贯穿整个软件生命周期，结构图对于各种团队成员都是有用的。一般而言，这些图支持设计验证，和个体与团队间的设计交流。举例来说，业务分析师可以使用类或对象图，来为当前的资产和资源建模，例如分类账，产品或地理层次。架构师可以使用组件和部署图，来测试/确认他们的设计是否充分。开发者可以使用类图，来设计并为系统的代码(或即将成为代码的)类写文档。

　　特殊的类图

　　UML 2 把结构图看成一个分类;这里并不存在称为“结构图”的图。然而，类图提供结构图类型的一个主要实例，并为我们提供一组记号元素的初始集，供所有其它结构图使用。由于类图是如此基本，本文的剩余部分将会把重点集中在类图记号集。在本文的结尾，你将对于如何画UML 2类图有所了解，而且对于理解在后面文章中将涉及的其他结构图有一个稳固的基础。

　　基础

　　如先前所提到的，类图的目的是显示建模系统的类型。在大多数的 UML 模型中这些类型包括：

　　类

　　接口

　　数据类型

　　组件

　　UML 为这些类型起了一个特别的名字：“分类器”。通常地，你可以把分类器当做类，但在技术上，分类器是更为普遍的术语，它还是引用上面的其它三种类型为好。

　　类名

　　类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的(当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的)。图 1 显示一个航线班机如何作为 UML 类建模。正如我们所能见到的，名字是 Flight，我们可以在中间区域看到Flight类的3个属性：flightNumber，departureTime 和 flightDuration。在底部区域中我们可以看到Flight类有两个操作：delayFlight 和 getArrivalTime。

　　图 1: Flight类的类图

　　类属性列表

　　类的属性节(中部区域)在分隔线上列出每一个类的属性。属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。该线用如下格式：

　　继续我们的Flight类的例子，我们可以使用属性类型信息来描述类的属性，如表 1 所示。

　　表 1：具有关联类型的Flight类的属性名字

　　在类图上显示具有默认值的特定属性，有时是有用的(例如，在银行账户应用程序中，一个新的银行账户会以零为初始值)。UML 规范允许在属性列表节中，通过使用如下的记号作为默认值的标识：

　　举例来说：

　　显示属性默认值是可选择的;图 2 显示一个银行账户类具有一个名为 balance的类型，它的默认值为0。

　　图 2：显示默认为0美元的balance属性值的银行账户类图。

　　类操作列表

　　类操作记录在类图长方形的第三个(最低的)区域中，它也是可选择的。和属性一样，类的操作以列表格式显示，每个操作在它自己线上。操作使用下列记号表现：

　　下面的表 2 中Flight类操作的映射。

　　表 2：从图 2 映射的Flight类的操作

　　图 3：Flight类操作参数，包括可选择的“in”标识。

　　当文档化操作参数时，你可能使用一个可选择的指示器，以显示参数到操作的输入参数、或输出参数。这个可选择的指示器以“in”或“out”出现，如图3中的操作区域所示。一般来说，除非将使用一种早期的程序编程语言，如Fortran ，这些指示器可能会有所帮助，否则它们是不必要的。然而，在 C++和Java中，所有的参数是“in”参数，而且按照UML规范，既然“in”是参数的默认类型，大多数人将会遗漏输入/输出指示器。

　　继承

　　在面向对象的设计中一个非常重要的概念，继承，指的是一个类(子类)继承另外的一个类(超类)的同一功能，并增加它自己的新功能(一个非技术性的比喻，想象我继承了我母亲的一般的音乐能力，但是在我的家里，我是唯一一个玩电吉他的人)的能力。为了在一个类图上建模继承，从子类(要继承行为的类)拉出一条闭合的，单键头(或三角形)的实线指向超类。考虑银行账户的类型：图 4 显示 CheckingAccount 和 SavingsAccount 类如何从 BankAccount 类继承而来。

　　图 4: 继承通过指向超类的一条闭合的，单箭头的实线表示。

　　在图 4 中，继承关系由每个超类的单独的线画出，这是在IBM Rational Rose和IBM Rational XDE中使用的方法。然而，有一种称为 树标记的备选方法可以画出继承关系。当存在两个或更多子类时，如图 4 中所示，除了继承线象树枝一样混在一起外，你可以使用树形记号。图 5 是重绘的与图 4 一样的继承，但是这次使用了树形记号。

　　图 5: 一个使用树形记号的继承实例

　　抽象类及操作

　　细心的读者会注意到，在图 4 和 图5 中的图中,类名BankAccount和withdrawal操作使用斜体。这表示，BankAccount 类是一个抽象类，而withdrawal方法是抽象的操作。换句话说，BankAccount 类使用withdrawal规定抽象操作，并且CheckingAccount 和 SavingsAccount 两个子类都分别地执行它们各自版本的操作。

　　然而，超类(父类)不一定要是抽象类。标准类作为超类是正常的。

　　关联

　　当你系统建模时，特定的对象间将会彼此关联，而且这些关联本身需要被清晰地建模。有五种关联。在这一部分中，我将会讨论它们中的两个 -- 双向的关联和单向的关联，而且我将会在Beyond the basics部分讨论剩下的三种关联类型。请注意，关于何时该使用每种类型关联的详细讨论，不属于本文的范围。相反的，我将会把重点集中在每种关联的用途，并说明如何在类图上画出关联。

　　双向(标准)的关联

　　关联是两个类间的联接。关联总是被假定是双向的;这意味着，两个类彼此知道它们间的联系，除非你限定一些其它类型的关联。回顾一下Flight 的例子，图 6 显示了在Flight类和Plane类之间的一个标准类型的关联。

　　图 6：在一个Flight类和Plane类之间的双向关联的实例

　　一个双向关联用两个类间的实线表示。在线的任一端，你放置一个角色名和多重值。图 6 显示Flight与一个特定的Plane相关联，而且Flight类知道这个关联。因为角色名以Plane类表示，所以Plane承担关联中的“assignedPlane”角色。紧接于Plane类后面的多重值描述0...1表示，当一个Flight实体存在时，可以有一个或没有Plane与之关联(也就是，Plane可能还没有被分配)。图 6 也显示Plane知道它与Flight类的关联。在这个关联中，Flight承担“assignedFlights”角色;图 6 的图告诉我们，Plane实体可以不与flight关联(例如，它是一架全新的飞机)或与没有上限的flight(例如，一架已经服役5年的飞机)关联。

　　由于对那些在关联尾部可能出现的多重值描述感到疑惑，下面的表3列出了一些多重值及它们含义的例子。

　　表 3: 多重值和它们的表示

　　　　单向关联

　　在一个单向关联中，两个类是相关的，但是只有一个类知道这种联系的存在。图 7 显示单向关联的透支财务报告的一个实例。

　　图 7: 单向关联一个实例：OverdrawnAccountsReport 类 BankAccount 类，而 BankAccount 类则对关联一无所知。

　　一个单向的关联，表示为一条带有指向已知类的开放箭头(不关闭的箭头或三角形，用于标志继承)的实线。如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。在图 7 中的例子中，OverdrawnAccountsReport 知道 BankAccount 类，而且知道 BankAccount 类扮演“overdrawnAccounts”的角色。然而，和标准关联不同，BankAccount 类并不知道它与 OverdrawnAccountsReport 相关联。 2

　　软件包

　　不可避免，如果你正在为一个大的系统或大的业务领域建模，在你的模型中将会有许多不同的分类器。管理所有的类将是一件令人生畏的任务;所以，UML 提供一个称为 软件包的组织元素。软件包使建模者能够组织模型分类器到名字空间中，这有些象文件系统中的文件夹。把一个系统分为多个软件包使系统变成容易理解，尤其是在每个软件包都表现系统的一个特定部分时。 3

　　在图中存在两种方法表示软件包。并没有规则要求使用哪种标记，除了用你个人的判断：哪种更便于阅读你画的类图。两种方法都是由一个较小的长方形(用于定位)嵌套在一个大的长方形中开始的，如图 8 所示。但是建模者必须决定包的成员如何表示，如下：

　　如果建模者决定在大长方形中显示软件包的成员，则所有的那些成员 4 需要被放置在长方形里面。另外，所有软件包的名字需要放在软件包的较小长方形之内(如图 8 的显示)。

　　如果建模者决定在大的长方形之外显示软件包成员，则所有将会在图上显示的成员都需要被置于长方形之外。为了显示属于软件包的分类器属于，从每个分类器画一条线到里面有加号的圆周，这些圆周粘附在软件包之上(图9)。

　　图 8：在软件包的长方形内显示软件包成员的软件包元素例子

　　图 9：一个通过连接线表现软件包成员的软件包例子

　　了解基础重要性

　　在 UML 2 中，了解类图的基础更为重要。这是因为类图为所有的其他结构图提供基本的构建块。如组件或对象图(仅仅是举了些例子)。