目录
定义
类图 Class diagram通过显示出系统的类以及这些类之间的关系来表示系统。类图是静态的一它们显示出什么可以产生影响但不会告诉你什么时候产生影响。在系统分析阶段将类分成三种类型:实体类、边界类、控制类
- 边界类用于描述外部参与者与系统之间的交互。识别边界类可以帮助开发人员识别出用户对界面的需求。
- 实体类主要是作为数据管理和业务逻辑处理层面上存在的类别;它们主要在分析阶段区分。实体类的主要职责是存储和管理系统内部的信息,它也可以有行为,甚至很复杂的行为,但这些行为必须与它所代表的实体对象密切相关。
- 控制类用于描述一个用例所具有的事件流控制行为,控制一个用例中的事件顺序
用途
类图的目的是显示建模系统的类型,描述组成系统的对象内容与对象之间的关系。
组成元素以及元素之间的关系说明
类名
类的UML表示是一个长方形,垂直地分为三个区。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在一个类图上画一个类元素时,你必须要有顶端的区域,下面的二个区域是可选择的(当图描述仅仅用于显示分类器间关系的高层细节时,下面的两个区域是不必要的)。一个航线班机如何作为UML类建模。正如我们所能见到的,名字是 Flight,我们可以在中间区域看到 Flight类的3个属性: flightNumber, departureTime和 flightDuration 在底部区域中我们可以看到 Flight类有两个操作: delay Flight和 getArrivalTime
类属性列表
类的属性节(中部区域)在分隔线上列出每一个类的属性。属性节是可选择的,要是一用它,就包含类的列表显示的每个属性。如下格式:
- name： attribute type
- flightNumber： Integer
继续我们的 Flight类的例子,我们可以使用属性类型信息来描述类的属性
| 属性名称 | 属性类型 |
| flightNumber | Integer |
| departureTime | Date |
| flightDuration | Minutes |
在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。然而,用于生成代码的类图,要求类的属性类型必须限制在由程序语言提供的类型之中,或包含于在系统中实现的、模型的类型之中。
在类图上显示具有默认值的特定属性,有时是有用的(例如,在银行账户应用程序中,一个新的银行账户会以零为初始值)。UML规范允许在属性列表节中,通过使用如下的记号作为默认值的标识
- name ：attribute type = default value
举例来说:
- balance ： Dollars = 0
显示属性默认值是可选择的; 显示一个银行账户类具有一个名为 balance的类型,它的默认值为0。
类操作列表
类操作记录在类图长方形的第三个(最低的)区域中,它也是可选择的。和属性一样,类的操作以列表格式显示,每个操作在它自己线上。操作使用下列记号表现:
- name(parameter list): type of value returned
delay Flight操作有一个 Minutes类型的输入参数— numberofminutes。然而, delayFlight操作没有返回值。当一个操作有参数时,参数被放在操作的括号内;每个参数都使用这样的格式:“参数名:参数类型
当文档化操作参数时,你可能使用一个可选择的指示器,以显示参数到操作的输入参数、或输出参数。这个可选择的指示器以“in”或“out”出现，一般来说，除非将使用一种早期的程序编程语言,如 Fortran，这些指示器可能会有所帮助，否则它们是不必要的。然而,，C++和Java中，所有的参数“in”参数，而且按照UML规范。既然“in”是参数的默认类型，大多数人将会遗漏输入/输出指示器。
继承
在面向对象的设计中一个非常重要的概念,继承,指的是一个类(子类)继承另外的个类(超类)的同一功能,并增加它自己的新功能(一个非技术性的比喻,想象我继承了我母亲的一般的音乐能力,但是在我的家里,我是唯一一个玩电吉他的人)的能力。为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单 键头（或三角形）的实线指向超类。考虑银行账户的类型：图显示CheckingAccount 和SavingsAccount类如何从BankAccount类继承而来。
图中继承通过指向超类的一条闭合的，单箭头的实线表示。在图中，继承关系由每个超类的单独的线画出，这是在IBMRational Rose和IBM Rational XDE中使用的方法。然而，有一种称为超协诃的备选方法可以画出继承关 系。当存在两个或更多子类时，如图中所示，除了继承线象树枝一样混在一起外， 你可以使用树形记号。下图是重绘的与上图 一样的继承,但是这次使用了树形记号。
抽象类及操作，在图中，类名BankAccount中withdrawal 使用virtual。这表示，BankAccount类是一个父类，而withdrawal方法是虚方法。换句话说，BankAccount类使用withdrawal规定抽象操作，并且 CheckingAccount和SavingsAccount两个子类都分别地执行它们各口版本的操作。然而，超类（父类）不一定要是抽象类。标准类作为超类是正常的。
关联
当你系统建模时,特定的对象间将会彼此关联，而且这些关联本身需要被清晰地建模。 有五种关联（关联关系、聚合关系、依赖关系、泛化关系、实现关系）。
关联（Association）关系
关联关系是一种结构化的关系，指一种对象和另一种对象有联系。它使一个类知道另一个类的属性和方法。
关联关系有双向关联和单向关联。
- 双向关联：两个类都知道另一个类的公共属性和操作。
- 单向关联：只有一个类知道另一个类的公共属性和操作。
大多数关联应该是单向的，单向关系更容易建立和维护，有助于寻找可复用的类。例如航班需要使用到飞机，飞行行需要飞机，飞机需要飞行员。
UML图中实现使用一条实线箭头连接相同或不同类。
聚合（Aggregat ion)关系
聚合也称聚集，是关联的特例。表示类与类之间的关系是整体与部分的关系，即一个表示整体的模型元素可能由几
个表示部分的模型元素聚合而成。
- 共享聚合：如果在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成，则该聚集成为共享聚合。
- 复合聚合（简称为组成）：如果部分类完全隶属于整体类，部分与整体共存，整体不存在了部分也会随之消失（或失去存在价值），则该类聚集成为复合聚合。
普通关联关系的两个类处于同一层次上，而聚合关系的两个类处于不同层次：一个整体，一个部分。同时，是一种弱的”拥有“关系。此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与部门，公司与员工的关系等。表现在代码层面，和关联关系是一致的，只能从语义级别来区分。
UML图中聚合使用一条带有虚心菱形（聚合），实心菱形（组合）的线来表示。
依赖（Dependency)关系
依赖关系描述两个模型元素（类、用例等）之间的语义关系：其中一个模型元素是独立的，另一个模型元素不是独立的，它依赖于独立的模型元素，如果独立的模型元素改变，将影响依赖于它的元素。
例如：如果A依赖于Ｂ，则Ｂ体现为局部变量，方法的参数、或静态方法的调用。依赖就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是类B的变化会影响到类A。比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖。表现在代码层面，为类B作为参数被类A在某个method方法中使用。在UML类图设计中，依赖关系用由类A指向类B的带箭头虚线表示。
UML图中依赖使用一条右箭头的虚线指向被依赖的类。
泛化（Generalization）关系
UML中的泛化关系定义了一般元素和特殊元素之间的分类关系，与C++及Java中的继承关系有些类似。具体形式为类与类之间的继承关系，接口与接口之间的继承关系，类对接口的实现关系。
泛化可分为普通泛化和受限泛化。
UML图中泛化使用一条带有空心三角箭头的实现指向基类。
实现（Realization）关系
实现关系将一种模型元素（如类）与另一种模型元素（如接口）连接起来，其中接口只是行为的说明而不是结构或者实现。真正的实现由前一个模型元素来完成。或者理解为：一个类实现接口（可以是多个）的功能；
实现是类与接口之间最常见的关系，在以下两种地方会经常遇到：
- （1）一种是在接口和实现它们的类或构件之间；
- （2）一种是在用例和实现它们的协作之间。
实现指的是一个class类实现interface接口（可以是多个）的功能，实现是类与接口之间最常见的关系
UML图中实现使用一条带有空心三角箭头的虚线指向接口。
画法例子
=====================================================================
将源码直接转换成类图可参考如下：
1559
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
