第 用例和用例图

会计学1第用例和用例图5.1用例图概述在实际软件项目开发过程中，软件用户开始计划某个软件项目时，最先考虑的一定是软件产品功能的合理性，系统使用的方便性，软件界面的友好度等问题。至于整个软件系统是如何实现的，系统内部使用了哪些结构，应用了哪些技术，这些都不是用户所关心的内容。

UML用例图是软件产品外部特性描述的视图，它从用户的角度而不是开发者的角度来描述软件产品的需求，分析软件产品所需的功能和行为。用例图主要描述了系统需要实现的功能，而忽略系统是如何实现这些功能的。第1页/共42页5.1用例图概述下图是一个简单的在线购物系统，通过该用例图可以使系统的使用者和系统的开发者都对该在线购物系统有一个基本的了解。

管理员商品结算顾客商品浏览第2页/共42页5.1用例图概述

UML用例模型并不是单纯的只包括上图所示的用例图，还包括内容更加详细的用例描述。用例描述一般为单独的文档，用于详细说明一个用例。用例图一般用来从宏观上给出用例模型的基本轮廓，而用例的真正实现细节则由用例描述来详细说明。

第3页/共42页5.2为什么要使用用例图

用例模型由用例图组成，它是系统用例图的集合，是对系统从宏观角度的确定描述。用例模型主要用于需求分析阶段，该模型是系统开发者和系统使用者反复讨论的结果，表明了系统开发者和系统使用者对需求规格达成的共识。

首先，用例模型描述了待开发系统的功能需求；其次，用例模型将系统看作黑盒，仅从外部执行者的角度来理解系统；再次，用例模型驱动了需求分析之后各阶段的开发工作，影响到开发工作的各个阶段和UML的各个模型。

第4页/共42页5.2为什么要使用用例图使用用例图的主要原因主要有：明确系统已经具有的基本功能。明确了系统验收的基本要求，保证了用户最终得到的系统与当初需求的系统的一致性。通过对用例图建立详细的需求文档，明确系统各个功能的具体内容，明确各用例的前置条件和后置条件，明确用例的特殊要求等。为系统的后续开发提供一个统一的标准。

第5页/共42页5.3用例图元素用例图主要用于定义系统的功能需求，它描述了系统的参与者与系统提供的用例之间的关系，用例图仅从参与者使用系统的角度描述系统中的信息。用例图在UML中是一种比较简单的图，它没有包含过多的内容，只由几种简单的图符组成，一般情况，用例图由以下几种元素组成：

执行者、用例、系统、关系、用例描述第6页/共42页5.3用例图元素

5.3.1执行者

执行者（Actor）是系统的外部用户，它是与系统相关联的人或其它系统，可以是普通用户、外部硬件、其他系统。

执行者使用一个小人符号来表示，在符号下面标上这个执行者的名称，具体表示如图所示。

执行者第7页/共42页5.3用例图元素有些时候由于系统的外部执行者可能是其他的系统，因此有些时候也可以不使用小人的图符，而使用如图所示的执行者图符表示。该图符采用矩形表示，在上部写明《actor》标明该系统是个执行者。

每个执行者都需要一个简要的描述，用一句话或几句话对这个执行者进行说明。

第8页/共42页5.3用例图元素谁使用系统的功能。谁向系统提供必要的信息。谁从系统获取信息。谁维护、管理系统工作。系统需要使用哪些外部资源。需要与系统交互的其它系统有哪些。其他对系统产生的结果感兴趣的人或事物。在进行用例图绘制时，首先要找出系统的执行者。一般可以从以下几个方面来考虑怎样找到系统的执行者：第9页/共42页5.3用例图元素5.3.2用例

用例是指系统、子系统或类与外部执行者之间交互的动作序列说明，包括各种序列及出错序列。

用例用一个椭圆表示。用例的名称有两种标法：一种是把用例的名字写在椭圆的下面，另一种是把名字写在椭圆中。

