UML建模实例教程（第3版）课件 第5章 需求建模

第5章需求建模15.1用例模型概述5.2用例图组成5.3识别和描述用例5.4用例间的关系2本章将向读者详细介绍应用用例模型进行软件系统需求建模的基本内容。需求建模主要包括：用例模型概述、用例图的组成、识别和描述用例、识别用例之间的关系、绘制用例图等。本章的学习要点包括：用例图的组成（参与者和用例）；识别和描述用例；用例间的关系（泛化、关联和依赖）；绘制用例图。35.1用例模型概述45.1用例模型概述5任务1了解用例模型的基本功能和基本组成。任务描述

65.1用例模型概述

1.用例模型的功能用例模型是把应满足用户需求的基本功能（集）聚合起来表示的强大工具。对于正在构造的新系统，用例描述该系统应该做什么；对于已构造完毕的系统，用例则反映了系统能够完成什么样的功能。构建用例模型是通过系统开发者与系统的客户（或最终使用者）共同协商完成的，他们要反复讨论需求的规格说明，达成共识，明确系统的基本功能，为后阶段的工作打下基础。75.1用例模型概述

2.用例模型的基本组成用例模型的基本组成部件是用例、参与者和系统。

用例用于描述系统的功能，也就是从外部用户的角度观察系统应具备哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述。一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能（集）。

参与者是与系统进行交互的外部实体，它可以是系统用户，也可以是其他系统或硬件设备，总之，凡是需要与系统交互的任何东西都可以称做参与者。

系统仿佛是实现各种用例的“黑盒子”，我们只关心该系统实现了哪些功能，并不关心内部的具体实现细节（如系统是如何做的，用例是如何实现的）。85.1用例模型概述

3.引入用例的目的引入用例的主要目的包括以下几点：（1）确定系统应具备哪些功能，这些功能是否满足系统的需求（开发者与用户协商达成共识的东西）。（2）为系统的功能提供清晰一致的描述，以便为后续的开发工作打下良好的交流基础，方便开发人员传递需求的功能。（3）为系统验证工作打下基础。通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致，保证系统的实用性。5.2用例图组成95.2用例图组成10任务2确定WebShop电子商城系统中的参与者、系统边界。任务描述

11在UML中，用例模型（也就是用例视图）是用例图描述的。用例模型可以由若干个用例图组成。用例图中包含系统、参与者和用例等三种模型元素。绘制用例图时，既要画出这三种模型元素，同时还要画出元素之间的各种关系（泛化、关联、依赖）。5.2用例图组成WebShop用户管理用例图12

5.2.1参与者参与者（Actor）是与系统交互的人或事。所谓“与系统交互”指的是参与者向系统发送消息，从系统中接收消息，或是在系统中交换信息。

UML中用一个小人形图形表示角色类，小人的下方书写角色名字。5.2用例图组成购物用户参与者13

5.2.1参与者——参与者的类型5.2用例图组成从参与者的具体表现形式来看，参与者有三种类型：（1）系统用户，即系统的用户（真实的人），是最常见的参与者。（2）其他系统。（3）一些可以运行的进程。14

5.2.1参与者——参与者的确定5.2用例图组成怎样确定系统的参与者呢？开发人员可以通过回答以下的问题来确定系统的参与者：（1）使用系统主要功能的人是谁（主要角色）？（2）需要借助于系统完成日常工作的人是谁？（3）谁来维护和管理系统（次要角色），保证系统正常工作？（4）系统控制的硬件设备有哪些？（5）系统需要与哪些其他系统交互？（6）对系统产生的结果感兴趣的人或事是哪些？WebShop电子商城参与者15参与者对于系统而言总是外部的，它们可以处于人的控制之外；参与者可以直接或间接地同系统交互，或使用系统提供的服务以完成某件事务；参与者表示人或事物与系统发生交互时所扮演的角色，而不是特定的人或者特定的事物；一个人或事物在与系统发生交互时，可以扮演多个角色；每一个参与者需要一个具有业务一样的名字，并且必须有简短的描述（从业务角度描述参与者是什么）；参与者可以具有属性和事件，但使用不能太频繁。16

5.2.2系统5.2用例图组成系统是用例模型的一个组成部分，代表的是一部机器或一个商务活动等，而并不是真正实现的软件系统。

系统的边界用来说明构建的用例模型的应用范围。

