第7章-2 用例图

扩展（extend） （是一种依赖关系，加了版型<<extend>>）
在不改变原始用例的情况下有条件地扩展已有
用例的行为。扩展关系用来说明可选的、只在 特定条件下运行的行为，具有扩展关系的用例 基于参与者的选择，可以运行几个不同的流。 一个用例（在某些扩展点extension point上） 扩展另一个用例的功能，构成新用例；箭头方 向由扩展用例指向被扩展用例（即基本用例）；
7.3 用例图
用例建模是UML建模的一部分，它也是UML 里最基础的部分； 用例建模的最主要功能就是用来表达系统的 功能性需求或行为； 用例建模可分为用例图和用例描述；

用例图是由软件需求分析到最终实现的第一 步，它描述人们如何使用一个系统，是外部 参与者所能观察到的系统功能的模型图，该 图呈现了一些参与者和一些用例，以及它们 之间的关系，主要用于对系统、子系统或类 的功能行为进行建模，用画图的方法来完成 ； 用例描述用来详细描述用例图中每个用例， 用文本文档来完成。
1、这件事是相对独立的； 2、这件事的执行结果对参与者来说是可观测的和有意义的 3、这件事必须由一个参与者发起 ；不存在没有参与者的 用例，用例不应该自动启动，也不应该主动启动另一个 用例。用例总是由一个参与者发起，并且满足特征二； 4、这件事必然是以动宾短语形式出现的 。

怎样识别用例
参与者希望系统执行什么任务？
7.3.3 用例描述－－事件流
用事件流更详细地描述用例的功能 主要组成

用例名称
简要说明 前提条件
后置条件
主事件流/其他事件流

用例名称

应该与用例图相符合，并写上其相应的编号
每个用例应有一个相关说明，描述该用例的作用，应注意语言简 要，使用用户能够阅读的自然语言 是执行用例之前必修满足的条件，例如前提条件可能是另外一个 用例已经执行、或者用户具有运行当前用例的权限。 用例结束后执行的动作，比如一个用例结束后必修运行另外一个 用例。并不是每个用例都有后置条件。
（3）系统管理员负责系统的管理维护工作，
维护工作包括图书的添加、删除和修改，书目 的添加和删除，借阅者的添加、删除和修改， 并且系统管理员能够查询借阅者、图书和图书 管理员的信息。 （4）查询图书可以通过图书的名称或图书的 ISBN/ISSN号进行查找。





2. 用例

Use Case
系统、子系统或类与外部参与者（actor）交互
的动作序列的说明，包括各种序列及出错序列。 简单理解为用例就是系统的功能。 用例分析可以认为是对系统功能的分解。 软件开发过程是用例驱动的。
什么是用例？
用例是一种获得系统需求的方法学
把用例解释为某个参与者(actor)要做的一件事，这样 的一件事有以下几个特征：




1．借阅者请求服务的用例 （1）登录系统； （2）查询自己的借阅信息； （3）查询书籍信息； （4）预订书籍； （5）借阅书籍； （6）归还书籍； （7）交纳罚款 2．图书馆工作人员处理借书、还书等的用例 （1）处理书籍借阅； （2）处理书籍归还； （3）删除预订信息。 3．系统管理员进行系统维护的用例 （1）查询借阅者信息； （2）查询书籍信息； （3）增加图书标题； （4）删除或编辑图书标题； （5）增加书籍； （6）删除书籍； （7）添加借阅者账户； （8）删除或更新借阅者账户。
个参与者关联，有一个参与者来参与），除包 含和扩展用例 无论用例和参与者是否存在双向数据交流（无 论是参与者提供信息给系统，还是从系统获取 信息），关联总是由参与者指向用例，只用单 向箭头。

包含（include） （是一种依赖关系，加了版型<<include>>）
两个以上用例有共同功能，可分解到单独用例，
基本用例 扩展点 具有条件 扩展用例 执行 返回
客户 <<extend>>
订购商品 <<extend>> <<extend>>
老顾客打折
季度销售价格
库存商品过多销售
扩展和包含的区别