用例名称用例名称第10页/共42页5.3用例图元素

用例描述的是用户可见的需求，一个具体的用户目标，也可以将用例理解为系统功能的分解。用例由执行者来执行，用例执行完成后将产生一个对执行者有价值的结果。用例可大可小，但必须是对具体的用户目标的描述。

同执行者一样，每个用例也可以增加一个简要的描述，用一句话或几句话对这个用例进行说明。在最初的用例分析中，使用这样简短的描述来说明一个用例。但随着分析的不断深入，用例的描述也变得更加详细。

第11页/共42页5.3用例图元素执行者要求系统提供哪些功能。执行者需要增加、查询、删除、修改或存储的信息有哪些。系统是否需要把自身的状态变化告诉执行者。系统是否需要知道哪些外部事件，执行者怎样把这些事件告诉系统。为了完整地描述用例，还需要知道执行者的某些典型功能是否能被系统自动实现。系统需要何种输入和输出，输入从何处来，输出到何处。如何对当前系统进行必要的维护。可以从以下几个方面来考虑怎样获取用例：第12页/共42页5.3用例图元素5.3.3系统在用例图中，为了清晰地表示出系统的边界可以使用系统图符，图符如图所示。图符把该系统的所有用例放在系统之中，外部执行者放在系统之外。使用系统图符将系统全部的用例包括在图符中，并在系统图符的上边标明系统名称。

网络购物系统第13页/共42页5.3用例图元素

使用系统图符是为了强调用例包含在系统内部，而执行者则不包含在系统之中。这样有利于分析系统的交互过程，有利于分析系统的接口和界面。

系统图符不是用例图必须的部分，在用例图中可以不使用该图符，但建议读者在自己画用例图时最好使用系统图符，这样有利于明确系统的范围。

第14页/共42页5.3用例图元素5.3.4关系

（1）关联在用例图中，用例和执行者之间的关系用一条连接二者带箭头的连线表示，如图所示，该连线称为关联。它表示了一个执行者和一个用例之间的关系。一个用例和一个执行者之间最多只有一个关联关系。但一个执行者可以和多个用例关联，同样一个用例也可以和多个执行者关联，正是由这种关联组成了系统的用例图。

第15页/共42页5.3用例图元素

在用例图中，关联关系只用在执行者和用例之间，用例和用例之间不会存在关联关系。关联关系采用的是单箭头的连线，表示在该关联中执行者是主动的，是执行者启动的用例。如下图所示。

顾客商品浏览在用例图中，一般情况下关联关系的箭头都是由执行者指向用例的，但在有些书籍中也有由用例指向执行者的情况，强调在关联中起主要作用的是用例。但这种方式并不值得推荐。

第16页/共42页5.3用例图元素

（2）包含

包含是指一个用例作为另一个用例必需的部分被使用，包含关系是依赖关系的一种。包含关系用一条连接二者带箭头的虚线表示，并在虚线的上面标注《include》，箭头方向由基本用例指向包含用例，如下图所示。<<include>>第17页/共42页5.3用例图元素

例如顾客通过网络购物系统看中了一件自己喜欢的商品，但现在又不想购买，只是想将该商品放在自己的收藏夹里，要想实现这个用例，首先顾客必须使用身份验证用例，输入用户名和密码登陆系统。收藏夹顾客身份验证<<include>>第18页/共42页5.3用例图元素在实际应用时，包含关系的例子还是很多的。在进行系统设计时，当有两个或两个以上的用例中都含有相同功能时，就可以考虑将这些相同的功能抽取出来，形成一个单独的用例，然后在用例之间建立包含关系。

当用例之间存在包含关系时，执行者每次调用基本用例时，都必须同时执行包含用例，这样才能实现执行者需要的功能。另外，执行者也可以独立的访问包含用例，不必通过基本用例，如上图所示。第19页/共42页5.3用例图元素

（3）扩展

