UML类图(高级)
超过基础
到此为止，我已经介绍了类图的基础，但是请继续往下读！在下面的部分中，我将会引导你到你会使用的类图的更重要的方面。这些包括UML 2 规范中的接口，其它的三种关联类型，可见性和其他补充。
接口
在本文的前面，我建议你以类来考虑分类器。事实上，分类器是一个更为一般的概念，它包括数据类型和接口。
关于何时、以及如何高效地在系统结构图中使用数据类型和接口的完整讨论，不在本文的讨论范围之内。既然这样，我为什么要在这里提及数据类型和接口呢？你可能想在结构图上模仿这些分类器类型，在这个时候，使用正确的记号来表示，或者至少知道这些分类器类型是重要的。不正确地绘制这些分类器，很有可能将使你的结构图读者感到混乱，以后的系统将不能适应需求。
一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”，如图 10 所示。 5
图 10：Professor类和Student类实现Person接口的类图实例
在图 10 中显示的图中，Professor和Student类都实现了Person的接口，但并不从它继承。我们知道这一点是由于下面两个原因：1) Person对象作为接口被定义 -- 它在对象的名字区域中有“interface”文本，而且我们看到由于Professor和Student对象根据画类对象的规则（在它们的名字区域中没有额外的分类器文本）标示，所以它们是 类对象。 2) 我们知道继承在这里没有被显示，因为与带箭头的线是点线而不是实线。如图 10 所示，一条带有闭合的单向箭头的点 线意味着实现（或实施）；正如我们在图 4 中所见到的，一条带有闭合单向箭头的实线表示继承。
更多的关联
在上面，我讨论了双向关联和单向关联。现在，我将会介绍剩下的三种类型的关联。
关联类
在关联建模中，存在一些情况下，你需要包括其它类，因为它包含了关于关联的有价值的信息。对于这种情况，你会使用 关联类 来绑定你的基本关联。关联类和一般类一样表示。不同的是，主类和关联类之间用一条相交的点线连接。图 11 显示一个航空工业实例的关联类。
图 11：增加关联类 MileageCredit
在图 11 中显示的类图中，在Flight类和 FrequentFlyer 类之间的关联，产生了称为 MileageCredit的关联类。这意味当Flight类的一个实例关联到 FrequentFlyer 类的一个实例时，将会产生 MileageCredit 类的一个实例。
聚合
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中， 部分类 的生命周期独立于 整体类 的生命周期。
举例来说，我们可以想象，车 是一个整体实体，而 车轮 轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。然而，有些情况下， 部分 类的生命周期并 不 独立于 整体 类的生命周期 -- 这称为合成聚合。举例来说，考虑公司与部门的关系。 公司和部门 都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于Company类的实例而存在。
让我们更进一步探讨基本聚合和组合聚合。
基本聚合
有聚合关系的关联指出，某个类是另外某个类的一部分。在一个聚合关系中，子类实例可以比父类存在更长的时间。为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。图 12 显示车和轮胎间的聚合关系的例子。
图 12: 一个聚合关联的例子
组合聚合
组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。在图13中，显示了Company类和Department类之间的组合关系，注意组合关系如聚合关系一样绘制，不过这次菱形是被填充的。
图 13: 一个组合关系的例子
在图 13 中的关系建模中，一个Company类实例至少总有一个Department类实例。因为关系是组合关系，当Company实例被移除/销毁时，Department实例也将自动地被移除/销毁。组合聚合的另一个重要功能是部分类只能与父类的实例相关（举例来说，我们例子中的Company类）。
反射关联
现在我们已经讨论了所有的关联类型。就如你可能注意到的，我们的所有例子已经显示了两个不同类之间的关系。然而，类也可以使用反射关联与它本身相关联。起先，这可能没有意义，但是记住，类是抽象的。图 14 显示一个Employee类如何通过manager / manages角色与它本身相关。当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关。
图 14：一个反射关联关系的实例
图 14 描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。然而，因为“manages”的关系角色有 0..*的多重性描述；一个雇员可能不受任何其他雇员管理。
可见性
在面向对象的设计中，存在属性及操作可见性的记号。UML 识别四种类型的可见性：public，protected，private及package。
UML 规范并不要求属性及操作可见性必须显示在类图上，但是它要求为每个属性及操作定义可见性。为了在类图上的显示可见性，放置可见性标志于属性或操作的名字之前。虽然 UML 指定四种可见性类型，但是实际的编程语言可能增加额外的可见性，或不支持 UML 定义的可见性。表4显示了 UML 支持的可见性类型的不同标志。
表 4：UML 支持的可见性类型的标志
|
现在，让我们看一个类，以说明属性及操作的可见性类型。在图 15 中，所有的属性及操作都是public，除了 updateBalance 操作。updateBalance 操作是protected。
图 15：一个 BankAccount 类说明它的属性及操作的可见性
UML 2 补充
既然我们已经覆盖了基础和高级主题，我们将覆盖一些由UML 1. x增加的类图的新记号。
实例
当一个系统结构建模时，显示例子类实例有时候是有用的。为了这种结构建模，UML 2 提供 实例规范 元素，它显示在系统中使用例子（或现实）实例的值得注意的信息。
实例的记号和类一样，但是取代顶端区域中仅有的类名，它的名字是经过拼接的:
举例来说：
因为显示实例的目的是显示值得注意的或相关的信息，没必要在你的模型中包含整个实体属性及操作。相反地，仅仅显示感兴趣的属性及其值是完全恰当的。如图16所描述。
图 16：Plane类的一个实例例子（只显示感兴趣的属性值）
然而，仅仅表现一些实例而没有它们的关系不太实用；因此，UML 2 也允许在实体层的关系/关联建模。绘制关联与一般的类关系的规则一样，除了在建模关联时有一个附加的要求。附加的限制是，关联关系必须与类图的关系相一致，而且关联的角色名字也必须与类图相一致。它的一个例子显示于图 17 中。在这个例子中，实例是图 6 中类图的例子实例。
图 17：图 6 中用实例代替类的例子
图 17 有Flight类的二个实例，因为类图指出了在Plane类和Flight类之间的关系是 0或多。因此，我们的例子给出了两个与NX0337 Plane实例相关的Flight实例。
角色
建模类的实例有时比期望的更为详细。有时，你可能仅仅想要在一个较多的一般层次做类关系的模型。在这种情况下，你应该使用 角色 记号。角色记号类似于实例记号。为了建立类的角色模型，你画一个方格，并在内部放置类的角色名及类名，作为实体记号，但是在这情况你不能加下划线。图 18 显示一个由图 14 中图描述的雇员类扮演的角色实例。在图 18 中，我们可以认为，即使雇员类与它本身相关，关系确实是关于雇员之间扮演经理及团队成员的角色。
图 18：一个类图显示图14中扮演不同角色的类
注意，你不能在纯粹类图中做类角色的建模，即使图 18显示你可以这么做。为了使用角色记号，你将会需要使用下面讨论的内部结构记号。
内部的结构
UML 2 结构图的更有用的功能之一是新的内部结构记号。它允许你显示一个类或另外的一个分类器如何在内部构成。这在 UML 1. x 中是不可能的，因为记号限制你只能显示一个类所拥有的聚合关系。现在，在 UML 2 中，内部的结构记号让你更清楚地显示类的各个部分如何保持关系。
让我们看一个实例。在图 18 中我们有一个类图以表现一个Plane类如何由四个引擎和两个控制软件对象组成。从这个图中省略的东西是显示关于飞机部件如何被装配的一些信息。从图 18 的图，你无法说明，是每个控制软件对象控制两个引擎，还是一个控制软件对象控制三个引擎，而另一个控制一个引擎。
图 19: 只显示对象之间关系的类图
绘制类的内在结构将会改善这种状态。开始时，你通过用二个区域画一个方格。最顶端的区域包含类名字，而较低的区域包含类的内部结构，显示在它们父类中承担不同角色的部分类，角色中的每个部分类也关系到其它类。图 19 显示了Plane类的内部结构；注意内部结构如何澄清混乱性。
图 20：Plane类的内部结构例子。
在图 20 中Plane有两个 ControlSoftware 对象，而且每个控制二个引擎。在图左边上的 ControlSoftware（control1）控制引擎 1 和 2 。在图右边的 ControlSoftware（control2）控制引擎 3 和 4 。
  |
|
结论
至少存在两个了解类图的重要理由。第一个是它显示系统分类器的静态结构；第二个理由是图为UML描述的其他结构图提供了基本记号。开发者将会认为类图是为他们特别建立的；但是其他的团队成员将发现它们也是有用的。业务分析师可以用类图，为系统的业务远景建模。正如我们将会在本系列关于 UML 基础的文章中见到的，其他的图 -- 包括活动图，序列图和状态图——参考类图中的类建模和文档化。
关于“UML 基础”的本系列的后面的元件图。