uml第2章.pptVIP

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