第02章 用例图.ppt

第2章 用例图 2.1 用例图的概念 2.2 用例图建模技术 2.6 实例——-图书馆管理系统中的 用例图 用例图 人们在进行软件开发时，无论是采用面向对象方法还是传统方法，首先要做的就是了解需求。由于用例图是从用户角度来描述系统功能的，所以在进行需求分析时，使用用例图可以更好描述系统应具备什么功能。用例图由开发人员与用户经过多次商讨而共同完成，软件建模的其他部分都是从用例图开始的。这些图以每一个参与系统开发的人员都可以理解的方式列举系统的业务需求。 本章将首先介绍系统、参与者和用例等一些基本概念及表示方法，然后再讨论泛化用例与参与者，以及用例之间的关系。最后介绍如何对用例进行描述以及如何绘制用例图。 系统 系统是用例图一个重要组成部分。系统是用于执行某一项功能的，它不单指一个软件系统。但说本书的目的而言，我们感兴趣的是计算机软件，系统是为用户执行某类功能的一个或多个软件构件。系统的边界用来说明用例图应用的范围。例如，一台自动售货机应提供售货、供货、提取消售款等功能，这引功能在自动售货机之内的区载起作用，自动售货机之外的情况则不考虑。准确定义系统的边界并不总是很容易的，因为有些情况下，严格地划分哪些任务是由系统完成，而哪些是由人工或其他系统完成是很困难的。另外，系统最初的规模应有多大也应该考虑。一般的作法是，先识别出系统的基本功能，然后以此为基础定义一个稳定的、精确定义的系统架构，以后再不断地扩充系统功能，逐步完善系统。这样做可以避免由于系统太大，需求分析不易明确，从而导致辞浪费大量的开发时间。 2.1.1 概述 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。 用例图最常用来描述系统以及子系统。 2.1.1 概述 用例图包含6个元素： 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 2.1.2 参与者 参与者是系统外的一个实体，参与者通过向系统输入或者系统要求参与者提供某种信息来进行交互。在确定系统的用例时，首要问题就是识别参与者。 参与者的概念 参与者用于表示使用系统的对象。参与者可以是一个人、一个计算机系统、另一个子系统或另外一种对象。例如，一个计算网络系统的参与者可以包括操作员、系统管理员、数据库管理员和普通的用户，也可以有非人类参与者，如网络打印机。参与者的特征是其作为外部用户与系统发生交互。在系统的实际运作中，一个实际用户可能对应系统的多个参与者。同样，不同的多个用户也可以只对应于一个参与者，从而代表同一个参与者的不同实例。 2.1.2 参与者 系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。 2.1.2 参与者 参与者的种类： 系统用户 与所建造的系统交互的其他系统 一些可以运行的进程 确定参与者 如何寻找系统的参与者 对参与者建模的过程中需要注意的问题 参与者间的关系 在用例图中，使用泛化关系来描述多个参与者之间的公共行为。 参与者间的泛化关系示例： 2.1.3 用例 用例是一组连续的操作，在用户使用系统来完成某个过程时出现，它是外部可见的系统功能单元。通过将这些不同的功能单元进行组合，就构成了对系统总体需求的描述。 用例的概念 用例是用户期望系统具备的功能，它定义了系统的行为特征，如果没有这些特征，系统就不能被成功地使用。例如，程序开发人员使用开发系统来开发软件，则开发系统应具备编译功能以满足程序开发人员的需求。 用例的目标是要定义系统（包括一个子系统或整个系统）的一个行为，但并不显示系统的内部结构。每个用例说明一个系统提供给它的使用者的一种服务，即一种对外部可见的使用系统的特定方式。它以用户的观点描述用户和系统间交互的完整顺序，以及由系统执行的响应。这里的交互只包括系统与参与者之间的通讯，而其内部行为和实现是隐藏的。一个系统的全部用例分割和覆盖它的行为，每个用例代表一部分量化了的、有深刻意义的和对用户可用的功能性。注意这里的用户包括人、计算机和其他对象。 2.1.3 用例 外部可见的系统功能单元。 在不揭示系统内部构造的前提下定义连贯的行为。 不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。 2.1.3 用例 用例的名称： 简单名 路径名 识别用例 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。 如何识别用例。 用例与事件流