这一季我们来了解一下UML中的用例图。
在开发系统之前，最重要的工作是获取用户的需求，而在用户需求中最重要的是关于用户提出的系统功能性需求，我们可以借助用例图来可视化的表达用户的需求。
用例图（Use Case Diagram）是由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的视图，是被称为参与者的外部用户所能观察到的系统功能的模型图。
用例图常在需求分析阶段使用。
用例图中主要的元素包括参与者、用例以及各元素之间的关系。
除此之外，用例图中还可以包含注解和约束。
参与者（Actor）是与主体系统交互的外部实体。
参与者可以是系统外部的人、子系统、其它系统等。
每个参与者实际上是一个角色集。
在UML中，参与者使用使用人形的图形表示，并给这个参与者赋予一个名字。
如下图中的“读者”即是图书馆借阅系统中的一个参与者。
参与者应位于系统边界之外，而不是系统的一部分。
在进行用例建模时，确定参与者是用例图建模的第一步。那么，如何确定系统的参与者呢？我们可以从以下思路进行考虑：
（1）系统的服务对象
如图书馆借阅系统中的读者；
（2）为其提供支持以完成工作的人
如图书馆借阅系统中的图书馆工作人员，他需要借助系统帮助读者完成借阅、还书、催还工作。
（3）系统的维护者：负责安装、维护和管理系统的人员，这种情况下，需要系统确实提供了相关功能以帮助这类人员完成安装、维护和管理工作。
（4）外部设备：需要向外部设备传输信息或从外部设备读入信息，如读卡器。
（5）其它系统或子系统：如借阅系统中的财务系统，财务系统并非借阅系统的功能，但借阅系统需要向其传递信息以完成超期罚款工作。
（6）时间：在预定的时刻，有特定事件自动发生，如自动备份、定时提醒等。
（7）特定事件：如外卖系统中自动接单，是由订单产生事件推动的。
在识别参与者时，要注意以下几点：
参与者位于系统的外部，而不是系统的一部分；
参与者通过系统边界与系统进行交互；
参与者的图标虽然使用人形图标来表示，但参与者不一定是人，也可能是其它子系统、其它系统、时间、温度等其它因素。
参与者间的主要关系是泛化。泛化关系是一般和特殊（具体）之间的关系。
在泛化关系中一个参与者的抽象描述可以被一个或多个具体的参与者所共享。
下图描述了图书馆借阅系统中参与者之间的泛化关系。
上图中，读者是一个“一般”参与者，下面的教职工、学生、教职工家属等是“具体”的参与者。
泛化使用实线空心三角形箭头来表示，箭头指向更一般的参与者，箭尾端在“具体”参与者这端。
参与者泛化可以理解为：“具体”参与者是一种“一般”参与者，如教职工是一种读者。
在参与者泛化中，表示“一般”参与者可执行的用例，作为“具体”（“特殊”）参与者也可以执行。
用例是参与者可以感受到的系统服务或功能单元。它定义了系统要实现的一个目标。用例只定义系统的一个行为，而不显示系统的内部结构。
用例最大的优点是站在用户的角度描述系统功能。
在图形上，用例使用实线椭圆来表示，并在椭圆内部或下部标注用例的名称：
可以通过以下要点来识别用例：
（1）参与者需要系统提供哪些功能，以支持他的工作？
（2）参与者是否需要查询系统中的某些信息？
（3）参与者是否需要改变系统中的某些信息，如创建、修改和删除操作？
（4）系统发生的特定事件或状态的改变是否需要通知参与者？
（5）系统哪些外部事件会促使系统执行相关功能以应对？
（6）系统是否提供相关功能以帮助维护人员来维护系统？
（1）识别出的用例应该反应出系统的目标，即“要做什么”，而非“怎么做”，就是说用例不是系统实现的细节；
（2）从参与者（用户）的角度出发定义用例，而非系统的角度。
（3）用例应为参与者提供有价值的结果，而非动作的集合；
（4）避免陷入功能分解，步骤分解；
（5）每个参与者都应该有可执行的用例，每个用例都应关联至少一个参与者
在确定好系统的用例后，需要给各个用例进行命名。
用例的命名需要站在用户的角度描述参与者达到的目标。可以使用下述命名方式：
（状语）动词+（定语）宾语
也就是说，用例的名称应该是动宾短语的格式。
如选课、借阅图书、订购货物、使用信用卡支付。
用例粒度是指用例细化或综合系统功能的程度。也可以说用例所包含的系统服务或功能单元的多少。用例粒度过粗或过大，则用例包含的系统功能就越多，反之越少。
用例粒度过粗，不便于理解系统，粒度过细会使用例模型过于庞大，给设计带来困难。
用例粒度过细，可能会陷入功能分解，如：
实际上，系统中很多业务都包含这种增、删、改、查的操作，这样做并不能为用户提供任何有意义的目标，反而会忽略了用户的真正目的。
上面这种“增删改查”无非就是用户管理，这才是参与者的真实目的。使用下面这种方式处理上面的用例也许会更好一些：
管理用户这种用例体现了系统管理员的一个目标或任务。如果非要添加上增删改查，可以使用下面的方式来表达会更好一些。
在用例建模中常犯的另外一个错误是把步骤当用例。
如下面这个，似乎挺完美，但是很明显是把操作步骤当用例了。
上面这些步骤，无非就是完成用户这个参与者的目标：注册。因此，应该改成下面这个样子：
在用例建模中，常犯的第3个错误是把系统活动当用例。
上面这个用例图中，建立连接对象、建立命令对象和执行SQL语句是系统内的活动，是用户无法感知的，不是用户的目的，用户也不关心。所以这种用例图是不准确的。
用例建模中常犯的第4个错误是使用系统观点来命名用例。
上面左右这两个用例图，哪个画得更好呢？
很明显，右边的比左边的要好，因为右边的是从用户的角度命名的用例，而左侧的用例是从系统的角度对用例进行命名，用户看到后会感到莫名其妙的。
用例图在总体上描述了用户的功能需求（系统提供的功能或服务），但对于每个用例还要进行详细的描述，以便让人知道这个用例具体要做什么，这就是用例规约。也就是说，用例模型实质上是由用例图和对每一个用例的详细描述（用例规约）组成的。
一个用例规约（use case specification）应该包含以下内容：
（1）用例的标识与名称；
（2）用例涉及到的参与者；
（3）用例的简要说明；
（4）相关的其它用例；
（5）用例执行的前置条件
（6）基本事件流；
（7）备选事件流；
（8）用例执行的后置条件；
（9）其它信息，如非功能性需求、设计约束、用例审核状态、编制者、修改记录等。
下面是一个用例文档中对借阅图书用例的一个描述情况。
用例之间的关系主要包括泛化、包含和扩展三种。
当多个用例拥有相似的属性或行为时，我们可以将它们的共性抽象为父用例，而其它用例作为泛化关系的子用例。子用例继承父用例中的属性和行为。
用例的泛化关系可以理解为同一业务目的的不同实现路径。
泛化（Generalization）关系在图形上使用带空心三角形箭头的实现表示，箭头由子用例指向父用例。
上面这个例子中，“使用微信支付”和“使用支付宝支付”是“支付”的子用例。在父用例“支付”中并不提供具体的支付方式，只提供支付必须的属性和接口，而在其子用例中实现具体的支付功能。
在系统建模过程中，有些功能在不同业务情境中需要反复使用。这些反复使用的功能可以单独剥离出来形成一个单独的用例，而在执行相关功能时，可以把剥离出来的公共功能再包含到主流程中去。用例的包含关系就可以描述这种情形。另外，如果一个基本用例的功能过多时，也可以把其拆解成多个小的用例。
被包含的用例称作提供者用例，包含其它用例的用例称作客户用例。
在UML中，包含（include）关系使用带<<include>>构造型的虚线箭头表示，箭头由基本用例（包含用例/客户用例）指向被包含的用例（提供者用例）。
下面是一个具体的例子：
在这个例子中，读者要预借图书，他需要执行查询图书用例，才能执行预借图书，所以查询图书用例将被包含到预借图书用例中来，同时，读者要执行预借图书时，前提他必须已经登录到系统中，系统已经保存了他的登录状态才能执行预借操作，所以验证身份用例也将被包含到预借图书用例中来。查询图书即是一个读者要求具有的一个基本功能，又是其它功能的一个必要操作过程。验证身份不仅在预借图书时要用到，还要在执行如查询借阅记录、缴纳罚款时等用到的一个功能，把验证身份单独提出来形成一个用例比较合适。
基本用例提供扩展点，在扩展点中可以添加新的行为，扩展用例提供了一组插入片段，这些片段能插入到基本用例的扩展点上。
基本用例仅提供扩展点，而不必知道扩展用例的任何细节。
基本用例即使没有扩展用例也是完整的，这与包含关系不同。
一个用例可以提供多个扩展点，每个扩展点也可出现多次。
一般情况下，基本用例的执行不会涉及到扩展用例，只有在特定条件或事件发生时，才会执行扩展用例的功能。
在UML中，扩展关系使用带构造型<<extend>>的虚线箭头表示。箭头由扩展用例指向基本用例。
下面这个例子是图书馆借阅系统中，一个用例图片段：
在这个例子中，缴纳罚款即是读者的一个基本用例，也是归还图书的一个扩展用例。
“缴纳罚款”作为“归还图书”的扩展用例，只有在以下条件时，才会被执行：
（1）读者图书有超期或其它原因产生有罚款记录，且未缴清；
（2）读者选择了在归还图书后，同时缴清罚款。
扩展关系与包含关系有什么不同呢？
扩展关系中，基本用例是完整的，执行基本用例不一定执行扩展用例；但包含关系中的基本用例不完整，执行基本用例必须执行包含用例。
在下一篇文章中将给出一个具体的用例图案例，敬请关注。
新闻热点
疑难解答
