UML类图(高级)

野性酷女 2022-08-27 01:19 137阅读 0赞

超过基础

到此为止，我已经介绍了类图的基础，但是请继续往下读！在下面的部分中，我将会引导你到你会使用的类图的更重要的方面。这些包括UML 2 规范中的接口，其它的三种关联类型，可见性和其他补充。

**接口**  
在本文的前面，我建议你以类来考虑*分类器*。事实上，分类器是一个更为一般的概念，它包括数据类型和接口。

关于何时、以及如何高效地在系统结构图中使用数据类型和接口的完整讨论，不在本文的讨论范围之内。既然这样，我为什么要在这里提及数据类型和接口呢？你可能想在结构图上模仿这些分类器类型，在这个时候，使用正确的记号来表示，或者至少知道这些分类器类型是重要的。不正确地绘制这些分类器，很有可能将使你的结构图读者感到混乱，以后的系统将不能适应需求。

一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”，如图 10 所示。[5][]

![图 10:Professor类和Student类实现Person接口的类图实例][10_Professor_Student_Person]

**图 10：Professor类和Student类实现Person接口的类图实例**

在图 10 中显示的图中，Professor和Student类都实现了Person的接口，但并不从它继承。我们知道这一点是由于下面两个原因：1) Person对象作为接口被定义 -- 它在对象的名字区域中有“interface”文本，而且我们看到由于Professor和Student对象根据画类对象的规则（在它们的名字区域中没有额外的分类器文本）标示，所以它们是 *类*对象。 2) 我们知道继承在这里没有被显示，因为与带箭头的线是点线而不是实线。如图 10 所示，一条带有闭合的单向箭头的*点* 线意味着实现（或实施）；正如我们在图 4 中所见到的，一条带有闭合单向箭头的*实*线表示继承。

**更多的关联**  
在上面，我讨论了双向关联和单向关联。现在，我将会介绍剩下的三种类型的关联。

**关联类**  
在关联建模中，存在一些情况下，你需要包括其它类，因为它包含了关于关联的有价值的信息。对于这种情况，你会使用 *关联类* 来绑定你的基本关联。关联类和一般类一样表示。不同的是，主类和关联类之间用一条相交的点线连接。图 11 显示一个航空工业实例的关联类。

![图 11:增加关联类 MileageCredit][11_ MileageCredit]

**图 11：增加关联类 MileageCredit**

在图 11 中显示的类图中，在Flight类和 FrequentFlyer 类之间的关联，产生了称为 MileageCredit的关联类。这意味当Flight类的一个实例关联到 FrequentFlyer 类的一个实例时，将会产生 MileageCredit 类的一个实例。

**聚合**  
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中， *部分类* 的生命周期独立于 *整体类* 的生命周期。

举例来说，我们可以想象，*车* 是一个整体实体，而 *车轮* 轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。然而，有些情况下， *部分* 类的生命周期并 *不* 独立于 *整体* 类的生命周期 -- 这称为合成聚合。举例来说，考虑公司与部门的关系。 *公司和部门* 都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于Company类的实例而存在。

让我们更进一步探讨基本聚合和组合聚合。

***基本聚合***  
有聚合关系的关联指出，某个类是另外某个类的一部分。在一个聚合关系中，子类实例可以比父类存在更长的时间。为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。图 12 显示车和轮胎间的聚合关系的例子。

![图 12: 一个聚合关联的例子][12_]

**图 12: 一个聚合关联的例子**

***组合聚合***  
组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。在图13中，显示了Company类和Department类之间的组合关系，注意组合关系如聚合关系一样绘制，不过这次菱形是被填充的。

![图 13: 一个组合关系的例子][13_]

**图 13: 一个组合关系的例子**

在图 13 中的关系建模中，一个Company类实例至少总有一个Department类实例。因为关系是组合关系，当Company实例被移除/销毁时，Department实例也将自动地被移除/销毁。组合聚合的另一个重要功能是部分类只能与父类的实例相关（举例来说，我们例子中的Company类）。

