文档介绍：一、概述
用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。
用例图最常用来描述系统以及子系统。
第1页/共37页
第一页，共38页。
1 概述
用例图包含6个元素：
参与者（Actor）
用子用例表示父用例的特殊形式。
子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为。
第13页/共37页
第十三页，共38页。
泛化关系（续）
概括表示几个元素的某些共性，例如买票系统中，个人购买和团体购买都是买票特例，具有一些共同的特性。
第14页/共37页
第十四页，共38页。
包含关系
(1)客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。即：在一个用例中重用另一个用例中的步骤。
(2)在种情况下我们引入包含关系:
首先,如果两个以上的用例有相同的功能,则可以将这个功能分解另一个用例中
一个用例的功能太多时,可以用包含关系建模两个小用例.
第15页/共37页
第十五页，共38页。
包含关系(续)
例:在自动饮料售货系统中,用例“放置饮料”和“收钱”都包括打开和关闭机器的功能。由此抽取出这个两个用例，并让用例“放置饮料”和“收钱”包含它们
第16页/共37页
第十六页，共38页。
扩展关系
扩展用例被定义为基础用例的增量扩展。
基础用例提供扩展点以添加新的行为。
扩展用例提供插入片段以插入到基础用例的扩展点上。
即：允许你通过对已有的用例增加步骤创建一个新的用例
它与包含关系相似，这两个关系都是把相同功能分离另一个用例中。扩展只能在特定的设计点发生，称这个点为扩展点
第17页/共37页
第十七页，共38页。
扩展关系(续)
比如：一个订货系统的用例图，订货过程包括客户填写客户信息、订货和付费。因为付费有现金支付和信用卡支付，所以概括这一个抽象的用例。客户可能会提出看一看货物目录的请求，所以从基用例扩展出“请求目录”的用例，以满足客户查看货物目录的要求。
第18页/共37页
第十八页，共38页。
扩展关系(续)
第19页/共37页
第十九页，共38页。
二、用例图建模技术
对语境建模
对需求建模
第20页/共37页
第二十页，共38页。
1 对语境建模
识别系统外部的参与者。
将类似参与者组织成泛化的结构层次。
在需要加深理解的地方，为每个参与者提供一个构造型。
将参与者放入到用例图中，并说明参与者与用例之间的通信路径。
第21页/共37页
第二十一页，共38页。
2 对需求建模
识别系统的外部参与者来建立系统的语境。
考虑每一个参与者期望的行为或需要系统提供的行为。
把这些公共的行为命名为用例。
确定提供者用例和扩展用例。
对这些用例、参与者和它们之间的关系建模。
用注释修饰用例。
第22页/共37页
第二十二页，共38页。
三、实例——学生选课系统的用例图
1 确定系统涉及的总体信息
2 确定系统的参与者
3 确定系统的用例
4 使用Rational Rose绘制用例图的步骤
5 学生选课系统的用例图
第23页/共37页
第二十三页，共38页。
1 确定系统涉及的总体信息
学生：
选课
查询课程
第24页/共37页
第二十四页，共38页。
确定系统涉及的总体信息
管理员：
增加课程
修改课程
删除课程
添加学生帐户
删除或更新学生帐户
第25页/共37页
第二十五页，共38页。
2 确定系统的参与者
首先分析系统所涉及的问题领域和系统运行的主要任务：
分析使用该系统主要功能部分的是哪些人。
谁将需要该系统的支持以完成其工作。
系统的管理者与维护者。
第26页/共37页
第二十六页，共38页。
确定系统的参与者
网上选课系统的参与者：
学生
管理员
第27页/共37页
第二十七页，共38页。
确定系统的用例
1. 学生请求服务的用例
2. 管理员处理课程等的用例
第28页/共37页
第二十八页，共38页。
1. 学生请求服务的用例
登录系统
查询自己的选课
选课
第29页/共37页
第二十九页，共38页。
2. 管理员处理课程的用例
处理学生帐户
处理课程增加
删除课程
修改课程
第30页/共37页
第三十页，共38页。
使用Rational Rose绘制用例图的步骤
1. 创建用例图
2. 用例图工具栏按钮简介
3. 工具栏的定制
4. 添加参与者与用例
5. 添加参与者与用例之间的关系
6. 添加用例之间的关系
第31页/共37页
第三十一页，共38页。
5 学生选课系统的用例图
1. 学