泛化（generalization）
一个用例和其几种情形的用例间构成泛化； 往往将父用例用抽象用例（abstract）表示
扩展的执行：只有当控制到达插入位置时条件
为真，才会发生扩展行为。 扩展用例依赖于被扩展用例（基本用例），只 是部分片段组成，不是完整的独立用例，无法 单独执行； 扩展用例不一定每次都被执行和调用。（吃饭 前也可以不洗手），而被包含用例每次必须执 行。 肯定没有参与者指向扩展用例，因为扩展用例 依赖基本用例。
形成包含依赖； 箭头方向由基本用例指向被包含用例； 执行基本用例时，每次都必须调用被包含的用 例（吃饭前洗手）； 被包含用例也可以单独执行
<<include>>
基本用例1
<<include>>
包含用例1
<<include>>
角色 基本用例2
<<include>>
包含用例2
一个基本用例可以有多个包含用例。 一个包含用例可以包含在若干基本用例中。
举例：图书管理系统

图书管理系统的功能性需求包括以下内容： （1）图书管理系统能够为一定数量的借阅者提 供服务。每个借阅者能够拥有唯一标识其存在 的编号。图书馆向每一个借阅者发放图书证， 图书证中包含每一个借阅者的编号和个人信息 。系统通过一个单独的程序为借阅者提供服务 ，不需要管理人员的干预，这些服务包括提供 查询图书信息、查询个人信息服务和预定图书 服务等。
参与者在系统中访问哪些信息？（创建、存储
、修改、删除等） 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉参与者？ 如何维护系统？

怎样确定用例的粒度？（用例规模的大小）
用例的粒度可大可小，一般一个系统控制在20
个左右，但没有严格规定 用例是系统级的、抽象的描述，不是细化的 （考虑的是“做什么what”，而不是“怎样做 how”） 对复杂的系统可以划分为若干子系统处理
简要说明


前提条件


后置条件


主事件流和其他事件流
用例的具体细节在主事件流和其他事件流中描述。事件
流描述执行用例功能的具体步骤。事件流关注系统做什 么，而不是怎么做，它是从用户角度写成的。 主事件流和其他事件流包括如下方面： 用例如何开始 用例的各种途径 用例的主流程 用例主事件流或其他事件流的变形 错误流

7.3.1 组成
用例（use case）：代表系统提供的服务 角色（参与者，actor）：代表系统的用户 关系（relationship）：泛化，包含，扩展 还可以有包、注解等

1. 参与者
参与者(actor)是指系统以外的、需要使用系统或与 系统交互的事物, 包括: 人、设备、外部系统等. 其它 译名有: 活动者、执行者、行动者、角色等； 参与者是系统外部的一个实体，参与者只可能存 在于边界之外，边界之内的所有人和事物都不是参与 者。
脚本
其它译名: 情景、场景、情节、剧本. 脚本就是用例的一次完整的、具体的执行过程。用例 与脚本的关系，如同类与对象的关系。 每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
例：在“订货”用例中包括几个相关脚本： • 订货顺利进行的脚本; • 相关货源不足时的脚本; • 购货者的信用卡被拒绝时的脚本; • ……

用例图的作用

用例图展示了用例之间以及用例与参与者之间是怎 样相互联系的。用例图对系统、子系统或类的行为 进行了可视化，使用户能够理解如何使用这些元素 ，并使开发者能够实现这些元素。
用例图主要用来描述用户的功能需求。UML侧重 从最终用户的角度来理解软件系统的需求，强调谁 在使用系统、系统可以完成哪些功能。用例分析技 术已经是一种公认有效的用户需求获取、分析和描 述技术
情况四：如果扩大系统边界，让呼叫中心成为 机票预定系统的一个子系统，并且假设机票 购买者将可以自主选择是通过人工座席还是 自动语音登录网站预订机票，那么谁是参与 者？
参与者间的关系
由于Actor实际上是一个类, 因此它们之间可以 存在一定的关系,参与者之间的关系一般表现为特殊 /一般化关系，即，泛化关系。
（即，父用例往往是虚的，真正用的是子用 例。）