**反射关联**  
现在我们已经讨论了所有的关联类型。就如你可能注意到的，我们的所有例子已经显示了两个不同类之间的关系。然而，类也可以使用反射关联与它本身相关联。起先，这可能没有意义，但是记住，类是抽象的。图 14 显示一个Employee类如何通过manager / manages角色与它本身相关。当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关。

![图 14:一个反射关联关系的实例][14]

**图 14：一个反射关联关系的实例**

图 14 描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。然而，因为“manages”的关系角色有 0..\*的多重性描述；一个雇员可能不受任何其他雇员管理。

**可见性**  
在面向对象的设计中，存在属性及操作可见性的记号。UML 识别四种类型的可见性：public，protected，private及package。

UML 规范并不要求属性及操作可见性必须显示在类图上，但是它要求为每个属性及操作定义可见性。为了在类图上的显示可见性，放置可见性标志于属性或操作的名字之前。虽然 UML 指定四种可见性类型，但是实际的编程语言可能增加额外的可见性，或不支持 UML 定义的可见性。表4显示了 UML 支持的可见性类型的不同标志。

**表 4：UML 支持的可见性类型的标志**

<table> 
 <tbody> 
  <tr> 
   <td> 
    <table> 
     <tbody> 
      <tr> 
       <th>标志</th> 
       <th>可见性类型</th> 
      </tr> 
      <tr> 
       <td>+</td> 
       <td>Public</td> 
      </tr> 
      <tr> 
       <td>#</td> 
       <td>Protected</td> 
      </tr> 
      <tr> 
       <td>-</td> 
       <td>Private</td> 
      </tr> 
      <tr> 
       <td>~</td> 
       <td>Package</td> 
      </tr> 
     </tbody> 
    </table> </td> 
  </tr> 
 </tbody> 
</table>

现在，让我们看一个类，以说明属性及操作的可见性类型。在图 15 中，所有的属性及操作都是public，除了 updateBalance 操作。updateBalance 操作是protected。

![图 15:一个 BankAccount 类说明它的属性及操作的可见性][15_ BankAccount]

**图 15：一个 BankAccount 类说明它的属性及操作的可见性**

UML 2 补充

既然我们已经覆盖了基础和高级主题，我们将覆盖一些由UML 1. x增加的类图的新记号。

**实例**  
当一个系统结构建模时，显示例子类实例有时候是有用的。为了这种结构建模，UML 2 提供 *实例规范* 元素，它显示在系统中使用例子（或现实）实例的值得注意的信息。

实例的记号和类一样，但是取代顶端区域中仅有的类名，它的名字是经过拼接的:

> <table> 
>  <tbody> 
>   <tr> 
>    <td> <pre>Instance Name : Class Name</pre> </td> 
>   </tr> 
>  </tbody> 
> </table>
> 
>   
>

举例来说：

> <table> 
>  <tbody> 
>   <tr> 
>    <td> <pre>Donald : Person</pre> </td> 
>   </tr> 
>  </tbody> 
> </table>
> 
>   
>

因为显示实例的目的是显示值得注意的或相关的信息，没必要在你的模型中包含整个实体属性及操作。相反地，仅仅显示感兴趣的属性及其值是完全恰当的。如图16所描述。

![图 16:Plane类的一个实例例子(只显示感兴趣的属性值)][16_Plane]

**图 16：Plane类的一个实例例子（只显示感兴趣的属性值）**

然而，仅仅表现一些实例而没有它们的关系不太实用；因此，UML 2 也允许在实体层的关系/关联建模。绘制关联与一般的类关系的规则一样，除了在建模关联时有一个附加的要求。附加的限制是，关联关系必须与类图的关系相一致，而且关联的角色名字也必须与类图相一致。它的一个例子显示于图 17 中。在这个例子中，实例是图 6 中类图的例子实例。

![图 17:图 6 中用实例代替类的例子][17_ 6]

**图 17：图 6 中用实例代替类的例子**

图 17 有Flight类的二个实例，因为类图指出了在Plane类和Flight类之间的关系是 *0或多*。因此，我们的例子给出了两个与NX0337 Plane实例相关的Flight实例。

