第4章节 用例图.ppt

第四章 用例图 学习目标 掌握：用例图定义、用例图的标记符组件以及如何建立用例图模型。 理解：用例图建模的原因、泛化技术，以及包含与扩展关系。 了解：描述用例的方法。 4.1 用例图概述 用例建模的目的 利用“系统”的观点来分析问题、解决问题。 使用计算机逻辑来模拟描述系统本身，包括系统的组成、关系、系统的各种可能状态以及系统中可能产生的过程和过程引起的切换。 可以利用一个容易理解的模型来描述用户如何使用这个系统、系统和客户以及系统和外部系统之间的交互过程，这个模型也就是通常我们所说的使用UML设计新系统的起始点——用例图。 4.1 用例图概述 定义用例图 用例图是有关系统细节的最高形式。它能准确地说明客户对他们要开发的应用程序期望有什么样的功能 用例图是一种在系统完成后能使管理机构、用户和其他干系人了解其功能的极好方法。 4.1 用例图概述 ① 用例（Use Case） 定义：系统、子系统或类与外部的参与者交互的动作序列的说明，包括各种序列以及出错序列。 用例分析可以认为是对系统功能的分解。 4.1 用例图概述 思考： 怎样确定用例的粒度？ A．用例的粒度（用例的大小）可大可小，一般一个系统宜控制在20个用例左右 B．用例是系统级的、抽象的描述，不是细化的（是做什么，非怎样做） C．对复杂的系统可以划分为若干子系统处理 4.1 用例图概述 思考： 怎样获取用例？ 参与者希望系统执行什么任务？ 参与者在系统中访问哪些信息（创建、存储、修改、删除等）？ 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉参与者？ 如何维护系统？ 4.1 用例图概述 ②参与者（actor） 系统外部的参与者，可以是用户、外部硬件、其他系统 4.1 用例图概述 怎样识别参与者？？？？ 识别方法： 谁向系统提供信息？？ 谁从系统获取（使用）信息？？ 谁操作系统？？ 谁维护系统？？ 系统使用哪些外部资源？？ 系统是否和已经存在的系统交互？？ 4.1 用例图概述 理解： actor不是指人，而是代表某一种特定功能的角色，因此同一个人可能对应很多个actor。Actor是虚拟的概念，可以指外部系统和设备 如果一个角色的操作是由另外一个角色代理完成的，请建立该角色到另外角色的依赖 4.1 用例图概述 ③关系 关联（association） 包含（include） 扩展（extend） 泛化（generalization） 4.1 用例图概述 关联（association） 用单向箭头表示，只表示谁启动用例，不考虑信息的双向流动。每个用例都有角色启动，除包含和扩展用例 无论用例和角色是否存在双向数据交流，关联总是由角色指向用例 4.1 用例图概述 包含（include） 箭头方向由基本用例指向被包含用例 两个以上用例有共同功能，可分解到单独用例，形成包含依赖 执行基用例时，每次都必须调用被包含用例，被包含用例也可单独执行 4.1 用例图概述 包含（include） 一个用例功能过多需分解成小用例，构成包含依赖 4.1 用例图概述 扩展（extend） 一个用例（在某些扩展点上）扩展另一个用例的功能，构成新用例 扩展用例依赖于被扩展用例（基本用例），只是部分片段组成，不是完整的独立用例，无法单独执行 4.1 用例图概述 泛化（generalization） 一个用例和其几种情形的用例间构成泛化 往往父用例表示为抽象用例（abstract） 4.2 用例图 显示系统和外部实体交互的图 4.2 用例图 选择谁？ 4.3 用例描述 更详细地描述用例的功能 主要组成： 用例名称 简要说明和描述 优先级 参与者 前提条件 主事件流 其他事件流 扩展点 后置条件 4.3 用例描述 用例名称：应该与用例图相符合，并写上相应的编号 简要说明：对该用例对参与者所传递的价值结果进行描述，应注意语言简要，使用用户能够阅读的自然语言 前置条件：是执行用例之前必须存在的系统状态，这部分内容如果在现在不容易确定可以在后面再细化 后置条件：用例执行完毕系统可能处于的一组状态，这部分内容如果在现在不容易确定也可以在后面再细化 4.3 用例描述 扩展点：如果包括扩展或包含用例，则写出扩展或包含用例名，并说明在什么情况下使用。而在本例中，用例图里没有相应的内容，因此可以直接写无。如果有，则应该在编写编写事件流的同时进行编写。 优先级：说明用户对该用例的期望值，可以为今后开发时制定先后顺序。可以采用满意度/不满意度指标进行说明，用户的满意程度；而不满意度的值也为0-5，是指如果不实现该功能，用户的不满意程度。 4.3 用例描述——个人图书馆里系统 基本事件流： 图书管理员向系统发出“