UML笔记 - 类图
Posted 鱼鱼不愚
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了UML笔记 - 类图相关的知识，希望对你有一定的参考价值。
3. 类图、对象图和包图
3.1 类图
在面向对象的处理中，类图处于核心地位，其提供了用于定义和使用对象的主要规则。
3.1.1 概述
类图是描述类、接口以及它们之间关系的图，其显示了系统中各个类的静态结构，是一种静态模型。
类图用于对系统的静态视图建模，通常有以下方式：
-
对系统的词汇建模 -
对协作建模 -
对数据库模式建模
3.1.2 类及类的表示
类定义了一组具有状态和行为的对象，这些对象具有相同的属性、操作、关系和语义。
UML规范用具有3个预定义分栏的图标表示类，分栏自上而下分别表示：名称、属性和操作。
1. 名称
类名通常表示为一个名词，不带前后缀，命名最好能够反映类所代表的问题域中的概念。
规范的类名单词首字母要大写！！
2. 属性
属性即特性，描述了类在软件系统中代表的事物（对象）所具备的特性。描述语法如下：
[可见性] 属性名 [:类型] [=初始值] [{属性字符串}]
可见性有三种：
-
Public：公开外部可查看、使用和更新。 -
Protected：其属性和操作可以被类的其它方法访问，也可以被子类访问。 -
Private：只有类本身能够访问、使用。
UML不像Java还有指定的default类型，但实际绘UML类图时可见性还有Package包可见。
属性名：
UML规定属性名用小写，多个单词组合时第二个单词开始首字母大写。
3. 操作
属性是要处理的数据，操作则是描述了处理数据的具体方法，即是对其所属对象的行为进行抽象。
操作和属性差不多规则，也有可见性，命名规则也一样。
4. 职责
操作分栏下面可以另加的分栏，用于说明类的职责，即类或其他元素的契约或者义务。
5. 约束
和职责的意义差不多，但形式不一样，约束是对类的一种规范。用花括号括起来的文本表示。
3.1.3 定义类
构造类图之前，要定义类，然后定义属性、操作。其实编程时经常定义操作对象，所以这个就看经验吧。
3.2 关联关系
对象之间的通信手段即关系。
3.2.1 二元关联
关联是以属性形式包含对其他类的一个或多个对象的引用，二元关联即只有两个类参与的关联。
1. 关联的名称
关联名称表示了关联的内容，是为了清晰而简洁地说明对象间关系的目的，关系的目的用于指导对对象之间的通信方式进行定义，同时决定每个对象在通信中所扮演的角色。
2. 关联的端点
关联的端点作为具有相应规则的独立实体，其包含了对象在关联中扮演的角色，以及关联的数量，对象之间是否有顺序排列，对象的访问特征及一个端点的对象是否可以访问另一端点等。
3. 关联中的角色
角色名称描述了不同类型的对象参与关联的方式。
4. 可见性
参考前文。
5. 多重性
多重性指有多少对象可以关联。
6. 定序
即{ordered}关键字，表示对多重性的对象进行一定顺序排列。
7. 约束
定序也算是约束了。
8. 限定符
就是关系型数据库中的外键，即可以用其定义被参考对象的一个属性，并能够适使用该属性作为之间访问被参考对象的关键字。
使用限定符的关联被称为受限关联。
9. 导航性
就是关联可以有箭头，如果存在箭头则表示该关联是单向的，关联没有箭头的情况下都是双向的。
10. 可变性
可变性允许建模者对属于某个关联的链进行操作，默认是允许任何操作。
可以用{frozen}或{addOnly}等对可变性进行修改。
3.2.2 关联类
关联类就是与一个关联关系相连的类。在关系型数据库中，关联关系表里面就是一堆外键和一些其他的衍生信心。
3.2.3 或关联与反身关联
或关联是指对多个关联附加约束条件，使类中的对象只能参与一个关联关系。
反身关联就是自己与自己关联，即参与关联的对象属于同一个类，叫一元关联了。
3.2.4 聚合
聚合关系用于表明一个类拥有但可能共享另一个类的对象。整体类需要部分类组成，且部分类能独立或者组成其它类。
用的空心棱形箭头连接。
3.2.5 组成
与聚合相比，没了整体类，部分类也不可以参与其它东西了，也只能跟着整体类一起没了。
用的是实心棱形箭头连接。
3.3 泛化关系
就是继承关系。即一个类不仅用有自己独有的属性和操作，也能包含其它类的属性和操作。
用空心实线箭头连接。
泛化约束
约束都是用花括号括起来的。多个泛化使用同一约束，可以用虚线穿过两个泛化表示，也能将两个泛化的实线合并一起。
-
不完全约束(incomplete)：表示类图中没有完全显示出泛化的类，只是展示了一部分内容。 -
完全约束(complete)：你猜它的定义是什么？ -
解体约束(disjoint)：泛化类不能子类化为通用的类。我大儿子的孙子不能继承自我二儿子的意思。 -
重叠约束(overlapping)：和解体相反。
3.4 依赖关系和实现关系
依赖关系
依赖关系表示其中一个元素的改变会影响或提供消息给另一个依赖，即一个元素以某种形式依赖于另一元素。
依赖关系的类型：
-
使用依赖：包括调用、参数、实例化和发送，即某个模型元素需要用到已有的另一模型元素，是最常用的依赖关系。 -
抽象依赖：声明不同模型元素之间存在没有映射精确的连接。没有详细的语义，主要用于追溯跨模型中的系统要求及跟踪模型中的影响、变化。对应的还有精化依赖。 -
授权依赖：用于表示一个事物访问另一个事物的能力。有访问、导入、友元，其中访问是包的角度，友元是元素的角度。 -
绑定依赖：具有精确语义的高度结构化的关系，用于为模板参数提供值，以创建一个新的模型元素。
实现关系
实现关系用于规定规格说明与其实现之间的关系，通常用在接口及实现该接口的类之间。
3.5 构造类图模型
不写。
3.6 抽象类
允许具有属性及特定操作但缺少一部分定义的类，那一部分即抽象部分，其不允许被实例化，需要先被其它类继承并定义抽象部分。
需要注意的是，抽象类的类名和抽象操作都是斜体，图中吃饭是一个抽象类，且打饭操作已经实现了，但吃饭操作没有实现，为抽象方法，所以可以用其他类去继承吃饭类以实现吃饭的操作。
3.7 接口
接口只有一组抽象操作，不能有属性也不能部分定义。
人只依赖吃饭这个行为，但吃饭有多种实现方式，如拿筷子吃，拿勺子吃，所以吃饭可以作为接口，然后由其他类去实现它。
3.8 对象图
对象是类的实例，对象图也可以看作是类图的实例。其它不说。
3.9 包图
面向对象对包的概念应该是熟悉的了。
以上是关于UML笔记 - 类图的主要内容，如果未能解决你的问题，请参考以下文章
设计模式 - 学习笔记 - UML统一建模语言 - 类图Class Diagram