**角色**  
建模类的实例有时比期望的更为详细。有时，你可能仅仅想要在一个较多的一般层次做类关系的模型。在这种情况下，你应该使用 *角色* 记号。角色记号类似于实例记号。为了建立类的角色模型，你画一个方格，并在内部放置类的角色名及类名，作为实体记号，但是在这情况你不能加下划线。图 18 显示一个由图 14 中图描述的雇员类扮演的角色实例。在图 18 中，我们可以认为，即使雇员类与它本身相关，关系确实是关于雇员之间扮演经理及团队成员的角色。

![图 18:一个类图显示图14中扮演不同角色的类][18_14]

**图 18：一个类图显示图14中扮演不同角色的类**

注意，你不能在纯粹类图中做类角色的建模，即使图 18显示你可以这么做。为了使用角色记号，你将会需要使用下面讨论的内部结构记号。

**内部的结构**  
UML 2 结构图的更有用的功能之一是新的内部结构记号。它允许你显示一个类或另外的一个分类器如何在内部构成。这在 UML 1. x 中是不可能的，因为记号限制你只能显示一个类所拥有的聚合关系。现在，在 UML 2 中，内部的结构记号让你更清楚地显示类的各个部分如何保持关系。

让我们看一个实例。在图 18 中我们有一个类图以表现一个Plane类如何由四个引擎和两个控制软件对象组成。从这个图中省略的东西是显示关于飞机部件如何被装配的一些信息。从图 18 的图，你无法说明，是每个控制软件对象控制两个引擎，还是一个控制软件对象控制三个引擎，而另一个控制一个引擎。

![图 19: 只显示对象之间关系的类图][19_]

**图 19: 只显示对象之间关系的类图**

绘制类的内在结构将会改善这种状态。开始时，你通过用二个区域画一个方格。最顶端的区域包含类名字，而较低的区域包含类的内部结构，显示在它们父类中承担不同角色的部分类，角色中的每个部分类也关系到其它类。图 19 显示了Plane类的内部结构；注意内部结构如何澄清混乱性。

![图 20:Plane类的内部结构例子.][20_Plane_.]

**图 20：Plane类的内部结构例子。**

在图 20 中Plane有两个 ControlSoftware 对象，而且每个控制二个引擎。在图左边上的 ControlSoftware（control1）控制引擎 1 和 2 。在图右边的 ControlSoftware（control2）控制引擎 3 和 4 。

结论

至少存在两个了解类图的重要理由。第一个是它显示系统分类器的静态结构；第二个理由是图为UML描述的其他结构图提供了基本记号。开发者将会认为类图是为他们特别建立的；但是其他的团队成员将发现它们也是有用的。业务分析师可以用类图，为系统的业务远景建模。正如我们将会在本系列关于 UML 基础的文章中见到的，其他的图 -- 包括活动图，序列图和状态图——参考类图中的类建模和文档化。

关于“UML 基础”的本系列的后面的元件图。

[5]: http://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb05/bell/#notes
[10_Professor_Student_Person]: /images/20220824/f91980d9812f4459bb65875302e3f6a0.png
[11_ MileageCredit]: /images/20220824/a18e9d3d7c8b42a28fbdc8c019ed88d4.png
[12_]: /images/20220824/37dce11ae47a459da97faa3a47bbd8f5.png
[13_]: /images/20220824/4a69d4b73549406589bf6454edf0b885.png
[14]: /images/20220824/ba30ee75f4b94e3fb4f13f800ced1ce7.png
[15_ BankAccount]: /images/20220824/b02cf530ebf04b9286e0cf5de2135b3d.png
[16_Plane]: /images/20220824/92fac4a958b34b91a37e4b67c8feddad.png
[17_ 6]: /images/20220824/dbd1a3c000c94aecae2fbe033a2eb232.png
[18_14]: /images/20220824/3e50869b551a4fd4b3d773811a4c9cf0.png
[19_]: /images/20220824/7a69dc7163d743acb46b61199c9c040a.png
[20_Plane_.]: /images/20220824/d7e902db17eb4d729085bd63baf911dc.png