用例图中的系统用一个长方框表示，系统的名字写在方框上方或方框里面，方框内部还可以包含该系统中的用符号表示的用例。系统17

5.2.3用例——什么是用例5.2用例图组成用例代表一个系统或系统的一部分行为，是对一组动作序列的描述，系统执行该动作序列来为参与者产生一个可观察的结果值。用例代表的是一个完整的功能。UML中的用例是动作步骤的集合。动作是系统的一次执行（能够给某个参与者输出结果值）。用例应支持多种可能发生的动作。

UML中的用例用椭圆形表示，用例的名字写在椭圆的内部或下方。用例示例18

5.2.3用例——用例的特征5.2用例图组成用例具有以下的特征：（1）用例总是由参与者初始化。用例所代表的功能必须由参与者激活，而后才能执行。（2）用例为参与者提供值。用例必须为参与者提供实在的值，虽然这个值并不总是重要的，但是应能被参与者识别。（3）用例具有完全性。用例是一个完整的描述。不管用例内部的小用例是如何通信工作的，只有最终产生了返回给参与者的结果值，才能说明用例执行完毕。19用例表示的也是一个类（如搜索图书），而不是某个具体的实例（搜索名称为“Java程序设计”的图书）。用例描述了它代表的功能的各个方面，也就是包含了用例执行期间可能发生的种种情况。20（1）小组讨论用例模型的主要功能有哪些。（2）根据已往的软件开发经验，讨论使用用例模型来描述需求与使用纯文字的方式来描述需求有什么不同。（3）结合实例说明用例模型由哪几部分组成。

（4）根据典型图书管理系统的需求，确定该系统中的参与者，并说明确定参与者的根据。（5）确定图书管理系统的系统边界。

1.操作要求

2.操作提示

（1）通过学习小组讨论和上网查询资料形式完成。（2）使用手绘形式绘制出图书管理系统的参与者和系统边界。5.3识别和描述用例21225.3识别和描述用例任务3确定WebShop电子商城中的用例，绘制WebShop电子商城的用例图，并对用例进行描述。任务描述

235.3识别和描述用例

5.3.1识别用例——针对参与者（1）某个参与者要求系统为其提供什么功能？该参与者需要做哪些工作？（2）参与者需要阅读、创建、销毁、更新或存储系统中的某些信息吗？（3）系统中的事件一定要告知参与者吗？参与者需要告诉系统一些什么吗？（4）系统新功能的识别，参与者的日常工作被简化或效率提高了吗？245.3识别和描述用例

5.3.1识别用例——针对系统（1）系统需要什么样的输入和输出？输入来自哪里？输出到哪里去？（2）该系统的当前状况还存在哪些问题？（3）系统的改进方向？255.3识别和描述用例

5.3.1识别用例【任务3-1】确定WebShop电子商城中的用例。265.3识别和描述用例

5.3.2绘制WebShop电子商城用例图【任务3-2】绘制WebShop电子商城中的用例图。详见教学视频《绘制图书管理系统用例图》275.3识别和描述用例

5.3.2绘制WebShop电子商城用例图按钮按钮名称功能Selection选择工具Note添加注释Anchor将图中的元素与注释相连Label添加文本标签Box绘制盒子，将某些元素框在一起Actor绘制参与者UseCase绘制用例Association添加双向关联关系DirectionalAssociation添加单向关联关系Dependency添加依赖关系Generalization添加泛化关系用例图绘图工具栏按钮285.3识别和描述用例

5.3.3通过文件夹对用例进行合理规划Umbrello的用例视图可以通过文件夹“Folder”来管理，把各种各样的模型元素通过内在的语义连在一起成为一个整体。Umbrello中的文件夹通常用于对模型进行组织管理，它是一个逻辑元素，并不会出现在用例图中。【任务3-3】通过文件夹对WebShop电子商城中的用例进行规划。295.3识别和描述用例

5.3.4WebShop电子商城用例图（不含关系）系统的参与者购物用户管理相关的用例图305.3识别和描述用例

5.3.4WebShop电子商城用例图（不含关系）前台购物相关的用例图后台管理相关的用例图315.3识别和描述用例

5.3.4WebShop电子商城用例图（不含关系）管理购物用户相关的用例图325.3识别和描述用例

5.3.5用例描述用例的描述应包括以下几个方面：（1）用例的目标。（2）用例是怎样被启动的。（3）参与者和用例之间的消息流。（4）用例的多种执行方案。（5）用例怎样才算完成并把值传给了参与者。用例编号用例名称用例描述参与者前置条件后置条件基本路径1．….XXXX2．….XXXX扩展点 2a.….XXXX 2a1.….XXXX变异点补充说明用例描述的模板335.3识别和描述用例