扩展是指一个用例扩充了另一个用例的功能，但这个扩充功能不是必需的，扩展关系也是依赖关系的一种。扩展关系用一条连接二者带箭头的虚线表示，但在虚线的上面标注的是《extend》，箭头方向由扩展用例指向基本用例，如下图所示。<<extend>>

某个用例是一个完整的用例，它有自己独立的功能，但通过调用另一个用例对该用例的功能进行扩充，使该用例能够完成新的功能，这样两个用例之间就是扩展关系。

第20页/共42页5.3用例图元素

例如，在网络系统购物系统中，拥有一个商品结算用例，但系统中对不同的商品或顾客购买一定金额的商品都会给与不同额度的优惠，系统中还存在一个商品优惠用例。这样当顾客使用商品结算用例时，根据顾客购买的商品金额和具体商品，就有可能会调用商品优惠用例来扩展商品结算用例的功能，从而实现优惠结算的功能。

顾客商品结算商品优惠<<extend>>第21页/共42页5.3用例图元素

扩展关系和包含关系看上去很相似，但它们之间还是存在很大区别的。与包含用例不同的是，包含用例是一个完整的用例，它可以独立的存在，也可以单独被执行者所调用。但扩展用例并不是一个完整的用例，它只是由部分扩展功能组成的，它不能独立的存在，必须依赖于基本用例。

更重要的是扩展用例是不能够单独被执行者所调用的。也就是说上图中的扩展用例商品优惠用例不可被顾客这个执行者直接调用。

第22页/共42页5.3用例图元素

（4）泛化

用例间的泛化关系是指一个概念较为抽象的用例可以被一般化为一个或多个概念更为具体的用例。其中概念较为抽象的用例被称为父用例，概念更为具体的用例称为子用例。子用例是父用例的特殊形式，子用例从父用例处继承属性和行为，还可以添加、覆盖或改变继承的行为。泛化关系使用一条带一个三角箭头的实线表示，箭头方向子用例指向父用例，如下图所示。

第23页/共42页5.3用例图元素

如果系统中一个或多个用例是某个一般用例的一般化时，就需要使用用例的泛化关系。当系统中存在泛化关系时，如果父用例被使用，其任何子用例也可以被使用。例如，网络购物系统中包含一个商品结算用例，但在实际进行商品结算时，可以进一步分解成网上结算和汇款结算这两种结算功能，这种情况就可以使用泛化功能。其中父用例为商品结算用例，两个子用例分别为网上结算用例和汇款结算用例，这两个子用例都从父用例商品结算用例处继承了商品结算的功能，但根据自己不同的特点从而实现了两种不同方式的结算。第24页/共42页5.3用例图元素顾客商品结算汇款结算网上结算第25页/共42页5.3用例图元素5.3.5用例描述

为了进一步说明用例是如何完成功能的，就需要对用例进行更加详细的描述。用例描述主要用来说明执行者为了实现自己的目标与系统进行交互的过程。这个交互的过程由执行者开始，执行者向系统发出一个请求。系统响应执行者发出的请求并给出一个结果。执行者再根据这个结果，再次给出下一个请求，这样一直到执行者得到一个有价值的结果为止，整个用例交互过程结束。第26页/共42页5.3用例图元素在用例描述中，需要对用例的主要属性进行说明。这些属性主要包括：事件流前置条件后置条件特殊要求扩展点用例场景问题说明第27页/共42页5.3用例图元素

（1）事件流

事件流描述了在执行一个用例时，执行者与系统之间的一次交互过程。这个过程可以包括多个分支，也就是说执行者在执行这个过程时可以有多个路线。其中按照系统设计者的预期会成功的路线被称为基本流，剩下的其它路线被称为备选流。

基本流备选流事件流的循环与分支第28页/共42页5.3用例图元素

（2）前置条件

