UML面向对象建模chapter2用例图

1、UML面向对象建模基础用例图本节目标理解需求分析与用例图之间的关系。掌握参与者、用例、关系的概念。学会通过分析需求画出用例图。 任务 分析本章的项目引入中的系统的需求，确定系统中的参与者和主要用例，并画出用例视图。一、用例图的组成用例（Use Case）活动者（角色，Actor）关系（Relationship）1. 用例Use Case:系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。用例分析可以认为是对系统功能的分解。怎样确定用例的粒度？用例的粒度（用例的大小）可大可小，一般一个系统宜控制在20个用例左右。用例是系统级的、抽象的描述，不是细化的（是做

2、什么，非怎样做）对复杂的系统可以划分为若干子系统处理。怎样获取用例？活动者希望系统执行什么任务？活动者在系统中访问哪些信息（创建、存储、修改、删除等）？需要将外界的哪些信息提供给系统？需要将系统的哪个事件告诉活动者？如何维护系统？2 . 活动者（角色）Actor系统外部的参与者，可以是人、外部硬件、其他系统，甚至时间。怎样识别活动者？谁向系统提供信息？谁从系统获取（使用）信息？谁操作系统？谁维护系统？系统使用哪些外部资源？系统是否和已经存在的系统交互？是否有事情自动在预计时间发生？理解： Actor不是指人，而是指代表某一种特定功能的角色，因此同一个人可能对应很多个Actor。Actor是虚拟

3、的概念，可以指外部系统和设备。 如果一个角色的操作是由另外一个角色代理完成的，请建立该角色到另外角色的依赖。3. 关系关联（association）包含（include）扩展（extend）泛化（generalization）关联association用单向箭头表示，只表示谁启动用例，不考虑信息的双向流动；每个用例都有角色启动，除包含和扩展用例无论用例和角色是否存在双向数据交流，关联总是由角色指向用例。包含include箭头方向由基本用例指向被包含用例；两个以上用例有共同功能，可分解到单独用例，形成包含依赖；执行基用例时，每次都必须调用被包含用例，被包含用例也可单独执行；包含include一个

4、用例过于复杂，可以分解成小用例，构成包含依赖（三个被包含的用例合起来实现完整的事件流，不能单独调用）；扩展extend一个用例（在某些扩展点上）扩展另一个用例的功能 ，构成新用例；扩展用例依赖于被扩展依赖（基本用例），只是部分片断组成，不是完整的独立用例，无法单独执行；泛化（generalization）一个用例和其几种情形的用例间构成泛化。往往父用例表示为抽象用例（abstract）。Eg 二、用例图显示系统和外部实体交互的图。Rational Software Modeler选择谁？三、用例描述更详细地描述用例的功能主要组成：用例名称简要说明/描述优先级参与者前提条件主事件流其他事件流扩展

5、点后置条件用例描述模板用例名称：应该与用例图相符，并写上其相应的编号；简要说明：对该用例对参与者所传递的价值结果进行描述，应注意语言简要，使用用户能够阅读的自然语言。前置条件：是执行用例之前必须存在的系统状态，这部分内容如果在现在不容易确定可以在后面再细化。后置条件：用例执行完毕系统可能处于的一组状态，这部分内容如果在现在不容易确定也可以在后面再细化。扩展点：如果包括扩展或包含用例，则写出扩展或包含用例名，并说明在什么情况下使用。而在本例中，用例图里没有相应的内容，因此可以直接写无。如果有，则应该在编写事件流的同时进行编写。优先级:说明用户对该用例的期望值，可以为今后开发时制定先后顺序。可以采

6、用满意度/不满意度指标进行说明，其中满意度的值为0-5，是指如果实现该功能，用户的满意程度；而不满意度的值也为0-5，是指如果不实现该功能，用户的不满意程度。基本事件流1）图书管理员向系统发出“新增书籍信息”请求；2）系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类；3）图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号；4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN 号、开本、页数、定价、是否有CDROM；5）系统确认输入的信息中书名未有重名；6）系统将所输入的信息存储建档。扩展事件流5a）如果输入的书名有重名现象，则显示出重

7、名的书籍，并要求图书管理员选择修改书名或取消输入；5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作；5a2）图书管理员选择修改书名后，转到5）用例图的绘制流程步骤：捕获需求；确定系统的边界范围，找出系统外部的参与者和外部系统；确定每一个参与者所希望的系统行为，命名用例；把公共系统行为分解为新用例，供其他用例引用；把一些变更的行为分解为扩展用例；编制用例的脚本；绘制用例图；把特殊情况的用例画成单独的子用例图。记录需求特性表识别参与者已有的上下文关系图（表示系统范围）及其他相关模型：它们描述了系统与外部系统的边界，从这些图中可以寻找出与系统有交互关系的外部实体。项目相关人员分析：对项目

8、的相关人员进行分析，就能够决定出哪些人将会与系统进行交互。书面的规格说明和其它项目文档（如会谈备忘录等）需求研讨会和联合应用开发会议的记录：这些会议的参与者通常是很重要的，因为他们在组织中所代表的角色就是可能与系统发生交互的参与者。当前过程和系统的培训指南及用户手册：这些东西中经常会有潜在参与者。合并需求获得用例绘制用例图细化用例描述搭框架1.用例名称：新增书籍信息（UC01）2.简要说明：录入新购书籍信息，并自动存储建档。3.事件流：3.1 基本事件流3.2 扩展事件流4.非功能需求5.前置条件：用户进入图书管理系统。6.后置条件：完成新书信息的存储建档。7.扩展点：无8.优先级：最高（满意

