第5章-用例图

1、1,第5章 用例图,主讲：才智,2,第5章 用例图,5.1 概述 5.2 参与者（Actor） 5.3 用例（Use Case） 5.4 用例间的关系 5.5 用例图建模 5.6 用例图建模实例,3,5.1 概述,面向对象的系统分析主要特点是把问题域中的事物抽象为系统中的对象，最终建立一个用面向对象概念表达的系统模型。 抽象必须有一个目标，对分析而言，这个目标就是要满足用户需求。,4,5.1 概述,Jacobson提出：针对系统对外提供的每一项功能，详细地描述对这项功能的使用情况（use case，简称用例）。 以用例作为建立需求模型的基本单位，一个用例只针对一项系统功能，详细的描述系统边界以

2、外的参与者使用这项功能时与系统进行交互的情况，这可以比较确切地定义系统的功能需求。 用例的概念的提出弥补了以往各种面向对象分析方法在需求定义方面的不足，因此很快就被广泛采纳。,5,5.1 概述,UML的面向对象系统开发过程中在需求分析阶段的需求模型由用例建模完成，以用例为驱动，因此又称为用例模型。 用例模型是表达系统外部事物（参与者）与系统之间交互的可视化工具。 一个系统的用例模型由若干用例图组成，用例图的主要成分有参与者（Actor）、用例（Use Case）以及用例间的各种关系。 用例图可以包含注释和约束，还可以包含包，用于将模型中的元素组合成更大的模块。,6,5.1 概述,基本用例图,7

3、,5.2 参与者（Actor）,参与者（Actor）是在系统之外与系统进行交互的任何事物，可以是人或其他系统，他以某种方式参与了系统内用例的执行。 参与者的特征是其作为外部用户与系统发生交互，交互的方式可以是参与者向系统发送消息，也可以是从系统那里接收消息，或与系统之间交换消息。,8,5.2 参与者（Actor）,参与者代表一种角色，而不是具体的某个人。 在系统的实际运作中，多个不同的用户可能只对应于一个参与者；同时一个实际用户也可能对应系统的多个参与者。 例如，在“房地产开发经营管理系统”中，所有的购房者作为一个集合，在“房屋销售子系统”中作为购房合同的签约方出现，多个个体在系统中担任一个参

4、与者；同时，某个独立的购房者在“物业管理子系统”中又作为房屋的业主出现，同一个人在系统中担任了两类参与者。,9,5.2 参与者（Actor）,参与者的分类 人参与者和外部系统参与者 主参与者和副参与者 主动参与者和被动参与者,10,5.2 参与者（Actor）,人参与者和外部系统参与者 系统的各类用户是人参与者，用户通过与系统进行交互来操纵系统，完成各种工作。 参与者也可以是位于系统外部的其他软件系统或硬件设备，这类参与者统称为外部系统参与者。 例如，计算机网络系统的参与者可以包括操作员、系统管理员、数据库管理员以及普通用户等人参与者，另外也可以有外部系统参与者，如网络打印机。,11,5.2

5、参与者（Actor）,主参与者和副参与者 主参与者使用系统的主要功能，是使用系统较频繁、业务量较大的用户。 副参与者处理系统的辅助功能，它与用例进行交互的主要目的是为了给其他的参与者提供某些服务，如管理数据库、通信、系统备份以及其他管理等系统维护工作。 区分主参与者与副参与者不应该以参与者在使用系统时的权限为依据，一般情况下，应该以使用系统时的业务量为依据。,12,5.2 参与者（Actor）,主动参与者和被动参与者 主动参与者是系统的启动者，负责启动一个或多个用例，他们是为了完成某项事务而启动系统的，一个主动参与者可以请求某种服务或者触发一个事件。 被动参与者从不启动用例，只是参与一个或多个

6、用例，他们相应系统的请求，为系统提供某种服务。,13,5.2 参与者（Actor）,参与者的表示 在用例图中，参与者用一个简化的人体形状的符号表示，在符号的下方注明了参与者的名称。,14,5.2 参与者（Actor）,识别参与者 进行用例图建模，首先要做的就是确定系统的参与者。 在确定参与者之前，一定要明确一点：参与者对于系统而言，总是处于系统外部的，而不是系统的组成部分。,15,5.2 参与者（Actor）,识别参与者 谁将使用系统的主要功能（主参与者）？ 谁将借助于系统来完成日常工作？ 为了保证系统正常运行，谁将对系统进行维护管理（副参与者）？ 谁将完成系统数据的录入、导出及修改等工作（主

