UML第2章[1][1].用例图.pptVIP

第2章 用例图 用例图的组成 理解泛化 理解用例之间的关系 对用例进行描述 绘制用例图 2.1 组成 用例（Use Case） 活动者（角色，Actor) 关系（Relationship） 2.1.1 用例 Use Case 系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。 用例分析可以认为是对系统功能的分解。 2.1.1 用例 怎样确定用例的粒度？ 用例的粒度（用例的大小）可大可小，一般一个系统宜控制在20个用例左右 用例是系统级的、抽象的描述，不是细化的（是做什么，非怎么做） 对复杂的系统可以划分为若干子系统处理 2.1.1 用例 怎样获取用例 活动者希望系统执行什么任务？ 活动者在系统中访问哪些信息（创建、存储、修改、删除等）？ 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉活动者？ 如何维护系统？ 2.1.2 活动者（角色） Actor 系统外部的参与者，可以是用户、外部硬件、其他系统。 2.1.2 活动者（角色） 怎样识别活动者？ 谁向系统提供信息？ 谁从系统获取（使用）信息？ 谁操作系统？ 谁维护系统？ 系统使用哪些外部资源？ 系统是否和已经存在的系统交互？ 2.1.2 活动者（角色） 理解： Actor不是指人，而是指代表某一种特定功能的角色，因此同一个人可能对应很多个Actor。Actor是虚拟的概念，可以指外部系统和设备。 如果一个角色的操作是由另外一个角色代理完成的，请建立该角色到另外角色的依赖。 2.1.3 关系 关联（association） 包含（include） 扩展（extend） 泛化（generalization） 2.1.3 关系 关联association 用单向箭头表示，只表示谁启动用例，不考虑信息的双向流动；每个用例都有角色启动，除包含和扩展用例； 无论用例和角色是否存在双向数据交流，关联总是由角色指向用例。 2.1.3 关系 包含include 箭头方向由基本用例指向被包含用例； 两个以上用例有共同功能，可分解到单独用例，形成包含依赖； 执行基用例时，每次都必须调用被包含用例，被包含用例也可单独执行； 2.1.3 关系 包含include 一个用例功能过多需分解成小用例，构成包含依赖； 2.1.3 关系 扩展extend 一个用例（在某些扩展点上）扩展另一个用例的功能，构成新用例； 扩展用例依赖于被扩展依赖（基本用例），只是部分片段组成，不是完整的独立用例，无法单独执行； 2.1.3 关系 泛化（generalization） 一个用例和其几种情形的用例间构成泛化。 往往父用例表示为抽象用来（abstract）。 2.1.3 关系 2.2 用例图 显示系统和外部实体交互的图。 2.2 用例图 选择谁？ 2.3 用例描述 更详细地描述用例的功能 主要组成： 用例名称 简要说明/描述 优先级 参与者 前提条件 主事件流 其他事件流 扩展点 后置条件 2.3 用例描述 用例名称： 应该与用例图相符，并写上其相应的编号； 简要说明： 对该用例对参与者所传递的价值结果进行描述，应注意语言简要，使用用户能够阅读的自然语言； 前置条件： 是执行用例之前必须存在的系统状态，这部分内容如果现在不容易确定可以在后面再细化。 后置条件： 用例执行完毕系统可能处于的一组状态，这部分内容如果现在不容易确定也可以在后面再细化。 2.3 用例描述 扩展点： 如果包括扩展或包含用例，则写出扩展或包含用例名，并说明在什么情况下使用。而在本例中，用例图里没有相应的内容，因此可以直接写无。如果有，则应该在编写事件流的同时进行编写。 优先级： 说明用户对该用例的期望值，可以为今后开发时制定先后顺序。可以采用满意度/不满意度指标进行说明，其中满意度的值为0-5，是指如果实现该功能，用户的满意程度；而不满意度的值也为0-5，是指如果不实现该功能，用户的不满意程度。 2.3 用例描述 基本事件流 图书管理员向系统发出“新增书籍信息”请求； 系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类； 图书管理员作出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号； 图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、开本、页数、定价、是否有CDROM； 系统确定输入的信息中书名未有重名； 系统将所输入的信息存储建档。 扩展事件流 5a 如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理员选择修改书名或取消输入； 5a1 图书管理员选择取消输入，则结束用例，不做存储建档工作； 5a2 图书管理员选择修改书名后，转到5） 2.4 用例分析 步骤： 确定系统的边界范围，找出系统外部的参与者和外部系统； 确定每一个参与者所希望