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