[工学]用例图专题介绍.pptVIP

第5章 用例图 5.1 用例图的概念 5.2 用例图建模技术 5.6 实例——-图书馆管理系统中的 用例图 试想描述自动售货系统的功能 用例图示例 5.1.1 概述 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。 用例图最常用来描述系统以及子系统。 5.1.1 概述 用例图包含6个元素： 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 5.1.2 参与者 系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。 5.1.2 参与者 参与者的种类： 系统用户 与所建造的系统交互的其他系统 一些可以运行的进程 确定参与者 如何寻找系统的参与者 谁将使用该系统的主要功能。 谁将需要该系统的支持以完成其工作。 谁将需要维护、管理该系统，以及保证该系统处于工作状态。 系统需要处理哪些硬件设备。 与该系统交互的是什么系统。 谁或什么系统对本系统产生的结果感兴趣 确定参与者 对参与者建模的过程中需要注意的问题 参与者对于系统而言总是外部的，因此它们可以处于系统的控制之外。 参与者可以直接或间接地同系统交互，或使用系统提供的服务以完成某件事务。 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或者特定的事物。 一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。 每一个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似于“新参与者”的名字。 每一个参与者必须有简短的描述，从业务角度描述参与者是什么。 和类一样，参与者可以具有表示参与者的属性和可以接受的实际那，但使用的频繁 参与者间的关系 在用例图中，使用泛化关系来描述多个参与者之间的公共行为。 参与者间的泛化关系示例： 5.1.3 用例 外部可见的系统功能单元。 在不揭示系统内部构造的前提下定义连贯的行为。 不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。 5.1.3 用例 用例的名称： 简单名 路径名 识别用例 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。 如何识别用例： 特定参与者希望系统提供什么功能 系统是否存储和检索信息，如果是由那个参与者出发。 当系统改变状态时，是否通知参与者。 是否存在影响系统的外部事件。 有哪个参与者通知系统这些时间。 用例与事件流 1. 简要说明 2. 前提条件 3. 事件流（主事件流、其他事件流、错误流 ） 4. 事后条件 5.1.4 用例间的关系 1 关联关系 2 包含关系 3 扩展关系 4 泛化关系 关联关系 表示参与者用例之间进行通信。 不同的参与者可以访问相同的用例。 包含关系 客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。 扩展关系 扩展用例被定义为基础用例的增量扩展。 基础用例提供扩展点以添加新的行为。 扩展用例提供插入片段以插入到基础用例的扩展点上。 泛化关系 父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为。 5.2 用例图建模技术 5.2.1 对语境建模 5.2.2 对需求建模 5.2.1 对语境建模 识别系统外部的参与者。 将类似参与者组织成泛化的结构层次。 在需要加深理解的地方，为每个参与者提供一个构造型。 将参与者放入到用例图中，并说明参与者与用例之间的通信路径。 5.2.2 对需求建模 识别系统的外部参与者来建立系统的语境。 考虑每一个参与者期望的行为或需要系统提供的行为。 把这些公共的行为命名为用例。 确定提供者用例和扩展用例。 对这些用例、参与者和它们之间的关系建模。 用注释修饰用例。 5.3 实例——图书馆管理系统的用例图 5.3.1 确定系统涉及的总体信息 5.3.2 确定系统的参与者 5.3.3 确定系统的用例 5.3.4 使用Rational Rose绘制用例图的步骤 5.3.5 图书馆管理系统的用例图 5.3.1 确定系统涉及的总体信息 读者： 借书 还书 书籍预定 5.3.1 确定系统涉及的总体信息 图书馆管理员： 书籍借出处理 书籍归还处理 预定信息处理 5.3.1 确定系统涉及的总体信息 系统管理员： 增加书目 删除或更新书目 增加书籍 减少书籍 增加读者帐户信息 删除或更新读者