5.3.5用例描述用例编号：001用例名：购物用户登录用例描述：购物用户根据所注册的用户名和密码，登录到WebShop电子商城系统。参与者：购物用户前置条件：电子商城正常运行时间。后置条件：如果购物用户登录成功，则该购物用户可搜索商品并购买商品；如果购物用户登录未成功，则该用户不能进行商品的购买。基本路径1．购物用户进入WebShop电子商城系统；2．购物用户输入用户名和密码；

3．购物用户提交输入的信息；4．系统对购物用户的账号和密码进行有效性检查；5．系统记录并显示当前登录用户；6．购物用户搜索商品并购买商品；7．系统允许购物用户的购买操作。扩展点 4a．购物用户的账号错误 4a1．系统弹出账号错误或账号已关闭警告信息； 4a2．购物用户离开或重新输入账号。 4b．购物用户的密码错误 4b1．系统弹出密码错误警告信息； 4b2．购物用户离开或重新输入密码。变异点

无补充说明34在用例描述中不要包含GUI设计，因为用例是针对需求的，而界面设计是“设计”，不要把设计的东西放进需求中；用例描述的目的是对用例的具体完成情况进行详细说明；用例通常描述参与者与系统的交互，如购物用户怎样，系统怎样等。35（1）确定图书管理系统的用例。（2）绘制图书管理系统的用例图。（3）对图书管理系统的用例进行描述。

1.操作要求

2.操作提示

（1）通过学习小组讨论和上网查询资料形式完成。（2）使用Umbrello2.32进行图形的绘制。（3）建议通过包图对图书管理系统中的用例进行逻辑分类。5.4用例间的关系365.4用例间的关系37任务4识别WebShop电子商城中用例间的关系，并绘制其关系图。任务描述

38用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即客户希望系统具备的完成一定功能的动作。通俗地理解，用例就是软件的功能模块，所以用例图是系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系。用例图中的用例之间和参与者之间也是具有一定的联系的。用例是从系统外部可见的行为，是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出泛化（Generalization）、关联（Asscociation）和依赖（Dependency）几种关系。用例间关系的共性就是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。5.4用例间的关系395.4用例间的关系

5.4.1泛化关系——用例泛化关系用例泛化关系（Generalization）是指一种从子用例到父用例的关系，它指定了子用例如何特化父用例的所有行为和特征。

Umbrello使用“”表示泛化关系。箭尾方向为子用例（子参与者），箭头方向为父用例（父参与者）。用例间的泛化关系详见教学视频《绘制泛化关系》405.4用例间的关系

5.4.1泛化关系——参与者泛化关系跟用例一样，参与者和参与者之间也存在着泛化关系

右图所示的参与者的包中包含了五个参与者。其中用户被购物用户和后台管理员所特化，后台管理员进一步由普通管理员和系统管理员所特化。参与者间的泛化关系415.4用例间的关系

5.4.2关联关系

关联关系（Association）是指表示参与者与用例之间的通信，任何一方都可发送或接受消息。关联关系包括普通关联关系（Association）和定向关联关系（DirectionalAssociation）。前者表示参与者与用例之间的通信，任何一方都可发送或接受消息，后者表示只有一方表示可以发送消息，另一方则接受消息。Umbrello使用“”表示普通关联关系，使用“”表示定向关联关系，箭尾方向为发送消息方，箭头方向为接受消息方，如图5-29所示。参与者与用例之间的关联关系详见教学视频《绘制关联关系》425.4用例间的关系

5.4.3依赖关系依赖关系（Dependency）是指一个用例会使用到另一个用例的关系。Umbrello使用“”表示依赖关系，箭尾方向为使用者用例，箭头方向为提供者用例。相比RationalRose等UML建模工具，Umbrello简化了用例图中的关系，不再区分扩展（extend）和包含（include）关系，统一使用依赖关系表示。依赖关系详见教学视频《绘制依赖关系》435.4用例间的关系

5.4.4WebShop电子商城用例图（含关系）参与者关系购物用户管理用例之间的关系详见教学视频《绘制图书管理系统用例间的关系》445.4用例间的关系

5.4.4WebShop电子商城用例图（含关系）前台购物用例之间的关系后