图书馆管理系统用例的视图.pptVIP

图书馆管理系统用例视图 5.1、概述 Use Case Diagrams，用例图是由软件需求到最终实现的第一步，在UML中用例图用于对系统、子系统或类的行为的可视化，以便使系统的用户更容易理解这些元素的用途，也便利软件开发人员最终实现这些元素。 5.1、概述 用例视图是从用户角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为。 用例图是至关重要的，它的正确与否直接影响到用户对最终产品的满意程度 5.1、概述 UML中的用例图描述了一组用例、参与者以及它们之间的关系，它包括三个方面内容： 用例（Use Case） 参与者（Actor） 依赖、泛化以及关联关系（Example） 5.2 参与者（Actor） 参与者（Actor）是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。 参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由他们参与用例时所担当的角色来表示 5.2 参与者（Actor） 寻找参与者的方法： 谁或什么使用该系统 交互中，它们扮演什么角色 谁安装系统 谁启动和关闭系统 谁维护系统 与该系统交互的是什么系统 谁从系统获取信息 5.2 参与者（Actor） 寻找参与者的方法： 谁提供信息给系统 有什么事发生在固定事件 5.2 参与者（Actor） 在建模参与者过程中，记住以下要点： 参与者对于系统而言总是外部的，因此它们在你的控制之外 参与者直接同系统交互，这可以帮助定义系统边界 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物 一个人或事物在系统发生交互时，可以同时或不同时扮演多个角色。如，某研究生担任某教授的助教，同职业的角度看，他扮演了两个角色——学生和助教 5.2 参与者（Actor） 在建模参与者过程中，记住以下要点： 每一个参与者需要有一个具有业务一样的名字，在建模中，不推荐使用诸如NewActor这样的名字 每个参与者必须有简短的描述，从业务角度描述参与者是什么 像类一样，参与者可以具有分栏，表示参与者属性和它可接受的事件。 5.3 用例（Use Case） 概念：它是一个叙述型的文档，用来描述参与者（Actor）使用系统完成某个事件时的事情发生顺序。用例是系统的使用过程，更确切地说，用例不是需求或者功能的规格说明，但用例也展示和体现出了其所描述的过程中的需求情况。 5.3 用例（Use Case） 命名： 每个用例都必须有一个唯一的名字以区别其他用例。其名字可以是一个字符串，它包括简单名（Simple)和路径名（Path Name）。 （Example Ex5_01） 5.3 用例（Use Case） 识别用例 系统分析者必须分析系统的参与者和用例，它们分别描述了“谁来做？”和“做什么”这两个问题 识别用例的最好方法是从分析系统的参与者开始，考虑每个参与者怎样使用系统？ 5.3 用例（Use Case） 识别用例 特定参与者希望系统提供什么功能 系统是否存储和检索信息，如果是，这个行为由哪个参与者触发 当系统改变状态时，通知参与者吗 存在影响系统的外部事件吗 是哪个参与者通知系统这些事件 （Example 仓库管理系统Ex5_aaa） 5.3 用例（Use Case） 用例与事件流 用例分析处于系统的需求分析阶段，这个阶段应该尽量避免考虑系统的细节问题，也就是说，用例描述的是一个系统做什么，而不是怎么做 可通过一个清晰的、易被用户理解的时间来说明一个用例的行为。这个事件包括用例何时开始和结束，用例何时和参与者交互，什么对象被交互以及该行为的基本流和可选流 5.3 用例（Use Case） 用例与事件流 例：仓库管理——“用户登录” 主事件流：参与者管理员或操作员输入自己的密码时，用例开始。输入的密码被提交后，服务器判断密码是否正确。如果正确，用户成功登录，系统用户的类型（管理员或操作员）为其分配相应的权限 异常事件流：用户密码错误，不能登录，用例重新开始 异常事件流：在密码提交前，用户清除输入密码，重新填写 5.3 用例（Use Case） 用例之间的关系 泛化（Generalization）（Example Ex5_Generalization） 5.3 用例（Use Case） 用例之间的关系 包含关系（Include） 包含关系把几个用例的公共步骤分离成一个单独的被包含的用例。 用例间的包含关系允许包含提供者用例的行为到用户用例的事件中。 把包含用例称为客户用例，被包含用例称为提供者用例 （Example Ex5_include） 5.3 用例（Use Case） 扩展关系（Extend） 扩展关系是把新行为插入到已有用例的方法。基础用例提供了一组扩展点（Extension points），这