用例图

用例图

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

椭圆表示用例，用例名称放在椭圆的中心或下面

参与者（人形符号）用箭头的线段表示参与者和用例之间的关系，箭头所指表示对话的被动接受者

可以使用注释，更清晰的描述用例和参与者

（黑盒子）

构成

1. 参与者（Actor）

​ 是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。
​ 每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。
　　在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。

2. 参与者间的的关系

​ 参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）
​ 泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。

3.系统边界

​ 系统边界是指系统与系统之间的界限（通常说的系统可以认为是由一系列相互作用的元素形成的具有特定功能的有机整体）

​ 系统是相对的，一个系统本身可以是另一个更大系统的组成部分。系统和系统之间需要使用系统边界区分开。

​ 系统环境：系统边界以外的同系统相关联的其他部分

重要元素

1.如何识别

任何用例图都不能在缺少参与者的情况下独立存在，同样，任何参与者也必须要与之关联的用例。所以识别用例的最好方法就是从分析参与者开始，在分析过程中往往会发现新的参与者。

• 参与者希望系统提供什么功能
• 参与者是否会读取、创建、修改、删除、存储系统的某种信息；如果是，参与者如何完成这些操作的
• 参与者是否会将外部的某些事件通知给系统
• 系统中发生的事件是否通知参与者
• 是否存在影响系统的外部事件

2.用例的粒度

粒度是指：用例所包含的系统服务或功能单元的多少。粒度越大，用例包含的功能越少。

用例数目过多会造成用例模型过大和引入设计困难大大提高，用例数目过少会造成用例的粒度太大，不便于进一步的分析。

3.用例规约

对每个用例，需要有详细的描述信息

• 简要说明：用例作用和目的的简要描述
• 事件流：包括基本流和备选流。基本流使用里的基本流程，“正常”运行的场景
• 用例场景：同一个用例在实际执行的时候有很多不同的情况发生，成为用例场景——即用例的实例
• 特殊需求：一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性登。（法律法规、应用程序标准和所构建系统的质量属性）
• 前置条件：执行用例前系统必须所属的状态（要求用户有访问权限或者要求某个用例必须先执行完）
• 后置条件：用例执行完系统可能处于的一个状态（比如，执行完一个用例，必须执行另一个用例）

4.关系

1.包含

一个用例包含其他用例，并把这个用例包含的用力行为作为自身行为的一部分。

把几个用例的公共部分单独的抽象出来成为一个新的用例：

1. 多个用例用到同一段的行为，把这段共同的行为单独抽象成为一个新的用例，让其他用例来包含这一用例
2. 某个用例的功能过多、事件流过于复杂，可以把某一段事件流抽象成一个被包含的用例，达到简化的目的

2.扩展

把新的行为加到已有的用例中，获得新的用例叫扩展用例，原有的叫基础用例

一个基础用例可以有一个或多个扩展用例

3.泛化

一个父用例可以被特化形成多个子用例，这种关系就是泛化关系

子用例继承了父用例所有的机构、行为和关系

子用例可以添加、覆盖、改变继承的行为