UML—Use Case Diagram

用例图是软件需求分析到最终实现的第一步，用于描述人们希望如何使用一个系统。

用例图显示了谁是相关的用户、用户希望系统提供什么服务，以及用户需要为系统提供的服务。

Use Case Diagram是由参与者（Actor）、用例（Use Case）以及他们之间的关系构成的用于描述系统功能的动态视图。

用例图的组成

一：参与者（Actor）

系统外部并直接与系统进行交互的人、系统、子系统、类的外部实体的抽象。

每个参与者可以参与一个或多个用例，每个用例可以有一个或多个参与者。

二：用例（Use Case）

是参与者（角色）可以感受到的系统服务或功能单元。

它把系统当作一个黑盒子，并不关心系统内部是如何完成它所提供的功能，表达了整个系统对外部用户可见的行为。

三：关系

1> 参与者之间的关系

泛化关系（继承关系）

2>用例间的关系

1泛化关系（generalization)

2扩展关系（extend）

在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例（extension），原有的用例叫基础用例（Base）

应用：往往被用来处理异常或构建灵活的系统框架。

优点：降低系统的复杂度，有利于系统的扩展，提高系统的性能。

  

3包含关系（include）

用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为

作为自身行为的一部分。

优点：*不但可以避免在多个用例中重复的描述同一段行为，而且还可以避免在多个用力中对同一段行为描  述的不一致。

      *提高了用例模型的可维护性，当需要对公共需求进行修改时，只需要修改一个用例而不必修改所有   与其相关的用例。

泛化关系	包含关系
类似于继承，把多个例子中的共性抽象成一个父用例，子用例在继承父用例的基础上可以修改。子用例之间是相互独立的。	把多个基础用例中的共性抽象为一个被包含的用例，被包含的用例就是基础用例中的一部分，基础用例的执行必然引起被包含用例的执行。
所有子用例都有相似的目的和结构，他们是整体上的相似	基础用例在目的上可以完全不同，单他们都有一段相似的行为，他们相似是部分的相似，而不是整体的相似

 

扩展关系	包含关系
基础用例的执行并不一定会涉及到扩展关系，扩展用例只会在一定条件下才会被执行	基础用例执行后，被包含的用例一定会执行
基础用例提供了一个或多个插入点，扩展用例为这些插入点提供了需要插入的行为	插入点只能有一个
没有扩展用例，扩展关系中的基础用例本身就是完整的	基础用例在没有被包含用例的情况下是不完整的存在

绘制用例图步骤

01.需求分析

02.识别参与者

03.识别用例

04.构件用例模型