用例和用例图

例监视周边。由于安全主管与经理，安全
主管与保安之间泛化关系的存在，意味着
安全主管可以担任经理和保安的角色，就
能够参与经理和保安参与的用例。这样，
安全主管就可以参与全部4个用例。但经理
或者保安却不能担任安全主管的角色，也
就不能参与用例批准安全证书。
实例2 用例之间扩展和包含关系
• 用例的上下文是：短途旅行但汽车的油不足以应付全部路 程。那么为汽车加油的动作在旅行的每个场景(事件流)中 都会出现，不加油就不会完成旅行。吃饭则可以由司机决 定是否进行，不吃饭不会影响旅行的完成。
– 被包含用例也可以单独执行；
4.2.2 包含关系
• 包含关系示例
图书管理员
删除图书 修改图书信息
<<include>> <<include>>
查询图书
4.2.2 包含关系
• 包含（include）
– 一个用例功能过多，可分解成小用例，构成包含依赖
– 本例中，被包含用例不能单独执行，没有Actor直接指向 它们
4.1.1 用例
• 怎样识别用例 – 参与者需要从系统中获得什么功能？参与者需要做什 么？ – 参与者读取、产生、删除、修改或存储系统的哪些信 息？ – 需要将系统的哪个事件告诉参与者？ – 需要将外界的哪些信息提供给系统？（输入、输出信 息） – 采用什么实现方法满足特殊要求？
图书管理系统的用例图
在图书管理系统中，“图书管理员”和“读者”为 系统的执行者。“图书管理员”负责使用系统的主 要功能，“读者”从系统中获取所需的信息。
4.1.2 参与者
• 理解
– Actor不是指人，而是指代表某一种特定功能 的角色，因此同一个人可能对应很多个Actor。 Actor也可以指外部系统和设备。
– 如果一个活动者的操作是由另外一个活动者代 理完成的，可以建立该活动者到另外活动者的 依赖（或关联）关系。
4.3.1 用例图中的事物
事物名称 参与者(Actor) 用例(Use Case)
解释
在系统外部与系统直接交互的人或事物(如另一 个计算
机系统或一些可运行的进程)。我们需要注意的 是：
1.参与者是角色而不是具体的人，它代表了参与 者在与系统打交道的过程中所扮演的角色。所 以在系统的实际运作中，一个实际用户可能对 应系统的多个参与者。不同的用户也可以只对 应于一个参与者，从而代表同一参与者的不同 实例。
（即，父用例往往是虚的，真正用的是子用 例。）
4.2.4 泛化关系
• 泛化关系指的是一般与特殊的关系。当多个用例共同拥有 一种类似的结构和行为的时候，可以将它们的共性抽象成 为父用例，其它的用例作为泛化关系中的子用例。在用例 的泛化关系中，子用例是父用例的一种特殊形式，子用例 继承了父用例所有的结构、行为和关系。
• 例如，张明是图书馆的管理员，他参与图书管理系统的交互， 这时他既可以作为管理员这个角色参与管理，也可以作为借 书者向图书馆借书，在这里张明扮演了两个角色，是两个不 同的参与者，即管理员和借阅者。
• 因此，在“图书管理系统”中“借阅者”和“系统管理员” 都是参与者。
4.1.2 参与者
• Actor
第4章 用例
4.1 用例图的组成
• 用例（use case） • 参与者（活动者，角色，actor） • 关系（relationship）
• 还可以有包、注解等
4.1.1 用例
• Use Case – 系统、子系统或类与外部参与者（actor）交互的动作 序列的说明，包括各种序列及出错序列。 – 简单理解为用例就是系统的功能。 – 用例分析可以认为是对系统功能的分解。
2.参与者作为外部用户(而不是内部)与系统发生 交互作用，是它的主要特征。
3.在后面的顺序图等中出现的“参与者”，与此 概念相同，但具体指代的含义，视具体情况而 定。
系统外部可见的一个系统功能单元。系统的功能 由系统单元所提供，并通过一系列系统单元与一 个或多个参与者之间交换的消息所表达 。创建 新用例，确认候选用例和划分用例范围的优秀法 则----“WAVE”测试(见附录)
置正文的字体为宋体
借
书
还
书
图4.5 用例
4.1.1 用例
• 怎样确定用例的粒度？（用例规模的大小）
– 用例的粒度可大可小，一般一个系统控制在20 个左右，但没有严格规定
– 用例是系统级的、抽象的描述，不是细化的 （考虑的是“做什么what”，而不是“怎样做 how”）
– 对复杂的系统可以划分为若干子系统处理
• 用例是代表系统中各个项目相关人员之间根据系统的行为 所达成的契约。用例描述了在不同条件下，针对某一项目 相关人员的请求，系统对其作出的响应。也就是说用例指 的是对一组动作的描述，系统通过执行这些动作将对用例 的参与者产生可以看到的结果。用来描述参与者可以感受 到的系统服务或功能。
4.1.1 用例
借阅者
还书
<<include>> <<extend>>
查询图书 交罚款
4.2.3 扩展关系
• 扩展（extend） （是一种依赖关系，加了版型<<extend>>）
– 一个用例在某些扩展点上扩展另一个用例的功能，构 成新用例；箭头方向由扩展用例指向被扩展用例（即 基本用例）；
– 扩展用例依赖于被扩展用例（基本用例），只是部分 片段组成，不是完整的独立用例，无法单独执行；
图 《include》
《extend》
4.3.3 用例图的例子
• 实例1 参与者之间的泛化关系
• 参与者：经理，安全主管，保安
•
用例：管理人事，批准预算，批准安
全证书，监视周边
•
Байду номын сангаас
在参与者之间不存在泛化关系的情况
下，各个参与者参与用例的情况分别是：
经理参与用例管理人事和批准预算；安全
主管参与用例批准安全证书；保安参与用
– 系统外部的参与者，可以是用户、外部硬件、 其他系统。
4.1.2 参与者
• 【例4-1】客户给销售员发来传真订货， 销售员 下班前将当日订货单汇总输入系统。谁是系统的 参与者？
• 分析：根据参与者的定义可知，此系统的参与者 是销售员。
4.1.2 参与者
• 【例4-2】在需求分析中常见的权限控制问题，一 般的用户只可以使用一些常规的操作，如查询等， 而管理员除了常规操作之外还需要进行一些系统 管理工作，如一些关键数据的增加、删除、修改 等，操作员既可以进行常规操作又可以进行一些 配置操作。
– 扩展用例不一定每次都被执行和调用。（吃饭前也可 以不洗手），而被包含用例每次必修执行。
– 肯定没有活动者指向扩展用例，因为扩展用例依赖基 本用例。
4.2.4 泛化关系
• 泛化（generalization）
– 一个用例和其几种情形的用例间构成泛化； – 往往将父用例用抽象用例（abstract）表示
4.1.2 参与者
• 识别参与者
4.2 关系
• 用例除了与参与者有关联关系外，用例之间也存 在着一定的关系，如泛化关系、包含关系、扩展 关系等。
• 关联（accociation） • 包含（include） • 扩展（extend） • 泛化（generalization）
4.2.1 关联关系
4.2.3 扩展关系
• 扩展（extend）关系是对基本用例的扩展，基本用例是一个 完整的用例，即使没有子用例的参与，也可以完成一个完整 的功能。extend的基本用例中将存在一个扩展点，只有当扩 展点被激活时，子用例才会被执行。
• 在扩展关系中，对于扩展用例有更多的规则限制，即基本用 例必须声明若干“扩展点”（extension point），而扩展用 例只能在这些扩展点上增加新的行为和含义。扩展关系是从 扩展用例到基本用例的关系，它说明扩展用例定义的行为如 何插入到基本用例定义的行为中。也就是说，扩展用例并不 在基本用例中显示。
• 例如，在图书管理系统中，用户可以进行“查询图书的基 本信息”，“借书”以及“还书”，管理员可以对图书的 基本信息进行管理，如“新增图书信息”、“修改图书信 息”，“删除图书”等等操作。即这些操作都是系统提供 的服务（功能），因此，这些都可以独立成为一个用例。 执行这些操作的都是人（即参与者）。
• 用例在UML中通常用一个椭圆图形符号来表示。如图4.4 所示。
实例3. 航空售票的用例图
参与者(actor)：clerk，监督员，信用卡 服务商，信息亭
用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales
4.1.2 参与者
• 参与者（也称为角色或活动者，Actor）是系统外部的一个 人或者物，它以某种方式参与了系统的执行过程。参与者 不是特指人，是指系统以外的，在使用系统或与系统交互 中所扮演的角色。因此参与者可以是人，可以是事物，也 可以是时间或其他系统等等。还需要注意的是，参与者不 是指人或事物本身，而是表示人或事物在系统中所扮演的 角色。
– 包含关系指的是两个用例之间的关系，其中一个用例 （称为基本用例）的行为包含了另一个用例（称为包含 用例）的行为。也就是说基本用例会用到包含用例。
– 在UML图中，使用带虚线箭头表示，并在线上标有 <<include>>。 箭头方向由基本用例指向被包含用例；
– 执行基本用例时，每次都必须调用被包含的用例（吃饭 前洗手）；
4.1.1 参与者
• 例如，在“图书管理系统”中，可以认为 “读者”是“学生读者”和“教师读者” 的泛化，而“学生读者”还可以具体化为 “本科生读者”和“研究生读者”；同样， “图书管理员”也是“采购员”、“ 编目 员”及“借阅人员”的泛化。
教师
读者 学生
本科生
研究生
4.1.2 参与者
• 怎样识别参与者 – 谁使用系统的主要功能？ – 谁需要系统的支持以完成日常工作任务？ – 谁从系统获取信息？ – 谁负责维护和管理系统以保证其正常工作？ – 系统需要使用哪些外部硬件设备？（系统启动打印机、 扫描仪） – 系统需要和哪些外部系统交互？（跨行转账的外部银 行系统、时间到了定时启动系统某功能）
用例1
图4.4 用例符号
4.1.1 用例
• 例如，在文字处理程序中，“置正文的字体为宋体”是一 个用例，在图书管理系统中“新增图书信息”、“借书” 和“还书”也是用例，在超市管理系统中的“进货”也是 一个用例，如图4.5所示。在这里可以看出，用例可大可 小，有的用例可能比较简单，而有的可能就很复杂，如 “置正文的字体为宋体”这个用例就比较简单，很容易实 现，但是对于“进货”和“借书”这样的用例相对就比较 复杂，可能需要花一些时间才能够实现。
借阅者
查找图书
精确查找 模糊查找
4.3 用例图
• 用例图是被称为参与者的外部用户所能观察到的系统功能 的模型图。
• 用例图列出系统的用例和系统外的用例，并显示哪个参与 者参与了哪个用例的执行（或称为发起了哪个用例）。
• 用例图多用于静态建模阶段(主要是业务建模和需求建模)。 • 显示系统和外部实体（Actor）交互的图
箭头指向的用例为被扩展的用例，称为扩展 用例；箭头出发的用例为基用例。扩展用例 是可选的，如果缺少扩展用例，不会影响到 基用例的完整性；扩展用例在一定条件下才 会执行，并且其执行会改变基用例的行为。
发出箭头的事物“is a”箭头指向的事物。泛 化关系是一般和特殊关系，发出箭头的一方 代表特殊的一方，箭头指向的一方代表一般 一方。特殊一方继承了一般方的特性并增加 了新的特性。
UML表示
4.3.2 用例图中的关系
关系
参与者 与用例 之间的 关系
关联
用例之 间的关 系
包含 扩展
参与者 之间的 关系
泛化
解释
表示参与者与用例之间的交互，通信途径。 (关联有时候也用带箭头的实线来表示，这样 的表示能够显示地表明发起用例的是参与 者。)
箭头指向的用例为被包含的用例，称为包含 用例；箭头出发的用例为基用例。包含用例 是必选的，如果缺少包含用例，基用例就不 完整；包含用例必须被执行，不需要满足某 种条件；其执行并不会改变基用例的行为。
• 关联（accociation）
– 每个用例都有活动者启动（每个用例必须和一 个活动者关联，有一个活动者来参与），除包 含和扩展用例
– 无论用例和活动者是否存在双向数据交流（无 论是参与者提供信息给系统，还是从系统获取 信息），关联总是由活动者指向用例，只用单 向箭头。
4.2.2 包含关系
• 包含（include） （是一种依赖关系，加了版型<<include>>）