前置条件是指在用例启动前，执行者与系统应置于什么样的状态，这个状态应该是系统能够检测到的、可观测的，它用来描述在什么条件下可以开始执行一个事件流。这个条件是正确执行一个事件流的起点，一般用执行者或系统的状态来表示。例如，“ATM取款”用例的前置条件为：

执行“ATM自检”用例第29页/共42页5.3用例图元素

（3）后置条件

后置条件用来说明当用例结束时系统的状态，这个状态也应该是系统能够检测得到的、可观测的。在用例描述中增加用例后置条件，可以明确表明用例结束时系统的状态，避免使系统出现处于不确定状态的情况。一般在开始定义并划定用例的范围时，可以使用前置条件来定义用例的起点，使用后置条件定义用例完成的目标。前置条件和后置条件可以方便用例的验证和评审。第30页/共42页5.3用例图元素

（4）其他除了上面所说的主要属性外，用例描述中还包括一些其它的主要属性。如：用例场景、特殊要求、扩展点、问题说明等。其中用例场景包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。特殊要求是指在用例中涉及到的非功能性需求。扩展点用来描述该用例的扩展。问题说明中主要列出本用例在分析和描述过程中还存在哪些问题。

第31页/共42页5.5用例粒度

粒度的概念主要用来表示颗粒的大小。用例粒度表示的用例的大小。

在进行需求分析时，用户表述的功能目标可能有大有小，而且有些功能可能还会有重复或重叠，有的是商业目标，有的是要构建系统的目标。为了能够更好更准确的获取用例，在进行用例建模时需要考虑用例粒度的问题。

用例的粒度从大到小分成以下三个层次：概述级、用户目标级、子功能级。

第32页/共42页5.5用例粒度

（1）概述级

概述级用例用来描述商业目标，它可以包括多个用户目标级的用例。一般用于初期的需求讨论。也可以用做用户目标级用例的划分目录。例如用户可以通过ATM来完成取钱的工作。这就是一个概述级用例，其用例图如图所示。

用户ATM取钱第33页/共42页5.5用例粒度

（2）用户级目标级

用户目标级用例用来描述执行者或用户完成工作或使用系统的目的。这一类用例一般用来描述某个人在某个时间地点完成某项工作。

自由金额取款固定金额取款例如上面的例子，用户可以通过ATM来完成取钱的工作。该用例在用户目标级被描述成“固定金额取款”和“自由金额取款”两个用例。

第34页/共42页5.5用例粒度

（2）子功能级

子功能级用例是比用户目标级用例再低一级的用例，除非是为了重用或其它特殊要求，一般建议在获取用例时不要深入到这一层，否则容易出现可能取得的用例无穷无尽的现象。

在ATM取款系统中，固定金额取款用例和自由金额取款用例中都涉及到用户身份验证的功能，这个功能可以设计成一个子功能用例。

第35页/共42页5.6用例图应用

用例图是用来描述用户需求的，是表达用户需求的一种方式。系统的需求包括四个不同的层次：业务需求、用户需求、功能性需求、非功能性需求。业务需求说明了提供给用户的系统的最初利益，反映了用户对系统高层次的目标要求。用户需求主要描述了用户使用产品必须要完成的任务。功能性需求主要定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。非功能性需求主要是用户对系统良好运作提出的期望，包括了易用性、反应速度、容错性、健壮性等等。

第36页/共42页5.6用例图应用

用例图是系统建模的起点，可以使用用例图对将要开发系统的实际工作流程进行业务建模，从业务模型的基础上过度到系统建模的开始，可以通过用例图来搜集用户的需求，明确和系统相关的用户和其他系统，同时确定系统将会提供什么功能，以及各个功能间的关系。

用例图是用来描述系统的概要功能和行为，实现这些功能和行为的细节则由用例描述文档进行详细说明。进行系统用例图绘制主要需要经过以下几个步骤：用户需求、需求分析、需求描述。第37页/共42页5.6用例图应用5.6.1用户需求

用户需求指的是用户对系统的功能要求，