第2章_用例图.pptVIP

2.3.2 确定系统的参与者 图书馆管理系统的参与者 读者（借阅者） 图书馆管理员 图书馆管理系统维护者 2.3.3 确定系统的用例 1. 借阅者请求服务的用例 2. 图书馆管理员处理借书、还书等的用例 3. 系统管理员进行系统维护的用例 1. 借阅者请求服务的用例 登录系统 查询自己的借阅信息 查询书籍信息 预定书籍 借阅书籍 归还书籍 2. 图书馆管理员处理借书、还书的用例 处理书籍借阅 处理书籍归还 删除预定信息 3. 系统管理员进行系统维护的用例 查询借阅者信息 查询书籍信息 增加书目 删除或更新书目 增加书籍 删除书籍 添加借阅者帐户 删除或更新借阅者帐户 2.3.4 图书馆管理系统的用例图 1. 借阅者请求服务的用例图 2. 图书馆管理员处理借书、还书的用例图 3. 系统管理员进行系统维护的用例图 1. 借阅者请求服务的用例图 2. 图书馆管理员处理借书、还书的用例图 3. 系统管理员进行系统维护的用例图 讨论题 假设有一个基于网络的学生成绩管理系统，该系统主要完成以下功能：教师使用该系统完成学生成绩的录入、修改、显示和打印，学生使用该系统来查询所学课程的成绩，管理员使用该系统输入学生信息、教师信息、班级信息和课程信息。 对上面给出的系统进行分析，找出系统中的参与者、用例，并对每个参与者、用例进行详细的描述。 第2章 用例图 2.1 用例图的概念 2.2 用例图建模技术 2.3 实例——-图书馆管理系统中的 用例图 2.1.1 概述 用例图是由软件需求分析到最终实现的第一步，它描述人们希望如何使用一个系统。显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务，以便使系统的用户更容易地理解这些元素的用途，也便于软件开发人员最终实现这些元素。 用例图最常用来描述系统以及子系统。 2.1.1 概述 用例图包含6个元素： 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 2.1.2 参与者 系统外部的一个实体，以某种方式参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。 它通过交换信息与用例发生交互，而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分描述参与者。 2.1.2 参与者 参与者的种类： 系统用户 命名这类参与者时，应当按照业务而不是按位置命名，因为一个人可能有很多业务。 与所建造的系统交互的其他系统 一些可以运行的进程 ，如时间等。 确定参与者 如何寻找系统的参与者？ 谁将使用该系统的主要功能。 谁将需要该系统的支持以完成工作。 谁将需要维护、管理该系统，以及保持该系统处于工作状态。 系统需要处理哪些硬件设备。 与该系统交互的是什么系统。 谁或什么系统对本系统产生的结果感兴趣。 确定参与者 对参与者建模的过程中需要注意的问题 参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。 参与者可以直接或间接地同系统交互，或使用系统提供的服务以完成某件事务。 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或者特定的事物。 一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。 每一个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似于“新参与者”的名字。 每一个参与者必须有简短的描述，从业务角度描述参与者是什么。 和类一样，参与者可以具有表示参与者的属性和可接受的事件，但使用得不频繁。 参与者间的关系 在用例图中，使用泛化关系来描述多个参与者之间的公共行为。 参与者间的泛化关系示例： 2.1.3 用例 用例是一个叙述型的文档，用来描述参与者使用系统完成某个事件时的事情发生顺序。 外部可见的系统功能单元，这些功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。 用例的用途是：在不揭示系统内部构造的前提下定义连贯的行为。 不是需求或功能的规格说明，也是展示和体现其所描述的过程中的需求情况。 2.1.3 用例 用例的名称： 简单名 路径名 是在用例名前加上所属包的名字 2.1.3 用例 用例的动态执行过程可以用UML的交互来说明，可以用状态图、时序图、协作图或非正式的文字描述来表示。用例功能的执行通过系统中类之间的协作来实现。一个类可以参与多个协作，因此可以参与多个用例。 在系统层，用例表示整个系统对外部用户可见的行为。 识别用例 识别用例最好的方法就是从分析系统的参与者开