9、度 5，不满意度5）细化用例描述填血肉3.事件流：3.1 基本事件流1）图书管理员向系统发出“新增书籍信息”请求；2）系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类；3）图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号；4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、开本、页数、定价、是否有CDROM；5）系统确认输入的信息中书名未有重名；6）系统将所输入的信息存储建档。3.2 扩展事件流5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理选择修改书名或取消输入；5a1）图书管理员选择取消输入，则结束用例，不

10、做存储建档工作；5a2）图书管理员选择修改书名后，转到5）4.非功能需求：无特殊要求四、 业务用例图作用：帮助了解机构及其软件系统（或工作内容）；帮助业务过程重建工程工作；帮助员工（小组内成员）充分了解业务及其角色。什么时候需要？对机构不熟悉；机构业务发生变更；机构中主要部分使用的软件需建立；机构中有些大型复杂工作流的文档不足。业务角色（Business Actor）机构（组织）外部参与者业务工人（Business Worker）机构内部参与者所起作用的表示业务用例（Business Use Case）业务功能（无论是手工还是自动处理）业务机构（Business Organization）机构

11、的组织部门 ，业务元素的集合；业务实体（Business Entity）机构的主要产品等实体物理工人（Phsical Worker）机构内部人类参与者五、实例有一个爱书之人，家里各类书籍已过千册，平时又时常有朋友外借，因此需要一个个人图书理系统。该系统应该能够将书籍的基本信息按计机类、非计算机类分别建档，实现按书名、作类别、出版社等关键字的组合查询功能。在使用系统录入新书籍时系统会自动按规则生成书号，以修改信息，但不能够删除记录。该系统还应该够对书籍的外借情况进行记录，可对外借情况列打印。另外，还希望能够对书籍的购买金额、册按特定时限进行统计。 摘自程序员错误（不能用包含）优化练习1网上选课系

12、统： 管理员通过系统管理界面进入，建立本学期要开的各门课程，将课程信息保存在数据库中，并可以对课程进行改动和删除。学生通过浏览器根据学号和密码进入选课界面，在这里学生可以查询已选课程信息并选课，教师可以选择所上课程并提交成绩。管理员负责维护各项信息。这些操作结果存入数据库中。请用UML画出其用例图，并写出详细的用例描述。选课事件流：1、学生进入选课登录界面，用例开始。2、系统提示输入学号和密码。3、学生输入学号和密码。4、系统验证。A1：验证失败5、进入选课主界面。6、学生点击选课。7、系统显示所有课程信息。8、显示选择课程。9、系统验证课程是否可选。A2：不可选10、系统提示课程选择成功，提

13、示学生交费。11、用例结束。错误流：A1：验证失败1、系统提示验证失败，提示重新输入。2、三次失败，拒绝访问。3、成功，转选课事件流第5步。A2：课程不可选1、系统提示课程不可选及原因。2、学生重新选课。3、重新验证直至成功。4、转选课事件流第10步。练习2问题描述 现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警, 并实时打印病人的病情报告，立及更新病历。要求根据现场情景，对医院病房监护系统

14、进行需求分析， 建立系统的Use case model。请对系统需求进行分析！经过初步的需求分析，得到系统功能要求：1. 监视病员的病症（血压、体温、脉搏等）2. 定时更新病历3. 病员出现异常情况时报警。4. 随机地产生某一病员的病情报告。 例2 医院病房监护系统产生病情报告监视病情更新病历简单的需求分析说明系统名称：医院病房监护系统根据分析系统主要实现以下功能：1、病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。2、中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。3、当病症信号异常时，系统自动更新病

15、历并打印病情报告。4、值班护士可以查看病情报告并进行打印。5、医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。6、系统定期自动更新病历。建立系统的用例图1、通过以下六个问题识别角色(1)谁使用系统的主要功能？(2)谁需要系统的支持以完成日常工作任务？(3)谁负责维护，管理并保持系统正常运行？(4)系统需要应付（或处理）哪些硬设备？(5)系统需要和哪些外部系统交互？(6)谁（或什么）对系统运行产生的结果（值）感兴趣？四个角色：值班护士，医生，病人，标准病症信号库。. 识别用例回答下面的问题： 与系统实现有关的主要问题是什么？ 系统需要哪些输入/输出？这些输入/输出从何而来？到

16、哪里去？ 执行者需要系统提供哪些功能？ 执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为： 通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：医院病房监护系统高层用例图 值班护士医生病人标准病症信号库病症监护提供标准病症信号中央监护病历管理病情报告管理进一步将用例细化，即分解用例：1. 中央监护 分解: a 分解信号 将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。 b 比较信号 将病人的病症信号与标准信号比较 。 c 报警 如果病症信号发生异常（即高于峰值），发出报警信号。 d 数据格式化 将处理后的数据格式化以便写入病历库 。2. 病症监护 分解: e 信号采集 采集病人的病症信号。 f 模数转化 将采集来的模拟信号转化为数字信号。 g 信号数据组合 将采集到的脉搏，血压等信号数据组 合为一组信号