一用例图概述
所谓用例图是用来描述用户的需求，从用户的角度描述系统的功能，并指出功能的执行者，强调谁在使用系统，
系统为执行者完成了哪些功能。
用例图是需求分析的产物，描述了系统的参与者与系统进行交互的功能，是参与者所能观察和使用到的系统功能
的模型图。它的主要目的就是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的角色关系
以及系统各个功能之间的关系。它通过用例(Use Case)来捕获系统的需求，再结合参与者(Actor)进行系统功能需求的
分析和设计。
用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的功能，通俗地理
解用例就是软件的功能模块，所以是设计系统分析阶段的起点。设计人员根据客户的需求来创建和解释用例图，用来
描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以
求把系统的整个结构和功能反映给非技术人员(通常是软件的用户)，应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者(Actor)提供的一段完整的服务。从原则上来讲，
用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维
护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
由参与者(Actor)、用例(Use Case)以及它们之间的关系构成的用于描述系统功能的静态视图称为用例图。
二用例图的组成
用例图有四部分组成：参与者、用例、系统边界、子系统、关系。
(1)参与者(Actor)
在一个系统开发前，我们必定首先要确定系统的用户，系统的用户就是系统的参与者。除此以外，我们还会想
到，我们开发的系统与其他的系统有什么关联？因此，系统的参与者可分为两类，一类是人，包括系统的使用者、维
护者等，另外一类是其他系统。
参与者表示与你所做的应用程序或系统进行交互的用户、组织或外部系统。在系统外部与系统直接交互的人或事
物，需要注意以下两点：
1)参与者是角色而不是具体的人，它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运
作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不
同实例。
2)参与者作为外部用户(而不是内部)与系统发生交互作用，是它的主要特征。
在UML中，参与者使用如图所示的一个小人表示：
(2)用例(Use Case)
用例(Use Case)是参与者(Actor)可以感受到的系统服务或功能单元。是对包括变量在内的一组动作序列的描述，
系统执行这些动作，并产生传递特定参与者的可观察结果。通常我们把系统能做的事情或者说能完成的功能当做用
例，用一个动词或者是动词词组来给用例命名。
任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例，所以识别用例
的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。
系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者
之间交换的消息所表达。
UML中的用例使用用椭圆表示，椭圆中的文字简述系统的功能：
用例是有粒度的，用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功
能越多，反之则包含的功能越少。
用例的粒度划分：
1)概念级
2)用户目标级
3)子功能级
(3)系统边界
所谓系统边界是指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称之为系统环境。
UML中系统边界使用一个矩形边框来表示一个系统：
(4)子系统(Subsystem)
子系统用来展示系统的一部分功能，这部分功能联系紧密。
UML中子系统使用一个矩形边框表示一个子系统，里面可以写部分系统的描述：
(5)关系
所谓关系就是指参与者和参与者，用例和用例，用例和参与者之间的关系，通常分为四种：关联、泛化、包含、
扩展。
UML中标准的用例图中包含以下四种关系：
1)关联(Association)
表示参与者与用例之间的交互，通信途径，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
2)泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行
为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
3)包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】：指向分解出来的功能用例
4)扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。扩展用例是可选的，如果缺少扩展用例，
不会影响到基用例的完整性。
【箭头指向】：指向基础用例
包含(include)、扩展(extend)、泛化(Inheritance) 的区别：
条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条的；
直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提
供间接服务。
对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系。
下图提供一个完整的系统的用例图，让大家有一个感官上的全面认识。
三用例描述
描述用例，有时仅用例图是不够的，还需要用例描述。它可以更详细地描述用例的功能。用例描述的组成包含：
用例名称，简要说明，优先级，参与者，前置条件，基本事件流，其他事件流，异常事件流，后置条件。
(1)事件流
描述一个用例在执行时执行者与系统之间的交互过程。事件流就是用例执行时，由一序列活动组成的控制流。这
个过程包含多个分支：基本流和备选流。
基本事件流：对用例中常规和预期路径的描述。
其他事件流流：由于受到其他因素影响，用例执行来了其他的路径。
异常流主要是对一些异常情况、选择分支进行描述。
(2)前置条件
在用例启动时参与者(actor)与系统应置于什么状态。是该用例执行的前提条件，用来描述在什么条件下可以开始
执行一个事件流。
(3)后置条件
说明用例结束时系统的状态。
前置条件和后置条件可以用于用例的验证和评审。
(4)使用用例的注意事项：
1)应该清晰的定义系统边界
2)防止用例过多
3)应该从执行者的角度来命名用例
4)用例描述正规程度
5)避免执行者的名字不一致
6)避免执行者和用例之间的关系太复杂
7)注意用例的大小是否恰当
8)避免用例描述混乱
9)区分用力分解和功能分解
10)避免客户不能理解用例的情况发生
11)有些场合，用用例图描述需求是不适合的
总结
在软件工程中的需求分析阶段通常需要使用UML的用例图来对目标系统进行建模，通过可视化的用例模型，对将
要开发的系统有一个看得见的描述，从而使开发人员和用户对需求规格达成一个共识，同时也是开发者和客户进行交
流的一个有力工具。
用例模型描述了待开发系统的功能需求，它将系统看成黑盒，仅从外部执行者的角度来理解和描述系统，并且驱
动了需求分析之后各个阶段的开发工作。