UML-用例、类图、类图之间的关系详解

一、用例图

用例图的基本概念

由参与者、用例以及用例与用例之间的关系构成的用于描述系统功能的动态视图称为用例图。

参与者的基本概念

参与者(Actor)是指存在于系统外部并直接与系统交互的人、系统或者设备等。

参与者在画图中使用简笔人物画来表示，如下所示：

用例的基本概念

用例是系统为参与者提供的功能。

对于用例的命名，我们可以给用例取一个简单的、概括性的，一般带有动作性的词语。

用例的图形化表示，如下所示： 

参与者和用例的关系

如下所示： 

用例与用例之间的三个基本关系

① 包含关系（include）：一个用例中包含了其他的用例。 先看一个购买**的例子：

解释：当一个彩民进入到手机App页面后，购彩大厅页面包含了注册和登陆按钮，而注册和登陆按钮分别对应着两个页面。而用户，可能会经过购彩大厅去注册或者去登陆。包含关系，一般含有这一个意图的延续性。

② 扩展关系（extend）： 将基用例中一段相对独立并且可选的动作。看一个简单的登陆页面：

对于自动登陆而言，它相对于登陆页面是相对独立，并且可选的，这个就叫做扩展关系。图形关系如下所示：

解释：对于彩民而言，他经过购彩大厅，主要的目标可能是登陆（延续性），但是他登陆并不代表他会把自动登陆给选上，这里面没有延续性，可能选择也可能不选择，只能作为登陆的一个跟屁虫存在，如果登陆界面不存在了，那么自动登陆也没有存在的必要了。

③ 泛化关系（generalization）：代表着一般到特殊的关系。反应到代码中，要么是接口和实现类的关系，要么是抽象类和子类的关系。图形化表示如下所示：

解释：对于”双色球选号”or”福彩3D选号”来说，选号是他们公共的部分。

二、类图

简单的类图

先看一个简单的代码与类图的对应关系的示例：

解释：我们可以把类图看成三个抽屉，第一个抽屉对应着类名，第二个抽屉对应着成员变量，第三个抽屉对应着方法。

一个完整的类图：

如何表示一个抽象类

图片如下所示，第一个抽屉中的字体是斜体：

如何表示一个接口

类与类之间的关系

①泛化(父子)关系（Generalization）：在Java中，此类关系通过关键字extends来明确的标识。

在UML中如下所示：

②实现关系（Realization）：在Java中，此类关系通过implements来标识。

在UML中如下所示：

③依赖关系（Dependency）（很薄弱的关系，很少画）：依赖关系体现为，局部变量、方法中的参数、和对静态方法的调用。

在UML中如下所示：

④ 关联关系（Association）：如果在Field中出现了其他类的引用，那么它就是关联关系。

这些关系出现的位置有迹可循，请看下图：

但是，关联关系中也有区别的，有如下几种形式： 
1. 单向关联：单相思 
2. 双向关联：心心相印，彼此都有对方的引用 
 
3. 自关联：自己有自己的引用，典型的应用是单例模式 
 
3. 聚合：是整体和部分的关联，描述的是”has a”的关系。汽车 = 发动机+轮子。当汽车报废时，发动机和轮子不一定会报废，可能会进入二手市场。 
 
4. 组合：首先，是整体和部分的关系，但是和聚合有些区别，整体会控制部分的生命周期，是一种产生（或者叫生产）的关系。例如：公司 = 部门1+部门2….。当公司倒闭是时，部门也就没了，会随之销毁。 

类图解决的问题

① 数据封装成类

② 类与类之间的关系

本文转自：

http://blog.****.net/biezhihua/article/details/43793729