UML 用例图

用例图简介：

Use case diagrams (UCDs) ：用例图用于描述Actor和System之间的关系。我们使用用例图进行分析，描述用户的需求，确定系统的行为和边界。它是用于描述系统的外部视图。

用例图中的元素：

实体模型：

Use Case：代表用户期望系统需要提供的功能。

Actor：使用这些功能的人或者与该系统有交互的组织或者外部系统。（不一定是人，也可以是系统）

System bound：系统边界，用于区分Use Case和Actor之间的边界。

连线模型：

Association: 

用例和用户之间的关系，表示用户参与了某个用例

Generalization：

也是一种关系，类似继承 。 比如说：订票，分为电话订票，按网上订票。电话订票和订票之间，就是泛化关系。

Include：

 Include关系主要用于显示用例如何分解为较小的步骤。 被包括用例位于箭头端。 分解后的小步骤跟操作顺序无关。 

For Example:

在订餐系统中，订餐是一个用例，该用例中包含如下：选择菜单、点菜、付款。订餐和点菜之间的关系就是include关系。

Extend：

扩展用例向被扩展用例添加目标和步骤。  被扩展用例位头端于箭。一般在增加一些条件时会使用。

Dependency
指示源的设计依赖于目标的设计。

UML中扩展和泛化的区别 

 用例图中的泛化 泛化类似于“继承”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；

包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：

泛化 侧重表示子用例间的互斥性，公共的相同部分已经提取出来，作为父用例，子用例之间应该是不包含相同的；

包含 侧重表示被包含用例对Actor提供服务的间接性；

扩展 侧重表示扩展用例的触发不定性；

  既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：

         ⒈无条件发生：肯定发生的；

         ⒉有条件发生：未必发生，发生与否取决于系统状态；

         

因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。

进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

用例图示例：

需求：开发一个家庭报警系统。

1.要求能够通过一个keyboard开启报警系统或者关闭报警系统，不管是开启还是关闭都要输入密码，要求能够修改密码。

2. 当户主输入正确密码并点击开启按钮后后，有一个延迟的时间让户主离开，离开后，报警系统真正开启

3. 当报警系统是开启的，并且门被打开了，有一个进入延迟，户主可以在这个时间关闭报警系统。而入侵者无法关闭系统，就会开始报警。

4.  报警系统是开启，并检测到入侵，开始报警（入侵不一定是打开门，比如检测到人在房间里移动也是）。

应用场景如下：一个家庭报警系统，Actor分为两类，房主（homeowner）、入侵者(intruder)

看看有哪些用例，房主希望这个系统提供这些功能：

检测入侵：具有入侵检测功能，能够发现非法用户进入

仿真测试：进行非法用户入侵的仿真

开启预警系统

关闭预警系统

启动警报声

密码输入：支持密码输入

修改密码：能够修改密码

开启警报和关闭警报依赖密码输入，所以两者之间是依赖关系。

其中修改密码依赖密码输入，所以两者之间是依赖关系。

仿真测试是模拟真实入侵检测，但是不是一定会发生的，

                         图1：该图时Rhapsody自带的例子中第一张图，也是分析的起点：用例图

参考资料：

1. Rhapsody User Guide （该文档是rhapsody建模工具自带的帮助文档，阐述了UML Use Case Diagram基本元素的概念）

2. http://www.cnblogs.com/fan0136/archive/2008/12/14/1354730.html  该文档讲述了 UML中扩展和泛化的区别 

转载于:https://my.oschina.net/myspaceNUAA/blog/58088