第5章 用例图.pptVIP

第5章 用例图 主讲：才智 第5章 用例图 5.1 概述 5.2 参与者（Actor） 5.3 用例（Use Case） 5.4 用例间的关系 5.5 用例图建模 5.6 用例图建模实例 5.1 概述 面向对象的系统分析主要特点是把问题域中的事物抽象为系统中的对象，最终建立一个用面向对象概念表达的系统模型。 抽象必须有一个目标，对分析而言，这个目标就是要满足用户需求。 5.1 概述 Jacobson提出：针对系统对外提供的每一项功能，详细地描述对这项功能的使用情况（use case，简称用例）。 以用例作为建立需求模型的基本单位，一个用例只针对一项系统功能，详细的描述系统边界以外的参与者使用这项功能时与系统进行交互的情况，这可以比较确切地定义系统的功能需求。 用例的概念的提出弥补了以往各种面向对象分析方法在需求定义方面的不足，因此很快就被广泛采纳。 5.1 概述 UML的面向对象系统开发过程中在需求分析阶段的需求模型由用例建模完成，以用例为驱动，因此又称为用例模型。 用例模型是表达系统外部事物（参与者）与系统之间交互的可视化工具。 一个系统的用例模型由若干用例图组成，用例图的主要成分有参与者（Actor）、用例（Use Case）以及用例间的各种关系。 用例图可以包含注释和约束，还可以包含包，用于将模型中的元素组合成更大的模块。 5.1 概述 基本用例图 5.2 参与者（Actor） 参与者（Actor）是在系统之外与系统进行交互的任何事物，可以是人或其他系统，他以某种方式参与了系统内用例的执行。 参与者的特征是其作为外部用户与系统发生交互，交互的方式可以是参与者向系统发送消息，也可以是从系统那里接收消息，或与系统之间交换消息。 5.2 参与者（Actor） 参与者代表一种角色，而不是具体的某个人。 在系统的实际运作中，多个不同的用户可能只对应于一个参与者；同时一个实际用户也可能对应系统的多个参与者。 例如，在“房地产开发经营管理系统”中，所有的购房者作为一个集合，在“房屋销售子系统”中作为购房合同的签约方出现，多个个体在系统中担任一个参与者；同时，某个独立的购房者在“物业管理子系统”中又作为房屋的业主出现，同一个人在系统中担任了两类参与者。 5.2 参与者（Actor） 参与者的分类 人参与者和外部系统参与者 主参与者和副参与者 主动参与者和被动参与者 5.2 参与者（Actor） 人参与者和外部系统参与者 系统的各类用户是人参与者，用户通过与系统进行交互来操纵系统，完成各种工作。 参与者也可以是位于系统外部的其他软件系统或硬件设备，这类参与者统称为外部系统参与者。 例如，计算机网络系统的参与者可以包括操作员、系统管理员、数据库管理员以及普通用户等人参与者，另外也可以有外部系统参与者，如网络打印机。 5.2 参与者（Actor） 主参与者和副参与者 主参与者使用系统的主要功能，是使用系统较频繁、业务量较大的用户。 副参与者处理系统的辅助功能，它与用例进行交互的主要目的是为了给其他的参与者提供某些服务，如管理数据库、通信、系统备份以及其他管理等系统维护工作。 区分主参与者与副参与者不应该以参与者在使用系统时的权限为依据，一般情况下，应该以使用系统时的业务量为依据。 5.2 参与者（Actor） 主动参与者和被动参与者 主动参与者是系统的启动者，负责启动一个或多个用例，他们是为了完成某项事务而启动系统的，一个主动参与者可以请求某种服务或者触发一个事件。 被动参与者从不启动用例，只是参与一个或多个用例，他们相应系统的请求，为系统提供某种服务。 5.2 参与者（Actor） 参与者的表示 在用例图中，参与者用一个简化的人体形状的符号表示，在符号的下方注明了参与者的名称。 5.2 参与者（Actor） 识别参与者 进行用例图建模，首先要做的就是确定系统的参与者。 在确定参与者之前，一定要明确一点：参与者对于系统而言，总是处于系统外部的，而不是系统的组成部分。 5.2 参与者（Actor） 识别参与者 谁将使用系统的主要功能（主参与者）？ 谁将借助于系统来完成日常工作？ 为了保证系统正常运行，谁将对系统进行维护管理（副参与者）？ 谁将完成系统数据的录入、导出及修改等工作（主动参与者）？ 谁或什么系统对系统产生的结果感兴趣（被动参与者）？ 系统控制的硬件设备有哪些？ 系统需要与哪些其他外部系统进行交互？ 在预定的时间，是否有事件自动触发？ 系统从何处获取信息？ 5.2 参与者（Actor） 参与者之间的关系 泛化关系：用一个三角箭头来表示，其中箭头所指向的角色为超类参与者，箭头尾端的角色为特殊化的参与者。 5.3 用例（Use Case） 用例（Use C