UML 类图

 

• 类图

     类图用于表示类的静态内容以及它们之间的关系，在其中可以显示出类的成员变量和成员函数，以及类之间的继承和引用关系。

     类的UML表示是一个长方形，垂直地分为三个区，顶部区域显示类的名字，中间的区域列出类的属性，底部的区域列出类的操作。

 

• 分类
• • 类
  • interface
  • utility
  • abstract（斜体表示）

• 可见性
• • +  public
  • #  protected
  • -   private
  • ~  package

• 类的属性

     类的属性节在分隔线上列出每一个类的属性。属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的。然而用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的模型的类型之中。

name : attribute type

flightNumber : Integer

• • • 属性关联类型

属性名称	属性类型
flightNumber	Integer
departureTime	Date
flightDuration	Minutes

• • • 属性默认值

name : attribute type = default value

• 类的操作

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

name(parameter list) : type of value returned

操作名称

返回参数

值类型

delayFlight

Name	Type
numberOfMinutes	Minutes

N/A

getArrivalTime

N/A

Date

• 继承关系

     继承指的是一个子类继承一个父类的功能，并增加它自己的新功能。为了在一个类图上建模继承，从子类拉出一条闭合的单键头（或三角形）的实线指向父类。

 

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

 

• 关联关系

     关联关系是一种普遍存在的关系，它指两个类的实例之间存在稳定的连接，即当一个类的对象作为另一个类的对象的变量成员，它使一个类知道另一个类的属性和方法 ，这样两个类就存在关联关系。

• • 双向关联

     关联是两个类间的联接。关联总是被假定是双向的；这意味着，两个类彼此知道它们间的联系，除非你限定一些其它类型的关联。

 

     一个双向关联用两个类间的实线表示。在线的任一端，你放置一个角色名和多重值。Flight与一个特定的Plane相关联，而且Flight类知道这个关联。因为角色名以Plane类表示，所以Plane承担关联中的“assignedPlane”角色。紧接于Plane类后面的多重值描述0...1表示，当一个Flight实体存在时，可以有一个或没有Plane与之关联。也显示Plane知道它与Flight类的关联。在这个关联中，Flight承担“assignedFlights”角色；Plane实体可以不与flight关联或与没有上限的flight关联。

• • 单向关联 

     在一个单向关联中，两个类是相关的，但是只有一个类知道这种联系的存在。

 

     一个单向的关联，表示为一条带有指向已知类的开放箭头的实线。如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。OverdrawnAccountsReport 知道 BankAccount 类，而且知道 BankAccount 类扮演“overdrawnAccounts”的角色。然而，和标准关联不同，BankAccount 类并不知道它与 OverdrawnAccountsReport 相关联。

• • 关联类 

     在关联建模中，存在一些情况下，你需要包括其它类，因为它包含了关于关联的有价值的信息。对于这种情况，你会使用关联类来绑定你的基本关联。关联类和一般类一样表示。不同的是，主类和关联类之间用一条相交的点线连接。在Flight类和FrequentFlyer类之间的关联，产生了称为MileageCredit的关联类。这意味当Flight类的一个实例关联到FrequentFlyer类的一个实例时，将会产生MileageCredit类的一个实例。

 

• • 聚合关系

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

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

 

• • 组合关系

     组合关系是聚合关系的进一步强化，子类实例的生命周期依赖于父类实例的生命周期。在图中，显示了Company类和Department类之间的组合关系，注意组合关系如聚合关系一样绘制，不过这次菱形是被填充的。在图中的关系建模中，一个Company类实例至少总有一个Department类实例。因为关系是组合关系，当Company实例被移除/销毁时，Department实例也将自动地被移除/销毁。组合聚合的另一个重要功能是部分类只能与父类的实例相关。

 

• • 反射关系

     类也可以使用反射关联与它本身相关联。起先，这可能没有意义，但是记住，类是抽象的。下图显示一个Employee类如何通过manager / manages角色与它本身相关。当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关。图描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。然而，因为“manages”的关系角色有 0..*的多重性描述；一个雇员可能不受任何其他雇员管理。

 

• 依赖关系

     依赖关系是表示“使用”的语义，一个类依赖另一个类并且总是单向的，用带有箭头的虚线表示。可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用。

 

• 实现关系

     实现关系是一个类定义声明，另一个类来实现它。一条带有闭合的单向箭头的点线意味着实现。

 

• 多重值和它们的表示

可能的多重值描述
表示	含义
0..1	0个或1个
1	只能1个
0..*	0个或多个
*	0个或多个
1..*	1个或多个
3	只能3个
0..5	0到5个
5..15	5到15个

• 实例

     当一个系统结构建模时，显示例子类实例有时候是有用的。实例的记号和类一样，但是取代顶端区域中仅有的类名，它的名字是经过拼接的。

Instance Name : Class Name

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

 

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

 

• 角色

     建模类的实例有时比期望的更为详细。有时，你可能仅仅想要在一个较多的一般层次做类关系的模型。在这种情况下，你应该使用角色记号。角色记号类似于实例记号。为了建立类的角色模型，你画一个方格，并在内部放置类的角色名及类名，作为实体记号，但是在这情况你不能加下划线。注意，你不能在纯粹类图中做类角色的建模，为了使用角色记号，你将会需要使用下面讨论的内部结构记号。

 

• 内部的结构

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

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

 

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

 

• 软件包

     软件包使建模者能够组织模型分类器到名字空间中，这有些象文件系统中的文件夹。把一个系统分为多个软件包使系统变成容易理解，尤其是在每个软件包都表现系统的一个特定部分时。