7、动参与者）？ 谁或什么系统对系统产生的结果感兴趣（被动参与者）？ 系统控制的硬件设备有哪些？ 系统需要与哪些其他外部系统进行交互？ 在预定的时间，是否有事件自动触发？ 系统从何处获取信息？,16,5.2 参与者（Actor）,参与者之间的关系 泛化关系：用一个三角箭头来表示，其中箭头所指向的角色为超类参与者，箭头尾端的角色为特殊化的参与者。,17,5.3 用例（Use Case）,用例（Use Case）是对参与者使用系统某项功能时所进行的交互过程的描述，过程中包括交互双方所执行的一系列动作。 用例描述了参与者与系统交互的完整过程。,18,5.3 用例（Use Case）,用例特征： 响应性。

8、一个用例不会自动执行，总是由参与者启动或由系统根据某些事件触发，参与者必须直接或间接地指示系统去执行用例。 回执性。用例执行完毕，向参与者提供可识别的返回值。 完整性。用例表示一个完整的功能，必须是一个完整的描述。,19,5.3 用例（Use Case）,用例的表示 在UML语言中，用例用一个椭圆来表示，并且每个用例必须有一个名字。 在用例命名时用例的名字一般用字符串来表示，可分为简单名和路径名。其中，路径名引入了包的概念，在用例名前加上该用例所属包的名字，两个名字之间用两个冒号分开。,20,5.3 用例（Use Case）,确定用例 确定用例最好的方法是从分析系统的参与者开始，对于已经确定的

9、参与者，通过考虑每个参与者是如何使用系统的，以及系统对事件的响应来识别用例。 使用这种策略进行具体分析的过程中，可能会发现新的参与者，这对完善整个系统的建模有很大的帮助作用。 用例建模的过程是一个迭代并逐步细化的过程。,21,5.3 用例（Use Case）,确定用例 参与者需要系统提供什么功能？即参与者需要系统“做什么”？ 参与者是否需要读取、产生、删除、修改或存储系统中的某种信息？ 当系统状态改变时，是否通知参与者？ 是否存在影响系统的外部事件？ 系统需要什么样的输入/输出信息？,22,5.3 用例（Use Case）,描述用例 用例图通过图形符号描述了参与者和系统之间的关系，但是它对于系

10、统行为的细节描述比较欠缺。 在一般情况下，需要以书面文档的形式对于用例进行描述，每个用例应具有一个用例描述。,23,5.3 用例（Use Case）,描述用例 1.名称：能够明确的表明用户的意图或用例的用途，切记不要使用诸如UseCase1、UseCase2之类的名称，会使用例图的读者在阅读时无法读懂用例图所描述的内容。 2.标识符可选：用来唯一标识一个用例，如“UC0001”，这样就可以在项目的其他元素中用它来引用这个用例。 3.参与者可选：与此用例相关的参与者列表。在没有用例图时，它有助于增加对改用里的理解。 4.状态可选：用来指示该用例的状态，通常可包括进行中、等待审查、通过审查或未通过

11、审查等状态。,24,5.3 用例（Use Case）,描述用例 5.频率：记录参与者使用该用例的频率。 6.前置条件：前置条件以一个条件列表的形式进行记录，用来描述执行用例之前系统所必须满足的条件。这些条件必须在使用用例之前得到满足。前置条件在使用之前，已经由用例进行过测试。如果条件不满足，则用例不会被执行。 7.后置条件：后置条件将在用例成功完成以后得到满足，它提供了系统的部分描述。即在前置条件满足后，用例做了什么？以及用例结束时，系统处于什么状态？,25,5.3 用例（Use Case）,描述用例 8.假设可选：假设描述的是系统在使用用例之前必须满足的状态，这些条件并没有经过用例的检测，用

12、例只是假设它们为真。 9.基本操作流程：参与者在用例中所遵循的主要逻辑路径。操作流程描述了用户和执行用例之间交互的每一步。 10.可选操作流程：包括用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径。 11.修改历史记录可选：主要记录的是关于用例的修改时间、修改原因和修改人的详细信息。,26,借阅图书用例的描述,27,5.4 用例间的关系,泛化关系 包含关系 扩展关系,28,5.4 用例间的关系,泛化关系 泛化关系表示两个用例之间存在用例泛化，其中一个用例称为父用例，其派生的用例称为子用例，子用例是父用例的特殊化形式。子用例除了具有父用例的特性外，还可以有自己

