用例图
用例图
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者（即系统的理想用户）有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。
有时，可以将用例的实例引入到图中。
用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。
命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类参与者是其它的系统。
用例图
2001年2.0版 2001年2.0版 稳定流行版本
文字上的修改 没有显著的技 术变化
<documents> UML 0.9 <documents> Unified Method 0.8
1997年国际标准 1997年国际标准
1995年提出 1995年提出UML 年提出UML
UML组成元素UML组成元素-视图 （view） view）
函数
父类
用例
↓
调用
↑
继承
↓
条件触发
↓
子函数
↑
子类
↓
扩展用例
包含关系
泛化关系
扩展关系
实验任务1：在visio2003环境中画出
指导书中的用例图；
实验任务2：在visio2003环境中画某
个实际应用系统的用例图；案例1
案例2 案例2 项目与资源管理系统
系统的主要需求：包括项目管理， 系统的主要需求：包括项目管理，资源管理和系 统管理三大功能。 统管理三大功能。 1. 项目管理包括项目的增加、删除、更新。 项目管理包括项目的增加、删除、更新。 2. 资源管理包括资源和技能的添加、删除和更新。 资源管理包括资源和技能的添加、删除和更新。 3. 系统管理包括系统启动和关闭 ， 数据的存 储 系统管理包括系统启动和关闭， 数据的存储 (分为添加技能和查找技能 和备份功能 （ 分为备 分为添加技能和查找技能)和备份功能 分为添加技能和查找技能 和备份功能（ 份资源数据及备份项目数据） 份资源数据及备份项目数据）等，数据的存储和 备份均需要启动和关闭系统。 备份均需要启动和关闭系统。 技能可指人力资源。 注：技能可指人力资源。
用例图组成
用例图组成：使用者 用例+关系。 用例图组成：使用者+用例+关系。 组成
需求中如何画用例图
需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。
从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。
但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
用例图(User Case)
用例图（User Case）用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义：小人：对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
圈圈：圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。
按着这样的读法，我们可以得到两句完整的句子：“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
大框框：在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
UML用例图介绍
UML用例图介绍目录1、UML用例图概述 (1)2、用例图怎么使用？ (1)3、UML用例图的目的 (2)4、如何画用例图？ (3)1、UML用例图概述用例图捕捉了模拟系统中的动态行为，并且描述了用户、需求以及系统功能单元之间的关系。
用例图展示了一个外部用户能够观察到的系统功能模型图。
用例图由主角，用例和它们之间的关系组成。
2、用例图怎么使用？要了解一个系统的动态，我们需要使用不同类型的图表。
用例图就是其中之一，其具体目的是收集系统的的需求和参与者。
用例图指定系统的事件和他们的流向。
但从未用例图描述了他们是如何实现的。
可以被想象成一个黑盒子，只有输入，输出和黑盒子的功能被称为用例图。
在这些图中使用的设计在一个非常高的水平。
那么这种高层次的设计高雅，一遍又一遍完善使系统得到一个完整实用的图片。
一个结构良好的用例，还介绍了前置条件，后置条件和例外。
而这些多余的元素在执行测试时被用来制造测试的情况下。
用例都不是正向和反向工程，但他们仍然使用略有不同的方式。
同样是真实的逆向工程。
仍用例图的使用方式不同，使其逆向工程的一个候选。
在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节。
所以下面的地方使用用例图：2.1.需求分析和高水平的设计。
2.2.模拟系统的上下文。
2.3.逆向工程。
2.4.Forward engineering.3、UML用例图的目的用例图的目的是捕捉到一个系统的动态方面。
用例图是用来收集系统的要求，包括内部和外部的影响。
这些要求大多是设计要求。
所以，分析一个系统时要收集其功能用例和确定参与者。
简单来说，用例图的目的如下：3.1.用例图用来收集系统的要求。
3.2.用例图用于获取系统的外观图。
3.3.用例图识别外部和内部因素影响系统。
3.4.用例图显示要求之间的相互作用是参与者。
4、如何画用例图？用例图被认为是高层次的需求分析系统。
因此，当系统的要求，分析被捕获在用例的功能。
用例图(User Case)
用例图（User Case）用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义：小人：对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
圈圈：圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。
按着这样的读法，我们可以得到两句完整的句子：“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
大框框：在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
用例图
• Abstract（抽象参与者）
3 参与者规范及应用
3.1 参与者规范
– Relations标签
• 列出了参与者参与的所 有关系。包括参与者与 用例、参与者与其他参 与者的一切关系
3 参与者规范及应用
3.2 参与者的操作
– 1）增加参与者 – 2）删除参与者
4 用例规范及应用
用例图及其应用
内 容
基本概念
关系及其应用
参与者规范及应用
用例规范及应用
用例视图
1 基本概念
用例图由三部分组成：
– 参与者（角色）（actor） – 一组（个）用例 (usecase) – 关系
1 基本概念
1.1 参与者
– 定义 • 是直接与系统相互作用的系统、子系统或 类的外部实体的抽象。它是用户所扮演的 角色，是系统的用户。每个参与者定义了 一个角色集合。通常，一个参与者可以代 表一个人、一个计算机子系统、硬件设备 或者时间等角色。典型的参与者如销售部 经理、销售员和结帐系统。 – 图形表示 • 用小人图符表示
– 定义
• 存在于两个模型要素之间的一种关系，其中一个 模型要素的改变将影响另一个模型要素
– 表示方法
• 工具箱和模型图中均表示为一个带箭头的虚线 • 画图时，拖动鼠标从客户到提供者画出关联关系
2 关系及其应用
2.3 泛化关系
– 定义
• 在一个更一般的模型要素和另一个较具体的模型 要素之间存在的一种关系，通常用于表示类（包 括用例、参与者等）之间的继承关系
3 参与者规范及应用
3.1 参与者规范
– Rose在实现中对参与者和类使用相同的规 范窗口，包括如下一些标签：
用例图
用例图的Rose建模 建模 用例图的
RecordGrade
QueryGrade Teacher Student ModifyGrade
一、创建用例图 右击“ 右击“use case view” -new->use case diagram
二、重命名用例图并双击打开用例图窗口
用例 参与者 关联 扩展或包含 泛化
实例： 实例：学生管理系统
（4）意义 它有助于在将来实现系统时，确定哪些功能可以重用， 它有助于在将来实现系统时，确定哪些功能可以重用， 在编写代码时就可实现代码的重用，缩短开发周期。 在编写代码时就可实现代码的重用，缩短开发周期。
提示：执行基用例时，每次都必须调用被包含用例。 提示：执行基用例时，每次都必须调用被包含用例。
用例名称 标识符 基本操作流程
归还图书 UC0002 1.图书管理员输入图书信息 图书管理员输入图书信息 2.检索借阅该图书的借阅者的信息 检索借阅该图书的借阅者的信息 3.删除与该图书相关的借阅记录 删除与该图书相关的借阅记录 1a.图书管理员发现图书被损坏，进行损坏处罚 图书管理员发现图书被损坏， 图书管理员发现图书被损坏 1b.输入的图书不存在时，进行确认 输入的图书不存在时， 输入的图书不存在时 2a.借阅者有超期的借阅信息时，进行超期处理 借阅者有超期的借阅信息时， 借阅者有超期的借阅信息时
myCoat.pay(); } }
（3）使用场合 ） 对扩展用例的限制规则： 对扩展用例的限制规则：将一些常规的动作放在一个基本 用例中； 用例中；将可选的或只在特定条件下才执行的动作放在它 的扩展用例中。 的扩展用例中。
练习： 练习：图书管理系统
——摘自《程序员》
答案一： 答案一：
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例的名称有两种： ① 简单名，如：AddItem ② 路径名，如：Business::Maintenance
识别用例
识别用例最好的方法就是从分析系统的参 与者开始，考虑每个参与者是如何使用系 统的。 如何识别用例。
用例与事件流
事件流描述系统“做什么”，而不是“怎 么做”，它通常包括： 1. 简要说明； 2. 前提条件； 3. 主事件流、其他事件流、错误流； 4. 事后条件。
1. 借阅者请求服务的用例 2. 图书馆管理员处理借书、还书等的用例 3. 系统管理员进行系统维护的用例
1. 借阅者请求服务的用例
① ② ③ ④ ⑤ ⑥ 登录系统 查询自己的借阅信息 查询书籍信息 预定书籍 借阅书籍 归还书籍
2. 图书馆管理员处理借书、还书的用例
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
31
面向对象分析与设计 & UML
3.7 寻找用例的方法
发现用例的一般原则：
与用户交互 假设自己是参与者, 与系统进行交互 确定用例和确定参与者不能截然分开
Jacobson提供的一些原则:
32
参与者的主要任务是什么? 参与者需要了解系统的什么信息? 需要修改系统的什么信息? 参与者是否需要把系统外部的变化通知系统? 参与者是否希望系统把异常情况通知自己?
确定参与者
如何寻找系统的参与者； 对参与者建模的过程中需要注意的问题。
参与者间的关系
在用例图中，使用泛化 关系来描述多个参与者 之间的公共行为。 参与者间的泛化关系 示例：
5.1.3 用例（Use Case）
用例是外部可见的系统功能单元。 用例的用途是在不揭示系统内部构造的前提 下定义连贯的行为。 用例不是需求或功能的规格说明，但是也展 示和体现其所描述的过程中的需求情况。
(2) 储户按“取款”按钮,并输入 • 设置交易类型为“取款” 取款数目 • ATM系统获得取款金额 (3) 储户取走现金/ATM卡/收据 • 输出现金、收据和ATM卡 (4) 储户离开
只描述了actor的行为
29 面向对象分析与设计 & UML
• 系统复位
只描述了System的行为
3.6 用例的描述
网上预订
填写电子表格
5.1 包含关系
15
面向对象分析与设计 & UML
扩展关系
扩展用例被定义为基础用例的增量扩展。 基础用例提供扩展点以添加新的行为。 扩展用例提供插入片段以插入到基础用例的扩展 点上。
如：
<<extend>>
还车
交纳罚金
5.1 扩展关系
17
面向对象分析与设计 & UML
确定参与者
参与者
学生 教师
系统管理员
确定与参与者相关的用例
5.3.5 图书馆管理系统的用例图
1. 借阅者请求服务的用例图 2. 图书馆管理员处理借书、还书的用例图 3. 系统管理员进行系统维护的用例图
1. 借阅者请求服务的用例图
2. 图书馆管理员处理借书、还书的 用例图
3. 系统管理员进行系统维护的用例图
实例分析—网络教学系统
学生可以登录网站浏览信息、查找信息和 下载文件 教师可以登录网站输入课程简介、上传课 件、发布消息、修改和更新消息 系统管理员对页面维护以及处理注册申请
28
面向对象分析与设计 & UML
3.6 用例的描述
ATM系统“取款”用例的两个错误描述：
Use case: Withdraw cash Actor: customer 主事件流： (1) 储户插入ATM卡,并输入密码 Use case: Withdraw cash Actor: customer 主事件流： • ATM系统获得ATM卡和密码
5.1.2 参与者（Actor）
系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统 输入某些事件来触发系统的 执行。 由参与用例时所担当的角色 来表示。 每个参与者可以参与一个或 多个用例。
① ② ③
参与者的种类： 系统用户； 与所建造的系统交互的其他系统； 一些可以运行的进程 。
频率[可选]
27
参与者访问此用例的频率, 如: 每日一次/每月一次等
面向对象分析与设计 & UML
例：用例“处理订单”的描述
3.6 用例的描述
描述用例时易出现的错误：
只描述系统的行为, 没有描述参与者的行为
只描述参与者的行为, 没有描述系统的行为 在用例描述中就设定了对用户界面的设计的要求 描述过于冗长
ATM系统“取款”用例的正确描述：
Use case: Withdraw cash Actor: customer 主事件流： • 储户通过读卡机插入ATM卡 • ATM系统从卡上读取银行ID、账号、加密密码, 并通过主银行 系统验证银行ID和账号 • 储户输入密码, ATM系统根据加密密码对输入密码进行验证 • 储户按 “取款”按钮, 并输入取款数目, 该数目应该为$5的倍 数 • ATM系统通知主银行系统, 传递账号和金额, 并接收返回的确认 信息和账户余额 • ATM系统输出现金、ATM卡和收据 • ATM系统记录交易到日志文件
3.8 常见问题分析
(2) 四轮马车 系统中相似的功能, 是合并为一个用例还是 分解为几个用例?
方法1 一个用例/三个脚本
方法2 三个用例
36
面向对象分析与设计 & UML
3.8 常见问题分析
(4) 下面哪个用例图正确?
37
面向对象分析与设计 & UML
5.3 实例——图书馆管理系统的用例图
5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 确定系统涉及的总体信息 确定系统的参与者 确定系统的用例 使用Rational Rose绘制用例图的步骤 图书馆管理系统的用例图
30 面向对象分析与设计 & UML
3.7 寻找用例的方法
用例分析的基本步骤：
①
② ③ ④
找出系统外部的参与者和外部系统, 确定系统边界和范围
确定每一个参与者所期望的系统行为 把这些系统行为命名为用例 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分
⑤
⑥ ⑦ ⑧
编制每一个用例的脚本
绘制用例图 区分主要事件流和异常事件流, 如果需要, 可以把异常事件流处 理为单独的用例 细化用例图, 解决用例间重复与冲突的问题.
描述项
被泛化的用 例 此用例所泛化的用例列表 此用例所包含的用例列表 此用例所扩展的用例列表 关于用例的修改时间、修改原因、修改人的详细信息 与此用例的开发有关的问题列表 关键决策的列表, 将这些决策信息记录下来以便维护时使 用
说明
被包含的用 例
被扩展的用 例 修改历史记 录[可选] 问题[可选] 决策[可选]
5.1 几种关系的比较
关系类型 关联 说明 actor与use case 之间 表示符号
泛化
包含 扩展
21
actor之间或use case之间
use case之间 use case之间
面向对象分析与设计 & UML
5.2 用例图建模技术
5.2.1 对语境建模 5.2.2 对需求建模
5.2.1 对语境建模
5.2 用例的描述
用例描述一般包括的内容：
用例的目标
用例是怎么启动的 参与者与用例之间的消息如何传送
用例中除了主路径外, 其它路径是什么
用例结束后系统的状态 其它需要描述的内容 描述用例时的原则是尽可能写得“充分”, 而不是形式 化、完整或漂亮.
25 面向对象分析与设计 & UML
5.1.4 用例间的关系
1 2 3 4 关联关系 包含关系 扩展关系 泛化关系
关联关系
表示参与者与用例之间进行通信。 不同的参与者可以访问相同的用例。
包含关系
客户用例可以简单地包含提供者用例具有的行为， 并把它所包含的用例行为作为自身行为的一部分。
如：
<<include>>
3. 系统管理员进行系统维护的用例
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ 查询借阅者信息 查询书籍信息 增加书目 删除或更新书目 增加书籍 删除书籍 添加借阅者帐户 删除或更新借阅者帐户
5.3.4 使用Rational Rose绘制用例图 的步骤
1. 2. 3. 4. 5. 6. 创建用例图 用例图工具栏按钮简介 工具栏的定制 添加参与者与用例 添加参与者与用例之间的关系 添加用例之间的关系
前置条件
后置条件 基本操作流 程
一个条件列表, 这些条件必须在访问用例前得到满足
一个条件列表, 这些条件必须在用例完成之后得到满足 描述用例中各项工作都顺利进行时用例的工作方式
可选操作流 描述变异工作方式、出现异常或发生错误的情况下的路径 26程 面向对象分析与设计 & UML
3.6 用例的描述
用例的描述格式(续表)
第5章 用例图
5.1 用例图的概念 5.2 用例图建模技术 5.6 实例——图书馆管理系统中的 用例图
5.1.1 概述
用例图显示谁将是相关的用户、用户希望系统提 供什么服务以及用户需要为系统提供的服务。 用例图最常用来描述系统以及子系统。
5.1.1 概述
① ② ③ ④ ⑤ ⑥ 用例图包含6个元素： 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization）
强调的是：系统的外部参与者。