图书馆管理系统—需求建模1（用例图）

一、概述

用例模型是从应用领域的角度，面向用户的一种模型，旨在描述用户眼中（而非程序员眼中）此系统的功能。

用例图体现了该系统能够为参与者提供的种种功能以及这些功能之间的联系。

要画好一张用例图，需要把握三个元素：参与者（Actor）、用例（Use Case）和用例间的关系（Relationship）。

二、 参与者

参与者代表的是参与使用系统的一类角色，例如，读者就是图书馆这个系统的参与者。要正确把握参与者，需要注意以下几点：

1. 参与者本身并不属于系统结构之中，位于系统之外；

2. 参与者代表的是一类角色而不是一个具体对象，换言之，你可以说参与者是猪，而不能说参与者是“佩奇”；

3. 参与者不一定是人，也可以是另一个外部的系统、环境等等。

三、 用例

每个用例代表系统能够提供的一类功能，UML中使用一个椭圆形表示用例。

每个用例在文档中都需要进行详细说明，说明中需要包含：

1. 用例名称；

2. 用例的参与者：使用该用例的参与者；

3. 用例的进入条件：满足什么条件可以使用该用例；

4. 用例的离开条件：满足什么条件可以结束该用例的使用；

5. 流程：参与者使用该用例的步骤；

6. 特殊需求：包含对用例性能上的需求或者拓展业务。

四、 关系

用例之间的关系有三种：扩展、包含和继承。

1. 扩展

扩展关系是在一个已有用例的基础上扩展新的功能而产生的关系，常用于对特殊情况的补充。比方说，购票“选票->付钱->出票->找零”本身是一个完整用例，但是在过程中可能出现零钱不足、缺票、用户中途取消等特殊状况，处理这些特殊状况的功能就是扩展功能。

扩展功能在UML中用<>和箭头表示，由子用例指向主用例。箭头的方向与主语->宾语一致。即 A extends B， 代表A扩展了B的功能，所以箭头由A指向B。

2. 包含

包含关系指一个主用例包含子用例。包含关系常用于子用例频繁被使用的情况。例如下图所示的例子，买单次票与买多次用卡的用例中都包含了收费这一子用例，为避免重复书写子用例，我们使用包含关系。

包含关系在UML中用<>和箭头表示，箭头指向由主用例指向子用例。箭头方向依然可以用语法判断，若A包含B，箭头方向就是A指向B。

3. 继承

处于继承关系中的用例在不同抽象层，其中被继承的一方是继承的一方更概括抽象的概念。例如：主用例是“用户识别”，“人脸识别”是用户识别的一种，“指纹识别”也是用户识别的一种。在继承关系中常常出现“…是…的一种”（is a kind of）这样的关系，这可以帮助大家识别继承关系。下面是一个例子：

在UML中，继承关系由一个空心箭头表示，由继承的一方指向被继承的一方（具体的一方指向抽象的一方）。

在用例图中，用例关系的箭头方向是比较容易出错的一点，我的记忆方法是带入“A extends B”，“A includes B” 和 “A inherits B”这样的句型，箭头永远从主语指向宾语。