第三章 用例和用例图课件.ppt

第三章 用例和用例图 航空兵某师副师长、空军特级飞行员严锋 “把飞行当职业只能会飞， 把飞行当事业可以飞好， 把飞行当艺术才能飞精。” 用例 定义 用例是系统、子系统或类和外部的参与者（actor）交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。 用例（use case）是对一个活动者（actor）使用系统的一项功能时所进行的交互过程的一个文字描述序列 用例是系统提供的外部可感知的功能单元，用例的目的是定义清晰的系统行为，但不解释系统的内部结构 在UML中，用例用一个椭圆表示，用例名往往用动宾结构或主谓结构命名（英文命名，往往采用动宾结构） 怎么获取用例？ 活动者希望用户执行什么任务？ 活动者在系统中访问哪些信息（创建、存储、修改、删除等）？ 需要将哪些外界信息提供给系统 需要将系统的什么事情告诉活动者 如何维护系统 系统和关联 系统：用于界定系统功能范围，描述该系统功能的用例都置于其中，而描述外部实体的执行者都置于其外。 关联：连接执行者和用例，表示执行者所代表的系统外部实体与该用例所描述的系统需求有关。 用例作需求分析的特点 用例从使用系统的角度描述系统中的信息，即站在系统外部察看系统功能，而不考虑系统内部对该功能的具体实现方式。 用例描述了用户提出的一些可见需求，对应一个具体的用户目标。 用例是对系统行为的动态描述，属于UML的动态建模部分。 UML中的 Use Case 表示 常见错误 识别用例时一个常见的 错误是把用例当成是单独的步骤、操作或事务的处理。 参与者 参与者（actor）是指系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等。 参与者的三种表示形式 系统及其边界 典型的系统边界包括 硬件设备或者计算机系统的硬件/软件边界 一个组织中的部门 整个组织 系统边界识别的目的：为了识别出什么是系统内以及什么在系统之外，进而识别出什么是系统的职责。 以销售点终端系统为例 选择整个商店或者企业作为“系统” 选择销售点终端的软硬件系统作为系统边界 如果开发的是一个应用软件或者硬件设备，那么用这个软件或硬件的边界作为系统边界通常是合理的选择 如果从事的是企业过程重组或业务过程重组，那么选择整个企业或者商店作为系统是可取的 用例间的关系 关联（association）是指参与者与其参与执行的用例之间的通信途径 泛化（generalization）是代表一般和特殊的关系 在泛化关系中，子用例继承父用例的行为和含义，子用例也可以增加新的行为和含义或覆盖父用例的行为和含义 包含（include）关系指的是两个用例之间的关系，其中一个用例（称为基本用例，base use case）的行为包含另一个用例（称为包含用例，inclusion use case）的行为 箭头方向由基本用例指向被包含用例。 执行基本用例的时候，每次都应该调用被包含用例（或其中一个），被包含用例也可单独执行。 什么时候使用包含用例 第一 如果两个以上的用例有共同的功能，则可以将这个功能分解到另一个用例中． 第二 一个用例的功能太多时，可以用包含关系建模两个小用例。 扩展关系（extend）的基本含义与泛化关系类似，但在扩展关系中，对扩展用例有更多的规则限制，即基本用例必须声明若干“扩展点”，而扩展用例只能在这些扩展点上增加新的行为和含义 箭头方向由扩展用例指向基本用例。 扩展用例依赖于被扩展用例，不是完整的独立用例，无法单独执行。 用例的泛化、包含和扩展关系的比较 在扩展关系中，一个基本用例执行时，可以执行、也可以不执行扩展部分 在包含关系中，在执行基本用例时，一定会包含用例部分 用例图 用例图（use case diagram）是显示一组用例、参与者以及它们之间关系的图。 在UML中，一个用例模型由若干个用例图描述。 用例的描述 更详细地描述用例的功能 用例的描述内容 用例的目标 用例是怎么启动的 参与者和用例之间的消息是如何传送的 用例中除了主路径外，其他路径是什么 用例结束后的系统状态 其他需要描述的内容 用例描述的主要组成 用例名称 简要说明/描述 优先级 参与者 前提条件 主事件流 其他事件流 扩展点 后置条件 用例描述的主要组成 用例名称 应该与用例图相符合，可以写上编号（标识） 简要说明 对用例的价值结果进行描述，语言应简洁易懂 前置条件 用例执行之前应该满足的条件 后置条件 用例执行完毕系统可能处于的一组状态 用例描述的主要组成 扩展点（泛化、包含、扩展） 如果有被扩展、包含或泛化的用例，写出它们的名称，并说明在什么情况下使用 优先级 说明用户对该用例的期望值，可以为今后开发时制定先后顺序 主事件流 主事件流是正常情形,是用例中的最常用路径