用例和用例图讲述.pptxVIP

UML建模语言及其开发工具Rose 第4章 用例和用例图 第4章 用例和用例图 4.1 概述 用例模型是表达系统外部事物与系统之间交互的可视化工具。当用例模型在外部事物面前出现时，它捕获到系 统、子系统或类的行为，将系统功能划分成对系统用户有用的需求。交互部分或功能被表示成用例。 用例图展示了系统边界、参与者（系统外部事物）、用例以及它们之间的关系，描述了参与者与系统交互的情况以及系统的功能。 4.2 参与者 参与者（actor）：在系统外部与系统交互的人或事物，它以某种方式参与系统内用例的执行。 位于系统（边界）之外 表示的是人或事物与系统交互时所担任扮演的角色 参与者不仅可以由人承担，还可以是其他的外部系统，甚至是时间等。 系统实际运作中，一个实际用户可能对应系统的多个参与者。如，一个人可以既是一个商店的售货员又是顾客 4.2 参与者 寻找和确定参与者 获取用例前，首先要确定系统的参与者。询问以下问题帮助确定参与者： 谁使用系统的主要功能？ 谁改变系统的数据？ 谁从系统获取数据？ 谁需要系统的支持以完成日程工作任务？ 谁负责支持和维护系统？ 系统需要控制哪些外部资源或硬件设备？ 系统需要和哪些外部系统交互？ 谁对系统运行结果感兴趣？ 4.2 参与者 参与者之间的关系 参与者实际上是版型化的类，因此多个参与者之间可以具有与类之间相同的关系。用例图中，使用泛化关系来描述多个参与者之间的公共行为。 4.3 用例 定义 用例定义了一组用例实例，其中每个实例都是系统执行的一系列动作，这些动作可以对参与者产生有一定价值的可观察到的结果。 采用用例进行需求分析的特点： 1、用例由一组用例实例组成。用例实例也称为场景，是参与者和系统之间一系列特定的活动和交互。场景是使用系统的一个特定情节或用例的一条执行路径。 例 商场购物“付款”的用例 场景一：使用现金成功付款 场景二：银行卡付款被拒绝，付款失败。 4.3 用例 采用用例进行需求分析的特点： 2、用例站在系统外部察看系统功能，而不考虑系统内部对该功能的具体实现。 3、用例描述了用户提出的一些可见需求，对应一个具体的用户目标，即用例的执行结果对参与者有意义。 4、用例是对系统行为的动态描述，属于动态建模部分 此外，用例不是全部的系统需求，只是功能性的需求。 4.3 用例 发现用例 用例的来源是参与者对系统的期望，所以识别用例最好的方法是从客户的需求入手。识别用例过程中，以下的问题可以帮助发现用例： 参与者为什么要使用该系统？ 参与者打算在这个系统里做些什么事情？ 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是，如何来完成这些操作的？ 参与者是否会将外部的某些事件通知给该系统？ 系统是否会将内部的某些事件通知该参与者？ 4.4 用例间的关系 泛化关系 4.4 用例间的关系 包含关系（Include） 一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包含关系。 用例是一个事件流的集合，当某个事件流片段在多个用例中出现时，可以将这个事件流片段抽取出来，放在一个单独的包含用例中，简化基用例的描述。 4.4 用例间的关系 扩展关系（Extend） 扩展关系表示基本用例在由扩展用例间接说明的一个位置上隐式的合并了另一个用例（扩展用例）的行为。 基本用例不知道扩展用例的任何细节，没有扩展用例，基本用例是完整的。只有在特定条件下，它的行为可以被扩展用例的行为扩展，因此扩展关系处理事件流的异常或者可选事件。 4.4 用例间的关系 关联关系：参与者与用例之间的关系 用例图中，关联关系描述参与者与用例之间的关系，表示参与者和用例之间的通信。 如果参与者启动了用例，箭头指向用例；如果参与者利用了用例提供的服务，箭头指向参与者；如果二者是互动的，则是直线。 4.5 边界 “系统边界” 用来定义系统的界限，系统用例都置于其中，参与者置于边界外。 边界决定了抽象的层次。 4.6 事件流与用例描述 用例描述的是一个系统做什么的信息，并不说明怎么 做。用例是对使用场景进行抽象的总结，形成一组事件流。 1、事件流 前置条件：用例执行前系统和参与者应处于做什么状态。 后置条件：用例结束后系统处于什么状态。 基本事件流：对用例中常规、预期路径的描述，是大部分的时间所遇到的场景。 扩展事件流：对一些异常情况、选择分支进行描述。 4.6 事件流与用例描述 2、用例描述 用例编号 [用例唯一标识符，通常格式为UCxx，在文档别处可以用标识符来引用该用例] 用例名称 [表明用户意图或用例的目标，一般是动词短语] 用例描述 [对用例目标的一