13、另外的特性。,29,5.4 用例间的关系,包含关系 一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。 包含关系是一种依赖关系。 包含关系把几个公共步骤抽取出来形成一个单独的被包含用例，包含有公共步骤的用例称为基本用例。,30,5.4 用例间的关系,包含关系 包含关系用虚线箭头加注字样来表示 。,31,5.4 用例间的关系,扩展关系 扩展关系也是一种依赖关系。 它指定了一个用例可以增强另一个用例的功能，通过项基本用例添加动作来扩展该用例。 一个用例被定义为基本用例的增量扩展，这称作扩展关系。 在扩展关系中，基本用例可以是独立的。在一定条件下

14、，基本用例的动作可由另外一个用例扩展而来。基本用例提供了若干“扩展点”，扩展用例只能在这些扩展点上增加一个或多个新的动作。也就是说，扩展用例只能发生在基本用例序列中的某个特定的点上。,32,5.4 用例间的关系,扩展关系,33,5.5 用例图建模,在UML中，用例图建模的步骤主要包括： 识别和确定参与者。 识别和确定用例。 描述用例。 定义用例之间的关系。 建立用例图，构造用例模型。 审核用例模型。,34,5.5 用例图建模,在所开发系统较为庞大、比较复杂的情况下，通常可将系统分解为若干子系统，子系统还可以拥有自己的下属子系统，在构造用例模型是也应该采用层次化用例图的方法，每一个子系统都需要相

15、应的用例图进行描述，用例图之间也具有了层次结构，高层系统的用例可以分解为若干下属系统的用例，自上而下，逐层细化，可以更为全面、完整的描述用例模型。 对于一个功能需求相对简单的系统，用例图较少，可以不用对用例图进行分层细化。,35,5.6 用例图建模实例,1.识别和确定系统参与者 图书管理系统的基本功能： 系统可供图书管理员处理借阅者的借书及归还图书工作； 系统应允许图书管理员查询借阅者的借阅信息； 系统需要控制借阅者的借书期限，对于超期未还的情况，系统应生成超期罚款信息，以便在借阅者归还图书时进行相应的超期处理； 系统的管理和维护工作应由系统管理员负责，系统管理员可以进行借阅者信息、图书信息、

16、借阅信息、图书管理员信息等内容的管理工作。,36,5.6 用例图建模实例,1.识别和确定系统参与者 通过需求分析，应当主要到以下几点： 借阅者不参与系统的交互，他只是向图书管理员发出借书、还书和续借的请求，其余工作有图书管理员完成。因此，借阅者不属于该系统的参与者。 在系统中，直接完成与系统交互以实现系统功能的是图书管理员，他完成图书的借阅、归还和续借工作，并且可以进行借阅信息的查询。 一个系统要正常运行，必要的维护及管理是必不可少的。因此，在这个系统中，一定要有系统管理员来完成系统的日常管理及维护工作。,37,5.6 用例图建模实例,1.识别和确定系统参与者 图书管理员Librarian 图

17、书管理员代理学生完成借书、还书工作，并可以查询其借阅信息。 系统管理员Administrator 系统管理员可以添加、修改、删除为借阅者建立的借阅者账户；可以添加、修改、删除图书信息；可以添加、修改、删除图书书目信息；还可以添加、修改、删除管理员信息，实现对访问系统权限的管理。,38,5.6 用例图建模实例,2.识别和确定系统用例 图书管理员所涉及到的系统用例包括： 借阅图书 归还图书 查看借阅信息 系统管理员所涉及到的系统用例包括： 管理借阅者信息 管理图书信息 查看借阅信息 管理图书管理员信息,39,与图书管理员相关的系统用例： Login用例 完成图书管理员的登录功能，验证图书管理员的身

18、份，以保证系统的安全。 ModifyPassword用例 当图书管理员成功登录系统后，调用该用例可以完成对用户密码的修改。 BorrowBook用例 完成书籍借阅处理。 ReturnBook用例 完成图书归还处理。 ProcessOverTime用例 该用例检查每个借阅者是否有超期的借阅信息，如有超期信息，进行超期处理。 NotifyOverTime用例 如果某借阅者有超期信息，该用例用以通知图书管理员给借阅者有图书超期未还，执行完毕该用例后，继续执行ProcessOverTime用例进行超期处理。 QueryLoanInfo用例 查找某个借阅者信息。 DisplayLoanInfo用例 用于显示某借阅者的所有借阅信息。,40,与系统管理员相关的系统用例： Login用例 该用例完成对系统管理员身份的验证，以保证系统的安全。 MaintenanceBorrowerInfo用例 用于完成对借阅者信息的管理及维护，包括添加借阅者（AddBorrower）、修改借阅者信息（UpdateBorrow）、删除借阅者（DeleteBorrower）。 MaintenanceManagerInfo用例 用于完成对管理员信息的管理及维护，包括添加管理员（Add