第5章UML中的用例图讲解.pptVIP

第5章 用例图 5.1 用例图的基本概念 5.2 用例图的组成 5.3 用例图的创建概述 5.4 用例图的创建示例 5.5 实例——-图书馆管理系统中的用例图 5.1 用例图的基本概念 用例图通过用例来捕获系统的需求，在结合参与者进行系统功能需求的分析和设计。 5.1.1 用例图的定义 由参与者、用例以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。 5.1.2 用例图的作用 用例图是需求分析中的产物。 主要作用是描述参与者和用例之间的关系，帮助开发人员可视化地了解系统的功能。 用例图是可视化地描述了系统的功能性需求。 完全从外部来定义系统功能，把需求和设计完全分离开来。 清晰地描述了参与者之间的关系。 是沟通的好方法。 5.2 用例图的组成 用例图包含4个元素： 参与者（Actor） 用例（Use Case） 系统边界 关联 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 5.2.1 参与者 系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。 参与者的种类： 系统用户 与所建造的系统交互的其他系统 一些可以运行的进程 主要参与者和次要参与者 参与者的确定 如何寻找系统的参与者 对参与者建模的过程中需要注意的问题 参与者间的关系 在用例图中，使用泛化关系来描述多个参与者之间的公共行为。 参与者间的泛化关系示例： 泛化关系（或称继承关系）的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述为超类。 泛化关系表示的是参与者之间的一般/特殊关系。 5.2.2 系统边界 系统边界是指系统与系统之间的边界。 系统边界之外的同系统相关联的其他部分称为系统环境。 5.2.3 用例 外部可见的系统功能单元。 在不揭示系统内部构造的前提下定义连贯的行为。 不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。 5.2.3 用例 用例的名称： 简单名 路径名 用例和参与者之间的关系是关联关系，又称为通信关联。 关联关系是双向的一对一的关系。 用例必须由某一个参与者触发激活后才能执行，即每个用例至少应该涉及到一个参与者。 用例是完整的。 用例的识别 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。 如何识别用例。 用例的粒度 用例的粒度是指用例所包含的系统服务或功能单元的多少。 用例的粒度越大，用例包含的功能就越多，反之，则越少。 用例粒度大，用例数会少，反之，用例粒度小，用例数会多。 用例数目过多会造成用例模型过大和引入设计困难大大提高；用例数目过少不便于进一步充分分析。 用例的粒度不但决定了用例模型级的复杂度，还决定了每一个用例内部的复杂度。 在具体分析时，要尽可能保证整个用例模型的易理解性。 用例规约 用例规约就是对每个用例的详细的描述信息。 用例模型是由用例图和每一个用例的详细描述-用例规约组成。 用例规约基本上是用文本方式来表述的，可以适当的加入序列图、活动图、状态转移图或粘贴用户界面及其他图形来补充。 用例规约包括以下内容： 简要说明； 事件流； 用例场景； 特殊需求； 前置条件； 后置条件。 事件流：包括基本流和备选流。 基本流描述的是用例的基本流程，是用例“正常”运行时的场景。 备选流描述的是用例执行过程中可能发生的异常和偶尔发生的情况。 用例场景是指同一个用例在实际执行的时候会有很多不同的情况发生。 用例场景包括成功场景和失败场景。 场景使用事件流来描述。 注意不要遗漏某些需求。 特殊需求指一个用例的非功能性需求和设计约束。 特殊需求的非功能性需求包括可靠性、性能、可用性和可扩展性。 特殊需求的设计约束包括开发工具、操作系统及环境，兼容性等。 前置条件是指执行用例之前系统必须所处的状态。 后置条件是指用例执行完后系统可能处于的一组状态。 5.2.4 关联 1 关联关系 2 包含关系 3 扩展关系 4 泛化关系 关联关系 表示参与者用例之间进行通信。 不同的参与者可以访问相同的用例。 包含关系 用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。 使用包含关系的两种情况： 1、多个用例用到同一段的行为，把这段共同的行为单独地抽象出来成为一个被包含的用例。 2、某一个用例的功能过多，事件流过于复杂时，把某一段事件流抽象为一个被包含的用例，可以达到简化描述的目的。 包含关系的两个优点： 提高了用例模型的可维护性。 不但减少了重