[转]UML之类图

目录

• 定义
• 类
  • 属性（字段和属性）
  • 操作（方法）
  • 职责
• 接口
• 类图中的关系
  • 关联关系(association)
    • 派生关联
    • 聚合关系(aggregation)
    • 组合关系(composition)
    • 聚合与组合的区别
  • 泛化关系(generalization)
    • 泛化关系的特征
    • 泛化关系的两种情况
  • 依赖关系(dependency)
  • 实现关系(realize)
• 综合例子
• 类的其他概念
  • 抽象类
  • 模板类
  • 关联类
  • 分析类
• 类图的建模技术
• 如何阅读类图？

原文链接：UML之类图——博客园
原文链接：UML类图——简书
原文链接：看懂UML类图和时序图——Graphic Design Patterns

定义#

类图的定义：是显示一组类、接口、协作以及它们之间关系的图。

• 类图主要包含7种元素：类、接口、协作、依赖关系、泛化关系、实现关系、关联关系。
• 类图可以包含注解和约束。
• 类图还可以有包或子系统，二者都用于把模型元素聚集成更大的组件。

类#

类是一组拥有相同的属性、操作、方法、关系和行为的对象地描述符。 类定义了一组有着状态与行为的对象。类的状态由属性和关联来描述，个体行为由操作来描述，对象的生命周期则由附加给类的状态机来描述。

在UML中，类表达成一个有三个分隔区的矩形：

• 顶端显示类名，如果是抽象类，则就用斜体显示。
• 中间显示类的属性（字段和属性）
• 尾端显示类的操作（类的方法）

注：斜体表示抽象。

属性（字段和属性）#

可见性：描述了该属性在那些范围内可以被使用。

+表示public ，公有，其他类可以访问
-表示private，私有，只对本类可见、不能被其他类访问
#表示protected ，保护，对本类及其派生类可见
~表示default,也就是包权限 （既java 中的package、c#中的namespace）
_下划线表示static ，静态，类的所有实例共享 

类型：属性的数据类型，可以系统固有，也可以用户自定义。属性的类型决定了该属性的所有可能取值的集合。

操作（方法）#

可见性：同样描述该操作在那些范围内可以使用，与属性的可见性相同。
参数列表：是一些按照顺序排列的属性定义了操作的输入。例如：oper(out arg1:int, arg2:double=3.2)
返回类型：即回送调用对象消息的类型，void关键字表示无返回值（可省略），例如open Mac():boolean。
特性：是对操作性质的约束说明。

职责#

职责是类的契约或责任。当创建一个类时，就声明了这个类的所有对象具有相同种类的状态和相同种类的行为。在较高的抽象层次上，这些相应的属性和操作正式要完成类的职责的特征。

类的职责是自由形式的文本，在非正式的类图中，可以将职责列在类图操作下的另一分割栏中。

接口#

• 接口是一个被命名的操作集合，用于描述类或组件的一个服务。
• 接口不包含属性与方法实现，但可以有一些操作。接口的所有内容都是公有的。
• 接口代表了一份契约，实现该接口的类元必须履行它。
• 在UML中，接口由一个带名称的小圆圈表示；也可以表示为带有<>构造型的类。

类图中的关系#

UML中最常用的四种关系，即关联关系、泛化关系、依赖关系和实现关系。

关联关系(association)#

关联关系是用一条直线表示的；它描述不同类的对象之间的结构关系；它是一种静态关系， 通常与运行状态无关，一般由常识等因素决定的；它一般用来定义对象之间静态的、天然的结构； 所以，关联关系是一种“强关联”的关系；

比如，乘车人和车票之间就是一种关联关系；学生和学校就是一种关联关系；

关联关系默认不强调方向，表示对象间相互知道；如果特别强调方向，如下图，表示A知道B，但 B不知道A；

注：在最终代码中，关联对象通常是以成员变量的形式实现的。

派生关联#

派生关联：属于一种派生元素。它不增加语义信息，只是一种可以由两个或两个以上的基础关联推算出来的虚拟关联。

聚合关系(aggregation)#

聚合关系用一条带空心菱形箭头的直线表示，如下图表示A聚合到B上，或者说B由A组成：

聚合关系用于表示实体对象之间的关系，表示整体由部分构成的语义，例如一个部门由多个员工组成。

与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在。例如， 部门撤销了，人员不会消失，他们依然存在。

组合关系(composition)#

组合关系用一条带实心菱形箭头直线表示，如下图表示A组成B，或者B由A组成：

与聚合关系一样，组合关系同样表示整体由部分构成的语义，比如公司由多个部门组成。

但组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也不存在了。例如， 公司不存在了，部门也将不存在了。

聚合与组合的区别#

聚合关系：涉及的两个对象处于不平等的层次上，一个代表整体，一个代表部分。比如:电脑和它的显示器、键盘、主板以及内存就是聚集关系，因为主板是电脑的组成部分。

组合关系：代表整体的对象负责代表部分对象的生命周期。公司不存在，部门也没有意义了。再例如：人和五脏六腑、四肢的关系。

