UML 结构图之类图 总结

[注] 本文不是类图的基础教程, 只是类图的图形总结.

学习UML图形

推荐阅读<UML参考手册>第2版. http://www.umlchina.com/

推荐微软的开发软件设计模型 http://msdn.microsoft.com/zh-cn/library/dd409436.aspx

类图展示了面向对象系统的构造模块。描绘模型(或部分模型)的静态视图，显示它包含的属性和行为，而不是详细描述操作的功能或完善方法。

类图最常用来表达多个类和接口之间的关系。

〇 概述

可使用的工具集(EA工具箱)有:

一 类图元素 

1. 包

Package, 图形表示为一个文件夹, 包的版型(StereoType)有:

1) 普通包, 表示为一个文件夹, 如图Package1和Package4

2) 其它包, 表示为一个文件夹+书名号包含的具体版型或特殊符号, 如图Package2和Package3

2. 类

Class, 图形表示为一个实心矩形或圆形(椭圆)[+一系列附加符号], 类的版型(StereoType)有:

1) 普通类, 表示为一个实心矩形, 如图Class1

2) 边界类, 表示为一个实心圆形+实竖线, 如图Class2

3) 实体类, 表示为一个实心圆形+实横线, 如图Class3

4) 控制类, 表示为一个实心圆形+在圆周上的箭头, 如图Class4

5) 其它类, 表示为一个实心矩形或圆形(椭圆)+书名号包含的具体版型或特殊符号, 如图Class 5, 6, 7 ...

[注1] 类图标变化最大, 版型最多, 必须根据所属的视图或图形进行识别, 如Class2在包图和类图中称为边界类, 在活动图中同样的图标应称为边界对象.

[注2] 类图标的矩形表示和Artifact相似, 都是实心矩形, 区别方法是Artifact图标会含有Icon, 而类图标一般几何元素拼凑.

[注3] 类图标的椭圆表示和用例相似, 都是实心椭圆, 但用例不会出现在类图上, 类也不应该出现在用例图上, 因此不会冲突.

[注4] 包图上的类一般引用类图, 类图内部的画法, 参见类图部分. (下同)

3. 接口

Interface, 图形表示为一个实心矩形+书名号包含的interface字样, 接口没有版型(StereoType).

接口是特殊的类, 因此图标和类相同, 书名号包含的interface是其区别与类的唯一方式.

注意: 接口如果没有明确的详细操作，也可以画成一个圆环。当画成圆环的时候，到这个环形标柱的实现连接没有目标箭头。

4. 数据类型

DataType, 图形表示为一个实心矩形+书名号包含的datatype(或其它)字样, 数据类型的版型(StereoType)有:

1) 数据类型, 表示为一个实心矩形+书名号包含的interface字样, 如图DataType1

2) 基本类型, 表示为一个实心矩形+书名号包含的interface字样, 如图PrimitiveType1

3) 枚举类型, 表示为一个实心矩形+书名号包含的interface字样, 如图Enumeration1

4) 表格类型, 表示为一个实心矩形+书名号包含的interface字样, 如图Table1

5) 信号类型, 表示为一个实心矩形+书名号包含的interface字样, 如图Signal1

6) 其它类型, 表示为一个实心矩形+书名号包含的其它字样, 如图DataType 2, 3, 4 ...

[注4] 数据类型用来描述形如枚举, 结构, 表格等特殊的数据类型或类, 同样的, 使用不同的版型是为了定义更准确.

5. 关系

5.1 包与包之间的关系 

1) 合并 merge, 表示为一条虚线+单向空心箭头+书名号包含的merge字样, 箭头指向被合并的包, 如图Controller合并GenApply

包合并定义了一个包的内容是如何被另一个包扩展的关系(包合并定义了源包元素与目标包同名元素之间的泛化关系).

2) 导入(引入) import/access, 表示为一条虚线+单向空心箭头+书名号包含的import/access字样, 箭头指向被合并的包, 如图Controller导入Interger

包导入是一种允许采用非限定性名称访问来自于另一个命名空间中的元素的关系.

3) 嵌套 nesting, 表示为一条实线+带十字线的实心圆, 圆远离被合并的包, 如图Controller嵌套ConnSeq(即ConnSeq被嵌套)

源包和目标包间的嵌套连接符说明目标包完全包含源包.

5.2 类与类(接口/数据类型)之间的关系

本图中使用的例子来自 http://blog.csdn.net/tianhai110/article/details/6339565

1) 实现 realization, 表示为一条虚线+单向空心箭头, 箭头指向被实现的接口

2) 泛化 generalization, 表示为一条实线+单向空心箭头, 箭头指向被泛化的基(父)类

3) 依赖 dependency, 表示为一条虚线[+单向或双向开口箭头], 单向箭头表示单向依赖

4) ① 关联 association, 表示为一条实线[+单向或双向开口箭头], 单向箭头表示单向关联

4) ② 聚合 aggregation , 表示为一条实线[+单向空心菱形], 空心菱形箭头指向目标类或父类

4) ③ 组合 composition, 表示为一条实线[+单向实心菱形], 实心菱形箭头指向目标类或父类