参与者之间的泛化关系：在用例图中，使用泛 化关系来描述多个参与者之间的公共行为。
扩展与泛化的区别
思考：
修改用户信息
查询用户
7.3.2 用例图

显示系统和外部实体（Actor）交互的图
此图中， 客户所有 的业务都 通过职员 完成，所 以是依赖 关系。
（2）当借阅者需要借阅书籍、归还书籍时需
要通过图书管理员进行，也就是说借阅者不直 接与系统交互，而是图书管理员充当借阅者的 代理与系统交互。当借阅者借阅的图书数量超 过限制时，不允许借阅者再进行借阅。当借阅 者借阅的图书超过一定的期限时，需要对其进 行处罚。借阅图书时需要图书证作为凭据，归 还时不需要。
UML中用例用椭圆表示, 使用动宾结构或主谓结构 命名.
例: 字处理程序中, “置正文为黑 体”和”创建索引”都可以是用 例.
3. 关系

关联（accociation） 包含（include）
扩展（extend） 泛化（generalization）




关联（accociation）
每个用例都有参与者启动（每个用例必须和一

包含（include）
一个用例功能过多，可分解成小用例，构成包含
依赖 被包含用例也可以单独执行，有Actor 指向它们； 被包含用例不能单独执行，没有Actor直接指向 它们；
包含关系特点： 1）包含用例是基本用例的一部分，执行基 本用例必须执行其包含用例； 2）包含用例可以独立存在，单独执行。

用例：登记成绩 1．目标：本用例允许教师提交上学期完成的一门或多门课程的学生成绩。 2．事件流 基本流程：当教师希望提交上学期完成的一门或多门课程的学生成绩时，本 用例开始执行。 (1) 系统显示教师上学期所教的课程列表； (2)教师选择所教课程； (3)系统检索出已注册此课程的学生列表，显示每个学生及其以前所给的成 绩； (4)对于列表中的每个学生，教师输入百分制成绩，系统记录所提供课程的 学生成绩。如果教师希望跳过某个特定的学生，其相应的成绩可以为空，以 后在进行填写。教师可以修改学生的成绩。 可选流程：在主流程中，如果教师在上学期没有教课，系统将显示错误信息 ，教师接受此信息，用例结束。 3．特殊需求：无。 4．前提条件 用例开始之前，教师必须在系统登录成功。 5. 后置条件 如果用例执行成功，所提供课程的学生成绩被更新，否则，系统状态不变。

主事件流

其他事件流
7.3.4 用例分析

步骤
确定系统的边界，找出系统外部的参与者和外部
系统； 确定每个参与者所希望的系统行为，命名为用例； 把一些公共的系统行为分解为新的用例，供其他 用例引用，构成用例间的包含关系； 把一些变更的行为分解为扩展用例； 编制用例的脚本，对用例进行描述； 绘制用例图； 把特殊情况的用例画成单独的子用例图。
查找参与者时请注意，参与者一定是 直接并且主动的向系统发出动作并获得反 馈的，否则就不是参与者。下面对机票预 订系统进行分情况讨论： 情况一：机票购买者通过登录网站购买机票 ，那么谁是参与者？
情况二：假如机票购买者通过呼叫中心，由 人工座席操作订票系统购买机票，那么谁 是参与者？
情况三：如果机票购买者通过呼叫中心的自 动语音预定机票而不是通过人工座席，那 么谁是参与者？
百度文库
参与者的例子
UML中的Actor实际上是一个版型化的类, 可以有三种表示形式
Icon形式
Label形式
Decoration形式

怎样识别参与者
谁向系统提供信息？ 谁从系统获取（使用）信息？
谁操作这个系统？
谁维护这个系统？ 系统要使用哪些外部资源？（系统启动打印机、
扫描仪） 系统是否和已经存在的系统交互？（跨行转账 的外部银行系统、时间到了定时启动系统某功 能）