泛化关系(generalization)#

泛化关系定义为一个较普通的元素与一个较特殊的元素之间的类元关系。其中描述一般的元素称为父，描述特殊的元素称为子。（子类是父类的继承，则父类就是子类的泛化。）

通过泛化对应的继承机制使子类共享父类的属性和操作，缩小了模型的规模，同时也防止了模型的更新所导致的定义不一致的意外。

泛化关系用一条带空心箭头的直接表示，如下图表示（A继承自B）：

eg：汽车在现实中有实现，可用汽车定义具体的对象；汽车与SUV之间为泛化关系；

注：最终代码中，泛化关系表现为继承父类（抽象类、非抽象类）。

泛化关系的特征#

传递性：一个类子类的子类同样继承了这个类的特性。在父方向上经过了一个或几个泛化的元素被称为祖先，在子方向上则被称为后代。
反对称性：泛化关系不能成环，即一个类不可能是自己的祖先和自己的后代。

泛化关系的两种情况#

单继承：每个类之多能拥有一个父类（C#、Java等编程语言）。

多重继承：子类可以有多个父类并继承了所有父类的结构、行为和约束（C++等编程语言）。

依赖关系(dependency)#

依赖关系是用一套带箭头的虚线表示的，如下图表示A依赖于B。它描述一个对象在运行期间会用到另一个对象的关系。

与关联关系不同的是，它是一种临时性的关系，通常在运行期间产生，并且随着运行时的变化，依赖关系也可能发生变化；

显然，依赖也有方向，双向依赖是一种非常糟糕的结构，我们总是应该保持单向依赖，杜绝双向依赖的产生；

注：在最终代码中，依赖关系体现为类构造方法及类方法的传入参数，箭头的指向为调用关系；依赖关系除了临时知道对方外，还是“使用”对方的方法和属性；

实现关系(realize)#

实现关系用来表示规格说明与实现之间的关系。在类图中，实现关系主要用于接口与实现该接口的类之间。
一个类可以实现多个接口，一个接口也可以被多个类实现。

实现关系的两种表示法：

• 当接口元素以带构造型的类的方式表示时，用虚线三角形箭头表示。

• 当接口元素以小圆圈方式表示时，用实线表示。

注：最终代码中，实现关系表现为继承抽象类或实现接口。

综合例子#

一个常见的UML类图：

一个简化版的UML类图：

• 车的类图结构为<>，表示车是一个抽象类；
• 它有两个继承类：小汽车和自行车；它们之间的关系为实现关系（ 个人认为此处应该为泛化关系，用带空心箭头的实线表示），使用带空心箭头的虚线表示；
• 小汽车为与SUV之间也是继承关系，它们之间的关系为泛化关系，使用带空心箭头的实线表示；
• 小汽车与发动机之间是组合关系，使用带实心箭头的实线表示；
• 学生与班级之间是聚合关系，使用带空心箭头的实线表示；
• 学生与身份证之间为关联关系，使用一根实线表示；
• 学生上学需要用到自行车，与自行车是一种依赖关系，使用带箭头的虚线表示；

类的其他概念#

抽象类#

抽象类即不可实例化的类，也就是说，抽象类没有直接的实例。

在UML中，抽象类通过对类名添加斜体修饰来表示。

模板类#

模板又称为参数化元素是对一类带有一个或者多个未绑定的形式参数的元素的描述。模板应用在类上时称为模板类。

对应概念：C++中的模板、Java和C#中的泛型

模板类可以根据参数来定义类，而不用说明属性和操作参数及返回值的具体类型，使用时通过实际值代替参数即可创建新的类，这样就可以避免建立大量功能相似的类。

关联类#

具有类的特性的关联关系，称为关联类。关联类具有关联和类二者的特性，它既可以关联类元素，也可以拥有属性和操作。

关联类在UML中被表示为一个类符号，并通过一条虚线连接到关联路径。

分析类#

分析类是一个主要用于开发过程中的概念，用来获取系统中主要的“职责簇”，代表系统的原型类，是带有某些构造型的类元素。
边界类：用于对系统外部环境与其内部运作之间的交互进行建模的类。
控制类：对一个或多个用例所特有的控制行为进行建模的类。
实体类：用于对必须存储的信息和相关行为建模的类。

类图的建模技术#

对逻辑数据库模式建模：

• 识别模型中那些状态必须超过应用程序生存时间的类作为需要作为永久数据存储的类。
• 创建一个包含这些类的类图。可以自己定义相关的构造型和标记值组合。
• 对类的结构细节进行细化。包括属性的细节、类之间的关联及其多重性。
• 注意那些增加数据库设计复杂化的公共模式并尽量简化，如循环关联、一对一的关联和N元关联等。
• 考虑类的行为。这些行为主要包括对数据存取和数据完整性约束重要的操作。一般情况下，这些业务规则应该被封装在这些永久类的上一层中。

如何阅读类图？#

阅读顺序应遵循的原则：

• 先看清有哪些类
• 然后看看类之间存在的关系
• 结合多重性来理解类图的结构特点以及各个属性和方法的含义