[注5] 应避免双向依赖.

[注6] 几种关系所表现出的强弱程度从弱到强依次是: 依赖 < 关联 < 聚合 < 组合 ( 即耦合度: 组合 > 聚合 > 关联 > 依赖 ).

6. 可见性

6.1 包的可见性 

Package Visibility, 使用版型(StereoType)表示, <<import>>表示public, <<access>>表示private

[注] import VS access:

Ordering在import导入Products和Pricing后可直接使用Products和Pricing包内的元素;

Ordering在access导入Storage后仍可直接使用Storage包内的元素;

而当Ordering被其它包引用时, 其它包只能直接使用Products和Pricing包内的元素, 不能直接使用Storage包内的元素; 但仍可采用Storage::Goods这样的限定性名访问Storage包中的元素.

6.2 类(接口/数据类型)的可见性 

Class Visibility, 使用 +/-/#/~ 符号表示

1) 公共 public, 用 + 号表示, 如图Storage包内Goods类的GetCount成员

2) 私有 private, 用 - 号表示, 如图Storage包内Goods类的Count属性

3) 保护 protected, 用 # 号表示, 如图Storage包内Goods类的SetCount成员

4) 包 package, 用 ~ 号表示, 代表包内可见, 如图Storage包内Goods类的Test成员

二 类图关系 

1. 实现 realization 

是源对象执行或实现目标，实现被用来表达模型的可跟踪性和完整性－业务模型或需求被一个或多个用例实现，用例则被类实现，类被组件实现，等等。这种实现贯穿于系统设计的映射需求和类等，直至抽象建模水平级。从而确保整个系统的一张宏图，它也反映系统的所有微小组成，以及约束和定义它的细节。实现关系用带虚线的实箭头表示。

2. 泛化 generalization 

泛化被用来说明继承关系。连接从特定类元到一般类元。泛化的含义是源类继承了目标类的特性。

下图的图显示了一个父类泛化一个子类， 类“Circle”的一个实例将会有属性 “ x_position”，“ y_position” ， “radius” 和 方法 “display()”。

注意：类 "Shape" 是抽象的，类名显示为斜体。

3. 依赖 dependency 

依赖被用来描述模型元素间广泛的依赖关系。

通常在设计过程早期显示两个元素之间存在某种关系，因为是初期而不能确定具体是什么关系，在设计过程末期，该继承关系会被归入已有构造型 (构造型 可以是实例化 «instantiate»，跟踪 «trace»，导入 «import»， 和其它的关系)，或被替换成一个更明确类型的连接符。

3.1 跟踪 trace 

跟踪关系是一种特殊化的依赖关系。连接模型元素或跨模型但是具有相同概念的模型元素集。

跟踪被经常用来追踪需求和模型的变化。由于变化是双向的，这种依赖关系的顺序通常被忽略。

这种关系的属性可以被指定为单向映射，但跟踪是双向的，非正式的和很少可计算的。

4. 关联 association 

4.1 关联 Association 

关联描述了系统中对象或实例之间的离散连接.

关联表明两个模型元素之间有关系，通常用在一个类中被实现为一个实例变量。

连接符可以包含两端的命名的角色，基数性，方向和约束。

关联是元素之间普通的关系。如果多于两个元素，也可以使用菱形的关联关系。

当从类图生成代码时，关联末端的对象将变成目标类中实例变量。见下图示例 "playsFor" 将变成"Player"类中的实例变量。

4.2 聚合 Aggregations 与 组合 Aggregations 

聚合表示部分与整体关系的关联.

组合表示更强形式的关联, 整体有管理部分的完整职责, 比如为它们分配和释放空间.

三 静态视图 

1. 概述 

1) 静态视图是UML的基础. 模型中的元素是应用中有意义的概念, 包括真实世界的概念, 抽象的概念, 实现方面的概念...系统中各种概念.

2) 静态视图捕捉对象的结构. 面向对象的系统把数据结构和行为特征统一到一个对象结构中. 静态视图包括所有传统数据结构的内容, 同时也包括了数据相关操作的构成.

3) 静态视图将行为的声明, 比如操作, 描述成离散的模型元素, 但是不包括它们动态行为的细节. 静态视图将这些声明作为可命名实体对待, 这些实体的动态行为在其他视图中描述. 动态视图要求静态视图描述动态交互的事物 -- 如果希望说清楚交互是怎样进行的, 就必须先说清楚是什么在交互. 静态视图是建立其他视图的基础.

4) 静态视图中关键元素是类元及它们之间的关系. 类元是描述事物的建模元素. 类元有若干种, 包括类, 接口和数据类型. 行为实体, 比如用例和信号, 同样被具体化为类元. 例如组件, 协作和节点这样的类元能够体现实现方面的意图.

5) 为了利于理解和模型的可重用性, 大的模型必须由较小的单元组成. 包是拥有和管理模型内容的一般目的组织单元. 每个元素都被包所拥有. 模型是一个包的集合, 这些包描述了系统的完整视图, 并且能够或多或少地被独立使用. 模型则指定一个直接包含所有包的根包.

2. 类元 

1) 类

2) 接口

3) 数据类型

4) 含义分层